Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1067325 Posts in 43581 Topics- by 35620 Members - Latest Member: VirObitus

November 28, 2014, 11:09:54 AM
TIGSource ForumsDeveloperTechnical (Moderators: Glaiel-Gamer, ThemsAllTook)Binary file signing
Pages: [1] 2 3
Print
Author Topic: Binary file signing  (Read 1564 times)
kamac
Level 10
*****


Notorious posts editor


View Profile Email
« on: November 04, 2012, 02:04:01 PM »

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?
Logged

Nothing to do here
Shine Klevit The Utopian Peasent
Level 1
*



View Profile Email
« Reply #1 on: November 04, 2012, 02:07:31 PM »

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.
Logged
ThemsAllTook
Moderator
Level 10
******


Alex Diener


View Profile WWW
« Reply #2 on: November 04, 2012, 02:09:39 PM »

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.
Logged
Polly
Level 4
****


View Profile
« Reply #3 on: November 04, 2012, 02:12:02 PM »

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

+Edit: ThemsAllTook beat me to it!
Logged
rivon
Level 10
*****



View Profile
« Reply #4 on: November 04, 2012, 02:18:35 PM »

Yeah, hashing is the best option.
Logged
kamac
Level 10
*****


Notorious posts editor


View Profile Email
« Reply #5 on: November 04, 2012, 02:25:35 PM »

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

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.
Logged

Nothing to do here
rivon
Level 10
*****



View Profile
« Reply #6 on: November 04, 2012, 02:35:28 PM »

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.
Logged
ThemsAllTook
Moderator
Level 10
******


Alex Diener


View Profile WWW
« Reply #7 on: November 04, 2012, 02:39:59 PM »

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.
Logged
BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #8 on: November 04, 2012, 02:45:20 PM »

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.
Logged
nikki
Level 10
*****


View Profile Email
« Reply #9 on: November 04, 2012, 03:00:19 PM »

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  Well, hello there!




Logged
Shine Klevit The Utopian Peasent
Level 1
*



View Profile Email
« Reply #10 on: November 04, 2012, 03:14:56 PM »

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  Well, hello there!

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.
Logged
Muz
Level 10
*****



View Profile Email
« Reply #11 on: November 04, 2012, 04:09:44 PM »

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.
Logged
ThemsAllTook
Moderator
Level 10
******


Alex Diener


View Profile WWW
« Reply #12 on: November 04, 2012, 04:20:54 PM »

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.
Logged
citizen-erased
Level 0
**


View Profile WWW
« Reply #13 on: November 04, 2012, 05:00:25 PM »

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.
Logged
_Tommo_
Level 8
***


frn frn frn


View Profile WWW
« Reply #14 on: November 04, 2012, 05:01:04 PM »

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 Cool

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

citizen-erased
Level 0
**


View Profile WWW
« Reply #15 on: November 04, 2012, 05:08:05 PM »

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.
Logged
ThemsAllTook
Moderator
Level 10
******


Alex Diener


View Profile WWW
« Reply #16 on: November 04, 2012, 05:32:47 PM »

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.
Logged
_Tommo_
Level 8
***


frn frn frn


View Profile WWW
« Reply #17 on: November 04, 2012, 05:35:18 PM »

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
Logged

kamac
Level 10
*****


Notorious posts editor


View Profile Email
« Reply #18 on: November 04, 2012, 10:41:38 PM »

Quote
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.
Logged

Nothing to do here
Muz
Level 10
*****



View Profile Email
« Reply #19 on: November 04, 2012, 11:12:36 PM »

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 Tongue

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.
Logged
Pages: [1] 2 3
Print
Jump to:  

Theme orange-lt created by panic