How To Unpack Vmprotect
Nathen Paisley
This is my exploration around VMProtect security. VMP is a well known protection with a lot of features, main ones are Code Mutation and Virtualization, and compared to them, this part is the simplest regarding VMP. I will talk about all of those in future posts, but now I will focuse myself on the Packing and the Import Obfuscation.
Note that the entrypoint looks like a VMProtect virtualized routine, and in fact, it is ! In the past (version 2.x), VMP unpacking routine were not virtualized (like in this video), so it was easy to rush and breakpoint the jump to OEP (push and ret).
Since the TLS and DllEntryPoint come before ServiceMain being called they must unpack the malicious code and fill the memory with the exported functions. This represents a big advantage from the start because we could have a case where the whole ServiceMain stub contained the VM code which would make things way harder. So this implies we must run TLS and DllEntryPoint (optionally) first.
Why are these good? Because with virtualised packers, there is a lot of code that has hardly any meaning but it is responsible for logistics (e.g. pushing arguments on stack, preparing API calls, etc). Going through that code is painful and time-consuming even though it is quite simple to catch the pattern of calls at a certain point. The first line above allowed me to spot anti-debug calls like: IsDebuggerPresent, CheckRemoteDebugger and NtSetInformationThread (ThreadHideFromDebugger).
However, at a certain point i let the first line above run for hours and no more API calls where seen. While i cannot tell with certainty why this happened i can assume that it may have been some anti-debugging technique that did not involve any API calls (e.g. the infamous fs:30 BeingDebugged flag) or it could just be VM activity unpacking the malicious code (single stepping into very complex routines is far from fast).
As mentioned before, the sample subject to analysis here is meant to be run as a service. At around the time of writing this blog post i wrote another blog post on how to debug Windows services using Windbg. When i tried to implement the simple trick i am about to describe in the context of svchost rather than rundll i was unable to debug the service or even reach ServiceMain in a clear and repeatable way. I faced problems such as:
So we know that TLS callback is being called as a consequence of a call to LoadLibraryExW. We also know that ServiceMain should not be called by LoadLibraryExW because ServiceMain is not present on all DLLs. That should be the function of svchost.exe or some other mytical creature. The combination of TLS and DllEntrypoint should leave the ServiceMain and other exports ready for use or at least they should have some instructions so that the service runs properly. Also, DllEntrypoint on services must call functions like RegisterServiceCtrlHandler and SetServiceStatus. Per the following Microsoft doc:
Now, the temptation here is to set a BP on the return from LoadLibraryExW or on one of the Service initialization functions from Windows API. However, VMProtect anti-debug mechanisms will screw the plan. So here is the proposed approach:
Both Themida and VMProtect are commercial packers and are most commonly used to pack games and other commercial software. UnpacMe can unpack some versions of VMProtect and Themida but there are many limitations.
This is the first part in our three-part tutorial series on unpacking VMProtect malware. When approaching a VMProtect malware sample it is important to understand the concept of a packer vs. a virtualizer. VMProtect offers both the option to pack files, and the option to virtualize individual functions. Depending on what options are selected by the malware developer it may be possible to trivially recover the protected payload.
The VMProtect packing functionality simply protects that payload at rest. When the packed sample is executed the payload is unpacked into memory and executed. The concept behind this is similar to other, more well understood, packers like UPX -- though with some added protections that make unpacking more difficult.
The VMProtect virtualization protection is applied at the function level within the payload and transforms the function code into a series of virtual instructions that can only be interpreted by the VMProtect virtual machine. To attack this protection the virtualized instructions must be devirtualized using custom translation software like the suite of tools build around VTIL including a fully working VMProtect 3 devirtualizer: NoVmp.
Though we won't attempt to remove VMProtect virtualization there are two common mistakes that malware developers continuously make which may allow us to recover the full malware payload, even when virtualization has been "enabled".
Some malware developers lack a fundamental understanding of how VMProtect works and only use the packing functionality of VMProtect. This leaves all of the functions unprotected and allows us to simply dump the payload at runtime.
Other malware developers may attempt to protect their payload using VMProtect virtualization but misunderstand the VMProtect interface and succeed in only virtualizing their entry point. This leaves the rest of the functions unprotected and is the most common mistake we have observed when analyzing VMProtect malware samples.
We cannot redistribute VMProtect or samples protected with the VMProtect Demo but you can re-create our lab examples in your own analysis environment. Attached to this post is the HelloWorld binary from our examples. A free demo version of VMProtect can be downloaded from the VMProtect website.
This is a slightly unrelated question to the topic per-say, but where did you make this program? like what IDE? what UI Library, if C++, Qt? ATL? MFC? The overall layout and programming looks strikingly similar to this one.
The one in your picture is a game emulator by a team that has vanished long time ago using stolen code from a company called WebZen, while the one I made is completely empty written from scratch and does only what`s posted.
Also I didn't put to much effort on getting to the strings, everything is in plain text or at least that's how I see them, if there was supposed to be encrypted strings, then maybe there was a bug in the protection or you missed an option or something, I don't really know, now apart from that, strings are decrypted in memory, I'm myself a noob with VMProtect and all these high-end protectors, so I just tend to look for the objective the shortest way possible, I simply unhooked all Ring3 hooks, and left the executable with all the original calls intact, proceeded to inject and hide my debugger from VMProtect using ScyllaHide, apparently once I got inside, strings were decrypted.
Fully, fully, I cannot unpack it, I just can get to debug the program without the anti-debugger catching me that's all I know, but for unpacking purposes I now nothing, don't even know how to get to the OEP D:
Bits and pieces:
- resource protection is not difficult to beat, but it's hella annoying
- I have patched away some of the checks with some simple mov al, xx etc.
- VMP's sections have been removed, but not ALL the code has been recovered because I was running short on time, only the portions executed when the program is working normally. If it crashes it's probably because it's detecting something on your PC
- yep, strings are in clear. I think there is something you have to enable in VMP's interface (adding them to the protected objects or something?) for it to work
It has been tested locally by restarting the PC. Win7 x64, all seems fine. Please report back if you have some spare time to check if it works for you too.
Because of a quirk in the unpacking process (more specifically, the IAT fixing) it will only work on Win7 (and upward? And maybe Vista?) because WinXP lacks a couple of the DLLs needed. It can be fixed, buuuut... time.