Z4nzu/hackingtool: a 215-tool launcher with an AI layer that only suggests, never runs

The problem hackingtool solves is tool sprawl, not missing capability

Most penetration testers do not lack tools. They lack an index of them. A typical Kali install already carries dozens of binaries, and every engagement adds a few more cloned from GitHub into a directory nobody remembers. The result is that people re-solve the same discovery problem: which subdomain enumerator did I settle on, which OSINT script handled that API, and what was the exact flag I used last time.

hackingtool attacks that with a catalog rather than a new scanner. The README describes 215 curated tools across 21 categories, spanning recon, OSINT, web, wireless, phishing, forensics and post-exploitation. Each entry is a pointer to an upstream project plus the command to install and run it, surfaced through a single console. The audience named in the README is broad: pentesters, red teamers, SOC and DFIR analysts, OSINT researchers, bug-bounty hunters, CTF players and students, all on systems they own or are authorized to test.

The catalog is not the whole repository. The README states that 59 further entries are archived because they are unmaintained or their upstream is dead, and that they stay hidden unless you set `show_archived true` via `/config`. That is a more honest arrangement than most tool lists manage, and it also tells you something about the shelf life of security tooling: roughly a fifth of what was once worth listing is no longer worth defaulting to.

How the AI layer maps intent to a command without executing it

The distinguishing feature is not the catalog but the translation layer on top of it. The README describes three entry points. `/find` searches your local catalog first and then the GitHub API, and returns real maintained projects with the reason each was ranked. `/goal` takes an objective and plans it step by step, running one step at a time rather than as a batch. Recommendations let you say what you want in plain English, and the system maps that to the right tools and hands you the exact documented command.

The design constraint that matters is stated plainly: nothing auto-executes and nothing is fabricated. The AI produces a suggestion; you decide whether to run it. That is a deliberate refusal of the more common pattern, where an agent shells out on your behalf and you review the damage afterward. For a toolkit whose categories include phishing, RATs and DDoS, that refusal is the difference between a reference tool and something you cannot leave running unattended.

The AI layer is also optional in the sense that it needs a model behind it. The README says to bring your own key or run a local model, and points to `/config` for the settings. It does not document which providers are wired up or what the fallback looks like when no key is present, so treat the catalog and tag search as the parts you can rely on unconditionally and the language layer as the part you configure.

Underneath, the app is a standard Python package. The pyproject.toml declares a src-layout under src/hackingtool/, a console entry point `hackingtool = "hackingtool.cli:main"`, and five runtime dependencies: rich, pyyaml, platformdirs, prompt_toolkit and python-dotenv. The catalog and pipeline definitions ship as YAML package data resolved at runtime via __file__, which is why the Dockerfile installs with pip rather than copying a flat script.

Installing hackingtool with pipx and running a first search

The README recommends pipx because it installs the app into an isolated virtual environment and puts the `hackingtool` command on your PATH without touching system Python. You need Python 3.10 or newer on Linux or macOS. Clone the repository, then install from the checkout:

git clone https://github.com/Z4nzu/hackingtool.git
cd hackingtool
pipx install .

If pipx is not present, the README gives two package-manager routes. On macOS, `brew install pipx && pipx ensurepath`. On Debian, Ubuntu or Kali, `sudo apt install pipx && pipx ensurepath`. Open a new shell after `ensurepath` so the PATH change takes effect. Updating later is `git pull && pipx install . --force`, and removal is `pipx uninstall hackingtool`.

With the command on your PATH, launch the console from any directory:

hackingtool

The README describes the launch screen as a live system readout, with `/` opening the command palette. From there, typing a request in plain English is the intended first move; the system responds with a tool and the documented command rather than running it.

There is a container path as well. The docker-compose.yml defines a service that builds from the local Dockerfile, which is based on kalilinux/kali-rolling:latest and installs the package with pip3, using `--break-system-packages` to get past Kali's PEP 668 externally-managed marker. The compose file persists runtime-installed tools in a named volume at /root/.hackingtool.

docker compose run --rm hackingtool

That runs the interactive TUI. Because the container is built on Kali, many of the bundled tools are already present, which shortens the setup for tools that would otherwise clone and compile their own payloads.

Where hackingtool is the wrong choice

