Protecting client side files?

People don't bother most of the time.

For online games, certain checksumming algorithms (punkbuster, etc) can help to make sure that client data hasn't been modified.

You can't stop a determined attempt, but compressing it and possibly doing some simple encryption will help keep casual snoopers from discovering this kind of thing.

Quote:

Original post by Twixly I was wondering how people generally go about protecting data stored on clients, like maps, graphics, setting files etc? I would prefer if people could not access the world map to see how things look and where stuff is etc. Same goes for graphics, I don't want it available to just open/edit, not that it affects much but still. Is there some common way to get around this or do people just don't bother most of the time?

Stick your assets in some sort of archive file - anything more complicated than a simple .pak should be enough to dissuade casual snooping. For the more determined individuals, there is really very little you can do: even punkbuster, et al can be circumvented without too much difficulty.

Thanks. I am not after some super safe way, just to deter most 12y old boys on their fathers computers :)

no, seriously. This is done outside of code then? Like common zip?
Or is there some library you would use?
I am on Java 1.6 in this case if that helps.

Quote:

Original post by Twixly Thanks. I am not after some super safe way, just to deter most 12y old boys on their fathers computers :) no, seriously. This is done outside of code then? Like common zip? Or is there some library you would use? I am on Java 1.6 in this case if that helps.

Quake III uses .zip files, with the extension changed to .pk3. You need to consider how much time you want to invest. You could use a zip file with a different extension if you want a quick fix that will deter some people, or you can invest more time and create your own encrypted (and optionally compressed) file system that will deter most people.

However, the assets have to be decoded at some point, and it's surprisingly straightforwards to get them at that point.

In a word: impossible. There's no sense in trying to protect the data because that protection can (and will) be undone.

If a user snooping the files breaks your game, then you should rethink how/why you are sending such information to the client.

~don

Im not a great fan of 'protecting data' but yes for multiplayer I can see the need.

OK that in mind

A/ encrypt data
B/ do checks during gameplay for impossible states, if triggered then (exit program perhaps)

i thought of an idea of having those files also in the server side, and when the client tries to connect, force the client to randomly check some bytes(their data and location in the file) in some files, and send it to the server to check if these bytes have the same data and are in the same location in the file. it's a little costy if you have alot of files. if might not work if the files are slightly modified, but only way to pass it i can think of is reverse engineering the client.
what do you think about it?

Bru; all that does is force hackers to open the EXE, replace your client-side check code, and keep around unmodified copies of any files they altered. You can't force the remote machine to do anything, even if you wanted to. Once those bits are on their machine, they are beyond your control and forfeit from your discretion, and reverse engineering is not only free but very easy.

It's called DRM; it's also physically, mathematically, and economically impossible.

Quote:

Original post by Bru i thought of an idea of having those files also in the server side, and when the client tries to connect, force the client to randomly check some bytes(their data and location in the file) in some files, and send it to the server to check if these bytes have the same data and are in the same location in the file. it's a little costy if you have alot of files. if might not work if the files are slightly modified, but only way to pass it i can think of is reverse engineering the client. what do you think about it?

Reverse engineering a client is easy-ish, since you control its environment anyway.

If you mean the client to refuse running if the server's answer is negative, then it's very easy to circumvent: just disassemble the executable and change the jump instruction.

If you mean the server to refuse the connection if the client notifies it that the files have changed, I can see two easy way to work around that. Either hack the client to always tell the server that the files haven't changed, or just hack the client (again) to make the check against the original files, while using the modified files during the actual playing of the game. That would work with checksums as well (just record the checksums of the original files and send that instead of the current checksums).

It's also possible to simply reverse-engineer the protocol and to write a small application proxy that'll sit between the application and the server, thus avoiding the need to disassemble the client altogether. DLL injection can also be used to override some functions.

Really, there's no way to protect that data.

Quote:

Original post by Bru randomly check some bytes

The problem with that approach is that computers don't have the notion of "random"
There is no true randomness, but pseudo-randomness.
Eventually a determined hacker/cracker/whatever will find how that "randomness" is calculated and predict which bytes to look.
Then it can look at those bytes sent by the server, modify them client-side, and lie to the server sending the unmodified bytes to it.

Edit: let_bound got first with his post

Quote:

