hackingtool: All-In-One Terminal Arsenal for Pentesters
TL;DR
- What it solves: Fragmented tool discovery - knowing what you need conceptually but not what it’s called or where it lives
- Why it matters: 185+ curated tools across 20 categories, searchable and batch-installable from a single terminal prompt
- Best for: CTF competitors, OSCP students, and pentesters setting up fresh engagement environments
- Best use case: Type
/xss- get DalFox, XSStrike, and three alternatives with one keystroke - Main differentiator: It’s a manager, not a tool. One Python dependency (
rich), zero standalone capability, no magic
The Mental Model
I was setting up a new engagement last month. Active Directory environment. I knew what I needed conceptually - something to enumerate AD users, something for Kerberoasting, something for certificate template abuse. I could picture the output in my head.
I could not remember a single tool name.
Not because I don’t use them. Because there are too many, scattered across GitHub repos, Kali packages, and a ~/tools directory that hasn’t been cleaned since 2022. It’s a specific kind of paralysis: you know the maze, you just can’t find the door.
hackingtool is a library card catalog for your terminal. Not a weapon. A Dewey decimal system that says: here is what exists, here is what it does, here is how to install it. You come in with a problem, you leave with a tool.
What’s Inside
Twenty categories, 185+ tools. The catalog covers what you’d expect - SQL injection (sqlmap, NoSQLMap), OSINT (theHarvester, Maigret), wireless (aircrack-ng, bettercap) - and adds three territories that arrived in v2.0.0 and reflect how real engagements look today.
Active Directory: BloodHound, NetExec, Impacket, Responder, Certipy, Kerbrute. The full AD suite in one menu entry, one batch install.
Cloud Security: Prowler, Trivy, Pacu, ScoutSuite. The stack consultants reach for when the target runs on AWS or GCP.
Mobile Security: MobSF, Frida, Objection. Android and iOS assessment sitting in the same catalog as everything else.
There are also categories I’d approach carefully. DDOS Attack, Phishing Attack, Payload Creation - legal only against systems you own or have explicit written authorization to test. The README says this. Treat it as a hard constraint, not a disclaimer.
Quality is uneven. BloodHound, Nuclei, and Impacket are industry-standard, actively maintained. Some entries in Other Tools and the phishing categories are years stale. The TUI doesn’t surface maintenance status. You have to check each upstream repo yourself.
Where It Clicks
Scenario 1: CTF prep, night before the competition.
Old workflow: Google “best XSS tool,” scan three Awesome lists, clone four repos, discover one needs Python 2, spend forty minutes untangling dependencies.
New workflow: launch hackingtool, type /xss, select DalFox from the filtered results. Installed. Running.
hackingtool → /xss
DalFox [xss, scanner]
XSStrike [xss, web]
XSS Payload Generator [xss, payload]
XSSCon [xss, crawler]
Scenario 2: OSCP lab, fresh Kali install, you know exactly what’s needed.
Navigate to option 17 (Active Directory), type 97 to batch-install the entire category.
hackingtool → 17 (Active Directory) → 97
Installing: BloodHound, NetExec, Impacket, Responder, Certipy, Kerbrute
BloodHound ✔
NetExec ✔
Impacket ✔
Responder ✔
Certipy ✔
Kerbrute ✔
One number to choose the category. One number to install everything in it.
Scenario 3: First mobile assessment, unfamiliar terrain.
Type r to enter the recommendation prompt. Describe the task in plain English.
hackingtool → r
Prompt: "I want to analyze an Android APK"
MobSF, Frida, apktool, Objection
This is most useful when you’re learning the toolscape. Once you have a workflow, you’ll use search or install directly and ignore the recommendation prompt entirely.
--> // making it invisible to querySelectorAll. // // `data-cfasync="false"` keeps this rescue script executable even when // Rocket Loader is active. It rescues module scripts via two strategies: // 1. Query the DOM for type$="-module" + src (covers case A) // 2. Regex-parse the raw HTML for commented-out script tags (covers case B) // Dynamically-created scripts bypass Rocket Loader entirely. (function () { if (window.__markdyRescue) return; window.__markdyRescue = true; var rescued = false; function rescueModuleScripts() { if (rescued) return; rescued = true; var srcs = []; // Strategy 1: Rocket Loader kept the tag in DOM but changed the type. // type="module" → type="{uuid}-module" (still has src attribute) document.querySelectorAll('script[type$="-module"][src]').forEach(function (s) { srcs.push(s.src); }); // Strategy 2: Rocket Loader COMMENTED OUT the script tag entirely: // // These are invisible to querySelectorAll, so we parse the raw HTML. // We handle both attribute orderings (type-first or src-first). var html = document.documentElement.innerHTML; var reSrcFirst = //g; var reTypeFirst = //g; var m; while ((m = reSrcFirst.exec(html)) !== null) { srcs.push(m[1]); } while ((m = reTypeFirst.exec(html)) !== null) { srcs.push(m[1]); } // Re-inject each found src as a real module script. // Deduplicate first, then inject. Dynamically-created scripts bypass // Rocket Loader entirely. Modules with the same URL are only executed // once by the browser (cached), so re-injecting already-running scripts // is safe. var seen = {}; srcs.forEach(function (src) { if (seen[src]) return; seen[src] = true; var fix = document.createElement('script'); fix.type = 'module'; fix.src = src; fix.setAttribute('data-cfasync', 'false'); document.head.appendChild(fix); }); } // Rescue when user clicks the placeholder (fallback if autoplay failed). document.addEventListener('click', function (e) { var t = e.target; if (t && typeof t.closest === 'function' && t.closest('.markdy-placeholder')) { rescueModuleScripts(); } }); // Rescue automatically after a short delay for autoplay. // Only fires if initAll() never ran (no data-markdy-init on any root). setTimeout(function () { if (document.querySelector('.markdy-root:not([data-markdy-init])')) { rescueModuleScripts(); } }, 1500); }());Getting Started
One-liner:
curl -sSL https://raw.githubusercontent.com/Z4nzu/hackingtool/master/install.sh | sudo bash
hackingtool
Before you run that, read the script first. curl | sudo bash is convenient and exactly how supply chains fail. The manual path is one extra line and installs identically:
git clone https://github.com/Z4nzu/hackingtool.git && cd hackingtool
sudo python3 install.py
hackingtool
Docker, for sandboxed evaluation:
docker build -t hackingtool . && docker run -it --rm hackingtool
The Dockerfile builds locally from the cloned repo - no unverified external images.
Dependencies to know about: Runtime needs only Python 3.10+ and rich>=13.0.0. Lean. But roughly ten tools - Nuclei, ffuf, amass, httpx, katana, subfinder, gobuster, dalfox - also require Go 1.21+. This is documented in the requirements table but easy to miss. If a tool silently fails to install, missing Go is the most likely reason.
macOS: The OS-aware menus suppress Linux-only tools automatically. You lose wireless, kernel-level, and payload tools - roughly a third of the catalog. Use the Docker path on macOS for a complete experience.
The honest note: If you already know your tools and have a stable toolchain, hackingtool adds little operational value. It’s a discovery and installation interface. Once you’ve built your environment, you probably won’t open it again. That’s not a flaw. That’s what it’s for.
GitHub: Z4nzu/hackingtool - MIT · 74,838★
Hoang Yell
A software developer and technical storyteller. I spend my time exploring the most interesting open-source repositories on GitHub and presenting them as accessible stories for everyone.