- Apr 26, 2011
- 2,779
Modified Program Logic and Runtime Patching
A few paragraphs from the book entitled, "ROOTKITS, Subverting the Windows Kernel", pages 116 and 117, released in 2006:
Most material relating to code patches goes back to the days of software cracking and piracy. But applied in rootkits, runtime patching is one of the most advanced techniques possible. Armed with this technique you should be able to build undetectable rootkits, even against modern intrusion-prevention systems. If you combine runtime patching with low-level hardware manipulation (such as page-table management) you will be operating on the bleeding edge of rootkits.
The logic of software can be modified in several ways. The most obvious way is to modify the source code and then recompile the software. This is the practice of developers. The second way is to directly modify the bits and bytes that result from compilation---the binary software. This is what software crackers do, and is the basic approach to removing copy protection on software. The third way is to modify the data that is stored in memory when the software executes. In-memory data structures control how a program behaves; thus, changing this data changes the program logic. Good examples of this are "game trainers" that alter games to, for example, give the player 10 million gold pieces.
Modifying code logic is simple in comparison to rewriting or replacing files on the system with Trojan devices. By flipping a few bytes here and there, you can turn off most security functions. Of course, you have to be able to read and write the memory where these security functions reside. Since our rootkits operate from the kernel, we have full access to the memory space of the computer, so this typically is not a problem.
Introducing Code into the Kernel
The straightforward way to introduce code into the kernel is by using a loadable module (sometimes called a device driver or kernel driver). Most modern operating systems allow kernel extensions to be loaded so that manufacturers of third-party hardware, such as storage systems, video cards, motherboards, and network hardware, can add support for their products. Each operating system usually supplies documentation and support to introduce these drivers into the kernel. This is the easy route, and is the road we will take to introduce code into the kernel.
As its name suggests, a device driver is typically for devices. However, any code can be introduced via a driver. Once you have code running in the kernel, you have full access to all of the privileged memory of the kernel and system processes. With kernel level access you can modify the code and data structures of any software on the computer.
A typical module would include an entry point and perhaps a cleanup routine.
A cleanup routine is not always needed, which is why Windows device drivers make this optional. The cleanup routine would be required only if you plan on unloading the driver. In many cases, a rootkit can be placed into a system and left there, without any need to unload it. However, it is helpful during development to have an unload routine because you may want to load newer versions of the rootkit as it evolves. Most example rootkits provided by rootkit.com include unload routines.
This is why Iran's nuclear program and our drone controller software could use a behavior blocker and HIPS.
"ROOTKITS", Subverting the Windows Kernel
A few paragraphs from the book entitled, "ROOTKITS, Subverting the Windows Kernel", pages 116 and 117, released in 2006:
Most material relating to code patches goes back to the days of software cracking and piracy. But applied in rootkits, runtime patching is one of the most advanced techniques possible. Armed with this technique you should be able to build undetectable rootkits, even against modern intrusion-prevention systems. If you combine runtime patching with low-level hardware manipulation (such as page-table management) you will be operating on the bleeding edge of rootkits.
The logic of software can be modified in several ways. The most obvious way is to modify the source code and then recompile the software. This is the practice of developers. The second way is to directly modify the bits and bytes that result from compilation---the binary software. This is what software crackers do, and is the basic approach to removing copy protection on software. The third way is to modify the data that is stored in memory when the software executes. In-memory data structures control how a program behaves; thus, changing this data changes the program logic. Good examples of this are "game trainers" that alter games to, for example, give the player 10 million gold pieces.
Modifying code logic is simple in comparison to rewriting or replacing files on the system with Trojan devices. By flipping a few bytes here and there, you can turn off most security functions. Of course, you have to be able to read and write the memory where these security functions reside. Since our rootkits operate from the kernel, we have full access to the memory space of the computer, so this typically is not a problem.
Introducing Code into the Kernel
The straightforward way to introduce code into the kernel is by using a loadable module (sometimes called a device driver or kernel driver). Most modern operating systems allow kernel extensions to be loaded so that manufacturers of third-party hardware, such as storage systems, video cards, motherboards, and network hardware, can add support for their products. Each operating system usually supplies documentation and support to introduce these drivers into the kernel. This is the easy route, and is the road we will take to introduce code into the kernel.
As its name suggests, a device driver is typically for devices. However, any code can be introduced via a driver. Once you have code running in the kernel, you have full access to all of the privileged memory of the kernel and system processes. With kernel level access you can modify the code and data structures of any software on the computer.
A typical module would include an entry point and perhaps a cleanup routine.
A cleanup routine is not always needed, which is why Windows device drivers make this optional. The cleanup routine would be required only if you plan on unloading the driver. In many cases, a rootkit can be placed into a system and left there, without any need to unload it. However, it is helpful during development to have an unload routine because you may want to load newer versions of the rootkit as it evolves. Most example rootkits provided by rootkit.com include unload routines.
This is why Iran's nuclear program and our drone controller software could use a behavior blocker and HIPS.
"ROOTKITS", Subverting the Windows Kernel