Dicerigging


Navigation:
The History: Dicerigging via signing
The History: Dicerigging via speedup applications
Complications: The variable used to stop signing
Complications: The new issue with speedup apps
Complications: Why we can't build a program

The History: Dicerigging via signing:
Way back when (Before 2005ish) Sulake had no protection what so ever over their dice results...
What I mean is that the server basically used a piece of code that looked similar to this (Note: This is a really crappy pseudocode example):
function pesudoRandomNumberGen()
x = Round((time(nano) / 60), 1)
  if x => 7 OR x =< 0 then
  pesudoRandomNumberGen()
  else
end function

when diceStatus.clicked = true then
resultPacket = (Header + FurniID + '/VALUE/' + pseudoRandomNumberGen())
end

This code with give out a result packet which would basically look something like this:
AZ1337/VALUE/3

What each part means:
White - Random syntaxical parts of the packet.
Red - The header (I've put the clientside one, it would, obviously need to be the serverside equivalent!)
Green - The SpriteID (A unique incrementing number for each item on the hotel)
Blue - This is the number that would show up... (Pretty sure it even showed the flashing sequence before it popped up)

Back then this was also bloody easy to do without the encryption... here's my tutorial on Scratched Dice, it should help you understand how easily it could be done with just a packetlogger/sniffer and ArtMoney.

Naturally, with the encryption it was even easier... as simple as sending a single packet!
I'm not even 100% sure if you EVEN needed to be next to the dice back then!
But yeah... around 2005 this method was patched... due to the introduction of a new variable that hides the result number until it's displayed.




The History: Dicerigging via speedup applications:
A while after the signing method was patched someone realised that speedup applications (Applications that speed up anything on the computer screen, including online games etc) allowed for the result to be viewed (pretty much) instantly!

Not only could it be viewed super fast... but Sulake also put no block on how much you could click the dice and restart the spinning!
This, of course, meant you could view five or six results in under a couple of seconds (ish)... and apart from a slight delay (That Habbo gamblers caught on about pretty quickly) it was almost undetectable...
Another issue on top of the delay... is that the onscreen chat would also be spead up to a point where it was unreadable.
So if you asked the dealer questions while the dice rolled it was quite easy (Not too easy, but quite) to tell a cheat from the length before their reply... that is if they managed to reply at all!
(Note: This was way, way before the chat-log pull down menu).




Complications: The variable used to stop the signing method:
To stop the method above (Dicerigging via signing) what Sulake did was basically to do the randomNumberGeneration AFTER the packet was sent, so instead the packet would look more like this (Note: This isn't an example of the actual packet):
AZ1337ranNumVar

A basic, but effective way of patching this method...




Complications: The issue with speedup apps:
This method was originally patched by the introduction of a pause between rolling attempts, here's my example packet with this patch added:
function pesudoRandomNumberGen()
x = Round((time(nano) / 60), 1)
  if x => 7 OR x =< 0 then
  pesudoRandomNumberGen()
  else
end function

If diceTimer > 0 then
end
else when diceStatus.clicked = true then
resultPacket = (Header + FurniID + '/VALUE/' + pseudoRandomNumberGen())
diceTimer = diceTimer + 5seconds
end

For some reason (Probably by accident) this timer has been removed in the FlashClient. This allows for a bug that's been called "Dice alting" (Where you keep clicking a dice and it then flicks through a few results instead of displaying one).

But just because they've removed the timer... doesn't mean this method has been unpatched... far from it!
They seem to now make all in-game commands stop working if you're going at a certain speed (Anything over as little as 10x starts to bugger up).

This is quite possibly to do with some of the newer Habbo server packets:
Such as the infoChecker (Header: Fe) - This new packet checks your Webbrowser and OperatingSystem details every 5seconds.
Why? Well... there's quite a few reasons they could be using this... but the one I was thinking about in regards to the speedup app. complication is:
- To make sure your OS/WebBrowser is not changing and running at its proper speed.

I know what some of you are thinking: "What in this packet has anything to do with that?"
Good question... because the answer is "Nothing"... the main thing is the time it takes for each request (5secondS)...

I haven't had a chance to see the FlashClient decrypted packets yet... but I'm assuming that the new (ish) clientside packets have something to do with it: Eb (A random packet that show up every few seconds and increments a VL64 encoded number - that proceeds the header - by one each time).
My thoughts are that this client packet is linked to the Fe server packet in some way... possibly a request or a reply to it...

It's also possible they have nothing to do with each other...
After all, it's pretty odd that the clientside version would be made so much earlier than the server equivalent!
Although, I suppose they could've been using the client one for something else and then joined them together later on...
They HAVE done this with a few other old packets.

Also... even if they aren't connected... they (or one of them) may well be why speedup applications are patched.
Because a speedup app. would speed the request/reply also (I think?) and speeding up this would give errors.
One of these errors would be due to the fact only a certain amount of packets are allowed to be sent to the client/server in a certain amount of time (This is a result of the Masstask patch and probably a netbotting vulnerability).
Another error could be that the request/reply have to happen after 4seconds or something (Seems unlikely... but it's a possibility)

Finally, after all that, I'm gona say a couple of things that will make you wana slap me:
- There's a large chance all of the above is bull crap... I'm not really sure if Sulake have done anything special to stop these types of applications.
- Everything above is irrelevant anyway... because speedup apps only mean you get to watch a longer flashing-animation now! Sulake have added something that seems to bork it very well.




Complications: Why we can't build a program:
If you've read up to this stage... and you're still thinking "Surely this means it IS possible?!" this is the part where I crush your hopes.

First, speed-apps are totally patched due to Sulake putting some bork on speeding up their client (Possibly using those packets that seemingly do nothing but work as a ticker, checking your OS/WB status and probably your ping&speed)
So that's out of the question really... can't think it'd even be possible to bypass it even if it is to do with those packets...

Second is to try and predict the outcome of the pseudo random number generator... and here's why it's not possible:

In my example I'm using a very simple nano-second divided by 60... I doubt Sulake use something anywhere near as simple...
More likely that it'll look something like this example:
function pesudoRandomNumberGen()
x = Round((time(nano)/50 MOD * 5/2))
  if x => 7 OR x =< 0 then
  pesudoRandomNumberGen()
  else
end function

when diceStatus.clicked = true then
resultPacket = (Header + FurniID + '/VALUE/' + pseudoRandomNumberGen())
end

Let's put a number into it so you can see what it does... let's say an input of 128 nano seconds:
(128/50 = 2.56 MOD = 2 * 5 = 10/2 = 5).
(((128nano-seconds/50milli-seconds)MOD)*5seconds)/2 = 5 answer on the dice is: 5.

So it'll most likely be more like that (Obviously it'll be a little more sensible).
In fact it's quite likely (For another layer) Sulake use a list of like 1000 random numbers and then use a mathematical systemclock based algorithm to make a "GOTO LINE#" statement that goes to a line and picks the number on that line...
This is kinda unneeded but it would add another level of "randomness" to it... also it means the outcome could ALWAYS be a number between 1 and 6.

Another method could be the use of a randomly generated list that they go through number by number (each dice-spin either removes the number or moves the counter on one).
The list could either be never ending or repeat after a few thousand... this would be even more impossible for us users... but it would mean (If Habbo had less active accounts) that Sulake staff/a hacker could access the file and wreak havvoc (Again, only if there was only a handful of users and none of them were using dice!).

So, if it's just using an algorithm (Quite likely that it is only doing that, the other levels of security would be easy to add... but would be kinda pointless in all honesty), you'd probably still think it was possible at this point?
I mean if we could somehow get the algorithm via a leak or via some sort of crazy reverse engineering...
Naturally reversing a number between 1-6 to find the original mathematical problem... is 110% impossible... after all if the answer was "5" there's literally an infinite amount to the power of infinite amount to the power... you get the idea...

But yeah... even if it was possible... there's one more hurdle to cross that makes it impossible... this last step is: LAG

Specifically server-lag... since obviously Sulake will use a computer clock on THEIR side of the Habbo server...
So the main input (The time) is ungettable... because not only are we not sure if their clock is exactly GMT+0 for example, and to be honest, it'll probably be a few nano-seconds out... all clocks are unless they change themselves constantly...
BUT... even if we did get the EXACT time correct... server-lag would stop us...

I don't care how fast your connection is... you still have over a nano-second of lag... which would mean your number-output would be totally different when put through the same algorithm!

The only (even slight chance) method to build this type of program would be to ping the server and work out how many nano-seconds of lag you're getting... but pinging the server takes hundreds of nano seconds!
I mean, even by the time you got your lag-result and processed it... and put it through the algorithm... the lag-time will have changed probably a few thousand times!... And that's before you even got a chance to predict the number!

Even if you built a neural-network program that could pretty much 10-20% guess the lag-result within the next second (for example)...
Which would take weeks and weeks to build and train up... also 10-20% is a pretty hopeful prediction... in all honesty it'd more likely have under 5% accuracy!

So if you spent the months it would take to build this program... your result would be a program that'd get the correct answer in about 1/20 (If you're really lucky)...
Do you remember what the odds were at the start? A dice that spins and gives a result between 1-6?... It's a 1/6 chance...
If you did build this program... you'd honestly have built a program that's more likely to lesser your chances if anything.

I hope this editorial on dicerigging will bring people to their senses...
It is NOT possible to build a dicerigger for Sulake's official HabboHotel.
- Alex (Shenk).



- Tutorial was written by Alex (Shenk.)
Any errors in this tutorial should be emailed to or reported on the ShoutBox.