Flash client encryption – explained. [Part I]
Okay, since this blog is going to contain a hell of a lot of confusing stuff related to reversing stuff – I thought it’d be a nice start to explain how the current encryption routine works within the Flash client. (If you don’t understand this blog post, then you sure as hell aren’t going to understand the future ones!) I’ll do my best to explain things as simply as possible, but it’s not exactly as “simple” as some may think. Sulake have gone to great lengths to prevent the encryption being tampered with again – and with the transition to a brand new flash client who can blame them? (*cough*). Sitting comfortably? Then I may begin…
To make life simplier, I’m going to split the whole encryption process into two parts. Essentially, there are two parts to the encryption now – the Key Side and the Crypto side. The reason i’ve split the whole process into two seperate parts is purely because the Client now performs more operations to instantiate the new RC4 algorithm than it previously used to (Even when DH (Diffie Hellman Key Exchange) was first introduced within the Shockwave client! [Poorly, may I add!]) Whats Diffie Hellman Key Exchange?!? Well, i’m not really going to cover it here – but it basically means the server and client can both agree upon a key to use without previous knowledge of each other (shared secret anyone?!?). If you want to read more in-depth about it, you can visit the Wiki article HERE.
The Key side:
Sulake have really excelled themselves this time when implementing the encryption within the Flash client. As explained by Mike (Office.Boy) on the SOM placeholder page stating that it was closed, Sulake now have a new method of transferring the Diffie Hellman variables across an un-secured connection. Instead of the client grabbing a separate file (as the Shockwave client did) – it grabs a bitmap image. I know, how on earth can a bitmap image store any form of data without being visibly noticeable? Sulake have used a form of “Stenography” (Google it if you’re unsure what it is) to hide the P and G BigInteger’s which are then used to instiantate the RC4 class. Once the client has established a connection with the Habbo game server, and all handshakes have been performed appropriately – The server sends a packet which contains a unique “Hash” code (Explained later). This code is then used to grab the bitmap image containing the DYNAMIC P and G BigIntegers required to setup the encryption. The url of which the bitmap is grabbed from is:
http://www.habbo.co.uk/gamedata/banner?token=<HASH GOES HERE>
Of course, if an invalid token is specified – you just get a plain banner with no apparent data within it. However, if a valid token is provided – the server must generate a bitmap with the required P and G variables hidden within it. When analysying the image, the results of where the data is stored becomes apparent. Here are the two images next to eachother for comparison:
And thats about it when relating to the new key distribution implementation! Moving onto the Cryptology side now.. Here’s when things get even MORE interesting!
The Cryptology side:
The physical RC4 class has changed a lot since we previously remember. (Gone were the days where we could just simply setup the RC4 with the public key (@A) and encipher/decipher at will!) The current encryption still contains the functions (most) of you will probably remember:
- init(int[] key) -> Here is where the tables are setup, ready for enciphering/deciphering.
- encipher(string data) -> Here is where packets are encrypted… Although the actual flash client takes a ByteArray, you can deal with a string and perform the parsing later on
- decipher(string data) -> Same as above, except this is where packets are decrypted
- moveUp() -> Used within the encipher/decipher functions to essential “move up” the Encryption table.
- premixTable(string premixString, int count) -> Ahh, the ol’ premix that caused issues in V9 of Habbo. A given string is enciphered a given amount of times (count). The server also does this so the encryption table matches both client-side and server-side.
The only changes to the above are the way Encipher/decipher now currently work. (Everyones worst nightmare 
It was going to change sooner or later though!). Instead of using Hexadecimal, Sulake has decided to go with an alternative route known as Base64. This isn’t any odd Base64 though, it’s their own custom implementation of it – which is classed as by the RFC 2152 as UTF-7 Base64. Of course, the premix values (string and count) have changed too – but this doesn’t pose much of an issue as it’s simple to find! (Remember, premix is also not just called within init(int[] key), but after each decipher/encipher too!)
However, with the integration of base64 enciphering/deciphering, Sulake decided to implement their own custom (Hence the “UTF7″) padding! Heres the newer (and simple, yet complicated to use) functions integrated within the algorithm (not directly, but externally):
- addPad(string data, int count) -> Adds a given amount of padding to a whole packet. The initial padding doesn’t matter, aslong as it is padded a given amount of times!
- headerPad(string header) -> Adds a single char onto a header of a packet. Once again, it doesn’t matter initially what padder is used!
- iterateRandom(int seed) -> Used to generate a random number for addPad count.
Waste of resources if you ask me (padding packets so much), but I guess it’s Sulakes way of trying to confuse us! That’s the end of part I, the next post will focuse on how all this flows together step-by-step – as well as examples and demonstrations! If you have any questions or queries, or if you felt interested in this article – feel free to post within the comments! Questions, feedback and discussions are more than welcome!