hooker: A Frida-Based CLI Workbench for Android Reverse Engineering

What hooker Does and Who It Is For

Android app analysis with Frida typically requires manually pushing a frida-server binary to the device, starting it as root, confirming it is running, and then writing or sourcing JavaScript hook scripts. hooker automates that entire flow. It is aimed at Android security researchers, CTF participants, and developers who need to inspect how a closed-source app handles its SSL certificates, API calls, or internal Java method calls. On startup, hooker scans all installed apps, lists their PIDs and package identifiers, and presents an interactive prompt. The researcher types a package name, and hooker checks whether the app is running, brings it to the foreground if it is not, and creates a per-app working directory stocked with the project's bundled scripts. The result is a session where the researcher can attach Frida scripts, run built-in hooks, or start an embedded web server inside the target process, all from a single command line.

How hooker Deploys and Manages frida-server

The mechanism that makes hooker distinct from raw Frida usage is its automatic frida-server lifecycle management. When the tool starts, it detects the architecture and Android version of the connected device over ADB, downloads a matching frida-server binary if one is not already present, pushes it to the device, and starts it with root privileges. This removes the setup step that causes the most first-time friction with Frida. The working directory that hooker creates for each app contains the bundled JavaScript scripts, shortcut shell commands for common Frida operations, and a copy of the app's APK pulled from the device storage. If a working directory already exists from a previous session (shown with a check mark in the listing), all prior scripts and notes are preserved.

Installing hooker and Starting a Session

hooker runs on macOS and Linux directly. Windows users must install WSL first. Clone the repository and install the Python dependencies:

git clone https://github.com/CreditTone/hooker.git
cd hooker
pip3 install -r requirements.txt

The requirements.txt pins specific versions: frida==16.7.19, frida-tools==13.7.1, adbutils==1.2.11, androguard==3.3.5, jsbeautifier==1.15.4, plus gitpython and loguru. Connect a rooted phone over USB and confirm ADB sees it:

adb devices

The output should list the device serial and the word `device`. Then start hooker from the project directory (an absolute path will fail because hooker resolves scripts relative to its own location):

python3 hooker.py

Hooker prints a table of every installed app with its PID and package identifier. Type the package name at the prompt and press Enter. The tool checks whether the app is in the foreground, brings it there if needed, and copies the bundled scripts into a new directory named after the package. From that point the interactive session accepts commands such as `attach`, `spawn`, `help`, and `webserver start`.

The Embedded Web Server and HTTP-Accessible App Internals

One of hooker's more unusual features is an embedded HTTP server that it injects into the target app's process. Starting it is a single command in the interactive session:

webserver start

Hooker responds with the local IP and port (default 8080). Opening that address in a browser shows a list of all registered API endpoints. The endpoints cover a wide range of instrumentation tasks: clicking UI elements by text or coordinates, scrolling RecyclerViews, getting screen layout as JSON or XML, capturing screenshots with screencap or MediaProjection, reading SharedPreferences and SQLite tables, invoking static methods by class and method name, and fetching app metadata including package name, version, permissions, and signing certificate. This approach is useful for building lightweight automation against a target app or for quickly reading internal state without writing and redeploying Frida scripts each time.

Built-In Scripts: SSL Unpinning, Traffic Capture, and Anti-Detection

The per-app working directory contains more than twenty JavaScript scripts that hooker generates from its bundled library. The SSL unpinning scripts cover two strategies: just_trust_me.js patches the standard Java TrustManager and HostnameVerifier, while find_boringssl_custom_verify_func.js targets the BoringSSL native layer used by apps that bypass the Java layer. ssl_log.js captures plaintext SSL traffic for apps that use the native SSL stack. For anti-analysis bypass, the library includes bypass_frida_svc_detect.js (hides Frida from syscall-based detection), bypass_root_detect.js, and bypass_vpn_detect.js. On the extraction side, dump_dex.js pulls the decrypted DEX from memory for apps using runtime protection, and keystore_dump.js intercepts private key material as it passes through the Android Keystore API. The hook_encryption_algo.js and hook_encryption_algo2.js scripts trace common encryption calls. Researchers can edit any script directly in the working directory and reload it without restarting hooker.

Limitations: Hardware, Architecture, and Legal Boundaries

hooker has firm technical boundaries that matter before investing setup time. The README states explicitly that x86 architecture emulators are not compatible; the tool targets ARM and ARM64 physical devices with root access. Root is a hard requirement: hooker cannot push or start frida-server without it, and standard Android phones from consumer markets are not rooted. Windows users add WSL as a prerequisite, which introduces its own USB passthrough complexity for ADB. The project carries no GitHub releases, so the install is always from the master branch at a specific commit; the pinned dependencies in requirements.txt tie the tool to frida==16.7.19, which will conflict if any other Python project in the same environment uses a different Frida version. Finally, the README includes a prominent disclaimer: all content is for personal learning and technical exchange only. Using hooker to inspect apps the researcher does not own or does not have authorisation to test is outside the stated scope and carries legal risk.

Comparison to Using Raw Frida

Raw Frida is the underlying engine that hooker wraps. Using Frida directly offers more flexibility: any device that supports frida-server (including some x86 setups), any scripting language supported by the Frida bindings (Python, JavaScript, Swift, C), and no dependency on hooker's working-directory conventions. The trade-off is manual setup for every session: pushing and starting frida-server, writing hook scripts from scratch, and managing SSL unpinning logic that hooker bundles as ready-to-run files. For one-off experiments or when working on a platform hooker does not support, raw Frida is the better path. For repeated sessions against multiple Android apps where the bundled scripts cover the needed tasks, hooker removes a significant amount of session-management overhead. jadx is a different class of tool entirely: it performs static decompilation of APKs and does not require a running device, which makes it the starting point for analysis where dynamic instrumentation is not yet needed.

Editorial conclusion

Security researchers who do mobile app traffic analysis or instrumentation on rooted Android hardware will get real utility from hooker: it eliminates frida-server setup and gives a ready library of 20-plus scripts covering SSL unpinning, dump-dex, keystore extraction, and encryption hooks. Developers working on x86 emulators or unrooted devices cannot use it at all. Before committing, verify that your phone architecture is ARM or ARM64, confirm Python 3 and adb are installed, and review the disclaimer the project publishes: hooker is intended for personal learning and authorised research, and using it on apps without permission crosses legal boundaries regardless of how the tool was obtained.

Frequently asked questions

Official sources

1. CreditTone/hooker on GitHub
2. Issues
3. README