This post is a little bit long, for a better reading you can download the pdf version here: http://www.box.net/shared/static/nexbjpy0p6.pdf

Roaming around Symantec web pages I stumbled on a review of a trojan named Ascesso. The malware does a lot of things that are described inside the “Technical details” section. I decided to give it a try just because it’s interesting to read what a malware does, but it’s much more funny when you play with it! In this blog entry I won’t talk about what the malware does, but I’ll write something about the way I used to obtain a readable dead list inside Ida. One of the next blog entry could be focused on the analysis of the malware, don’t know.

The file I’m going to analyze is named asc3550.sys, md5=BBEB49A32417226CABED3E104A9C94B5.
The malware is crypted, I think it’s a home made protection. If you load the file in Ida you are not able to see too much, almost all the code has been crypted. To view the uncrypted malware you have two options: you can run the driver dumping the memory image using a ring0 dumper (i.e. softice+icedump), or you can use Ida trying to convert the initial output into something really closer to the original driver. Generally, I like to work on a simple dump of the packed/crypted file, but with a driver I prefer to work on a perfect file. With a simple dump of the image you’ll have to deal with instructions like:
Code:

Code:

.text:0040381B   call  dword ptr ds:0F77B3664h

.text:004028F9   mov   dword ptr [edi], 0F77AF000h

.text:0040294E   movzx eax, byte ptr ds:0F77B36D2h

It’s hard to say what’s going on when you have unknown addresses in front of you. I think you’ll prefer to look at something like:
Code:

This is what I’m going to do.


Initial decryption
When you load the file in Ida the decryption routine is the only visible code:
Code:

These are the starting instructions. Reading through various forums I had the impression that most of the people have some problems trying to anaylize this kind of snippets. It’s pretty obvious what the snippet does, it’s a simple decryption routine consisting in a sub operation. The main problem is: which part of code will be decrypted? Everything depends on value stored inside edx register, which is obtained by the instructions inside the call 400242:
Code:

How to know the exact value pointed by [esp+8]? Taking in mind that the file I’m analyzing is a .sys file you can get the value inside the stack with a simple deducting reasoning.

The first driver instruction is the one at 400240, but who brings me there? I mean, there should be an instruction which is executed before the one at 400240. The instruction is a call and it’s somewhere inside IopLoadDriver function (in ntoskrnl.exe):
Code:

[edi+2C] points to DriverInit, 400240 in this particular case. Look at the last parameter (pDriverObject), it’s really important. You have to concentrate on the stack only, when you are at the first driver instruction you’ll have something like:
Code:

Here’s how the stack looks like when you are inside the “call sub_400242″, at address 400242: Code:

Now it’s pretty easy to retrieve the starting value of edx: Code:

Just a little more step and you’ll have the value we are searching for. Look a the definition of the DRIVER_OBJECT structure, taken from ntddk.h:
Code:

DRIVER_OBJECT+0Ch is DriverStart, the memory address that points to the first byte of the driver. I don’t have the possibility to know the exact value stored inside DriverStart field, but for a static analysis you can suppose that the address is the ImageBase: 0×400000. It comes out that the edx value we want is: 0×400000+0×9540 = 0×409540

It’s time to decrypt the bytes using this simple idc script: Code:

I inserted the Message function just because I wanted to see the first non-decrypted address: 0×409A9C; you can remove the function, if you prefer.
Ok, now that the decryption is complete I have to look at the decrypted code. The last instruction of the initial decryption routine will bring me directly at a fresh decrypted instruction, which is the next instruction to be executed? Code:

The decrypted code is a small routine, all the other bytes of the file are still crypted; maybe I have to deal with some more layers. The decrypted code contains an initializations part, some calls end a final jmp instruction.


Initialization
It’s pretty easy to understand the initialization code. I won’t attach any snippet,it’s only a sequence of mov/add/lea instructions used to retrieve/store some special values that are used later.
At the end of the initialization part there’s a piece of code which is used to move 0×44 bytes: Code:

Do you know what 400240 is? It’s the entry point of the file. It’s something to remember for the next decryption script.


Sections decryption
The first interesting piece of code is located inside a call at 0×4095C1, before studying the call I prefer to take a look at the parameters: Code:

I can’t get any clue from the parameters, I can’t say nothing else without spying the code. After a little investigation over the previous instructions I discover what the parameters are:
- ebx = DriverStart
- eax = 0×409A38
- 1
- dword ptr [ebp+401BECh] = 0×9540
- dword ptr [ebp+401BF8h] = 0×8FA0

