CreditTone/hooker: A Frida Reverse Engineering Workbench for Rooted Android Devices

What hooker actually packages, and who it is written for

hooker is a Python command line program that sits on top of Frida. The README describes it as a reverse engineering toolkit whose goal is to give Android reverse engineers a comfortable CLI plus a set of universal scripts, automatic hook generation, memory roaming to detect activities and services, a Frida port of JustTrustMe, and BoringSSL unpinning. The audience is narrow and specific: someone with a rooted physical Android phone plugged into a Mac, Linux or WSL host, who already understands what Frida does and wants the repetitive parts handled. The README states that the phone only needs root and that hooker starts frida-server itself, so no manual frida-server launch is required. The same line states x86 emulators are incompatible, which rules out the most common cheap test environment. The disclaimer is explicit that the project is for study and technical exchange, and that it does not include cracking operations against specific apps. That framing matters when you decide whether the tool fits your context.

The startup flow: device enumeration before any hooking

Running python3 hooker.py from inside the cloned directory prints a table of every debuggable app on the device. The README documents four columns. PID is the app's main process id, or 0 when the app is not running. APP is the display name. IDENTIFIER is the package name. EXIST_REVERSE_DIRECTORY is a check mark if the app has been debugged before and a cross if it has not. That last column is the interesting one: hooker keeps a per-app working directory, and its presence is what tells the tool whether it has prior state for that package. The README warns not to invoke the script by absolute path and to cd into the hooker directory first, which suggests the tool resolves its own resources relative to the current working directory. After you type a package name you get a help prompt listing the available operations. The README's table of contents enumerates them: embedded webserver, automatic Frida script generation, listing the app directory's Frida scripts, attach execution, spawn execution, SOCKS5 proxy setup, JustTrustMe, proxy teardown, app restart, uid and pid lookup, file pull, r0capture, and self-upgrade.

The bundled script catalogue is the real product

The README lists roughly two dozen scripts that ship in the per-app working directory, and that list is where the tool's value concentrates. Some are traffic and crypto oriented: url.js, ssl_log.js, just_trust_me.js, find_boringssl_custom_verify_func.js, hook_encryption_algo.js and hook_encryption_algo2.js. Some are UI and instrumentation oriented: activity_events.js, click.js, android_ui.js, edit_text.js, text_view.js, webview_enable_debug.js. Some target the runtime itself: hook_register_natives.js, jni_method_trace.js, hook_artmethod_register.js, trace_init_proc.js, dump_dex.js, keystore_dump.js, replace_dlsym_get_pthread_create.js. A third group is counter-detection: find_anit_frida_so.js, bypass_frida_svc_detect.js, bypass_root_detect.js, bypass_vpn_detect.js, apk_shell_scanner.js. There is even just_trust_me_for_ios.js, which sits oddly in an Android toolkit and is not explained in the material available. Note the file name find_anit_frida_so.js, which appears to contain a typo for anti. If you script against that path, use the spelling the README gives.

Getting it running: commands, dependencies and the WSL path

The setup sequence in the README is four steps. Clone the repository, install Python dependencies with pip3 install -r requirements.txt, confirm the device with adb devices, then run python3 hooker.py from inside the hooker directory. Badges in the README pin Python 3.8.8 and Frida 16.7.19, so those are the versions the author was working against; treat them as the supported baseline rather than a hard requirement, since the README does not state a version check. Windows users are told to install WSL first, specifically Ubuntu 24.04, then configure a proxy inside WSL, then install Python 3.8 and Frida there. The README also documents a custom frida-server option, which matters because the bundled server has to match the target device's ABI and Android version. There is an upgrade command listed as hooker automatic upgrade, so the tool can pull its own updates. The README does not document configuration file keys; the only stated configuration surface is the per-app working directory and the custom frida-server setting.

The embedded webserver is the most under-documented feature

The README's own pitch list puts the embedded webserver second, describing it as a way to expose an app's internal capabilities as HTTP interfaces for automation. That is a meaningfully different use case from interactive hooking: it turns a session into something a test harness or CI job could call. The README also has a section titled developing phone API interfaces and another listing hooker's native operation API, so the design intent is clearly that users write their own scripts against a stable set of primitives. What the available material does not give is the HTTP surface itself: no port, no route names, no request or response shapes. Anyone planning to build automation on this should read the source rather than the README, because the README stops at saying the capability exists. The same gap applies to the automatic Frida script generation feature, which is named in the pitch and the table of contents but not specified in terms of input or output.

Where hooker breaks down, and what to use instead

Three concrete limits are visible in the material. The README states x86 emulators are incompatible, so the fast iteration loop of an emulator snapshot is closed off and you need real hardware. The device must be rooted, which on modern Android means an unlocked bootloader and the attendant trade-offs. And the counter-detection scripts exist precisely because apps detect Frida, root and VPN; their presence in the catalogue is an admission that detection is an ongoing arms race rather than a solved problem, and the README offers no claim about which apps they currently defeat. For a different approach, consider objection, which is also Frida-based but drives instrumentation over a REPL and a JavaScript API rather than a menu of pre-written scripts, and which targets both Android and iOS from one interface. The practical difference: hooker hands you a fixed set of scripts plus a Python CLI and a per-app working directory, so you trade flexibility for speed on common tasks. objection gives you a live console and expects you to write the hooks. If your work is one-off and exploratory, objection's model fits better. If you repeatedly run the same unpinning and dump routines across many apps, hooker's catalogue is the point.

Maintenance cost and the missing licence

The repository has no releases, so there is no versioned artefact to pin. Updating means pulling the master branch, and the README's own upgrade command suggests the author expects users to track master rather than a tag. That is a real cost: a change to a bundled script or to the CLI's output format lands on you the next time you upgrade, and there is no changelog in the material to read first. The pinned Frida version is the other moving part. Frida's own releases change the internal APIs that scripts like hook_register_natives.js and hook_artmethod_register.js depend on, so a Frida bump on the device side can break scripts that worked the week before. On licensing, the repository does not declare a licence, and the README carries only a disclaimer limiting use to study and technical exchange. Without a licence file, the default is that all rights are reserved, which means you have no granted right to redistribute or embed the code. That is a factual observation about the repository state, not legal advice; if you intend to use hooker inside a commercial product or an internal pipeline that ships to customers, get your own counsel to look at it before you do.

Editorial conclusion

Adopt hooker if you already work on a rooted ARM Android device over USB and want a single CLI that starts Frida, lists debuggable apps and runs packaged scripts such as just_trust_me.js and dump_dex.js. Do not adopt it for x86 emulators, for iOS work, or if you need a clearly stated licence before shipping it inside a commercial pipeline, because the repository does not declare one. Verify three things before relying on it: the Python and Frida versions pinned in requirements.txt against your host, whether your target app is listed as debuggable, and whether the app's own anti-Frida checks defeat the bundled bypass scripts. Then read the script you intend to run.

Official sources

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