VMProtect Software » Forum

First, I'd like to know if there is anything important I should know about injection when protecting a product. I am willing to recreate my injection system entirely if you recommend something other than manual mapping, or really just any noteworthy changes I should make. I've seen some threads here before talking about virtualization tools causing issues and memory protection causing issues. Please, tell me anything you think I need to know before purchasing.

try {
   throw 1;
}
catch(...)
{
  // do nothing
}

Second, I understand that there is already some debug detection. Is there anyway for me to avoid the default message boxes that come up and handle the results myself? I understand that there are some SDK functions for it, but I'd like to disable the default handler.

What about things like dumping? A large vulnerability for me is the ability to dump the dll from memory, so detection for that would be great. Even better would be prevention, even something basic like replacing the image base so novice dumpers could not dump the product.

Fourth, as I understand, there are refined techniques for VMProtected software reversing. Is there anyway to mask that I have used VMP for my software other than renaming the default .VMP section?

Fifth, I am running Windows. My web server is not. Would I need to purchase two copies in order to compile on both my windows machine and on the server? I have no problem with doing so, I'd just like some clarification before hand. If that is the case, can I purchase one version for personal use and then one version for the company as commercial use since only one will be used commercially or do they both need to be commercial?

Sixth, is there a way to automatically ultra-protect all functions then selectively unprotect those that are unnecessary (i.e. ones that need execution speed and otherwise don't matter) WITHOUT protecting external lib functions?

Seventh, is it possible to check binary modifications myself? I'd like to log attempts where the binary has been modified to the server before just refusing to allow execution of the binary.

Finally, I currently am using a system where it compiles the binaries for each user on use based on their user identification. This way, when I get my hands on the cracked version of my product, I can see who leaked what. I saw that there is a watermark system, does this function in a similar way to what I have in place? I can only assume that my current method of signature scanning for the user id area will be too protected for me to find when analyzing the binary, so I wanted to make sure there is still something I can use to identify each user.

Mattiwatti wrote:Just a note re: exception handling: on x64 it is possible to have limited support for exceptions due to the unwind data present in the PE. For this you can add an assembly stub to your injector that executes before DllMain and calls RtlAddFunctionTable, where FunctionTable is a pointer to the IMAGE_RUNTIME_FUNCTION_ENTRY of the PE, EntryCount is the total size of the table divided by sizeof(IMAGE_RUNTIME_FUNCTION_ENTRY), and ImageBase points to your DLL. You can free the memory used by the stub afterwards (assuming you fix up the stack so DllMain doesn't return to freed memory).

There are a few limitations:
- This works only for SEH exceptions, not C++ ones (at least with MSVC, this may be implementation dependent).
- This doesn't work on x86 due to the lack of unwind data.
- As noted, VMProtectIsDebuggerPresent will fail due to the use of probably many different types of exceptions.

What does work:
- SEH exceptions, including nested ones.
- (Vectored) exception handlers, as they are added at runtime by definition.

You shouldn't normally be using SEH in user mode, but some MS APIs are designed in a way that they are impossible to avoid. So this may be helpful to some.

I've implemented exception support in my manual mapper, so I believe this is a non-issue now. Exceptions are now handled fine for all of the ones I could think of.

I suppose an alternative would be if VMProtect has history clearing and runtime encryption. Does it? As in, is executable code cleared after its final use? For runtime encryption, the execution code is encrypted, decrypted to execute, then re-encrypted?

Is there anything else I can do to minimize the risk for detection of VMProtect? Or is it just an unavoidable thing that people will know it is protected by VMP? Is it an issue if they know?

Is there anyway to do the VMProtectIsValidImageCRC checks myself and not do the checks automatically at launch? Like I said, I'd like to log if the image has been modified in any way. I don't really need to know what the modification is; so CRC will work fine.