next »

[citizen-erased]

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.

There's actually no need for key exchange. Using a asymmetric crypto you can sign your data with your private key, then distribute the data and public key. Assuming an unmodified executable, only unmodified files will be successfully decrypt.

Since the private key is kept private, nobody can modify data and resign it (but they can see and modify the data).

But overall this is just a small step up from a checksum if someone is willing to modify the executable.

[powly]

I'd like to make it rather hard for end-user to modify program attributes / strings / whatever.

... Why? If someone wants to find out what's going on, you're making it harder for them for no apparent reason.

[Muz]

Asymmetric crypto is very computing intensive, so normally you'll just use it to exchange a symmetric key. Also encryption is kind of overkill if all you want to do is check if it's been modified.

[citizen-erased]

Asymmetric crypto is very computing intensive, so normally you'll just use it to exchange a symmetric key. Also encryption is kind of overkill if all you want to do is check if it's been modified.

Agreed. Definitely overkill. I wasn't sure how expensive it would be since I've never tried it.

[ham and brie]

You only need to encrypt a hash of the file's content to form a signature.

The advantage over storing the hashes of the data in the executable is that you can update your data and sign it without having to update the executable.

[Shine Klevit]

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.

Honestly, there actually are major advantages to leaving your code partially open to the public. If I were trying to sell a product. I'd assume the difficulty in getting people to give a fuck would be a massively bigger stumbling block than the thread of piracy/modification. In fact, having a mod community is NEVER bad for business.

[rivon]

There's actually no need for key exchange. Using a asymmetric crypto you can sign your data with your private key, then distribute the data and public key. Assuming an unmodified executable, only unmodified files will be successfully decrypt.

Since the private key is kept private, nobody can modify data and resign it (but they can see and modify the data).

They can just rewrite the public key that the game uses with their own public key and sign the data with their private key. It's the same as with rewriting the hash in the game's binary.
A good idea for this case would be to hack together your own private/public key crypto method so that the hacker could not sign the modified data at all.
But even then, he can just open the binary in hex editor and edit the function which checks the file integrity to always return true (or whatever it uses for signalling success).

[kamac]

You're asking why I'd like to protect bytecode generated by my compiler... Well, it's easy - I don't want some random guy, opening up another's work (bytecode) and modifying the strings / game functionality as he wants. Well, I can't stop that, but I'd like to minimalize the risk. Even if it's good to have moddable products, I don't think it applies that much when it comes to commercial / whatever languages.

Even if it's not right, I just wanted to know how to do that for the future.


Cheers

[ThemsAllTook]

You're asking why I'd like to protect bytecode generated by my compiler... Well, it's easy - I don't want some random guy, opening up another's work (bytecode) and modifying the strings / game functionality as he wants.

I think what we're trying to get at is why you don't want that. What potential harm is done by someone tinkering with the innards of your game? I used to do this sort of thing all the time as a kid, and it was a valuable step toward becoming a game developer as an adult.

[kamac]

Well, the question might be why all major commercial and some non-commercial languages do that. LUA, App Game Kit (just cross-compatible BASIC) are those I know.

You can't open up LUA bytecode which you just compiled, edit some string inside it, save & run since it will crash. I am not sure if it's meant to be this way, or it's just the editor that gets it messy, but I am sure that App Game Kit does that.

When giving a language to somebody, I cannot be sure that he wants his game's source to be modified. He might want to make it moddable, but then he wants to prepare it for modding himself (Like a level editor which can be extended with DLLs)

[PompiPompi]

You could sign it so the end user won't be able to read it, but the issue is that you WANT the end user to read it. Or at least your application.
Whatever you provide the application which the user install to read it, the hacker can use to read it as well.
You can't hold the rope on both ends.

Edit: You could make it harder for the hacker to reverse engineer it, but the question is why would you want to? This is an extremly waste of effort on protecting something that is not clear anyone will bother to hack or even want to play\use. To be honest.

It's like putting a nickle inside a safe, being a bit harsh. XD

[PompiPompi]

I was told to tell you to use this:

http://en.wikipedia.org/wiki/Caesar_cipher

[rivon]

As was said, LUA isn't doing anything with the code. It's most probably just your editor messing it up. Try editing it in a hex editor.

Also, if you have your own language, then you have no problem. If you save the instructions as just numbers identifying them, then nobody can get to know what the instructions mean unless they watch how your app works in a debugger or something. And you can encrypt the strings in the bytecode with some simple method.

Then it won't be enough to just open it in hex editor and edit it. The hacker would have to dissassemble your code, copy some parts of it and try to somehow make the encryption work.

I guess that noone would bother with this unless your game is as popular as Minecraft or something.

[kamac]

Actually, nope rivon.

What the possible 'hacker' would have to do to edit the source of a program compiled by my compiler easily is try that for example:

Code:

print "test"

This is the bytecode output he'd see in some editor (hex / whatever)

