File Checksum copy protection


#1

Is there a way to create a checksum of the current process (code segments only, no data segments included) for Windows or OS X?

This would be useful for some copy protection that would for example check the current process’es checksum after some hours and change the program’s behaviour so it doesn’t work normally no more (if it has been modified, the checksum differs and that means it has been cracked).

It would also be possible to do this via a checksum calculation based on accessing the process’es file, but this is very easy to crack, because disassemblers list OS functions.


#2

Might be possible, but very fiddly to build! How would you work out the correct checksum and get that in the exe without messing up the checksum!?


#3

One has to write the checksum into the .EXE or .DLL after that the build itself. There’s no way around that.

One could for instance do a 32 bit unsigned checksum by adding all bytes together of the build. Then write it to the position where the 32 bit checksum is needed (original value where this value is written must be 0 before). In the code itself, where the checksum is performed in the DLL, one will ofcourse get a 32 bit value that differs from the one written into the file (it will actually be the double of it), but one can then divide by 2 and it will be ok.

Example: Original .EXE checksum = 0x44. One writes 0x44 into it at the right place, then the original .EXE will determinate a checksum of 0x88, because the additional 0x44 was added but the code will divide this 0x88 by 2 so it gets 0x44 again, so it knows the checksum is correct.


#4

Then, what prevent an evil hacker from computing the checksum by itself, after code “modification” ?


#5

Well, first the cracker (not hacker) has to know that there actually is a checksum test. If the checksum is only tested all 2 weeks and the program does only behave strange afterwards (like for instance sometimes creating corrupted data when saving something), it is not easy to reproduce this effect when one wants it.
Afterwards the cracker has to find where this checking of the checksum occurs.

Ofcourse, if the checksum code accesses for instance the file itself to compute the checksum, it is very easy to find out where this occurs, because file access is done for that purpose.

That’s why I wanted to know if there is another way of doing this in memory.