Communicating via the Custom Driver

Can God create such a stone that he would be unable to lift, it is a question that can t be answered by science. Programmers, however, can easily find such a thing that they can t debug.

Programmers folklore

Overview

Protection requiring low-level access to the CD will inevitably give itself away by the presence of functions such as DeviceIoControl and/or SendASPI32Command in the import table. If protection mechanism loads these functions dynamically, this can be revealed by setting breakpoints to the LoadLibrary/GetProcAddress functions (however, experienced programmers can search for the required functions in the memory, ”this task is not as complicated as it seems).

Furthermore, the program body might contain strings such as: \\.\ , SCSI , CdRom , wnaspi32.dll , etc. By setting a breakpoint on the first byte of the string, we will be able immediately to locate the protection code as soon as it is called for the first time. To avoid this, developers often encrypt all text strings. However, most of them usually limit themselves to primitive static encryption (which usually is carried out by ASPack or other similar programs). Therefore, if we wait until decryption is completed and call the debugger after starting the program, instead of doing so before it, all text strings will be displayed in plain text! Dynamic encryption is much more reliable. In this case, text strings are decrypted directly before passing them to the appropriate API function, after which they are encrypted again. However, if desired, it is also possible to overcome dynamic encryption! To achieve this, it is enough to set a conditional breakpoint on the CreateFile function to which these text strings are passed, popping up only in the event that the first four bytes of the filename are equal to \\. \ . An example of such a call would look as follows :

 bpx CreateFileA if (*esp   >4=='\\.\') 

after which it remains only to enjoy the results.

Naturally, the results as we understand them include, first, the name of the file to be opened, or, to be more precise, the driver name (this is a result in itself), and, second, the descriptor returned by the CreateFile function. To proceed further, it is possible to choose one of the following two approaches: Either set the breakpoint at the memory cell , in which this descriptor is saved, or set a conditional breakpoint to the DeviceIoControl , catching only those calls to it that are necessary for us. An example of a debugger session is provided in Listing 5.1.

Listing 5.1: An example illustrating the determination of the protection mechanism using Soft-Ice

 :bpx CreateFileA if (*esp->4=='\\.\')  (setting a breakpoint)  :x  (exiting the debugger)     (Debugger pauses for a moment, and then pops up at the moment of call to CreateFileA.)  :P RET  (exit CreateFileA)  :? eax  (get the descriptor value)  00000030 0000000048 "0"  (response from debugger)  :DeviceIoControlA if (*esp->4==0x30)  (setting the breakpoint to DeviceIoCntrol)   (after a pause, the debugger pops up at the moment of call to DeviceIoControl)  :P RET  (exit DeviceIoControl)  : U  (Thats all. The protection is detected!)  001B:00401112     lea     ecx, [ebp-38]  001B:00401115     push    ecx  ;  001B:00401116     push    0004D004  ; Here it is, IOCTL_SCSI_PASS_THROUGH_DIRECT!  001B:0040111B     mov     edx, [ebp-0C]  001B:0040111E     push    edx  001B:0040111F     call    [KERNEL32!DeviceIoControl] 

 

As can be seen, the search for DeviceIoControl didn t take long. It only remains now to analyze the IOCTL code passed to it (in our example, this is IOCTL_SCSI_PASS_ THROUGHT_DIRECT ) and its parameters passed via the stack one double word higher.

Some developers place the critical part of the protection code in the driver, hoping that hackers won t find it there. Vain and naive hope! Drivers are very easy to analyze because of their small size . Consequently, there is no place in a driver to hide the protection code. However, if you dissipate the protection code by several megabytes of the application code, the analysis will take a horribly long time. Thus, if hackers have no special interest in cracking that protection, they are better off purchasing a legal copy rather than spending several weeks jumping from disassembler to debugger and vice versa.

What tricks are used by developers to complicate driver analysis? One method is to encrypt the text string with the symbolic name of the device created by the driver at the time of loading. As a result, the hacker knows for sure that the protection code opens the device "\\. \MyGoodDriver" , but can t determine quickly to which driver this name corresponds. In the case that there is no encryption, the problem is solved easily by a trivial context search. For example, let s assume that we need to know which driver creates the device with the name MbMmDp32 . Open the WINNT\System32\Drivers folder with Far Manager, press <ALT-F7>, and enter the name of the string to be searched for: MbMmDp32 . Do not forget to select the Use all installed character tables checkbox ( otherwise , nothing will be found, since the string must be specified in Unicode). After some disk activity, Far Manager will produce the only correct answer: ASPI32.SYS . This is the driver that we need! Now imaging that string containing the name is encrypted If the driver is loaded dynamically, the situation is not too bad. Simply set the breakpoint to the IoCreateDevice and wait until the debugger pops up. Then, issue the P RET command and search the map of loaded modules (displayed by the mod command) to find what can be discovered in this memory region. Drivers that load during the OS boot are significantly more difficult to overcome. Quite often, you will have to search for the required driver by means of trial and error. The date of file creation can often help in this search ”the driver installed by the protected application must bear the same data of creation as all of its other files. However, the protection mechanism can freely manipulate the creation data at its discretion, so this technique is not reliable. A positive result can be produced by comparing the contents of the WINNT\System32\Drivers directory before and after installation of the protected application. Clearly, the protection can only be hidden among one of the newly installed drivers.