30. August 2026 · Von YasKad
Z4nzu/hackingtool

hackingtool: eine All-in-One-Konsole für autorisierte Sicherheitstests

Z4nzu/hackingtool · 79.741★ · 9.039 forks

Ein Launcher-Tool mit 215 kuratierten Tools in 21 Kategorien, ein datengesteuerter Katalog und eine optionale KI-Schicht, die Anfragen in natürlicher Sprache in echte, dokumentierte Befehle verwandelt.


Was hackingtool ist

hackingtool ist ein Launcher für Sicherheitstest-Tools: Es implementiert Angriffs- oder Verteidigungswerkzeuge nicht selbst, sondern entdeckt, installiert und startet sie von einer einzigen Konsole aus. Das aktuelle README beschreibt es als „All-in-One-Kit mit KI-Anleitung für autorisierte Sicherheitstests”, mit 215 kuratierten Tools in 21 Kategorien (Recon, OSINT, Web, Funk, Phishing, Forensik, Post-Exploitation, unter anderem) und einer festen Taxonomie von 63 Tags, die jedes Tool auffindbar macht.

Das aktuelle Produkt ist eine interaktive Python-Konsole mit drei Eingabeformen: Slash-Befehle (/run, /search, /find), Arroba-Referenzen (@nmap, @tag:osint) und Text in natürlicher Sprache (“crack a wifi handshake”), den der Tool-Empfehler interpretiert.

Drei Eingabeformen der Konsole: Slash-Befehle, Arroba-Referenzen und natürliche Sprache

Über diesem Katalog wirkt eine optionale KI-Schicht mit eigenem Schlüssel (ein OpenAI-kompatibler Endpunkt oder ein lokales Ollama-Modell): Sie empfiehlt Tools, formuliert den exakten Befehl für ein Ziel, plant Ziele Schritt für Schritt und fasst Befunde zusammen. Ohne konfiguriertes Modell fallen alle Funktionen auf lokales, deterministisches Verhalten zurück: Nichts wird autonom ausgeführt, und nichts wird erfunden.

Optionale KI-Schicht mit eigenem Schlüssel: empfiehlt Tools und plant, ohne autonom etwas auszuführen

Das Repository unterscheidet sich von Tool-Listen dadurch, dass es ein datengesteuerter Katalog ist: Jedes Tool ist ein YAML-Eintrag in src/hackingtool/catalog/ mit Tags aus einer geschlossenen Taxonomie und Nutzungskarten mit echten Befehlen, verifiziert gegen die Dokumentation jedes Projekts.

Datengesteuerter Katalog: YAML-Einträge mit 63 Tags aus einer geschlossenen Taxonomie, keine erfundenen Tools

Ursprung

Das Repository wurde am 11. April 2020 von Hardik Zinzu erstellt (GitHub-Nutzer Z4nzu), dessen Account Wohnsitz in Indien angibt und dessen Bio sich auf „Python | Frappe | ERPNext | Odoo | DevOps” konzentriert, mit persönlichem Blog auf hardikzinzu.com. Der erste Commit des master-Branches lautet buchstäblich „Initial commit”, vom selben 11. April 2020.

Die ersten Commits zeigen den bescheidenen Ursprung des Projekts: ein einziges Skript (hackingtool.py), in den ersten zwei Wochen vom Handy aus aktualisiert (“From mobile”, “first time”, “small change”), mit einer auf sudo git clone basierenden Installation und einem klassischen nummerierten Menü. Die ersten Tags kommen spät: v1.0 verweist auf einen Commit vom 19. Juli 2020, v1.1.0 auf den 21. Juli 2020.

