DEV Community: engnzdl

Two real bugs in aiograpi: a race condition and a dropped auth token

engnzdl — Thu, 15 Oct 2026 15:34:00 +0000

aiograpi is the async Instagram private-API library (475★ on GitHub). A version bump of our vendored copy surfaced two real bugs. Both are fixed, tested, and PR'd upstream.

1. photo_upload extracts media from the wrong response

photo_upload retries photo_configure up to 10 times, then pulls the uploaded media out of self.last_json:

if await self.photo_configure(...):
    media = await self._extract_configured_media_or_recent(
        self.last_json,   # shared mutable state
        ...
    )

self.last_json is the client's shared "last response" field. In a single-upload flow it happens to equal the configure response. Run two uploads concurrently and another coroutine's response can land in self.last_json between the configure call and the read — you extract media from the wrong request, or fail outright.

photo_configure already returns the configured dict. The retry loop was discarding it:

if configure_result := await self.photo_configure(...):
    media = await self._extract_configured_media_or_recent(
        configure_result,
        ...
    )

Race gone.

2. Instagram's token rotation gets silently dropped

Instagram rotates the bearer token mid-session and returns it in the ig-set-authorization response header. aiograpi parsed that header in exactly one place — the login flow. A rotation returned on any other private request was dropped, so authorization_data went stale and every later request rebuilt a stale Authorization header.

The fix moves the parse into the shared private-request handler, so any response carrying the header updates the client:

authorization = response.headers.get("ig-set-authorization")
if authorization:
    self.authorization_data = self.parse_authorization(authorization)

Shipped with tests

Each fix has a regression test (mocked transport / mocked configure) and passes the project's ruff + pytest gates.

Race fix: https://github.com/subzeroid/aiograpi/pull/511
Auth fix: https://github.com/subzeroid/aiograpi/pull/512

Upgrading a vendored anti-bot library across a major version: the patch ledger

engnzdl — Thu, 15 Oct 2026 14:14:51 +0000

I run the Instagram side of a social-automation platform, and it depends on aiograpi — the async port of instagrapi, the library people use to talk to Instagram's private API without the official Graph API. We vendor it (we have to, because we patch it), and recently we took it from 0.9.6 to 2.0.15.

That's not a minor bump. 2.0.15 is the instagrapi 3.x lineage — a rewrite underneath. And when you've been patching a vendored library for months, a major upgrade isn't pip install. It's an accounting exercise: which of my local patches does upstream now have, and which are still mine to carry forward by hand?

The patch ledger

Over the life of our 0.9.6 fork, five local patches had accumulated. Going in, the job was to sort them into two buckets.

