Back to blog

Introducing Rutken

Most Android security tooling makes you choose a side. You reach for a decompilation tool and a rules engine to read an APK statically, and a completely separate stack (Frida scripts, proxy setups, a rooted device) to watch it actually run. The two worlds don't share data, don't share a findings model, and rarely agree on what a "finding" even is. Rutken exists because that split is an artifact of tooling history, not a property of the problem.

Rutken reads an APK the way an attacker would: it decompiles the app, follows how untrusted data moves through it, and correlates everything into findings a human can act on. Static analysis (decompilation, data-flow and taint tracking, rules, and software composition analysis against known CVEs) is the foundation, and it's free in the Community tier, in full, with no feature countdown.

Why speed is a feature

Speed was a design goal, not a late optimization. Tools that take minutes per APK push analysts toward sampling instead of coverage. You scan the app you're worried about, not the hundred you should be checking. Rutken is fast enough that scanning a whole device's worth of apps, or gating a CI pipeline on every build, is something you can actually afford to do on every run.

Static and dynamic, one engine

The same analysis layer that powers static findings also drives Rutken's dynamic side: live traffic capture, TLS unpinning, and active intervention against a running app on a real device or emulator. Instead of two tools disagreeing about what a given code path does, Rutken's static data-flow results tell the dynamic side where to look, and what it observes at runtime corroborates or extends the static picture, in the same findings model, not a separate report you reconcile by hand.

The bespoke hooking engine

Frida is excellent, and Rutken uses it where it fits. Community includes a live-capture path built on it. But Frida-style instrumentation has real limits: some targets resist repackaging, some devices and hardened apps detect and kill injected runtimes, and some interventions need finer control than a general-purpose scripting bridge gives you. So we also built our own: a bespoke, in-house hooking engine designed for no-repack delivery and precise, low-footprint intervention on real hardware. It's purpose-built for the cases where off-the-shelf instrumentation struggles, and it's part of what the paid tiers add on top of the free static foundation.

Rutken is offensive and defensive in the same breath. The same engine that finds a vulnerability can help you demonstrate and exploit it, because a finding you can't corroborate on a live target is just a guess. That's the product. If you want to see it on your own APKs, the docs will have you scanning in a couple of minutes.