![Helping Non-Security Stakeholders Understand ATT&CK in 10 Minutes or Less [VIDEO]](https://assets.crowdstrike.com/is/image/crowdstrikeinc/video-ATTCK2-1)
![Qatar’s Commercial Bank Chooses CrowdStrike Falcon®: A Partnership Based on Trust [VIDEO]](https://assets.crowdstrike.com/is/image/crowdstrikeinc/Edward-Gonam-Qatar-Blog2-1)
![Endpoint Protection and Threat Intelligence: The Way Forward [VIDEO]](https://assets.crowdstrike.com/is/image/crowdstrikeinc/GK-Blog_Images-1)
Background
Today, most malware is obfuscated to make it more difficult for traditional antivirus engines to detect the malicious code and to make it more arduous for analysts to understand the malware's functionality. Although many automated tools exist for deobfuscating (or "unpacking") malware, they have their limitations and analysts often need to manually unpack malware. Analysts typically follow three steps when unpacking malware:
- Trace to the malware's Original Entry Point (OEP)
- Dump the process's memory
- Reconstruct the Import Table
However, analysts' tools for dumping memory and reconstructing a module's Import Table are only designed to work when the unpacked code is written to an existing PE section in memory. In rare cases where an unpacking stub writes the unpacked content to a dynamically allocated region of memory (especially when that region is before the module's Base Address), common memory dumping and Import Table reconstruction tools fail.
This blog post discusses a method to fully unpack a malware sample whose unpacking stub writes the unpacked code and Import Address Table to dynamically allocated memory.
Problem
For this blog post, we'll be working with a file with MD5 hash65EE9D8CB2ACB1F95CDA5F66F4591918; it's a rogue antivirus program packed with ASProtect. Although tracing to the OEP for this sample is out of the scope of this blog post, suffice it to say that on a given run of this sample, the OEP was found to be at Virtual Address 0x011B1038. However, this OEP address is below the executable module's base address of
0x03000000:
will leave the original DOS header and PE header in-place at the beginning of the unpacked code's
dynamically allocated
memory region, ASProtect does not persist this information; as such, we cannot simply dump just the OEP's memory region to create a working executable. How then can we dump this process's unpacked memory to create a valid executable?
Solution
As mentioned above, most unpacking tools expect the code to be unpacked into an existing PE section. Therefore, we'd ideally like to "trick" the unpacking stub to unpack the malware's code into an existing PE section instead of into dynamically allocated memory. Let's start by creating such a section in the malware's executable. We can use a tool such as LordPE to create the new section. We begin by opening a copy of the file in LordPE's PE Editor:
0x0005A000
bytes:
0x1170000) with VMMap, we can see that its Type is "Private Data":
0x0005A000
bytes. We can thus run the new version of our target with the added section in a debugger, set a breakpoint on VirtualAlloc(...), and wait for it to be called with a requested size of
0x0005A000
bytes. If we set a logging breakpoint on VirtualAlloc(...), we see it called twice with a size of
0x0005A000
bytes:
If we track the returned value from these two VirtualAlloc(...) calls, we see that the malware's code is unpacked into the memory allocated by the second call to VirtualAlloc(...).
We now restart the process, set a breakpoint on VirtualAlloc(...), and the second time it's called with an allocation size of 0x0005A000 bytes we change the return value in EAX to actually point to the Virtual Address of our new section:
This causes the unpacking stub to treat our new section as the 0x0005A000
We can now analyze the unpacked file.
bytes that would have been returned by VirtualAlloc(...), causing the unpacking stub to unpack the malware's code into our new section instead of a dynamically allocated region of memory. We can now trace to the OEP, successfully dump the memory, and reconstruct the Import Table:
Conclusion
This blog post demonstrates that reverse engineering is not just a reliance on tools. A professional reverse engineer requires knowledge of the hardware, the underlying operating system, and a good deal of creativity in order to solve challenging problems. No matter what the bad guys do to make our work more difficult, we will alwayspersevere, outsmart them, and in the end, use our skills to bring pain to the adversary. Want to make reverse engineering easier? Try CrowdRE!
