Mesh design pattern: hash-and-decrypt

Post Reply
User avatar
Pigeon
Posts: 18055
Joined: Thu Mar 31, 2011 3:00 pm

Mesh design pattern: hash-and-decrypt

Post by Pigeon » Thu Apr 04, 2013 10:33 pm

Gauss cyber weapon makes use of this type of process.

Mesh design pattern: hash-and-decrypt

Filed under: Crypto,Hardware,Security,Software protection — Nate Lawson @ 2:00 pm

Hash functions are an excellent way to tie together various parts of a protection mechanism. Our first mesh design pattern, hash-and-decrypt, uses a hash function to derive a key that is then used to decrypt the next stage. Since a cryptographic hash (e.g., SHA-1) is sensitive to a change of even a single bit of input, this pattern provides a strong way to insure the next stage (code, data, more checks) is not accessible unless all the input bits are correct.

Image

For example, consider a game with different levels, each encrypted with a different AES key. The key to decrypt level N+1 can be derived by hashing together data which only is present in RAM after the player has beat level N with an unmodified game (e.g., correct items in inventory, state of treasure chests, map of locations visited, etc.) If an attacker tries to cheat on level N by modifying the game state, they won’t know what items they need to have, may load up their character with items that are impossible to have at that point in the game, or one or more map positions won’t have been marked as visited. In this case, the hash and thus the next level key will be incorrect. Any difference in the hashed data produces an incorrect key and the level cannot be decrypted without the exact key.

In software protection, the focus is on verifying that security checks are intact and running properly. Hash-and-decrypt would cover code and data locations that might be modified by an attacker who is debugging or patching the application in order to reverse engineer it. This includes locations that might be changed by setting breakpoints (i.e., int 3 or Detours-style function hooking, debug registers DR0-3, IDTR a la Red Pill) or self-check functions that may be disabled or paused while analyzing the executable. The encrypted stage N+1 can be parts of the application as well as other self-check functions.

Link


User avatar
Royal
Posts: 10562
Joined: Mon Apr 11, 2011 5:55 pm

Re: Mesh design pattern: hash-and-decrypt

Post by Royal » Fri Apr 05, 2013 7:02 am

changed by setting breakpoints (i.e., int 3 or Detours-style function hooking, debug registers DR0-3, IDTR a la Red Pill)

It's interesting, because I was thinking about breakpoints, specifically the int 3 or Detours-style function hooking, debug registers DR0-3, IDTR a la Red Pills all week.

User avatar
Pigeon
Posts: 18055
Joined: Thu Mar 31, 2011 3:00 pm

Re: Mesh design pattern: hash-and-decrypt

Post by Pigeon » Fri Apr 05, 2013 12:01 pm

Always Spit-out if the Trap Flag is set ... take no chances, well, only some ...

A Reverse Engineer's Blog

When the Red Pill is Hard to Swallow

I was looking at a malware sample last week that used a variation of Joanna Rutkowska's infamous Red Pill (http://invisiblethings.org/papers/redpill.html) to determine whether or not the malware was being run from inside a Virtual Machine. Based on the Red Pill concept, the guest OS's IDTR should be different from the host OS's IDTR.

