I'd like to start off by saying that I don't know a great deal about cryptography, but I'm willing to learn whatever I need to attain my goal.

My thing is that there is this custom client that uses the IRC protocol to communicate, with minor adjustments, and I'd like to reverse the protocol.. I can do that, BUT... The session starts by requesting some key then encrypting itself... Here are the details

Seems like flavor of DES since it sais so in one of the lines... but... Here are 2 full decoded sessions (IRC protocol - 2 sessions)

http://balder.prohosting.com/~fearfxf/txt1.txt
http://balder.prohosting.com/~fearfxf/txt2.txt

In adition, there are some keys that I have found in the .data section of the PE. Are these jibberish?
http://balder.prohosting.com/~fearfxf/keys.txt

Does anyone recognise any of this? Or can you tell me where I can start?

What's the target? Do you have a copy?

Requesting keys from whom?

Lines of what?

BTW, reading a dumped transcript of a protocol is like reading code. It needs to be formatted and commented if anyone is going to look at it for you.

Cool, a reply!

The target: Gamespy Arcade. Newest version. www.gamespyarcade.com.

The key is requested from the server. On line 2, client sais "CRYPT des 1 gslive" ending with 0D 0A ASCII characters. 0A usually ends an IRC command if I'm not mistaken right? I'm takind it that CRYPT des means crypt using the DES algorythim, or a variation of it... mabe... Then :s 705 -> being a custom reply from the server as I've never seen the 705 reply nor can I read about it anywhere. Probably means key from what I can understand. It is followed by a 16 ASCII character key or something, than a space, probably seperating from another key that is also 16 characters. So I see that there are 2 keys involved from the server (at least I think). The statement still isn't crpyted as it ends with 0A, a terminator, and starts with a perfectly legal IRC server reply... Now from then on, all statements are encrypted. And it shows!

So this crypting algorythim has at LEAST 2 keys, might use some of the things I fished out of the PE... If anyone needs the essential files necessary, please tell me in this thread I'm glad I got some attention

Yeah, "crypt des" sure sounds like DES. The key will be 56 bits long. I guess there'd be two ways of doing it. The first would be to send the client a DES key from the server, which would be trivial to break--just pick the key out of the transcript. That's the dumb way, and I doubt they'd use it.

Second, and more likely, is some kind of public key system. They might use the diffie hellman key agreement protocol or perhaps RSA. If it's RSA, the request would be for the server's public key; the client would respond by choosing a random session key, encrypting it with the public key and sending it back. Then all further communication would be encrypted with that key.

I think RSA is more likely than D-H because with D-H, each client would need its own private key. Do you know if any key-generation happened at any point?

The upside of all of this is that you'll certainly be able to find out what's being sent (received) because your client has to encrypt (decrypt) it. Once you find the encryption code, you can just stick a breakpoint on it and be able to look at the cleartext before it gets sent (and after the stuff from the server gets decrypted).

You know a great deal mike! Thanks for helping me out here. I posted similar things on many boards, and no one was able to even reply. I'll read up a little on RSA. The public key changes though, if you check the logs. Does that seem right? I read that DES needs a 56 bit key, dunno about RSA... Aparently 2 public keys are sent, 16 characters each (128 bits), seperated by a space. Normally, what are the standards of RSA? what is the public key length (s)? and I don't really understand how this system is more secure.... I will need to read up more on this Back to google. The trivial session key would be encrypted by the public key and then what? I mean the encryption/decryption key HAS to figgure in the transcript, or all (most) of the elements to recreate it. Is it possible? What are your thoughts on this subject?

The typical key length for RSA is on the order of 512-1024 bits. RSA works like this:

Bob wants to be able to receive encrypted messages. He chooses two large primes p and q of equal bitlength and calculates n=pq and phi(n)=(p-1)(q-1).

"phi(n) is the order of the multiplicative group in the ring of integers mod n." That means that for any number b coprime to n,

b^phi(n) = 1 mod n

and also that for any integer exponent x

b^x mod n = b^(x mod phi(n)) mod n.

Bob then chooses an encryption exponent e; usually e has a small hamming weight.

e=2^16 + 1

is a popular choice. He then calculates d=e^-1 mod phi(n). He publishes (n,e) as his public key and keeps (n,d) secret. He erases p and q.

If Alice wants to send him a message M, she computes

C=M^e mod n

and sends it to Bob. Bob computes

C^d = M^ed = M^1 = M mod n.

In the second model I described, Alice is the client and Bob is the server. Alice asks Bob for (n,e). She chooses a random 56-bit number r, computes

C=r^e mod n,

and sends it to Bob. Bob computes

r^ed mod n = r mod n

and then encrypts the rest of his traffic with r using DES.


If the server did the stupid method, it would send the key in the clear. I have no idea what two 128-bit numbers would be used for with DES or RSA or D-H. They're too small for RSA and D-H and too big for DES.

So aparently it looks like some custom encryption... I suppose that means deeply studying the assembly code

Thank you for your help, very well explained. I'll have to put this on hold for now. Mabe in a couple of months...