Vmprotect 3 Unpacker

[Claribel Szwaja]

fixedin v1.7 -/releases/v1.7 (make sure your commandline arguments are also correct)... Also be aware that vmemu currently does NOT support dumped modules as it uses LoadLibraryExA - DONT_RESOLVE_DLL_REFERENCES to load the module...

The unpacker does not recover the original entry point, its simply just a way for me to statically decrypt/unpack all sections in a standardized way so that you can run VMEmu upon the module. I fix sections (set raw ptr/size equal to virtual rva/virtual size) and append relocation blocks and relocation entries for relocations not declared in the relocation directory. A "dump" is pretty subjective term so the need for this auto unpacker/dumper was clear.

I also recoded VMEmu entirely ( -/blob/3c08edac2c4c452f0c50080eb0d801331f7ce4f6/src/vmemu_t.cpp) as the older code was very incorrect. Such things as the virtual JMP instruction can change virtual machine handler tables if the binary has more than a single virtual machine. This caused crashing. This is fixed now. Here is an example of what im talking about though:

Im now preparing to lift to llvm-ir and I have removed VTIL as I dont see a clear path forward using VTIL to get back to native x86_64. I am making steps to do entire module devirtualization and not just a single virtual routine. Ive written the code/algos to locate all virtual machine handler tables and all vm enters. You can find them here:

I have added a new flag "--locateconst" which will first locate every single vm enter and then run vmemu upon it to statically decrypt all virtual instructions. It will then loop over the virtual instruction code blocks for each virtual instruction and try and find any virtual instructions with an operand that matches the constant value you specified. This is really useful for locating math primes/relative virtual addresses and such... great for attacking.

Lastly, I rewrote the deadstore removal algo so that it produces much cleaner output. This algo will only work on vm arch related code such as vm handlers/vm_entry/calc_jmp as these are all linear and dont have any real JCC's.

vmdevirt lifts vmp IL generated by vmemu to llvm ir which can then be optimized and compiled back to native instructions. I have released a pretty rough/early version of EasyAntiCheat devirtualized here: -cheat-bypass/468099-easyanticheat-sys-devirtualized-version-1-optimizations.html

What is the best way to unpack PE files? I've seen some tools from 7 years ago, like Quick Unpack. Is there anything more recent? Or is it better to run different tools for different packers since individual unpackers are likely more up-to-date?

There is Pe-sieve & mal_unpack from hasherezade, mal_unpack can work in an automated fashion. Mal_unpack is basically just an automated version of Pe-sieve. Pe-bear is another tool from hasherezade which helps you re-align sections after doing a dump, which requires that you know how to unpack manually but it make the process much easier.

Successful malware distributors are not using public crypters as often, heuristics for detecting public packers is too easy, which is why we have seen a reduction in AIO unpacker tools. In addition, Themida and VMProtect are the standard now and as they continue to add more features, they're becoming more difficult to unpack everyday. With the new virtualization features, automated unpacking is becoming almost impossible.

Even though Quick Unpack is old, I would not underestimate its power in present days. As long as you find the best setup, this tool will produce launchable dumps of Exes/Dlls packed by dozens of known packers + even unknown ones!

This concerns packers in their classical definition.If you are looking for some "generic unpacker" for modern protectors (such as VMProtect, Themida, Enigma, Obsidium, etc.), then I do not think they will ever be made. There are some specific tools (both private and public) which can help you to automate "unpacking" partially, but the majority of work still needs to be done by hands to remove these kinds of protectors. But again, it depends on what you want to see in the end (analysable code, de-obfuscated dump, fully launchable reconstruct, ...).

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

3a8082e126