Code:

3 2 -2 test -2

Which is wordpad looks like this:

Code:

[][][][][][][]ţ˙˙˙t[][][]e[][][]s[][][]t[][][]ţ˙˙˙

And he could realize easily that 2 means the type, -2 -2 is something like quotes and 3 means print.

So, he could kinda reverse engineer it to understand it's working.


All I want is to do basic protection, so a random dude won't come up opening the bytecode and changing the strings as he wants.

Ofer, I don't want to hash strings. It's not needed here.

And I actually know how to do that now, thanks to some of your replies.

[rivon]

As I said, if you encrypt the strings then the result would look like this:

Code:

00 00 00 11 00 00 00 10 AB D7 F3 FE 32 F8 E5 G6 E2 FF 42 89

which would result in some random string when viewed as ASCII. When you take into account that there would be hundreds/thousands of instructions like this, one after another, then the hacker has no way of distinguishing where one instruction ends and the other one begins. What is the opcode and what is an argument etc. (That is, unless you're so dumb that you separate the instructions by some "space" character which is always the same and opcodes are always the same.)

I would do it like this:

Code:

OPCODE NUM_ARGUMENTS [ARG1_TYPE ARG2_TYPE ...] [ARG1 ARG2 ...]

where OPCODE is an int. But to make it more undistinguishable, you can use more OPCODEs for one operation. For example k*1337, where k is between 1 and 1,000,000. That way, anything which would be divisible by 1337 without any remainder would signify one specific operation. When compiling, you would randomly pick the "k" so every occurence of this instruction would use a different OPCODE.
NUM_ARGUMENTS is an int.
The types of arguments could use the same technique as the OPCODEs, that way many numbers would mean the same type.
And finally the arguments, they are clear too, apart from the string. The string would comprise of first 4 bytes (int) signifying the string's length and after the length, an encrypted string would follow.
And the instructions would be in the file one after another without any common separator.

This would make it impossible to edit the code just by hex-editing. The hacker would have to reverse engineer your executable.

[nikki]

Well, it's easy - I don't want some random guy, opening up another's work (bytecode)

technically speaking (beware I've watched rms' videos) that bytecode is not your work at all.
It is the work of the opensource and free (as in freedom and beer) lua compiler.

the original sourcecode could be your work (depending on what you threw in offcourse, and if that stuff was licenced properly), and possibly the only real work you could claim as your own are the images and sound effects you've made, (when not stolen offcourse) Which I could just steal of you by taking screenshots/capturing images/capturing sound.

So I'd get even more paranoid or chill down and don't worry so much, I used to open up games when I was a kid too , and for example changed random texts in california games. What's the problem with that?
Or player cheat, and have infinite lives and a not-so proud feeling when  they finish game.

 

[rivon]

You probably didn't read what he said. He has his own language. He isn't using Lua.

[nikki]

oops ! yeah I've seen lua mentioned a good few times. Filled in the holes in my head

[kamac]

As I said, if you encrypt the strings then the result would look like this:

Code:

00 00 00 11 00 00 00 10 AB D7 F3 FE 32 F8 E5 G6 E2 FF 42 89

which would result in some random string when viewed as ASCII. When you take into account that there would be hundreds/thousands of instructions like this, one after another, then the hacker has no way of distinguishing where one instruction ends and the other one begins. What is the opcode and what is an argument etc. (That is, unless you're so dumb that you separate the instructions by some "space" character which is always the same and opcodes are always the same.)

I would do it like this:

Code:

OPCODE NUM_ARGUMENTS [ARG1_TYPE ARG2_TYPE ...] [ARG1 ARG2 ...]

where OPCODE is an int. But to make it more undistinguishable, you can use more OPCODEs for one operation. For example k*1337, where k is between 1 and 1,000,000. That way, anything which would be divisible by 1337 without any remainder would signify one specific operation. When compiling, you would randomly pick the "k" so every occurence of this instruction would use a different OPCODE.
NUM_ARGUMENTS is an int.
The types of arguments could use the same technique as the OPCODEs, that way many numbers would mean the same type.
And finally the arguments, they are clear too, apart from the string. The string would comprise of first 4 bytes (int) signifying the string's length and after the length, an encrypted string would follow.
And the instructions would be in the file one after another without any common separator.

This would make it impossible to edit the code just by hex-editing. The hacker would have to reverse engineer your executable.

Ahem. Yeah. I did it almost the same way, technically, just I didn't have to specify number of arguments. Got this information from a file that is shared between compiler and interpreter.

You misunderstood me, since I wrote it incorrectly 
By writing

I don't want some random guy, opening up another's work (bytecode) and modifying the strings / game functionality as he wants.

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.

Anyway, I know what to do now. Maybe it won't be too great solution, but I guess I could just save the time the file was saved at and few other information about the bytecode as it was during the compilation.

[rivon]

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.