next »

[kamac]

Hi there.

I was completely unable to find any information on this one, so I ask here instead.

How can I protect my file from somebody modifying it, saving and loading up to my program?
What I would like to do, is somehow sign the file containing binary data, and if user edits & saves the file with that data, it goes either corrupt, or the sign is messed up. Later on, it gets loaded to my program, which checks the signature. If it's okay, then it proceeds, otherwise it aborts.


Anybody?

[Shine Klevit]

hmmm... You could hardcode some information in your program that indicates information that should end up in the particular files, and reject them if that information has been tampered. That's not foolproof, and you'll have to be constantly updating it when you add new things to your datafiles. It's an idea.

Or, maybe just a really strong encryption scheme. Also, hosting the original files, and making them available might not be a bad idea.

[ThemsAllTook]

How can I protect my file from somebody modifying it, saving and loading up to my program?

You can't. It's impossible. If you want to make it a little bit harder to do, though, you could run the file through a SHA-1 checksum (or something similar), embed the checksum in your game code, and check against it when you read the file. I did this for one of my previous games to disable online high score submission for locally modified levels, but it's not at all an effective solution.

What manner of thing are you trying to protect? There may be other approaches you can take to get the protection you need, depending on the nature and intended usage of the data.

[Polly]

Checksum. Although someone could always reverse engineer your executable and modify the checksum itself .. nothing is unhackable

+Edit: ThemsAllTook beat me to it!

[rivon]

Yeah, hashing is the best option.

[kamac]

Ouch, guys, that's not what I've really wanted! 

I meant protection like LUA bytecode has. Or any other bytecode. Basically, you can open it up, see some squares (which are binary information), and even whole strings which are hardcoded into the application, but after you save it and try to interpret it with LUA interpreter / any other interpreter, it will crash, because the bytecode sign was corrupted during file save.

And I've got no idea how to make such bytecode signing, where saving corrupts the sign.

[rivon]

That probably means that the hashing is taking into account the file properties like creation date, modification date, permissions etc. Even that can be changed though.

[ThemsAllTook]

I meant protection like LUA bytecode has. Or any other bytecode. Basically, you can open it up, see some squares (which are binary information), and even whole strings which are hardcoded into the application, but after you save it and try to interpret it with LUA interpreter / any other interpreter, it will crash, because the bytecode sign was corrupted during file save.

There's a lot going on here. You seem to be talking about opening a binary file with a text editor? That's rarely useful, but whether it gets resaved after modification in a usable form depends on a lot of things. In trying to interpret binary data as text, whichever text editor you're using may have modified portions of it so that saving out the same file again will either use a different text encoding or have otherwise modified some of its bytes. Any random bit of modification to a binary file is likely to render it unusable if not done in a way that conforms to the file's format. Note that this depends completely on how your text editor works, and not at all any special piece of data in the file.

[BorisTheBrave]

I think you misunderstand. I doubt lua has any bytecode signing. If it did have something considered signing, it would almost certainly be a checksum of some sort.

There's no such thing as detecting that a file has been resaved. You are probably seing crashes because *your editor* isn't capable of preserving the file identically - bytecode is a binary format, so the slightest *accidental" change is likely to cause it to be invalid. But it's not defense against people well equiped with editors and knowhow - without a checksum, they will be able to make changes that are still valid.

And the checksum isn't perfect defence either - the hacker can change that too - but the depending on your exact usage that is sometimes harder than the rest of the changes needed.

[nikki]

I'd have a peek at those files with a hex editor instead. Then the squares are actual data.
Probably the program checks/hashes/compares/counts/parses and finds errors/tampered data/or crashes.

nothing you cannot hack around with some reverse engineering and some patience .

maybe you could look into all the million dollar techniques the big boys use and get cracked/hacked the moment they go loose in the world. Then you atleast know which technique won't work 

[Shine Klevit]

maybe you could look into all the million dollar techniques the big boys use and get cracked/hacked the moment they go loose in the world. Then you atleast know which technique won't work 

Actually this is an incredibly point. The best file protection of all would probably to be to not entice people to steal your files. If you're selling a product, and somebody's going to spend the time to crack it, you're probably already making enough money to where you don't need to ask this question on these forums.

