Forum :: Programming :: Proper Packet Protocol

So I've decided to start working on my games packet protocol with my improved knowledge of since the last time I've worked on my game. Right now I've set up a basic packet class and here's what im thinking about doing with it:

The first packet sent/recieved will be raw containing a server validation hash and an encrypted key. The key will be decrypted and used to encrypt/decrypt that clients packets.

Every packet will consist of the checksum, packet family, and packet action, and then the data. The checksum will be used to validate packets and tell if they are malformed. The family and action obviously gets sent to the packethandler class and executes that delegate.

 

Obviously I have been learning a lot of Not-To-Do's from the EO packet protocol and was wondering if there is anything else I can do to get farther away from it?

Does this seem secure and what can I do to add on?

 

 

---
Andrewbob - I would be on the fucking copter of rofls

Programmer, Web Developer, and Graphics Designer

You're heading in the right direction. That's how most encrypted connections start out, with the first packet. I have a design for an encrypted connection, and research shows, your first packet DOESN'T have to be unencrypted, but is probably going to be reversible anyways.

I highly recommend throwing out the checksum, as this is wasted bandwidth over time. Instead, go with length bytes, and a sequence byte, similar to EO, but better designed... Use an encryption routine that makes each byte at least partly dependent on each other. Here's an example.

1 2 3 4

 + + +

3 5 7 5

Where the last byte is added by the first. Subtract in reverse to decrypt. If a byte is modified, it should eventually break this portion of a good encryption (if you add/subtract right), and eventually give you a bad sequence byte, assuming you use length bytes and read packets properly.

Sorry if I can't explain that better, it works better in my head.

