This ^^
Btw, for anyone wondering, it was before the new crypto was implemented. You could configure it to work with the new one though
As far as I knew there was no way to get the new crypto?

To put a long story short, Sulake encrypted their clients public key using the RSA encryption ; from which we all know is generally a pretty secure encryption even to this day if used and implemented correctly. Now to get technical. Since the clients publickey is encrypted using RSA, we are unable to see the plaintext (the original version) of the key; meaning we'd need to decrypt it back to its original state in order to setup the encryption class for decryption. Since our form of attack when intercepting communications between the client and server was the Man In The Middle Attack (MITM Attack) - which is a well known flaw of the DH Key-Exchange, we require the ability to have access to the original client key (which is crypted) in order to generate the shared key used by both the client and server. (Don't ask how it works; it just does, read Wiki for more info).

Now, since we are unable to decrypt this key, we are unable to generate a sharedkey for the decryption instance of the encryption algorithm - thus rendering Lemon Packetlogger useless. Now, you may be asking "why can't you decrypt it if RSA is an encryption within the public domain?!?". Well, let me explain. Sulake use a 60-digit (or around 60), base16 (that's hexadecimal) BigInteger, which equals a very, very large number indeed. This is called n. This number is calculated by first choosing two prime numbers, p and q. (In Sulake's case, these must have been very large too). To calculate n, p and q are multiplied together. (p * q = n). Then, using the two prime numbers generated earlier (p and q), the totient is calculated using eulers totient function (HERE if not familiar) - which is crucial in choosing values for both the public and private key exponents. (t = (p - 1) * (q - 1)). I wont go into too much detail in how e is chosen (the public key exponent), but in Sulake's case its 3. (e = 3). This covers the public key side of the RSA encryption (and is contained within Sulake's latest Habbo client for encrypting the publickey). So, we know n and e for public key generation, and enciphering the messages (Client-side public key in this case), but in order to decrypt the client-side public key, we need to know n and d. (Where d is the private key exponent, and is meant to be kept private). In order to work out d, we need to be able to do the multiplicative inverse of e and the totient (t) - which was calculated earlier using the two primes generated to make n. In our case, we only know n and e, meaning we don't have access to t, p, q or d. But we need to calculate d in order to decrypt the clients public key!

Well, this is impossible without knowing p and q, or just simply the totient calculated from p and q (remember p and q are our prime numbers we started with!). Of course, we could try a bruteforce attack, but that would take years - since n is such a large number, meaning d will also be a very large number; and for something Sulake could change overnight, bruteforcing would take way too long. Another method of attacking would be to try and factorize n giving us p and q, allowing us to calculate the totient (t), which means we'd be able to calculate d - meaning we could decrypt the clients publickey. However, since Sulake used such a large BigInteger number, this would take too long yet again, much like bruteforcing since factorizing such a large number is extremely difficult (even for a computer). Have I bored you? Well, I'll just summarize for you: Sulake have tried many different things to prevent us breaking their encryption; unique key exchanges, time stamped banners (making them unique and one of a kind!), and complex programming and obfuscation in order to stop us in our tracks, but finally defeated us with their RSA implementation. (I don't know why they didn't do it sooner?) Sulake brought in their RSA Class (well, not theirs, part of the as3crypto package), with this class they encipher only a single packet; a public key needed for the initialization of their RC4 Class, without it; the encryption cannot work Upon delving into the client to find out what was going out, we found out that the RSA Class being used, used a public key of length of around 60 characters (that's a 60 digit hexadecimal[base16] number) was being used to initialise the encryption. We didn't think much of it at the time, until we figured out there wasn't any way plausible we could work with a number that big without dedicating weeks bruteforcing our way through that number in order to finding p & q (BigInteger primes used to calculate the final key 'n'). So that we could attack that packet with a MITM and initialise the RC4 class.