INI protection

Hello all.

I've been making a simple little game to learn more about construct (usually I bite off more than I can chew, give up and never come back to a program again).

Now the basics are done I've been thinking of stuff to add to add replay value, better my construct knowledge and turn the small simple game into something bigger but still simple.

I had two nice ideas stat tracking & achievments. To track these I was going to use INI file(s) but these are simple to hack with a text editor, so I need to protect my files from naughty hackers.

This is what I came up with. It's pretty simple (and probably sloppily made) but seems to work great. When it gets a match between the stored hash it gives one message, if the hash isn't a match it gives a different message. In my game i intent to make it so if the hashes don't match it will simply reset all the stats & values to the default ones.

http://dl.getdropbox.com/u/1646976/inicrc32.zip

Oh and make sure all the files are unzipped to the same folder or else it won't work

Can anyone help me improve upon it? Or have any suggestions?

every time you save a file, save a hash of the file too (with crc32). Then when loading, make sure the hash equals the file.

every time you save a file, save a hash of the file too (with crc32). Then when loading, make sure the hash equals the file.

Thats exactly what I was going to do .

At the end of the game it'll write the new info in the crc32.ini then rehash and save the hash in the hash.ini and recheck at the start of the first layout of the game. If they don't match I'll reset all the info to default.

I did have one DUH! moment when playing about with this, I stored the hash of the crc32.ini in the crc32.ini and kept wondering why the hashes never matched.

Omg be sure to pm or email me when this is ready and you will be my new god! As i've always had trouble protectin INIs...

Your idea of checking the hashes is pretty good. Just keep in mind that it will only keep "honest" people honest. It does little to prevent a "hacker" from using a modified INI file. The reason why is the hacker can simply find the place in the .exe that checks the hash and simply patch it to always go to the "OK" state. This is not hard, probably only take 10 min or less to do.

That being said what you describe will keep average gamers from messing with the INI.

To track these I was going to use INI file(s) but these are simple to hack with a text editor, so I need to protect my files from naughty hackers.

I compiled a .cap file, then check and...receive this:

____________________________________________

CRC32 (Table)

|- Signature 77073096 found at offset 000E33DC (VA: 004EC7DC)

|- Signature ee0e612c found at offset 000E33E0 (VA: 004EC7E0)

|- Signature 990951ba found at offset 000E33E4 (VA: 004EC7E4)

|- Signature 076dc419 found at offset 000E33E8 (VA: 004EC7E8)

|- Signature 706af48f found at offset 000E33EC (VA: 004EC7EC)

|- Signature e963a535 found at offset 000E33F0 (VA: 004EC7F0)

|- Signature 9e6495a3 found at offset 000E33F4 (VA: 004EC7F4)

|- Signature 0edb8832 found at offset 000E33F8 (VA: 004EC7F8)

|- Signature 79dcb8a4 found at offset 000E33FC (VA: 004EC7FC)

|- Signature e0d5e91e found at offset 000E3400 (VA: 004EC800)

|- Signature 97d2d988 found at offset 000E3404 (VA: 004EC804)

|- Signature 09b64c2b found at offset 000E3408 (VA: 004EC808)

|- Signature 7eb17cbd found at offset 000E340C (VA: 004EC80C)

|- Signature e7b82d07 found at offset 000E3410 (VA: 004EC810)

|- Signature 90bf1d91 found at offset 000E3414 (VA: 004EC814)

|- Signature 1db71064 found at offset 000E3418 (VA: 004EC818)

|- Signature 6ab020f2 found at offset 000E341C (VA: 004EC81C)

|- Signature f3b97148 found at offset 000E3420 (VA: 004EC820)

|- Signature 84be41de found at offset 000E3424 (VA: 004EC824)

|- Signature 1adad47d found at offset 000E3428 (VA: 004EC828)

RC4

|- Signature fffefdfc found at offset 00084CB4 (VA: 004864B4)

