DroidHunter: a CLI Android security assessment framework from HexSecTeam

Who DroidHunter is for, and the problem it collapses

An Android assessment normally means juggling several unrelated tools. adb for device state, apktool or a disassembler for the APK, a port scanner for the network side, a proxy for traffic, and something else again for the write-up. DroidHunter's pitch is that one Python entry point, droidhunter.py, wraps all of those behind a single interactive menu or a set of long flags. The README describes it as a "comprehensive, CLI-based Android security assessment framework targeting ethical hackers and professional penetration testers" and repeats the authorization warning twice, once in the header and once in the overview.

The audience is narrow on purpose. You need a physical or emulated Android device you are allowed to test, a workstation running Linux or macOS (the badges list Platform as Linux | macOS), and enough ADB familiarity to know what a device serial is, because most CLI examples take --device ABC123. If you are auditing an APK you downloaded and have no device at all, only part of the tool applies: the APK Analyzer path takes a file, while the vulnerability scanner, port scan, logcat and screenshot paths all need a connected device.

How DroidHunter is put together: one script, a modules directory, three dependencies

The repository layout is shallow. At the top level there is droidhunter.py, a modules/ directory, requirements.txt, LICENSE, README.md and assets/. The dependency list is three packages: rich, requests and colorama. That tells you the interactive interface is built with rich, and that the tool is not pulling in a heavyweight analysis engine of its own. Anything that needs a real engine, such as msfvenom for payload generation, is treated as an external program you install yourself.

The README's feature table names eight modules: Device Manager, APK Analyzer, Network Scanner, Vulnerability Scanner, Exploit Engine, Payload Generator, Report Generator and Remote Control. The data flow implied by the CLI examples is consistent: a device serial or an APK path goes in, a module collects raw output from adb or from static inspection, and the report generator turns it into HTML, JSON, or a CLI table. The --report flag accepts html, json or both, and the README says the HTML output is dark-themed and carries remediation advice.

Two design choices are worth flagging. First, the tool shells out to adb rather than speaking the ADB protocol itself, so your adb version and your PATH decide what works. Second, the Exploit Engine and Payload Generator are grouped with the assessment modules in the same menu, which is convenient for a lab and risky in any other setting.

Installing DroidHunter and running a first APK analysis

The README gives a numbered install sequence. It assumes you are already inside the cloned directory, so clone first if you have not. The virtualenv step matters because the project pins rich, requests and colorama in requirements.txt and you do not want those mixed into a system Python.

git clone https://github.com/hexsecteam/DroidHunter.git
cd DroidHunter
python -m venv venv
source venv/bin/activate
pip3 install -r requirements.txt

After pip finishes, requirements.txt lists rich>=13.0.0, requests>=2.31.0 and colorama>=0.4.6, so a successful run leaves those three importable inside the venv. ADB is optional in the README's wording, but only if you skip the device modules; on Debian or Ubuntu the README suggests sudo apt install adb, and on Arch sudo pacman -S android-tools. scrcpy is a separate optional install for the Remote Control menu, and Metasploit is optional for payload generation.

The first thing most people can run without a device is the APK path. The README's example generates an HTML report and names the target:

python3 droidhunter.py --apk target.apk --report html --target-name "com.example.app"

You should get an HTML report on disk describing permissions, potential secrets and exported components, since those are the three items the feature table attributes to the APK Analyzer. If you would rather work from a menu, python3 droidhunter.py with no arguments, or with --interactive, opens the interactive mode the README calls recommended.

Once a device is attached and authorized, the pattern is the same with a serial added. Listing devices is the sanity check before anything else:

python3 droidhunter.py --devices
python3 droidhunter.py --device ABC123 --info

The first command should print the attached devices; the second prints the full device info for the serial you pass. Replace ABC123 with the serial from the first command, not with the placeholder.

What the APK Analyzer actually claims to check

The README's module section is where the specifics live, and it is also where the text is truncated. What survives is a permission audit that flags "30+ dangerous Android permissions by severity (CRITICAL -> LOW)", plus secrets and exported components, and a CVE mapping step. The vulnerability scanner module is described separately as covering CVE mapping, root detection, insecure storage, WebView issues and task hijacking.

That split is worth understanding before you trust a report. Static findings from an APK are candidates, not confirmations. A permission in the manifest does not mean the permission is exercised; an exported component does not mean it is reachable in a way that matters. DroidHunter appears to present these as severity-ranked findings with remediation advice, which is the right shape for a report but not the same as a proof. The CVE check on the device side works from the Android version, according to the README, so it can only be as accurate as the version string the device reports.

The secrets detection has the same character. The README does not describe the matching rules, so you cannot tell whether it is regex-based string hunting or something with entropy scoring. Treat a clean APK report as "nothing matched the built-in rules", not as "no secrets".

