DEV Community: engnzdl

Reversing TikTok's Request Signing: From Obfuscated Native Code to Pure Python

engnzdl — Sun, 18 Oct 2026 20:26:43 +0000

Reversing TikTok's Request Signing: From Obfuscated Native Code to Pure Python

TikTok's mobile app signs every API request with a stack of tokens: x-argus, x-gorgon, x-ladon, x-khronos. The server checks them before it returns a single byte. Get one wrong and you don't get a clean 403. You get an empty 200, or an error that looks like a network hiccup. The rejection is silent, and that silence is most of why this thing is hard to reverse.

I reverse-engineered the full signature set for TikTok 47.0.3 and rebuilt it in pure Python. No emulator, no runtime instrumentation, no JVM, no loading native modules. A few Python dependencies and a signing facade.

I'm leaving out the exact byte layouts, constant tables, and key-derivation steps. This post is about how to approach this class of problem, not instructions for reproducing the signatures.

1. What you're up against

Four moving parts, and they compose rather than stack independently:

Signature	What it covers	Character
x-argus	request body + query	the strict one, enforced on high-value endpoints
x-gorgon	a header-level signature	table-driven bit mixing
x-ladon	device / license attestation	ties the request to an app identity
x-khronos	timestamp	tightly coupled to the others; same-timestamp consistency matters

Enforcement is risk-based and per-endpoint. Not every endpoint checks every signature. I probed live endpoints with deliberately broken signatures and found the anonymous pre-login surface is where the server is strictest. Once you hold a valid session, the checks relax a lot. That looks like a deliberate anti-bot posture, and it doubles as a development shortcut: test against the strictest endpoints first, because if those pass, the rest will too.

2. The approach

The specific tools matter less than the order of thinking. Three principles carried the whole effort.

Observe at the point of least resistance. The native signing code is control-flow-obfuscated, and it generates constants in registers at runtime. They are never written to disk, so a disassembler finds nothing to grep for. The breakthrough came from watching the code at the one place where its secrets are briefly in the clear: a full emulation environment where timing side effects vanish and short-lived intermediate state can be captured. In a real process that state lives for microseconds. In an emulator you can freeze it and read it back.

Treat negative results as scope reduction. Instrumenting the higher-level runtime produced nothing but silence. The signature path was entirely native; the managed layer only handled string decryption and device queries. That silence was the finding. It told me precisely where not to look and saved weeks. A hook that returns nothing is still an answer, if you read it as a boundary.

Prove the generator before you trust it. The turning point was building the inverse of the signing pipeline and requiring it to fully reverse a genuine token before I accepted the forward implementation. If your decoder can't explain a real signature byte for byte, your generator is a guess.

3. The findings that mattered

These are behavioral findings, not the algorithm:

One byte in the argus header is a version/flag field that must be small. A random large value gets rejected before the body is even read. A whole class of plausible-looking forgeries dies on that single byte.
The trailing padding is not real PKCS7. It's length-prefixed random fill. Treating it as standard block padding produces a structurally plausible signature that gets silently rejected.
Not every field that looks like device attestation is actually checked. I found fingerprint-looking values that are client-generated and never verified by the server. The lesson isn't the specific field. It's to test every assumption: "the server checks this" is a hypothesis until you prove it with a live request.
Two error codes that look like siblings mean opposite things. One means "your signature is invalid." The other means "your signature is fine, but I want a challenge step first." I confirmed this by reproducing the app's own login flow: the challenge appears after the signature has already been accepted. Confusing the two sends you debugging the wrong layer for days.
Silent rejection is the real enemy. HTTP 200 with an empty body looks like success, but it's risk-control quietly dropping your action. A 403 at least tells you something. Treat an empty 200 as the red flag.

4. The pure Python port

The runtime is deliberately boring, and that's the point. A TLS layer that matches the app's own fingerprint, a pure Python implementation of the core hash primitive, and a standard library for the symmetric layer. No native modules, no subprocess, no emulator, no runtime instrumentation. It runs anywhere Python runs.

A single signing facade produces the entire header set from one timestamp, which guarantees the x-khronos consistency the server checks. Around it sits a thin client: device registration, session management, and a typed API layer for feed, search across 7 tabs, profile, video download, and DM read. The session store is sqlite-backed with restricted permissions.

