Poker Players Alliance Forums » Poker Players Alliance

Cheating with Deal Guardian

(10 posts)
  • Started 8 months ago by Big Jim Slade v2.0
  • Latest reply from Nick Maiorana

No tags yet.


  1. Big Jim Slade v2.0
    Moderator
    Visit User Profile

    In a previous thread I demonstrated that the DealGuardian software was flawed in it's implementation. So, knowing this allows a form of "advantage play" if I were to be playing on an online card room that uses the DealGuardian server to deal cards to players.

    My first thought was that if the one insider at Ultimate Bet was able to swindle people for $22 million by playing rigged poker, maybe I could hook up with Nick for Secure Card Dealer and offer to split it with him - $11 million each – if we worked together on this. But then I remembered that Nick said he wasn't going to look at any of the hidden cards, so that's that.

    My second thought was that I could ask my buddy Josh, who practically runs the pizza place (next door to Secure Card Dealer) for $8/hour, if I could place a server there and do network monitoring of Nick's DealGuardian servers. But then I thought that his 56 million virtual hands may be over 3,000 years of one person playing poker, it is only about two weeks at a major poker room (if you don't include play chips and micro limit games). To cover this much traffic, and six poker tables per DealGuardian server, there would have to be hundreds of DealGuardian servers. On second thought, I don't think Nick can fit that many blade servers in his 5" x 8" mailbox at the UPS store. He will probably run them all off his DSL line at home, so Josh the pizza man is no help to me.

    So that led me to the idea of pure "advantage play" which as a by product is totally legal, as opposed to my first two ideas. :)

    When you shuffle an electronic poker deck, there are 52! (read fifty two factorial) shuffled decks you can produce. 52! = 52 x 51 x 50 x 49 … = 80,658,175,170,943,878,571,660,636,856,404,000,000,000,000, 000,000,000,000,000,000,000,000 or about 2^225.

    Of course, the DealGuardian shuffle is flawed. It is flawed because it it doesn't return an even distribution of decks. That is, some shuffles are more likely to be produced than others are. This uneven distribution can be leveraged into an advantage if a tipped-off player is willing to sit at the table long enough. So how can we use this aspect of DealGuardian to cheat at poker?

    The unequal distribution of decks skews the probabilities of certain hands and changes the betting odds. Experienced poker players (who play the odds as a normal course of business) can take advantage of the skewed probabilities that DealGuardian provides. But wait, it gets better.

    The most common implementation of a Random Number Generator (RNG) produces numbers from the range of zero to about 4 billion, or 2^32, which is of course a huge number to you and I. Put another way, using this implementation of a RNG the largest "seed" that will fit into the RNG is 4 billion.

    As it turns out, 4 billion is far, far less than the possible 2^225 possible decks. The bit length of the seed for the RNG helps generate the deal bias of the DealGuardian server by simply not ever, even in three millenia of dealing cards, using all possible deck shuffles. In fact, most of the deck shuffles are thrown out and never used.

    Computerized RNGs are totally deterministic. For any given "seed" number you supply to the RNG, it will always produce the same string of random numbers. In other words, the same seed always gives you the same shuffled deck. The most common implementation of a seed for a RNG is to use the system clock, which provides the time in milliseconds since midnight.

    There are a mere 86,400,000 milliseconds in a day. Now we are only at a fraction of the 4 billion decks we thought we had. The could really cut down on the possible shuffled decks that are used in a DealGuadian server. But wait, if we are going to cheat, it gets better!

    We can synchronize our computer's system clock with the DealGuardian server's system clock. Now we only have about 200,000 possible decks. Searching through that amount of shuffles (decks) is trivial and can be done on a PC in real time.

    I'll skip the math here, but by knowing only five cards in the deck, we can determine which of the couple of hundred thousand shuffled decks we are using. For the five cards, let's use our two hole cards and the three flop cards in Texas Hold'em. Once we know these cards we know which shuffled deck was used by Deal Guardian. Knowing this we now know the the turn and the river and we have never even looked at the DealGuardian server. Of course at this point we also know everyone's hole cards because we know the the shuffled deck and in what order all the cards are.

    Please let me know what poker room is implementing your DealGuardian. Please.

    Posted 8 months ago #
  2. You know nothing of how our technology works.

    You have know idea how our shuffle works.

    Everything you stated above is wrong.

    BTW, you found that information about how one of the original sites did their shuffles and the flaw it had. I read that a few years ago. Here it is for the rest of the readers: http://www.cigital.com/papers/download/developer_gambling.php

    Edited by TheEngineer: removed personal attacks

    Posted 8 months ago #
  3. Just in case you think the Poker Fraud thing is taken care of, here is some news about Pit Bull Poker: http://www.pokernewsdaily.com/pitbull-poker-under-fire-over-security-superuser-accounts-3773/

    Posted 8 months ago #
  4. Well, not everything he stated is incorrect. There are, in fact, 52! possible decks.

    Of course, we have no idea if any of the presumptions about the software are true. You did originally say that there was no way you would be letting anyone else look at your code, although now you say you are releasing the shuffler on SourceForge.

    I'd bet that computers are powerful enough these days, that one decent one could deal with shuffling a few billion different decks if they needed to. It's more a RAM issue than a speed issue, at this point. And we've got that covered pretty well too.

    Posted 8 months ago #
  5. Big Jim Slade v2.0
    Moderator
    Visit User Profile

    nMaiorana said,

    You know nothing of how our technology works.

    You have know [sic] idea how our shuffle works.

    First a diversion ...
    Concerning the above statement it could be said that I do not have the ability to comprehend, not the technology, but the words that nMaiorana is saying. But would this be true? The actual sentence is wrong - is it spelling, is it diction? Is Nick stating I "have known ideas" about his shuffle, or that I "know an idea" about his shuffle. Or that I "have shown an idea," or is he saying that only I "know" how the shuffle works?

    My guess is that Nick meant to say that I "have no idea". But this is not what he said. I can only speculate on what Nick's intentions were when he opened his mouth. All I have are the actual words that came out. Nick produces textual errors in almost every message (business communication for Secure Card Dealer) he posts on here. I therefore speculate, by the process of inductive reasoning, that his computer code is written with the same level of preciseness and care as his business case.

    So while I can speculate on what he wrote, I truly do not know what his intentions were. I understand each and every word he used, even the incorrectly used words. I understand language, diction, grammar, syntax, punctuation, ASCII code, Hollerith, and Unicode. I even have a mild understanding of poker and the internal mechanisms such as dealing cards. But I don't know what Nick intended to mean.

    Back to the matter at hand....
    nMaiorana said,

    You know nothing of how our technology works.

    You have know [sic] idea how our shuffle works.

    Actually I do in fact know basically everything about how your technology works. I also know basically everything about how your shuffle works. Of the large multitude of ways you could have implemented your technology, I understand and am well versed in each and every one of the implementations, both good and bad.

    I know that 52! is the maximum number of possible decks you can create. I also know this number is meaningless because the number of possible decks in online poker is less that 52!. And I solidly understand the math behind it. I gave you the opportunity to point this out to me, but since you don't understand the math, you didn't. Instead you said you found a reprint of the original Datamation article about Planet Poker on the Citigal site, you just didn't know it was from Datamation apparently.

    I proffered a methodology for an in-place shuffle (one deck) and expected you to tell me how you don't use an in-place shuffle, but use a "two" deck shuffle.

    I understand entropy sources. I understand encryption and hashes. I understand prime numbers. I don't get my prime numbers from a reference book, but derive them myself with a heuristical sieve of my own design. I understand randomness. I understand predictive randomness, I understand non-predictive randomness. I understand psuedo-random numbers. I understand infinities, and that some infinities are larger than others. I understand probabilities, but I don't look them up on a web site, but rather use multiplication and division to derive the numbers.

    If I speak on one of these subjects I am definitive and authoritative. Of course when it comes to poker, I'm still trying to figure the game out.

    What I don't know is which implementation you chose in your DealGuardian product. I know the implementations for most of the major poker rooms because they publish this information in the open. Secure Card Dealer, your company, reveals nothing substantive about DealGuardian.

    If you had used the correct words to describe appropriate technologies and describe in general how they are relevant to your product I would probably say your product sounds solid. Unlike the online card rooms, you cannot do this. Therefore I cannot say your product is solid. Nor can I suggest others trust your product.

    But because your product is weak, people could use your implementation to their advantage and profit from it. Some call it advantage play, some call it cheating.

    Posted 8 months ago #
  6. thunderacura
    Member
    Visit User Profile

    I'm not randomness expert, but what's wrong with this?

    Use two decks A and B in your algorithm and a salted dynamic seed.

    Definitions:
    Deck A: two decks, always in order (2s-As 2c-Ac 2h-Ah 2d-Ad) x 2 (total size is 104)
    Deck B: the shuffled deck
    Placed P: 52 item array with true or false for each corresponding card that's been place in B, initialized to all false
    SaltedDynamicSeed: some seed with a secret salt appended to it.

    Algorithm:
    cur := 0;
    for(i = 0; i < 52; i++) {
    rand := random(52,SaltedDynamicSeed) //get a random number 0-51 inclusive given the SaltedDyanamicSeed;
    if(!P[rand]) {
    B[i] = A[rand];
    P[rand] = true;
    }
    else {
    for(cur = i; cur < 104; cur++) {
    if(P[cur%52]) continue;
    else {
    B[i] = A[cur%52];
    P[cur%52] = true;
    break;
    }
    }
    }

    return B;

    Posted 8 months ago #
  7. Big Jim Slade v2.0
    Moderator
    Visit User Profile

    thunderacura asks,

    I'm not randomness expert, but what's wrong with this?

    What's wrong? This is not a forum for solving math problems, correcting code, or providing riddles or challenges to people. But since you asked, that's the first thing wrong. Let's look at more.

    To restate your question, I'd ask what is it supposed to do, or ask what is the "evaluation criteria" for determining what is wrong. You have to provide information about what is the initial state, what is the desired final state, and then determine what variance there is - or perhaps you can state the variance and ask why it occurs.

    You did not provide evaluation criteria, so I'll make some assumptions. I'll assume you wanted to take an ordered deck of 52 cards and produce from this a randomly shuffled deck of cards.

    That is second item wrong. I'll assume the requirement was actually not to shuffle a deck, but rather the provider of this riddle wanted to deal cards to players in a card game, in this case a nine player Texas Holdem table. In any valid Requirements Analysis for a online poker room project, there is no actual requirement to shuffle a deck, merely to deal shuffled cards. While one implementation may be to shuffle a standard deck of 52 cards, dealing cards can be done in other ways. For an online poker room I'd state that there is no valid "Use Case" for shuffling a regular poker deck. That is merely an implementation detail that may, or may not, be used.

    There are 52! ways of shuffling each deck. But for a nine player Texas Holdem game the number of "possible" shuffles is far less. There are 9 player times 2 cards plus 3 burn cards plus 5 board cards, for a maximum total cards of 9*2 + 3 + 5 = 26 cards, which is only 1/2 of the 52 cards that are being processed. In all cases, for a nine player table in Texas Holdem, the remaining 26 cards are never used, therefore there is no reason to run the algorithm on the second half of the deck. (Therefore there are only 52! - 26! actual "deck shuffles" in Texas Hold'em with nine players)

    This will produce a time savings of perhaps half, actually a little more, for each shuffle. Implementing a similar strategy with DealGaurdian might increase their (amazingly slow) throughput significantly. This is the third item that is wrong.

    rand := random(52,SaltedDynamicSeed) //get a random number 0-51 inclusive given the SaltedDynamicSeed;

    You say you do not have a complete understanding of randomness. A random number generator function in a computer language is completely deterministic. For any given seed, the exact same random number always comes out. A typical random number function uses the last result to reseed itself for the next number. Typically a random() function is seeded once then it always produces the same sequence of results from the same seed. Until you change to a new seed.

    For the Gentle Reader I'll explain a "seed" may look like "1234567890ABCFDEF" and the salt may look like "MYSECRETWORD". So a seed may look like "1234567890ABCFDEFMYSECRETWORD".

    The "salt" you add to the seed is meaningless in terms of both entropy and randomness of the output. The salt may increase the bit length of the seed, but since it is always the same bits, there is no added entropy. It is common to put this through a one way hash function, but again while this might increase the bit length of the "entropy" no increased entropy is gained from the use of the hashing function or salt. The presence of salt is merely to obscure the source of the seed.

    I am unsure what is intended by a "SaltedDynamicSeed." I will assume this means that each call to the random() function is meant to contain a new seed from a new source of entropy. It is not apparent to me if this is a static variable, or some function that is hooked to, say, a Massive Dynamics #3 Entropy Generator.

    If the SaltedDynamicSeed is a static variable it appears to be set outside the "for loop" and since random number generators are deterministic, the rand result will always be the same number because the DynamicSeed never changes. If it is a function, sadly missing the parentheses, then the DynamicSeed changes with each card, but I have to wonder where it is getting it's entropy from. The routine is made slow by having to gather entropy for every card. This would make it as slow as, say DealGuardian. In some form or another, the seed is the fourth mistake.

    rand := random(52,SaltedDynamicSeed) //get a random number 0-51 inclusive given the SaltedDyanamicSeed;

    This piece of code is very fascinating, assuming it is meant to be a unique number each time. By generating each card from a separate entropy this lowers the "dealspace" from approximately 2^225 to less than 2^6. As I have said before, random number generators are entirely deterministic, so this suggests that the random function is not being used to create a string of random numbers, but acts as a hashing function for the SaltedDynamicSeed. So just don't use the random() function and use the entropy instead. Depending on the implementation of random() in the language, it may be producing a modulus error as well. This may be another item that is wrong.

    I could go on, but I tire and am in need of a bit of sustenance and a libation or two.

    Posted 8 months ago #
  8. Here's a page from a site that I play at..

    At the start of every game, the table asks for a freshly shuffled deck.

    The Shuffler requests a clean set of random data from the RNG.

    The RNG generates purely random data using the simple yet highly reliable and secure mathematical representation of the statistically random behavior of photons (particles of light) when fired through a half-mirror – or a mirror which allows only 50% of all light to be reflected while the other 50% passes through. As it is impossible to tell whether a photon will pass through or be reflected, the resulting data is a totally random string of ones and zeros, or binary code.

    Just to be sure, the Shuffler monitors the output of the RNG for randomness.

    If the data is clean, the string of code is translated into a freshly shuffled deck.

    This process is repeated again on the shuffled deck - i.e. a double shuffle.

    The cards are then sent along a secure, encrypted line to the table – a freshly double-shuffled deck.

    Before each card is dealt out, a re-shuffle of the remaining cards takes place. This means that each dealt card has been randomly drawn from a freshly reshuffled deck, each and every time.

    And so on, until the game is over and the next one begins. This process of continuous shuffling is a measure of added protection to ensure the highest level of randomness and security that can be obtained.

    Posted 7 months ago #
  9. Big Jim Slade v2.0
    Moderator
    Visit User Profile

    What eBlade has copied here is an excellent example of the level of transparency that online card rooms should employ when discussing their shuffle. There is a verbal description of the shuffle process, a description of the entropy source, and some description of the encryption used. What is missing are bit lengths, hash types, and cipher type being used. But all in all, this is miles ahead of anything DealGuardian provides in the way of transparency.

    In the example given (poker4ever I presume) The entropy source is given as a hardware based quantum device that relies on photons (light) as the source of entropy, or randomness, used to "seed" the random number generator algorithm. Other possible entropy sources that could be used in other systems include the system clock (milliseconds since midnight) as used in the RANDOMIZE statement of many programming languages, PlanetPoker in the Datamation article Nick referenced, or in Netscape's original 40-bit SSL implementation. Entropy can be gathered from user mouse and keyboard movements as well as network traffic. Other hardware devices are available commercially such as Intel's thermal entropy generator, and of course a large group of hobbyist homebrew entropy generators.

    An interesting feature, for good or bad, of this system is that it reshuffles the remaining deck at every burn card. Brick and Mortar poker has some safeguards built in to make sure if a card is exposed you get the card you were supposed to get. This reshuffling at every burn card seems to mess with that concept. On the other hand since random number generators are deterministic, this potentially prevents someone from discovering the seed and matching the deck since it is reshuffled at every burn card.

    For poker4ever, the shuffle methodology is transparent and the merits of the shuffle can be debated for good or bad. Not so with DealGuardian. Their shuffle is a "trade secret", it is "patent pending" it is "not discussed" for "security reasons". With DealGuardian there is no transparency, there is no way to trust them.

    Posted 7 months ago #
  10. Correction: SCD's shuffle algorithm is not a patent pending technology. Our patent application solves a problem with the mechanism to manage a hand securely and prevent internal fraud.

    Correction: Our shuffling software is now Open Source and available to the public.

    Posted 7 months ago #

Reply

You must log in to post.