In the world of security, there are typically two kinds of arms races – symmetric and asymmetric. Asymmetric warfare is where it is orders of magnitude easier to defend than it is to attack (or vice-versa). In other words, given a conscious decision to be secure, it is inherently a lot easier to carefully engineer a fail-safe system, than it is for a malicious attacker to figure out a way to break it. Good examples of asymmetric warfare are cryptography (most modern cryptographic algorithms are practically impossible to break), memory-corruption based exploitation (stack canaries, address-space layout randomization, non-executable memory pages / “PaX”, “no-execute” hardware support etc are all relatively easy to implement and use), deception & uncertainty (e.g. ICMP traceback, honeynets), etc. On the other hand, symmetric warfare is where the attackers and defenders are on a level playing ground in terms of available technologies. The best examples of this have been DRM (Digital Rights Management) and virus technologies (detection and evasion).

Every now and then, good defensive technologies from asymmetric warfare in one security domain are applied for offensive purposes in another security domain (or vice-versa depending upon which came first). The following are two recent examples.

Firstly, in the world of online form submission, “captchas” have become a de-facto standard to check whether an actual human is involved in the process. A captcha is essentially a visual challenge-response test. Typically, a distorted image is generated randomly for each form, and the user is supposed to visually recognize the content displayed and type it in. The assumption is that automated bots can’t identify the content quickly enough, only humans can. A pretty fail-safe technique actually, and it works to this day for most purposes. However, the same concept is now being used by spammers:

The entire unsolicited message is one captcha image. For traditional anti-spam agents that have to quickly scan through emails, this is indistinguishable from legitimate-looking emails from unknown senders and with image-attachments.

So the asymmetric defense from the world on online-form submissions has now introduced an asymmetry in the world of anti-spam. The day wire-speed OCR (optical character recognition) becomes available, possibly invented for spam defense, the asymmetry in online-form submissions will also be lost.

Second, let’s look at TLB (Translation Look-aside Buffer) desynchronization. The PaX technology from Grsecurity introduced the idea of non-executable memory pages via split TLB. A brilliant defensive technology that games the paging-logic of IA32 based CPUs using desynchronization of the TLB to allow a kernel mode driver to know whether a memory access is a data-access or an execute access. So it became possible to detect exploits that tried to execute code copied into pages marked non-executable.

Following this, the split-TLB defense was applied for offensive purposes in Shadow Walker (hiding rootkits from AV/AS scanners) and defensive purposes in Ollybone (reversing packed/encrypted malware). Packed malware typically start off by unpacking the original code into a separate section (marked non-executable by the malware analyst). Then, when the malware attempts to execute the OEP (Original Entry Point) instruction, the Ollybone driver can intercept it and present an “unpacked” memory layout to the reverse engineer. Shadow Walker uses an “inverse-PaX” technique. When a scanner attempts to read from a Rootkit occupied page, a cloaking driver detects it as a non-execute access, and presents a cloaked clean version of the page instead. The driver allows execution of the Rootkit pages as usual. This makes traditional user-space scanning for kernel-mode rootkits completely ineffective.

The following is the latest addition to the utility of this split-TLB trick.

View Demo Here

Unlike Shadow Walker which is designed to hide Rootkit’s kernel-space modifications, we apply the split-TLB trick to hide user-space code (or data) patches instead. This has a tremendous impact in the world of malware analysis and DRM.The proof of concept demo here shows a user-space executable that is designed to be tamper-resistant. It does this using a “checksum” thread that periodically monitors and posts the checksum of certain memory pages used by a critical “worker” thread. The worker thread periodically prints a status message. Once the anti-checksum driver is loaded, it first setups a cloaked clean version of the worker-thread page. Using split-TLB, the checksum thread is shown the clean version only. Then the driver patches the worker-thread code and completely disables its status messages. As seen in the demo, the checksum thread generates checksum-match messages even as the worker-thread has been visibly tampered with. Once the driver is unloaded, the cloaking is removed, and only then the checksum thread detects the process has been tampered with. This illustrates that user-space tamper resistance via self-checksums can not be relied upon anymore for any platform that supports split “TLB” or any style of memory cloaking that distinguishes executes from reads.

So the originally defensive PaX technology turned offensive in Shadow Walker, then defensive in Ollybone, and again either defensive/offensive depending upon whether it’s used for hiding code-patches in malware during analysis or in DRM-enabled products to break their tamper resistance.