5. Verification

I validated against the endpoints that actually enforce the signatures, not the lenient ones:

The anonymous feed endpoint, one of the strictest, returned a real feed.
The like endpoint returned is_digg: 1, meaning the server accepted the signature and applied the action.
The login endpoint returned the same challenge response the real app gets. That's the strongest signal: the server read the signature as valid and moved on to the next auth step.
A 38 MB video pulled clean through the signing path.

The read path holds. What's left is write actions, which hit risk-control silent rejections rather than signature failures.

6. What I'm not showing

This covers methodology and behavioral findings. The exact byte layouts, constant tables, and key-derivation chain stay private. If you want to take on a system like this yourself, the reusable part is the order of operations: observe where the secrets are briefly exposed, treat dead ends as scope reduction, and prove your generator with a reverse-verifier before you trust it.

The signature rotates with every app release anyway. The methodology is what lasts.

How apps spot an Android emulator (part 2): sensors, telephony, and the GPU

engnzdl — Sat, 17 Oct 2026 13:34:17 +0000

How apps spot an Android emulator (part 2): sensors, telephony, and the GPU

Part 1 covered the props layer and the kernel tells. Those are the cheap checks: a file you can edit, and a boot command line you can't. This part is about the expensive ones. The hardware and behavior layer, where the tells stop being strings and become things the VM simply does not have.

I measured everything below on a stock emulator this month, the same way I measured part 1. The values are real, from adb shell, not from memory.

Sensors: the vendor string is the giveaway

Android exposes its sensors through a HAL, and every sensor carries a vendor string. On a stock emulator:

$ adb shell dumpsys sensorservice | grep -E "Accelerometer|Gyroscope|Proximity|Light"
0x00000000) Goldfish 3-axis Accelerometer | The Android Open Source Project | ver: 1 | ...
0x00000001) Goldfish 3-axis Gyroscope | The Android Open Source Project | ver: 1 | ...
0x00000005) Goldfish Proximity sensor | The Android Open Source Project | ver: 1 | ...
0x00000006) Goldfish Light sensor | The Android Open Source Project | ver: 1 | ...

Two tells in one line. The sensor names all start with "Goldfish", the codename of the emulator's virtual platform. And the vendor on every sensor is "The Android Open Source Project".

A real phone does not look like this. Its accelerometer comes from Bosch or STMicroelectronics, its gyroscope from InvenSense, its proximity sensor from AMS. The vendor field names the silicon. Nobody ships a phone whose sensors are all "The Android Open Source Project", because that vendor string means "synthesized in software, no chip behind it".

The list is also thinner than a real device's. The emulator exposes the standard set: accelerometer, gyroscope, magnetometer, light, proximity, pressure, temperature, humidity. It can even stream fake events into them. But the characteristics of the ones it does expose look wrong to an app that has seen real hardware.

Telephony: the SIM says LOADED, the RIL says emulator

The emulator goes to real effort here. It simulates a full telephony stack:

$ adb shell getprop gsm.sim.state
LOADED

$ adb shell getprop gsm.operator.alpha
T-Mobile

$ adb shell getprop gsm.operator.numeric
310260

It has a SIM in state LOADED, an operator name, a network code, even an IMEI. Any app that checks "is there a SIM and a network" gets a plausible answer.

Two more props are the ones that matter:

$ adb shell getprop gsm.version.ril-impl
android reference-ril 1.0

$ adb shell getprop gsm.version.baseband
1.0.0.0

The RIL is the radio interface layer, the software that talks to the actual modem. On a real phone that string names the vendor's RIL binary: Qualcomm, MediaTek, Samsung, whatever the SoC is. The emulator reports android reference-ril 1.0, which is the reference implementation that ships with AOSP for bring-up and emulators. It is the RIL you get when there is no modem.

The baseband version is the same story. A real phone reports a modem firmware build like MPSS.DE.2.0.c3-00122-M8996FAAAANAZM-1. The emulator reports 1.0.0.0, a placeholder nobody ships.

So the telephony tell is not "no SIM". It is a perfectly ordinary SIM attached to a reference RIL and a placeholder baseband. The emulator fakes the part apps check casually, and leaves the part that requires real silicon with a string that gives it away.

