Script-o-matic.net

Sorry for the ridiculously late post, stuff’s been going on and I really wanted to have something to give you guys before I made another post, but that’s not going to happen just yet. So I thought i’d throw this up for you.

I’ve decided to go about the encryption another way; as oppose to waiting for Sulake to screw up with one of their obfuscations, which could take a lifetime! The new idea is to dissamble the Habbo.swf into AVM2 bytecode, modify the functions we need (decodeBitmap etc) then recompile the result back into native AVM2 code. Hopefully allowing me to use something along the lines of trace(param1); just to make sure they’re not doing anything sneaky! I’m going to be using as3c to do this. Feel free to have a look and a bit of a mess-around with it, if you get far enough you’ll notice that it wont work off the bat with static classes. That’s a rather easy fix though, however if you can’t be bothered to figure it out, just wait for the post entailing how to crack the encryption! (a detailed guide!) ;]

I also plan to release tutorials on how to inject your own .swf’s into the client, and an opensource C# Habbo applicaton. Those will probably be in the next few posts so stay tuned.

One final thing, I do have a present for Habbo emulator users. The Sandbox application that I want for the offical Habbo Hotel obviously needs to be designed and tested somewhere! So what other place than on unsecure Habbo Emulators! Here’s a version that was designed for HabboRP, it’s not complete nor do I promise that any of the features will still work. Just remember guys, because it’s open-source Aaron also has access to it, so when he patches things don’t come moaning to me. I’m not going to help you! Also this isn’t me attacking anyones retro, purely just releasing an application that’ll help people do so! You can download the binarys and source code by clicking here.

Oh, and check out http://suelake.com. It’s a great Habbo V5 emulator!

Until next time guys.

Dominic Gunn

One of two of you may have noticed that SOM has been all over the place today, and yesterday! Well i’m glad to say it’s now back on it’s feet and none of that should be happening again! There’s still a few things to sort out regarding the blog (Categories, links and what not!), but they’ll be done in time.

Regardless, hope you’re all having a great day and have got everything you wanted. I know i’ll be having fun later tonight, you should too! Merry Christmas!

Dominic Gunn

So, to my fustration I still can’t get this decodeBitmap function working correctly. It could be because of a number of reasons. These are:
1. Habbo sanitize something within the token before passing it onto the decodeBitmapString() function
2. The Bitmap is modified via an asset library before being passed onto the decodeBitmap() function
3. The position calculation within the decodeBitmap() function is incorrect

I havn’t seen any evidence of 1 and 2, so the best bet is point 3… I’ve debugged the client to a point where I know FOR CERTAIN where the initial decoding of the bitmap is – by getting an output of an error stack trace

Stay tuned, hopefully I can move onto the next stage soon – as all this “bitmap” shit is giving me a headache!

Dominic Gunn

Sorry for the lack of updates recently been busy with a few other things, but this blog isn’t about that!

The decodeBitmap() function i’m working on isn’t acting aswell as it should. I’m pretty certain that the only incorrect piece of code is this one:

pixels.position = position + channel;

That line alone is the cause of what I think is making the Sandbox give me the incorrect p&g keys. Currently the SandBox outputs:

P len is 53
G len is 51
P is 72057331058456166916582840012450119041673124206131971
G is 860860017052136081176025452969014307125978262247352

P should be almost double that length. However i’ve debugged through all the code and yeah, I’m pretty certain it’s just pixels.position that’s incorrect. The obfuscated version of it is unclear in every single habbo.swf that i’ve looked at.

Alongside that i’ve been working on injecting my own swf into the client. It’s been going pretty well I guess. The few first attempts churned out the following error from the flash client:

Warning: Ignoring 'secure' attribute in policy file from http://hotel-uk.habbo.com/crossdomain.xml.  The 'secure' attribute is only permitted in HTTPS and socket policy files.  See http://www.adobe.com/go/strict_policy_files for details.
Warning: Not a known player download type, http://images.habbo.com/c_images/hotel_view_images_hq/hotelview_dec09.png

--> attempting to inject malicious swf...

TypeError: Error #1009: Cannot access a property or method of a null object reference.
	at com.sulake.core.assets::_-4z/_-WM()
	at com.sulake.core.runtime.events::EventDispatcher/_-nd()
	at flash.events::EventDispatcher/dispatchEventFunction()
	at flash.events::EventDispatcher/dispatchEvent()
	at com.sulake.core.runtime.events::EventDispatcher/dispatchEvent()
	at com.sulake.core.utils::LibraryLoader/loadEventHandler()

