File Checksum Generator
Posted: Fri Jan 25, 2008 4:23 am
After spending the better part of a year learning to reverse engineer, and unpack every major version of Armadillo and ASprotect, I am putting forth more knowledge of Anti-crack solutions. This is an IN-DEPTH solution that requires some thinking.
Your software WILL BE UNPACKED, even EXEcryptor users. Even if you use Armadillo custom builds, yes I have easily unpacked those too. The key is to outsmart the cracker in other ways. I have already posted about double subclassing, and procedure arrays, and my next part is regarding file checksums and hashes. My example uses JCV's hashlib, so proper credit goes to him for that.
If youe EXE/DLL are modified, the hash will change no matter what. Even inline patching changes the checksum. The point here i am trying to make is that using MULTIPLE types of checksums in MULTIPLE ways can be an extremely useful tool. "File Checksum Generator" takes whatever EXE/DLL files you ask it to, and generates 12 DIFFERENT types of hashes for EACH file. It then exports ALL those hashes FOR EACH FILE into an INI file, that can even be encrypted itself. It also will calculate the HEX CHECKSUM of each string hash (see below) as an additional method of protection.
Here's how it works:
1) Completely compile your program
2) Add the complied files to File Checksum Generator
3) generate 12 different checksums
4) Encrypt the filename and each hash with a password
5) export that data to a file
6) Now, from your program, you can read the INI file hash checksums, AT ANY POINT IN TIME and then compare them against a checksum that your program generates itself.
So you have SomeDLL.dll that has your registration check in it. Its pre-determined MD5 hash is 12345678901234567890123456789012. HOWEVER, your EXE file returns a DIFFERENT checksum. FLAGGED!. But you still have 11 more checks you can perform AT ANY PLACE IN YOUR CODE. If one is patched, then there are 11 more to find and patch as well.
This solution basically does the gruntwork FOR you, and gives you the option of calculating and/or storing your checksums. One possibility it to use a a data file for all your strings in your EXE, which are encrypted with the MD5 of your EXE itself. You could check the MD5 of your exe, and then use the returned result to decrypt all your window/button texts. If the MD5 is altered, then your program will be GARBAGE.
This solution is a great way to introduce hidden timebombs and integrity checks into your code. For every EXE/DLL you have, this gives you 12 hashes to use in any manner you choose. Im posting the source so you can modify the output of the hash data to suit your needs. You could even make this append the hash data to a DLL, use stenography to hide it into a bitmap or JPEG, or whatever.
For the "Sum" of the hash checksum, this is another way to verify that the file hash is correct without even comparing the two strings. Basically, you add the hex values of EACH hash character to get a final total. If 2 hashes are the same, then their sum character totals will be as well. Now, the same total can be reached by many hashes, but the possibility that will happen for 12 different hashes of a single file is about 1:trillion.
THE MAIN POINT is that the more you cloak your integrity checks, and the more you use, the possibility of cracking your program CORRECTLY decreases dramatically. THIS IS A TOOL, which can be used by you in any way you see fit. I will post an example shortly of the full power of this method. For now here is the EXE, the source, 2 INI files, and a screenshot.
http://www.penguinbyte.com/apps/pbwebst ... 1/FCSV.zip
Your software WILL BE UNPACKED, even EXEcryptor users. Even if you use Armadillo custom builds, yes I have easily unpacked those too. The key is to outsmart the cracker in other ways. I have already posted about double subclassing, and procedure arrays, and my next part is regarding file checksums and hashes. My example uses JCV's hashlib, so proper credit goes to him for that.
If youe EXE/DLL are modified, the hash will change no matter what. Even inline patching changes the checksum. The point here i am trying to make is that using MULTIPLE types of checksums in MULTIPLE ways can be an extremely useful tool. "File Checksum Generator" takes whatever EXE/DLL files you ask it to, and generates 12 DIFFERENT types of hashes for EACH file. It then exports ALL those hashes FOR EACH FILE into an INI file, that can even be encrypted itself. It also will calculate the HEX CHECKSUM of each string hash (see below) as an additional method of protection.
Here's how it works:
1) Completely compile your program
2) Add the complied files to File Checksum Generator
3) generate 12 different checksums
4) Encrypt the filename and each hash with a password
5) export that data to a file
6) Now, from your program, you can read the INI file hash checksums, AT ANY POINT IN TIME and then compare them against a checksum that your program generates itself.
So you have SomeDLL.dll that has your registration check in it. Its pre-determined MD5 hash is 12345678901234567890123456789012. HOWEVER, your EXE file returns a DIFFERENT checksum. FLAGGED!. But you still have 11 more checks you can perform AT ANY PLACE IN YOUR CODE. If one is patched, then there are 11 more to find and patch as well.
This solution basically does the gruntwork FOR you, and gives you the option of calculating and/or storing your checksums. One possibility it to use a a data file for all your strings in your EXE, which are encrypted with the MD5 of your EXE itself. You could check the MD5 of your exe, and then use the returned result to decrypt all your window/button texts. If the MD5 is altered, then your program will be GARBAGE.
This solution is a great way to introduce hidden timebombs and integrity checks into your code. For every EXE/DLL you have, this gives you 12 hashes to use in any manner you choose. Im posting the source so you can modify the output of the hash data to suit your needs. You could even make this append the hash data to a DLL, use stenography to hide it into a bitmap or JPEG, or whatever.
For the "Sum" of the hash checksum, this is another way to verify that the file hash is correct without even comparing the two strings. Basically, you add the hex values of EACH hash character to get a final total. If 2 hashes are the same, then their sum character totals will be as well. Now, the same total can be reached by many hashes, but the possibility that will happen for 12 different hashes of a single file is about 1:trillion.
Code: Select all
Procedure SumChecksum(String.s) ;This is designed to sum all the Hex values of a character string into one final number
For a=1 To Len(String); go through ALL characters of the string
character.s=Mid(String,a,1); get a character
Char=PeekC(@character) ;current character Hex value from calculated serial
CharValue=CharValue+Char ; add them together
Next
ProcedureReturn CharValue ;return the TOTAL character Hex sum
EndProcedure http://www.penguinbyte.com/apps/pbwebst ... 1/FCSV.zip
