Research on Software Protection Technology Based on Driver

Recent years, with the rapid development of the Internet, the technology of software and hardware changes with each passing day. In order to pursue the economic interest, many software systems which contains fatal flaws are always come into use untimely. Although many software developers have involved a tremendous lot of work to make the life cycle of their software systems long enough. However, the law is strong but the outlaws are ten times stronger. In order to be able to illegally use software related charging functions, hackers improve their illegal cracking techniques. in the process of confronting software protection technology As many software developers only focus on the implementation of software system functions, they overlooked the software encryption protection and reverse cracking. Therefore, in the preliminary stage of studying software protection, researchers developed some relatively useful professional software encryption protection program (Shell for short). However, with the development of cracking techniques, even the strong shell ASProtect which uses powerful encryption algorithms such as Twofish, TEA, Blowfish, and the combination of CRC (Cyclic Redundancy Check) and anti-debugging techniques can be removed by using the free OllyDbg dynamic tracking shell after the disassembly code. Using the stack balance principle to find the shell before the program execution entrance, then combining the powerful functions of LoadPE tool to import table, import address table and relocation table. Presently, VMProtect and driver protection technology are two most important ways to protect software. However, VMProtect will need large amount of code in order to build virtual machines which will act as decoders of bytecode code generated to protect software. For the same reason, efficiency of executing software protected by VMProtect is very low. This article will introduce current state of software protection and give suggestions to limitation found in current application.


Introduction
Before software protection technology, we can only protect software at level ring3 in the system by means of encrypting Import Tables, IATs and Relocatables. Or encrypt important DLL file so that hackers may have a hard time reverse engineer encryption [6]. However, protected data will be fully exposed to hackers as long as those hackers use dynamic debuggers like OllyDbg to keep track of encryption process that happened in the CPU. It is proven that good encryption program like themida is still vulnerable before adding in software protection [1]. Since drivers are running at ring 0 level, which is the same level as operating system. Thus, it is allowed to edit any data from 4GB virtual memories [13]. We can protect and hide important data of a software when we use driver program to encrypt it. In the meantime, we can use GDTHOOK, IDTKOOK, SSDTHOOK to increase clearance of software and relocate key codes (decryption code for example) to level ring0. As a result, debuggers that running at ring3 level like OllyDbg won't work, hackers could only use debuggers at ring0 level to do the hacking job [12]. However, debuggers at ring0 level like windbg are way inferior than that in ring3 level. Moreover ring0 level debuggers require more advanced skill level from hackers, which in turn, increased difficulty of decryption greatly [2].

Current State of Driver Protection
Current main stream driver protection technologies are SSDTHOOK, kernel reboot technology and APC protection. Abnormality disposal system use APC function or abnormality disposal function to protect important data [14]. World famous TP (TenProtect) uses SSDTHOOK to hide important kernel functions. It creates Deep Inline Hook from NtOpenProcess, NtOpenThread, NtReadVirtualMemory, NtWriteVirtualMemory, KiAttachProcess etc. it also generates special threads in order to test kernel functions for abnormalities and modifications constantly. However, kernel testing tools like XueTr, Kernel Detective, PCHunter could still identify hooked functions easily [5]. Then hackers can reverse engineer those functions and break TP's encryption. The difference between SSDTHOOK and kernel reboot is that making a new copy of the kernel to the memory then activate the HOOK process will bypass tools like XueTr [11]. For the same reason, kernel reboot technology is more effective in driver protection.

Cloning the Kernel
Code has to be stored in memories in order to be executed by the CPU [8]. The first step of kernel rebooting is to copy kernel files (if operating system uses 10-10-12, then page kernel file is ntoskrnl.exe; if uses 2-9-9-23, then page kernel file is ntkrnlpa.exe; if program uses window function, then reloading win32k.sys is needed) to a newly allocated memory, just like how operating system loads PE files [10]. Process above is demonstrated below (take ntoskrnl.exe for example).