Device control, WiFi ADB and the scrcpy dependency

The Device Manager is the part that most resembles a convenience wrapper, and the README is unusually explicit about one of its constraints. DroidHunter supports both Manual ADB WiFi Connect and Auto ADB WiFi Connect. The auto path "requires the phone to be connected by USB first, USB Debugging enabled, and both devices on the same WiFi network." Those three conditions are not optional, and the USB step means the wireless mode is really a way to unplug after initial setup rather than a way to start from nothing.

Remote Control is a single feature with a hard external requirement: it opens a Remote Screen through scrcpy from the interactive menu. If scrcpy is not installed, that menu item has nothing to call. Nothing in the README suggests DroidHunter ships a mirroring implementation of its own.

The rest of the device surface is what you would expect from adb: screenshot, logcat with a line count (--logcat 200 in the example), file pull and push, WiFi info, and a subnet discovery mode that takes a partial address such as --discover 192.168.1. Note that subnet discovery is a network operation, not a device operation, so it does not need --device.

Where DroidHunter is the wrong tool

The most concrete limitation is platform. The README badges list Linux and macOS only. There is no Windows install path in the instructions, and the ADB and scrcpy steps are apt and pacman commands. A tester on Windows is outside the documented support surface.

The second is that the offensive modules are not sandboxed from the assessment modules. The Exploit Engine can launch activities, trigger broadcasts, dump content providers, fuzz deep links and drop a shell over ADB, and the Payload Generator can produce a msfvenom APK or a reverse shell one-liner. All of that sits in the same interactive menu as --info and --logcat. If you only want static APK analysis for a code review, this is more tool than the job needs, and the blast radius of a mistyped flag is larger than in a read-only scanner.

The third is verification depth. Nothing in the README describes a rollback for the ADB WiFi change, a way to undo a pushed file, or a dry-run mode for the exploit commands. The README is silent on all three. It is also silent on whether the report generator deduplicates findings across modules, which matters when you run an APK analysis and a device scan against the same package in one command, as the last CLI example does with --report both.

Alternatives and how their approach differs

The obvious split is between all-in-one frameworks and single-purpose tools. MobSF takes the opposite approach: it is a web application you run, you upload an APK or point it at a device, and it produces a scored report through a browser interface. DroidHunter keeps you in the terminal and drives a locally attached device over adb, which makes it better suited to a lab bench where the phone is in front of you and worse suited to a shared server where several analysts submit samples.

For the static side alone, apktool plus a decompiler gives you the decoded resources and smali without any opinion about severity, and you write your own checks. DroidHunter's value there is the severity ranking and the report output, not the decoding. For the dynamic side, Frida and Objection give you runtime instrumentation that DroidHunter does not claim to offer; its dynamic features are adb-level actions and an SSL pinning check, not hooking.

For network work, a general port scanner or a proxy like mitmproxy covers the same ground with more depth. DroidHunter's --mitm-guide is described as a guide, not an interception engine, so it points you at a proxy rather than replacing one. The honest summary is that DroidHunter is a coordinator. If you already have the specialist tools, it saves typing; if you do not, it will not substitute for them.

Maintenance, licence and upgrade cost

The last push to the default branch was on 2026-05-12. The repository is not archived, and no releases were retrieved, so there is no tagged version to pin against. The README badge says Version 2.0.0, but with no release artifacts the version string is documentation rather than something you can install by tag. Practically, that means upgrades are git pulls against main, and you should read the diff before pulling because there is no changelog in the README.

The dependency surface is small, which keeps upgrade cost low: three packages in requirements.txt plus whatever ADB, scrcpy and Metasploit versions your distro ships. The external tools are where breakage will come from, since adb output formats and scrcpy flags change independently of this project.

On licensing, the README badge says Educational while the repository metadata says MIT. Those two statements are not the same thing, and the badge is the more restrictive wording. The LICENSE file at the top level is the authoritative text; read it and, if the Educational label reflects the author's intent, get that clarified in writing before using DroidHunter in commercial client work. That is a question for your own counsel, not something this article can settle. The README also carries a USDT donation address on Ethereum ERC-20, with a warning that funds sent on another network may be lost permanently.

Editorial conclusion

DroidHunter fits testers who already have ADB and scrcpy on a Linux or macOS workstation and want one menu for device control, APK inspection and reporting, and it is a poor fit for Windows users or anyone without written authorization for the target device and app. Before adopting it, verify that your Python is 3.8 or newer, that requirements.txt installs cleanly in a virtualenv, and that the modules you plan to use exist under modules/, since no release artifacts are published and the README does not document rollback.

Frequently asked questions

Official sources

1. hexsecteam/DroidHunter on GitHub
2. Issues
3. License: MIT
4. README