Reversing Armadillo 4.20

From UIC

Armadillo 4.20

Infos
Author:	AndreaGeddon
Email:	andreageddon@gmail.com
Website:	http://quequero.org
Date:	??/??/2006 (dd/mm/yyyy)
Level:
Language:	English
Comments:	Shut up your face

Introduction

Armadillo is a nice animal, and a nice protection system! It is divided into two parts, the parent (Debugger) and the child (Debuggee). The code section is protected by a Copymem system and some code is emulated using nanomitesA nanomite is a 0xCC byte that cause a breakpoint managed from the parent process. Also API emulationIs a technique in which the behaviour of a real API is emulated without running the API itself and redirection is used, a lot of nice features! The target I am using is Armadillo itself version 4.20. Let’s start reversing.

Files

OllyDbg
IDA
Lord PE
Armadillo Nanomulator
Armadillo Importalizer

Essay

Step One: The ASM loader – Loading the loader

I start by having a general look at the PE, we can see that the import table seems to be correct (lots of API imports from kernel32, user32 and gdi32) but I don’t think it will be easy, so probably the real IT is loaded at runtime and is present elsewhere. Also, the section table is interesting

It seems that there are two executables joined in a unique PE. The entry point is located in the .adata section. This is the data section of the second executable. So we can assume that the initial code will be a pre loader that prepares the execution of the second executable, which resides in the .text1 section. Also this could mean that this second executable is the code of the protection core, and the first executable (.text) is the real application. Now that we have a general idea of the structure of the crypter, we can start tracing. The beginning is as usual:

The address of the start of the loader is stored into ebp, so the loader can access static data in the loader referring to the displacement from ebp. This is done because a loader has no fixed addresses, its location is known only at runtime. We soon find some polymorphic code:

This is usually the common form of the garbage code used by armadillo, there are some variants but the general structure is always similiar to this, so don’t waste time tracing these pieces of code, just skip them and focus on the real instructions. After this, we get to the first decryption routines

This simply decrypts some of the following code (starting at 004c917f). We will encounter a lot of decryption routines. Now we see some anti-debug code:

This code sets an exception handler (located at 004c9185) and at the line 004c91b3 it accesses a zero address to trigger the seh. In the seh we can see that the code zeroes registers (in the context provided by exception handler parameter) dr0, dr1, dr2, dr3, dr6 and sets in dr7 the bits corresponding to L0 – L3 and LE. In practice this interfers with the debugger, avoiding hardware memory breakpoints which rely on dr0-dr3. After this the exception handler quits returning the exception continuable value (0), so the execution is restored to the line 004c91b5 and the program continues running. Note that in the line 004c91b5 the unlinking of the exception record made with opcode 64:67:8F06 0000 sometimes causes troubles to ollydebug, in other packers I got troubles due to a massive use of these superfluous opcodes. We continue on and we find some other junk code:

This code dispatches the execution using a “call table” located at ebp+09CBA. EDI is the counter, we execute four functions. All this code is just used to decrypt the code that follows. At 004C91E8 in ebx is stored the pointer to the function taken from the function array, pointer which is relative to the loader starting offset, so ebp must be added to obtain the real address of the function. The if we trace the call to 004C9235 we find just a “JMP EBX” there, so the code jumps to the function. The various functions are quite easy:

This is the code without all the garbage polymorphic stuff. Basically it gets the relative pointer of the encrypted block in eax, relocates it by adding the loader base address, gets the size of the encrypted data in ecx, and then goes to the decrypt cycle, which performs a inc-add-ror-xor loop on each byte. The code being decrypted is located at 004C9238 and its length is 98AF bytes. You will find a lot of these loops, all with this similar structure (there are some variants), so just avoid tracing them and go directly to the following code that will be decrypted (usually you just need to go beyond the cmp edi, xx). After another call table of eight functions, we arrive to:

EBX is the address of a function that returns the base address of kernel32, its parameter is passed in esi and is the return address of the code that called the entry point of the exe from kernel32. This return address was incremented by 0x13800, I don’t know why, probably for some win9x compatibility problem. Of course the kernel32 base address is calculated by the code and not using GetModuleHandle or LoadLibrary. As we expect, after this the code:

