The anatomy of an APK teardown (and where the days go)
Someone hands you an APK and asks what's wrong with it. If you've done this for a living, you already know the shape of the next few days, because taking an Android app apart the normal way isn't one task, it's a relay race between a dozen tools, and you're the baton.
Day one is static. You unzip the package, run it through apktool and jadx, and start reading. Smali when the decompiler chokes, Java when it doesn't. You grep for secrets, for endpoints, for the crypto calls, and you start building a mental model of how data moves. Then you hit a wall: the interesting method is obfuscated, or it only makes sense at runtime, so you make a note and move on. Except "move on" means re-running the decompiler with different flags, or going back to re-read a class you already read, because the thing you need now didn't matter an hour ago.
Day two is dynamic, and it's a different stack entirely. A rooted device or an emulator, Frida, a proxy, certificates to wrangle. You write a hook to watch the method you flagged yesterday, and when it doesn't fire the way you expected, you tweak the script and try again. And again. Every loop is cheap on its own and expensive in aggregate.
By day three you're doing the part no tool did for you: correlating. You have static notes in one place, runtime logs in another, and the actual finding lives in the gap between them, in your head. You reconcile it by hand and write it up. Here's that whole shape, next to what we think it should be:
That's the real insight when you draw it out. No single box on the left is slow. What's slow is that nothing on the left shares a findings model, so you are the integration layer, carrying state between tools that don't talk to each other, and paying the context-switch tax on every hop. The loop back to "read code by hand" isn't a bug in your process; it's what happens when the static tool and the dynamic tool can't tell each other what they learned.
The right side is the same work, minus the relay
Rutken's version isn't fewer ideas. It's the same static analysis and the same dynamic analysis, run as one engine instead of a relay. The static pass decompiles, tracks taint and data flow, runs the rules, and does software composition analysis in a single go. Then it aims the dynamic pass: the data-flow result tells the runtime exactly which method to hook, so you're not guessing where to put a Frida script. And both land in one findings model, which means the correlation that used to live in your head is just… there. Finding, proof, and report, without reconciling three sources by hand.
None of this is magic, and we're not claiming the hard problems disappear. The point is narrower and, we think, true: the split between static and dynamic was never a property of the problem. It was an artifact of how the tools grew up separately. Collapse the split and the days collapse with it.
If your last teardown looked like the left-hand column, the right-hand one is free to try. Grab Rutken, point it at an APK, and see how much of day one you get back. The docs have you scanning in a couple of minutes.