Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

sectional CRC32

Status
Not open for further replies.

fenris

Programmer
May 20, 1999
824
CA
I found some code on PSC that appends a CRC32 checksum to the end of a file. The interesting thing about this program is that it just verifies sections of the executable. Normally the sections that are protected are where the registration routine is located.

I converted the code to a class and find it very easy to verify the checksum once it is written. The problem I am having is identifing the locations in the executable where protection needs to be administered.

I was thinking of writing some code to automate this, but I have no idea what to look for. Basically you have to open the file in a hex editor and identify chunks of code that are important. The chunks are specified as a starting byte and number of bytes. For example I would specify a starting position of 234 and a length of 500 bytes.

Any ideas would be appreciated.


BTW, the CRC32 check is integral to a protection scenerio that I am developing.


Troy Williams B.Eng.
fenris@hotmail.com

 
I don't think I'm clear on exactly what you're doing. Why do you need to get a checksum from just the "protected" section? This is probably just ignorance on my part, but it seems that it would be easier and just as effective to just checksum the entire executable. Or, better yet, divide the entire executable up into sections or predetermined size, and checksum each of them, so that you don't lose protection by having the data string too long. That way you know the information is well protected, but you don't have to hunt for a specific section in the binary.
 
The reason that I want to check specific "protected" sections is for efficency. I can quite easily crc32 the entire executable. But with an exe larger then 100k it can become time consuming.


<Quote>
Or, better yet, divide the entire executable up into sections or predetermined size, and checksum each of them, so that you don't lose protection by having the data string too long
</Quote>

That is the idea, except I don't need all the pieces that would make up your idea. I would only need the pieces that encapsulate the critical areas.

Ideally I would like to make a vb program that analyzes the executable and indicates where the if testing occurs and possible what line of code is related to it. This would help me determine where the sections should be.

As far as using the CRC32 check, I am running some experiments to see how tough of a software protection scheme I can make. My goal is too get a system that takes about an hour to break by an experienced cracker.

There are a number of tradeoffs that I have considered, namely the burden that a hardened system places on the end user. That is why I would like to CRC the exe vulnerable points, namely the points like:

if isregistered then
run program
endif

Of course I would obfuscate the name isRegistered to something a little less revealing.

I am going to have to experiment with the check and see if I can crc the whole exe and just verify the integrity when the program is loaded.

Thanks for the reply... Troy Williams B.Eng.
fenris@hotmail.com

 
I'm so far from it I can't see the purpose of the execrise. The statement APPEARS to by cyclic and redundant, so why check? A programmer who can crack the process of finding what you are doing (checking a registry value) and defeating it could, perhaps, also find where you are checking the CRC value (and equally bypass that), so providing the CRC check of the code snippet appears reasonably redundant? So, what am I missing here?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top