This is quick walkthrough for MalwareTech’s challange shellcode 2. It is quite similar to shellcode 1 but gets a little deep.
Problem Statement :
shellcode2.exe contains a flag stored within the executable. When run, the program will output an MD5 hash of the flag but not the original. Can you extract the flag?
You can download the shellcode2.exe from MalwareTech’s site. The password to the zip file is MalwareTech.
Let’s begin our analysis.
First we see a lot of memory being reserved and is assigned with the values 12h, 24h, 28h, …., 6Fh. Moving forward,
Then we see a call to GetProcessHeap which returns the handle to the process heap which is then passed as a parameter to HeapAlloc. Then the pointer to the allocated memory is stored to [ebp+var_4]. It then moves LoadLibraryA, GetProcAddress, var_28 (i.e. 12h, 24h, 28h, …., 6Fh), and 24h( i.e 36) to the heap. I just noticed that there are 36 values assigned to var_28 as well 😉 . Now similar to shellcode 1 there is a call to VirtualAlloc with parameters(0,248h,1000h,40h). The base address of allocated region is then moved to [ebp-0C0h]. Now our favourite part where the flag is loaded to the Dst by making a call to memcpy. It’s same as shellcode 1; for basics you can refer to shellcode 1 here. Now lets follow the src by double clicking the Offset loc_404040.
We see it moves one character at a time and the characters are in hexadecimal. You can select each character and press R in your keyboard to get ASCII equivalent of the hex. We find the hidden strings are msvcrt.dll, kernel32.dll, fopen, fread, fseek, fclose, GetModuleFileNameA and rb. This is a technique used by malwares to hide strings and bypass the detection. Cool isn’t it? Now lets see how these strings are processed further to get us our flag 😉 .
I have commented the code since I don’t wanna confuse you all so lets understand what is happening step by step 🙂 .
Till now the code imported all the required dll’s and API’s now next part we can guess would be file operations 😉
Now we know it is opening the same binary file to read 38 bytes starting from 78th position. Let’s use a hex editor to find what is being read into the buffer.
The DOS-header! “This program cannot be run in DOS mode” is being read. Okay lets look forward,
With those 38 bytes from DOS-header in buffer, the program then loads 36 in ecx i.e mov ecx, [edx+0Ch], then moves the 36 bytes from var_28 to edi. Then there is a iterative code that XOR’s the bytes in buffer with the bytes in var_28.
Now lets make a note of all the bytes and XOR them using a simple C program and see what we get 😉
You can find the C Program here. Executing it we get,