The source of the problem seemed to be related to the Habbo.swf not inheriting hh_hack.swf as it should. So I decided to try an alternative root. After a few attempts I got what seems to be a successfull injection!

-->
Warning: Ignoring 'secure' attribute in policy file from http://hotel-uk.habbo.com/crossdomain.xml. The 'secure' attribute is only permitted in HTTPS and socket policy files. See http://www.adobe.com/go/strict_policy_files for details.
Found Pet Pack: dog
Found Pet Pack: cat
Found Pet Pack: croco
Found Pet Pack: terrier
Found Pet Pack: bear
Found Pet Pack: pig
Found Pet Pack: terrier
Found Pet Pack: bear
Found Pet Pack: pig
(x=0, y=0, w=66, h=22) (x=0, y=1, w=66, h=19)
(x=0, y=0, w=66, h=22) (x=0, y=1, w=66, h=19)
(x=0, y=0, w=55, h=22) (x=0, y=1, w=55, h=19)
(x=0, y=0, w=55, h=22) (x=0, y=1, w=55, h=19)
(x=0, y=0, w=88, h=22) (x=0, y=1, w=88, h=19)
(x=0, y=0, w=88, h=22) (x=0, y=1, w=88, h=19)
--> attempting to inject malicious swf...
--> Injected Successfully................
TypeError: Error #1010: A term is undefined and has no properties.
	at com.sulake.core.assets::_-4z$/_-1ld()
	at com.sulake.core.assets::_-4z/_-WM()
	at com.sulake.core.runtime.events::EventDispatcher/_-nd()
	at flash.events::EventDispatcher/dispatchEventFunction()
	at flash.events::EventDispatcher/dispatchEvent()
	at com.sulake.core.runtime.events::EventDispatcher/dispatchEvent()
	at com.sulake.core.utils::LibraryLoader/loadEventHandler()
Warning: Ignoring 'secure' attribute in policy file from http://www.habbo.co.uk/crossdomain.xml. The 'secure' attribute is only permitted in HTTPS and socket policy files. See http://www.adobe.com/go/strict_policy_files for details.

That particular error hasn’t managed to cause any actual client errors and Habbo itself still works as it should. I think I know what’s causing the error and needless to say it’s nothing to particularly worry about! Next step is to completely fix decodeBitmap(), and possibly try and call some functions through hh_hack.

Dominic Gunn

Sorry to contradict myself, in the last post I stated that the next post would talk to you about how the encryption works, with a demonstration and such. However I felt it important to tell you all that Script-o-matic is under DDoS attack. We’re not sure why or by who in particular but I thought you should all know about it, just incase we happen to go down.

On a brighter note, everything is going strong. decodeBitmap() is almost done. It’s grabbing p&g keys nicely, just need to tweak a few things to finalise it completely! Until next time.

Dominic Gunn

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!

Dominic Gunn

Just wanted to post another quick update, to tell you that updates may not be as frequent over the weekend, jam packed with things to do but i’ll work on this the best I can! Deobfuscation is going great.

I’ve looked at everyones posts regarding a forum and for now have decided to just, ignore them! There is no plans for a forum as yet!

Anyway, might as well give you an example of the deobfuscation so far, this is a snippet of the BigInteger() class!

Obfuscated:

public function _-Bl() : BigInteger
{
	;
	var _loc_1:* = (null * (( <= _loc_1) * null))._-03q();
	_-Pq._-RC(this, _loc_1);
	return _loc_1;
}

Deobfuscated:

public function negate():BigInteger
{
	var r:BigInteger = nbi();
        ZERO.subTo(this, r);
        return r;
}

Expect more in the coming days!

Dominic Gunn

Hey Guys, hope you’re all enjoying the christmas season and that your advent chocolates are being eaten (Though you should’ve only eaten four!!)

So, the reason this is now here. After some nagging at Mike he’s agreed to let me use this site to post up my discoveries in regards to Habbos encryption.

Alot of the functions haven’t changed too much since we last attempted to crack it, and so I thought I’d give it another shot. Currently i’m in the process of reverse engineering the client. Going strong, the BigInt() function is almost done, found pretty much all the RC4 Functions and i’m certain I know where the decodeBitmap() functions are. Check back later I guess!

Dominic Gunn