Original post by let_bound Quote: Original post by Bru i thought of an idea of having those files also in the server side, and when the client tries to connect, force the client to randomly check some bytes(their data and location in the file) in some files, and send it to the server to check if these bytes have the same data and are in the same location in the file. it's a little costy if you have alot of files. if might not work if the files are slightly modified, but only way to pass it i can think of is reverse engineering the client. what do you think about it? Reverse engineering a client is easy-ish, since you control its environment anyway. If you mean the client to refuse running if the server's answer is negative, then it's very easy to circumvent: just disassemble the executable and change the jump instruction. If you mean the server to refuse the connection if the client notifies it that the files have changed, I can see two easy way to work around that. Either hack the client to always tell the server that the files haven't changed, or just hack the client (again) to make the check against the original files, while using the modified files during the actual playing of the game. That would work with checksums as well (just record the checksums of the original files and send that instead of the current checksums). It's also possible to simply reverse-engineer the protocol and to write a small application proxy that'll sit between the application and the server, thus avoiding the need to disassemble the client altogether. DLL injection can also be used to override some functions. Really, there's no way to protect that data.

i didnt say or atleast didnt mean to force client to refuse do anything, but to let the server refuse the client if he doesnt send those bytes at that location which the server reqeuested. that's a little harder to reverse engineering. correct me if i am wrong its just something i thought about.

matias, can hackers calculate the randomness if it is sent by the server?

Quote:

Original post by Bru i didnt say or atleast didnt mean to force client to refuse do anything, but to let the server refuse the client if he doesnt send those bytes at that location which the server reqeuested. that's a little harder to reverse engineering. correct me if i am wrong its just something i thought about. matias, can hackers calculate the randomness if it is sent by the server?

They don't even need to calculate the randomness. That scheme is very easy to bypass. It works the same way you bypass a CRC and that is to maintain two copies of the data, original and modified. You feed the original into the checking functions yet you use the modified data in game. Even if you are doing memory checks, those too are easily faked with detours on the Windows API functions or kernel level function hooks.

Basically I'll just say again what has already been said in this thread. Ultimately, you can only do so much to deter people, but anyone who really wants your data can and will get it. Compression and encryption is enough to deter most people, but once someone figures it out, they can just release the tools that make everyone else able to get the files as well.

You should not put too much time or resources into the issue, in my opinion. Just compress and encrypt your files and you will be set. Everything else is really out of your control or would be too much of an investment that would unlikely pay off.

You could also invest in a client protection technology like Themida, WinLicense, ExeCryptor, etc... and deter the largest amount of people, but then you will run into some support issues with antivirus programs detecting your files as viruses (such a pain to deal with).

Quote:

Original post by Bru can hackers calculate the randomness if it is sent by the server?

Just to make sure everyone is clear on the concept, copy protection and DRM have been attempted for over 30 years (the Apple II in 1976 had an elaborate copy protection scheme for both cassette tapes and diskette), and not one scheme I am aware of has avoided being cracked.

It isn't so much that the hackers are good (though they are), it is more that the whole idea is fundamentally flawed: you give someone a chunk of data (be it program, assets, etc.) and then expect to control how they use it - it is like handing someone an apple, and afterwards trying to prevent them from eating it...

Quote:

Original post by Bru matias, can hackers calculate the randomness if it is sent by the server?

The question has been answered. But in easy words:
Yes.
If it is sent by the server, the client needs to be told what the randomness is. The hackers just need to "listen" when the server tells the clients where the random byte is.
It is like trying to enter in a club if you have the secret password. You just need to put a wire to someone who knows it so you can listen when he tells it to the security guard.

If the randomness is, instead, calculated client-side to avoid a hacker "listening", he still can reproduce the steps the client program is doing to get the randomness he is looking for.

If you want to protect your data from illegal use, just use copyright law, with licenses.

Quote:

Original post by loufoque If you want to protect your data from illegal use, just use copyright law, with licenses.

come on dont be such a small headed person, do you realy think that stops anyone? its not so easy to track who edits the client files so no one is realy intimidated doing it.

Quote:

Original post by Bru Quote: Original post by loufoque If you want to protect your data from illegal use, just use copyright law, with licenses. come on dont be such a small headed person, do you realy think that stops anyone? its not so easy to track who edits the client files so no one is realy intimidated doing it.

Do you really think technological hindrances stop anyone?

A simple encryption/compression algorithm that means the file can't be opened in a commonplace editor should deter the average curious mind. Anything more than that is basically a waste of time as a dedicated person can and will crack it.

If it is a single player game then who cares – if someone cheats then it's only their own satisfaction they're spoiling. If it is a multi-player game then your server must be prepared to accept any old crap and react accordingly; all actions asked for by a client need to be checked for validity, and you want to only send visibility information for things which the user can actually see if possible.