This article will discuss EurekaLog's features that is related to shareware developers.

Checking file for corruptions

The first thing is, of course, checking the file for corruptions. You can enable this feature in "Build Options" section.

"Check file corruption" option adds check for file corruption in your project. If you enable this option, EurekaLog will calculate a CRC checksum of the compiled file and store it inside file. EurekaLog will also read this checksum from file on its startup (launch). If your executable was modified, EurekaLog will display an appropriate message and shutdown your application immediately:

EurekaLog detected changes in executable file

You can use this option to ensure that your code wasn't modified.

Notes:

As you can see it is a very simple check.

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.

See also: using EurekaLog with exe packers/cryptors/protectors.

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 (EurekaLog'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 a 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 a 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. It is not possible to display a proper call stacks with methods and units names and source lines without the debug information. Because of this, EurekaLog gather all debug information from your application and attaches it to executable as a 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). Surely, you can exclude certain "sensitive" routines from debug information by using {$D-} before routine and {$D+} after routine, but this will introduce gaps in debug information, which could be noticed by a cracker.

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 even 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 disable adding methods, functions and procedure names to your executable. You can do it by enabling "Store unit names only" option. With enabled option the only information that goes into your exe file is units names and line numbers. 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 with offsets - these are enough to track down the problem, though it may be harder to do.

Call stack without class and routine names

See this article for detailed explanations of the offsets.

Third: if you still worry about your names - you can encrypt debug information with custom password, which isn't stored in executable. You can do it by typing password in the "Debug information encryption password" option. So debug information will not be useful without a password (which is not stored in application). Please note that you can combine this option with "Store unit names only" option.

Encrypted call stack

Well, you can not view the call stack (and assembler information) directly - it will be encrypted (EurekaLog uses TEA - this well-known cipher has very compact code). But you can load such encrypted report into EurekaLog's Viewer, enter your password (which you do know and cracker is not) and view unencrypted report.

How reliable is this method? TEA has few weaknesses. TEA is susceptible to a related-key attack which requires chosen plaintexts. Because EurekaLog projects is compiled by you and it happens rarely (much less that about 8'000'000 projects which is required for this attack to succeed) - this attack type is not applicable to you. TEA also suffers from equivalent keys, which means that the effective key size is 126 bits instead of 128 bits.

This means that cracker is left with brute-forcing 126 bit key or dictionary attack (which you can avoid just by using random passwords). Therefore this protection method is quite reliable, and you shouldn't be worried about your routine names to be accessible to everyone.

Finally: if you really worry - you can completely remove names from executable by using "Store all names externally" option. That way absolutely no names will be stored in your executable. However, your executable will no longer be self-sufficient. A new .elsym file will be created. This file will contain your names. You have to store this file on your developer's machine. This file can be used by Viewer to compose bug report replacing names stubs with real names.

Call stack with external names

(without .elsym file present)

While it may look the same as encrypted report - it is actually very different. This report encodes information like compilation ID + symbol offset, no symbol name is encoded/encrypted (because it is not stored in executable).

Important Note: Be aware that your executable will no longer be self-sufficient!

See Debug information options for more information.

See also: