Winsock SOCKET buffer dumping
Author
Hey! Im writing the networking for my MMOG in WinSock and i always here check everything so when i check something and discover thats its not the message i want like a hacker sent it or something how do i dump the buffer to get rid of the message?
usually, the code looks something like this:
If the msg is invalid, just don't handle it. You can also quickly disconnect/close the socket, and simply not read any more from it.
while(1){ while(read()){ do(msg); }}If the msg is invalid, just don't handle it. You can also quickly disconnect/close the socket, and simply not read any more from it.
A hacker can easily create the correct checksum, so that doesn't add any additional security.
Quote:
A hacker can easily create the correct checksum, so that doesn't add any additional security.
yeah,i know it!
Andrew Kirmse knows it!
so he wrote an article about it in Game Programming Gems 1!
and BTW do u have any other good method to solve it(avoid hacker juggling packet)?
If your program does it (encryption, checksums, etc), it can be emulated by someone else. Basically you cannot trust ANY data sent by the client, the only solution is to test 100% of the data contained within the packets (100% means lengths, null termination, validate values, etc). With a smaller game that isn't a big deal, you can add simple encryption like xor and bitshifts, randomized sequential keys, etc, but in the long run it can be cracked. If your games success is dependant on the integrity of the data, then you have to work to make sure everything they give you is not BS. A common thing for servers to fail at securing is timing, and null pointers to objects represented by id's, which results to malicious users being able to exploit or crash the servers.
Another solution is to closely moderate the game, i've seen vournable games thrive on good moderation because any progress from cheaters was reset when found. Any cheating nobody knew about, didn't effect the playerbase :P. Still I'm very favorable of the first paragraph. :)
Another solution is to closely moderate the game, i've seen vournable games thrive on good moderation because any progress from cheaters was reset when found. Any cheating nobody knew about, didn't effect the playerbase :P. Still I'm very favorable of the first paragraph. :)
Ok let me illustrate an example !
client send a packet to server,and in the packet,must have a field show the
length of the packet(assume using TCP).for example the length is 20 bytes,
and a hacker change the value to 15 bytes,and send to server.
how to get rid of the BAD packet, because server dostnt know the BAD packet's
real length?
we dont just use checksum such as crc32, md5 and so on.
we can combine two encrpytion algorithms. and also we check the fields in
receiving packets , such as invalid tempID,invalid position,invalid attack strength and so on!
client send a packet to server,and in the packet,must have a field show the
length of the packet(assume using TCP).for example the length is 20 bytes,
and a hacker change the value to 15 bytes,and send to server.
how to get rid of the BAD packet, because server dostnt know the BAD packet's
real length?
we dont just use checksum such as crc32, md5 and so on.
we can combine two encrpytion algorithms. and also we check the fields in
receiving packets , such as invalid tempID,invalid position,invalid attack strength and so on!
Games like Eternal Lands will drop the socket when it encounters data that shouldn't be sent by a proper client. Since the client part of the game is open source, it is easy to just change something and send bad data and handling something that wouldn't normally (unaltered client) happen should just be disconnected.
I'd recommend logging information about it so you can analyze whether it was a hacking attempt or you programmed something wrong though. Log the user name and the data sent to the server (and maybe date/time and anything else appropriate).
ro4tub> The client shouldn't be sending things like their attack strength. That should only be sent by the server to the client.
I'd recommend logging information about it so you can analyze whether it was a hacking attempt or you programmed something wrong though. Log the user name and the data sent to the server (and maybe date/time and anything else appropriate).
ro4tub> The client shouldn't be sending things like their attack strength. That should only be sent by the server to the client.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
