The whole process of CreateFile function execution

Ring3 process of CreateFile

HANDLE CreateFileA(
  LPCSTR                lpFileName,
  DWORD                 dwDesiredAccess,
  DWORD                 dwShareMode,
  LPSECURITY_ATTRIBUTES lpSecurityAttributes,
  DWORD                 dwCreationDisposition,
  DWORD                 dwFlagsAndAttributes,
  HANDLE                hTemplateFile
);

CreateFile is a very common function. When writing code in VS, or F8 when Debugging, no one cares what process a CreateFile goes through and what kind of operating mechanism to open the file. Interested in researching it today. The research must be thoroughly studied, so that you will feel a little bit of pleasure when you call each API in the future.

CreateFile in Kernel32.dll. Just a sentence of jmp, this indirect dynamic jump instruction. Through X64dbg, you can see that it jumped to Kernelbase32.dll.

Add the "/??/" symbol to the opened file path in Kernelbase32.dll, and execute the __GSHandlerCheck code in the figure below after the CreateFileInternal function.

This GSHandlerCheck code is not very clear, and it feels less important. It should be some preparatory work for entering Ring0. Study more when you have time.

Finally, the NtCreateFile function is called. The next step will go to ntdll.dll to execute NtCreateFile. For some APIs under Ring3, it will eventually correspond to a Ntxxx function (that is, Native API) in Ntdll.dll. For example, this CreateFile finally calls the NtCreateFile function in Ntdll.dll. NtCreateFile finally puts the system service number into EAX, and then an address stored at 7FFE0300 of the CALL system (more on that later), enters the kernel, from Ring3->Ring0, and finally get the kernel address of the corresponding system service with the same name through the incoming EAX in Ring0.

For NtCreateFile, it is the same as ZwCreateFile. The program will enter the system call at the ntdll layer and enter the Ring0 layer.
The above picture 0x55 is the SSDT call number of the NtCreateFile function on this system. This system supports the syscall instruction, so the old version of int 0x2E will not be executed to enter the system kernel. The SSDT table is a storageFunction pointerTables, and these function pointers point to important service routines of the system. The importance of this table is very high. If a malicious program hooks this table and modifies the fake service routine provided by the service routine address, then it can do some bad things.

As shown in the figure above, after entering Ring0, many registers have changed. So far, our X64dbg can no longer be debugged, and we can't go deeper. Changing the tool Windbg, OD debugging 32-bit programs is the same, unable to go deep into the syscall kernel layer to continue tracking.

Continue to track the Ring0 process

The following process is: KiFastSystemCall->sysenter->KiFastCallEntry->Find SSDT and call in the past. Students who are interested can search for related functions in WRK to walk through the process.
Welcome to the kernel address space of 0x80000000-0xFFFFFFFF, the debugger is obsolete, but we can use itBTS driverContinue to capture the execution process and track it down.
There are too many HOOKs and countermeasures on Ring3, especially SSDT HOOK, which is the most common and easy to detect (directly compare the hard-coded copy in the kernel with the kernel address in the memory). But once the adversary (if it's a kernel-level rootkit) installs the driver in the machine, CreateFile's confrontation is a Ring0-level confrontation.
From Pchunter, you can see that the file location of SSDT is in ntoskr.exe (if you have not been HOOKed). You can also find the SSDT call number of NtCreateFile.

Find the implementation of NtCreateFile in ntoskrnl.exe. Note that this NtCreateFile has nothing to do with Ring3's NtCreateFile. Although they have the same name, they are in two different worlds, so there is no error (just like you and your antimatter) …). The IopCreateFile function is called again in the function. Obviously, the story of CreateFile is still very long.

No more nonsense, the above figure is the rest of the call flow. The above figure uses the IopCreateFile function of the IO manager. Inline Hook IopCreateFile function see see snow forum: Inline Hook IopCreateFile function . The common realization function of IoCreateFile in driver development is IopCreateFile(iosubs.c).

After this is the function of the file management driver. The I/O manager acts as the interface between the user mode code and the driver. The driver will process or forward the IRP sent by the I/O manager in a safe and stable manner, and finally complete the interaction with the hardware abstraction layer hal.dll, complete and feed back the CreateFile operation request.

to sum up

It can be seen that the whole process of calling the CreateFile function involves too much knowledge of the Windows platform. Win32 API interface, kernel principle and structure, driver development, etc. are all involved. At first glance, it seems that the process of opening a file in CreateFile is very complicated, and the file device I/O can be operated directly with the assembly instruction IN OUT. Why is such a complicated process required on windows? The answer is two words-Safety. It can be seen that the more mature and unified products, the greater the price paid for safety.
The Rootkit virus program may HOOK one of the functions during any of the above processes to reach the reading and opening of the control file (device). Therefore, for a long time, the technical confrontation between security software and virus development will not leave this necessary front. It has been doing HOOK and anti-HOOK, and ending the struggle with being ended. The traditional solution still stays on this kind of function-level confrontation.
There is no end to learning, and there is still a long way to go for the study and research of Windows.