\n\nThis page has been machine-translated from the original page.
\n
In Chapters 3 and 4, we analyzed DoPClient and identified the password (the first Flag).
\nAs confirmed in Chapter 3, when the correct password is entered into DoPClient, the program prints the strings Password is Correct and Clear Stage1 in sequence, then loads the kernel driver DoPDriver.sys and uses the CreateFileW function on the driver object.
In Chapters 4 and 5, we analyze the kernel driver module DoPDriver in order to identify the second Flag.
\n\nIRP_MJ_CREATE Callback FunctionIRP_MJ_CLOSE Callback FunctionAs confirmed in Chapter 2, the DoPDriver.sys file, which is a Windows kernel driver module, is also built as a file in PE format, just like a user-mode program.
\nTherefore, DoPDriver.sys can also be statically analyzed with analysis tools such as Binary Ninja, just like DoPClient.exe.
\nHowever, you need to be careful because a kernel driver module like DoPDriver has a slightly different structure from a user-mode program like DoPClient.
\nFor example, a user-mode program written in C starts from the main function, but Windows kernel drivers do not have a main function.
\nIn Windows kernel drivers, the DriverEntry function is configured as the entry point, and it is executed first when the kernel starts the driver module.1
\nTherefore, when statically analyzing a kernel driver file, identifying this DriverEntry function first is one useful approach.
\nThe DriverEntry function of a Windows kernel driver module is defined as follows. The first argument is a pointer to a DRIVER_OBJECT structure, and the second argument is a pointer to the path string of the driver’s registry key.2
DRIVER_INITIALIZE DriverEntry;\n\n_Use_decl_annotations_ NTSTATUS DriverEntry( \nstruct _DRIVER_OBJECT *DriverObject,\nPUNICODE_STRING RegistryPath \n)\n{\n // Function body\n}Note that the example above is code for creating a WDM (Windows Driver Model) driver, which has been available since Windows 98. However, the fact that the DriverEntry function is executed when the driver starts and that pointers to a DRIVER_OBJECT structure and a registry-key path string are passed as arguments is also common to KMDF/UMDF, which are supported from Windows Vista onward. (That said, KMDF and UMDF drivers require significantly different code from WDM drivers—for example, they must create a WDFDRIVER object with the WdfDriverCreate function.)3
The easiest way to identify the DriverEntry function is to use an analysis tool such as Binary Ninja to find the entry point that receives DriverObject and RegistryPath as arguments, and then identify the function called with DriverObject as an argument.
\nHowever, in this chapter, we will try another approach that uses the characteristics of the DriverEntry function to identify its address.
\nTo identify the DriverEntry function by analyzing DoPDriver.sys, first load DoPDriver.sys into Binary Ninja and open the Symbols window.
\nBecause no symbols are present, you cannot find the DriverEntry function from the Symbols window.
\nHowever, because the exported functions do not include Wdf* or Wpp*, we can judge that it is more likely a WDM driver than a KMDF/UMDF driver.
For example, a simple KMDF driver looks like the following when analyzed in Binary Ninja. (This is not the DoPDriver.sys analysis screen.)
\nClicking this address reveals a function that receives a pointer to a DRIVER_OBJECT structure as an argument and calls the IoCreateDevice function.
The first block creates a device object with the IoCreateDevice function.
\nDriverEntry:\nmov r11, rsp {__return_addr}\npush rbx {__saved_rbx}\nsub rsp, 0x60\nlea rax, [rel sub_140001280]\nmov dword [rsp+0x40 {DeviceName}], 0x240022\nmov qword [rcx+0x68], rax {sub_140001280}\nlea r8, [r11-0x28 {DeviceName}]\nlea rax, [rel sub_1400011a0]\nmov r9d, 0x22\nmov qword [rcx+0x70], rax {sub_1400011a0}\nxor edx, edx {0x0}\nlea rax, [rel sub_140001180]\nmov qword [rcx+0x80], rax {sub_140001180}\nlea rax, [rel data_140001590] {u\"\\Device\\DoPDriver\"}\nmov qword [r11-0x20 {var_20}], rax {data_140001590, u\"\\Device\\DoPDriver\"}\nlea rax, [r11+0x8 {DeviceObject}]\nmov qword [r11-0x38 {var_38}], rax {DeviceObject}\nmov byte [rsp+0x28 {var_40}], 0x0\nand dword [rsp+0x20 {var_48}], 0x0\ncall qword [rel IoCreateDevice]\ntest eax, eax\njns 0x140001238The IoCreateDevice function takes the following arguments and creates the device object used by the driver.5
\nNTSTATUS IoCreateDevice(\n [in] PDRIVER_OBJECT DriverObject,\n [in] ULONG DeviceExtensionSize,\n [in, optional] PUNICODE_STRING DeviceName,\n [in] DEVICE_TYPE DeviceType,\n [in] ULONG DeviceCharacteristics,\n [in] BOOLEAN Exclusive,\n [out] PDEVICE_OBJECT *DeviceObject\n);Clicking the IoCreateDevice function in Binary Ninja’s Graph view is very convenient because it analyzes the arguments for you in the Cross References window, as shown below.
\nThe first argument, arg1, uses the pointer to the DRIVER_OBJECT structure that the DriverEntry function received as an argument.
Also, DeviceName uses the name of the device object defined inside the function.
\nAt this point, note that the string used as DeviceName is a pointer to an object of the UNICODE_STRING structure 9.
typedef struct _UNICODE_STRING {\n USHORT Length;\n USHORT MaximumLength;\n PWSTR Buffer;\n} UNICODE_STRING, *PUNICODE_STRING;Many functions used by Windows kernel drivers use safe string objects, such as the UNICODE_STRING structure, that take proper buffer handling into account from the standpoint of software safety.10
As mentioned above, a string represented by a UNICODE_STRING structure is not a simple string. It is passed to functions such as IoCreateDevice as a structure that includes elements such as the buffer size.
For that reason, you need to keep this point in mind especially when performing dynamic analysis with a debugger.
\nLet’s actually read the code that prepares DeviceName, which is an argument to IoCreateDevice.
\nmov r11, rsp {__return_addr}\npush rbx {__saved_rbx}\nsub rsp, 0x60\n***\nmov dword [rsp+0x40 {DeviceName}], 0x240022\n***\nlea r8, [r11-0x28 {DeviceName}]\n***\nlea rax, [rel data_140001590] {u\"\\Device\\DoPDriver\"}\nmov qword [r11-0x20 {var_20}], rax {data_140001590, u\"\\Device\\DoPDriver\"}Binary Ninja interprets the stack area at address RSP+0x40 as DeviceName.
However, in the code mov dword [rsp+0x40 {DeviceName}], 0x240022, the value stored in that area is 0x240022 rather than a string.
This is because, as explained earlier, DeviceName is defined not as a plain string but as an object of the UNICODE_STRING structure.
In a UNICODE_STRING structure, the first 2 bytes store Length and the next 2 bytes store MaximumLength.
In other words, storing 0x240022 in the stack area at RSP+0x40 corresponds to writing a UNICODE_STRING structure whose Length is 0x22 and whose MaximumLength is 0x24.
The pointer to the actual string (\\Device\\DoPDriver) is stored in the Buffer field of the UNICODE_STRING structure.
You can also confirm this by running the dt nt!_UNICODE_STRING rsp+0x40 command when dynamically analyzing the DriverEntry function during kernel debugging.
kd> dt nt!_UNICODE_STRING rsp+0x40\n***\n+0x000 Length : 0x22\n+0x002 MaximumLength : 0x24\n+0x008 Buffer : 0xfffff807`100a1590 \"\\Device\\DoPDriver\"Also, DeviceType, the argument after DeviceName, receives a value indicating the device type.
\nIn DoPDriver, DeviceType is set to 0x22, which corresponds to FILE_DEVICE_UNKNOWN, indicating that it is not a standard Windows device.11
When the IoCreateDevice function is called with these arguments, a pointer to the DEVICE_OBJECT structure is stored at the address pointed to by the DeviceObject argument.
If creating the device object succeeds, the following code after 0x140001238 is executed.
\nlea rax, [rel data_140001570] {u\"\\??\\DoPDriver\"}\nmov dword [rsp+0x50 {SymbolicLinkName}], 0x1c001a\nlea rdx, [rsp+0x40 {DeviceName}]\nmov qword [rsp+0x58 {var_10_1}], rax {data_140001570, u\"\\??\\DoPDriver\"}\nlea rcx, [rsp+0x50 {SymbolicLinkName}]\ncall qword [rel IoCreateSymbolicLink]\nmov ebx, eax\ntest eax, eax\njns 0x140001274This code uses the IoCreateSymbolicLink function 12 to create a symbolic link (\\??\\DoPDriver) corresponding to the device object.
The actual device object created by the IoCreateDevice function exists at \\Device\\DoPDriver, but as explained in Chapter 3, a user-mode process cannot directly access device objects in the \\Device directory.
Therefore, if a user-mode program such as DoPClient needs to access the driver, the kernel driver must create a symbolic link in the \\GLOBAL\\?? directory and link it to the name of the device object in the \\Device directory.
In the code above, the symbolic link for the device object at \\Device\\DoPDriver is registered as \\??\\DoPDriver.
In the DriverEntry function, only the device object was created and the symbolic link for that device object was registered.
\nSo where is the code that runs when the user-mode program DoPClient uses DoPDriver?
\nIn the case of WDM drivers, the interface commonly used to execute driver operations in response to requests from applications is the dispatch routine defined by the entries in the MajorFunction array of the driver object.
\nThe MajorFunction array of the driver object contains callback functions corresponding to open (CreateFile) and close (CloseHandle), as well as read and write (ReadFile/WriteFile), and DeviceIoControl operations from user-mode programs.
\nWhen a user-mode program performs these operations on a device driver, the system’s I/O manager allocates an I/O Request Packet (IRP) and executes the driver’s dispatch routine corresponding to that request.13
\nAs confirmed earlier in this chapter, the MajorFunction array is defined as PDRIVER_DISPATCH MajorFunction[***]; starting at offset 0x70 of the DRIVER_OBJECT structure.
In DoPDriver, the callback functions for two dispatch routines were set in the driver object at 0x1400011f8 and 0x1400011fe in the DriverEntry function.
\nmov qword [rcx+0x70], rax {sub_1400011a0}\n***\nmov qword [rcx+0x80], rax {sub_140001180}The MajorFunction array is defined as PDRIVER_DISPATCH MajorFunction[***];, and in a C implementation it would be written as DriverObject->MajorFunction[IRP_MJ_CREATE] = <pointer to the callback function>.
Constants such as IRP_MJ_CREATE and IRP_MJ_CLOSE are defined in wdm.h and correspond to the following values.
IRP_MJ_CREATE 0x00\nIRP_MJ_CREATE_NAMED_PIPE 0x01\nIRP_MJ_CLOSE 0x02\nIRP_MJ_READ 0x03\nIRP_MJ_WRITE 0x04\nIRP_MJ_QUERY_INFORMATION 0x05\nIRP_MJ_SET_INFORMATION 0x06\nIRP_MJ_QUERY_EA 0x07\nIRP_MJ_SET_EA 0x08\nIRP_MJ_FLUSH_BUFFERS 0x09\nIRP_MJ_QUERY_VOLUME_INFORMATION 0x0a\nIRP_MJ_SET_VOLUME_INFORMATION 0x0b\nIRP_MJ_DIRECTORY_CONTROL 0x0c\nIRP_MJ_FILE_SYSTEM_CONTROL 0x0d\nIRP_MJ_DEVICE_CONTROL 0x0e\nIRP_MJ_INTERNAL_DEVICE_CONTROL 0x0f\nIRP_MJ_SHUTDOWN 0x10\nIRP_MJ_LOCK_CONTROL 0x11\nIRP_MJ_CLEANUP 0x12\nIRP_MJ_CREATE_MAILSLOT 0x13\nIRP_MJ_QUERY_SECURITY 0x14\nIRP_MJ_SET_SECURITY 0x15\nIRP_MJ_POWER 0x16\nIRP_MJ_SYSTEM_CONTROL 0x17\nIRP_MJ_DEVICE_CHANGE 0x18\nIRP_MJ_QUERY_QUOTA 0x19\nIRP_MJ_SET_QUOTA 0x1a\nIRP_MJ_PNP 0x1b\nIRP_MJ_PNP_POWER IRP_MJ_PNP\nIRP_MJ_MAXIMUM_FUNCTION 0x1bIn other words, because DoPDriver registers dispatch routines at RCX+0x70 and RCX+0x80, we can determine that DriverObject->MajorFunction[0(IRP_MJ_CREATE)] and DriverObject->MajorFunction[2(IRP_MJ_CLOSE)] are implemented.
IRP_MJ_CREATE Callback FunctionThe callback function registered in DriverObject->MajorFunction[0(IRP_MJ_CREATE)] is at address 0x1400011a0.
The result of analyzing this function in Binary Ninja’s Graph view is shown below.
\nThe IofCompleteRequest function 14 called first is a macro that completes I/O processing and returns the IRP received by the driver to the I/O manager.
This code appears to return the IRP immediately without performing any I/O processing, but if a device driver uses an IRP, some operation is performed on that IRP before IofCompleteRequest is executed.
Besides IofCompleteRequest, this callback function also executes the PsSetCreateProcessNotifyRoutine function 15.
\nPsSetCreateProcessNotifyRoutine is a function that can add or remove a callback routine specified by the device driver to the routines executed each time a process is created or deleted.
\nNTSTATUS PsSetCreateProcessNotifyRoutine(\n [in] PCREATE_PROCESS_NOTIFY_ROUTINE NotifyRoutine,\n [in] BOOLEAN Remove\n);By using this function, a device driver can execute arbitrary code whenever a new process is created or deleted in the system.
\nPsSetCreateProcessNotifyRoutine is also used in part by PROCMON24.SYS, which Sysinternals Procmon depends on.
\nInside DoPDriver, PsSetCreateProcessNotifyRoutine is called with the following code.
\nHere, the function pointer at 0x1400012e0 is passed as the first argument, and PsSetCreateProcessNotifyRoutine adds it as a callback routine.
\nxor edx, edx {0x0}\nlea rcx, [rel sub_1400012e0]\nadd rsp, 0x28\njmp qword [rel PsSetCreateProcessNotifyRoutine]Because the function at address 0x1400012e0 that is added to the callback routine is related to identifying the second Flag, we will analyze it in a later section.
\nIRP_MJ_CLOSE Callback FunctionThe address of the callback function registered in the other DriverObject->MajorFunction[2(IRP_MJ_CLOSE)] is 0x140001180.
The disassembled code for this function is shown below, and it does nothing except return the IRP through IofCompleteRequest.
\nTherefore, it seems safe to ignore this function.
\nsub_140001180:\nsub rsp, 0x28\nand dword [rdx+0x30], 0x0\nmov rcx, rdx\nand qword [rdx+0x38], 0x0\nxor edx, edx {0x0}\ncall qword [rel IofCompleteRequest]\nxor eax, eax {0x0}\nadd rsp, 0x28\nretn {__return_addr}The address of the callback function registered with PsSetCreateProcessNotifyRoutine inside the dispatch routine registered by DriverObject->MajorFunction[0(IRP_MJ_CREATE)] was 0x1400012e0.
Because this function references the string FLAG{The_important_process_is_, we can expect that it performs some processing related to identifying the second Flag.
First, let’s analyze the following code block immediately after the function call.
\nmov qword [rsp+0x8 {__saved_rbx}], rbx\nmov qword [rsp+0x18 {__saved_rdi}], rdi\npush rbp {__saved_rbp}\nmov rbp, rsp {__saved_rbp}\nsub rsp, 0x80\nand qword [rbp-0x60 {var_68}], 0x0\nmov rax, rdx\nmov rcx, rax\nlea rdx, [rbp-0x60 {var_68}]\ncall qword [rel PsLookupProcessByProcessId]\nmov rcx, qword [rbp-0x60 {var_68}]\ncall PsGetProcessImageFileName\nmov rcx, qword [rbp-0x60 {var_68}]\nmov rbx, rax\ncall qword [rel ObfDereferenceObject]\nmov rcx, rbx\ncall sub_140001000\ntest eax, eax\njne 0x1400013ecThis code block first calls the PsLookupProcessByProcessId function 16 with the process ID that the callback function received as its second argument.
\nNTSTATUS PsLookupProcessByProcessId(\n [in] HANDLE ProcessId,\n [out] PEPROCESS *Process\n);Because this function is the callback routine registered with PsSetCreateProcessNotifyRoutine, it receives three arguments: ParentId, ProcessId, and Create.17
\nPCREATE_PROCESS_NOTIFY_ROUTINE PcreateProcessNotifyRoutine;\n\nvoid PcreateProcessNotifyRoutine(\n [in] HANDLE ParentId,\n [in] HANDLE ProcessId,\n [in] BOOLEAN Create\n)\n{...}In other words, the PsLookupProcessByProcessId function receives the ProcessId value taken by this callback routine and obtains a pointer to the EPROCESS structure for that process.
\nThe pointer to the EPROCESS structure obtained here is stored in the stack area RBP-0x60.
The next code uses this pointer address to execute the PsGetProcessImageFileName function 18, obtaining the image file name of the process captured by the callback routine.
\nLPSTR NTAPI PsGetProcessImageFileName(PEPROCESS Process){\n return (LPSTR)Process->ImageFileName;\n}PsGetProcessImageFileName is an undocumented function, but it has been introduced in sources such as Sysinternals newsletters as a function that can be used to obtain a process image file name.
\nAfter PsGetProcessImageFileName obtains the image file name, the function at address 0x140001000 is executed using the obtained file name as an argument.
\ncall PsGetProcessImageFileName\n***\nmov rbx, rax\n***\nmov rcx, rbx\ncall sub_140001000When analyzing this function in Graph view, you can see that it implements very complex branching using the received file name, and at first glance it is difficult to determine the detailed behavior.
\n