finds the address of GetProcAddress,

finds the address of LoadLibraryA

makes a call to LoadLibraryA to have user32 handle

get the address of FindWindowA. Now

this code decrypts a pseudo import table:

Now every API address is stored in the import array, which starts at [EBP + 15B4]. I am talking of import array because this is not a real import table. It’s just a list of functions that will be used by the loader. Note that in every API about first five bytes are checked

0x660 shr 3 = 0xCC, so if you want to set a breakpoint on these api’s you will need to put it a few lines after the API entry point, otherwise armadillo will set an internal error status value

6675636B = ascii for “fuck”, so the execution will terminate. Whenever you see the code keeping that error value, it means that you are in the wrong place! After the import addresses are built, the import names are re-crypted. Here we come:

an interesting call to CreateFileA to open the file \\.\BCMDMCCP. This should be the driver of SpywareBlaster, so maybe armadillo has tampering problems with it. Now there is a really annoying part!

There are about ONE HUNDRED decryption layers; all are made with the call method we have seen above. Also seh are used among decryption routines. Note that the first of these layers will trigger a seh that will be resumed at line 004d25c5; where there is an invalid op code. Ollydbg will panice with this. You will need to trace it with shift-f9 to go on without problems. If you want you can trace all the hundred layers, but if you want to save your precious time then after all these layers there is a call to GetVersion, so just break on it and it’s done. Get out from GetVersion and we come to:

The important thing is RDTSC. Soon after this we have a SEH trigger. Inside we find:

another RDTSC. This instruction reads the timestamp counter of the CPU (that is, the number of cycles). So, in the seh it reads again the timestamp counter and subtracts from it the previously read timestamp value. If the difference is bigger than 0x5FFFFFFF then too much time is passed from one rdtsc to the other, and this means that someone is probably tracing the code (since tracing is much more slower than real execution), so it tries to do something on context.eip, but the ecx pointer is zeroed, giving you another exception inside the exception handler itself. Ok the end is near! We arrive to:

which is the code that decrypts the .text1 section. This is the code section of the protection. This is first layer. We find the second at:

You can now look at 00479000 and you will see all the code is decrypted. So we must trace just a few instructions and we find:

where ebx is 004B4BE3. This is a jump to the code in the .text1 section, so the boring ASM loader is now finished! You can see in this entry point the standard msvc code for WinMain, so you now can dump the executable and disassemble it and you will see the disassembly of the protection code. Let’s go for it.

STEP 2: Fatherland – a parent takes care of his child

Armadillo is now running the code that will become the parent process. The same code will also split into the child process which we will see it later. First of all we let the armadillo run under Ollydbg. We will get a crash of olly itself: it seems nowadays everyone is using this trick, which consists of sending a malformed debug string (lots of %s) which will cause a buffer overflow. So to avoid any problems, put a breakpoint on OutputDebugStringA and modify the string parameter that is passed to it into a simple string (for example “hi\0” ). There are two calls to OutputDebugStringA. Ok, at the beginning the loader is checking some string (INFO, REGISTER and so on) they are the parameters passed to the command line, going on we will find this:

It uses the string %X::DA%08X and transforms it in PID::DANUMBER where PID is the process id of the actual current (parent) process and number is usually a fixed number given from the line 004A07CD (it is xored). The final string is so composed, for example for me it is 938::DAC858ADB2. Of course pid will be different at every execution. This string will be the mutex name used for the OpenMutexA function. Why does it try to open a mutex that has never been created??? Simple, this mutex will be checked also in the child process, so this is the point where the process knows if it must be launched in parent or child mode. If the mutex does not exist, the process will be parent, otherwise it will be child. Now we are going to trace the parent process, later we will see how to trace the child process. We soon find other similar code:

Same as above, there are these two checks on the mutex before the code splits to child / parent flow. After this there is a call to IsDebuggerPresent, so it would be better if you set the PEB.BeingDebugged flag to zero every time you want to trace armadillo. NOTE: On winxpsp2 the PEB and TEB are no more at fixed addresses: usually PEB was always at 7FFDF000 and first TEB was 0x1000 bytes before PEB. Now they are in random addresses, so to find the PEB when the process starts you can look at TEB.Peb (TEB + 0x30), since the TEB address is indicated near the FS segment address base in Ollydbg. Soon after this we see:

A direct check to PEB.BeingDebugged without passing from IsDebuggerPresent, so don’t use breaks on such an API. Now let’s enter in this call.

In the following lines you see some calculus, just skip it, we will analyze it later; for now keep in mind what you have seen in those lines, that is a CreateFileMapping and some memory working on it and pointers adjustment. We come to a fundamental code:

Armadillo re-executes itself. The process being created is suspended but it’s not created in debug mode. In the call

Armadillo with ReadProcessMemory reads two bytes from the child process (the two bytes at entry point) and changes them into EB FE with a WriteProcessMemory, which is a self jumping instruction. This is made so that the child process once running will loop its execution on the entry point. Once we get out from that call we find

This is just a ResumeThread, Sleep, SuspendThread, used to run the program until it loops on the entry point.

The parent process attaches as a debugger to the child process. The call at 004A4C5A uses that function again to restore the bytes at the entry point removing the self-jumping op code. Again there is some calculus that for now we will skip until we arrive to

OK, the parent process is waiting for the child events, so of course we are going to look what kind of events armadillo is interested in, and why. Just in case you miss the event constant identifiers, here it is a little list:

in [ebp-0A24] you have the event type, so following the code and eliminating all the garbage you can make a map of the event handlers:

the ones we are interested in are the EXCEPTION_GUARD_PAGE and EXCEPTION_BREAKPOINT. The rest are not important for our purposes, they regard the normal debugging cycle. For example, the createthread event keeps track of newly created threads and stores their handles, and so on. So for now let’s examine the event sequence, until we see the use of the two handlers we are interested in:

Okay you should have a similar event sequence. All the DLL’s you see are probably loaded when the Armadillo is building the REAL import table. The first exception breakpoint event is ignored from the parent as it’s just the normal DebugBreak call inside the newly created process. It’s far from the program code itself. The interesting thing is the first GUARD_PAGE exception that we have, at address 00441CC0.

STEP 3: COPYMEM2 – swimming in a page pool

If we look at the memory of the child process at 00441CC0 we see:

nonsense code! It is obvious that the page is encrypted. If we look at the process memory regions, for example with Lord-PE, we see that all code sections have the attribute GUARD_PAGE, except the one we are looking now. GUARD_PAGE in fact is a “one-shot access alarm” (I love this definition in the msdn!). However, all pages are in GUARD_PAGE, this means ALL PAGES ARE ENCRYPTED, and they will shoot a GUARD_PAGE notification when executed the first time. So this 00441CC0 is the FIRST line executed from the original code section. This means that this is the original entry point of the packed program. The problem now is: how do we dump the program? If we let it run we are not sure that ALL pages will be decrypted, and in fact you can try and see that even executing the program some pages remain encrypted. The simplest idea is: we force armadillo to decrypt all pages. We must examine the PAGE_GUARD handler. I will paste the most important lines of a generic page decryption:

We see a variable (004e032c) here that keeps the number of decrypted pages (break on this handler more times and you see that number being increased), then the page number is calculated from the virtual address, so the program can use it as an index for the page array in the code section. There is some calculus then stepping into two calls there is the code that we need

The page of the faulting address is turned back in the PAGE_READWRITE attribute.

The parent process reads the memory of the page that was accessed and was in GUARD_PAGE protection.

This is the cycle that decrypts the memory read from the faulting page. It’s not the only one, another one is at

Once the page is decrypted, it is written back to the process

Finally, the attribute of the page is changed again:

The page is changed to PAGE_EXECUTE_READ. Now see this interesting compare:

If the number of decrypted pages is below the threshold, then the execution goes to the ContinueDebugEvent so that the exception is repaired, and the child process continues execution with the decrypted page. If the number of the decrypted pages goes above the threshold, then armadillo checks which pages are decrypted and how often they are used, then it re-encrypts them back to the process so that the number of decrypted pages is always under the threshold value. With this system the program is NEVER completely decrypted in memory, but at max only the page pool is decrypted at the same time. The page pool is the number of pages allowed to be simultaneously decrypted and present in memory. Usually the pool size is the half of the total number of code section pages. This means we can’t dump the executable. Besides, if we try to dump it, usually the dumpers will fail because of the GUARD_PAGE attribute interfering with the ReadProcessMemory used to dump the executable image.

The first thing I did was to write a decrypter for the pages, but the decryption uses random keys that change at every execution, so the simplest solution is to force the routine to decrypt all pages, then dump the decrypted child process. To do this, we simply raise the threshold value so it is never reached, then we modify the code to loop for every page, so, start debugging Armadillo, and arrive at the first PAGE_GUARD exception. I executed all of the handler until it’s end, at address 004a7446. Now the entry point page at 00441000 si decrypted, and we write our shell code. I used the following steps:

[004d97e4] is set to 0x100. This is the threshold value, since the program has 0x48 code pages the re-encryption will never occur. [004a7482] is set to 00400000. This is the page address that each time is passed as the faulting address. I searched every occurrence of the faulting EIP given for this exception, and found it in these memory locations

With every iteration the shell code must overwrite these with our page address (004a7482). Here is the shell code:

This loop will cycle for all the pages until the entry point page, which is already decrypted, so we must not execute the handler on it. You just need to change a bit of the shell code to decrypt pages from the page after the entry point to the end of the section:

After this shell code we finally will have decrypted all the code section. We can now dump the process and we have the code and data sections decrypted. Of course the exe will not run we must still fix some things.

STEP 4: IMPORT TABLE – Rebuilding after war

We fix the entry point of the dumped PE (oep is 00441CC0), and disassemble the dumped exe. First thing I see is just the ep:

This is again the standard entry point of a visual studio compiled exe. The call we see here should be a call to GetVersion, but instead of the API address, we find that horrible 0FC3154. This means that API addresses are redirected using a wrapper or something like this.

Also, we see from the op code that the import table information is completely destroyed, we don’t have the FirstThunk or OriginalFirstThunk information. Everything relies on the memory bridge at 0FC3154. You can look at the code and see that a lot of imports are redirected towards that memory bridge. So what are we waiting for? Let’s dump that bridge from the child process. You can use LordPE to see the child process memory regions and their size. The region we are dumping goes from 00FC2000 to 00FCB000. It’s just a data region, so with IDA you can transform all the bytes in dwords. I used this little script

Load it as an idc file and call it from idc command window passing starting and ending addresses. All the bridge bytes will be dworded. We see a lot of zeroed memory, a lot of strange nonsense dwords, the interesting thing is this little piece:

This is our IAT. We see API thunks (those 77xxxxxx addresses), and some other strange 00E8xxxx thunk. This makes me think that some api’s are called directly, some others are wrapped by another memory layer (the 00E8* one). Let’s look again with LordPE at the child process memory. This time our attention should be attracted by the memory around this bridge:

The first block is of 0x1000 bytes, then the second is an executable block... it seems this is a dll! We can look at the module list of the child process, but there is no module at imagebase 00E70000, probably this is a dll that armadillo loaded by itself. Let’s dump it!

We look into LordPE and it is a normal dll, it has imports and exports. In the export window and we also see its name string: “security.dll”. There is only one export: SetFunctionAddresses. Ok, let’s disassemble this dll and look at 0E8A452:

where

This function just returns the value A280105, which is the value returned by GetVersion. This is API emulation. Luckily there are only a few emulated APIs. Other kinds of APIs are wrapped with some types of wrappers; for example:

This wrapper calls MessageBoxA, before it calls GetTickCount to fool automatic tracers. First five bytes of the API are checked to see if there is a breakpoint on it (0xCC byte). API addresses are stored in the security dll but are subtracted by 0x64 bytes. That’s why you see those add edx, 64h. In another kind of wrapper the API call is encrypted instead:

there are calls to Enter/LeaveCriticalSections (again it fools automatic tracers), then the call to the real API (in this case this wrapper calls LoadLibraryA) is in an encrypted code block. It is decrypted at runtime, the call is executed and then the block is re-crypted. There are some other simpler variants of these wrappers, where there are no tricks, or just some calls to time function. If you can’t figure out what API is called you can assemble a call to the wrapper in the child process and see where it goes. This introduces a new problem!

STEP 4.1: SECURITY.DLL – tracing the child process

Having this self loaded DLL in the child process means we need to debug it. How can we debug the child if the father is part of its execution? Well we can at least debug the loader until the oep of the application. Then PAGE_GUARD and BREAKPOINT faults will not be handled and the program won’t run, but that’s not a problem for now. First of all start the parent with olly. We break on WaitForDebugEvent and let it run. Ok, we break on the first debug event, that is CREATE_PROCESS. Coming out from the API we are at

If we trace the CREATE_PROCESS event handler we find

going on we see

where the mutex name is PID::DANUMBER, and the mutex we have seen above. So reassuming we have:

also two other mutexes are created, named DILLOOEP and DILLOCREATE. We execute this handler so that per-process initialization is done correctly. Note that we also encounter this line

It resumes the main thread of the application. You must not execute it, just set edx to zero so the ResumeThread will fail. Why? Simple. Our idea is to detach the parent debugger, and attach ourselves as debugger. If we resume the thread, when we detach, the debugger will be shut down, and the thread suspend count will go to zero, running the thread before we can attach to it. Once this resume is failed, we let the Armadillo run, and wait for the second break on WaitForDebugEvent. We exit from the function, and when at the line 004A4DDF we assemble

Now the parent is detached. Don’t close the parent debugged process. We open another instance of olly and attach to the child process (use its pid to recognize it). We will break on ntdll.DbgBreakPoint. We can set a bpx on program entry point (004C9000), and we must go to view->threads and resume the thread, because when we detached we missed the ContinueDebugEvent, so the thread suspend count was not updated.

Okay, once you resume the thread, you can run the child and it will break on the entry point. Now we can step through the child. We directly set a break on OpenMutexA, so we go to the parent / child forking code. We have two breaks, on the code we have just seen in step 2:

If you correctly executed the CREATE_PROCESS event handler in the parent, these function will return valid handles. So now that the mutexes are valid, the execution will go to the child flow. First thing we find is this call is:

Step over it (remember that you must have a break on OutputDebugStringA to avoid olly crash) and you will see that after this call the dll is mapped and ready to be used (look in view->memory and see the region in 00E70000). We continue and see some calls to the dll, until we get to

This is a call to the dll, then if you let the program run you will arrive at

This is the entry point, breaking on access. Now you can assemble the calls to the redirected apis, and trace them if needed. Of course you can trace the dll loading, just enter in the call to 0049F70B. The code allocates memory for the dll then maps it, then there is a call to:

the address 00EA31DD, which is the entry point of the dll. If you dump the dll, the image base will be 0x10000000, change it to 00E70000 so when disassembling it you will have the same memory addresses you see in the child process. NOTE that 0x00E70000 is a dynamic allocation, it will probably be a different address on other computers. After this there is a call to the only exported API from that dll

it sets some function pointer.

Here there are the calls to OutputDebugStringA. First thing I want to know is emulated apis. I know that there is the emulation code for GetVersion, we have seen above that the GetVersion value is placed at 00EB7D60, so we go to the call to the security.dll entry point, and set a memory breakpoint on 00EB7D60. We will break into

Okay, that’s what we wanted to know. If we continue stepping we find some other emulated api

Our emulation information is built, now we know emulated apis:

only four. We are lucky. In the same way we find other iat information:

and so on.