Windows is not supported. The README states this directly: the app tells you so and exits. The classifiers in pyproject.toml still list Microsoft Windows, which is a packaging metadata inconsistency rather than a supported platform, and anyone reading only the classifiers will be misled.

The second limit is the console itself. hackingtool is a TUI. The README mentions headless engagements as a feature, but the primary interaction model is an interactive terminal, and the Docker instructions use `stdin_open: true` and `tty: true` for exactly that reason. If your workflow is a CI pipeline that runs a scanner and parses JSON, this is not the layer you want; you want the upstream tool directly, with its own flags and output format.

The third limit is that a catalog is not a maintenance commitment. hackingtool indexes other people's projects. When one of those upstreams breaks, changes its interface or goes dormant, the entry in the catalog does not fix itself. The 59 archived entries are the visible evidence of that drift, and the fact that they are hidden by default rather than deleted means the catalog carries a growing tail of entries that no longer earn their place.

Finally, the AI layer is only as good as the model you point it at, and the README does not document what happens when the model returns a command for a tool you have not installed, or a command that does not match the version of the upstream tool on your machine. The suggestion is a starting point, not a verified invocation. Check the command against the tool's own documentation before you run it against a live target.

hackingtool compared with a plain Kali install or a script runner

The obvious alternative is doing nothing: install Kali, learn the tools, and keep your own notes. That approach has no dependency on a third-party catalog and no risk of a stale entry pointing you at the wrong binary. Its cost is exactly the problem hackingtool was built for. Discovery is manual, and the knowledge lives in your head or in scattered notes.

The second alternative is a general task or script runner, where you keep your own YAML of commands and aliases. That gives you full control over what runs and how. What it does not give you is a curated starting set, the 63-tag taxonomy the README mentions, or a search that falls back to the GitHub API when your local catalog has nothing. You would be building the index yourself, which is a reasonable choice if your toolset is narrow and stable.

The third alternative is the upstream tools one at a time. Amass, theHarvester, Nuclei and the rest all ship their own documentation and their own installation instructions. If you know which one you need, going direct is faster and gives you the current interface rather than a catalog's snapshot of it. hackingtool earns its place when you do not yet know which tool you need, which is the situation `/find` and the recommendations feature are designed for.

The honest framing is that hackingtool sits between a package manager and a cheat sheet. It does not replace the tools, and it does not replace knowing them. It replaces the search.

Maintenance cost, licence and what the repository tells you about upgrades

The repository is not archived, but no last push date is available, so there is no basis for describing the project as actively maintained or regularly updated. Treat update frequency as something you verify yourself by looking at the commit history on the master branch before you depend on it.

Upgrading is cheap by design. Because the install is a local checkout rather than a published package on an index, the update path is `git pull` followed by `pipx install . --force`. That reinstalls the console script from the current source. There are no retrieved releases, so version pinning and changelog-driven upgrades are not part of the picture; you are tracking a branch.

The licence is MIT, declared both in the LICENSE file and in pyproject.toml as `license = { text = "MIT" }`. That is permissive: it allows commercial and private use, modification and redistribution, with the licence and copyright notice retained. Two caveats are worth naming without giving legal advice. First, MIT covers hackingtool itself, not the 215 upstream tools it indexes. Each of those carries its own licence, and some security tooling is dual-licensed or restricted. Second, the payloads you install at runtime under /root/.hackingtool are governed by their own terms. If you are packaging this for a client engagement, the licence review has to cover the whole dependency tree, not just the launcher.

The README also points to signed releases with an SBOM under SECURITY.md, and states that downloads are pinned and SHA-256 verified and that subprocess calls use list form rather than shell strings. Those are supply-chain choices worth checking in the source rather than taking on faith, particularly the verification step, since a catalog that installs third-party code is only as safe as that step.

Editorial conclusion

Adopt hackingtool if you already run Kali or Parrot and keep losing track of which recon or OSINT tool you installed last month; the pipx install and the fixed tag taxonomy solve a real discovery problem. Skip it if you work on Windows (the app states it is unsupported and exits), if you need a headless CI runner rather than a TUI, or if you expect the AI layer to execute anything on your behalf, because the README states nothing auto-executes. Before trusting a tool entry, open docs/TOOLS.md and check the upstream repository it points at, then run `hackingtool` once with no engagement loaded and confirm the catalog header matches the 215 tools the README claims.

Frequently asked questions

Official sources

1. Official README
2. Project repository