Die frühe Issue-Historie dokumentiert die Kinderkrankheiten des Projekts: Syntaxfehler durch Python-2/3-Inkompatibilität (Issue #174, 31 Kommentare; #185, 11 Kommentare), Fehlschläge beim Ausführen mit sudo (#242, 10 Kommentare) und Installationsprobleme (#7, 10 Kommentare). Es gibt auch einen frühen Sicherheitsmeilenstein: PR #116, “RCE fix: Changed all cmd executions from os.system to subprocess.Popen calls”, mit 12 Kommentaren, der die Befehlsausführung über die System-Shell beseitigte.

Der moderne Sprung stammt aus 2026. Der Commit vom 15. März 2026, “Restructure for v2.0.0 with new tools, features, and UI updates” (PR #590), strukturierte das Projekt um; und am 26. Juli 2026 kam das vollständige Redesign: “feat: AI operator console — 215 curated tools, AI layer, /find discovery (v2.0.0 rework)”, gefolgt von “chore(release): 3.0.0”. Die Repository-Beschreibung auf GitHub bleibt die ursprüngliche (“ALL IN ONE Hacking Tool For Hackers”), aber das aktuelle README präsentiert sich bereits als Werkzeug für „autorisierte Sicherheitstests”, ausgerichtet auf das gesamte Spektrum: Red Teams, Blue Teams, OSINT, Bug Bounty, CTF und Forensik/IR.

Philosophie und Prinzipien

Die in CONTRIBUTING.md dokumentierten Grundregeln werden als „nicht verhandelbar” erklärt und, wo möglich, in Review und CI durchgesetzt:

  • Nur autorisierte Ziele. Keine Funktion setzt Zugriff auf Systeme voraus, die der Operator nicht besitzt oder nicht testen darf.
  • Keine Erfindung. KI-Ausgaben werden gegen geschlossene Mengen validiert; Katalogbefehle müssen echte, dokumentierte Aufrufe sein, niemals erfunden.
  • Nur subprocess in Listenform. Niemals shell=True mit interpolierter Eingabe.
  • Fixierte und verifizierte Downloads. Jeder Download trägt eine fixierte Version und eine SHA-256-Summe; kein curl | bash, „niemals”.
  • Kein erzwungenes sudo. Tools werden in ~/.hackingtool/ installiert, nicht in Systempfade.
  • Linux/macOS zuerst. Ausschließlich für Windows gedachte Tools werden nachrangig behandelt.

Das README fügt Designprinzipien der KI-Schicht hinzu: Sie ist optional und mit eigenem Schlüssel (BYO-key); die KI kann nur Tags aus der festen Taxonomie zurückgeben (der Katalog löst Tag → Tool auf, sodass ein Tool nicht erfunden werden kann); /find liefert nur Vorschläge (klont, installiert oder führt niemals aus) und macht null Modellaufrufe; Ziele außerhalb des Umfangs (Jamming, DoS, Massenbelästigung, Malware) werden vor jedem Netzwerkaufruf verweigert, mit einer autorisierten Alternative, wenn eine existiert; und die Ausgaben der Scan-Tools werden gegenüber der KI als nicht vertrauenswürdige Daten behandelt (siehe den Operator-Brief in src/hackingtool/skill/OPERATOR.md).

Sicherheitsprinzipien: nur autorisierte Ziele, keine Erfindung, nur Subprocess in Listenform, fixierte SHA-256-Downloads

Wie es funktioniert

Der in docs/HOW-TO-USE.md dokumentierte Grundablauf:

  1. Start. Die Konsole zeigt das Banner, den Systemstatus und den Prompt. Tab vervollständigt Befehle, Toolnamen und Tags; ↑/↓ navigiert die Historie.
  2. Entdeckung. /tags listet die 63 Tags mit ihrer Anzahl; @tag:osint öffnet die Tools dieses Tags; /search <keyword> sucht in Namen, Beschreibungen und Tags; @nmap öffnet ein Tool direkt (groß-/kleinschreibungsunabhängig, mit Tippfehlertoleranz).
  3. Tool-Karte. Jedes Tool zeigt Beschreibung, Link zum Projekt und, falls kuratiert, eine Nutzungskarte mit echten Befehlen. Menü: 1 installieren, 2 ausführen, c den exakten Befehl für ein Ziel anfordern, 98 Projektseite, 99 zurück. Existiert das Tool bereits im PATH (apt, brew, Kali), verwendet hackingtool die Binärdatei erneut, statt sie neu zu klonen.
  4. /find beantwortet „was nutze ich für X?”: Es durchsucht zuerst die 215 kuratierten Tools und dann die GitHub-Such-API, wobei Ergebnisse mit dem Grund für jede Platzierung geordnet werden. Es ist nur eine Vorschlagsfunktion: Ein mit a gespeichertes Ergebnis wird in ~/.hackingtool/found.yaml geschrieben, ohne Installations- oder Ausführungsbefehl, sodass ein entdeckter Eintrag niemals etwas ausführen kann.

Der Befehl /find: sichere, nur vorschlagende Suche ohne Installation oder automatische Ausführung

  1. /goal verwandelt ein Ziel in einen kurzen Plan aus echten Befehlen (ein einziger Modellaufruf, nur zur Planung) und führt ihn Schritt für Schritt mit Nutzerbestätigung aus ([y] ausführen, [s] überspringen, [e] bearbeiten, [q] abbrechen). Jeder Schritt wird in Listenform ausgeführt, niemals per Shell, mit einer 30-Minuten-Grenze pro Schritt, und alles landet in einem zeitgestempelten Arbeitsbereich unter ~/.hackingtool/goals/ (plan.json, run.log mit UTC-Zeitstempeln und der Rohausgabe jedes Schritts). Die Ausgabe der Tools wird niemals an das Modell zurückgegeben.

Der Befehl /goal: schrittweise Planung mit Nutzerbestätigung und einer 30-Minuten-Grenze pro Schritt

  1. Hintergrund-Panels (tmux). Mit installiertem tmux öffnet /run <tool> … & ein etikettiertes Fenster in einer abgetrennten Sitzung; /panes listet, /attach beobachtet (Ctrl-b d zum Zurückkehren) und /kill stoppt. Ohne tmux öffnet sich das Tool inline.

Hintergrund-Panels mit tmux: lang laufende Scans in etikettierten Fenstern innerhalb einer abgetrennten Sitzung

  1. Headless-Modus. Derselbe Katalog steuert einen nicht-interaktiven Orchestrator: hackingtool --engagement acme --targets example.com --pipeline recon normalisiert die Tool-Ausgabe in einer findings.json; --report erzeugt einen deterministischen Markdown-Bericht; --ai-summary und --ai-report sind optionale KI-Durchläufe, die nur bereits bestehende Befunde zusammenfassen (der deterministische Bericht wird nie durch den KI-Entwurf überschrieben).

Headless-Modus: nicht-interaktive Pipeline, die findings.json und einen deterministischen Markdown-Bericht erzeugt

Der Katalog ist das technische Herzstück: YAML-Einträge in src/hackingtool/catalog/ (oder Python-Klassen für benutzerdefinierte Installations-/Ausführungslogik), Tags, die in src/hackingtool/tags.py (TAXONOMY) existieren müssen, und ein „Overlay”-Mechanismus, der es erlaubt, bestehenden Tools Anleitungen hinzuzufügen. 59 Einträge sind archiviert (stillgelegt oder upstream tot) und bleiben verborgen, sofern nicht show_archived true in /config gesetzt ist.

Offizieller und halboffizieller Status

  • PyPI: nicht veröffentlicht. Zum Messzeitpunkt (25. August 2026) lieferte die PyPI-API 404 für hackingtool. Das README selbst verbirgt die PyPI-/.deb-Installationsanweisungen mit einem Kommentar, der lautet: “Hidden until these distribution channels are live”.
  • GitHub-Releases: keine. Die Releases-API lieferte zum Messzeitpunkt eine leere Liste, obwohl SECURITY.md signierte Releases mit SLSA-Provenienz, ein via Sigstore attestiertes CycloneDX-SBOM und PEP-740-Attestierungen für PyPI dokumentiert. Dieser Abschnitt beschreibt den vorgesehenen Prozess (oder einen aus einer Version nach der Messung); zum 25. August 2026 existierte kein Release im Repository.
  • Docker Hub: Das Image hardikzinzu/hackingtool (Namespace des Autors) existiert, aktualisiert am 26. Juli 2026; die API lieferte zum Messzeitpunkt 0 Downloads, eine Zahl, die nicht als Adoptionsindikator gelesen werden sollte.
  • Context7: Ein Commit vom 23. August 2026 fügt context7.json mit der URL context7.com/z4nzu/hackingtool und einem öffentlichen Schlüssel hinzu, was die Projektdokumentation in Context7 für Coding-Agenten integriert.
  • Trendshift: Das README enthält Trendshift-Badges (Repository 869), einen Tracker für Trending-Repositories.
  • De facto: Mit 79.100 Sternen ist es mit weitem Abstand das meistgesternte „All-in-One-Hacking”-Repository auf GitHub (das nächste in dieser Linie hat ~746 Sterne), was es zur Standardreferenz macht, wenn jemand eine einzelne Konsole für Sicherheitstools sucht. Es gibt jedoch kein Vendor-Endorsement und keinen offiziellen Standard-Status in den konsultierten Quellen.

Das Ökosystem

Repositories des Autors (Z4nzu / Hardik Zinzu)

Der Autor pflegt weitere Sicherheitsprojekte aus derselben Zeit, laut seiner in dieser Recherche konsultierten Repository-Liste:

  • Z4nzu/fakeap: ein Evil-Twin-Angriff mit gefälschtem Access Point; 160 Sterne.
  • Z4nzu/fastssh: schnelles SSH-Scannen und Brute-Forcing; 104 Sterne.
  • Z4nzu/wlcreator: ein Wordlist-Generator in C; 95 Sterne.
  • Z4nzu/PhoneInfoga: ein fortgeschrittenes OSINT-Framework für Telefonnummern; 84 Sterne.

Der Rest seiner Aktivität liegt im Frappe-/ERPNext-Ökosystem (Forks von frappe, erpnext, raven, krama, agent, Bildungs- und Handelsprojekte), konsistent mit seiner ERP-/DevOps-Entwickler-Bio.

Community-Erweiterungen und Plugins

  • AKCodez/hackingtool-plugin (Autor Ariacodez / AKCODEZ): ein Claude-Code-Plugin, das den Katalog von Z4nzu/hackingtool umhüllt — 183 Pentesting- und OSINT-Tools — mit automatischer Backend-Auswahl (natives Bash unter Linux/macOS, WSL unter Windows, oder eigens erstellte Docker-Images wie instrumentisto/nmap, projectdiscovery/nuclei, caffix/amass und 20 weitere). Installation mit /plugin marketplace add AKCODEZ/hackingtool-plugin; 1.016 Sterne und 231 Forks, erstellt am 23. April 2026. Es ist die sichtbarste Erweiterung des Ökosystems: Sie bringt den Katalog zu einem KI-Agenten statt zu einer eigenen Konsole.
  • MAXZL1/hackingtool-plugin: eine weitere 183-Tool-Integration für Claude Code; 14 Sterne.
  • assiff/hackingtool: eine „by Z4nzu”-Kopie/Fork; 98 Sterne.
  • Das Hauptrepository sammelt insgesamt 8.975 Forks, wobei die überwiegende Mehrheit persönliche Nutzungsklone sind, keine aktiven Ableger.

Ökosystem rund um hackingtool: Repositories des Autors, Community-Plugins, Docker-Images und Dokumentation für Agenten

Kuratierte Listen

  • rawfilejson/awesome-osint-arsenal (2.291 Sterne): führt Hackingtool in seiner Tabelle von All-in-One-Tools.
  • Wechat-ggGitHub/Awesome-GitHub-Repo (17.192 Sterne): listet es mit chinesischsprachiger Beschreibung, ein Zeichen seiner Verbreitung in der chinesischen GitHub-Community.

Auf Agenten ausgerichtete Dokumentation

Der Operator-Brief (src/hackingtool/skill/OPERATOR.md, auch mit /skill sichtbar) definiert die „Verfassung”, die die KI-Schicht regiert: eine Persona für autorisierte Tests, ausschließlich autorisierte Ziele, nicht vertrauenswürdiger <scan_data>-Inhalt und explizite Anti-Erfindungs-Regeln. Zusammen mit der Datei context7.json dokumentiert er die 2026er-Strategie des Projekts: Drittanbieter-KI-Agenten (Claude Code, Context7-fähige Agenten) den Katalog unter denselben Sicherheitsregeln wie die Konsole bedienen zu lassen.

Schnellstart-Anleitung

Installation und erster Start

Voraussetzungen: Python 3.10+ unter Linux oder macOS (Kali, Parrot, Debian/Ubuntu, Arch…). Windows wird nicht unterstützt: Die Anwendung erkennt es und beendet sich.

# 1 — Code holen
git clone https://github.com/Z4nzu/hackingtool.git
cd hackingtool

# 2 — in den PATH installieren (isolierte Umgebung mit pipx)
pipx install .

# 3 — von jedem Verzeichnis aus ausführen
hackingtool

Ohne pipx: brew install pipx && pipx ensurepath (macOS) oder sudo apt install pipx && pipx ensurepath (Debian/Ubuntu/Kali), dann eine neue Shell öffnen. Dokumentierte Alternativen: uv tool install ., venv + pip install ., oder der veröffentlichte Container docker run -it --rm hardikzinzu/hackingtool:latest.

Beim ersten Start erstellt die Anwendung ~/.hackingtool/ mit config.json (Standardeinstellungen), .env (auskommentierte Secrets-Vorlage, chmod 600), tools/ (wohin installierte Tools geklont/gebaut werden) und history. In einem nicht-interaktiven Terminal (oder ohne prompt_toolkit) fällt sie auf das klassische nummerierte Menü zurück; man kann es jederzeit mit hackingtool --classic erzwingen.

Übliche Workflows

  • Zum Erkunden des Katalogs: /tags gibt die 63 Tags mit ihrer Anzahl aus; @tag:osint listet die OSINT-Tools, ausgewählt per Nummer; @nmap öffnet das Tool direkt; /search wordlist sucht nach Stichwort.
  • Um ein Tool zu finden, das nicht im Katalog ist: /find hidden directories on a website liefert zwei Blöcke — “In your toolbox (vetted)” und “Found on GitHub — NOT vetted by us” — und mit a plus der Nummer wird das Ergebnis als Lesezeichen in ~/.hackingtool/found.yaml gespeichert (keine Befehle, nur Referenzen).
  • Zum Planen und Ausführen eines Ziels: /goal find live subdomains of example.com erzeugt den Plan (ein Modellaufruf), bittet um Bestätigung der Autorisierung mit y, und führt Schritt für Schritt aus mit [y] run / [s] skip / [e] edit / [q] abort. Plan, Log und die Ausgabe jedes Schritts landen in ~/.hackingtool/goals/<UTC-Zeitstempel>/.
  • Für lange Scans im Hintergrund (mit tmux): /run nmap -sV -oA scan 10.0.0.5 & startet ein etikettiertes Panel; /panes listet, /attach beobachtet und /kill all stoppt alles.
  • Für ein skriptgesteuertes Engagement (CI oder Stapel): hackingtool --engagement acme --targets example.com --pipeline recon erzeugt findings.json; --engagement acme --report regeneriert den deterministischen Markdown-Bericht.

Wesentliche Konfiguration

Datei / EinstellungWas man zuerst anfasst
~/.hackingtool/config.jsonAlle Konsoleneinstellungen; bearbeitet mit /config (Pfeile zum Bewegen, t zum Testen der Verbindung) oder /config <schlüssel> <wert> (z. B. /config theme cyan, /config show_archived true).
~/.hackingtool/.envKI-Schlüssel (HACKINGTOOL_AI_KEY) und GitHub-Token (HACKINGTOOL_GITHUB_TOKEN), Modus 600; werden nie auf dem Bildschirm ausgegeben.
ai_base_url + ai_model (+ Schlüssel)Aktiviert die KI-Schicht mit jedem OpenAI-kompatiblen Endpunkt; bleibt ai_base_url leer, wird lokales Ollama genutzt (z. B. ollama pull llama3).
GitHub-Token ohne BerechtigungenErhöht das Limit von /find von 10 auf 30 Suchen pro Minute; muss ohne jeglichen Scope und ohne ausgewähltes Repository generiert werden.
background_runneroff deaktiviert die tmux-Hintergrund-Panels.

Umgebungsvariablen (HACKINGTOOL_AI_BASE_URL, HACKINGTOOL_AI_MODEL, HACKINGTOOL_AI_KEY, HACKINGTOOL_AI_PROVIDER) haben immer Vorrang vor config.json.

Häufige Fallstricke und Lösungen

  • Windows funktioniert nicht. Die Anwendung erkennt es und beendet sich. Die dokumentierte Lösung ist Linux oder macOS (Kali/Parrot sind die typischen Umgebungen).
  • Ohne tmux öffnet /run … & keine Panels. Die Konsole weist darauf hin und öffnet das Tool inline; lässt sich mit /config background_runner off deaktivieren.
  • /find ohne Token ist auf 10 Suchen/Minute der GitHub-API begrenzt. Mit einem persönlichen GitHub-Token ohne Scopes oder Berechtigungen steigt es auf 30; der Guide dokumentiert Schritt für Schritt, wo man es generiert (/config github).
  • Ohne konfiguriertes Modell plant /goal nicht: Es fällt auf Tool-Empfehlungen für dasselbe Ziel zurück. Die Verbindung wird mit /config test geprüft, das den echten Fehler meldet.
  • Projekthistorie (v1.x): Frühe Versionen schlugen unter Python 2 fehl (Syntaxfehler, Issue #174 mit 31 Kommentaren; #185 mit 11) und erforderten bestimmte Umgebungen (Issues #13 und #242, Installationsfehler mit sudo). Die Restrukturierung von 2026 löste das Installationsmodell (pipx/uv, kein erzwungenes sudo, kein curl | bash), aber wer alte Versionen aus einem 2020–2024-Klon installiert, wird auf diese dokumentierten Probleme stoßen.
  • Offensive Kategorien sind vorhanden. Der Katalog umfasst offensive Kategorien (DDoS, RAT, XSS, Phishing). Die 2026er-Schicht verweigert Anfragen außerhalb des Umfangs (Jamming, DoS, Massenbelästigung, Malware) in /find und verlangt die Bestätigung der Autorisierung in /goal, aber der vollständige Katalog bleibt verfügbar; die Verantwortung für den Umfang liegt beim Operator, wie SECURITY.md anerkennt.

Integrationen und Migration

  • Mit KI-Agenten: Der Operator-Brief (/skill, OPERATOR.md) ist das Skript, dem die KI-Schicht folgt; die Datei context7.json integriert die Dokumentation in Context7 für Coding-Agenten; und AKCodez/hackingtool-plugin bringt den Katalog mit Docker-/WSL-Backends zu Claude Code.
  • Mit CI: Der Headless-Modus (--engagement, --pipeline recon, findings.json, --report) ist für Pipelines gedacht; das normalisierte JSON lässt sich grep-en, diffen oder in andere Tools einspeisen.
  • Mit Sicherheits-Distros: Ist ein Tool bereits im PATH (apt, brew, Kali-Metapakete), verwendet hackingtool die Binärdatei erneut, statt neu zu klonen; deshalb koexistiert es mit einer Kali-Installation, statt sie zu ersetzen.
  • Migration von Legacy-Launchern (v1.x): Der Ablauf besteht darin, das aktuelle Repository zu klonen und mit pipx install . zu installieren; das alte sudo git clone && sudo ./hackingtool.py ist obsolet, und die Tools leben nun in ~/.hackingtool/tools/ statt in Systempfaden.
  • Migration zu etwas anderem: Die zugrunde liegenden Tools (nmap, sqlmap, nuclei usw.) sind unabhängige Projekte; hackingtool zu verlassen bedeutet einfach, den Launcher nicht mehr zu nutzen — das Wissen über jedes Tool ist dasselbe, das man erhielte, würde man es separat dokumentieren.

Zahlen zum Repo

Messung: 25. August 2026, GitHub-API.

MetrikWert
Sterne79.100
Forks8.975
Abonnenten1.474
Commits auf master340
open_issues_count der API132
Gesamtzahl der Issues (Such-API)525
Gesamtzahl der Pull Requests (Such-API)166
HauptsprachePython (487.109 Bytes; Dockerfile 1.520; Shell 949; Makefile 384)
LizenzMIT
Erstellung11. April 2020
Letzter Push23. August 2026
Letztes Tagv3.0.0 (26. Juli 2026); auch v1.1.0 (2020) und v1.0 (2020)

Die wichtigsten von der API zurückgegebenen Contributor nach Beitragszahl: Z4nzu (122), cclauss (85), Greatest125 (69), mokrunka (6), W1LDN16H7 (4). Die 340-Commits-Zahl wurde von der letzten Seite des Paginierungslinks der Commits-API ermittelt. Die GitHub-API nutzt open_issues_count, was offene Pull Requests einschließen kann, weshalb es nicht als reine Issue-Zahl gelesen werden sollte; die Such-API unterscheidet 525 Issues und 166 PRs insgesamt (offen und geschlossen). Ebenso spiegelt watchers_count der allgemeinen Antwort die Sternezahl; deshalb wird subscribers_count als die tatsächliche Abonnentenzahl gemeldet. Das Tag v2.0.0 existiert nicht als Tag: nur als Name in den Commits des Redesigns (März und Juli 2026).

Wie man beiträgt

Der in CONTRIBUTING.md dokumentierte Prozess ist konkret:

  1. Entwicklungsvorbereitung: git clone + make setup (einmalig: verweist git auf .githooks, dessen Pre-Push das Verifikations-Gate ausführt) und uv run hackingtool, um aus dem Quellcode auszuführen.
  2. Das Gate: make check (ruff mit verpflichtenden Lint-Fehlern + pytest + Katalog- und Schemavalidierung) ist genau das Skript, das CI und der Pre-Push-Hook (scripts/check.sh) ausführen. Die Überprüfung eines PR gilt als „Gummistempel” eines grünen Gates, weshalb erwartet wird, dass es grün ist, mit einer hinzugefügten Prüfung für nicht-triviale Logik.
  3. Ein Tool hinzufügen (bevorzugter Weg): ein einzelner YAML-Eintrag in src/hackingtool/catalog/ — neu oder als „Overlay” über einem bestehenden (gepaart nach exaktem title). Tags müssen in TAXONOMY von src/hackingtool/tags.py existieren; usage sind [Beschreibung, Befehl]-Paare mit kanonischen, dokumentierten Befehlen; Überwachungs-/C2-/Keylogger-/RAT-Tools erhalten nur Tags, keine operativen Befehle.
  4. Legacy-Weg: eine Python-Klasse in der passenden Datei tools/*.py, mit Installern in Listenform und fixierten Downloads + SHA-256.
  5. PRs: von master verzweigen (niemals direkt zu master committen), Titel [New Tool] Name — Kategorie, [Fix] … oder [Improve] …, beschreiben, was sich geändert hat und was getestet wurde, eine logische Änderung pro PR, und die PR-Vorlage verwenden.
  6. Fehler und Sicherheit: funktionale Bugs mit der Bug-Report-Vorlage; Schwachstellen privat, über den Advisory-Flow von GitHub (SECURITY.md: Bestätigung innerhalb von 5 Werktagen, eine Behebung oder ein Plan innerhalb von 30 Tagen für bestätigte Meldungen).

Wie die Community es aufnahm

Die öffentliche Aufnahme ist bemerkenswert asymmetrisch: Die massive Adoption (79.100 Sterne, die größte in der Kategorie) steht im Kontrast zu einer Knappheit verifizierbarer öffentlicher Debatte.

  • Hacker News: Es wurde kein diesem Repository gewidmeter Thread gefunden. Suchen nach dem Namen des Repos, nach Z4nzu, nach der Repository-URL und nach dem Motto des Projekts lieferten 0 relevante Ergebnisse (Treffer für “hacking tool” sind unabhängige Nachrichten: Bit Pirate, Pegasus, Metasploit usw.). Es werden also keine HN-Punkte oder -Kommentare abgeleitet.
  • Reddit: Nur über die Such-API gefundene Erwähnungen minimaler Aktivität: auf r/hacking der Thread 18jmsbu “Hackingtool don’t work for me can someone recommend something else?” (1 Punkt, 0 Kommentare); auf r/iguru 190l7qz “HackingTool 1.2.0: ALL IN ONE Hacking Tools” (1 Punkt, 0 Kommentare); und Crossposts von 15r59mg “I suggest you to read this articles if you want to start Hacking through CTFs” auf r/Kalilinux, r/tryhackme, r/InfoSecWriteups und r/securityCTF (1 Punkt jeweils). Keiner davon ist eine substantielle Diskussion.
  • GitHub (die eigentliche Debatte findet hier statt): Frühe Issues dokumentieren die Frustration von Einsteigern: #13 “error” (39 Kommentare), #174 SyntaxError (31), #185 (11), #242 “error while running sudo hackingtool” (10), #200 “Kali Linux not running the program” (8). Die Sicherheit des Launchers war ein frühes Thema: PR #116 behob die Ausführung via os.system (12 Kommentare), und PR #176 “Update ddos.py” (10 Kommentare) zeigt die Kontrolle, die die enthaltenen DDoS-Tools erhielten. Die Bilanz dieser Quellen: Die Adoption ist enorm und nachhaltig, aber das Projekt lebt eher von praktischer Nutzung als von öffentlicher Debatte; die dokumentierte Kritik konzentriert sich auf die Installationsreibung alter Versionen und auf die Präsenz offensiver Tools im Katalog.
  • YouTube: Videos kleinen Umfangs: “how to stay anonymous using Z4nzu’s hacking tool” (Kanal Waxweazel81, ~499 Aufrufe), “Z4nzu/hackingtool - Gource visualisation” (Kanal Gourcer, ~233 Aufrufe), und zwei Videos des Kanals “GitHub Daily Trend AI Podcast” über das Repository (~226 und ~2.289 Aufrufe, Letzteres auf Spanisch).

Hackingtool im Vergleich zu anderen Ansätzen

VorschlagVerifizierbare ÜbereinstimmungVerifizierbarer Unterschied
CodingRanjith/hackingtoolkit (746 Sterne)All-in-One-Python-Sammlung für Pentesting und Cybersicherheit.Eigener unabhängiger Katalog; in der konsultierten Quelle keine vergleichbare dokumentierte KI-Schicht.
AKCodez/hackingtool-plugin (1.016 Sterne)Derselbe Basiskatalog: Es ist ein Wrapper von Z4nzu/hackingtool für Claude Code.Es konkurriert nicht: Es erweitert. Bringt Docker-/WSL-Backends und eigens erstellte Images; läuft auf dem KI-Agenten statt in einer Konsole.
laxa/HackingTools (338 Sterne)Sammelt Hacking-Tools erschöpfend.Ist eine Liste, ohne Installation oder Konsole.
ByteHackr/HackingTools-2 (374 Sterne)Sammlung exzellenter Listen für Pentester.Meta-Liste (Listen von Listen), ohne Ausführung.
Kali LinuxGleiche Zielgruppe: Das README richtet sich explizit an Kali/Parrot-Nutzer.Kali bettet die Tools in die Distro ein; hackingtool läuft auf jedem Linux/macOS, nutzt bereits vorhandene Binärdateien erneut und fügt Entdeckungsschichten hinzu (Tags, /find, /goal), die die Distro nicht bietet.

Der nützlichste Vergleich ist der nach Schicht: Klassische All-in-One-Launcher (einschließlich der eigenen v1.x dieses Projekts) lösten „installieren und ausführen”; die 2026er-Version fügt „entdecken, planen und dokumentieren” hinzu, mit dem KI-Agenten als optionalem Assistenten.

Anwendungsfälle

  • Pentester und Red Teamer, die Engagements gegen ein Ziel eröffnen: /goal mit Autorisierungsbestätigung und Audit-Log pro Schritt (run.log unter ~/.hackingtool/goals/), tmux-Panels für lange Scans, und Headless-Modus (--engagement, findings.json, --report) für Pipelines oder reproduzierbare Deliverables.
  • Blue-Team-/DFIR-Analysten: Das README erklärt, dass defensive Formulierungen (“detect a SYN flood”, “hunt for…”) in /find nie verweigert werden, der Katalog 12 forensische und defensive Post-Exploitation-Tools umfasst, und Überwachungs-/C2-/RAT-Tools nur Tags tragen, keine operativen Befehle, per dokumentierter Designentscheidung.
  • OSINT-Ermittler: 26 Informationsbeschaffungs-Tools und das Tag osint als Einstiegspunkt (@tag:osint), zusammen mit der Context7-Integration für recherchierende Agenten.
  • Bug-Bounty-Jäger: /goal find live subdomains of example.com verkettet subfinder/httpx/nuclei mit schrittweiser Bestätigung; /find-Lesezeichen in found.yaml erlauben, ein persönliches Arsenal ohne Code aufzubauen.
  • Studierende und CTF-/THM-Spieler: Die „60-Sekunden-Grammatik” (Befehle, Arrobas, natürliche Sprache), pro Tool kuratierte Nutzungskarten und der KI-freie Betrieb (deterministischer Fallback) senken die Einstiegshürde gegenüber der separaten Installation von 215 Tools.
  • Teams, die KI-Agenten über Sicherheit betreiben: Der Operator-Brief (OPERATOR.md), die Datei context7.json und das Community-Plugin AKCodez/hackingtool-plugin (1.016 Sterne) dokumentieren das Muster, einen Agenten Katalog-Tools auswählen und ausführen zu lassen, mit Anti-Erfindungs-Regeln und begrenztem Vertrauen in Scan-Ausgaben.
  • Wartungspersonal für Sicherheitsinfrastruktur, das Oberflächen bewertet: Derselbe Katalog fungiert als auditierbares Inventar: 215 Tools, eine geschlossene 63-Tag-Taxonomie, fixierte und verifizierte Downloads sowie das Gate make check für Beiträge.

Ressourcen


Dieser Artikel kombiniert das README, docs/HOW-TO-USE.md, CONTRIBUTING.md, SECURITY.md, den Operator-Brief, die GitHub-API (gemessen am 25. August 2026), Hacker-News- und Reddit-Suchen, das Docker-Hub-Register und YouTube-Ergebnisse, gesammelt während dieser Recherche. Zahlen ändern sich mit der Zeit.

Kommentare