Home → Mobile Security
Client integrity · developer notes
Mobile poker client security: emulator, root, and integrity checks
In one paragraph: a mobile poker client like IDN's is the network's most forward defence. Before it trusts a session it tries to answer one question — is this a real, untampered phone operated by a human? It does that with five overlapping layers: device integrity, runtime protection, input/overlay checks, device fingerprinting, and server-side behaviour. No single layer is decisive; the defence is the stack, and the stack is exactly what automation on a mobile-only network has to defeat.
Layer 1 — Device integrity
The first thing a hardened client wants is confidence the operating system is what it claims to be. On Android this leans on hardware-backed attestation — the Play Integrity API and underlying key attestation, where the device's secure element signs a statement about boot state and app authenticity. On iOS the analogue is App Attest / DeviceCheck. An emulator or a heavily modified ROM generally cannot produce a valid hardware-backed attestation, so a client that requires the strongest verdict can refuse those environments outright.
Around attestation sit cheaper, classic checks:
- Root / jailbreak signals: presence of
su, Magisk artefacts, writable system partitions, known root-hiding packages, suspicious mounts. - Emulator signals: telltale build properties (
ro.product.model, generic hardware names), missing or simulated sensors, default IMEI/MAC patterns, x86 ABI on a "phone". - Debug posture: developer options enabled, ADB connected, a debugger attached, USB debugging over network.
Each signal individually is weak — power users and reviewers trip them too — so clients combine them into a score rather than a single yes/no, and the strongest gate is the attestation verdict, which is hard to forge.
Layer 2 — Runtime protection
Attestation tells you the device was clean at launch. It says nothing about what happens to the app while it runs. Automation frameworks like Frida, Xposed/LSPosed, and various hooking libraries inject into the process to read memory, intercept functions, and rewrite behaviour. Runtime protection tries to notice that:
- Anti-hook / anti-instrumentation: scanning loaded libraries and the process maps for known injection frameworks, detecting inline hooks and trampolines on critical functions.
- Debugger traps: timing checks and self-debugging tricks that misbehave when a debugger is attached.
- Integrity / tamper checks: verifying that the app's own code and assets match expected checksums, so a repackaged or patched APK is rejected.
- Anti-repackaging: binding the app to its original signing certificate, so a re-signed clone fails server-side checks.
This is an arms race with no permanent winner; the goal is to raise cost and increase the chance that a tampered build trips a server-side flag rather than to achieve a perfect block.
Layer 3 — Input and overlay
A bot has to act, not just read. On Android the cheapest way to drive another app is the accessibility service — designed for assistive tech, it can read the screen and dispatch taps and gestures into other apps. It is also the single most abused automation channel, so clients watch for it carefully:
- Detecting that an accessibility service is enabled and inspecting which ones, flagging non-allowlisted automation services.
- Watching for screen overlays (the "draw over other apps" permission) that bots use to read or annotate the table.
- Distinguishing synthetic from human input — injected events can lack the pressure, size, and micro-timing jitter of a real fingertip, and a perfectly periodic tap stream is its own tell.
- Screen-capture / projection checks, since computer-vision bots need a frame source.
Layer 3 is where the mobile-only nature of IDN bites automation hardest: on desktop, injecting input is trivial; on a locked-down phone client, every input path is itself a monitored surface.
Layer 4 — Device fingerprinting
Even a perfectly automated, well-hidden client is only useful at scale if you can run many of them. Fingerprinting attacks that scale. The client gathers a stable, hard-to-spoof identity for the device and ties it to the account:
- Hardware & build profile: model, SoC, screen metrics, sensor list and calibration quirks, available codecs.
- Sensor entropy: accelerometer and gyroscope noise patterns are individual and very hard for an emulator to fake convincingly.
- Persistent identifiers: install ID, attestation key, network ASN and routing characteristics.
The point is linkage. If twenty "different players" share one sensor profile, one emulator signature, or one ASN, the network can collapse them into a single actor — which feeds directly into the collusion-cluster detection described on the Network & Skins page. Fingerprinting is what turns per-device suspicion into a per-ring case.
Layer 5 — Server-side behaviour
The first four layers can all be probed, faked, and eventually beaten on a determined attacker's own hardware. The fifth cannot be inspected by the attacker at all, which is why it is the durable backstop. The server watches outcomes:
- Timing fingerprints: humans vary; bots tend toward suspiciously stable decision intervals or react faster than a person can after a card is revealed.
- Strategy signatures: play that hugs solver outputs across thousands of hands is itself anomalous against a human field.
- Win-rate & variance anomalies: sustained results that sit outside plausible human distributions.
- Multi-account & collusion graphs: the table, money, and device graphs combined — the highest-confidence signal of all.
Because the server sees every hand on the shared pool, it has the one vantage point no client tamper can remove. Good mobile security is therefore not about winning the device arms race outright; it is about raising client-side cost enough that whatever slips through still lights up a server-side pattern.
The honest limits
None of this is a wall. A skilled attacker with real hardware (not an emulator), careful input humanisation, and patience can keep a single client alive for a while. What the stack does is make scale expensive and traceable: every shortcut that makes a bot cheaper to run — emulators, shared fingerprints, accessibility automation, common settlement agents — also makes it easier to cluster and catch. On a mobile-only, shared-pool, agent-funded network, security is an economic argument as much as a technical one, and the device client is where that argument starts.