STEP 4.2: IMPORTS – Analysis and rebuilding

Now we know the emulated apis, and we know how to determine redirected apis. What we need to do is change the address of the redirection bridge with the address of the real API thunk in the program’s original code section. We have:

The first thing we do is scan the original code and see what imports in the code are redirected to the security.dll. I have lost the code of such a scanner, but you can easly adapt the following code of the rebuilder to make it. Well, once the scan is complete you have a list of 0x00E8xxxx addresses that are used in the code section. With the previous step we have seen how to find the API to which they point to, so we will have the following list:

Now it’s done. We have everything we need to rebuild the import table. First of all we add a new section to build the IAT

Then in the first 0x200 bytes we put the import table itself, with all descriptors. I made descriptors for all the dlls of the process, though they will not be in the import table, so remember to delete the unwanted ones after the rebuilding.

The last three import descriptors are the ones that originally were in the IT. Here is the code for the rebuilder:

• See -> Importalizer\data.h
• See -> Importalizer\main.cpp

The program scans the code section to find all addresses relative to the memory bridge (0x00FC3*). When found, it looks in the bridge for the bytes at the given address. If these bytes are not an API thunk then they are the address of the security.dll, so from our associative array it extracts the API thunk corresponding to the security.dll wrapper. Once the API thunk is found, the program writes it in our newly created import table. As a result we will obtain an executable with all imports pointing to the correct API addresses. We created the import table so that the pointer of the OriginalFirstThunk is the same of the FirstThunk. Now that we have the correct import table and the correct import address table, we can use any import rebuilder, and our OriginalFirstThunk will be created. Now we have a perfect import table.

STEP 5: NANOMITES – Here comes the pain!

The program is dumped, decrypted and rebuilt, but it still is not running. Let’s have a look at the code, everything is ok, the imports are ok, let’s look at the WinMain:

int 3? What is it doing there? If we look around we find a lot of those int 3’s. Of course this means we need to debug the parent process in the EXCEPTION_BREAKPOINT handler. If we have a fast look, we break on that handler (004a5adf), we see a call to GetThreadContext which gives us the context.eip = 00401D10, then at the end of the handler we have a call to SetThreadContext, where context.eip is being set to 00401D14. So basically int 3 is just a change of eip, a jump. Now we must analyse the handler; here is the code of it, with no garbage and divided into blocks:

All these code blocks use static or dynamic arrays of data and functions, some functions are executed dynamically. Maybe using some image will clarify the situation:

Okay this is the structure of the nanomites processing. We see that the EIP and EFLAGS from the context of the child process are used in the calculus, so what is now clear is that nanomites are used to emulate jumps, both conditional or unconditional. Every 0xCC in the code represents a jump. What we can do now is try to fix every 0xCC to its original opcode, or make an emulator of these jumps. Fixing the code is not easy, we should code a scanner which supports instruction tracing. Armadillo infact can’t recognize if a 0xCC is really a nonomite or not, so for example if we scan the code section and we meet the bytes of the instruction

we would trash the original instruction trying to fix this non-nanomite. Even having a disassembling engine, it would be easy to make mistakes and patch wrong 0xCCs. So what I did is coded the emulator. I took all the functions of the breakpoint handler, and inlined them in C, then dumped all the data used by the emulation blocks and the functions. It needed to be modified a little, but with some time the work is done. Once I had all the emulation functions, I just had to code a parent process which makes emulation:

• See -> Armadillo Nanomulator/main.cpp
• See -> Armadillo Nanomulator/core.h
• See -> Armadillo Nanomulator/core.cpp
• See -> Armadillo Nanomulator/coredata.cpp

The End

Thanx to Arilou and Neoxquick who helped me with Armadillo. Thanx to my personal beta-reader, Devine9.
Greetings to all my RET friends and all UIC guys.
A super greet to the super The_Enigma aka Giulia :)
GoodBye!

[AndreaGeddon] andreageddon@gmail.com my mail
[RET] www.reteam.org RET's great site
[UIC] www.quequero.org Italian University of Cracking

Disclaimer