Binary Auditing Training Package unpackme_03
Introduction
Today, I was bored so I decided to have fun with http://www.binary-auditing.com/.
And I found a very fun challenge inside unpacking exercices :
Unpackme
Packer starts here :
seg009:00411800 start proc near
seg009:00411800 call $+5
seg009:00411805 xor ebp, ebp
seg009:00411807 pop ebp
seg009:00411808 sub ebp, offset word_401A1E
seg009:0041180E xor ebx, ebx
seg009:00411810 lea eax, byte_401A4D[ebp]
seg009:00411816
seg009:00411816 loc_411816: ; CODE XREF: start+1Fj
seg009:00411816 inc bl
seg009:00411818 mov cl, [eax]
seg009:0041181A xor cl, bl
seg009:0041181C cmp cl, 55h
seg009:0041181F jnz short loc_411816
seg009:00411821 mov ecx, 55Ah
seg009:00411826 lea esi, byte_401A4D[ebp]
seg009:0041182C mov edi, esi
seg009:0041182E
seg009:0041182E loc_41182E: ; CODE XREF: start+32j
seg009:0041182E lodsb
seg009:0041182F xor al, bl
seg009:00411831 stosb
seg009:00411832 loop loc_41182E
The first loop is for computing key for XOR operation. ebx will be equal to 0x77.
The second loop will decrypt first stage of the packer with the key stored into ebx.
Next the packer will resolve base address of kernel32.dll by getting the current structured exception handling (SEH) frame into fs:[0] and get an address inside kernel32 after the seh handler, and back
from this address into memory for finding 'PE' and 'MZ' signature.
At this point it will have the base address of kernel32.dll
Then it will parse PE header of this dll, get export function name table and search for GlobalAlloc().
It will Alloc some space, and copy different portion of code into it. We will return to the analysis of this code later (some stuff are here for api resolution during main execution).
For not loosing time by analysing all the copy of portion of code, we will setup memory breakpoint on acces on code section and run our debugger.
We land here :
00157BFC AD LODS DWORD PTR DS:[ESI]
00157BFD 35 DEC0ADDE XOR EAX,DEADC0DE
00157C02 AB STOS DWORD PTR ES:[EDI]
00157C03 ^ E2 F7 LOOPD SHORT 00157BFC
00157C05 C3 RET
At this point ecx equal to 0x1E00, and raw size of code section equal to 0x7800, so it's actually deciphering all code section with 0xDEADCODE as XOR key.
Disable the memory breakpoint on access, and go to ret, then do the operation again (setup memory breakpoint acces), and we land here :
00157BEB 8DBD BF6F4000 LEA EDI,DWORD PTR SS:[EBP+406FBF]
00157BF1 8B85 A71F4000 MOV EAX,DWORD PTR SS:[EBP+401FA7]
00157BF7 8B0F MOV ECX,DWORD PTR DS:[EDI]
00157BF9 81C1 00004000 ADD ECX,400000 ; ASCII "MZP"
00157BFF C601 E8 MOV BYTE PTR DS:[ECX],0E8
00157C02 83C1 05 ADD ECX,5
00157C05 50 PUSH EAX
00157C06 2BC1 SUB EAX,ECX
00157C08 8941 FC MOV DWORD PTR DS:[ECX-4],EAX
00157C0B 58 POP EAX
00157C0C 81C7 88000000 ADD EDI,88
00157C12 837F 04 00 CMP DWORD PTR DS:[EDI+4],0
00157C16 ^ 75 DF JNZ SHORT 00157BF7
00157C18 C3 RET
Do you recognize this operation ?
Opcode 0xE8, add 5 ?, it is making a call.
The destination of the call (eax) go to the first virtual part I talked, we will call this "api address solving".
The packer is making call redirection for each API.
The next memory breakpoint on access will land us here :
004085D4 E8 9706D5FF CALL 00158C70
A call crafted juste before, let's follow it.
00158C70 9C PUSHFD
00158C71 60 PUSHAD
00158C72 E8 00000000 CALL 00158C77
00158C77 5D POP EBP
00158C78 81ED 1C1C4000 SUB EBP,401C1C
00158C7E 8BBD B01C4000 MOV EDI,DWORD PTR SS:[EBP+401CB0]
00158C84 8B7424 24 MOV ESI,DWORD PTR SS:[ESP+24]
00158C88 83EE 05 SUB ESI,5
00158C8B 81EE 00004000 SUB ESI,400000 ; ASCII "MZP"
00158C91 81EF 88000000 SUB EDI,88
00158C97 81C7 88000000 ADD EDI,88
00158C9D 3B37 CMP ESI,DWORD PTR DS:[EDI]
00158C9F ^ 75 F6 JNZ SHORT 00158C97
00158CA1 68 2680ACC8 PUSH C8AC8026
00158CA6 FFB5 B41C4000 PUSH DWORD PTR SS:[EBP+401CB4]
00158CAC E8 A4000000 CALL 00158D55
00158CB1 8D4F 48 LEA ECX,DWORD PTR DS:[EDI+48]
00158CB4 8BD1 MOV EDX,ECX
00158CB6 E8 3B000000 CALL 00158CF6
00158CBB 51 PUSH ECX
00158CBC FFD0 CALL EAX
00158CBE 93 XCHG EAX,EBX
00158CBF 68 EEEAC01F PUSH 1FC0EAEE
00158CC4 FFB5 B41C4000 PUSH DWORD PTR SS:[EBP+401CB4]
00158CCA E8 86000000 CALL 00158D55
00158CCF 8D4F 08 LEA ECX,DWORD PTR DS:[EDI+8]
00158CD2 E8 1F000000 CALL 00158CF6
00158CD7 51 PUSH ECX
00158CD8 53 PUSH EBX
00158CD9 FFD0 CALL EAX
00158CDB 8D4F 08 LEA ECX,DWORD PTR DS:[EDI+8]
00158CDE E8 13000000 CALL 00158CF6
00158CE3 8D4F 48 LEA ECX,DWORD PTR DS:[EDI+48]
00158CE6 E8 0B000000 CALL 00158CF6
00158CEB 894424 1C MOV DWORD PTR SS:[ESP+1C],EAX
00158CEF 61 POPAD
00158CF0 9D POPFD
00158CF1 83C4 04 ADD ESP,4
00158CF4 FFE0 JMP EAX
- At 0x00158C84, it will get from where the call occured.
- It will substract 5 and ImageBase to it.
- And look into the same table (for making call) if the offset is known.
- Once he found this offset into its table, it will resolve Address of LoadLibrary (0xC8AC8026 rol 7).
- Before calling 0x00158CF6, it will set into edx an address at offset 0x48 of the index into the table.
- 0x0x00158CF6 is just here for not (~) operation on each byte until it get a null byte.
- And then LoadLibrary with the string deciphered by not operation.
- 0x00158CCA it will call back again 0x00158D55 but with hash 1FC0EAEE for resolving address of "GetProcAddress".
- 0x00158CCF, decipher some stuff starting at offset 0x8.
- And finally GetProcAddress of it.
- All the string will be cypher again juste after as you can see.
Maybe with a schem it will be more clear, example of a typical call to an api :
So if you follow me, here is the structur for each api :
struct api
{
DWORD offset; /* +0x00 */
DWORD unknow; /* +0x04 */
char api_name[0x40]; /* +0x08 */
char dll_name[0x40]; /* +0x48 */
};
Here is one exemple :
Writing test program :
> cat test.c
int main(void)
{
char api_name[] = "\xB8\x9A\x8B\xB2\x90\x9B\x8A\x939A\xB7\x9E\x91\x9B\x93\x9A\xBE\xFF\xFF";
char dll_name[] = "\xB4\xBA\xAD\xB1\xBA\xB3\xCC\xCD\xD1\xBB\xB3\xB3\xFF\xFF";
int i;
for (i = 0; i < strlen(api_name); i++)
api_name[i] = ~api_name[i];
for (i = 0; i < strlen(api_name); i++)
dll_name[i] = ~dll_name[i];
printf("%s\n", api_name);
printf("%s\n", dll_name);
}
> ./test
GetModueHandleA
KERNEL32.DLL
This entry in the table was for solving call to GetModuleHandleA() from kernel32.dll
So for dumping our program, we will have to reconstruct all those redirections, we will write a dll and inject it into the process.
What the injected code will do ?
- Search call addr into code section, where the content of addr equal to a call to virtual memory (GlobalAlloc()) "api address solving".
- Hook the jmp eax, for gaining control, we will replace it by a jmp ebx.
- Store result (api address) into idata section.
- Replace each call virtual memory by jmp dword ptr[idata_section].
But have we got enough for replacing call
Opcode for jmp dword ptr [0x42424242] = FF 25 42 42 42 42, size : 6, we got enought place.
Code for the dll :
#include <stdio.h> #include <Windows.h> #define LDE_X86 0 #ifdef __cplusplus extern "C" #endif int __stdcall LDE(void* address , DWORD type); void fix_call(void) { IMAGE_DOS_HEADER *idh = NULL; IMAGE_NT_HEADERS *inh = NULL; IMAGE_SECTION_HEADER *ish = NULL; IMAGE_SECTION_HEADER *ish_import = NULL; DWORD imagebase; DWORD imageend; FILE *fp = NULL; DWORD i; BYTE *ptr; int val; DWORD addr_call; DWORD nb_api = 0; fp = fopen("debug_msg.txt", "w"); if (!fp) MessageBoxA(NULL, "fopen failed :(", "failed", 0); imagebase = (DWORD)GetModuleHandle(NULL); idh = (IMAGE_DOS_HEADER *)imagebase; inh = (IMAGE_NT_HEADERS *)((BYTE*)imagebase + idh->e_lfanew); ish = (IMAGE_SECTION_HEADER*)((BYTE*)inh + sizeof (IMAGE_NT_HEADERS)); imageend = imagebase + inh->OptionalHeader.SizeOfImage; fprintf(fp, "Image Base : %08X\nImage End : %08X\n", imagebase, imageend); ish = (IMAGE_SECTION_HEADER*)((BYTE*)inh + sizeof (IMAGE_NT_HEADERS)); ish_import = (IMAGE_SECTION_HEADER*)((BYTE*)inh + sizeof(IMAGE_NT_HEADERS) + sizeof(IMAGE_SECTION_HEADER) * 4); fprintf(fp, "Ish Import : %08X\n", imagebase + ish_import->VirtualAddress); for (i = 0; i < ish->Misc.VirtualSize; i++) { ptr = (BYTE*)(imagebase + ish->VirtualAddress + i); /* Look for a call */ if (*(ptr) == 0xE8) { val = *(ptr + 4) << 0x18 | *(ptr + 3) << 0x10 | *(ptr + 2) << 0x8 | *(ptr + 1); val += imagebase + ish->VirtualAddress + i + 5; /* Is destination inside code section ? */ if (val > imagebase + ish->VirtualAddress && val < imagebase + ish->VirtualAddress + ish->Misc.VirtualSize) { ptr = (BYTE*)val; addr_call = val; /* Look for a call */ if (*(ptr) == 0xE8) { val = *(ptr + 4) << 0x18 | *(ptr + 3) << 0x10 | *(ptr + 2) << 0x8 | *(ptr + 1); val += (int)ptr + 5; /* Is destination is not into code section ? */ if (val < imagebase + ish->VirtualAddress || val > imagebase + ish->VirtualAddress + ish->Misc.VirtualSize) { fprintf(fp, "Call Redirect found at %08X to %08X, ", imagebase + ish->VirtualAddress + i, val); ptr = (BYTE*)val; /* Change JMP EAX to JMP EBX */ val = imagebase + ish->VirtualAddress + i; *(ptr + 0x85) = 0xE3; __asm { pushad mov ebx, end_api mov eax, val call eax end_api: add esp, 8 mov val, eax popad } fprintf(fp, "Addr Api : %08X\n", val); /* Put Api Addr into idata section */ ptr = (BYTE*)(imagebase + ish_import->VirtualAddress + 0x58 + nb_api * 8); memcpy(ptr, &val, 4); val = (imagebase + ish_import->VirtualAddress + 0x58 + nb_api * 8); /* Replace call by jmp dword ptr [idata_section] */ ptr = (BYTE*)addr_call; *ptr = 0xFF; *(ptr + 1) = 0x25; memcpy(ptr + 2, &val, 4); nb_api++; } } } } } fclose(fp); } BOOL (__stdcall *Resume_GetVersionExA)(LPOSVERSIONINFO lpVersionInfo) = NULL; BOOL __stdcall Hook_GetVersionExA(LPOSVERSIONINFO lpVersionInfo) { DWORD return_addr; __asm { mov eax, [ebp + 4] mov return_address, eax } if (return_addr == 0x00405ABF) { MessageBoxA(NULL, "ready ?", "Ready ?", 0); fix_call(); __asm jmp $ } return Resume_GetVersionExA(lpVersionInfo); } void setup_hook(char *module, char *name_export, void *Hook_func, void *trampo) { DWORD OldProtect; DWORD len; FARPROC Proc; Proc = GetProcAddress(GetModuleHandleA(module), name_export); if (!Proc) { MessageBoxA(NULL, name_export, module, 0); } len = 0; while (len < 5) len += LDE((BYTE*)Proc + len , LDE_X86); memcpy(trampo, Proc, len); *(BYTE *)((BYTE*)trampo + len) = 0xE9; *(DWORD *)((BYTE*)trampo + len + 1) = (BYTE*)Proc - (BYTE*)trampo - 5; VirtualProtect(Proc, len, PAGE_EXECUTE_READWRITE, &OldProtect); *(BYTE*)Proc = 0xE9; *(DWORD*)((char*)Proc + 1) = (BYTE*)Hook_func - (BYTE*)Proc - 5; VirtualProtect(Proc, len, OldProtect, &OldProtect); } BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) { DisableThreadLibraryCalls(GetModuleHandleA("inject_unpackme03.dll")); Resume_GetVersionExA = (BOOL(__stdcall *)(LPOSVERSIONINFO))VirtualAlloc(0, 0x1000, MEM_COMMIT, PAGE_EXECUTE_READWRITE); memset(Resume_GetVersionExA, 0x90, 0x1000); setup_hook("kernel32.dll", "GetVersionExA", &Hook_GetVersionExA, Resume_GetVersionExA); return (1); }My code use the Length Disassembly Engine from BeatriX.
Now we code a little injector in masm for changing :
.386 .model flat,stdcall option casemap:none include \masm32\include\windows.inc include \masm32\include\kernel32.inc includelib \masm32\lib\kernel32.lib .data PInfo PROCESS_INFORMATION <> SInfo STARTUPINFOA <> Kernel db "kernel32.dll", 0 LLib db "LoadLibraryA", 0 exe_name db "03_unpackme.exe", 0 dll_name db "inject_unpackme03.dll", 0 Addr_name dd 0 .code start: invoke GetStartupInfo, addr SInfo invoke CreateProcess, addr exe_name, NULL, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, addr SInfo, addr PInfo invoke VirtualAllocEx, PInfo.hProcess, 0, 100h, MEM_COMMIT, PAGE_READWRITE mov [Addr_name], eax invoke WriteProcessMemory, PInfo.hProcess, Addr_name, addr dll_name, LENGTHOF dll_name, NULL invoke GetModuleHandleA, addr Kernel invoke GetProcAddress, eax, addr LLib invoke CreateRemoteThread, PInfo.hProcess, NULL, 0, eax, [Addr_name], 0, NULL invoke WaitForSingleObject, eax, INFINITE invoke ResumeThread, PInfo.hThread exit: invoke ExitProcess, 0 end start
So as you can see, I used a little trick for waiting unpacking of all executables :
I setup an hook on GetVersionExA() and if the call occurs from one interesting address (near OEP), I call fix "fix_call" function and enter in infinite loop.
With this infinite loop we can attach Olly to our process and watch the result :
It's cool, but wait i forgot to talk about one thing, finding real OEP !
Restart OllyDBG, let the loop xor all the first stage, and setup breakpoint on :
0041196F E8 C2010000 CALL 03_unpac.00411B36
Step into and add breakpoint on :
00411B61 FF95 4B1D4000 CALL DWORD PTR SS:[EBP+401D4B]
You should land here (Addr can change due to allocated memory) :
00157C44 ^\FFA5 BB1F4000 JMP DWORD PTR SS:[EBP+401FBB]
Trace the code until you got something like that :
00153BC4 9D POPFD
00153BC5 61 POPAD
00153BC6 5A POP EDX
00153BC7 58 POP EAX
00153BC8 E8 D35F0000 CALL 00159BA0
If we step into, we will find something very interesting :
00159BA0 60 PUSHAD
00159BA1 E8 00000000 CALL 00159BA6
00159BA6 5D POP EBP
00159BA7 81ED E21B4000 SUB EBP,401BE2
00159BAD 8B7424 20 MOV ESI,DWORD PTR SS:[ESP+20]
00159BB1 83EE 05 SUB ESI,5
00159BB4 8B9D 111C4000 MOV EBX,DWORD PTR SS:[EBP+401C11]
00159BBA 83EB 28 SUB EBX,28
00159BBD 83C3 28 ADD EBX,28
00159BC0 3973 10 CMP DWORD PTR DS:[EBX+10],ESI
00159BC3 ^ 75 F8 JNZ SHORT 00159BBD
00159BC5 8B73 08 MOV ESI,DWORD PTR DS:[EBX+8]
00159BC8 89B5 0C1C4000 MOV DWORD PTR SS:[EBP+401C0C],ESI
00159BCE 61 POPAD
00159BCF 68 DEC0ADDE PUSH DEADC0DE
00159BD4 C3 RET
This not api resolution, but call resolution !This sub is quite simple, like api resolution it will check into a table the offset of the call and replace 0xDEADCODE by the addr of the (stolen ?) call.
I think (it's not sure) the packer has stolen some call from the virgin file and reconstruct them with a push addr ret.
Let's put a conditional log on ret address ( Expression = "[esp]" ).
We run the program and exit him and watch the log.
00159BD4 COND: 004085D4
00159BD4 COND: 00402128
00159BD4 COND: 004014C4
00159BD4 COND: 0040212C
00159BD4 COND: 00402D44
00159BD4 COND: 004085D4
00159BD4 COND: 00403D20
00159BD4 COND: 00403FA4
00159BD4 COND: 00403394
00159BD4 COND: 004033A4
00159BD4 COND: 00402F2C
00159BD4 COND: 004085B6
00159BD4 COND: 004085AA
00159BD4 COND: 00405BD4
00159BD4 COND: 00405C18
00159BD4 COND: 004066AC
00159BD4 COND: 004066B4
00159BD4 COND: 00406978
00159BD4 COND: 004085D4
7E390000 Module C:\WINDOWS\system32\USER32.DLL
00159BD4 COND: 00405B84
77EF0000 Module C:\WINDOWS\system32\GDI32.dll
Process terminated, exit code 0
If you remember at the begining of the article, the second breakpoint on access on code section land us to the first entry of your log, is it OEP ?I don't think so, it's a call to GetModuleHandleA(), ... strange, ... strange.
If you look closely, there is another thing strange, before the log of the loading module "USER32.dll", we can see a call to 0x004085D4, but this call is just a redirection to GetModuleHandleA, so what's happen between ?
We will restart our debugger and put a breakpoint on the ret of the call redirection function and wait until it go to the last 0x004085D4.
We trace the code, call "api address solving", we put a breakpoint on the JMP EAX, trace into GetModuleHandleA(), and execute till return.
We are back into virtual memory code, and trace it until get :
00154119 9D POPFD
0015411A 61 POPAD
0015411B 5A POP EDX
0015411C 58 POP EAX
0015411D FF56 18 CALL DWORD PTR DS:[ESI+18]
[ESI + 18] will be equal to 0x00401000, is it the real OEP ?
00401000 55 PUSH EBP
00401001 8BEC MOV EBP,ESP
00401003 6A 00 PUSH 0
00401005 68 20104000 PUSH 03_unpac.00401020
0040100A 6A 00 PUSH 0
0040100C 68 E7030000 PUSH 3E7
00401011 8B45 08 MOV EAX,DWORD PTR SS:[EBP+8]
00401014 50 PUSH EAX
00401015 E8 56760000 CALL 03_unpac.00408670
0040101A 33C0 XOR EAX,EAX
0040101C 5D POP EBP
0040101D C2 1000 RET 10
CALL 03_unpac.00408670 will go to resolve api, and call DialogBoxParamA().But wait we store first argument into eax, so this function need an argument.
If we look msdn documentation first parameter of DialogBoxParamA() is a handle to the module whose executable file contains the dialog box template.
So the parameter of this function should be the result of GetModuleHandleA(NULL) (this will be first stolen fix).
A second problem is when we will return from DialogBoxParamA, and return from sub_00401000 we should ret to a fonction wich call ExitProcess().
Launch the injector, and attach olly to the process, and search reference to kernel32.ExitProcess, and we found this sub :
0040669C 55 PUSH EBP
0040669D 8BEC MOV EBP,ESP
0040669F 8B45 08 MOV EAX,DWORD PTR SS:[EBP+8]
004066A2 50 PUSH EAX
004066A3 E8 F01E0000 CALL 03_unpac.00408598 ; JMP to kernel32.ExitProcess
004066A8 5D POP EBP
004066A9 C3 RET
Now we just have to find some place for putting the stolen bytes, just after all the jmp dword ptr [idata_section] it's cool.
- Add a call to GetmoduleHandleA(NULL) for getting base adresse required by DialogBoxParamA
- Push Addr of ExitProcess()'s sub
- Push Real OEP
- Ret to it
Now we can dump our process with our favorite toolz dumper, and fix iat with ImportRec and putting the new OEP.
We test the dump file and it works :].
Conclusion
As deroko said, this unpackme is really not difficult, but I enjoyed solving it.