was to locate the code for the random number generator (RNG). Alex's guess that the Japanese programmers who wrote the code for the machine might have taken shortcuts that left errors in the design of the random number generator turned out to be correct; they had.
Rewriting the Code Alex sounds proud in describing this effort. "We were programmers; we were good at what we did. We figured out how numbers in the code turn into cards on the machine and then wrote a piece of C code that would do the same thing," he said, referring to the programming language called "C."
We were motivated and we did a lot of work around the clock. I'd
say it probably took about two or three weeks to get to the point
where we really had a good grasp of exactly what was going on in
the code.
You look at it, you make some guesses, you write some new code,
burn it onto the ROM [the computer chip], put it back in the
machine, and see what happens. We would do things like write
routines that would pop hex [hexadecimal] numbers on the screen
on top of the cards. So basically get a sort of a design overview of
how the code deals the cards.
It was a combination of trial and error and top-down analysis;
the code pretty quickly started to make sense. So we understood
everything about exactly how the numbers inside the computer
turn into cards on the screen.
Our hope was that the random number generator would be rela-
tively simple. And in this case in the early 90's, it was. I did a lit-
tle research and found out it was based on something that
Donald Knuth had written about in the 60's. These guys didn't
invent any of this stuff; they just took existing research on Monte
Carlo methods and things, and put it into their code.
We figured out exactly what algorithm they were using to gener-
ate the cards; it's called a linear feedback shift register, and it was
a fairly good random number generator.
But they soon discovered the random number generator had a fatal flaw that made their task much easier. Mike explained that "it was a relatively Chapter 1 Hacking the Casinos for a Million Bucks 7
simple 32-bit RNG, so the computational complexity of cracking it was within reach, and with a few good optimizations became almost trivial."
So the numbers produced were not truly random. But Alex thinks there's a good reason why this has to be so:
If it's truly random, they can't set the odds. They can't verify
what the odds really are. Some machines gave sequential royal
flushes. They shouldn't happen at all. So the designers want to be
able to verify that they have the right statistics or they feel like they
don't have control over the game.
Another thing the designers didn't realize when they designed this
machine is that basically it's not just that they need a random
number generator. Statistically there's ten cards in each deal --
the five that show initially, and one alternate card for each of
those five that will appear if the player chooses to discard. It turns
out in these early versions of the machine, they basically took those
ten cards from ten sequential random numbers in the random
number generator.
So Alex and his partners understood that the programming instructions on this earlier-generation machine were poorly thought out. And because of these mistakes, they saw that they could write a relatively simple but elegantly clever algorithm to defeat the machine.
The trick, Alex saw, would be to start a play, see what cards showed up on the machine, and feed data into their own computer back at home identifying those cards. Their algorithm would calculate where the ran- dom generator was, and how many numbers it had to go through before it would be ready to display the sought-after hand, the royal flush.
So we're at our test machine and we run our little program and
it correctly tells us the upcoming sequence of cards. We were pretty
excited.
Alex attributes that