[Muz]

What I'd do is maybe take the first 1MB of the file and hash it. Or other priority components. I can't really think of an efficient way to do this. While you can modify checksums, you can't modify hashes.

[ThemsAllTook]

What I'd do is maybe take the first 1MB of the file and hash it. Or other priority components. I can't really think of an efficient way to do this. While you can modify checksums, you can't modify hashes.

...what? A checksum is a hash. Also, while you might not be able to get the output of running a file through a hashing function to match a specific hash, you can modify the hash it gets compared to in the executable. Simply running a hash on a file does nothing interesting as far as verifying its integrity; you have to compare the result with a known value to determine if it's been edited. This just moves your vulnerability to the comparison function and/or the data it uses to compare.

[citizen-erased]

You could use public key cryptography. Encrypt your data with a private key and have your game use the public key to decrypt while loading. This won't prevent people from seeing your data but it will prevent the game from loading modified data.

This assumes your executable isn't modified. I've never tried it so I'm not sure what effect this will have on performance.

[_Tommo_]

whatever you come up with, both public (ie. the hash, a RSA key, etc) and the private (ie. an hash func, a in-exe stored hash, a RSA pkey) keys reside on the user's machine and are completely reachable with the user's level of privileges, so you can't do anything that is *theoretically* secure, you can only go for obscurity and hope that it will take a while to figure the trick out.
But someone WILL break it and they will be fast if there's enough interest.

ie. in a_citizen_erased example, you can just encrypt sniffed&modified data using the keys you steal from the game files, and the game will happily load this "secure" data.

What you can do is move part of the authentication to a remote (ie. verified) server, or have a special kernel-level (or lower) function that does that (like on consoles).
But still, what can be read can be copied and a man in the middle attack will at least allow to use modified files offline

And besides, protecting game contents from the user like this is totally pointless.

[citizen-erased]

ie. in a_citizen_erased example, you can just encrypt sniffed&modified data using the keys you steal from the game files, and the game will happily load this "secure" data.

The private key should not be on the user's computer. Only the public key is known and distributed.

And besides, protecting game contents from the user like this is totally pointless.

Yes, it wouldn't be difficult to modify the executable to get around the decryption (or any other schemes). I wouldn't recommend spending time on this stuff.

[ThemsAllTook]

Yes, it wouldn't be difficult to modify the executable to get around the decryption (or any other schemes). I wouldn't recommend spending time on this stuff.

Yep, quick rule of thumb... If the user's computer can decrypt it during normal execution of your game, the user can decrypt it and do whatever they want with just a little bit of effort and know-how.

[_Tommo_]

The private key should not be on the user's computer. Only the public key is known and distributed.

Even if the exe uses a ssh connection for the key exchange you can modify the exe itself to dump the key to a nice file, so it would only be harder for the hacker.

Yes, it wouldn't be difficult to modify the executable to get around the decryption (or any other schemes). I wouldn't recommend spending time on this stuff.

Amen

[kamac]

And besides, protecting game contents from the user like this is totally pointless.

Well, it's not for my game scripts, but it's rather to protect my language's bytecode that is generated after compiling the program. I'd like to make it rather hard for end-user to modify program attributes / strings / whatever.


Anyway, thanks for you input guys, that'll help me for sure.

Cheers.

[Muz]

What I'd do is maybe take the first 1MB of the file and hash it. Or other priority components. I can't really think of an efficient way to do this. While you can modify checksums, you can't modify hashes.

...what? A checksum is a hash. Also, while you might not be able to get the output of running a file through a hashing function to match a specific hash, you can modify the hash it gets compared to in the executable. Simply running a hash on a file does nothing interesting as far as verifying its integrity; you have to compare the result with a known value to determine if it's been edited. This just moves your vulnerability to the comparison function and/or the data it uses to compare.

Oh, I thought you meant like a school assignment kind of 'checksum' as in converting some bytes to a number and adding all of them together and checking the sum. Forgot that you could modify the sum it compares it to

Maybe have the comparison value online and verify it there? But you can still hack that by intercepting the online request and returning a value that you want.