Exploiting pseudo-RNGs in slot machines (2017) | Hacker News Reader

Exploiting pseudo-RNGs in slot machines (2017)

wired.com

38 pointslocalhost12 comments

Alex claims to be a Robin Hood figure, wanting to help people against an immoral industry.

His plan for that is to extort an 8-figure sum out of the machine manufacturer to disclose the exploit and help them patch their PRNG to... help them more effectively exploit the gamers?

Is there a more technical article?

Related story from an earlier time:

Planet Poker, one of the earliest online poker sites, had about the least secure shuffler one could imagine, including:

1) They used the default pRNG library that came with their Borland C++ compiler. 2) That pRNG generated only 32-bit outputs (slightly smaller than 52!) 3) They reseeded it for every shuffle, with the current system time, in milliseconds.

A former consultant eventually took advantage. With a reasonable guess for the server's system time, it was sometimes possible to identify the entire deck ordering based on one's first two cards, and almost certainly after seeing 5 cards (hole cards and flop, in holdem).

Even without source code access (as in the consultant case), 1 and 3 might have been sufficient for someone to guess their way into this exploit.

The original paper isn't loading for me, but here's a recap detailing even more problems than the above: http://www.lauradhamilton.com/random-lessons-online-poker-ex...

Does anyone know if there are binaries or even open source directories for the code on these machines? It's kind of lame that you'd likely need to buy one in order to tell if it's vulnerable to some type of attack, not to mention it's not clear how you'd even go about buying one if you wanted to.

Any purchase agreement would surely include a contract prohibiting any sort of redistribution of the binaries or reverse engineering of the machine? I wouldn’t even be surprised if that prohibition was protected by law.

It’s not, in fact, the DMCA has an exemption specifically protecting reverse engineering.

I don't understand what is so hard to get right about the RNGs of these machines. Any of-the-shelf cryptographically secure random number generator should cheaply and efficiently do the trick. Seeding? Combine the current time from the RTC with a machine specific key programmed at the factory, and/or use a hardware RNG. Linux+openSSL does the job. In fact, my i386 from the 90's could do an adequate job. That's of the top of my head, without doing any research. Using an algorithm from Knuth for these things would be completely irresponsible.

I must be missing something here, they can't be this grossly incompetent while gambling millions.

While it's not difficult to use a good RNG it's quite likely that none of these machines have been significantly updated since they were first designed and when they were first designed they probably weren't thinking about attack vectors.

The exploit isn't being able to crack incredibly well designed RNGs, the exploit is being able to crack crap RNG based machines without the casino or machine manufacturer noticing. Slot machines are a huge industry and no one thinks of them as an attack vector, so these guys can probably milk quite a bit of cash out of them without anyone ever noticing. Meanwhile the cost of fixing these machines is high - they're not going to be set up for OTA updates, so the manufacturer now has to spend probably 2 days changing the RNG, and the next 6 months delivering updates to all their customers and explaining to them that their slot machines were probably costing them several hundred thousand dollars.

Presumably the fact that they video the machine shortly before using it means that they’re relying on the fact that the hardware randomness is low. They implied that it wasn’t 100% effective, simply effective enough to make their odds better than the house’s. In cryptography, `/dev/random` is preferred to urandom since it blocks when one doesn’t have enough randomness. The machine doesn’t have randomness sourced from user input between the videoing and the attack, so all it has is relatively-low-entropy randomness (at least, within a small timeframe) such as ambient heat. I could definitely believe that this is very hard to defend against without a dedicated hardware randomness source or blocking when entropy is low.

I believe there's a huge literature on methods to generate pseudo-random numbers. Experts on HN please jump in. One approach, which I thought is quite ingenious, is to observe cosmic radiation and extract randomness from this data.

Unless I'm misunderstanding what you're saying, that wouldn't be pseudo-random; cosmic-ray arrival times are random * (in the sense that we don't have a formula for finding their arrival times).

* Unless you can figure out where cosmic rays come from and model their propagation mechanism accurately, in which case you'll solve some long-standing astrophysics questions.

I think that's not pseudo random, it's really random. There can be problems with how you sample the noise and feed it into whatever you're using.

Also, if you need random numbers there are usually better ways to get them.

http://www.robertnz.net/true_rng.html

http://www.robertnz.net/hwrng.htm

Reply on news.ycombinator.com