// Gossip, Industry, News

How would you do playing against Mike Postle? Check out this NEW QUIZ to find out! How to Beat Mike Postle QUIZ: https://pokercoaching.com/poker-quizzes/how. Which simply pre-fills the player table with some players and also enables God Mode. God Mode lets you see the other players' cards as well as act on behalf of them, perfect for experimenting as well as making further changes to this doc.

There’s widespread disappointment today in the poker world following yesterday’s approval by the Nevada Gaming Commission of former UltimateBet fraud firm iovation as a service provider for online geolocation service, despite the historical nature of the UltimateBet cheating scandal and the infamous “God Mode” cheating tool. We’ll do a complete story in a bit, but rest easy, readers, and understand that the fix was in. Anger alone won’t rectify the situation. Only exposure can do that.

So, a special treat today, for our readers: A heretofore unpublished excerpt of a lengthy deposition-style interview I did with early ielogic programmer Jack Bates, who was there when the orders to the programming staff to program the used-for-cheating tool came done through iovation’s (then known as ieLogic) hierarchy.

Bates himself did not program the cheating tool, though he was publicly, falsely accused of doing so in a malicious lawsuit filed a few years back. Both the original cheating tool and the ongoing upkeep to make it work were always done in Portland by ieLogic/iovation staffers. A programmer named Brian Russ was the original coder tasked with creating it, and another programmer named Todd Bartleson was tasked with doing the necessary updates to keep the thing running, as shown in an e-mail published earlier this week.

Now, I’d like to make one thing perfectly clear: I gave the complete transcript of this interview to the Nevada Gaming Commission three months ago. Not only does it show the genesis of the cheating tool, it shows that UltimateBet was absolutely, incontrovertible being operated from Portland, not Toronto.

So, everyone, enjoy. I have done some minor stripping of irrelevant commentary, since we conducted the interview as an ongoing dialogue:

. . .

Haley Hintze: [] What everyone is going to focus on, to know about, is the creation of the “God Mode” program, which was later asserted to be the method by which certain UB insiders cheated other players. Let me start this off with a precursor question: Was there an earlier form of God Mode, an auditing program and/or developmental tool that was not a live tool, or that existed with a delay?

Jack Bates: My answer to that is no, not that I’m aware of. Now, I feel that I was aware of everything. That said, let’s go over – okay, let’s go over the creation of what should be referred to as the “Stealth Observer” mode. That’s what we’re talking about here, this God Mode client. Before that, there was, on the server itself – which, access to those servers was strictly controlled – the ability for an admin to look at log files, and/or look at things that were logged into the MySQL database for a live hand.

I don’t think there was a tool, per se; I’m not aware of a tool having existed prior to the stealth observer feature, other than I and three other people I’m aware of were authorized to log in to the server. On that server you could see the live action, in a manner that you could see hole cards.

HH: Okay, so it wasn’t encoded in a way to protect it from prying eyes.

JB: Well, there were only four sets of eyes that could get in there.

HH: Who were the other three? [Note: Bates himself was one of the four.]

JB: Daniel [Cunningham, the company’s lead engineer and software designer], [Chief Technical Officer] Jason DeHaan and Brian Russ. [Later, Bates realized that a fifth programmer, Scott Kirkowski, likely also had access.] Now, that said, Brian Russ hated getting onto the production system, and was kind of scared to be there for fear of – he was not the most capable UNIX/LINUX sys-admin kind of guy. He was not on there frequently at all. Now, Daniel and Jason – let me kind of describe what they did there.

Daniel was in charge of basically all the operations. What I mean by that is, for example, tonight $1/$2 limit hold’em is hot, and we don’t have any open seats. So, we made sure there’s another table running. That literally involved, in the early days, getting onto the system and starting a table up.

HH: That had to be manually done, okay.

JB: Anything of that nature, anything that was kind of real-time admin, Daniel and Jason did that. Jason was the backup. Daniel was the primary – I don’t know, they shared duties in shifts and stuff, I don’t know. They were the two guys who knew enough, to do, you know, who knew the system in and out in the production world. Besides myself (chuckles).

HH: Now, let’s talk about this meeting where the stealth observer tool was proposed. Why don’t you just take it from the top and describe what happened that day.

JB: Okay, well, let me give you a little bit of background. We had fairly regular engineering meetings. The typical attendance on this meeting: It would be led by Jason DeHaan, I would be there, Brian would be there, John Salyer would be there, Todd [Bartleson] would be there, Jim Hendrie (our quality assurance guy) would be there, and that was generally it. These were regular meetings, where we talked about the development plan, status, deadlines, all that kind of crap.

Now, this particular meeting you’re asking about, it was actually quite frequent that Jason would not be there; he would call in from Chicago and he’d be on a Polycom conference phone. It was kind of like Charlie’s Angels. I cannot remember, and I’ve kind of been wracking my brain for a couple of days about this, whether he was actually present in Portland or over the phone for this, this particular meeting. A bunch of new features for our next big push were being discussed and that one came up, and I and several other people voiced an objection to that [the creation of the stealth observer]. I remember in particular John Salyer saying something to the effect that “No good can come from that.”

I might have said – I’m more of an asshole, okay – I might have said something like, “All the security work I’ve done, and you want to do that?” I might have been that incensed about the idea. In the meeting itself, it was clearly communicated by engineering staff to Jason that we really didn’t want to do this.

HH: Within this discussion that was going on, what the reason given for doing it?

JB: Sure. I vaguely – no, not vaguely – I clearly remember Jason saying that Russ wanted this feature because he believed there were cheaters. Those probably weren’t the exact words, but that was the sentiment. That’s what was expressed there. We’d just gotten over, gotten past, got on our feet after a huge credit-card fraud problem. I forget to mention that earlier; my other job was implementing the early versions of ieSnare.

HH: Which we would’ve gotten to anyhow…

JB: Yeah. So, that didn’t really matter to management that we thought it was a bad idea. [] Clearly this is a security problem. The places in the code on the server where this actually required modifications were not really in my world, and I probably wouldn’t have done the work anyway. Brian did that work, to implement the tool. [] Just as a quick aside, Brian had nothing to do with any cheating.

[] There are two parts to the tool, essentially. One part was on the server side; the other part was – speaking technically here – a compile-time modification of the client, such that in order to build the stealth observer client required a separate build to be performed with a digital studio, which is what they were using for all the client work.

So, how did all this work? On the server side, and by the way, I didn’t even look at this until I close to walking out the door – (chuckles) – to me it just felt bad to even look at it. There was a database table in the system that contained a list of users who were allowed stealth-observer admin privilege. In addition to that, if they had that privilege, whenever a deal was done, that stealth observer could see all the hole cards at the table. That stealth observer couldn’t play in the game, but I’ll get back to that.

The other half of this was on the client side. Until I read about this stuff on the internet recently about a guy who had essentially decompiled or disassembled the client and looked at what was going on in there, I didn’t know jack about how it worked. I didn’t know that beyond just having a user name and password, that was in that table on the server, an additional layer or something – as it turned out, there needed to be a registry tree.

HH: How do you think, just as an aside here, how do you think that the registry keys which appear to be linked to the stealth observer ended up in standard builds of the client software?

JB: That’s a good question. I know that on the client side you could not activate the stealth-observer feature from a non-stealth-observer client. I know that from reading some stuff on the internet and having some discussions with the client guys. That discussion occurred, obviously, after the news broke.

HH: Even if you had these registry keys in your software, you would not have been able to use stealth mode, simply because your screen name and password would not have been part of this separate database maintained at the home office. Correct?

JB: Here’s how I think it worked. Inside the client, you had to have the ability to parse and display the message that contained the hole cards for everyone at the table. It was a special message. I think that was the part that was additionally compiled, as I said earlier.

HH: Now, in the original version of this, did this have a delay that was attached to it?

JB: No. I think that two different features might be getting confused here. There was a promotion we did where well-known poker celebrities would play heads-up.

HH: Ah, yes.

JB: There was, I believe, a five-minute lag on the data feed to people who wanted to watch that game. That was implemented as a server feature, and Brian implemented that as well. Anything involving game play itself, that was kind of his world. This was some sort of a promotion we had, where Phil Hellmuth played some other favorite guy, and you can see the hole cards on a five-minute delay.

HH: Got it, got it.

JB: It was only heads-up, you know. Heads-up hands never last five minutes, so that was a security mechanism so that those guys couldn’t cheat on each other.

HH: That makes sense. Going back to the meeting, do you remember an approximate date when this meeting occurred?

JB: I’ve been thinking about it, and it was shortly after we moved into Big Pink, which is the name of an office building in Portland, where I believe iovation is still quartered. If I had to guess, I would say it was early 2003, so maybe January or February. I’m not really sure. It was shortly after that; the meeting that occurred was in the conference room in that building, which my office was right next to. The initial release of that feature was probably a month or six weeks after that. I don’t know – that was our basic “push” cycle.

HH: Okay. I believe the final KGC report listed a date of May, 2003 for when they believe the hole-card cheating started. Does that fall in with the same general timeline that you remember?

JB: That’s plausible. I certainly couldn’t refute that. My memory’s not good enough.

HH: [] Moving down the list here of questions, you mentioned the screen names that had access to stealth mode being stored in a small database?

JB: Yes.

HH: Who would have had access to that, specifically? I just want to clarify that.

JB: Okay, that was a database on the production cluster, so the same four people: Myself, Jason DeHaan, Daniel Cunningham and Brian Russ. [We] would have been able to manipulate that table.

HH: But you never actually did any work with that, correct?

JB: I never even looked at that.

HH: Right. I just wanted to get that on the record for you here. Let’s see here….

JB: In fact, I didn’t even know how it worked until shortly before my departure.

HH: Okay. What I did here, I’ve just pulled some of the names from the programming core here, and I wanted to ask if you knew of any connection they had to God Mode. You’ve already talked about Brian a little bit. Can you think of anything else he might have programmed, in terms of the God Mode stuff? The stealth observer, as you prefer to refer to it as?

JB: He implemented the entire feature on the server side. I would guess that Whitney [Arnold] didn’t have anything to do with it. When that feature was installed on the server, the way that it worked was that Daniel did all of our upgrades, so a SQL update script would be run. The way this worked was, I’m sure, there was a script that created the table, and possibly also drop some usernames into that table, though I’ve never seen that script. It was fairly easy, also, to just drop a username into the table using, directly, the MySQL access monitor program. You could just write an SQL statement and have it do anything you wish.

HH: Now, the client and the registry keys and all that had to be updated with each new version of the software, and distributed to people that were in the know? Is that an accurate depiction of how you believe this happened?

JB: Yes. That is correct. Now, the reason for that is, as I said, the thing was conditionally compiled. Now, part of the protocol that occurred, when the client attached to the server, is that the server would advertise a version number, a minimum version number of the client that was required. That was because we might have made a change to the messaging structure. So, upon initial contact, the server would say, “You need to be at least version 2.5” or whatever. If the client was not that version, there was coding found in the client to go and download the upgrade.

The reason that the stealth mode client would have to occasionally be updated was exactly that. If the messaging format had changed, an old stealth mode client wouldn’t connect any more. It’s come to light that the distribution of that stealth mode client was made via e-mail.

HH: Yes it has. And I guess that brings me to the next name on my list: Todd Bartleson. Did Todd have any connection to the stealth observer program? Distributing it, or compiling the numerous files.

JB: I’m sure he and John both worked on it. Todd was a little bit more of a junior guy, so anything he did, he didn’t report to John, but John would review it. John — (chuckles) — was a particularly particular kind of guy. That whole client was his baby, and he really kind of made sure that there was no stupid in there. Except for this, of course. (laughs)

HH: From what I’ve been told, Todd didn’t really understand the ramifications of a lot of this.

