I recently found a nice crackme which uses VMProtect 3.x as defense. After doing a little research online I found couple of API's VMProtect uses as an anti debug method.

I set software breakpoint on those functions but unfortunately I somehow don't hit them. I'm 100% sure the APIs are getting called during the the running of the program.

The APIs including (CheckRemoteDebuggerPresent, IsDebuggerPresent, etc...).

If someone knows what is the reason to that or what evasion method VMProtect uses I would be more then happy if they could share it.

  • 2
    It would be more useful if you can attach the executable, and specified exactly where you put the breakpoints. – user202729 Dec 10 '18 at 10:55
  • it's possible that VMProtect knows what the function prologues should look like and skips a few instructions before calling into the function. You could try placing the breakpoint somewhere inside the function instead. – peter ferrie Dec 14 '18 at 15:52

VMProtect uses a few anti-debug techniques. Firstly, you aren't going to want to tackle them on your own because there is quite and exhaustive set of techniques to detect a debugger. Consider using an anti-anti-debug plugin (ScyllaHide)

One you are probably going to encounter that is difficult to work around is the rdtsc instruction.

rdtsc essentially allows the application to measure time that has elapsed in-between a series of instructions executing. The stepping behavior of a debugger will make this period of time large and thus trigger a detection that a debugger is present via some application logic. With heavy code obfuscation there is no way you can manually work around these. You will need to use find some automated approach (however, since rdtsc is not a privileged instruction getting around this can be a huge pain.)

The best approach here is probably write a custom Intel PIN tool to modify the CPU state as the instruction is used (see https://github.com/jingpu/pintools/blob/master/source/tools/InstLib/time_warp.H ). There are other approaches too (including using a kernel level driver, but IIRC this approach can be very slow and difficult to get working.)

As far as overall the approach you take with VMProtect, the obfuscation is quite complex and if you have never devirtualized code before than you're going to want to try a simple VM first. Devirtualizing code and reverse engineering Virtual Machines, especially ones as obfuscated as VMProtect, can be a project that takes week.

Also VMProtect has multiple different VM "archetypes" per-se. There are some simpler VMs with heavier obfuscation in other areas and some very heavy-weight VMs or multiple layers of vitualization. So it is definitely not a project you want to approach without understanding practical applications of other code obfuscation techniques (control flow flattening, false predicates, and virtualization)

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.