Online Games Are Written By Humans

Aug 29, 2005 gaming security suggest edit

Remember that online games are written by humans and thus are subject to the bugs and flaws that humans are so good at introducing.

This was made quite evident by an article for the current issue of 2600: The Hacker Quarterly that a former coworker of mine wrote. It’s an interesting read and I encourage you to check it out, though it is only in print on dead trees.

In this article he describes a flaw that became apparent to him within a newly released BlackJack game on the Paradise Poker website. In BlackJack, when the dealer is showing an ace, the dealer offers the players the option to purchase insurance. This is a way for the players to pay to cut their losses should the dealer have ten (10, Jack, Queen, or King) in the hole.

On this particular online game, he noticed that when the dealer did have a pocket ten, there would be a noticeable pause before he was prompted with the Insurance request. When there wasn’t a pocket ten, the prompt appeared immediately.

After doing some quick calculations, he realized this bit of information gave him an edge over the house. He ended up playing the next seven hours exploiting this bug and made a nice chunk of change during that time.

Obviously I don’t know what caused the flaw in the game, but my guess is that there was some calculation the system needed to make to determine whether or not to offer insurance. That calculation may have taken more time to perform in the situation the dealer had a ten.

Let’s pretend I am right (not a huge stretch as I am always right) and think about that for a sec. The code itself may have been completely correct in the sense that it did what it was supposed to do. It was the amount of time the code needed to execute that ended up being the tell. No different than when a poker player twitches when holding a great hand.

The fix may have been to change the execution profile of the code so that it made the same pause no matter what was in the hole. Talk about a challenge for game developers. Not only does the code need to be bug free in syntax and semantics, but they now need to worry about the execution profile for their games.

Who knows if there are several other timing flaws like this in other games. It didn’t even require my friend to hack into anything. He simply observed the timing disparity. Now imagine if he was running a timing program specifically designed to look for other timing flaws. Something that would notice discrepancies down to the millisecond.

Found a typo or mistake in the post? suggest edit

Comments

7 responses

optionsScalper • August 29th, 2005
Mr. Haacked,

This is similar in many respects to the side-channel attack in cryptology.

http://en.wikipedia.org/wiki/Side_channel_attack

The most recent high-profile side-channel attack on AES was a timing attack and my write-up is here (with links to schneier and other security guys):

http://www.jjbresearch.org/acs/blogs/optionsscalper/archive/2005/05/17/30.aspx

Schneier mentions the timing attack on SSL here (from 2003):

http://www.schneier.com/crypto-gram-0303.html

I agree with you (because you are always right; how could I argue?). This is a difficult problem, but there are many ways to deal with masking of timing. The simplest is to do the following:

1. Benchmark the implementation over a significant sample size (10,000 runs or some significant number).

2. Find the distribution of the implementaion timings.

3a. If the distribution is normal (random normal), proceed to step 4.

3b. If the distribution is not normal, determine distribution and decide whether to scale/normalize the distribution. If an alternative distribution is chosen, proceed to step 27.

4. Choose a small value (pad) within one sigma of the normal distribution and add that to the mean value of the timing.

5. Write timing code that provides for a random normal distribution within one sigma of that mean + pad (using a crypto-ready PRNG, of course).

. . .

OK, maybe it's not so simple, but it is definitely within the capabilities of most programmers.

This example will still present biased timing results (that can be hacked), but will not exhibit the basic outliers and linear timing approximations that standard algorithms provide at runtime.

As for your friend, I say exploit away. The vendor has a responsibility to make the games fair. If they don't hire competent programmers that know this kind of stuff, they deserve to have people reach into their pockets and take their money. I'm guessing that there are other available exploits at this site as well. There are plenty of observable facts that are subject to exploitation.

Now where are those Poker Bots . . .

---O
Thomas • August 29th, 2005
If its the same person I am thinking of , then his brother or friend actually discovered the flaw and excitely called whereupon this fellow spent an entire night cheating and making several thousand dollars.
Haacked • August 29th, 2005
Thomas: you are correct, it was his brother. The author merely exploited the flaw. Though whether his actions constitute "cheating" is open for debate. Is it cheating in poker to notice that an opponent scratches his head when he has a hot hand, and use that information to your advantage?

optionsScalper: Thanks for the interesting follow up. The exploit was fixed by the next morning.
Boing Boing • August 29th, 2005
Here's a fascinating account of a "side-band" attack on online Blackjack. At a certain point in the gameplay, the software dealer appeared to need substantially more calculations if there was a ten in the dealer's hole than if there wasn't. Players who timed the pause could therefore get a partial peek at the dealer's cards and so gain an edge over the house. In Poker, this is called a "tell" -- the propensity of a player with junk to mop his brow, or of a player to unconsciously tap his foot when he's bluffing. Computers are generally considered not to have tells, because they're not sentient and hence not prone to subconscious fidgeting, but computer tells do arise in those situations where they are doing something computationally intensive. The code itself may have been completely correct in the sense that it did what it was supposed to do. It was the amount of time the code needed to execute that ended up being the tell. No different than when a poker player twitches when holding a great hand. The fix may have been to change the execution profile of the code so that it made the same pause no matter what was in the hole. Talk about a challenge for game developers. Not only does the code need to be bug free in syntax and semantics, but they now need to worry about the execution profile for their games. Link (Thanks, Haaked!)...
Chris • August 29th, 2005
Can anyone confirm if this "problem" has been corrected by PartyPoker.com?

Thanks,

Chris
Haacked • August 29th, 2005
Yes, it was fixed the next day.
The Lazy Genius • August 30th, 2005
Here's a fascinating account of a "side-band" attack on online

Blackjack. At a certain point in the gameplay, the software dealer

appeared to need substantially ...