JB: A lot of us were not poker players before we got a job there. In fact, I fall into that category, and so, there was certainly some naivety about “What does this really mean?” I think that some of the folks there are victims of that.

HH: Recently a letter has surfaced, via an assistant to Russ Hamilton named Travis Makar, that showed some blacked-out names. Is Todd Bartleson’s name one of those that’s blacked out?

JB: In a discussion I had with Todd, he told me that he was the author of that e-mail. Now, to be clear, that e-mail contained an attachment which was an update to the stealth-mode observer client.

HH: Yes.

JB: Okay; we’re talking about the same e-mail.

HH: Correct; same e-mail. There were two or three names in there that were blacked out. Did he mention the names of the other parties?

JB: Ahh, he kind of mentioned it to me in passing, saying, well, “Now there’s an e-mail that I sent out there,” something of that nature. Now, in other discussions I’ve had, I know that Russ Hamilton was one of the people who got that update. Or at least that’s what was conveyed to me. I don’t know if he was on that particular “To:” list.

HH: The one I’m thinking of – and I don’t want to lead you to anything here, but there was pretty strong visual evidence that Mansour was one of the recipients of the letter, based on the spacing and the partial blockage but not complete blockage of one of the names. But you don’t know if Todd would’ve said…

JB: You know, I heard Mansour’s name a bunch of times while I worked there, but I don’t know anything about that guy. [] But let me tell you what I do know about Mansour. As far as the development of desired features for the system, the flow of that to me, it was always Jason saying, “Russ wants something,” or Jason saying, “Mansour wants something.” Yes, I actually did meet and I have spent a little bit of time with Russ, but I’ve never met and don’t really know anything about Mansour. Take that for what it’s worth. (chuckles)

…

We’ll continue in another piece with more excerpts from this interview, regarding various aspects of UltimateBet, the “God Mode” cheating tool, and iovation’s corrupted business and technical practices.

COMMENTS

Leave a Comment

LATEST NEWS

filter by

Dan Katz

29th February 2020 // Uncategorised

Is the Coronavirus a Threat to the 2020 WSOP?

This has been one hell of a week. The coronavirus (COVID-19) is picking up steam globally. World financial markets have...

Dan Katz

26th February 2020 // Uncategorised

Side Bets Available at PokerStars Poker Tables

Poker is gambling. We like to say that it is a game of skill – and it is – but it is also gambling. And that’s...

Dan Katz

17th February 2020 // News, Online Poker Action, Poker Tournaments

World Series of Poker Expands Online Bracelet Schedule to 14 Events

On Thursday, the World Series of Poker released the schedule for this summer’s online bracelet events, to be hosted...

Dan Katz

8th February 2020 // Gossip, News, Online Poker Action

Phil Galfond Down €750,000 to VeniVidi1993 in Galfond Challenge

Look, I don’t typically make a habit of feeling bad when people of means lose money, but oh man, I am starting to get...

Dan Katz

2nd February 2020 // News, Online Poker Action

PokerStars, partypoker Launching Dueling Bounty Tourney Series on Super Bowl Sunday

The year 2020 is already one-twelfth gone. It seems like just yesterday that Larry David was arguing that it was too...

Haley Hintze

31st January 2020 // Misc, News, Poker Tournaments

Coronavirus Outbreak Forces Postponement of Triton Jeju Series

The Triton Super High Roller Series scheduled for mid-Februry in Jeju, South Korea has become the first poker event...

TOP POKER SITES

• PokerStars
• $600

• 888 Poker
• $400

• William Hill
• £1,200

• Betsafe Poker
• $1,000

• Bet-at-Home
• €1,500

• Guts Poker
• $/€/£300

view all

POKER IN YOUR COUNTRY

• US POKER SITES
• CANADIAN POKER SITES
• UK POKER SITES
• EUROPEAN POKER SITES
• SOUTH AFRICAN POKER SITES

DEVICE COMPATIBILITY

Mobile Poker Sites

Linux Poker

