Security mechanism working

When securing the original .exe file with our exeSecure tool, the original executable will be encrypted and a binary shield(executable code) will be wrapped around this encrypted piece. This shield itsself also exists out of binary program code and contains the security mechanism, which causes the activation window to show up on running. This software verification shield is not crackable by simply modificating a flag or modifying an if-statement of the shield:
The key used to encrypt the original .exe file is also based upon the original binary code of this shield. So the shield is part of the key(this is important). Modifying the shield will result in inproper decryption.

This is what globally happens when the verification process succeeds for a user:
1. The encrypted binary code of your original .exe file will be loaded in memory.
2. The encrypted code in memory will now be decrypted also in memory.
3. The decrypted code will now be executed, and your program is running!
Note: You original file, in it's secured form, will never be placed on the harddrive.


Secured .exe-files have been tested succesfully on Windows XP, Vista and 7, both on 32-bit and 64-bit systems. exeSecure can secure virtually every win32.exe-file, inclusive of the .NET framework. As an exception to this, 64-bit compiled applications and java executables can not yet be secured with exeSecure. It is necessary that a user has the Microsoft Visual C++ 2008 Redistributable Package installed, or a recent .NET Framework. People performing regular Windows Updates should experience no problems. Note: when protecting a .NET application, Microsoft .NET Framework 4 should be on people's system. A secured program will warn for this immediately.

Special files

After opening the secured .exe and a succesful activation, there are three files being generated. You don't have to know what they are doing, but in case you are interested: exesecure.dat contains the offline key, so that the end-user doesn't need to contact the activation server again next run. When you delete this file, either you'll have to reactivate by typing in the offline key that was shown to you before or by doing over the online activation process. Remember, reactivation in both cases will not cost the end-user an additional activation. The two .exe files which end on _l1.exe and _l2.exe are part of the special security formula that exeSecure uses. Don't worry about that your original .exe is written to disk, this is not the case.

Activation Scheme

After "exeSecuring" it, certain behavior is added to an application. Below is a diagram showing this behavior. Hover numbered items to get more detailed information.