|- Signature fbfaf9f8 found at offset 00084CB0 (VA: 004864B0)

|- Signature f7f6f5f4 found at offset 00084CAC (VA: 004864AC)

|- Signature f3f2f1f0 found at offset 00084CA8 (VA: 004864A8)

--------------------------------------------------------------------------

Can't understand the role of RC4.

By the way, I changed text in hash.ini file, but managed to preserve the same CRC32 code. Prog still complaining.

P.S. would like to know who implemented RC4 check in Construct - developers of Construct or MSVC?

CRACKED!!!!!!!!!!!!

Two folders: "cracked" and "fault". Check the age of a gamer in crc32.ini in both folders. What do you think?

http://rapidshare.com/files/273039011/cracked___.7z (1,7 mb)

Well, game just check two, but not one (as I think before) file. Simple CRC32, nothing more...

EDIT: in original file the age was 20.

Well so it isn't hacker proof but at least some one is going to have to try a lot harder to hack any values.

And nearly every commercial has been hacked/cracked so if proffesional studios can't be hacker safe I feel a bit better.

Thanks for the info Yaraslau.

I find the best way to get rid of the "me too" hackers is to simpley rename the .ini extension to something a bit more scary looking like .cab, .dat or something in the same line of things that way they are to scared to open it.

also keep in mind most knowledgeable people (not even hackers) will know which alogrithm you're using by counting digits.

Mix, cut and interleave hashes (CRC32, SHA1, MD5) to keep them guessing. Don't name the files something obvious, then you have a decent check that requieres some effort to crack.

=)

Thanks for the suggestions.

I was thinking of renaming the file extension something different than ini but hadn't got round to trying it yet.

Also making the hash look different than what it is ie hiding it in a longer "fake" hash sounds good as well.

I'll play around with the ideas.

Thanks guys.

You are spending a lot of energy on the INI protection. Sure, it grants you invaluable experience, but shouldn't you be focusing on the main project at hand?

Simple solutions oft prove to be the best. In this case, you can opt to save the INI file with no extension or obfuscated extension (not .txt nor .ini), by doing so you will stop about 80% of players from editing the file. MD5 hashing and such would only stop like 15% of the remaining 20%.

The 5% will find a way to hack into it in any case - most likely by editing values in memory.

In the future, as our projects get more serious, we'll want serious protection as well. By then, we'd have a need for encryption of some kind - scrambling the text and using a certain key to decode the content. Perhaps a plugin could be developed for that purpose, who knows?

Just my two (broken) cents.

You are spending a lot of energy on the INI protection. Sure, it grants you invaluable experience, but shouldn't you be focusing on the main project at hand?

Simple solutions oft prove to be the best. In this case, you can opt to save the INI file with no extension or obfuscated extension (not .txt nor .ini), by doing so you will stop about 80% of players from editing the file. MD5 hashing and such would only stop like 15% of the remaining 20%.

The 5% will find a way to hack into it in any case - most likely by editing values in memory.

In the future, as our projects get more serious, we'll want serious protection as well. By then, we'd have a need for encryption of some kind - scrambling the text and using a certain key to decode the content. Perhaps a plugin could be developed for that purpose, who knows?

Just my two (broken) cents.

Thanks Mipey.

I agree with all you said. The ini protection was just a side project and to gain experience in construct and ini files that I had never used before.

For my game I'll keep the CRC32 hash and as a few others have mentioned rename the file extension. I've also kept the ini itself a bit ambiguous - items are simply numbers and I have a list to match up my variable to the ini item, if you open the ini in notepad there is isn't a nice line of text saying "LIVES" edit here.

Thanks again.

You should be aware if you're only using a well-known one-way hash algorithm anyone sufficiently determined will still be able to crack it (curious people like me open cabs, dlls, sys files etc with suspiciously small file sizes). If you really want a good solution, use something like blowfish encryption.

Also: if there is no multiplayer, I'd say just let'em at it.

It's their game to enjoy!