Android Poker Sites

Mac Poker

GUIDES

Deposit Methods

Poker Networks

SPORTS BETTING GUIDE

'He had the calm confidence of a Christian with four aces.'
-- Mark Twain
Getting to the final table of a tournament that began with a decent amount of entries is always an accomplishment. Most people need to run significantly luckier than average to accomplish it -- especially in No Limit Hold'em where winning numerous coin flips for all your chips is a necessity. On the other hand, highly skilled players don't need to get lucky to make a final table, but they do need to avoid running significantly unlucky.
So a typical final table may have one or more highly skilled players who got there despite running below average in luck during the tournament, but most of the final table players, including most highly skilled ones, will have been among the luckiest (say at least the luckiest 20%) to that point in the event.
The logical and strategic implications of this 'table full of luckboxes' reality deserves far more attention than it gets.
For a highly skilled player, playing at a table full of people who have been running good is normally heavenly. Whim players, non-mathematical players, players without a strategic overview to their tournament play adopted before the cards have been dealt... when these types of players run good, they think they can dodge bullets. They think the law of averages and laws of physics are meant for mere mortals, not them.
In short... they think they will 'get there' in whatever hands they play. If they have been making flushes, they think they make this flush draw. If their bluffs have been working (because they are soooo clever in picking their spots), they will think this next bluff will work.
Watching the replay of a Stud High-Low tournament the other day, on fifth street a player with four to a low and four to a flush capped the betting against an opponent with an open pair of Aces. The low/flush-draw player was the chipleader, and was being assaulted by the deck over and over... making scooping hands, escaping with half when his opponent had a monster to win the other half, etc. Putting in the last raise with this low/flush-draw hand on fifth street against a player who might already have a full house was nonsensical, but through the computer screen you could just feel that this player knew he was going to get there.
Simulating the two hands shows the Aces would scoop about 20% more than the low/flush-draw player, but the equity was only about 10% different. Still, it's not the bad play that is the point here. The point is the player was playing bad because he had been running so good.
This factor should get a lot more attention in poker reporting than it does. Often times a hand will get reported that doesn't seem to make sense, but suddenly does make sense if you understand one (or both) of the players have been running as if the hand of God is holding their cards. This 'running like god' (or 'running like god-mode') explains a great deal of the blowups we see at final tables (or very deep in tournaments).
Poker is about adapting, but it's a poor plan to adopt a line of play based on the assumption you will get lucky. Many final tables feature a player crashing and burning in about sixth place who has been the chipleader for hours or days. These players will lose, and lose rather quickly, because the horseshoe finally falls out.
Playing against opponents who have been running good all day/week is to be playing against false confidence due to always 'getting there' or having the deck bail them out. They should generally be your #1 target at a final table.
Simultaneously, an opposite phenomenon often plays out at final tables. Sometimes very tight players will make the final table who play great starting hands well and make few mistakes. But these players have their own Achilles heel at a final table as play gets shorter.
A great example of this was an Omaha High-Low final table, down to three players. By far the tightest player that started the final table was in the small blind, and by far the loosest was in the big blind. The tight player limped with 8643. The loose player checked the big blind with KJ63. The flop comes 764.

Poker God Model