I was using Virtual PC to step through the malware sample in OllyDbg, with the goal of skipping the conditional-jump after SIDT led to the detection of my VM (see http://download.intel.com/design/Pentiu ... f#page=275 for details on the SIDT instruction). You can imagine my surprise when SIDT returned 0x8003F400 as the base address of the IDT, which is the same base address of the IDT for my host Windows XP system!

My first thought was that maybe the Virtual PC team figured out some ingenious way to make this happen via the Virtual Machine Additions add-on (see http://www.microsoft.com/technet/prodte ... ue&#41). So I uninstalled Virtual Machine Additions, rebooted, and tried again. To my continued surprise, OllyDbg was still showing the host OS's IDTR when stepping through the SIDT instruction on my guest OS.

After some more thinking, I thought, "maybe it has something to do with the fact that I'm single-stepping through SIDT in OllyDbg." To test this hypothesis, I set a breakpoint after the SIDT instruction, and ran the program from the start. Sure enough, SIDT returned 0xF9CB6440 as the base address of the IDT that time.

The whole trick behind the Red Pill is that VMs don't typically have the opportunity to intercept SIDT since it's not a privileged instruction. However, when the Trap Flag is set (due to single-stepping), Virtual PC intercepts the int 1 interrupt and can execute the current instruction however it pleases; when it has the opportunity, it will use the host's IDTR for the SIDT instruction.

Hopefully this knowledge will make the Red Pill a little easier for you to swallow (or spit-out if the Trap Flag is set).

Link


User avatar
Pigeon
Posts: 18055
Joined: Thu Mar 31, 2011 3:00 pm

Re: Mesh design pattern: hash-and-decrypt

Post by Pigeon » Fri Apr 05, 2013 12:07 pm

The Interrupt Descriptor Table (IDT) is a data structure used by the x86 architecture to implement an interrupt vector table. The IDT is used by the processor to determine the correct response to interrupts and exceptions.

The details in the description below apply specifically to the x86 architecture and the AMD64 architecture. Other architectures have similar data structures, but may behave differently.

Use of the IDT is triggered by three types of events: hardware interrupts, software interrupts, and processor exceptions, which together are referred to as "interrupts". The IDT consists of 256 interrupt vectors–the first 32 (0-31 or 00-1F) of which are reserved for processor exceptions.


User avatar
Royal
Posts: 10562
Joined: Mon Apr 11, 2011 5:55 pm

Re: Mesh design pattern: hash-and-decrypt

Post by Royal » Fri Apr 05, 2013 7:46 pm

Interesting stuff. I have trouble visualizing it. How do professors model this in their head? IS there an analogy to use.

User avatar
Pigeon
Posts: 18055
Joined: Thu Mar 31, 2011 3:00 pm

Re: Mesh design pattern: hash-and-decrypt

Post by Pigeon » Fri Apr 05, 2013 8:10 pm

Not sure if I can give an analogy for a visualization. I suppose an interrupt could be seem as someone stopping what they are doing, and then handing a pressing situation. After that, possibly returning to the previous task.

User avatar
Pigeon
Posts: 18055
Joined: Thu Mar 31, 2011 3:00 pm

Re: Mesh design pattern: hash-and-decrypt

Post by Pigeon » Fri Apr 05, 2013 8:25 pm

In protected mode, the IDT is an array of 8-byte descriptors stored consecutively in memory and indexed by an interrupt vector. These descriptors may be either interrupt gates, trap gates or task gates. Interrupt and trap gates point to a memory location containing code to execute by specifying both a segment (present in either the GDT or LDT) and an offset within that segment.

The only difference between these two is that an interrupt gate will disable further processor handling of hardware interrupts, making it especially suitable to service hardware interrupts, while a trap gate will leave hardware interrupts enabled and is thus mainly used for handling software interrupts and exceptions.

Finally, a task gate will cause the currently active task-state segment to be switched, using the hardware task switch mechanism to effectively hand over use of the processor to another program, thread or process.

The protected mode IDT may reside anywhere in physical memory. The processor has a special register (IDTR) to store both the physical base address and the length in bytes of the IDT. When an interrupt occurs, the processor multiplies the interrupt vector by 8 and adds the result to the IDT base address. With help of the IDT length, the resulting memory address is then verified to be within the table; if it is too large, an exception is generated. If everything is okay, the 8-byte descriptor stored at the calculated memory location is loaded and actions are taken according to the descriptor's type and contents.


User avatar
Pigeon
Posts: 18055
Joined: Thu Mar 31, 2011 3:00 pm

Re: Mesh design pattern: hash-and-decrypt

Post by Pigeon » Fri Apr 05, 2013 9:01 pm

Interrupt descriptor table

INT_NUM Short Description PM
0x00 Division by zero
0x01 Debugger
0x02 NMI
0x03 Breakpoint <------- interrupt 3
0x04 Overflow

---

A non-maskable interrupt (NMI) is a computer processor interrupt that cannot be ignored by standard interrupt masking techniques in the system. It is typically used to signal attention for non-recoverable hardware errors. (Some NMIs may be masked, but only by using proprietary methods specific to the particular NMI.)

Overview

An NMI is often used when response time is critical or when an interrupt should never be disabled during normal system operation. Such uses include reporting non-recoverable hardware errors, system debugging and profiling, and handling of special cases like system resets.

In modern architectures, NMIs are typically used to handle non-recoverable errors which need immediate attention. Therefore, such interrupts should not be masked in the normal operation of the system. These errors include non-recoverable internal system chipset errors, corruption in system memory such as parity and ECC errors, and data corruption detected on system and peripheral busses.

On some systems, an NMI can be triggered by the computer's user through hardware and software debugging interfaces and system reset buttons.

Debugging NMIs are typically used to diagnose and fix faulty code. In such cases an NMI is used to execute an interrupt handler that transfers control to a special monitor program. From this program a developer can inspect the machine's memory, and examine the internal state of the program at the instant of its interruption. This also allows computers which appear to be hung to be debugged or diagnosed.


User avatar
Pigeon
Posts: 18055
Joined: Thu Mar 31, 2011 3:00 pm

Re: Mesh design pattern: hash-and-decrypt

Post by Pigeon » Fri Apr 05, 2013 9:21 pm

Back to red pill

The reference to the pills is also implemented in a special type of malware that utilizes the virtualization techniques of modern CPUs to execute as a hypervisor; as a virtual platform on which the entire operating system runs, it is capable of examining the entire state of the machine and to cause any behavior with full privilege, while the operating system "believes" itself to be running directly on physical hardware, creating a parallel to the illusory Matrix.

Blue Pill describes the concept of infecting a machine while red pill techniques help the operating system to detect the presence of such a hypervisor.

In computing, a hypervisor or virtual machine monitor (VMM) is a piece of computer software, firmware or hardware that creates and runs virtual machines.

A computer on which a hypervisor is running one or more virtual machines is defined as a host machine. Each virtual machine is called a guest machine. The hypervisor presents the guest operating systems with a virtual operating platform and manages the execution of the guest operating systems. Multiple instances of a variety of operating systems may share the virtualized hardware resources.

Classification

Type 1 (or native, bare metal) hypervisors run directly on the host's hardware to control the hardware and to manage guest operating systems. A guest operating system thus runs on another level above the hypervisor.

This model represents the classic implementation of virtual machine architectures; the original hypervisors were the test tool, SIMMON, and CP/CMS, both developed at IBM in the 1960s. CP/CMS was the ancestor of IBM's z/VM. Modern equivalents of this are Oracle VM Server for SPARC, Oracle VM Server for x86, the Citrix XenServer, VMware ESX/ESXi, KVM, and Microsoft Hyper-V hypervisor.

Type 2 (or hosted) hypervisors run within a conventional operating system environment. With the hypervisor layer as a distinct second software level, guest operating systems run at the third level above the hardware. BHyVe, VMware Workstation and VirtualBox are examples of Type 2 hypervisors.

In other words, Type 1 hypervisor runs directly on the hardware; a Type 2 hypervisor runs on another operating system, such as FreeBSD, Linux, or Windows.


Post Reply