tmd.rar_Themida 1.2.0.1_Themida/Winlicense_WinLicense_themida_tm

The Oreans (Themida/Winlicense) VM antidumps.

quosego

October 6, 2009

Intro;

The virtual machine of any Oreans protected application usually tries to prevent itself from running

in any dumped application. It does so with the use of antidumps, these antidumps are small parts of

code that try to detect if you’re running a protected application or an unprotected application.

This code always resided in the VM making it very hard to analyze. However usually the code checks

for values somewhere in memory which get wiped when you dump an application, these checks

them. That is something you can now do yourself. Please consider the antidumps were first defeated

without knowing the actual ASM code, doing it with the info in this tutorial should be easy.

General idea of antidumps;

Antidumps attempt to detect whether a program dumped or it is run on a different computer.

Many things are different between a dumped application and a protected application. The stack is no

longer the same, the heap has been wiped and perhaps you’ve changed your PE header. Each of

these variables is semi-randomly checked by the Themida VM if they are still the same as defined by

the protection. You will notice these antidumps immediately after you dump an application.

However some do not show and are only revealed when your dump runs on a different OS, this is

due to the checking of API’s. API locations can differ between operating systems and the VM checks

stack will have changed. However the Setevent antidump is more devious and won’t show until you

run your dump on a different OS or service pack.

As you can see in the following antidump block they are used together to prevent dumping. And both

when failing end in the “add dword ptr ss:[esp],4” and “add esp,8” instructions which greatly disrupts

the flow of a program. Everything is checked against stored values which can be manipulated.

Figure 1: Stackantidump/SetEvent antidump in ASM. As you can see SetEvent and the stack are checked for

correctness. Program flow is always destroyed using two instructions.

Please note that the location of the SetEvent antidump is not always the SetEvent API in kernel32.dll.

It can also be the custom loaded SetEvent in the Oreans kernel32.dll. (Just search for the same bytes

as the kernel SetEvent and you’ll end up in the Oreans kernel32. ) As noted in previous tutorials the

This usage of HLT will make Oreans products incompatible with protecting ring0 products that use

the x86 version of HLT.

These values will have been put there by the packer, and updated when the protection is intact. If

the heap is not equal this will fail and the program flow destroyed, if the heap is located in a different

memory section it will give an access violation. The effects of this antidump are immediate, after

dumping the heap is already different and this antidump will be triggered.

The values to be checked by the antidump will be written to the heap as followed.

Figure 2: Heap antidump writing in ASM. As you can see the heap is filled with two dwords and the locations

are stored to be later checked by the VM.

Every time the packer is executed it will write to the heap using ntdll.ReAllocateHeap and these