Can Cheats See or Predict Undealt Cards?

Can a cheat know the cards in advance?

In the BluffKing default Hold’em sealed-dealing code reviewed here, we found no path that lets an ordinary player read another player’s unrevealed hole cards or future board cards during a hand merely by modifying their client, inspecting browser memory or capturing their own traffic. We also found no weak-randomness entry point that makes the deck practically predictable from public information. This is a conclusion about specific code paths, not a guarantee that no cheat can ever exist.

There are three different questions: reading someone else’s already-dealt hole cards, learning cards still in the deck, and reconstructing cards after play ends. After a completed hand, the default commit–reveal mechanism lets players actually dealt into that hand reconstruct the entire deck, including folded cards and unused cards. That is retrospective verification, not live visibility.

This article examines source snapshot f2b2c13e28c8f9704011a011606b082419e0230f, dated October 22, 2026. Its scope is the default Hold’em dealing path, not every game or encrypted mode. This is a source review, not verification of the deployed version or a comprehensive penetration test.

What can packet capture and a modified client see?

If a game sends every card to the browser and merely paints card backs over them, a cheat can read the hidden values. The relevant question is what the server sends.

Default sealed dealing generates the full deck in a separate dealer process. The game connection sends a seat ticket to the corresponding player dealt into the hand; the dealer connection uses that ticket to return that seat’s hole cards. Tickets come from 32 bytes of operating-system randomness. Changing a seat number does not obtain another player’s cards. A ticket is a bearer credential and must remain secret: stealing someone else’s valid ticket or controlling their device exceeds the assumption of modifying only your own client.

Game WebSocket hole-card messages filter by viewer seat: other seats’ card values become None, and spectators receive no private-card message. Reconnect snapshots also redact hole cards by seat. Board events carry only newly revealed cards. Default sealed dealing additionally keeps the full plaintext deck out of normal live game state. See sources [1] and [2].

On these paths, changing a card back into a face, reading your browser memory or reconnecting repeatedly cannot produce values that your client never received. Malware can read your own cards once delivered to your device, enabling leaks or collusion; that does not grant access to cards the server has not sent.

Does knowing the shuffle algorithm reveal the next card?

The algorithm is public; the per-hand random seed is secret. The actual call chain is:

1. The dealer generates a fresh 32-byte server_seed with OsRng. Initially it publishes only a domain-separated SHA-256 commitment.
2. It hashes the server seed, collected client seeds in seat order and the hand’s hand_id into a deck_seed.
3. The complete 32-byte deck seed initializes ChaCha20Rng. Fisher–Yates shuffles the deck, using rejection sampling for swap positions to avoid modulo bias.

This does not seed the shuffle with the clock, room number or previous hand’s outcome. Knowing your client seed and the hand identifier still leaves the server seed unknown during play. Its hash is not the seed itself. Assuming a sound operating-system entropy source, uncompromised secrets and secure cryptographic primitives, this chain provides no practical way to predict upcoming cards. [3]–[5]

A fixed seed reproduces a fixed deck, which is necessary for verification. Reproducibility does not mean players know that seed at the start. A predetermined order also does not let someone derive the next card from recent wins, losses or card history. Software may estimate equity, ranges and probabilities; those are not knowledge of this hand’s actual deck.

Post-hand reconstruction is a real privacy boundary

The normal completion path calls finish_blind() to check that the hand has ended before retrieving the full deck for settlement and verification. SeedReveal then gives the server seed, client seeds and deck seed to players actually dealt into that hand. The fairness export endpoint also checks actual participation. Spectators and people who joined the same table later do not thereby receive those seeds. [6], [7]

Those seeds let participants reconstruct every position, including other players’ folded or unrevealed hole cards and the unused remainder of the deck. A card back remaining in the history interface does not imply permanent secrecy from those participants. This is how the default verification mechanism currently behaves.

The revealed seed verifies this hand against its initial commitment; it does not directly reveal the next hand’s fresh random seed. Verification alone cannot prove that nobody saw cards during play, that players did not collude or that the server was never compromised. See how to verify a hand independently.

What could still expose hidden cards?

• A compromised player device or stolen dealing credential: an attacker may obtain cards that player has received or is entitled to collect.
• Collusion: players can share their own hole cards, increasing their combined information without breaking the random generator.
• A compromised game process, dealer process or host: the full deck exists in dealer memory. Internal calls require a token and signature, but the source explicitly excludes a compromised game process or host administrator from its protection. [8]
• Undiscovered bugs or deployment differences: source review cannot rule out every authorization flaw, credential leak or production configuration problem, nor replace inspection of the running version.

Default sealed dealing creates specific process and message boundaries. It cannot support a claim that the operator can never know the cards under any circumstances. Advanced encrypted dealing uses a different protocol and trust model. The presence of a mental-poker directory does not apply its guarantees to every table; see poker fairness and card privacy.

The precise answer is: we found no practical route through an ordinary player’s own client and public information in the reviewed default path. Participants can reconstruct cards afterward, while compromised devices, credentials or servers introduce different attack conditions.

Source references

1. server/src/sealed_dealer.rs — SealedHand::new_committed / new_with_rng
2. server/src/protocol/translation.rs — translate_for
3. server/src/pf_dealing.rs — os_random_32 / seed_commit / derive_deck_seed
4. engine/src/rng.rs — PokerRng::from_seed_bytes
5. engine/src/deck.rs — Deck::new / rng_range
6. server/src/sealed_dealer.rs — finish_and_settle
7. server/src/session/fair_dealing.rs — pf_emit_reveal
8. server/src/sealed_dealer/authorization.rs — Trust boundary

Additional call sites and authorization checks: server/src/protocol/translation.rs (snapshot_for_user_with_equities_from); server/src/sealed_dealer.rs (sync_tickets / hole_ws); server/src/handlers/hands_fairness.rs (get_hand_fairness); server/src/session/hand_play.rs (play_hand); mental-poker/src/hash.rs (ds_hash).