🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Encrypting Packets
Author
where can i learn how?
i recently got a source code to a game the a friend wanted me to take over but everyone has the source and can edit the packets... so how do i encrypt the packets to keep hackers out
plz post pages or if u can help me directly aim me at Demonic0288
Look into the crypto api if you''re looking for a windows-only solution. Otherwise, SSL and/or OpenSSL is an option.
you could just use xor the data with a key. look for tea (tiny encryption algorithm) or a public key solution. or you could roll your own encryption. i highly siggest not using something too complex or it will kill your performence. remeber, that the hacker WILL have the encryption/decryption keys. so no matter what form you use, it is trivial to crack without using some checksumming/digest techniques as well.
why did your friend give the source to everyone? that is quite silly. you should NOT use anything too sophisticated, or you will put your firend''s game into a world of hurt.
why did your friend give the source to everyone? that is quite silly. you should NOT use anything too sophisticated, or you will put your firend''s game into a world of hurt.
Author
I heard to use CRC (Cyclic Redundancy Check)
but i have no idea what it is or where to implement it
but i have no idea what it is or where to implement it
a person is certainly right about the performance. XOR is generally fine. You can''t use classic SSL with datagram sockets anyway (and UDP is the way to go for games), since there is no connection state to alter.
You might want to calculate the used key from the packet sequence number though - and maybe from some other parameters which are negotiated on startup. Note that you can''t use IP / port numbers due to NAT servers.
Oh, and from my own experience, bit-packing is actually a highly efficient "encryption" method. It doesn''t actually involve crypto; instead, you just send all variables with exactly the number of bits you need: If there''s e.g. a flags field with 13 flags, you only send those 13 bits. That saves you at least 3 bits of packet sizes, while at the same time, it makes it _extremely_ difficult for a hacker to find out just how many bits you used. It is also a lot harder to spot common patterns: in a non-bit-packed protocol, you''ll easily find ASCII strings (like chat messages). In a bit-packed protocol, those are quite hard to spot.
Of course, the bit-packing routines will use up some performance, so it''s probably not a good idea for servers with a large number of players.
cu,
Prefect
You might want to calculate the used key from the packet sequence number though - and maybe from some other parameters which are negotiated on startup. Note that you can''t use IP / port numbers due to NAT servers.
Oh, and from my own experience, bit-packing is actually a highly efficient "encryption" method. It doesn''t actually involve crypto; instead, you just send all variables with exactly the number of bits you need: If there''s e.g. a flags field with 13 flags, you only send those 13 bits. That saves you at least 3 bits of packet sizes, while at the same time, it makes it _extremely_ difficult for a hacker to find out just how many bits you used. It is also a lot harder to spot common patterns: in a non-bit-packed protocol, you''ll easily find ASCII strings (like chat messages). In a bit-packed protocol, those are quite hard to spot.
Of course, the bit-packing routines will use up some performance, so it''s probably not a good idea for servers with a large number of players.
cu,
Prefect
http://208.225.205.249/projects/
I came up with a quick way to do some decent encyption. You''d just need to change the plain text key format to byte code which isn''t much of a stretch. You could then have the server make a new random key every hour or so and send it to the connected clients to use on the packets.
It whipped through a 50MB file in only a few seconds on a 700Mhz Duron with 1GB of ram. Using it on packets shouldn''t cause any sort of performance hit.
Ben
[The Rabbit Hole | The Labyrinth | Programming | Gang Wars | The Wall]
I came up with a quick way to do some decent encyption. You''d just need to change the plain text key format to byte code which isn''t much of a stretch. You could then have the server make a new random key every hour or so and send it to the connected clients to use on the packets.
It whipped through a 50MB file in only a few seconds on a 700Mhz Duron with 1GB of ram. Using it on packets shouldn''t cause any sort of performance hit.
Ben
[The Rabbit Hole | The Labyrinth | Programming | Gang Wars | The Wall]
quote: Original post by JonStelly
Look into the crypto api if you''re looking for a windows-only solution. Otherwise, SSL and/or OpenSSL is an option.
some algorithms in the crypto api are available on other systems
too. You''d need a different implementation but you can still exchange keys and checksums of course. So there''s no reason why you couldn''t use the crypto api for your windoze clients
KalvinB''s ideal is a good one and is very similar to what I am thinking of.
This is for an MMO*. Every player that logs in to the server will negotiate a public key from the server. This key is this session only (I''ve been thinking of changing the key on an hourly basis as well). The big problem with this is that there are several clients that receive messages from the server and each one has to go through the specific encrption for that client... which could be a drawback due to speed.
I am close to testing this and will be glad to post my results if anyone is interested.
Dave "Dak Lozar" Loeser
This is for an MMO*. Every player that logs in to the server will negotiate a public key from the server. This key is this session only (I''ve been thinking of changing the key on an hourly basis as well). The big problem with this is that there are several clients that receive messages from the server and each one has to go through the specific encrption for that client... which could be a drawback due to speed.
I am close to testing this and will be glad to post my results if anyone is interested.
Dave "Dak Lozar" Loeser
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
