Posted: Wed Aug 31, 2005 9:21 pm Post subject: Complicated Protocol
Here's an idea I came up with for how to invent a very hard-to-crack protocol.
First of all, to crack a protocol all you do is packet sniff and mimick the client you're trying to b/s the server into believing you are. That's how we have our MSN bots.
So here's the idea for how to complicate things to make it nearly impossible to crack a protocol:
The Perl module Crypt::RC4 is for making reversible encryptions using a password key. It's like Perl's crypt() function but can be reversed. Example:
Code:
use Crypt::RC4;
# Encrypt this string.
my $string = "all your base are belong to us";
my $pass = "cryptkey";
my $enc = RC4 ($pass,$string);
Before: all your base are belong to us
Encrypted: ò_6Ió╒å←Ŷ½≈7┼¡ï`+VA»e3a½≤è⌡╘"
Decrypted: all your base are belong to us
Anyhow, now that the introduction to that module is over... the protocol.
The protocol would have a common password or two, that both the server and official clients would know. The server would create its message to send (which can very well be plain text), and then encrypts its ENTIRE message before sending. The client receives the message, decrypts, makes a reply, encrypts the reply, sends the encryption back.
So over a packet sniffer all you see is a ton of garbage.
Now this is still crackable: just copy and paste all this garbage. Don't need to know how it works, just have to use it to trick the server. But wait, there's more...
To complicate the protocol, the messages can include values of time() or random numbers with them. These values will serve NO purpose is the protocol's specs, but their inclusion will dramatically change the output of the encryption.
So you might have a simple conversation like this:
Code:
Client: C_LOGIN|time()|username|password
Server: S_WELCOME|time()|Welcome username to the server!
But over a packet sniffer you'd have just long junk crap messages sent back and forth.
And so watching these interactions with a packet sniffer, on each login attempt or whatnot the junk sent to and from will look much different than the last time you checked... and this would make things more difficult to crack.
So basically the only clients that even know HOW to crack the protocol would be the official ones themselves.
Of course, no protocol is impervious to heavy duty devoted hackers. i.e. they could spend hours and hours and hours just watching these little conversations and see how they work (couldn't imagine how much of a life you'd hafta lack for that kind of a job), or they'd have to hack the official client to find out what the password is.
And then more alterations could be, the client starts with a random number from 0 to 9, then on the 7th command it goes from 10 to 19, on the 14th command from 20 to 29, and so-on, to complicate things even more.
Anyway, reply with your feedback on all this. And let's hope MSN doesn't think to complicate things in this way either. _________________ Current Site (2008) http://www.cuvou.com/
Joined: 19 Jul 2004 Posts: 556 Location: Los Angeles, CA votes: 1
Posted: Thu Sep 01, 2005 2:48 pm Post subject:
besides it still being possible to crack, the problem with yours is if it is cracked the password is sent directly, not "one way" encrypted like msn's so if someone knew the "seed", and sniffed your client, they would have your password.
All clients do this sort of thing with there auth, and it always gets broke.
I do like what yahoo did.... They included 2 different authentication methods in there clients...then one day out of nowhere swaped to the other one.
My idea for a client would be to use a "one time bit pad" and use different resources from the client for the bit-pad.... like the logo and things like that....this would make it hard to figure out what was being used...and if it periodically switched that would help as well.
User passwords would still be MD5 encrypted or whatever, something non-reversible. The reversible encryption would be the entire messages sent and received.
So for another example that doesn't include any authentication (just to avoid confusion between user passwords and encryption keys):
The client sends a request to list all the chat rooms:
Code:
C_LIST_ROOMS|1125674457
The client encrypts this entire string with the key "secret" and gets this:
«i₧U╤≡ë⌠}ä÷ÅÅ╫─♣ÿ☺E╓╖╞≤
And that encrypted junk is what's actually sent to the server.
So the server receives that line of encrypted junk, then decrypts it with the key "secret" to get the original message the client was planning on sending. So then the server creates and formats its reply:
Code:
S_ROOMS|1125674457|Lobby|Tech Support
Encrypts it with key "secret" to get:
╛iÇS═Θà┌♥·ëΘ┼╤┴♥ÿ ♫«∞æª%♀(◄ä▓J♠j╧ëp±▓
And it sends that encrypted stuff over the socket back to the client, who knows the key ("secret") to decrypt it and get once again the plaintext message the server was trying to send.
So when you look at it over a packet sniffer, all you see is:
The last bit is the MD5 encryption of the word "password", assuming this is soandso's actual password text. The client encrypts the whole message into:
«iôI╓∞¬ù♥∙ÄΩ─╥═♦£K☺ìΓ¥á/▼ Aüε♫6|î¢*Γºt↑ε.τ■╝²æ▼Å╟p▌⌐╖ù↔Ü|≈
Server receives that encryption, decrypts it again, gets the client's plaintext string, makes a reply of its own:
Server: S_LOGIN_OK|1125674831
╛i₧S┼φÿ∙}Ç╟φ┬╘└☺Ü♥J╤▓
And so-on.
Now do you understand better? _________________ Current Site (2008) http://www.cuvou.com/
User Control Panel
And let's hope MSN doesn't think to complicate things in this way either. 
