Reverse-Engineering a Tool That Was Too Fast

My partner bought an AI image-generation tool. It was cheap, it worked, and it was suspiciously fast. It opens a browser, generates images, saves them — but there's no visible automation, no simulated clicks, no browser history on the page. The whole thing runs so smoothly it feels like it's not doing what it appears to be doing.

We needed to know how it worked, because our pipeline had a gap: we generate videos in bulk, and the tool had no API. If it was just driving a browser, we could either replicate it or integrate it. If it was doing something cleverer, we wanted to know what. So began weeks of poking at a black box that mostly didn't want to be opened.

The hypothesis

The first observation: the tool opens a browser (Firefox, of all things) but shows no scripted interactions — no cursor movement, no form fills, no visible automation frame. That's unusual. Browser automation is normally loud — there are mouse trajectories, input events, elements being clicked.

When a browser appears to do nothing yet work happens, the strongest hypothesis is that the tool is not driving the browser at all. It's calling the underlying service's API directly, and the browser window is theater — a decoy so the user (and the vendor's licensing) believes a real account is being used.

The toolchain we brought

The attack plan had two prongs:

1. Network sniffing. Watch what the tool actually sends. If it calls an API directly, the requests appear as clean HTTP to a service endpoint — no browser chrome, no websocket to a page, no DOM events. The traffic itself would tell us the mechanism.
2. Decompiling the client. The tool ships as a packaged app. If it's built on a JS runtime, the logic is recoverable — you can unpack it and read the code.

What the forensics said

The network side pointed toward direct API calls: the requests looked like a client talking to a service, not a browser talking to a page. That fit the "API direct, browser is a decoy" theory.

Then decompilation gave us the truth about the stack: the tool is built on Hermes — the JavaScript engine — and it embeds Playwright. Playwright is a browser-automation library. So the tool does drive a browser... but the way it's wired up is engineered to be invisible: Playwright's stealth mode suppresses the automation fingerprints that would normally show up, and the visible window is only one part of what's running.

We never fully cracked it. The decompile showed us the building blocks — Hermes runtime, Playwright, Google-account-based auth — but not the exact call sequence, and I eventually stopped. Here's the honest part I don't see written down enough in "how I reverse-engineered X" posts: sometimes you don't get the whole answer, and you have to decide whether the remaining unknown is worth the hours.

What I actually learned

• The invisible thing is usually just the familiar thing wearing a coat. Playwright in stealth mode isn't magic — it's the same automation library you know, with the tells removed. The "we can't explain this" mystery was, at bottom, "a browser driver with a stealth flag."
• Fast + no visible automation = API, or stealth browser. Those are the two ways to make a tool "do things without looking like it's doing things." The diagnostic path splits immediately based on which you believe.
• Decompiling tells you the stack, not the sequence. Knowing it's Hermes + Playwright was genuinely useful — it told us what to look for and what to replicate. It didn't hand us the integration, because the integration was a sequence of calls, not a library.
• Rate limits were the real bottleneck all along. The tool's actual value wasn't the clever stealth — it was that its account had image quota we were burning through. The mechanism was interesting; the quota was the business. We spent weeks on the mechanism and should have spent them on the quota.

The honest ending: the tool's exact mechanism still sits in the "mostly understood, not fully" bucket. We built our own path to bulk image generation instead, and the tool became a footnote. Reverse-engineering taught me more about what not to chase than what to build — and sometimes the most valuable output of a forensic session is the decision to stop and go build your own thing.