The CHECK_PROTECTION macro allows you to check if your application has been partially unpacked or some protection engines have been attacked by a cracker. This macro offers communication between the protected application and the SecureEngine protection.
NOTE: The current version of SecureEgine® does not support this macro for .NET languages or Visual Basic applications.
The CHECK_PROTECTION macro can be called from inside other macros. In fact, it's highly recommend to call the CHECK_PROTECTION macro from inside VM macros.
The CHECK_PROTECTION macro has a special syntax:
CHECK_PROTECTION (user_variable, user_value)
Where "user_variable" is any local or global variable in the application and "user_value" is any immediate value (constant value). The way that it works is the following:
•The CHECK_PROTECTION macro is called.
•SecureEngine takes control of the processor and make special checks to know if the application has been tampered.
•If the application is not tampered, SecureEngine sets "user_variable" equal to "user_value".
•If the application is tampered, SecureEngine does not set "user_variable". You should take care of initializing "user_variable" to something else from "user_value".
•SecureEngine returns control to the protected application. The protected application should check the value of "user_variable" and execute the desired action if the application has been tampered.
If you detect that your application has been tampered, please, consider the following practices:
•Avoid taking an immediate action, like displaying a message or crashing the application. If you take an immediate action, the cracker will know where the problematic code is located and will focus all his attention at that point, trying to figure out the root of the problem in that code.
•Avoid displaying messages saying that the application has been tampered. Instead, make a "late" crash (see below) or display a strange error message at a later point in your application.
•Produce a "late crash" or malfunction. That is, if you detect that your application has been tampered, you mark special variables (or similar action) in your code. At a later point in your application, you crash your application or initialize further structures in a wrong way, so, your application won't work as expected. For example, suppose that you are protecting a CD burning application. When your application is initializing, you call "CHECK_PROTECTION" macro to determine if the application is tampered or not. If it's tampered, you won't take any action yet, but instead, you will wait for the CD recording process to burn random or incorrect data into the CD.
•Use VM macros in all those places where you call CHECK_PROTECTION and where you check if the application was tampered. Also, if you decide to produce a "late" crash or malfunction, that code which produces the crash or malfunction should go inside VM or CodeReplace macros.
int MyCheckVar;
VM_START
// your code goes here
CHECK_PROTECTION(MyCheckVar, 0x12345678)
// your code goes here
if (MyCheckVar != 0x12345678) printf("We are tampered!");
VM_END |
var MyCheckVar: Integer;
begin
{$I VM_Start.inc}
// your code goes here
{$I CheckProtection_Prolog.inc} asm push 11111111 // 11111111 is our special constant pop MyCheckVar // SecureEngine will set "MyCheckVar" to 11111111 if protection is OK end; {$I CheckProtection_Epilog.inc}
// your code goes here
if MyCheckVar <> 11111111 then ShowMessage("We are tampered!");
{$I VM_End.inc} |
Advises about how to use this macro
•Put the CHECK_PROTECTION macro inside VM or CodeReplace macros.
•Think always that the first attack from a cracker is just directly jump over your VM / CodeReplace macro (that is, the code inside the macro is not executed), so you should make sure that inside the macro you put code that is necessary for your application to run correctly.
•You don't have to call the CHECK_PROTECTION macro periodically, just make sure that it's executed at any time in your application.
•You can put as many CHECK_PROTECTION macros as desired, but we recommend you just putting a few of them (about 5 of them) in different routines in your application.