kamac
|
|
« Reply #40 on: November 05, 2012, 02:56:41 PM » |
|
Then the simplest thing you can do is to use any encryption method (just XORing or Caesar method should suffice) on the strings in the bytecode and then decrypting them when you load up the bytecode. The hacker would have to dissasemble your code to see how you are doing the encryption and would then have to encrypt all the modified strings. Uh... I ment that I don't care if he sees the contents, but I don't want him to be able to save the edited file, with modified strings and boot it up, which would result in running the app as it was, just with changed strings for example. I said, that I don't care if somebody sees strings inside bytecode. I don't actually want to hash it, I don't want to hide it. I've found the solution as mentioned above actually.
|
|
|
Logged
|
|
|
|
Geti
|
|
« Reply #41 on: November 05, 2012, 07:25:03 PM » |
|
Seriously if all you want is it to be annoying to load a modified file, hash it (does nothing to the file, just outputs a number that represents that file, since you dont want it to be cryptographic you could just use MD5), put the hash in your binary, hash it again on load, if the hashes all match, execute. I'm not sure you're understanding what hashing is.
As has been said, though, if you really really want, you can go find the hashes in your binary, and edit them to be some new hashes for some modified file. It's just more annoying.
I seriously would not bother with any of this, but its your call.
|
|
|
Logged
|
|
|
|
Muz
|
|
« Reply #42 on: November 05, 2012, 09:36:51 PM » |
|
I love how these threads are all "why do you want to solve a theoretical problem?" long after the problem is resolved.
|
|
|
Logged
|
|
|
|
kamac
|
|
« Reply #43 on: November 06, 2012, 08:43:37 AM » |
|
I love how these threads are all "why do you want to solve a theoretical problem?" long after the problem is resolved.
Seriously if all you want is it to be annoying to load a modified file, hash it (does nothing to the file, just outputs a number that represents that file, since you dont want it to be cryptographic you could just use MD5), put the hash in your binary, hash it again on load, if the hashes all match, execute. I'm not sure you're understanding what hashing is.
As has been said, though, if you really really want, you can go find the hashes in your binary, and edit them to be some new hashes for some modified file. It's just more annoying.
I seriously would not bother with any of this, but its your call. Sorry, but I don't want to hash... My solution: Put information about bytecode length during the compilation and for example the time at which file has been saved. The rest remains untouched. When somebody edits the file by, for example, changing only strings, he'll violate one of those information provided, which I can detect. No hashing, just some additional bytecode information. Problem solved.
|
|
|
Logged
|
|
|
|
Fallsburg
|
|
« Reply #44 on: November 06, 2012, 09:22:33 AM » |
|
Except they could just change those bytes as well.
But whatever, you obviously don't understand what you are asking about, so enjoy your "solution".
|
|
|
Logged
|
|
|
|
kamac
|
|
« Reply #45 on: November 06, 2012, 09:33:51 AM » |
|
Except they could just change those bytes as well.
But whatever, you obviously don't understand what you are asking about, so enjoy your "solution".
As soon as they find out what they are. I said that I don't need 100% secure solution, I want a solution just so that a random guy won't change some strings in a program happily.
|
|
|
Logged
|
|
|
|
zalzane
|
|
« Reply #46 on: November 06, 2012, 10:26:01 AM » |
|
screw binary signing, that shit is for nerds
heres how you do it:
-have the binary your player downloads act as a JIT interpreter for whatever language your game uses -use brainfuck as your intermediate language -when the player starts your game, the interpreter queries your hosting server for the intermediate language code for the beginning of your game -hosting server sends a portion of your binary to the interpreter for execution -player gets through main menu or whatever and hits new game -intepreter queries host server for that part of binary -etc, and make sure to encrypt as much shit as you can on the way
10/10 hardcores
|
|
|
Logged
|
|
|
|
rivon
|
|
« Reply #47 on: November 06, 2012, 11:18:24 AM » |
|
Sorry, but I don't want to hash...
My solution: Put information about bytecode length during the compilation and for example the time at which file has been saved. The rest remains untouched. When somebody edits the file by, for example, changing only strings, he'll violate one of those information provided, which I can detect. This is the worst solution ever... First, if he just overwrites the strings without adding any additional characters, then the length is absolutely useless. Second, I'm not sure how you check the date of "saving" but I think that if you zip your game or use some kind of installer, then when the user installs it/unzips it, the creation and modification time will be changed. So it won't work.
|
|
|
Logged
|
|
|
|
ThemsAllTook
|
|
« Reply #48 on: November 06, 2012, 12:34:11 PM » |
|
I'm not sure how you check the date of "saving" but I think that if you zip your game or use some kind of installer, then when the user installs it/unzips it, the creation and modification time will be changed. So it won't work.
Modification dates are filesystem metadata that's not particularly special, and can be set to any arbitrary value without difficulty. So yeah, this goes both ways... Certain file operations might update your modification date unexpectedly, and after modifying a file, a savvy user has plenty of ways to change the modification date back to whatever it was before they made their edits. The exact same kind of savvy user who's going to poke at your files with a hex editor in the first place. So, modification dates provide zero protection from this sort of thing.
|
|
|
Logged
|
|
|
|
kamac
|
|
« Reply #49 on: November 06, 2012, 12:39:08 PM » |
|
This is the worst solution ever... First, if he just overwrites the strings without adding any additional characters, then the length is absolutely useless. Second, I'm not sure how you check the date of "saving" but I think that if you zip your game or use some kind of installer, then when the user installs it/unzips it, the creation and modification time will be changed. So it won't work. http://msdn.microsoft.com/en-us/library/ms724320%28VS.85%29.aspxNo, I don't know how did you get that idea. Try zipping a random file, then unzipping it. Last modificated date will stay untouched. I don't know about installers, but I guess some of them work on zipped files. Not sure here. I don't need or want installers though. First, if he just overwrites the strings without adding any additional characters, then the length is absolutely useless. Then how about writing the length + sum of all characters inside bytecode? Or length + sum + average of all values? I would add those between - gees - think, this way it's harder to modify the file. I choose to write few information that can be violated, instead of one. I might aswell hash the additional information.
|
|
|
Logged
|
|
|
|
BorisTheBrave
|
|
« Reply #50 on: November 06, 2012, 02:10:59 PM » |
|
I might aswell hash the additional information.
ffs you could have saved 4 pages of pointless dialog if you just listened for the answers everyone, their mother and their mother's dog has been trying to tell you. Next time, don't ask a question unless you want an answer.
|
|
|
Logged
|
|
|
|
Geti
|
|
« Reply #51 on: November 06, 2012, 09:32:29 PM » |
|
> I DONT WANT TO HASH > http://en.wikipedia.org/wiki/Hash_function "A hash function is any algorithm or subroutine that maps large data sets of variable length, called keys, to smaller data sets of a fixed length." > I ACTUALLY DO BUT I DONT KNOW WHAT I'M TALKING ABOUT !?!??!?! Next time, don't ask a question unless you want an answer.
|
|
|
Logged
|
|
|
|
|