Just wait some minutes and I’ll tell you everything about these parameters.
As you can see I renamed the call, the name suggests the task performed by the call: all the sections are decrypted. The call contains a loop which is executed until all the sections are not decrypted; it starts from the last section. At each round, it firstly gets the pointer to the IMAGE_SECTION_HEADER of the current section (he needs to know where the section starts/ends) and then decrypt it. The decryption algo is really simple: Code:

Another simple decryption. This time a xor instruction between the crypted dword and a fixed value, it’s 0×003CF5B5 and it’s located at address 409A38.
Look at the comments I inserted in the code, don’t you have any doubt about it? The decryption routine resides in .reloc section, is it possible to decrypt all the bytes in .reloc section? Well, no because if you decrypt every single byte you’ll decrypt the decryption routine generating a bsod. That’s why the call needs the first two parameters (0×9540 and 0×8FA0). The values are taken from .reloc IMAGE_SECTION_HEADER. One of them, 0×8FA0, is the Raw Offset of of the section. To calculate the number of bytes to decrypt the malware uses 0×9540 substracting 0×8FA0 from it, obtaining 0×5A0. These are the bytes to decrypt. The rest of the bytes belong to the decryption routine I’m checking and they are untouchables.

Exploring the decryption routine I found a strange piece of code I’m not able to totally understand: Code:

Three things:
1. it checks for ‘rsrc’. This is a common name generally used for resource type section, if the file contains this particular section the decryption won’t be executed over that section. The driver doesn’t have a .rsrc section for sure, why the author needs to add this check?
2. do you remember the 5 parameters passed to the function? One of them is the value 1. At 40995A it checks that value. The condition is satisfied and the conditional jump occours. This function is called one time only, which is the purpose of this check?
3. it really needs two parameters (0×9540, 0×8FA0) and a sub instruction? It only needs 0×5A0 and a different implementation algorithm.

I don’t have an answer for the first two things, but I think the author ripped this code. Why? It’s a behaviour of some packers, they leave resource section untouched. Moreover, there’s another check for [ebp+Fixed_Value_1]: Code:

Call_4099A7 is almost identical to Call Decrypt_current_section, they only differ by a pushad, nothing more. Hm, who adds an useless bugged function in his code? I might be wrong but ‘rip’ is the first thing I can think of, what do you think?

Anyway, here is the script I used to decrypt the entire file:
Code:

The decryption ends here. Now…


Relocation: to fix or not to fix, that is the question
When the file is totally decrypted the loader has to fix some things: relocations, some pe fields and something else. The function able to fix relocation is located at 40962F, essentially the algorithm is:

http://zairon.files.wordpress.com/2007/10/reloc_procedure.JPG

This diagram should be enough for you to understand the algo. Taking in mind I’m going to reconstruct a fully readable file under IDA, is it necessary to change the relocated addresses? The answer is no; as you can see from the picture above relocation is not applied when DriverStart is equal to ImageBase, I’ll do the same.


Fix PE fields
After relocation there’s a little function, it changes some fields in the PE header. Code:

Some minor changes to PE header. It changes rva and size relative to IMAGE_DIRECTORY_ENTRY_EXPORT and IMAGE_DIRECTORY_ENTRY_BASERELOC.
Again, there’s a strange thing in this piece of code. It zero-es PE+78 and PE+7C while they are already zero…


Change FirstThunk field
The last part of the loader, the function starts at 4096B7. The algorithm fixes every single FirstThunk element overwriting the old value with the starting memory address of the relative function. Code:

The external loop scans every single IMAGE_IMPORT_DESCRIPTOR structure, and the internal function changes every single FirstThunk.
To understand the algo I’ll show you a little example explaining how to fix one element, the first function (KfAcquireSpinLock) of the first dll (Hal.dll). This is the IMAGE_IMPORT_DESCRIPTOR: Code:

FirstThunk array starts at rva 45C0 and it contains 2 elements: Code:

The first two dwords are relative to the two Hal.dll’s imported functions, and the 3° dword represents the null terminator dword. I’m interested in the first function, _IMAGE_IMPORT_BY_NAME is located at rva 0×8A34: Code:

At this point the malware uses MmGetSystemRoutineAddress to retrieve the function’s address, that’s why MmGetSystemRoutineAddress is one of the functions imported by the original encrypted file. Once it has the address of the function it stores the memory address at 4045C0.
There’s a little exception in this system regarding the function from ndis module, the malware doesn’t use MmGet.. function but it takes the addresses directly from the running module. Why? I’m sure you can easily find out why by yourself.

Now, to obtain a readable dead list I have to write a simple idc script able to convert:
Code:

to the more readable instruction:
Code:

Here is the script: Code:

That’s all, now you can explore the malware.