Three had been absorbed upstream. The XDT media types (XDTGraphImage / XDTGraphVideo / XDTGraphSidecar — Instagram's newer Graph response shapes), a null guard on empty video_versions, a normalize on carousel-children pk extraction. Those just disappear on upgrade.

Two hadn't. Those are the ones worth describing, because they're the kind of bug that only surfaces in production, and only in an async client.

Patch one: the walrus-operator fix

The photo upload path retries its configure step up to ten times. The original code checked success by reading self.last_json — a shared field the client overwrites on every response. In a synchronous client that's already fragile. In an async client, where another coroutine's response can land between your configure call and your read, it's actively wrong: you're checking whether your upload succeeded by looking at some other request's response.

The fix is one line, and it's the whole lesson:

if (configure_result := await self.photo_configure(upload_id, width, height, caption, ...)):
    media = await self._extract_configured_media_or_recent(configure_result, ...)

The walrus captures configure's return value into a local, so you test the response you actually received — not whatever last touched the shared field. This is the bug that makes photo uploads flake intermittently in ways that are miserable to reproduce: it only bites when two requests race.

Patch two: the authorization header Instagram sends you

Instagram hands the session's auth token back in a response header, ig-set-authorization. The code parsed its sibling — ig-set-x-mid, the machine id — but never parsed the authorization header into the client's authorization_data.

So the session looked logged in while the client quietly worked with an empty authorization, and the first privileged request failed in a way that pointed at everything except the real cause. The fix is a straight header parse:

auth = response.headers.get("ig-set-authorization")
if auth:
    self.authorization_data = self.parse_authorization(auth)

It took a failing login to trace it there, because the symptom — "auth required" on the first action — is indistinguishable from a dozen other auth problems.

The bug the upgrade didn't cause, but the test run caught

None of this counts until it's exercised against a real account. The end-to-end run was: session login, reads (user info, search, friendship status), then writes — follow, like, unlike, unfollow.

The unlike action 404'd with "not-logged-in". It turned out _action_unlike only called the web client's unlike(), while the session we were holding was a mobile session — so the web client had no cookie and got a clean 404. The like path already had the right shape (mobile first, web fallback); the unlike path didn't. Fixed by mirroring it: try media_unlike on the mobile client, fall back to web.

After that, every write verified against the real account — follow reflected as following: true on Instagram, like / unlike / unfollow all clean.

Why I'm writing this

Because this is the unglamorous reality of building on top of reverse-engineered, unofficial APIs: the library is one platform change away from breaking, so you vendor it, you patch it, and when upstream finally catches up you run the ledger — what's absorbed, what's still yours, and what only shows up when you run it against a live account.

If your product sits on a private-API library and you're tired of the treadmill — the upgrades, the patch accounting, the 404s that mean something else entirely — this is the work I do. DM me on X (@engnzdl) or reach me at enginozdal.com.

I reverse-engineered TikTok's x-argus anti-bot signature

engnzdl — Thu, 15 Oct 2026 12:57:18 +0000

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.

I built a cross-platform Android emulator manager with Tauri 2 + Rust — no Android Studio required

engnzdl — Thu, 15 Oct 2026 11:55:38 +0000

I got tired of three things at once: the Android emulator CLI is tedious, Android Studio is a multi-gigabyte install for just running AVDs, and every decent alternative is either closed-source or expensive. So I built Enmulator — a desktop app that manages Android Virtual Devices end to end, ships on Windows/macOS/Linux, and doesn't need Android Studio installed.

It's Tauri 2 on the backend (Rust, 13 modules), React 18 on the frontend, and it's GPLv3.

What it actually does

Create / start / stop / clone / delete AVDs, plus batch operations across multiple devices
66 pre-loaded device profiles across 16 brands (Pixel, Samsung, Xiaomi, OnePlus, realme…)
Device identity spoofing: IMEI, operator, phone number, WiFi MAC, timezone, locale
Root: adb root for google_apis images, and Magisk via rootAVD for everything else
Per-device proxy, GPS mocking, screen recording, clipboard sync, live logcat, a split-panel file explorer
A headless REST API (Actix-web) so you can drive it from CI or a script

The whole point was to make emulator setup feel like a product, not a shell-script chore.

Why Tauri instead of Electron

A tool that spawns emulator processes shouldn't eat 300 MB of RAM on its own. Tauri uses the OS webview instead of bundling Chromium, so the installer is small and idle memory is low. The backend being Rust mattered more than I expected: adb calls are blocking Command invocations, and being able to move them off the main thread with plain std::thread — without async ceremony — kept the UI responsive for free.

The tradeoff is real too: the macOS/Windows/Linux build matrix means three toolchains and three sets of platform quirks (more on that below).

Architecture

The Rust side is a flat set of modules, each owning one concern:

sdk.rs — locate the Android SDK, adb, emulator, avdmanager binaries
avd_manager.rs — create/delete AVDs, write config.ini (resolution, DPI, hardware keyboard)
emulator.rs — process management + port allocation (each emulator gets a console port)
adb_bridge.rs — the adb shell / install / push / pull wrappers
fingerprint.rs — the identity-spoofing engine
bypass.rs — build.prop patching for detection bypass
extras.rs — GPS, clipboard, screen record, logcat streams
api_server.rs — the REST layer

The frontend is a few focused components: a create wizard, per-device cards, an identity panel, the file explorer, quick actions. Nothing clever — state lives in the backend, the UI just calls commands over Tauri's IPC.

The parts that were actually hard

Fingerprint spoofing is a moving target

The naive version is adb shell setprop with the IMEI/operator values. That works for some properties and silently fails for others — and "silently fails" is the worst outcome because the user thinks they're spoofed when they aren't.

The reality on modern Android:

ro.product.* (brand, model, manufacturer) are immutable — set at boot by the system image, setprop can't touch them.
IMEI/SIM fields (persist.radio.imei, etc.) stopped being settable via setprop around API 29.
The reliable route for read-only props is Magisk's resetprop, which patches the property store in memory.

So the identity engine is now Magisk-aware: if the device is rooted with Magisk, it uses resetprop for ro.product.* and ro.build.fingerprint; otherwise it falls back to setprop for the fields that still allow it. The app also reports which fields applied and which failed, instead of one big "success" that might be a lie.

Magisk integration without Android Studio

Rooting an emulator normally means patching the ramdisk. Enmulator bundles rootAVD, which does exactly that: it grabs ramdisk.img from the system image, patches it with Magisk, and pushes it back.

The gotcha I learned: the ramdisk is shared per system image, not per AVD. Root one device on a given image and every AVD using that image is rooted. That's worth documenting loud, because it surprises people.

Also adb root only works on google_apis (non-Play-Store) images — Play Store images reject it outright. So the app offers both paths and tells you which one applies to your image.

Windows wants to show you console windows

Every adb / emulator spawn on Windows popped a black console window. The fix is CREATE_NO_WINDOW (0x08000000) in the process creation flags — one line, but it has to wrap every command invocation, so it went into a shared sdk::new_command() helper used everywhere.

Windows also likes to prepend \\?\ to long paths, which broke resolving the rootAVD submodule. dunce::canonicalize fixed it by stripping the prefix.

Shipping three platforms from one repo

The release pipeline is a GitHub Actions matrix (ubuntu / windows / macos) that produces a .deb, .AppImage, .msi, and .dmg with stable filenames, then uploads them to the release. The thing that bit me: the default GITHUB_TOKEN can't update a release — it needs permissions: contents: write in the workflow. Took a failed run to learn that.

I also did a git history cleanup before open-sourcing: the repo's .git was 483 MB because old target/ and node_modules blobs were stuck in history. git filter-repo brought it to 6.7 MB. Same code, 72× smaller clone.

Honest limitations

ARM64 system images only run natively on Apple Silicon — x86_64 everywhere else.
The detection-bypass and fingerprint features are for testing on software you own/are authorized to test. There's a disclaimer in the README for a reason.
This is a solo project, so some edges (snapshot management, exotic device configs) are rougher than a team-built tool.

Try it

Repo: github.com/engnzdl/enmulator

Installers for macOS / Windows / Linux are on the releases page. If you poke at it and hit something, open an issue — and if it's useful, a star helps others find it.

Built with Tauri 2, Rust, and React. GPLv3.