Edit: LET ME THROW THIS OUT. Your sequence byte (and it's increment, if you choose to do it this way), can also be in the first packet, along with your encryption key, and causes your server/clients to have different sequence patterns. Example: Sequence Byte, Increment. 1, 2 -> 1 3 5 | 2, 4 -> 2 6 10

This, along with that byte dependent encryption I mentioned, makes packet replay (attacks), MUCH more difficult.

---
Wish upon a star!

Plasmastar posted: (1st Oct 2012, 02:23 am)

You're heading in the right direction. That's how most encrypted connections start out, with the first packet. I have a design for an encrypted connection, and research shows, your first packet DOESN'T have to be unencrypted, but is probably going to be reversible anyways.

I highly recommend throwing out the checksum, as this is wasted bandwidth over time. Instead, go with length bytes, and a sequence byte, similar to EO, but better designed... Use an encryption routine that makes each byte at least partly dependent on each other. Here's an example.

1 2 3 4

 + + +

3 5 7 5

Where the last byte is added by the first. Subtract in reverse to decrypt. If a byte is modified, it should eventually break this portion of a good encryption (if you add/subtract right), and eventually give you a bad sequence byte, assuming you use length bytes and read packets properly.

Sorry if I can't explain that better, it works better in my head.

Oh that sounds so much better then using a checksum. I can also throw out the whole CRC32 hasher class. 

I get what your saying though. If it's malformed the sequence value will be read incorrectly and then won't match up with the server. Then Hello_Hax0r

 

Edit: So for the raw packet it'll provide an increment for the what the sequence value increases by as each packet is sent? That's a pretty good idea! :O

---
Andrewbob - I would be on the fucking copter of rofls

Programmer, Web Developer, and Graphics Designer

I personally would use an old fashioned keycode encryption along with the byte dependent one (EVEN ON THE FIRST PACKET), to make things a little harder for people. Example: A -> Z, B -> Y, C -> X

But you can go one step further and build that keycode list during the entire session, by using a pattern of your choice. Example: First packet consists of DEADBEEFCAFE, keycode list is now DEABFC, etc etc etc.

Edit: Yup...except that literally none of the packets need to be "raw", if you use non-initiated encryptions. Only thing I'd leave "raw" is, file transfers, but that's only because they're so big...but hey, if you're a paranoia freak, go for it.

---
Wish upon a star!

Plasmastar posted: (1st Oct 2012, 02:38 am)

I personally would use an old fashioned keycode encryption along with the byte dependent one (EVEN ON THE FIRST PACKET), to make things a little harder for people. Example: A -> Z, B -> Y, C -> X

But you can go one step further and build that keycode list during the entire session, by using a pattern of your choice. Example: First packet consists of DEADBEEFCAFE, keycode list is now DEABFC, etc etc etc.

Edit: Yup...except that literally none of the packets need to be "raw", if you use non-initiated encryptions. Only thing I'd leave "raw" is, file transfers, but that's only because they're so big...but hey, if you're a paranoia freak, go for it.

Yeah, the only reason I have the first one raw tho, its not really "raw" because it consists of a validation hash and a key independent encrypted key, is to initialize the client for encrypting/decrypting using that key.

Then it will just contain some simple details required for the initialization.

Also, didn't really understand the deadbeefcafe keycode thing

---
Andrewbob - I would be on the fucking copter of rofls

Programmer, Web Developer, and Graphics Designer

Plasmastar, I don't follow decrypting your method. Can you please explain and give an example?

Yeahhh, I'm going to call bullshit on that encryption method. Show me mathematically.

x y z w

Encrypted:

x+y y+z z+w w+x

Show me how you can get x, y, z, w with it encrypted?

---
http://www.addipop.com

Addison posted: (1st Oct 2012, 02:47 am)

Plasmastar, I don't follow decrypting your method. Can you please explain and give an example?

Yeahhh, I'm going to call bullshit on that encryption method. Show me mathematically.

x y z w

Encrypted:

x+y y+z z+w w+x

Show me how you can get x, y, z, w with it encrypted?

O.o I didn't even think of that. How is that going to be decrypted?

---
Andrewbob - I would be on the fucking copter of rofls

Programmer, Web Developer, and Graphics Designer

Just to add to the topic. The way EO encrypts its packets is actually pretty good. Fuck, it took Sausage a long time to figure it out and it is crazy how he did do it. I doubt there is any way to perfect it 100% but EO did do a good job at it.

---
http://www.addipop.com

Addison posted: (1st Oct 2012, 02:47 am)

Plasmastar, I don't follow decrypting your method. Can you please explain and give an example?

Yeahhh, I'm going to call bullshit on that encryption method. Show me mathematically.

x y z w

Encrypted:

x+y y+z z+w w+x

Show me how you can get x, y, z, w with it encrypted?

Sorry, it's been a long time since I designed this technique. You may have to do compound addition... Thanks for pointing out the miscalculation there.
I did something to get it to work... give me a few minutes to rework it.

Edit: Very sorry...I really did have this technique down, I can't remember the formulas, and the source for it is on my old desktops...

There really is byte dependent encryption algorithms though.

---
Wish upon a star!

I also remember Sordie saying she did something with Kalandra 2 to make her packets immune to WPE or something like that. Any ideas on that?

---
Andrewbob - I would be on the fucking copter of rofls

Programmer, Web Developer, and Graphics Designer

Wildsurvival posted: (1st Oct 2012, 03:05 am)

I also remember Sordie saying she did something with Kalandra 2 to make her packets immune to WPE or something like that. Any ideas on that?

I assume something similar...

---
Wish upon a star!

Found it. "KalandraII uses hopping key encryption and a CRC32 signature/digest of the packet. This is totally breakable (as all communications are) but at least stop WPE and other generic packet/proxies from functioning"

---
Andrewbob - I would be on the fucking copter of rofls

Programmer, Web Developer, and Graphics Designer

That's one way of doing it. EO has the sequence byte which stops it as well. I would go with the sequence byte myself since it can be 1 byte while CRC32 has to be 4bytes.

Plasmastar: I decided to try and find a method to incorporate your method. I realized it's dumb because if you add multiple bytes together, you have to increase the maximum size by that many bytes. Which would require splitting it into 3 separate bytes to send across the socket. So redundant shit is redundant.

I haven't gave much thought to encryption methods. Sequence byte + packet length + packet and then encrypt it very well should stop WPE and most retards. Of course, if someone breaks the encryption and creates a server emulator and releases it as open source, then your game is pretty much stolen :P

---
http://www.addipop.com

Don't bother doing anything at all, unless you really want to rely on obscurity to protect... whatever it is you're trying to protect by not letting people understand packets, which of course, will be inevitably broken by anyone who tries hard enough.

All you need is a fixed-size length to frame packets, and put the rest of your effort in to making sure people can't gain any benefit by seeing or manipulating packets. If your goal is to stop MITM snooping, use a key derivation function based on the user's credentials to generate a keypair and use TLS, which will just as easily stop anyone novice enough to not break your "super secret add 27 to every byte and send them in reverse" style encoding.

GOT IT. COMPOUND ADDITION.

Formula: Variables a b c d e |  a+e, b+(a+e), c+(b+(a+e)), d+(c+(b+(a+e))), e+(d+(c+(b+(a+e)))) Simplify as needed bitches.

Example:

a b c   d   e
1 2 3   4   5
6 8 11 15 20

20 - 15 = 5 | 15 - 11 = 4 | 11 - 8 = 3 | 8 - 6 = 2 | 6 - 5 = 1

Edited for clarity...also, I missed a variable in a formula.

---
Wish upon a star!