1. IDA plugin: Extract (UnRot13) and analyze

    Some times ago I stumbled on a post at Offensive Computing where an user had some problems trying to figure out the encryption used by a malware (md5=36401cb9178232dde01b2788e8fc56f4).
    The malware contains 2 files located in the resource section. The files are encrypted, how to find out the encryption scheme? Well, using a debugger I would say. I didn’t start any debugger btw, deciding to take a look at the files using a resource editor. It’s a common thing to store files inside resource section. Here are the starting bytes of the first file:

    If you know which are the first common bytes in an exe file you should be able to figure out yourself which kind of encryption has been used. The presence of many 013 bytes is a nice hint, the file has been rot13-ed.

    In an old blog entry ( I talked about a little ida plugin able to extract and analyze an hidden file; I slightly changed the plugin adding the possibility to un-rot13 the hidden file. Take a look at the simple dialog:

    You can download the plugin from:
  2. Some words on how to decrypt trojan Ascesso

    This post is a little bit long, for a better reading you can download the pdf version here:

    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:
    .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:
    .text:0040381B   call  ds:_ExAllocatePoolWithTag
    .text:004028F9   mov   dword ptr [edi], offset __ImageBase
    .text:0040294E   movzx eax, ds:byte_4046D2
    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:
    00400240 000    jmp  short loc_400257   ; Entry point
    00400242     sub_400242 proc near
    00400242     arg_4= dword ptr  8
    00400242 000    lea  edx, [esp+arg_4]
    00400246 000    mov  edx, [edx]
    00400248 000    mov  edx, [edx+0Ch]
    0040024B 000    add  edx, 9540h
    00400251 000    mov  eax, 9AEDh
    00400256 000    retn
    00400256     sub_400242 endp
    00400257     loc_400257:
    00400257 000    call sub_400242
    0040025C 000    pusha
    0040025D 020    push 55Ch
    00400262 024    pop  ecx
    00400263     Decrypt_1:
    00400263 020    mov  eax, [edx]        ; Current dword to decrypt
    00400265 020    sub  eax, 0FA598390h   ; Decryption: sub operation
    0040026A 020    mov  [edx], eax        ; Save the decrypted dword
    0040026C 020    lea  edx, [edx+4]      ; Next dword to decrypt
    0040026F 020    sub  ecx, 4
    00400272 020    test ecx, ecx
    00400274 020    jnz  short Decrypt_1
    00400276 020    popa
    00400277 000    mov  ecx, 9B29h
    0040027C 000    add  edx, 2
    0040027F 000    add  edx, 6
    00400282 000    jmp  edx
    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:
    00400242 lea  edx, [esp+8]     ; stack value
    00400246 mov  edx, [edx]       ; edx is an address !?!
    00400248 mov  edx, [edx+0Ch]   ; edx points to a structure !?!
    0040024B add  edx, 9540h       ; add operation
    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):
    PAGE:004DCFE2 020 push [ebp+68h+PreviousMode]   ; PUNICODE_STRING RegistryPath
    PAGE:004DCFE5 024 push edi                      ; PDRIVER_OBJECT pDriverObject
    PAGE:004DCFE6 028 call dword ptr [edi+2Ch]      ; Call DriverEntry
    [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:
    esp+00h: IopLoadDriver_return_address
    esp+04h: pDriverObject
    esp+08h: RegistryPath
    esp+0Ch: …
    Here’s how the stack looks like when you are inside the “call sub_400242″, at address 400242:
    esp+00h: call_400242_return_address
    esp+04h: IopLoadDriver_return_address
    esp+08h: pDriverObject
    esp+0Ch: RegistryPath
    esp+10h: …
    Now it’s pretty easy to retrieve the starting value of edx:
    00400242 lea  edx, [esp+8]        ; edx = pDriverObject
    00400246 mov  edx, [edx]          ; edx points to the first byte of DRIVER_OBJECT structure
    00400248 mov  edx, [edx+0Ch]      ; edx = DRIVER_OBJECT+0Ch
    0040024B add  edx, 9540h          ; edx = edx + 09540
    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:
    typedef struct _DRIVER_OBJECT {
    CSHORT Type;                   // +000
    CSHORT Size;                   // +002
    PDEVICE_OBJECT DeviceObject;   // +004
    ULONG Flags;                   // +008
    PVOID DriverStart;             // +00C
    ULONG DriverSize;              // +010
    PVOID DriverSection;           // +014
    PDRIVER_EXTENSION DriverExtension;   // +018
    UNICODE_STRING DriverName;           // +01C
    PUNICODE_STRING HardwareDatabase;    // +024
    PFAST_IO_DISPATCH FastIoDispatch;    // +028
    PDRIVER_INITIALIZE DriverInit;       // +02C
    PDRIVER_STARTIO DriverStartIo;       // +030
    PDRIVER_UNLOAD DriverUnload;         // +034
    PDRIVER_DISPATCH MajorFunction[IRP_MJ_MAXIMUM_FUNCTION + 1];   // +038
    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: 0400000. It comes out that the edx value we want is: 0400000+09540 = 0409540

    It’s time to decrypt the bytes using this simple idc script:
     static main()
       auto CurrentAddress, i;
       CurrentAddress = 0409540;
          PatchDword(CurrentAddress, (Dword(CurrentAddress) - 0xFA598390));
          CurrentAddress = CurrentAddress + 4;
       Message(”\nDecryption done, last address: %X”, CurrentAddress);
    I inserted the Message function just because I wanted to see the first non-decrypted address: 0409A9C; 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?
    00400276 popa              ; edx = 0409540
    00400277 mov  ecx, 9B29h   ; ecx = 09B29
    0040027C add  edx, 2       ; edx = 0409540 + 2 = 0409542
    0040027F add  edx, 6       ; edx = 0409542 + 6 = 0409548
    00400282 jmp  edx          ; jmp 0409548
    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.


    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 044 bytes:
    .reloc:00409592 add  edi, [ebp+401BF4h]   ; edi = 400240
    .reloc:00409598 lea  esi, [ebp+401D52h]   ; esi = 409A48
    .reloc:0040959E mov  ecx, 44h
    .reloc:004095A3 rep movsb
    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 04095C1, before studying the call I prefer to take a look at the parameters:
    .reloc:004095B1 push dword ptr [ebp+401BF8h]   ; ebp+401BF8 and ebp+401BEC were setted
    .reloc:004095B7 push dword ptr [ebp+401BECh]   ; up in the initialization part
    .reloc:004095BD push 1
    .reloc:004095BF push eax
    .reloc:004095C0 push ebx
    .reloc:004095C1 call Decrypt_First_5_Sections
    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 = 0409A38
    - 1
    - dword ptr [ebp+401BECh] = 09540
    - dword ptr [ebp+401BF8h] = 08FA0

    Just wait some minutes and I’ll tell you everything about these parameters.
    As you can see I renamed the call, the name suggests ...

    Updated October 4th, 2007 at 13:09 by ZaiRoN

Page 2 of 2 FirstFirst 12