Unpack Vmprotect
Juvencio Parise
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.
The target is an old software (from 2010) coded in c++, I just apply the VMP protection without any special code as I show in the two screenshots. All available protection features in VMProtect were used with this unpackme. Refer to the attached images for the specific protection settings used.
Lack of any explanation whatsoever, likely the author just ripped code directly from the source of the original program; which they clearly have access to given the details of the post. For those of you seeking guidance, I'd look elsewhere (old but gold).
Setting TMP folder to a RAM drive was a good idea in 1990s. Now it's year 2019 and you can't manage virtual memory better than Windows already do. But some people apparently still try, so I added checks to stop them from shooting themselves in the foot.
actual htlauncher.exe
ClientLib.dll - contains ZIP with more files
gameguard.dll - probably some sort of anticheat
nvidiar.exe - some sort of anticheat? Very suspicious file.
And inside the ZIP file there are:
0.56 doesn't work with Wine anymore (4.0/4.9). It's possible to run unpacked software in native NW.js, so I use it for that. My /tmp is tmpfs as well, but that's not the problem here. Would be great if you could fix it, thank you.
Could you provide me with more details about your system and how you run the unpacker? df -l and wine output during the execution + screenshots from winecfg would be a good start. Otherwise there is not much I can do - it works for me.
Sorry, my whole system (most of it) might be currently located in RAM, so that can possibly be the reason. This is the first time there is such a problem, I'm not sure what to think about it. Should I mention that previous version works perfectly fine?
[+] Filename: C:\shit\Peasants Quest NYD191.exe
[x] There is not enough space in working directory. Unpacking would most likely fail!
[+] Filename: C:\shit\Peasants Quest NYD191.exe
[x] There is not enough space in working directory. Unpacking would most likely fail!
i unpacked enigma but failed, help me extract it all with, thank you
file: hidden link
[+] Embedded files are compressed
[?] LoaderSize = 0. Probably old unsupported EnigmaVB version.
[!] Unknown EnigmaVB version, cannot guarantee that unpacking will work properly!
[!] unknown virtual file type 0
[!] unknown virtual file type 0
I tried extracting according to the video's instructions but my file has anti-debug feature, I use strongod to bypass the anti-debug feature but it's useless for my file :(, I treaty you create the tool Extract as molebox
Sorry for raising a question which is not so related to the unpacker.
Recently I unpacked some Molebox-VS-packed application, but the unpacked executable seem to be 16-bit and the Windows system refused to run it (but it is not corrupted, for it can be run in wine, or maybe some old versions of Windows).
So in fact I am wondering why it can run inside molebox. Does molebox somehow modify the PE header or something? And I'm also wondering what can I do to make it run.
Again, sorry for bothering.
Sorry for such a late reply... course assignments and the graduation project kill me...
I have uploaded the whole archive on mediafire, and what I am trying to unpack is malie_chs.exe inside that archive. I am doing this because ESET (or maybe other virus scanners would also do this) keeps complaining about the MoleboxVS packed file, and it also keeps deleting some games I am to play.
But in fact I don't think the unpacked executable is corrupted. As far as I can see, it may be caused by some non-standard way MoleboxVS use to create the process.
File link here: hidden link
[+] Filename: M:\cracking\New folder (4)\Jazz Digit By kashif bharwan.exe
[+] MD5: 47f755ddbf231efbc4a49a8e85c6e598
[+] x86 executable
[x] Looks like this file is protected with Enigma Protector, not Enigma Virtual Box.
[x] It is not supported by my unpacker
Researchers analyzed six malware families that are using the protectors Themida and VMProtect. None of the samples used code virtualization, significantly simplifying the analysis, as only one sample had anti-debugging enabled.
The malware code itself was largely unprotected, except for the initial stages of compression and decryption. While almost all samples had encrypted/obfuscated strings, only two obfuscated their C2 servers.
c80f0f1006