Forum :: Programming :: Proper Packet Protocol

Sausage posted: (1st Oct 2012, 03:14 am)

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.

Yeah, my main goal was to stop MITM. I doubt anyone would try to put the effort to crack into the packets, as seeing the amount of security our into it unless my game gets quite popular, which i doubt will happen. That seems like a good idea though.

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

Programmer, Web Developer, and Graphics Designer

Sausage posted: (1st Oct 2012, 03:14 am)

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.

That's pretty retarded. This is the same thing as encrypting graphics in the client. I bet I have a foolproof method of encrypting graphics in my client. Whenever I release it, I'll challenge you to break it. I'm sure you cbf or something stupid. Now, networking is something you probably cannot efficiently encrypt like graphics since users can have an expected outcome of the packet. This seems very vague but an example is a create account packet in EO. Sausage knew that if he typed in the username penis, then that packet will have those letters. From there, he can see the difference from p to e and see if that relative change is located anywhere in the packet. That is what I would do at least.

That is a bit harder to do with graphics, a long with the fact they're usually compressed and such.

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

Addison posted: (1st Oct 2012, 03:23 am)

Sausage posted: (1st Oct 2012, 03:14 am)

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.

That's pretty retarded. This is the same thing as encrypting graphics in the client. I bet I have a foolproof method of encrypting graphics in my client. Whenever I release it, I'll challenge you to break it. I'm sure you cbf or something stupid. Now, networking is something you probably cannot efficiently encrypt like graphics since users can have an expected outcome of the packet. This seems very vague but an example is a create account packet in EO. Sausage knew that if he typed in the username penis, then that packet will have those letters. From there, he can see the difference from p to e and see if that relative change is located anywhere in the packet. That is what I would do at least.

That is a bit harder to do with graphics, a long with the fact they're usually compressed and such.

If you offered me $100 I'd have it done for sure (the same kind of incentive you'd have to assume your attacker had). It's not hard to debug your application, find the code that draws said graphic, then trace it back to where it was loaded from and how. That's how part of the EO protocol was reverse engineered.

What's retarded is thinking you can store something on someone elses computer and think they won't have access to it, when people a lot smarter than have been trying and failing for years to keep pirates from copying their movies.

Plasmastar posted: (1st Oct 2012, 03:19 am)

GOT IT. COMPOUND ADDITION.

Example:

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

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

Ahhh took me awhile to understand. I got it now. I kinda like this idea though. I will probably end up using it.

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

Programmer, Web Developer, and Graphics Designer

Sausage posted: (1st Oct 2012, 03:27 am)

Addison posted: (1st Oct 2012, 03:23 am)

Sausage posted: (1st Oct 2012, 03:14 am)

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.

That's pretty retarded. This is the same thing as encrypting graphics in the client. I bet I have a foolproof method of encrypting graphics in my client. Whenever I release it, I'll challenge you to break it. I'm sure you cbf or something stupid. Now, networking is something you probably cannot efficiently encrypt like graphics since users can have an expected outcome of the packet. This seems very vague but an example is a create account packet in EO. Sausage knew that if he typed in the username penis, then that packet will have those letters. From there, he can see the difference from p to e and see if that relative change is located anywhere in the packet. That is what I would do at least.

That is a bit harder to do with graphics, a long with the fact they're usually compressed and such.

If you offered me $100 I'd have it done for sure (the same kind of incentive you'd have to assume your attacker had). It's not hard to debug your application, find the code that draws said graphic, then trace it back to where it was loaded from and how. That's how part of the EO protocol was reverse engineered.

What's retarded is thinking you can store something on someone elses computer and think they won't have access to it, when people a lot smarter than have been trying and failing for years to keep pirates from copying their movies.

I have checked the assembly on my application and I couldn't find what I needed to decrypt it easily. Now I'm sure if you broke it down line for line, MAYBE. I don't know what your skill level with assembly is but it's possible. I only tried it with one disassembler, so others might have more advanced technology. There's also the possibility of decompiling the application. I have never tried this but if it was successful, then yes it would be very simple.

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

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

Plasmastar posted: (1st Oct 2012, 03:19 am)

GOT IT. COMPOUND ADDITION.

Example:

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

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

Ahhh took me awhile to understand. I got it now. I kinda like this idea though. I will probably end up using it.

Hey, I edited the post, but you might consider using this routine twice and/or once with the string reversed.

---
Wish upon a star!

Is there even a point anymore? You've just told the entire world how you're going to try obfuscating your packets...

Sausage posted: (1st Oct 2012, 03:38 am)

Is there even a point anymore? You've just told the entire world how you're going to try obfuscating your packets...

Point out the obvious.

A good encryption requires multiple routines, in particular order anyways.

---
Wish upon a star!

Plasmastar posted: (1st Oct 2012, 03:39 am)

Sausage posted: (1st Oct 2012, 03:38 am)

Is there even a point anymore? You've just told the entire world how you're going to try obfuscating your packets...

Point out the obvious.

A good encryption requires multiple routines, in particular order anyways.

This^ and its not going to be implemented exactly as has been said here.

I think the goal of this thread has been accomplished :D

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

Programmer, Web Developer, and Graphics Designer

Don't encrypt your packets. I agree with Saus, just make it so it doesn't matter if people do edit your packets.

---
Love you too.

newguy posted: (1st Oct 2012, 03:52 am)

Don't encrypt your packets. I agree with Saus, just make it so it doesn't matter if people do edit your packets.

Yeah give up and take it in the ass like a bitch.
That's all I'm hearing.
You're never going to have a foolproof method but you can at least put some encryption to stop some people. Otherwise it's just too easy and that many more people will do it.

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

Please stop using the term "encryption", which might imply any kind of security at all. You are just talking about obscure encoding methods.

http://danielmiessler.com/study/encoding_vs_encryption/

So maybe it's an encode...but it's being used to keep the encryption key SLIGHTLY secret. I dunno.

---
Wish upon a star!

Plasmastar posted: (1st Oct 2012, 04:45 am)

http://danielmiessler.com/study/encoding_vs_encryption/

So maybe it's an encode...but it's being used to keep the encryption key SLIGHTLY secret. I dunno.

Okay, so let's just call it very bad encryption, because these kinds of algorithms a highschooler jots in the back of his notebook when his bored couldn't keep anything secure or confidential (a goal which is, of course, impossible in the context of trying to keep users in the dark about what's happening on their PCs anyway).

I'd rather just see it as artificially imposed encoding for the purposes of being obscure and wasting CPU cycles, making sure someone has to find the method of encoding you used to be "compatible" with you, and send their own communications.

Sausage is right, though. It's stored on someone else's computer. Although, securing more with "encryption" is still a good idea as it would just make them take longer.