Design brief · Researched 23 Oct 2026
Deep research into the modern tool-installer landscape, practitioner blogs and hacker-community benchmarks, plus a hands-on baseline test of the current version in a VM. The conclusion is blunt: the classic DarkFly model is dead, and practitioners have already replaced it. DarkFly v4, Tool-X, AllHackingTools, Lazymux and Katoolin all share one design, a numbered menu over hundreds of hard-coded repos, installed with git clone and Python 2, with no pinning, no uninstall and no verification. They share the same failure modes too.
The replacement model, agreed by Kali, Black Hills Information Security, ProjectDiscovery, SpecterOps and Exegol: a small curated catalog, installs through a real package manager wherever possible, and every install pinned, recorded and reproducible. This page is the blueprint for building DarkFly that way.
Star counts are point-in-time readings from the web index on 2026-10-23 and will drift. Research confidence: high for the landscape, patterns, safety and Termux findings; medium-low for all published speed benchmarks, which are self-reported (see Benchmarks).
The engine described on this page is built and published. Install the package, then run the new CLI.
Package: darkfly-tool 5.1.1 on PyPI · Source and releases: DarkFly-Tool on GitHub · v5.1.1 release. Use only on systems you own or have permission to test.
Every classic installer fails the same five ways. Each one is documented, not opinion, and each maps to a design rule for the new version.
Sources: DarkFly v4 repo · Linux Mint forum, Katoolin breakage · AllHackingTools remote config check
Sources: Kali metapackages · BHIS cheatsheets · Exegol on reproducibility
The clone field is saturated: a new entrant cannot win on "more tools, new banner". The projects practitioners actually respect solve a different problem: curation, signed packages, and lifecycle management.
| Project | Catalog | Install method | UX | Why users like / abandon it |
|---|---|---|---|---|
| DarkFly v41,980 ★ · 407 forks · 0 releases · since 2018 | Hard-coded, partly obfuscated in Python 2; 530 tools claimed + 7 SMS-spam tools | pkg install python2 git, then pick by number | Numbered menu: show all / about / uninstall / exit | Liked for zero searching. Abandoned: Python 2, Linux path broken per its own README, updates delete the old install. |
| DarkFly v5 (current)131 ★ · 30 forks · 2 releases · Python 3.10+ | Small JSON catalog, config-driven and extensible | None yet for listed tools: list / info show suggested commands only | CLI subcommands + simple menu | The right direction (Python 3, JSON, Linux + Termux), but it does not actually install, has no search, and only 8 entries today. |
| Tool-XStar count not verified, see open questions | Hard-coded list, 370–377 tools claimed, by category | git clone + per-tool clone/apt scripts | Numbered menu | Same one-click promise, same failure modes. The canonical clone URL itself drifts between authors (Rajkumrdusad in old guides, ekadanuarta in 2025 guides), a supply-chain smell in itself. |
| AllHackingTools~2.2 GB installed footprint claimed | Categorised menu, 370+ tools claimed | bash Install.sh; clones into a central Tools dir | Categorised menu + Termux theming | Illustrates a red flag: it fetches a remote system.txt token and compares it before the menu even opens. Exactly what a trustworthy installer must never do silently. |
| ALHacking18 fixed menu options | One menu slot per tool: zphisher, CamPhish, DDoS-Ripper, RED_HAWK, Facebash… | Clone into Tools dir, install deps, run with bash/python/php | Single numbered menu, 1–18 | Shows the genre's skew: menu space goes to phishing, webcam and DDoS tools instead of the practitioner core. A curation and GitHub-policy liability. |
| Katoolin266 open issues, 38 PRs, no maintainer response | Kali repo categories bolted onto a Debian/Ubuntu host | Adds Kali APT repos + apt-key, installs by category number | Numbered menu | Effectively dead (requires Python 2.7). The cautionary tale: foreign rolling repos, no safety checks, broken hosts. Modern guides recommend Docker instead. |
| Kali LinuxOfficial distribution | Curated metapackages, not a flat list: kali-tools-web, kali-tools-passwords, kali-tools-top10, up to kali-linux-everything | Signed Debian packages via apt; dependency resolution, upgrade and removal are APT's job | apt install kali-tools-web, or the kali-tweaks menu | The credible reference design for curation: install a category or the top 10, not everything. everything exists but is explicitly the heavy option. |
| BlackArch2,700+ tools per secondary guides | Pacman groups: blackarch-webapp, blackarch-scanner, blackarch-wireless… | Signed pacman repo + keyring; or build from PKGBUILDs with blackman | CLI package manager | Proves a huge catalog can work, but only by becoming a real distro repo with packaging and maintainers per package. That cost is the lesson. |
| pdtm (ProjectDiscovery)The modern model to copy | Single-vendor catalog, ~20 Go tools (Nuclei, Subfinder, httpx, Naabu, Katana…), cached with a fallback when the GitHub API is down | Pre-built GitHub-release binaries per OS/arch, or go install fallback; manages PATH | pdtm -ia install all · -ua update all · -l list installed + outdated · per-tool remove | What "good" looks like in 2025: narrow scope, one vendor, binary releases, real update, remove and outdated-listing. A new DarkFly should delegate ProjectDiscovery tools to pdtm, not re-clone them. |
| ExegolDocumented, versioned Docker images | Tools installed "under installation standards (isolated environments, tested installs)" | Docker images/containers; one image, many clean containers per engagement | CLI container management; optional MCP server | Practitioners accept the Docker weight on desktop for reproducibility: "Alice's Kali with random Git checkouts does not survive methodology review." Not viable on Termux (no real Docker): copy the principles, not the mechanism. |
Full per-project sources in Sources. Note on classification: Nexfil, sometimes listed beside these projects, is not an installer at all. It is a single OSINT username-finder; it belongs inside a catalog as one entry.
Cyber blogs, cheatsheets and community benchmarks converge on the same small core, organised by workflow phase rather than alphabetically. Kali 2025.2 even reorganised its own menu around MITRE ATT&CK.
Black Hills Information Security's Offensive Tooling Cheatsheets went through "careful technical peer review" and "double- and triple-checking syntax", and cover only nine tools: Burp Suite, DNS Triage, EyeWitness, GraphRunner, Hashcat, Impacket, Netcat, Nmap, Wireshark. They moved from print to updatable digital "as tools and technologies shift".
EC-Council's 2026 beginner toolkit is deliberately minimal: Kali + Nmap + Burp Community + Metasploit + HackTheBox / TryHackMe, which "covers 80% of what professional pentesters use". Meanwhile Kali's own kali-tools-top10 is Nmap, Wireshark, Burp, sqlmap, Metasploit, Hydra, John, Responder, NetExec and Aircrack-ng.
SecLists (74,307 ★) is maintained by named people, Daniel Miessler, Jason Haddix, Ignacio Portal and g0tmi1k, so a tester can "pull this repository onto a new testing box and have access to every type of list that may be needed". Wordlists and references like PayloadsAllTheThings and HackTricks carry the same value as tools, at a fraction of the install risk.
Chain synthesised from HTB-style practitioner cheatsheets: awjunaid.com. Two more practice signals: trust attaches to a tool's own maintainer (TrustedSec's tools are consumed as individual repos, never via installers), and enterprise packaging is the trend, BloodHound CE ships containerised with an ~80% deployment-time cut (Help Net Security). On Termux that means shipping the BloodHound collectors, never the server.
The proposed catalog, built from the research: the timeless core, the modern layer classic DarkFly lacks entirely, resources treated as first-class entries, and a small clearly-labelled emerging tier. Filter by tier or search. Backend is how the new installer would install it; Termux flags what is honest to promise on a phone.
Explicitly excluded, by design: SMS/call bombers and spam tools (v4's headline "7 SMS spam tools"), Gmail bombers, webcam-phishing and DDoS-Ripper-style entries, and any tool whose upstream is archived with a named successor. Their absence is a differentiator, and the README should say so.
Practitioner comparison numbers are useful for one thing: deciding which tools belong side by side in the catalog. They are not catalog facts, and the new project should never quote them as such.
Gigabit LAN, Kali 2025.1. Log scale, seconds to finish. The lesson: ship Nmap and RustScan, and document the combined workflow. Speed without service detection is not a finished scan.
Source: securityelites.com, self-reported. A comparative study reaches the same qualitative split: Nmap is the depth/NSE standard, Masscan/ZMap are internet-scale speed with accuracy trade-offs (Latinoware study).
Requests per second in one local benchmark. On real internet targets "the difference is minimal", so the catalog carries all three with a one-line "use when" each. Wordlist choice dominates results, which is why SecLists is a Tier 2 entry.
Source: securityelites.com, self-reported, local targets only.
One SEO benchmark pits Hashcat on an RTX 4090 against John on a 16-core CPU: NTLM 164,000 vs 8,200 MH/s, MD5 68,000 vs 4,100 MH/s. HackMag's practical testing counters that benchmarks "outperform actual results by several times" and are "not really stable". A careful comparison concludes the two are "complementary, not competitors": Hashcat for raw hashes and Wi-Fi, John for files and no-GPU machines.
Catalog decision: on Termux there is no GPU path that matters, so John is the sensible default and Hashcat is a low-priority, warn-heavy entry. GPU MH/s figures never appear in the catalog.
SEO benchmark · HackMag scepticism · techearl, complementary view
A practitioner head-to-head on the same target: Caido's scanner plugin found ~400 issues / 12 unique, Burp Scanner over 1,000 / 17 unique. Caido has no built-in scanner or crawler (plugins fill the gap) but is Rust, lightweight, with a modern UX. Kali packaged Caido in 2025.3.
Catalog decision: Burp and ZAP stay the reference; Caido is listed as "emerging, laptop-class", not as a Termux install.
What would make the new version genuinely different from the old one and every clone, in the order the research says to build them.
Install, update, uninstall and list-installed, all backed by an installed.json manifest recording tool, version or commit, backend, files created and dependencies. v5's core gap is that it installs nothing; pdtm proves users value install-all / update-all / list-outdated / remove in one tool. The manifest is also what makes every other safety feature possible.
Kali top-10 plus the ProjectDiscovery suite plus the AD set is the product. Every entry carries status (maintained / stale / archived), successor_to and last_verified, turning link-rot from a silent failure into visible data. Curation is ongoing work: budget for it, and automate the checks in CI.
Stand on signed and isolated channels instead of owning 100 bespoke install scripts. Delegate ProjectDiscovery tools to pdtm and Kali-packaged tools to apt. Record which backend was used so update and uninstall reverse the right thing. The ladder is specified below.
--dry-run prints every command, download size and file to be written, and executes nothing. Installs are staged and journaled so an install killed mid-way (signal 9, battery, network) resumes or rolls back cleanly. Re-running install on an installed tool is a no-op success. Try it in the simulation.
v5 has no search, and numbered menus collapse well before 80 tools. darkfly search nuclei, scriptable subcommands with --dry-run, --yes and JSON output, Rich tables, and a questionary picker for interactive use, all on the same code path. Stay in Python: a Go rewrite would orphan the v5 codebase and shrink the Termux contributor pool.
Checks Termux source and mirror sanity, Python version, free storage, the phantom-killer risk, whether each installed tool's binary still runs, and whether its upstream has been archived. It turns "it broke" GitHub issues into self-service diagnosis, the same issue pattern that produced v5's open "how do I use it" reports.
SecLists subsets, PayloadsAllTheThings, HackTricks, GTFOBins: resumable, checksummed downloads with size choices (small bundles on Termux, full on Linux; rockyou as a verified download, never bundled). Data, not code, so the install risk is minimal and the value is daily.
CI validates the catalog schema, checks every upstream URL resolves and is not archived, and smoke-tests --dry-run for every entry, catching link-rot continuously. Then publish measured time-to-install, failure rate and uninstall cleanliness for the top-20 catalog on a named Termux device and a named Linux VM. No competitor can copy that with a banner change.
Modelled on Homebrew's reviewed formulae and bottles, mise's "prefer backends that install a publisher's release directly", and cargo-binstall's checksum-verified atomic installs. Sources in Sources.
{
"id": "netexec", "name": "NetExec",
"aliases": ["nxc"],
"description": "Network service exploitation /
AD assessment (successor to CrackMapExec)",
"categories": ["ad", "post-exploitation"],
"license": "…", "homepage": "…",
"status": "maintained",
"successor_to": "crackmapexec",
"platforms": { "termux": true, "linux": true,
"gui_required": false },
"size_mb_estimate": 120,
"last_verified": "2026-10-23",
"install": { "backend": "pipx",
"package": "git+https://…@<pin>" },
"run": "nxc"
}
One plain-JSON record per tool, in-repo and diff-able in pull requests. No obfuscated catalog, ever: that was a v4 failure mode, not a style choice.
Policy sources: GitHub active malware or exploits policy · GitHub acceptable use policies · Why curl | bash is dangerous
Two kinds of evidence. Left: the current v5, cloned and actually run in a VM for this brief, the "before" picture. Right: a simulation of the proposed CLI's dry-run behaviour, generated from the catalog blueprint above, so the design can be judged before it is built.
Baseline run in a local VM against the current repo state, October 2026. The proposed test regime from the blueprint: schema validation and URL/archive checks in CI on every change, dry-run smoke tests for all entries, and full install tests for Tier 0 on Termux and Linux.
Simulated output of the proposed CLI, composed from the catalog schema and safety rules in this brief. Nothing here executes on your device; the point of --dry-run is that the real tool would behave exactly this way: show the full plan, change nothing.
Most "installer randomly died" reports are platform facts the installer ignored. The new design treats these as constraints, not surprises.
The Play Store build was abandoned in 2020, is frozen at 0.101, and points to dead repository mirrors. APKs and all add-ons must come from the same source, because they are signed with different keys; mixing them fails with INSTALL_FAILED_UPDATE_INCOMPATIBLE. A current Play listing for Android 11+ exists but is still in development with missing functionality.
Android 12+'s Phantom Process Killer terminates Termux children past roughly 32 phantom processes or under heavy CPU: the infamous [Process completed (signal 9)]. User-side fixes exist (Android 14+ Developer Options, or ADB device_config settings), but the design consequence is on us: resumable, journaled, low-parallelism installs are mandatory, with a pre-flight warning before heavy installs.
Home is /data/data/com.termux/files/home, binaries live under $PREFIX, and there is no FHS, no systemd and no root. Desktop glibc binaries generally won't run on Android's Bionic libc, the classic "No such file or directory" for a file that exists. Storage permission is opt-in via termux-setup-storage; the installer must work fully without it.
pkg wraps APT with mirror selection (health-checked, weighted), a cache-freshness check and a refusal to run as root. Official repos are signed via termux-keyring. A good installer shells out to pkg and lets it verify signatures instead of reimplementing downloads. Dead mirror? The fix users need is termux-change-repo, and doctor should say so.
Python 2 is legacy and is the single reason v4-era tools fail on a fresh install. Modern Python also blocks global pip install ("externally-managed environment"), the exact wall a practitioner hit installing NetExec on HTB Pwnbox, and solved with pipx. The whole tool targets Python 3.10+, and every Python tool it installs is pipx-isolated.
In order: stale Play-Store Termux with dead mirrors; dead or slow mirrors failing pkg update; Python 2 scripts; global pip dependency conflicts; signal-9 kills mid-build; desktop-glibc or x86 binaries on arm64; tools needing root, monitor mode, systemd or a GUI; and multi-GB "install everything" runs exhausting phone storage (AllHackingTools alone claims ~2.2 GB).
Sources: Termux package management (wiki) · Andronix, phantom process killer · NetExec via pipx on Pwnbox · Termux community: prefer repo packages over installer scripts
Each of these sounds like an upgrade. Each is refused or deferred for a stated reason, so the decision survives the next "why don't we just…" conversation.
Multi-GB, hours long, maximal signal-9 and storage failure, and most entries will be stale. Kali can offer kali-linux-everything only because a real distro repo stands behind it. A clone-script cannot honour it.
No usable Docker daemon or Nix store model on unrooted Android, and both are storage- and complexity-heavy. Copy their pinning, manifest and isolation principles only.
It delays the one thing that matters, working installs, and a Go/Bubble Tea rewrite orphans the Python v5 code and its contributor pool. Textual can come later as an optional front-end.
GUI tools, the BloodHound server, GPU Hashcat and monitor-mode Wi-Fi need a desktop, a database, a GPU or special hardware. List them as "desktop companion" info entries; never fake-install them on Termux.
Kali is only now adding MCP/AI servers, and practitioner sources call LLM tooling "still early, still maturing". An autonomous executor multiplies the safety surface: prompt-driven arbitrary commands and API-key exfiltration. Later, opt-in and dry-run-gated, at most.
apt-fast-style tricks only speed the download phase and risk mirror or signature shortcuts. Mobile networks and the phantom-killer limit dominate Termux install time anyway.
Policy risk under GitHub's acceptable-use rules, reputational risk, and zero practitioner demand. Their absence is a differentiator.
The clone field is saturated with 370-to-530-tool menus. BlackArch shows what a huge catalog actually costs: a distro, a keyring and maintainers per package. Curation is the moat; count is the trap.
Marked plainly, because a brief that hides its gaps produces a README that repeats them.
All sources read 23 Oct 2026 via the web index. Benchmark sources are flagged low-authority where they appear in the text.
DarkFly & the classic clones
Distributions & practitioner-grade managers
Practitioner blogs & community benchmarks
Modern patterns, safety & Termux