Understanding the Habbo Protocols [V1-V6, V7-R63 Pre Post-Shuffle, R63 Post-Shuffle]

    Hello, today I'm giving you a big tutorial about ALL habbo protocols.
    Thanks to Nillus for helping me through with the V5 protocol (the '#HELLO##' protocol), thanks to ItachiKM for helping me in the past, thanks to somebody from KM (I don't know maybe it was ItachiKM) for posting a tutorial about the Binary encoding, thanks to Dominic for all wise words.

    I'm starting off with the '#HELLO##' protocol, the easiest protocol because there's no encoding/decoding (well not much, just a little bit)

    I'm starting off with V1, because it's a slight different with V5.

    Starting off with the incoming messages (outgoing in DCR):

    PHP Code:
    22  VERSIONCHECK client002 
    Okay, so first of all, the first value is 22. This is the length starting on VERSIONCHECK, so it doesn't include the 2 spaces after 22. It's the length of the packet.

    Then there are 2 spaces, IDK what the reason is, but they're not important. After those 2 spaces, we get VERSIONCHECK. This is the 'name' of the packet (which is in V7+ the packet header / packet id).

    The same is with '#HELLO##'. HELLO is simply the packet header (which is in V7+ replaced by @@ - which is Base64) which is for initializing the sender on DCR. What it simply does is it starts the DCR socket to send packets. If you don't send #HELLO## (yes, WITH the #'s), you can't receive packets.

    And then we got the 'extra data' such as extra ints/strings. client002 is the extra data. Most of time, the extra data is used (like in Login for username and password, or for checking name in register)

    But every request has a response. The #HELLO## (as described above) is a response (sent to the DCR). But how does it work? You got a few types:

    A string with a starting break (chr(13))
    A string
    A string with a starting tab (chr(9))
    A int
    A raw int with starting tab/break (chr(9)/chr(13))

    PHP Code:
    #FILM 49## 
    Let's see this (this is V5 packet for camera film). It only appends a int (which is in this term a 'raw' int because the int is just used with .ToString())

    The code would be:

    PHP Code:
    base.fuseResponse.Initialize("FILM");
    base.fuseResponse.appendInt(49);
    base.sendResponse(); 
    Moving on with the V7+ protocol. From V7, Habbo has changed their encryption to Base64 and WireEncoding/VL64Encoding. Differences are:

        The packet headers are no longer names, they're codes (like @@ for ID 0, @A for ID 1 etc.)
        Integers are now sent with the Wire/VL64 Encoding (H = 0, I = 1, J = 2 etc.)
        Booleans are sent the same way as int (false = 0 = H, true = 1 = I)
        The packets are not send with #'s, but are sent with an ending chr(1) (example: SendData("@@" + (char)1);)



    First of all, the @@ (the '#HELLO##' from V1-V6) is only needed in shockwave. In flash, it's replaced by Policy-File-Request.

    Let's take this packet under the loop:

    PHP Code:
    @F35.0 
    The packet starts off with the packet header. But in incoming messages (DCR/SWF composers), it starts off with a type (@ for packets, < for policy-file-request, but only in flash), then the packet length encoded in Base64 and then the packet header. For server composers, it starts immediately with the header.

    In our case, @F is the packet header. If you use Nillus' Packet Scout, and you decode @F as Base64, you'll get 6, so the packet ID for @F is 6. (Makes sense?)

    After that, all data willl come. This is the credit composer, which will send a 'raw' string with CREDITS.0 (without any other chars) and this would be the code:

    PHP Code:
    base.fuseResponse.Initialize("@F");
    base.fuseResponse.AppendRawString(base.session.GetHabbo().coins);
    base.sendResponse(); 
    OR:

    PHP Code:
    base.fuseResponse.Initialize(6);
    base.fuseResponse.AppendRawString(base.session.GetHabbo().coins);
    base.sendResponse(); 
    In flash versions, strings with chr(9) and chr(13) are mostly removed, and it contains only strings with ending chr(2). However, shockwave still contains tabbed/breaklined strings.

    Moving on to the most-changing-versions ever, Post-Shuffle. This is with Binary encoding. People think it's the hard, but after all, it's just the default encoding for AS3 sockets!

    It uses chars/bytes. It kinda makes sense they are all chars if you show them on your console.
    The encoding is as follow:

    Int32 - 4 bytes/chars (reversed)
    Int16 - 2 bytes/chars (reversed)
    String - 2 bytes/chars as string length (reversed), then the amount of bytes/chars from string length as string
    Boolean - 1 byte/char (0/1 for false/true)

    The packet always starts off with an Int32 for the length (reversed) of packet (only exception is the policy-file-request). This is important, Habbo sometimes send 2 packets in 1, which means you need to use the length to make it all splitted.

    The next part is the packet header/ID, which is an Int16 (reversed).

    The next data is the other data, such as ints/strings etc.
    NOTE: All server composers have reversed bytes at Int32 and Int16 (EVEN at the string length).

    When using a servermessage, you need to add an Int32 at the end when you send with the length of the packet (once again.. REVERSED). You can't send any packet without length. Also, every mistake made will cause a disconnection. No extra chars are used at sending a servermessage.

    I hope I explained much. If you got questions, just ask me. I'm sorry for my bad English sometimes, I'm Dutch. If you like this tutorial, just REP me or like me (better thing: do both, I'll reward you a cookie *bakes cookies*)

    I hope I'll see you soon around!