How Qutoutiao Built a Robust Anti-Cheat SDK and Device Fingerprinting System

Qutoutiao Security Team Overview : Responsible for security across all business lines, developing device fingerprinting, real‑time risk control, anti‑cheat systems, WAF, vulnerability platforms, and ensuring compliance, network, system, data, and business security.

Since the launch of the Qutoutiao app, continuous attacks from black‑market operators have driven the evolution of a bespoke anti‑cheat technology stack, which this article briefly introduces from a practical perspective.

Anti‑Cheat SDK

Why develop a dedicated SDK?

1. Decouple from business data to standardize formats and simplify feature releases, ensuring strategies remain maintainable.

2. Obtain trustworthy device environment data that cannot be easily tampered with via hooking tools.

3. Enable unique device fingerprinting for anti‑cheat, analytics, product strategy, and advertising purposes.

The SDK has been iterated through multiple rounds, now integrated into dozens of internal apps.

Protection measures include a custom binary encoding format (neither JSON nor Protobuf) with compression, a proprietary C‑implemented encryption and signature algorithm with obfuscation, dual‑layer parameter verification between C and Java, and debug‑state detection.

These safeguards raise the difficulty of reverse engineering and allow risk perception.

The SDK accomplishes two key tasks:

Generating device fingerprints and tuid by combining strong client‑side perception with server‑side algorithms for high accuracy.

Reporting explicit client environment parameters (e.g., boot time, volume, light sensor) that comply with national security regulations, enabling detection of fake devices such as emulators, jailbroken devices, and parameter clusters.

Example emulator detection strategies include checking CPU architecture, Wi‑Fi SSID (e.g., BlueStacks), unique process names (e.g., com.android.emu.coreservice), and cloud‑phone brand signatures.

Device Fingerprint

The fingerprint uniquely identifies a real device across reinstallations, reboots, and system restores, while tolerating normal user modifications. The system has progressed through three versions:

Version 1 – Single‑field mapping : Simple ID mapping stored in Redis; faced scalability and collision issues as device count grew beyond billions.

Version 2 – Multi‑field mapping : Switched to MySQL with multiple indexes to improve accuracy, but encountered performance bottlenecks and high CPU usage.

Version 3 – Optimized model algorithm : Adopted a self‑optimizing model capable of adjusting to Android ecosystem changes (e.g., IMEI deprecation, OAID adoption) and privacy constraints, achieving higher accuracy than previous versions.

Continuous refinements have made the fingerprint highly accurate and stable.

tuid

tuid combines the server‑side device fingerprint with a temporary client fingerprint to provide a stable identifier during app startup before the server fingerprint is available. It was initially created for A/B testing when traditional IDs (IMEI, Android ID) proved unreliable.

tuid became the unified identifier across all business lines, enabling consistent data alignment and accurate metrics. Disagreements between anti‑cheat and data‑center teams over who should compute new‑user counts were resolved by implementing a tuid conversion service that bridges client and server identifiers, reducing false‑new‑user rates from up to 18% down to 1–2%.

Despite Android system changes (non‑unique Android IDs, randomized MAC addresses, restricted serial numbers) and privacy regulations requiring user consent before collecting environment parameters, the enhanced tuid pipeline—augmented client fingerprints plus conversion service—maintains stability and accuracy.

Overall, the anti‑cheat SDK, high‑precision device fingerprint, and innovative tuid solution form a robust, adaptable security framework that mitigates black‑market threats while complying with evolving platform and regulatory requirements.