Anti-bot signatures are the modern CAPTCHA. Every serious mobile app signs its API requests with a token only the app itself can produce, and TikTok's is among the hardest to break. I've spent the past weeks taking it apart, and I want to share what's inside a protected native signer like this and what it takes to work with one.
The signature, structurally
The x-argus header is a 728-character token. Under the base64 it's a 546-byte blob with a clean layout: an 8-byte nonce, a 32-byte SM3 digest, and a 506-byte AES-CBC ciphertext.
The pipeline: a protobuf payload (device id, install id, app version, timestamp, and the SM3 hash of the request body) is hashed with SM3, encrypted through SIMON-128/256 (72 rounds), then AES-128-CBC, then base64. The companion headers — x-gorgon, x-ladon, x-khronos — come out of the same pass.
This logic doesn't live in the APK's Java. It's inside libmetasec_ov.so, a native library built to resist analysis: OLLVM control-flow flattening, a custom bytecode VM, and JIT-generated code. Static disassembly of a signer like this just folds back on itself.
Emulating, not disassembling
The approach that actually produced results was to stop reading the binary and start running it. unidbg executes an Android .so on a desktop JVM; once the native entry point was mapped and fed the right inputs, the library produced valid signatures under emulation.
That's the inversion worth internalizing: against obfuscation at this level, you don't beat it — you give the binary the environment it expects and let it sign for you.
Dynamic analysis had its own traps. The signer's entry function takes its arguments in a non-obvious way — the request URL isn't passed where you'd assume. Calling it the intuitive way throws an "argument types do not match" from the JNI layer; it only signs correctly when you pass the headers array instead of the URL string. Details like that are the difference between "I looked at it" and "I ran it."
What the client actually returns
The result isn't a paper analysis — it's a working Python client that speaks the API natively. Profile lookups (/tiktok/user/profile/other/v1) return real account data — uid, avatar, follower counts. The feed endpoint (/aweme/v2/feed/) returns fresh content with the full aweme_id / sec_uid shape. Search works across all three surfaces — users, videos, hashtags — through /aweme/v2/search/general/single/, returning live user lists with real ids and follower counts.
A couple of non-obvious details that fall out of doing this for real. The API routes each request to a different host based on what it is — one host for profile, another for feed, a third for search — and sending a request to the wrong one fails even with a valid signature. Gzipped bodies need an extra x-ss-stub header that's just the MD5 of the plaintext, folded into the signature with the data field left empty. These are the small things a headless browser never shows you, and exactly what breaks when you guess.
The two layers you don't expect
Two non-crypto layers make this genuinely hard in practice. The first is transport: the API only accepts a client presenting Android's TLS fingerprint (OkHttp3_13), so everything has to ride on a TLS stack that mimics the device. The second was the bigger surprise — the signature binds a device fingerprint, read live from the property trie at /dev/__properties__. The crypto is portable; the device identity isn't.
Why this matters
If you build anything that talks to a mobile API — data collection, growth tooling, automation, market research — you eventually hit this wall. The only real question is whether the team can actually get through it, or just throws a headless browser at the problem and hopes.
That's the work I do: mobile reverse engineering, signature and anti-bot bypass, TLS fingerprinting, and building clients that speak these protocols natively.
If your product is stuck at one of these walls, let's talk — DM me on X (@engnzdl) or reach me at enginozdal.com.
The full research notes — signing chain, endpoint catalog, dynamic-analysis hooks — are on GitHub: github.com/engnzdl/tiktok-x-argus-research.
Educational security research. This describes a publicly documented signature scheme at a structural level — no working code, keys, or implementation details are published.
Top comments (0)