The tight player flops two pair with an 83 low and... checks. The loose player flops middle pair with a King kicker, and a one card low draw and bets. The tight player folds.
An extensive article could be written just about this one hand, but the tight player's inability to adapt, inability to know that when the loose player didn't raise him pre-flop meant that he had a horrible hand, and the loose player's ability to risk a single bet here to win two bets reflect both of the principles above...
1) the loose player bet his weak hand in part because he had been winning over half the pots all day
2) the tight player had been playing good starting cards all day, cards that he knew how to play well post-flop. But now when he played unfamiliar garbage cards, he didn't know what to do with them! He didn't adapt, in part because he had not needed to adapt earlier in the tournament.
If instead of folding, the tight player would have checkraised the loose player, he would have won the three bets in the pot, or at least have been near-freerolling the loose player.
If you are a very tight player, and 99.99% of your poker playing involves not playing weak, random cards, then why when short-handed at the end of tournaments where big prize money is at stake do you suddenly start playing bad cards (for a limp bet that allows your opponent to play for free)? Don't put yourself in unfamiliar, uncomfortable territory when you don't have to.
While both the majority of loose players and the majority of very tight players will make final tables because of luck, and while both those types will have made many very good hands relative to the amount of hands they've played, as play gets shorter, the advantage goes to the loose/lucky players over the tight/lucky players. Bad players in the habit of playing bad cards have an edge at the end of tournaments over tight players incapable of adapting to having to play mediocre cards. Besides making hands, too loose players in god-mode will win lots of pots by betting and getting opponents to fold. Too-tight players need the rarer combo of 1) getting more than their fair share of good starting cards, and then also 2) having those good hands win.
'Tight is right' is the correct attitude for getting the money in all forms of poker, but 'tight' 9-handed is different than tight 6-handed, which is different than tight playing head-up. 'Tight' is relative to your circumstances.
Great poker players make the mathematically correct decision, for the right reasons, at the right time. They hold tightly to that, even if sometimes they get unlucky. Start with a better EV+ circumstance than your opponent, win the pots where you end up with a better hand than your opponent, and win some pots when your opponent has a better hand than you. Luck is not a central element in any of that.
Playing head-up in a freeze-out tournament with limited chips is a relatively rare situation for anyone, but again a core principle should be that if you aren't comfortable or familiar playing in some situations, don't solicit these situations unless you absolutely have to. Most players who have gotten to the final table via running lucky tend to play head-up poorly.
Assuming both players have a decent amount of chips, freeze-out head-up poker should be quite time-consuming. But very often head-up confrontations don't last very long at all, especially in No Limit Hold'em... and a big reason for this is often that 'I'm a luckbox running in god-mode' factor. Players who have played a lot of No Limit events but still have very little head-up experience seem to often immerse themselves in their own 'dodge bullets' Kool-Aid.

Poker God Mode

The person in position has a great advantage over the player out of position. So, why on Earth do so many players insist on calling from their big blind with hands as weak as 92offsuit? Do they somehow forget that the very next hand they will be dealt in on the button and they can raise from position with 92offsuit instead? It's not being rude to fold 92 in the big blind.
Even worse, when in position players will often adopt a 'standard' raise size. But hands aren't 'standard'. Some are way better than others. Some are more likely to bust an opponent when they hit big. Others are more likely to win a middling-sized pot when they hit big. Some, like 92offsuit, are best for just stealing the blinds.
I don't mean for this to come off as a discussion of head-up tactics though. I'm pointing out the confluence of events that often is underway in head-up tournament situations...
1) two people who have been hit by the deck for hours or days are playing each other
2) these players have generally not been calling raises from the big blind with weak hands like 92
3) these players, even the very loose ones, have generally not been playing every hand for one standard bet size
4) these players have generally not been winning by doing things like checkraising bottom pair for value on the flop
In short, the skills required to do well playing head-up poker are not the same skills involved in building a chip stack when running good earlier in tournaments!
This means that oftentimes the two remaining players are both ill-suited to playing head-up poker at this particular moment in their poker lives (after running in god-mode for hours or days).
So, as a tournament player, you should be battling hard to turn off all the impulses and reactions to having run good in this tournament, and instead shift to the mindset of exploiting your position and patience over a person who still thinks he can walk on water. And, as a tournament reporter, or an observer trying to improve your game, you should challenge yourself to recognize the difference between those players who are playing sound head-up poker versus those players whose actions are more in line with god-mode thinking.
Of course, luck will always be there. A deuce can come on the river and make all the difference. But since first place typically pays significantly more than second place, there may be no moment in poker where more value is transferred between players than when tournaments shift to head-up, and more skillful/sensible/adapting players grab value from god-mode players who don't adapt.
Also see Tournament End Games, Winning a Poker Tournament and more Poker Tournament Strategy