Newbie questions about using VMProtect

[vmuser1]

Hello,

I am using VMProtect DEMO v3.8.5 for a VS C++ DLL and have a few questions:

1. It seems that when I add compiler markers inside my code, the DLL then becomes dependent on VMProtectSDK32.dll. From what I understand, VMProtect will remove this dependency when it processes the DLL, however what happens if I just want to use a Debug version without releasing it? Does this mean I need to wrap all the VMProtect macros with an #ifdef DEBUG so I can run my application without the VMProtect DLL? Is there any other option? I can see that you can potentially manually name all the functions to virtualize in the GUI, however I assume it will break if any function name changes?

2. When I process my DLL with any of the "File" options (ie. Memory, Import, Resource or Packing protection), it adds a massive lag to my application to the point of being unusable. If they are all disabled, then it works normally but is there any point of using VMProtect without these options enabled?

3. When I wrap my function calls with the "Virtualization" option (Complexity=Default), the functions also become very very slow (over 60 seconds for a response from my GUI that calls the DLL). The operation is instant when unprotected. Looking at the areas that I have wrapped, these represent the core code I want obfuscated and it isn't very many lines of code (approx 20 lines of c++ code). Anything I can do about this?

Thank you.

[00p$]

Random VMP user's opinion:

1. If I remember correctly, using of code markers is not recommended since you leave prolog/epilog of the function unprotected (maybe this has changed now, not sure). I usually add all needed functions manually (or dynamically via script). Yes, functions will break if you change their names, but this doesn't happen often.
2. VMP is a good static mutation/virtualization tool, many people use it without dynamic options just to obfuscate the binary. Depends on your needs.
3. It's not a count of lines of code that matters, but the resulting binary size. You can literally inline megabytes of code on a single line and not know it. For my projects, virtualization was never a critical problem, so you probably should send a basic example for Admin to look (if you can achieve this behavior on non-private piece of code).

[vmuser1]

Hello,

Thank you for taking the time to reply. Regarding 1), do you know what happens if I use a .map file for the initial setup of naming which functions should be virtualized and subsequently not generate it any more? Does the application find the function by name or by address? Does that mean if I change my DLL in any way, I need to regenerate the .map file?

Regarding 2), if there are no functions set for virtualization and all "file" options are on, does this mean that all the functions are still hard to analyze?

Regarding 3), my DLL only grows by about a megabyte or two (roughly 10% increase) but it slows down to the point of being unusable.

Thanks again for your help (not sure if I will get any official response?).

[Admin]

1. Does this mean I need to wrap all the VMProtect macros with an #ifdef DEBUG so I can run my application without the VMProtect DLL? Is there any other option?

What is a problem with "#ifdef/ifndef DEBUG"?

Code: Select all

#ifndef DEBUG
#include "VMProtectSDK.h"
#endif

void foo()
{
#ifndef DEBUG
	VMProtectXXX(...);
#endif
	...
}

2. When I process my DLL with any of the "File" options (ie. Memory, Import, Resource or Packing protection), it adds a massive lag to my application to the point of being unusable. If they are all disabled, then it works normally but is there any point of using VMProtect without these options enabled?

More detailed information about these options you can read here

3. When I wrap my function calls with the "Virtualization" option (Complexity=Default), the functions also become very very slow (over 60 seconds for a response from my GUI that calls the DLL). The operation is instant when unprotected. Looking at the areas that I have wrapped, these represent the core code I want obfuscated and it isn't very many lines of code (approx 20 lines of c++ code). Anything I can do about this?

Don't use the code virtualization for speed critical functions.

[vmuser1]

Hello,

Thanks for your reply.

What is a problem with "#ifdef/ifndef DEBUG"?

The issue with "#ifndef DEBUG" is that aside from creating lots of additional noise in the code, I still can't test my release version until it is packed or unless I include the VMProtect DLL. Of course, as a workaround I can start adding additional compiler directives to handle this, but it means more coding/testing and the risk that the executable ships without correct packing. Most other protectors I have tried have all the information contained in the project file and/or the compiler directives do not require additional DLLs just to run the program. Since the latter doesn't appear to be possible, I assume that the only way to have that independence is by producing a MAP file and protect by function call. Is that correct? If so, do I need to regenerate the MAP file each time or does VMProtect automatically detect the address protection ranges once the function names are known?

More detailed information about these options you can read here

Thanks, I did read this section but still can't explain why if any of these options are selected it grinds my DLL to a halt (I've tried each in turn). Does VMProtect provide any level of protection if all these options are unchecked?

Thanks again.

[Admin]

The issue with "#ifndef DEBUG" is that aside from creating lots of additional noise in the code, I still can't test my release version until it is packed or unless I include the VMProtect DLL. Of course, as a workaround I can start adding additional compiler directives to handle this, but it means more coding/testing and the risk that the executable ships without correct packing.

I can recommend you don't use our SDK if you are not going to "waste your time" for additional coding.

Since the latter doesn't appear to be possible, I assume that the only way to have that independence is by producing a MAP file and protect by function call. Is that correct? If so, do I need to regenerate the MAP file each time or does VMProtect automatically detect the address protection ranges once the function names are known?

I have gave you several times the link to our user manual that has answers on all your questions, but you haven't read it yet.

P.S. The topic is closed.