Repair Relocation Table
There are many global variables in ntoskrnl.exe (like KeServiceDescriptorTable) and address of functions (like KiAttachProcess). They are all directly accessible. Those address in clones are the same as before, thus, system will crash if we forget to repair those addresses [9]. Sometimes, it will cause hardware failure.The whole process is shown below.

Repair KeService Descriptor Table Pointer Address of System Service Table Address of Kernel Functions Inside SSD
After repairing relocation table, when we use API(Application Programming Interface) from ring3 to enter ring0, KeServiceDescriptorTable pointer, address of system service table and address of kernel functions inside SSDT [15]. They all point to the original data as process chart shown below.

Hook KiFastCallEntry Kernel Function
Now our new kernel has new KeServiceDescriptorTable pointer (pNewSSDT). Data in new system service table are pointed to kernel functions in our new kernel. As we know, when using API from ring3 to enter ring0, KiFastCallEntry function is still calling for functions in the old system service table located in the old kernel [3]. So we need to Inline Hook KiFastCallEntry funtion. KiFastCallEntry will allocate pNewSSDT->ServiceTableBase new kernel functions from new system service table when we designated that process. In this way, kernel is reloaded as process chart shown below. We use method of stack backtrace in order to determine addresses that were hooked in KiFastCallEntry [4]. Fist we use SSDTHOOK to hook a kernel function randomly. Take NtOpenProcess function for example. After hookin g NtOpenProcess, we will be entering function MyNtOpenProcess (defined by ourselves) when using OpenProcess at level ring3 to enter ring0. Functions mentioned above is shown below (Key code shown below After hooking KiFastCallEntry, we can find and use functions located in new system service table based on pNewSSDT, Ebx, Eax and Edi.

Limitations of Kernel Rebooting Protection
After rebooting the kernel, when we are SSDT HOOKING kernel functions from new system service table, hackers won't detect our hooking process using tools like XueTr, Kernel Detective, PCHunter etc. In this way, SSDT HOOK is still effective in protecting software and drivers. Although kernel rebooting could save us from kernel detecting tools, it is still vulnerable against pattern matching. Because files in new kernel contain patterns that could reveal identities, we will be calling such patterns as "kernel fingerprints" in the rest. Patterns like PE symbol, kernel functions will allow hackers to use byte-search to search memories. If PE fingerprints are found in a memory (0X4D 5A), other kernel fingerprints like NTOpenProcess are found or extra processes done by kernel function were found, hackers would acquire strong evidence that the kernel was rebooted. Apparently, hackers can reverse engineer KiFastCallEntry function and figure out the differences after software protection program was executed. Then they could find out where KiFastCallEntry was hooked, all they have to do is to unhook KiFastCallEntry and all protections are decrypted. There are way too many fingerprints in new kernel files; in that case, we need to find a way to hide those fingerprints as much as possible to prevent hackers from finding real identities of those files. Hackers can't break the encryption when they failed to find fingerprints using pattern matching technique. So we need to encrypt kernel fingerprints before kernel rebooting (for example, xor fingerprints). Using this method, when new kernel is expanded to the memory, files inside the kernel won't show fingerprints. Rather, they look like ordinary data blocks that have been encrypted. When we need to execute functions from new kernel, we can then simply decrypt the new kernel and run software encrypting program then to protect the code.

Limitations of Kernel Rebooting Protection
Although the drive protection scheme mentioned in the essay can provide an effective protection for the software system, yet the skills require to accomplish by the software developers, and the programming techniques have a relative barriers to entry. So, if the developers want to use the system mentioned by the author to pretect the software, it requires to understand the working principles and processes of windows kernel code, which makes the software developement harder and extending the period of developing.

Limitations of Kernel Rebooting Protection
Due to the limitation of the energy and ability, the author hasn't done the experimental demonstration of the software-driven protection scheme. so the author expect to accomplish it as soon as possible, by the way those who interested in the demonstration are welcomed.

Limitations of Kernel Rebooting Protection
The intellectual property of the software has been severely infringed for a long time. Reverse software crack has damaged the profit of developers seriously. It is hoped that crackers will reduce the persecution on the intellectual property through the research of this paper and this research can inspire those who are interested in the skills of software driver.