In this blog, I will discussed some of the technique that can be used when we encountere with the corrupted PE or IAT obfuscated samples.
1. Obfuscated IAT
Sample: Mugatu.exe (FlareOn 2019 Chal 10, writeup pdf)
As state in the writeup given, the original import thunks has been reversed in the memory. In order to beat this kind of obfuscation, we can use Scylla to dump out the executable after the import address table has been fixed. Once the IAT has been fixed, the API will be resolved 😎 and appears again in the static decompiler tools.
You may refer to the screenshot below for the guidance. ✌
It can see that the decompiled code after the deobfuscation function makes more sense than before. 😃
Afterwards, it will need to rebuilt the IAT to get the second payload (In this case PE-Sieve will comes in handy). Will leave this to the those are interested.
2. PE Unpacking
Sample: Refer to [Mal Series #7]
For the payload unpacking, I will mention on the common one that I used often, which is placing breakpoint on the common Windows API to let it unpack itself. Here comes the famous guys 🎉VirtualAlloc, VirtualAllocEx, WriteProcessMemory, VirtualProtect🎉
Other than that, there are a lot of unpacking method for different packers such as UPX (Finding the far jump to the entry point of the code) etc.
3. Corrupted/Misaligned PE
Sample: Refer to [Mal Series #7]
When Windows loads a PE file, it will try to map the address of the physical address to memory address.
Mapping (Translate from physical address from disk to virtual address, usually refer to memory address).
When we dump the payload out of the memory, it might require to unmap the dumped files so it can interpret by the static analysis tools correctly. Usually just to make the sections can be continuously read by the tools by merging those padded section into one. E.g:
Raw Data Size of a section 1 = VA Section 2 - VA Section 1
In order to do that, we will use PE-Bearto fix the alignment of the PE section headers. Make sure Raw Address align with Virtual Address in this case after aplied the calculation above for each section.
Repeat this for the rest of the sections and you will see something afterwards.
For .reloc section, we leave it to zero as we are now unmapping the PE from the memory and make the unmapped (Memory) address align to mapped (Raw) address. Based on my 💡 understanding 💡 is that the function address has been once adjusted when the file is loaded from disk into memory, so there is nothing much useful for static tool analysis unless there is a need to dynamically run the sample again 🤔?
Some good reading for .reloc here.
For more details, you may refer to the youtube video 🎬 from OALabs x MalwareAnalysisForHedgehogs below.
🤩Highly recommend these channel for PE Unpacking and Malware Stuffs🤩
4. [Extra] Transplanting PE header
❗ This is a interesting read for us to understand more on recontructing PE headers of the headerless PE payload for SmokeLoader sample. It is quite fun if you start to get your hands dirty from the beginning as you will faced a lot of anti debugging trick and a RX mapped payload in the remote process. Besides, it also intrduce the LIEF tools to construct the PE file programatically.
