Finding OEP in a VMProtect v3.0 protected malware

Question

I've been trying to reverse engineer a malware that has been packed with VMProtect v3.0. My first instinct was to google an automated way for this and I found a script. Unfortunately the script to unpack VMProtect protected binary does not work with version 3.0.

So far I've seen that the packer changes the access rights of the sections to be writable, decrypts the original code and writes the code to the sections then changes the access rights for those sections back to their initial values. I saw that by putting breakpoint on the VirtualProtect API. After the final call to VirtualProtect I put the access breakpoint on the sections that had executable right and when my breakpoint was hit I expected it to be the OEP but when I dumped the process it did not run.

From my research I understand that you need to rebuild the IAT and tools like UIF & Scylla won't be any help. Can you give me some tips on how to find the OEP or how to deal with this kind of packing mechanism in general?

P.S. This is the first time I am dealing with VMProtect protected malware.

UPDATE

Sha256 Hash: 8200755cbedd6f15eecd8207eba534709a01957b172d7a051b9cc4769ddbf233

Answer 1

Here are a few links that address your question in a broad manner:

• VMAttack: Deobfuscating Virtualization-Based Packed Binaries
  Link to PDF Paper which uses the VMAttack IDA PRO Plugin.
  

• Unpacking Virtualization Obfuscators by Rolf Rolles.

• Unpacking the FinSpy VM, parts #1, #2, #3

• Various other articles by Rolf Rolles .

Answer 2

Set a breakpoint on the "VM exit" instruction (though there may be more than one of these if the sample is using the multiple VM option, whose proper name I don't recall). From here you can see where the VM transfers control when it exits. It will exit several times during "packer" mode. Eventually it will exit to OEP.

Answer 3

Since you say it's malware please provide either the SHA256/MD5 hash or a Virustotal/Hybrid-analysis link of the target so that I can take a quick look at it.

VMP and its protection mechanisms differ wildly in terms of complexity and characteristics between versions and even builds, in some cases.

For example, many techniques of finding the OEP and rebuilding the IAT which are successful for targets packed with VMP v2.xx fail miserably when attempted on targets packed with VMP v3.xx.

As such its impossible to characterize and give a detailed canonical answer that would address all concerns and cover all versions of VMP.

What I guess can be done is that if you give us the links/hashes of the malware, I would be able to take a look at it and then discuss the answer in the context of that version VMProtect used to pack the malware.

Note: :Since VMProtect is a commercial protector, I understand would be appropriate to discuss it only in the context of reversing the malware that was protected with it, to avoid this question being closed off as being off-topic or too broad..

Hence I guess that unless you can give us more details of the target you are attempting to reverse, we cannot proceed further.

Answer 4

Note: I never unpacked VMProtect myself.

From looking at a sample unpackme, all intermodular calls that normally pointed to the IAT, are replaced with direct calls to what I think are obfuscated redirections inside the VMProtect's section that eventually lead to code inside .dlls. It's possible the executable will function if dumped correctly without rebuilding the import table, but it won't work after a reboot when .dll addresses change. Easy but unreliable ways of knowing which redirection leads to which imported function I can think of are by tracing or setting execution breakpoints on imported .dlls and calling the redirections. You can also dig deep into the import resolution mechanism of VMProtect.

Some protections virtualize the entire entrypoint function but I don't know if VMP has that as a feature. This means setting a page guard on the executable section won't break on the OEP - it's going to break on the first non-virtualized function called by the OEP function. The virtualized OEP function executes inside the protector's section. So if the OEP is virtualized what I'd try doing is finding the VM entry for that function (in VMProtect it's a push + call pattern) and setting the entrypoint to that when dumping. You can also paste the entrypoint function from another unprotected executable - for example if you have an earlier unprotected build of this malware compiled in the same environment in which case it's possible you even can borrow the imports.