How to verify as a valid client?
You can design it to prevent tampering of the client, a hardware dongle comes to mind.
[quote name='SimonForsman' timestamp='1340550234' post='4952328']
Such a system still doesn't prevent the user from modifying his own client, the best it lets you do is identify the user (But a normal login system lets you do that as well), There is no need to crack the keys since the modified client only needs the public key (Which it allready has access to) to encrypt any data it is going to send, it can freely modify it before that point, digital signatures on the code itself are worthless since the server cannot verify them (it can request verification data from the client but a modified client can get the correct data from the unmodified one for such purposes)
Combine it with a unalterable hardware dongle.
[/quote]
The client is responsible for reading/writing data from/to the dongle, so it doesn't work either, those things are fine for authentication, not for preventing modification. (I.E, you can ensure that the user has a valid dongle (or valid emulation of a dongle if its a good hacker), but the dongle cannot be trusted to verify the clients software since the client controls the software which interacts with the dongle.
Did you not read, or not understand, the argument?
The argument is checking the validity of a client, that is what digital signature is for, and it will do that. You are assuming a hacker with unlimited knowledge and power, which most aren't.
You could easily implement a system such as on-live if your that worried about it. I was not assuming the worst case scenario, but this would solve it.
All the things you mentioned are hurdles. They do slow developers of cheats down. But cheating remains possible, and in the meantime you were slowed down as well: your time could have been spent developing nice new features, or possibly cheat detection, which is arguably more important. So you have to ask yourself if you're really spending your time well.
All the things you mentioned are hurdles. They do slow developers of cheats down.
How would you design a cheating system if all your being fed is image data such as on-live?
[quote name='Prefect' timestamp='1340566840' post='4952408']
All the things you mentioned are hurdles. They do slow developers of cheats down.
How would you design a cheating system if all your being fed is image data such as on-live?
[/quote]
aimbots can work with image recognition, but on-live is pretty much as secure as it gets since the client is just a dumb terminal (The software runs entierly on trusted machines), the only type of cheats that work with on-live are bots basically, and they take quite a bit of extra effort to write since you don't get the data in an easy to use format.
I think if you combined any of the techniques I mentioned, with a cheating detection techniques, and put as much data as possible on the server, the idea of hacking is impractical.
You can design it to prevent tampering of the client, a hardware dongle comes to mind.
Wow, we're really following this same trajectory again?
Each and every software application that has a hardware dongle is available in a cracked version.
If you sign a message using a hardware dongle, then there's still the question of where the message came from in the first place -- the user can feed whatever message he wants into the dongle, and have it signed.
The only way to avoid this is to have the hardware dongle generate the messages as well -- at that point, you have a closed hardware platform, like the Xbox. And, even there, there exists mod chips and hacks, which Microsoft ends up dealing with by detecting banning consoles, rather than trying to authenticate each message into each game server.
I'm going to lock this thread. This conversation has been had a dozen times, and you can just search through the archives for the various arguments.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement