bba runs cloned Android apps inside a sandboxed host package and lets authorized analysts inject QuickJS scripts through Spindle, a command-line client styled after the frida toolchain.
| Tool | openbba0/bba — an Android app-cloning sandbox with a Frida-style CLI that injects QuickJS scripts via Frida Gum hooks |
| Category | Mobile dynamic analysis / instrumentation framework |
| Primary Use | Authorized analysis of Android app behavior in an isolated clone, using Interceptor and Stalker hooks driven by the Spindle client |
| Safe Use | Intended for authorized security assessments, malware research in lab sandboxes, and defensive analysis of apps an analyst has permission to examine |
| Telemetry Note | Runs only inside the com.android.bba host package on the analyst's own device; USB mode uses adb forward to 127.0.0.1:2408, leaving a local, auditable TCP footprint rather than remote indicators |
bba is an Android app-cloning sandbox that answers a question mobile analysts face constantly: how do you observe an application's runtime behavior without installing it as a normal app on a dedicated device? Instead of a conventional install, a cloned application executes inside the host package com.android.bba, which acts as a containment shell around the target. The project is written primarily in C, ships under the Apache-2.0 license, and currently sits at 28 stars on GitHub — small, but clearly an engineering-driven effort rather than a weekend wrapper. The companion command-line client is called Spindle, delivered as a python3 script under tools/, and it deliberately mirrors the ergonomics of the frida CLI so that experienced operators can transfer their muscle memory directly.
The README's architecture description is unusually precise about process boundaries, which is where the design gets interesting. The development machine never talks to a cloned app directly. It connects only to the host process com.android.bba:black listening on 127.0.0.1:2408 over TCP. The host and each individual clone act as agents: they register themselves with that endpoint over Android's Binder IPC, receive injected scripts, and stream logs back. In USB mode, Spindle transparently runs adb forward tcp:0 tcp:2408, so the operator does not have to manage port forwarding by hand. This broker pattern keeps all instrumentation traffic local to the device and a single loopback socket, which is a cleaner containment story than tools that scatter debug servers across processes.
Spindle's flag surface will feel immediately familiar to anyone who has driven frida-cli. Spawn is -f, attach by name is -n, attach by PID is -p, and scripts load with -l, with -e accepting a one-liner inline. The README shows the canonical invocation as python3 tools/spindle -U -f com.example.app -l tools/test_js_api.js, and that is about the extent of what you need to get started; connection selection is handled by exactly one of -U (USB), -D <serial> (a specific device), or -H 127.0.0.1:2408 (an already-forwarded port). The constraint model is strict and documented: pass only one connection flag, and only one of -f, -n, -p. Multiple devices are supported through the serial form, which matters for lab racks running parallel analysis phones.
The spawn semantics deserve attention because they solve a classic race condition in early-startup instrumentation. When -f is used, the client sends the script and then a frame the README calls UNLOCK. The clone deliberately blocks on its startup path until that frame arrives, guaranteeing hooks are resident before Application.onCreate executes. For analysts chasing initialization-time behavior — anti-debugging checks, root detection, certificate pinning setup — this determinism is the difference between reproducible traces and flaky ones. Note that -f always operates on user 0, and attaching with -n requires the target process to have already registered with the host, with names matching the package name Spindle recorded.
The scripting runtime is QuickJS, not the V8-derived engine you might expect, and it exposes Frida Gum primitives from native code. That means Memory operations, raw pointers, Module enumeration, Interceptor.attach, Stalker.follow, a Java.hook bridge, and rpc.exports are all available from plain JavaScript. The repository ships five example scripts in tools/ covering each surface: test_js_api.js for the memory and module API, test_native_hook.js demonstrating Interceptor.attach("libz.so!deflate", …), test_java_hook.js hooking Activity.onCreate, test_stalker.js for instruction-level tracing started from inside a hook, and test_rpc.js for bidirectional calls. Console output from the injected script flows back to the terminal as log lines until the process exits, the server drops, or the operator interrupts with Ctrl-C.
There is one significant platform limitation: scripts run on arm64 only. On armeabi-v7a devices there is no embedded runtime at all, and an RPC attempt there returns the error string js runtime is not in bba. This is an honest constraint, and labs still holding 32-bit test devices will need to account for it when planning hardware. The restriction is consistent with where modern Android malware analysis is heading anyway, since most current targets ship arm64 natives, but it is worth verifying before building a workflow around the tool.
The RPC mechanism rounds out the interactive story. After a script loads, Spindle can invoke exported functions by name, pairing each --call with a --args JSON array. The README's example loads tools/test_rpc.js, calls the ping export with the argument hi, and receives pong hi before the client settles back into log-listening mode. This turns the sandbox from a passive tracer into a queryable analysis harness — an analyst can enumerate loaded modules, dump structures, or interrogate the Java heap on demand without restarting the target. Process discovery is covered too, with --list emitting registered processes as JSON and the companion tools/spindle-ps -U rendering the same data as a table, including the host UI process com.android.bba itself, which is also attachable by PID.
From a defensive and authorization standpoint, the tool's footprint is inherently local and self-documenting. Everything an operator does is mediated through the com.android.bba host package on a device they control, and the only network surface is a loopback TCP endpoint created via adb forward. There is no remote C2 infrastructure, no cloud callback, and no persistence outside the sandbox package — cloned apps simply do not exist as normal installs. This makes bba a good fit for authorized contexts: internal app-vetting programs, malware triage in isolated device labs, and academic study of obfuscated Android payloads, all under the Apache-2.0 license that permits audit and modification of the runtime itself. It is not a tool for touching devices or applications you lack permission to examine, and its design doesn't really accommodate that anyway.
The documentation closes with a bilingual note — a README.zh-CN.md translation exists — and a WeChat community group named openbba with a QR code expiring on 20 October 2026, suggesting an actively maintained project with a developer audience in the Chinese Android security community. What bba ultimately offers is a tidy synthesis: the spawn/attach mental model of frida, the lightweight embeddability of QuickJS, and the isolation guarantees of app cloning, all mediated by a Binder-registered agent architecture. For teams that want Frida-Gum-grade native and Java hooking without installing targets conventionally, it is a project worth cloning, building, and kicking around in a lab.
If you want to evaluate it yourself, the entry points are minimal: fetch the repository with git clone against openbba0/bba, build or obtain the host APK, and drive the sandbox through python3 tools/spindle -U --list to see registered processes before loading any of the bundled test_*.js samples against a target you are authorized to analyze.
openbba0/bba.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.