Icesword Driver Analysis

Icesword driver

When icesword.exe is executed, a driver ispubdrv.sys,icesword.exe will be released to load the driver, which will not be uninstalled after installation. Until the system restarts. This may be because the driver calls the pssetcreatethreadpolicyroutine function. The following describes the function in DDK. //////////////////////////////////////// /////// Pssetcreatethreadpolicyroutine registers a driver-supplied callback that is subsequently notified when a new thread is created and when such a thread is deleted. Ntstatus Pssetcreatethreadpolicyroutine ( In pcreate_thread_policy_routine policyroutine ); Any driver that successfully registers such a callback must remain loaded until the system itself is shut down. //////////////////////////////////////// ////// Although DDK says that a successful call to the pssetcreatethreadpolicyroutine function requires the driver to be retained until the system restarts, there is still a way to uninstall it. How does icesword list hidden processes? Icesword uses the pspcidtable table to limit the process. pspcidtable is not exported by ntoskrnl.exe. This involves how to locate pspcidtable. Icesword searches for feature strings to locate pspcidtalbe. pspcidtable is a handle_talbe structure. The pspcidtalbe variable will be referenced in the pslookupprocessbyprocessid function. Icesword searches for the pspcidtalbe variable from the dozens of bytes before the pslookupprocessbyprocessid function. Some people may think, so I sent the pslookupprocessbyprocessid function to the patch. Why can't he find the pspcidtalbe variable? Yes, you can. Of course we can think of this. The author of icesword can also think of this. In order to prevent you from doing so, the author also takes corresponding countermeasures. His countermeasure is to run the pre-validation restoration method. When executing key system functions, it compares the dozens of bytes in the function's header to determine whether the function has been modified. If it is modified, it will restore the modified content to the original content of the system. Then we may ask a question, how can I know the original content of the system if I patch the function to validate before it starts? This is a good question. Now let's take a look at how the icesword author achieves this. Take The pslookupprocessbyprocessid function. The pslookupprocessbyprocessid function is exported from the ntoskrnl.exe file. The author does not use our usual method to locate the pslookupprocessbyprocessid function, that is, ispubdrv. sys does not import this function. Similarly, the address of pslookupprocpolicyprocessid is not obtained through the mmgetsystemroutineaddress function. So how does he get the pslookupprocessbyprocessid address? Then, some people will think about how to open the ntoskrnl.exe file and analyze and export the function. This is what icesword authors do. Of course, he is still skillful here. The operating file of the author does not use the operating file that we often use to write the driver to access the file. We usually use zwcreatefile, zwopenfile, zwreadfile, zwwritefile, ntcreatefile, and other functions to open and read files in the driver. In this way, the author can avoid some file filtering programs. The author uses the iocreatefile function to open a file. When reading a file, the author does not use normal file-related API functions, but uses iofcalldriver. I am not familiar with the driver, nor do I know what iocalldriver is used for. I only know that the data is read after the iocalldriver function is called. This prevents regular file read/write Filtering programs. Analyze the PE file and find the export address of the function to be located. Then he will read the first dozens of bytes of the function. Of course, this involves the issue of code relocation. (People familiar with PE may understand the issue of relocation. I will not talk about it here. If you do not understand it, refer to the relevant documentation of PE file format .) The author redefines the read code snippets as themselves. In this way, the original code at the beginning of the function is obtained. Through this method, the author obtains the original validation data. This ensures that the function has not been patched before running the system function. Of course, if you are not afraid of trouble, you can put your patch on a deeper call path. In this way, even breakpoint debugging under the windbg, SoftICE, and syser debuggers cannot be broken. Of course, you cannot use the interrupt handler, because icesword.exe will repeatedly reset the interrupt handler for int 1 and INT 3 in a timer. Set it to the default handler in Windows ntoskrnl.exe. Even if you use the hardware breakpoint register, it does not work. Some people will say that since it is set to the default handler function in Windows ntoskrnl.exe, we can use windbg dual-host debugging. icesword also handles it. icesword will judge whether to allow kernel debugging through the kddebuggerenabled variable. If debugging is allowed,. icesword will call the kddisabledebugger function to disable kernel debugging. Here, by the way, two anti-debugging traps encountered in the analysis of icesword are listed here. I hope the author will forgive me. . Text: 000xxxf0 mov [EBP + iocontrolcode], eax . Text: 000xxxf3 mov eax, [esp + 5ch-6ch]; reverse debugging code . Text: 000xxxf7 push eax . Text: 000xxxf8 mov eax, [esp + 60h-6ch] . Text: 000 xxxfc pop EBX . Text: 000 xxxfd CMP eax, EBX . Text: 000 xxxff JZ short loc_1240b; jump if not debugged . Text: 000xxx01 mov eax, 200 edbh . Text: 000xxx06 not eax . Text: 000xxx08 push eax . Text: 000xxx09 pop EDI . Text: 000xxx0a stosd . Text: 000xxxf3 mov eax, [esp + 5ch + 6ch] When you execute this command in a single step or set a breakpoint on this command, because when the debugger pops up on this command, the stack of the program to be debugged is used to save eflags, Cs, EIP, (if int 1 or INT 3 is used to process the function, this problem can be solved .) For example, when the Code executes this command, esp = 805e4320h is the value of eax after executing this command: [esp + 5ch-6ch] = [ESP-10h] = [805e4320h-10h] = [805e4310h. When one step is executed. text: 000xxxf8 mov eax, when the [esp + 60h-6ch] command is run, esp = 805e432ch thinks that an eax is added to the stack, So ESP = 805e432ch. text: 000xxxf8 mov eax, [esp + 60h-6ch] eax = [esp + 60h-6ch] = [esp-CH] = [805e432ch-ch] = [805e4310h] read the same command without debugging the value of an address, therefore, the two values should be the same, that is. text: 000 xxxfd CMP eax, The comparison results of the EBX command should be the same. This command. Text: 000 xxxff JZ short loc_1240b is directly redirected. If it is debugged by the debugger,. Text: 000 xxxff JZ short loc_1240b will not jump. If the current code is not redirected, the current ETHREAD pointer of the system will be overwritten. Next, calling many system functions will cause the system to crash and crash into the system module. This will mislead you in locating errors. . Text: 000xxx68 Push 1; Alignment . Text: 000xxx6a push 40 h; Length . Text: 000xxx6c push currenteprocessobject; Address . Text: 000xxx72 call DS: probeforread Here, we intentionally make an exception to achieve the jump. If you execute a single step in the. Text: 000xxx72 call DS: probeforread command, the debugger will run, that is, exit from the debugger and keep tracing. Next, after we find the pspcidtable variable in our pspcidtable, The pspcidtable [handle table of this handle_table stores pointers of all processes and thread objects. PID (process ID) and threadid (thread ID) Are indexes in the handle table. This handle_table does not belong to any process, nor is it linked to the handle_table chain. The global variable pspcidtable is a pointer to this handle_table. This handle_table is also different from other handle_table, that is, the first 32bit in its handle_table_entry stores the Object Body pointer (of course the conversion is required) instead of object header pointer (Object Pointer is Object Body pointer).] (If [] is specified, it is not written on the Internet. Here we are particularly grateful to the author of the article "jiurl is playing with Win2k process thread handle_table": jiurl) we need to figure out a way to traverse the pspcidtable handle table to traverse all processes in the system. Icesword uses the export function exenumhandletable of the system's public ntoskrnl.exe to traverse this table. Icesword locates the exenumhandletable function exported by ntoskrnl.exe. This function is an undisclosed function. The original form of this function may be void stdcall exenumhandletable (Pulong handletable, pvoid callback, pvoid Param, phandle handle optional). The parameter Pulong handletable can be used as the parameter. the pvoid callback type is bool (* exenumhandletablecallback) (handle_talbe_entry *, dword pid, pvoid PARAM) function pointer. The pvoid Param parameter is the parameter sent to the callback function. The phandle handle optional parameter has not been fully understood yet. I can't use him, so I don't care about him. When the exenumhandletable function is called, the function calls a callback function every time it is enumerated to a handle in the table. When the returned value of the callback function is 0, continue to enumerate the handle table. If 1 is returned, stop enumeration.