4

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

  • 2
    OK, so this malware is protected with the VMProtect (v3.0.465) with even a valid taggant.Since VMP is a commercial protector,would like the admins to comment whether it would violate the rules of this site if I discuss in detail the steps of finding the OEP and re-building the IAT, as asked by the OP. I would hate to spend a couple of hours writing an answer only to have it deleted, as I see happening quite frequently these days (sorry). Waiting for a confirmation to go ahead. Thanks. – TechLord Mar 8 '18 at 21:45
  • waiting fingers crossed... – rustam Shirinov Mar 8 '18 at 22:22
5
+50

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

2

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.

  • I updated my question with the sha256hash of the sample – rustam Shirinov Mar 8 '18 at 10:33
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.

  • Heey I read your articles about reversing FinFisher after I asked the question. After reading them I realized it was not as easy as putting a breakpoint on an API call. I learned a lot from them. Now I am trying to find the Vm exit instruction. It is not easy to do if you are dealing with VMProtect at least for me – rustam Shirinov Mar 12 '18 at 23:15
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.