Checking file for corruptions
The first thing is, of course, checking the file for corruptions. You can enable this feature in "Build Options" section:
The first thing that should catch your attention here is that this option is located in "Build Options" section. What does it mean? Well, it means that EurekaLog will calculate CRC of your exe and write it to standard
CheckSum field in the _IMAGE_OPTIONAL_HEADER record. Yes, in the very standard (and documented) field in PE header.When you application executes, EurekaLog first calculates your CRC and compares it with value stored in
CheckSum field. If your executable was modified, EurekaLog will display an appropriate message and shutdown your application immediately:
Since there is nothing that prevents the cracker from changing the CRC in the header of the file once it has been changed, then this mechanism could not be considered as significant protection. Its purpose is checking file on unpremeditated changes. It should not be considered as serious line of defence against crackers. If you want to protect your file from crackers (not from simple modifications) then you need to deploy your own custom protection (okay, many so-called crackers are unable to pass even this check, but that is another story).
Another trick here is using executable compressor or signing the application. You see, once you have feed your exe to file compressor (such as UPX, for example) or sign it with digital signature - your file is changed, therefore EurekaLog fails while checking your CRC at start-up and shutdowns your application. From your point of view: your application just stopped working after compressing (or signing). The important point there is that compressing or signing your application already implies file checking. Since compressed file is far more sensitive to changes - therefore any modern file compressor contains some sort of checking mechanism that detects changes in the very same way that EurekaLog does. The same thing is applied to file signatures. If file is signed, then OS loader (and not the application itself) will check it before execution to ensure that its signature was not broken. The conclusion here is simple: if you use file compressor or you sign your application, then you can safely turn off the EurekaLog's "Check file corruption" option.
BTW, if you are writing an installer on your own - then you probably don't want to build it as single exe-file AND enable some sort of checking on it (EL's check, file compressor or digital signature). Why? Well, imagine that you got a 200 Mb installer in one single exe file and your client launches it. Whatever mechanism you use - it will scan the ENTIRE file at start-up. And scanning 200 Mb takes a lot of time! User can think that your application hangs. It is a lot better to make a (minimum) two-files distribution (small installer exe and large application archive) or turn off protection for installer.
And, finally: remember, that even digital signature is helper anti-malware mechanism for end-users and not an anti-crack protection! Digital signature on exe can only ensure user that this file was not modified and don't come from hacker instead of real application developer. It does not protect your application from cracker, since cracker can just simply remove digital signature.
Debug information: Pros and Cons
Another very important feature for shareware developers is debug information. EurekaLog embeds debug information into your executable to help you track source of your bugs. By default debug information is included only in dcu-files and don't go into your exe file. Without the debug information it is not possible to display a proper call stacks with methods and units names and source lines. Because of this, EurekaLog gather all debug information from your application and attaches it to executable as resource.The debug information is not stored in clear text, of course - it is compressed and encrypted. But since the password is stored in the exe itself - again, nothing prevents cracker from reading the password and decoding debug information. What kind of bonus can receive a cracker from debug information? Well, debug information contains names of units, classes, methods, function and procedures. Plus line numbers. It does not contain your source code, but, indeed, it is very interesting information.
Because of it, the very common question is: "isn't an executable file compiled with EurekaLog easier to crack?".
Well, it depends on many settings.
Let's check it out.
Yes, it is true, that including debug information to your application CAN make cracker's life easier. But it do not mean, that crack will appear automatically. Cracker still need to study your protection, and if your protection is written good, then it is not contained in dedicated procedures, but rather spread over all of your code. Since there is no "protection procedures", then reading procedure names gives no valuable information (and if you still have those - just give them a non-descriptive names).
In any case, even if debug information included in clear text (which is not, even without password), it can only speed up the study of your application. It can not suggest a way to crack. With or without debug info cracker will do the very same things. Therefore the difference "debug info" <> "no debug info" is equivalent of "crack can appear sooner" <> "crack can appear later", but not the equivalent of "app is cracked" <> "app can not be cracked".
Though you can do a certain steps to prevent cracker from gaining this speed-up bonus from your debug information.
First: you can exclude certain procedures from being included into debug information attached to exe. Just wrap them in compiler's directives that switches debug information on and off (it's
{$D+/-}). But, again, the cracker can see the "white spaces" in debug info coverage (if that idea comes to his mind too), so this will lead him directly to your protection code (good for honeypots though).Second: you can encrypt debug information with custom password, which isn't stored in executable. You can do it by typing password in the "Encryption password" field at the "Advanced options" tab in the EL's project options:
So debug information will not be useful without a password (which is not stored in application). Cracker can try to brute-force your password or ignore debug info. Well, you can not view the call stack (and assembler information) directly too - it will be encrypted (EurekaLog uses TEA - this well-known cipher has very compact code):
But you can load such report into EurekaLog's Viewer, enter your password (which you do know and cracker is not) and view unencrypted report.
Third: if you are really worry, that cracker can pick a password for your debug information (why just don't pick up a complex password?) - then you can move even further and disable including methods, functions and procedure names to your executable. You can do it by enabling "Do not store the Class/Procedure names" option in the same "Advanced options" tab:
With enabled option the only information that goes into your exe file is units names and line numbers! This information is completely useless to cracker. Of course, now your reports do not contains these names too. But call stack is still useful to you, since there are unit names and line numbers - these are enough to track down the problem, though it may be a little harder.
