How To Unpack VMProtect Malware - Part 2
Added 2022-01-25 21:02:13 +0000 UTCDebugging and Dumping
This is part two in our three-part tutorial series on unpacking VMProtect malware. We are attempting to unpack a sample that has been packed with VMprotect where the entry point has been virtualized but all other functions are not protected.
Unpacking Concept
The concept behind our approach is to use a sandbox to identify an API that is called by the malware payload (not the VMprotect code). Then use that API call as a "flag" to indicate that the payload is unpacked in our debugger. Once the payload is unpacked we can use a custom dumping tool like VMPDump to dump out the unpacked payload. The custom dumping tool is required because VMProtect uses obfuscation to protect API calls in the payload.
If the sample is an MSVC binary the entry point will contain boilerplate code that is common to all MSVC binaries. Because this code is common we can search in memory for the Security Cookie Constant and identify the entry point. This allows us to set a breakpoint on the entry point and obtain a cleaner dump of the sample. If this is not an MSVC binary we cannot use this trick.
Tools
- Sandbox with API tracing capabilities -- we recommend CAPE
- Malware analysis environment with x64dbg -- we recommend FLARE-VM
- VMProtect dumping tool -- for VMProtect 3 64-bit we recommend VMPDump
Unpacking Steps
- Run the sample in a sandbox that has API tracing enabled. We prefer to use CAPE but any sandbox that provides a view of the APIs called by the sample will work.
- Examine the API trace to identify an API call that is made by the malware payload (not by the VMProtect code). Usually this is easy to identify as the behaviour of the malware is closely linked to the APIs it calls. For example, ransomware usually calls CreateFileW to obtain a handle to the files that it is encrypting.
- Launch the sample in x64dbg and set the hardware breakpoint on the API you have identified with the sandbox.
- Once the breakpoint is triggered use x64dbg to observe the code that called the API. Is the code in the .text section of the binary? Does the code look readable?
** If the code is in the .text section and appears readable (not virtualized) then this is a good candidate for our dumping method! - Optional for MSVC binaries only!
- Search in memory for the Security Cookie Constant
- If the constant exists use this to identify the __security_init_cookie function and set a hardware breakpoint
- Remove the API breakpoint and re-launch the payload
- When the __security_init_cookiet breakpoint is reached this is your new dump point - Dump the process using VMPDump.
Anti-Debug and Anti-VM Protections
If the anti-debug and anti-vm protections are enabled in VMProtect you will need to take additional steps to hide your VM and your debugger from the sample. These steps are outside the scope of this tutorial but but simple anti-anti-debug features we recommend installing ScyllaHide.
Other Versions of VMProtect
Our tutorial is focused on VMProtect 3 with 64-bit samples but there are many older versions of VMProtect in use by malware developers as well as many 32-bit payloads. The following dumping tools may of useful depending on the version you encounter.
