Runtime Patching (The silent rootkit)

Gnosis

Level 5
Thread author
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
 

Gnosis

Level 5
Thread author
Apr 26, 2011
2,779
Trojans, Rootkits, and Injecting Executable Code Into the Kernel Via Buffer Overrun

False Program Logic

So a hacker plants a Trojan out in the wild and you click on it. At that point does the rootkit it might contain get installed? Is the next step for the hacker to begin a bug/exploit operation via buffer overrun to inject executable code (binary) into the Kernel, thus creating "false logic" induced stealth by means of "runtime patching"?

False logic = an ignorant OS, and (or) an OS that lies to signature based security software due to its ignorance. This is why I have a behavior blocker.

I assume that illegitimate hackers that create an atmosphere of false logic, via runtime patching, is our biggest threat. I would think that is how Iran landed that drone, and of course they had a key sniffer in their Rootkit.

"ROOTKITS, Subverting the Windows Kernel"

I hope this will help to start a very interesting and intriguing conversation.
 

Gnosis

Level 5
Thread author
Apr 26, 2011
2,779
Kernel Module and Driver

"A rootkit may use more than one kernel module or driver program. For instance, an attacker may use one driver to handle all file-hiding operations, and another driver to hide registry keys. Distributing the code across many driver packages is sometimes a Good Thing because it helps keep the code manageable---as long as each driver has a specific purpose. It would be hard for an attacker to manage a monolithic "kitchen-sink" driver that provides every feature known to man."

Detour Patching

In Chapter 4, we saw the power of using call hooks as a convenient way to modify program behavior. One downside of the call hook is that it modifies call tables, and this can be detected by anti-virus and anti-rootkit technology. A subtler approach to the problem is to patch the bytes within the function itself by inserting a jump into rootkit code. Additionally, modifying just a single function can affect multiple tables pointing to that function, without the need to keep track of all the tables that point to the function. This technique is called detour patching, and can be used to reroute the control flow around a function.

Generally speaking, the direct code-byte patch is one of the strongest methods for modifying program logic. Almost any program code or logic can be modified. Furthermore, the technique is somewhat difficult to detect—at least with current rootkit-detection technology.

Direct Code Byte Patch

Code-byte patches offer an alternative way to implement many of the hooking strategies described in this book. If combined with other powerful techniques, such as direct hardware access and virtual-memory obfuscations, the direct code-byte patch can be used to develop a very deadly and hard-to-detect rootkit.

As you’ve seen, the common place to insert code patches into a function is at the very beginning of the function. This is easy, because functions are easy to find in memory. Of course, we don’t need to stop there; we can also patch code bytes deep within the function itself. Deeper code patches provide better stealth and, therefore, aren’t as easy to detect. Some rootkit-detection software checks the integrity of only the first 20 bytes of a function. If you place your code modification past the initial 20-byte mark, you remain undetected by that software.

Searching for code bytes to patch can sometimes work well. If the series of code bytes you wish to patch are unique, you can simply search for them in memory and patch them. When the code can simply be searched for, there is no need to use function pointers to find it. If the patch itself is simple, you can sometimes search for unique code bytes that are near the intended patch location. The trick is to find some code bytes that are unique, so they can be searched for without generating false hits.

Layered Drivers

Developers engineer clever solutions to avoid work. In fact, this laziness drives many innovations in code. The ability to layer drivers is one such innovation. Using layers, a developer can chain multiple drivers together. In this way, a developer can modify the behavior of an existing driver without coding a whole new driver from scratch.

Layering is a reliable and robust way to intercept and modify data in the system. It can be used not only for stealth, but also for data collection and modification. Adventurous readers and would-be rootkit developers can expand on the examples in this chapter to intercept or modify network data, create covert channels, intercept or create video signals, and even create an audio bug.

That was another excerpt from: "ROOTKITS, Subverting the Windows Kernel".
 

Gnosis

Level 5
Thread author
Apr 26, 2011
2,779
Keep in mind that these posts are for a "reverse engineering" mindset. They are to help you understand what is going on when you are infected, not encourage you to engage in malicious and illegitimate activities. We are "getting into their heads", so to speak.
 

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top