GPU: the renderer string and the ANDROID_EMU extensions

This is the strongest one. The graphics stack advertises itself in more than one place.

$ adb shell getprop ro.hardware.egl
emulation

The EGL implementation property is literally the string "emulation". No real device says that. A real phone reports adreno, mali, powervr, or similar.

The OpenGL renderer string is worse:

$ adb shell dumpsys SurfaceFlinger | grep GLES
GLES: Google (Google Inc. (Google)), Android Emulator OpenGL ES Translator (ANGLE (Google, Vulkan 1.3.0 (SwiftShader Device (LLVM 10.0.0) ...

"Android Emulator OpenGL ES Translator". "SwiftShader Device". SwiftShader is Google's software renderer, a CPU implementation of Vulkan and GL. A real phone renders with a hardware GPU and reports something like "Adreno (TM) 730" or "Mali-G78". The emulator reports a software translator, because that is what it is.

Then there are the extensions. OpenGL lets an app query the list of supported extensions with glGetString(GL_EXTENSIONS). A stock emulator returns, alongside the standard ones, a family that only the Android emulator emits:

ANDROID_EMU_checksum_helper_v1
ANDROID_EMU_native_sync_v2
ANDROID_EMU_dma_v1
ANDROID_EMU_direct_mem
ANDROID_EMU_host_composition_v1
ANDROID_EMU_host_composition_v2
ANDROID_EMU_vulkan
ANDROID_EMU_YUV_Cache
...

There are more than twenty of them, all prefixed ANDROID_EMU_. They exist to let the guest and the host coordinate rendering through QEMU, and they are not present on any physical device, because no physical device runs on QEMU. A single glGetString call, a substring search for "ANDROID_EMU_", and the app knows.

This is the hardest one to fake, for the same reason as the kernel tells in part 1. The renderer string and the extension list come from the graphics driver, and the driver is part of the guest image. Changing them means shipping a different driver, not editing a property.

Why this layer is different

The props from part 1 are strings in a file. The kernel tells are strings from the boot command line. The hardware tells are behavior. A sensor HAL, a radio interface, a graphics driver. Each one is a piece of software that exists to talk to silicon the VM does not have, and each one reports its synthetic origin in its own way.

That is also why faking them is a different category of work. You cannot patch a vendor string and call it done, because the app reading that string is also asking the sensor for data, and the shape of that data has to match a real chip's. This is reimplementing a driver or a HAL, not editing a config file.

Across both parts the ladder is: props (editable), kernel (needs a custom ROM), hardware (needs a reimplemented driver). An app that checks all three is drawing the real line, and the line is not "is it an emulator", it is "how much work went into hiding it".

I have been measuring all of this while building enmulator, an open source Android emulator manager in Tauri 2 + Rust.

Educational security research. No working bypass, keys, or implementation details published.

If you build device detection, or you run automation that keeps getting flagged, this is the kind of problem I work on. DM me on X or reach me at enginozdal.com.

How apps spot an Android emulator (part 1): build props and kernel tells

engnzdl — Sat, 17 Oct 2026 13:24:01 +0000

How apps spot an Android emulator (part 1): build props and kernel tells

I spent a few days this month poking at a stock Android emulator to answer one question: what actually gives it away? Not the obvious stuff everyone lists, but the signals an app reads when it decides "this is not a phone". This is part one of what I found. It covers the two layers you can touch from userspace and the one you can't. Part two covers hardware and behavior.

Quick context on why this matters at all. Emulators are used for legit test automation and for bot farms that install an app thousands of times to farm bonuses. The app's defense side wants to separate a real user on a phone from a VM in a rack. Everything below is that detection, looked at from the inside.

The props layer: a file you can edit

Android exposes device identity through Build.* and the ro.* system properties. Most of them live in one file, build.prop. A stock emulator reports this:

$ adb shell getprop ro.build.product
emulator64_arm64

$ adb shell getprop ro.product.model
sdk_gphone64_arm64

$ adb shell getprop ro.build.fingerprint
google/sdk_gphone64_arm64/emu64xa:12/SGR1.210910.001/7793123:userdebug/dev-keys

Two things jump out. The model name sdk_gphone64_arm64 is not a device anyone has ever bought. And the fingerprint ends in userdebug/dev-keys, which is a build signing that does not ship to consumers. Every real phone in the wild runs user builds with release-keys. Those two strings alone are enough for a cheap first filter.

Here's what this layer actually is. An app reads these values with SystemProperties.get(), which is a string lookup into a shared memory region that init fills at boot from build.prop. It is a file, loaded into memory, read back as strings. With root you can rewrite any of it at runtime and it will happily lie until the next reboot.

I changed it the persistent way: boot the emulator with -writable-system, remount the system partition read-write, edit build.prop, reboot. The new values stuck. ro.build.product went from emulator64_arm64 to a real device's product name and stayed that way.

One flag is worth knowing about. The emulator documents -prop as a way to set properties at boot, and it worked on older versions. On recent versions it's dead: it sets nothing. The reliable path is editing build.prop directly, which is what I used for the rest of this.

So the props layer is fakeable, and everyone knows it. An app that checks only Build.MODEL is catching the VMs whose owners did not bother. That is the point of this layer in a detection stack: cheap, catches the sloppy cases, nothing more.

The kernel layer: the part that does not lie

The second layer is where it gets harder. These values do not come from a file you can edit. They come from the kernel and its boot command line.

$ adb shell getprop ro.kernel.qemu
1

$ adb shell cat /proc/cmdline
... androidboot.hardware=ranchu androidboot.hardware.platform=ranchu ... qemu=1 ...

$ adb shell grep -m1 "Hardware" /proc/cpuinfo
Hardware : goldfish

Three signals pointing the same direction. ro.kernel.qemu is set from a qemu=1 flag on the kernel command line when QEMU boots the guest. /proc/cpuinfo reports goldfish, the codename of the virtual platform the Android emulator has used for years. The kernel itself is a ranchu build, a fork of goldfish compiled for QEMU's virtual hardware, not for any shipping SoC.

I wanted to know whether these could be faked the way props can, so I tried. First I patched build.prop to change ro.hardware from ranchu to a real device's hardware name, rebooted, and checked. Still ranchu. Then I passed androidboot.hardware=... on the QEMU command line to try to override it at boot. Still ranchu.

The reason is that ro.hardware is not a build.prop key. init derives it at boot from androidboot.hardware on the kernel command line, and QEMU sets that when it starts the guest. My edit was ignored because the key I edited was not the key that set the value. To change it you need a custom kernel or a custom ROM, one recompiled with a different hardware identity or one that does not advertise QEMU at all. That is a build system problem, not a config tweak.

ro.board.platform behaved the same way, but for a different reason. I edited it in build.prop and it stayed empty after boot. That one is restricted by SELinux property contexts, so init refuses to accept the value from that file.

The kernel layer is the line. A spoofed build.prop gets caught here because the kernel keeps telling the truth. /proc/cpuinfo is the kernel reporting its own identity, and a userspace process asking for it gets the kernel's answer. This is what a serious detector checks after the props pass, and it is why the props layer alone was never going to be enough.

Where that leaves the first two layers

Props are cosmetic. They are rewritable and any detector worth the name treats them as such. The kernel layer is the real first filter, and it is where a VM leaves marks it cannot edit away from userspace without a custom ROM.

That split matters more than it sounds like it should. These signals look like the same kind of thing from the outside, just strings you could rewrite. They are not. Some of them come from a file, some of them come from the kernel, and the difference determines what you have to build if you want them to say something else.

Next part: the hardware and behavior layer. Sensors, telephony, the GPU renderer string, and why faking those convincingly means reimplementing drivers instead of editing files.

I have been measuring all of this while building enmulator, an open source Android emulator manager in Tauri 2 + Rust.

Educational security research. No working bypass, keys, or implementation details published.

If you build device detection, or you run automation that keeps getting flagged, this is the kind of problem I work on. DM me on X or reach me at enginozdal.com.

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:
    parsed = self.parse_authorization(authorization)
    if isinstance(parsed, dict):
        self.authorization_data.update(parsed)

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:
    parsed = self.parse_authorization(auth)
    if isinstance(parsed, dict):
        self.authorization_data.update(parsed)

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 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.