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

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.

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.