  ___ ___         __             _________                       __
 /   |   \_____ _/  |_  ____     \_   ___ \____________    ____ |  | __
/    ~    \__  \\   __\/ __ \    /    \  \/\_  __ \__  \ _/ ___\|  |/ /
\    Y    // __ \|  | \  ___/    \     \____|  | \// __ \\  \___|    <
 \___|_  /(____  /__|  \___  >____\______  /|__|  (____  /\___  >__|_ \
       \/      \/          \/_____/      \/            \/     \/     \/

Installation

Die Installation aus dem Quellcode ist der einzige unterstützte Weg. hate_crack wird nicht über PyPI verteilt: pip install hate-crack löst auf einen 0.0.0-Platzhalter auf, der absichtlich fehlschlägt und hierher zurückverweist. Der Name wird nur gehalten, damit niemand sonst ein Nachahmungsprodukt darunter veröffentlichen kann — siehe packaging/pypi-placeholder/.

1. hashcat installieren

Hashcat muss installiert und in Ihrem PATH verfügbar sein:

Ubuntu/Kali:```bash sudo apt-get install -y hashcat

macOS (Homebrew):```bash
brew install hashcat

Or lade eine vorgefertigte Binärdatei von https://hashcat.net/hashcat/ herunter und setze hcatPath in config.json auf deren Speicherort.

2. hate_crack herunterladen

Mit Submodulen klonen (erforderlich für hashcat-utils, princeprocessor, pcfg_cracker, Corporate_Masks und optional omen):```bash git clone --recurse-submodules https://github.com/trustedsec/hate_crack.git cd hate_crack

Wenn du ohne Submodule geklont hast, initialisiere sie:```bash
git submodule update --init --recursive

Dann passe die Konfiguration bei Bedarf an. hate_crack verwendet zwei Konfigurationsdateien, die jeweils einen eigenen Satz an Einstellungen besitzen:

config.json — Wortlistenpfade, Masken, Regeln, Tuning, Potfile, Hashcat-Pfad, Kandidatenlimits, Benachrichtigungs-Schalter, CLI-Präferenz-Standardwerte (35 Einstellungen).
.env — nur Einstellungen für Drittanbieter-Integrationen: Hashview- und Hashmob-Anmeldedaten, Pushover-Anmeldedaten, Ollama und pipal (14 Einstellungen). Nicht von git verfolgt, im Modus 0600 erstellt.

Die Trennung erfolgt aus einem Grund: .env ist die Datei, die Geheimnisse enthalten kann. Anmeldedaten für und Konfiguration von Drittanbieter-Diensten gehören in die nicht verfolgte Datei mit 0600; alles, was hate_crack lokal tut, bleibt in config.json, das sicher geteilt, per Diff verglichen und in die eigenen Notizen eingecheckt werden kann. Deshalb stehen auch die Pushover-Anmeldedaten in .env, während die Pushover-An/Aus-Schalter in config.json liegen — die Schalter sind lokale Präferenzen, keine Geheimnisse.

Jeder Schlüssel hat genau einen festen Platz. Ein Schlüssel, der in der anderen Datei platziert wird, wird ignoriert, und hate_crack gibt eine Warnung aus, die die Datei nennt, zu der er gehört. Jeder Schlüssel kann für einen einzelnen Lauf dennoch überschrieben werden, indem seine Umgebungsvariable exportiert wird. Die meisten Nutzer können diesen Schritt überspringen, da die Standardpfade sofort einsatzbereit funktionieren.

config.json ist dauerhaft und erstklassig — es ist nicht veraltet und es gibt keinen Entfernungszeitplan dafür. Nur die Integrationseinstellungen sind umgezogen.

Upgrade von einer einzelnen config.json? hate_crack migriert sie beim ersten Lauf für dich: Die Integrationseinstellungen werden in eine neue .env mit 0600 kopiert und dann aus config.json entfernt, sodass die beiden Dateien sie nicht beide beanspruchen. Es gibt aus, welche Schlüssel verschoben wurden (niemals deren Werte), und speichert dein Original als config.json.pre-split.bak, bevor es sie anfasst. Alles andere in config.json bleibt exakt so, wie es war, einschließlich der Schlüsselreihenfolge.

Erster Lauf: hate_crack erstellt beide Dateien für dich, es gibt also nichts zu tun. Um .env stattdessen von Hand einzurichten, kopiere die verfolgte Vorlage:```bash cp .env.example .env chmod 600 .env

`.env.example` wird mit ausgeliefert und enthält jeden Credential-Schlüssel leer. `.env` selbst darf **niemals** committet werden – es ist gitignored, zusammen mit seinen üblichen Backup-Schreibweisen, und hate_crack erstellt es immer mit Modus `0600` (nur Eigentümer lesen/schreiben). `.env.example` wird aus dem Schema generiert; generiere es nach Änderungen an `hate_crack/config_schema.py` mit `uv run python -m hate_crack.config_writer` neu.

### 3. Abhängigkeiten und hate_crack installieren

Der einfachste Weg ist, `make` (oder `make install`) auszuführen, das dein Betriebssystem automatisch erkennt und Folgendes installiert:
- Externe Abhängigkeiten (p7zip, transmission-daemon / transmission-remote)
- Baut Submodule (hashcat-utils, princeprocessor, pcfg_cracker und optional omen) und checkt den reinen Daten-Maskensatz Corporate_Masks aus
- Python-Abhängigkeiten über uv und einen CLI-Shim unter `~/.local/bin/hate_crack````bash
make

Dies ist idempotent – bereits installierte Tools werden übersprungen. Für eine saubere Neuinstallation:```bash make reinstall

**Oder Abhängigkeiten manuell installieren:**

### Externe Abhängigkeiten
Diese werden für bestimmte Download-/Extraktionsabläufe benötigt:

- `7z`/`7za` (p7zip) — wird zum Extrahieren von `.7z`-Archiven verwendet.
- `transmission-daemon` / `transmission-remote` — wird zum Herunterladen von Weakpass-Torrents verwendet.

Manuelle Installationsbefehle:

Ubuntu/Kali:```bash
sudo apt-get update
sudo apt-get install -y p7zip-full transmission-daemon

macOS (Homebrew):```bash brew install p7zip transmission-cli # provides transmission-daemon and transmission-remote

Dann installiere die Python-Abhängigkeiten und den CLI-Shim:```bash
uv sync
mkdir -p ~/.local/bin
printf '#!/usr/bin/env bash\nset -euo pipefail\nexec uv run --directory %s python -m hate_crack "$@"\n' "$(pwd)" > ~/.local/bin/hate_crack
chmod +x ~/.local/bin/hate_crack

Projektstruktur

Die Kernlogik ist nun in Module unter hate_crack/ aufgeteilt:

hate_crack/cli.py: argparse-Helfer und Konfigurationsüberschreibungen.
hate_crack/api.py: Hashview-, Weakpass- und Hashmob-Integrationen (Downloads/Menüs/Helfer).
hate_crack/attacks.py: Menü-Angriffshandler.
hate_crack/corpus_stats.py: Passwortstatistiken für den gesamten Korpus, die verwendet werden, um einen Korpus für das LLM zu beschreiben.
hate_crack/plaintext.py: stellt das Passwort aus einer Korpuszeile wieder her (Entfernen des Hash-Präfixes, $HEX[...]-Dekodierung); wird von den LLM-Modi, corpus_stats und rulegen gemeinsam genutzt.
hate_crack/llm.py: strukturierte (JSON) LLM-Kandidatengenerierung über Atomic Agents.
hate_crack/menu.py: gemeinsamer Menü-Renderer, einschließlich optionaler Pfeiltasten-Navigation.
hate_crack/noninteractive.py: Dispatcher für die skriptgesteuerten Angriffs-Unterbefehle.
hate_crack/notify/: Benachrichtigungspaket (Pushover-Backend, Tailer pro geknacktem Passwort).
hate_crack/username_detect.py: erkennt username:hash-Eingabedateien, um über hashcats --username zu entscheiden.
hate_crack/formatting.py, hate_crack/progress.py: Helfer für Ausgabeformatierung und Fortschrittsanzeige.
hate_crack/main.py: Haupt-CLI-Implementierung.

Die Datei hate_crack.py auf oberster Ebene bleibt der Haupteinstiegspunkt und orchestriert diese Module.

Referenzen und Danksagungen

Dieses Projekt hängt von einer Reihe externer Projekte und Dienste ab und ist von ihnen inspiriert. Dank an:

Verwendung

Nach der Installation mit make können Sie hate_crack von überall aus ausführen:```bash hate_crack

or with arguments:

hate_crack <hash_file> <hash_type> [options]

Alternativ über `uv` ausführen:```bash
uv run hate_crack.py <hash_file> <hash_type>

Als Tool ausführen (empfohlen)

Installation mit make aus dem Repository-Stammverzeichnis – dies erstellt Submodule und bündelt Assets:```bash cd /path/to/hate_crack make hate_crack

The `make install`-Befehl erstellt einen Bash-Shim unter `~/.local/bin/hate_crack`, der aus dem Repo-Verzeichnis heraus ausgeführt wird, sodass Konfiguration und Assets unabhängig von Ihrem aktuellen Arbeitsverzeichnis immer gefunden werden.

Die Konfiguration wird auch gesucht in:
- Dem Repo-Root und dem Paketverzeichnis
- `~/.hate_crack`

**Hinweis:** Der `hcatPath` in `config.json` dient nur für den Speicherort der hashcat-Binärdatei (optional, wenn hashcat im PATH ist). Hate_crack-Assets (hashcat-utils, princeprocessor, pcfg_cracker, Corporate_Masks, omen) werden aus dem Repository-Verzeichnis geladen und automatisch von `make install` gebündelt.

### Als Skript ausführen
Das Skript verwendet einen `uv`-Shebang. Machen Sie es ausführbar und führen Sie es aus:```bash
chmod +x hate_crack.py
./hate_crack.py

Du kannst auch Python direkt verwenden:```bash python hate_crack.py

### Nicht-interaktive / Skript-Nutzung

Für die Automatisierung können Sie einen einzelnen Angriff direkt starten und dabei das Menü umgehen. Der Angriffsname ist das erste Argument, gefolgt von der Hash-Datei und dem Hashcat-Hash-Typ. Vorverarbeitungsabfragen (Computer-Konten-Filterung, LM-zuerst-Brute-Force, Deduplizierung doppelter Konten) akzeptieren in diesem Modus automatisch ihre Standardwerte. Der Prozess beendet sich mit `0` bei Erfolg und mit einem Wert ungleich Null bei einem Fehler (fehlende Hash-Datei, nicht-numerischer Hash-Typ, fehlende Wortliste oder ein unbekannter Regel-Dateiname).```bash
# Quick crack: one wordlist + optional rule(s) from the rules directory
hate_crack quick hashes.txt 1000 --wordlist rockyou.txt --rules best64.rule

# Chain two rules in a single run
hate_crack quick hashes.txt 1000 --wordlist rockyou.txt --rules best64.rule+d3ad0ne.rule

# Run two rules as two separate passes
hate_crack quick hashes.txt 1000 --wordlist rockyou.txt --rules best64.rule d3ad0ne.rule

# Canned dictionary methodology (uses your configured wordlists)
hate_crack dict hashes.txt 1000

# Brute force lengths 1-8
hate_crack brute hashes.txt 1000 --min 1 --max 8

# Top-mask attack targeting ~4 hours
hate_crack topmask hashes.txt 1000 --target-time 4

Fehlerbehebung

Fehler: „would clobber existing tag“ beim Aktualisieren

Ein älterer Klon kann die Aktualisierung verweigern und eine lange Liste von Zeilen wie diese ausgeben:``` ! [rejected] v2.5.0 -> v2.5.0 (would clobber existing tag)

Dies betrifft Klone, die vor Juli 2026 erstellt wurden. Die veröffentlichte Historie wurde damals
neu geschrieben, um einige Dateien zu entfernen, die niemals hätten committet werden dürfen, wodurch
jeder Commit eine neue ID erhielt; die Tags eines älteren Klons zeigen daher auf Objekte, die dieses
Repository nicht mehr enthält, und git weigert sich, ein Tag zu verschieben, das es bereits besitzt.
Mit Ihrem Checkout ist nichts falsch und keine Cracking-Daten sind gefährdet.

Stellen Sie es mit einem einmaligen Reset wieder her. Dies verwirft lokale Commits und Änderungen im
Checkout. Wenn Sie also etwas angepasst haben, das von git verfolgt wird (im Gegensatz zu
`config.json`, das nicht verfolgt wird), committen Sie es zuerst auf einen Branch:```bash
cd /path/to/hate_crack
git fetch --tags --force origin
git checkout -B main origin/main
make install

--force aktualisiert hier nur die Tags; es kann deine Commits nicht verändern. Danach funktioniert der integrierte Updater normal. Versionen vor 2.18 konnten diese Wiederherstellung nicht selbst durchführen, weshalb sie einmalig von Hand erledigt werden muss.

Fehler: Build-Verzeichnis existiert nicht

Wenn du einen Fehler wie diesen siehst:``` Error: Build directory /opt/hashcat/hashcat-utils does not exist. Expected to find expander at /opt/hashcat/hashcat-utils/bin/expander.

Dies bedeutet, dass die hate_crack-Assets nicht in das installierte Paket gebündelt wurden.

**Die Pfade verstehen:**
- `hcatPath` in config.json → zeigt auf den **Speicherort der hashcat-Binärdatei** (optional, kann im PATH liegen)
- `hashcat-utils/` und `princeprocessor/` → werden durch `make install` in das Paket gebündelt

**Lösung:**
Installieren Sie das Tool erneut über das Makefile, das die Untermodule erstellt und das Tool installiert:```bash
cd /path/to/hate_crack  # the repository checkout
make install

Standardkonfiguration (config.json.example):

Die meisten Benutzer können die Standardwerte ohne Anpassung verwenden:

hcatWordlists: ./wordlists (relativ zum Repository-Stammverzeichnis oder HOME/.hate_crack)
hcatOptimizedWordlists: ./optimized_wordlists (Verzeichnis, das von Quick Crack verwendet wird; fällt auf hcatWordlists zurück, falls nicht gefunden)
rules_directory: ./hashcat/rules (enthält Submodul-Regeln)
hcatTuning: `` (leerer String – keine Standard-Tuning-Flags)

Beispiel für config.json-Anpassungen:```json { "hcatPath": "/usr/local/bin", # Location of hashcat binary (optional, auto-detected from PATH) "hcatBin": "hashcat", # Hashcat binary name "hcatWordlists": "./wordlists", # Dictionary wordlist directory (relative or absolute) "rules_directory": "./hashcat/rules", # Rules directory (relative or absolute) "hcatTuning": "", # Additional hashcat flags (empty by default) ... }

**Konfigurationsladung:**
- Priorität für jeden Schlüssel: `os.environ` > die eigene Home-Datei des Schlüssels (`.env` oder `config.json`) > eingebauter Standardwert
- Fehlende Schlüssel fallen auf die eingebauten Standardwerte zurück; `config.json.example` dokumentiert jeden `config.json`-Schlüssel
- Beide Dateien werden unabhängig voneinander in dieser Reihenfolge durchsucht: **Repo-Root**, dann das **installierte Paketverzeichnis**, dann **`~/.hate_crack`**. Der erste Treffer gewinnt; es ist normal, dass die beiden Dateien aus verschiedenen Verzeichnissen stammen.
- Beim ersten Lauf werden beide erstellt — `config.json` aus `config.json.example`, `.env` aus den eingebauten Standardwerten. Wenn eine ältere `config.json` noch Integrationsschlüssel enthält, werden diese in die neue `.env` kopiert und hate_crack teilt dir mit, welche du aus `config.json` löschen sollst; es bearbeitet diese Datei selbst nie.
- Bei jedem Lauf gibt hate_crack die beiden tatsächlich geladenen Dateien aus:  ```
  [*] config.json: /home/you/.hate_crack/config.json
  [*] .env:        /home/you/.hate_crack/.env

Lies diese beiden Zeilen, bevor du eine Einstellung debuggst, die „nicht greift“. Sie existieren wegen zweier Fallstricke in der Suchreihenfolge:

Ein Checkout hat Vorrang vor deinem Home-Verzeichnis. Die Repo-Wurzel wird zuerst durchsucht, also gewinnt eine .env oder config.json, die in irgendeinem Checkout liegt, von dem aus du das Tool ausführst, gegenüber der in ~/.hate_crack — und das Ausführen des Tools aus einem Checkout ist genau das, was diese Dateien dort überhaupt erst erzeugt. Falls das jemals eine echte ~/.hate_crack-Konfiguration überschattet, weist hate_crack jetzt mit einer dritten [!]-Zeile darauf hin, die beide Pfade nennt — behandle diese Zeile als „die Datei unten wird ignoriert“, nicht als zweite, gleichermaßen gültige Konfiguration.
Das aktuelle Arbeitsverzeichnis wird nie durchsucht. Eine .env in dem Verzeichnis, in dem du dich gerade befindest, wird absichtlich ignoriert: Engagement-Verzeichnisse sind voller Dateien, die niemand als Konfiguration gedacht hat. Lege sie in die Repo-Wurzel oder nach ~/.hate_crack.

Fehler: merge with ref 'refs/heads/master' but no such ref was fetched

Wenn du Folgendes siehst:``` Your configuration specifies to merge with the ref 'refs/heads/master' from the remote, but no such ref was fetched.

The default branch was renamed from `master` to `main`. Fix with:```bash
git remote set-head origin -a
git branch -m master main
git branch --set-upstream-to=origin/main main
git pull

Makefile-Ziele

Standard (vollständige Installation) – erstellt Submodule, installiert Abhängigkeiten und installiert das Tool:```bash make

or explicitly:

make install

Dies ist idempotent – bereits installierte Tools werden übersprungen.

**Erzwungene saubere Neuinstallation:**```bash
make reinstall

Schnelles Update – baut Submodule neu auf und installiert das Tool neu (nach dem Ziehen von Änderungen):```bash make update

**Deinstallation** – entfernt Betriebssystem-Abhängigkeiten und das Tool:```bash
make uninstall

Nur hashcat-utils erstellen:```bash make hashcat-utils

**Tests ausführen** – übernimmt automatisch HATE_CRACK_SKIP_INIT, wenn nötig:```bash
make test

Abdeckungsbericht:```bash make coverage

**Build-/Test-Artefakte bereinigen:**```bash
make clean

Entwicklung

Einrichtung der Entwicklungsumgebung

Installieren Sie das Projekt mit optionalen Entwicklungsabhängigkeiten (einschließlich Linter und Testwerkzeugen):```bash make dev-install

### Linter und Typprüfungen ausführen

Bevor du Änderungen pushst, führe diese Prüfungen lokal aus. Verwende `make lint` für alles, oder führe einzelne Prüfungen aus:

**Ruff (Linting und Formatierung):**```bash
make ruff
# or manually:
uv run ruff check hate_crack tests tools packaging hate_crack.py

Auto-Fix-Probleme:```bash uv run ruff format hate_crack tests tools packaging hate_crack.py uv run ruff check --fix hate_crack tests tools packaging hate_crack.py

**ty (Typprüfung):**```bash
make ty
# or manually:
uv run ty check hate_crack

Alle Prüfungen gemeinsam ausführen:```bash make lint

### Tests ausführen

Die Tests erkennen automatisch, wenn Submodule nicht gebaut sind, und setzen `HATE_CRACK_SKIP_INIT=1` automatisch.```bash
make test

Or führen Sie pytest direkt aus:```bash uv run pytest -v

Mit Abdeckung:```bash
make coverage

Or with pytest:```bash uv run pytest --cov=hate_crack

### Git Hooks (prek)

Git-Hooks werden von [prek](https://github.com/j178/prek) (v0.3.3+) verwaltet. Installiere die Hooks mit:```bash
prek install --hook-type pre-push --hook-type pre-commit

Dies installiert die Hooks, die in prek.toml definiert sind, unter Verwendung des pre-commit local-repo-TOML-Schemas:

pre-push (lokale Hooks): ruff, ruff-format, ty, pytest, pytest-lima, bandit
pre-commit (von pre-commit/pre-commit-hooks): trailing-whitespace, end-of-file-fixer, check-yaml, check-merge-conflict, check-added-large-files, detect-private-key

Die pre-commit-Auto-Fixer schreiben Dateien direkt um, also stufe sie erneut ein und committe erneut, nachdem sie ausgeführt wurden.

Hinweis: prek 0.3.3 erwartet repos = [...] auf der obersten Ebene. Das alte Format [hooks.<stage>] commands = [...] wird nicht unterstützt.

Menüs verwenden standardmäßig die klassische nummerierte Auswahl über print() + input(), die vollständige mehrstellige Tasten akzeptiert.

Um die Pfeiltasten-Navigation über simple-term-menu zu aktivieren, setze HATE_CRACK_ARROW_MENU=1. In diesem Modus funktionieren nur einstellige Schnellwahltasten; Optionen ab Nummer 10 müssen mit den Pfeiltasten erreicht werden. Der Pfeiltasten-Modus erfordert außerdem ein TTY, daher bleibt er deaktiviert, wenn die Ausgabe weitergeleitet wird.

Entwicklungsabhängigkeiten

Die optionale Gruppe [dev] umfasst:

ty - Statischer Typprüfer
ruff - Schneller Python-Linter und -Formatierer
pytest - Test-Framework
pytest-cov - Abdeckungsberichterstattung

Allgemeine Optionen:

--download-hashview: Hashes von Hashview herunterladen, bevor mit dem Knacken begonnen wird.
--hashview: Interaktives Hashview-Menü zur Verwaltung von Hashes, Wortlisten und Jobs.
--hashview --help: Hashview-Befehlszeilenoptionen anzeigen.
--weakpass: Wortlisten von Weakpass herunterladen.
--hashmob: Wortlisten von Hashmob.net herunterladen.
--hashmob-masks: Masken von Hashmob.net herunterladen.
--download-torrent <FILENAME>: Eine bestimmte Weakpass-Torrent-Datei herunterladen.
--download-all-torrents: Alle verfügbaren Weakpass-Torrents aus dem Cache herunterladen.
--wordlists-dir <PATH> / --optimized-wordlists-dir <PATH>: Wortlistenverzeichnisse überschreiben.
--pipal-path <PATH>: Pipal-Pfad überschreiben.
--restore-potfile: <hashfile>.out beim Start aus der hashcat-POT-Datei neu aufbauen, vorhandene Inhalte ersetzen und dann mit dem normalen Menü fortfahren. Ohne dieses Flag wird die POT-Suche nur ausgeführt, wenn .out nicht bereits existiert. Menüoption 93 macht dasselbe bei Bedarf, mit einer Bestätigungsabfrage.
--maxruntime <SECONDS>: Maximale Laufzeit überschreiben.
--bandrel-basewords <PATH>: Bandrel-Basiswortdatei überschreiben.
--update: Auf die neueste Version aktualisieren und neu installieren. Wechselt den Checkout auf main, wenn er sich auf einem anderen Branch befindet, da sich dort die Release-Tags befinden.
--nightly: Stattdessen auf die neueste Nightly-Version vom Branch nightly-dev aktualisieren. Nightly-Builds haben CI bestanden, sind aber nicht Teil eines veröffentlichten Releases. Kann auch als --update --nightly geschrieben werden.
--no-optimized-kernel (oder --no-optimize): Übergibt für den gesamten Lauf niemals -O an hashcat. Überschreibt optimizedKernelAttacks in config.json und entfernt jedes -O, das du in hcatTuning eingefügt hast. Es wird nichts zurück in die Konfiguration geschrieben, daher gilt dies nur für diesen Lauf. Bei einem Unterbefehl platziere es vor dem Unterbefehl: ./hate_crack.py --no-optimize quick hashes.txt 1000 --wordlist words.txt.
--debug: Debug-Logging aktivieren (schreibt nach stderr).

Hashview-Integration

hate_crack integriert sich in Hashview für zentrales Hash-Management und verteiltes Knacken.

Auf das interaktive Hashview-Menü zugreifen:```bash hate_crack.py --hashview

Menüoptionen:
- **(1) Cracked Hashes hochladen** – Cracked Ergebnisse aus der aktuellen Sitzung zu Hashview hochladen
- **(2) Wortliste hochladen** – Eine Wortlistendatei zu Hashview hochladen
- **(3) Wortliste herunterladen** – Eine Wortliste von Hashview herunterladen
- **Regel herunterladen** – Eine Regeldatei von Hashview herunterladen (dekomprimiert zu Klartext, bereit für `hashcat -r`)
- **Alle Regeln herunterladen** – Jede von Hashview gelistete Regeldatei in einem Durchgang herunterladen; Fehler bei einzelnen Regeln werden gemeldet, ohne den Rest abzubrechen
- **(4) Verbleibende Hashes herunterladen** – Verbleibende ungecrackte Hashes herunterladen (fragt nach Wechsel zum Cracken)
- **(5) Gefundene Hashes herunterladen** – Bereits gecrackte Hashes mit Klartext-Passwörtern herunterladen (zur Referenz/Analyse)
- **(6) Hashdatei hochladen und Job erstellen** – Neue Hashdatei hochladen und einen Crack-Job erstellen
- **(99) Zurück zum Hauptmenü** – Zum Hauptmenü zurückkehren

**Wichtig: Gefundene herunterladen vs. Verbleibende herunterladen**
- **Verbleibende Hashes herunterladen (4)**: Lädt ungecrackte Hashes herunter, die gecrackt werden müssen. Wird automatisch mit gefundenen Hashes zusammengeführt, falls verfügbar, und fragt nach Wechsel zu dieser Hashdatei zum Cracken.
- **Gefundene Hashes herunterladen (5)**: Lädt bereits gecrackte Hashes im Format hash:Klartext herunter. Diese dienen zur Referenz und können nicht weiter gecrackt werden. Es wird keine Wechselabfrage angezeigt.

#### Befehlszeilenschnittstelle

Hashview-Operationen können auch über die Befehlszeile durchgeführt werden:

Cracked Hashes hochladen:```bash
hate_crack.py --hashview upload-cracked --file <output_file>.out --hash-type 1000

Lade eine Wortliste hoch:```bash hate_crack.py --hashview upload-wordlist --file .txt --name "My Wordlist"

Downloaden Sie eine Regeldatei (dekomprimiert gespeichert, bereit für `hashcat -r`):```bash
hate_crack.py --hashview download-rules --rules-id 4 --output best64.rule

Download left hashes (uncracked hashes for cracking):```bash hate_crack.py --hashview download-left --customer-id 1 --hashfile-id 123

Download gefundener Hashes (bereits geknackte Hashes mit Klartext):```bash
hate_crack.py --hashview download-found --customer-id 1 --hashfile-id 123

Upload-Hashdatei und Job erstellen:```bash hate_crack.py --hashview upload-hashfile-job --file hashes.txt --customer-id 1
--hash-type 1000 --job-name "NTLM Crack Job" --hashfile-name "Domain Hashes"

#### Konfiguration

Setzen Sie die Hashview-Anmeldedaten in `.env` (es handelt sich um Integrationseinstellungen, daher befinden sie sich nicht in `config.json`):```
HASHVIEW_URL=https://hashview.example.com
HASHVIEW_API_KEY=your-api-key-here

LLM-Konfiguration

Der LLM-Angriff (Option 12) und der Rosetta-Mask-Angriff (Option 23) erzeugen ihre Kandidaten mit einem lokalen Modell. Konfigurieren Sie das Modell, das Kontextfenster und das Request-Timeout in .env:``` LLM_BACKEND=ollama OLLAMA_MODEL=qwen3:4b-instruct OLLAMA_NUM_CTX=8192 OLLAMA_TIMEOUT=300

**Die `OLLAMA_*`-Schlüssel unten gelten für jedes Backend, nicht nur für Ollama.** Sie behalten dieses Präfix, weil `OLLAMA_HOST` dieselbe Variable ist, die auch Ollamas eigene CLI liest, und eine Umbenennung würde jede bestehende `.env` ohne funktionalen Gewinn brechen — ein vLLM- oder OpenAI-kompatibler Server möchte dieselben Host-, Modell-, Timeout-, Kontext- und Sampling-Regler unter denselben Namen. `LLM_BACKEND` wählt nur aus, wie die Anfrage geformt wird.

- **`OLLAMA_MODEL`** — Das Ollama-Modell, das für die Kandidatengenerierung verwendet wird (Standard: `qwen3:4b-instruct`). Der LLM-Angriff verwendet strukturierte (JSON-)Ausgabe, wähle also ein Modell mit guter Tool-/JSON-Unterstützung.
- **`OLLAMA_NUM_CTX`** — Kontextfenstergröße für das Modell (Standard: `8192`). Dies war vor der Einführung der Korpusstatistiken `2048`, was zu klein war, um den Prompt zu fassen, den es erhielt: 500 gesampelte Klartexte umfassen grob 2.000–3.500 Tokens vor System-Prompt und Antwort, sodass Ollama stillschweigend einen Teil der Stichprobe abschnitt, die der Sampler sorgfältig über die Datei verteilt hatte.
- **`OLLAMA_TIMEOUT`** — Sekunden, die auf eine Generierungsantwort gewartet wird, bevor aufgegeben wird (Standard: `300`). Erhöhe diesen Wert, wenn ein großes Modell bei der ersten Anfrage noch in den VRAM lädt, was sonst den Timeout überschreiten kann; hate_crack gibt den verstrichenen Timeout und den Namen dieser Einstellung aus, wenn er auslöst.
- **`OLLAMA_MAX_SAMPLE_LINES`** — Der Schwellenwert, unterhalb dessen die LLM-Modi auch die wörtlichen Klartexte in den Prompt einfügen (Standard: `500`). Werte ≤ 0 werden als 500 behandelt.

  Korpusbasierte Modi (**Wortliste**, **Geknackte Passwörter**, **Musterregeln**) beschreiben immer den *gesamten* Korpus statistisch — Basiswortanteile, Masken, Groß-/Kleinschreibung, Längen, nachgestellte Ziffern und Symbole, Jahreszahlen — statt einen Ausschnitt davon einzufügen. Die Aggregation ist begrenzt, sodass ein Dump mit 120.000 Passwörtern etwa denselben Prompt-Platz kostet wie einer mit 500 Zeilen. Wenn der gesamte Korpus unter diesen Schwellenwert fällt, werden die rohen Klartexte ebenfalls einbezogen, da nichts gewonnen wird, wenn man dem Modell einen kleinen Korpus vorenthält.

  Dies ersetzt das bisherige Verhalten, eine gleichmäßig verteilte Stichprobe von bis zu `ollamaMaxSampleLines` Passwörtern einzufügen. Eine Stichprobe eines großen Dumps vermittelte keinerlei Häufigkeitsinformationen: Das Modell konnte ein Basiswort, das von 8 % der Organisation verwendet wird, nicht von einem unterscheiden, das nur eine einzelne Person nutzt — genau das Signal, das einen Versuch lohnenswert macht.
- **`OLLAMA_NO_CLOUD`** — Wenn `true`, weigert sich das Tool, irgendetwas von diesem Host zu senden, für alle drei LLM-Backends (Ollama, vLLM oder einen generischen OpenAI-kompatiblen Server). Zwei Prüfungen werden durch diese eine Einstellung gesteuert: Ollama leitet ein mit `-cloud` gekennzeichnetes Modell (`gpt-oss:120b-cloud`, `deepseek-v3.1:671b-cloud`) über denselben lokalen Endpunkt, den auch ein lokales Modell nutzt, an ollama.com weiter, sodass an der Anfrage nichts anders aussieht — das wird per Modellname abgelehnt. Die konfigurierte Backend-URL wird ebenfalls geprüft: Ein Ziel, das weder Loopback, privat noch link-lokal ist (und nicht `localhost` oder ein `.local`/`.internal`/`.lan`/`.localdomain`-Name), wird per Ziel abgelehnt, und ein Hostname, den diese Prüfung nicht auflösen kann, wird ebenfalls abgelehnt — fail-closed — statt ein nicht verifizierbares Ziel durchzulassen. hate_cracks Prompts enthalten wiederhergestellte Klartexte, Korpusstatistiken sowie Name, Branche und Standort des Kunden, sodass jede auslösende Prüfung bedeutet, dass die Anfrage abgelehnt wird, bevor sie erstellt wird. Standard ist `false`, sodass ein bewusst konfiguriertes Cloud-Modell oder ein Remote-Server weiterhin funktioniert; aktiviere es für Engagements, bei denen Kundendaten den Host nicht verlassen dürfen.
- **`OLLAMA_AUTO_RESEARCH`** — Wenn `true` (Standard), fragt der Modus **Zielinformationen** das lokale Modell, sobald du den Firmennamen eingegeben hast, nach Branche, Standort und Muttergesellschaft / Übernahmegeschichte und bietet sie als bearbeitbare Prompt-Standardwerte an. Setze es auf `false`, um immer leere Prompts zu erhalten (nützlich bei einem langsamen Modell, da die Recherche einen zusätzlichen Round-Trip vor Angriffsbeginn kostet).
- **`OLLAMA_HOST`** — Wo das konfigurierte Backend lauscht. Akzeptiert ein nacktes `host:port` (`theplague.lan:11434`) oder eine vollständige URL mit Schema (`https://ollama.example.com`); in beiden Fällen wird die Basis-URL vor der Verwendung normalisiert. Standard ist `localhost:11434`, Ollamas Port — ein vLLM- oder OpenAI-kompatibler Server benötigt hier seinen eigenen (vLLM lauscht üblicherweise auf `:8000`). Setze es in `.env` oder exportiere es als echte Umgebungsvariable, um es für einen einzelnen Lauf zu überschreiben — es ist dieselbe Variablenbezeichnung, die auch Ollamas eigene CLI liest.
- **`LLM_BACKEND`** — Mit welchem OpenAI-kompatiblen Server gesprochen wird: `ollama` (Standard), `vllm` oder `openai` für einen generischen. Jedes Backend spricht dieselbe `/v1`-Chat-Completions-API, sodass dies nur die zwei Details der Anfrageformung auswählt, in denen sie sich unterscheiden: `ollama` erhält `options.num_ctx`, und `vllm` erhält `chat_template_kwargs={"thinking": false}` — ohne das leitet ein vLLM-Server mit Reasoning-Parser die gesamte strukturierte Antwort in `message.reasoning` um, lässt `message.content` leer und bricht die JSON-Parsung. `openai` sendet keines von beiden, da `num_ctx` dort keine Entsprechung hat. Es ändert **nicht**, woher Host-, Modell-, Timeout-, Kontext- oder Sampling-Einstellungen kommen — das sind für alle drei die `OLLAMA_*`-Schlüssel oben.
- **`LLM_API_KEY`** — Die Anmeldedaten, die an das konfigurierte Backend gesendet werden. Standard ist der wörtliche Wert `ollama`, der Platzhalter, den Ollamas eigener Server ignoriert, sodass die Anfragen einer bestehenden Installation unverändert bleiben; ein leerer Wert fällt auf denselben Platzhalter zurück, weil das OpenAI-SDK `api_key=""` ablehnt. Setze es auf den echten Wert, wenn der Server einen erzwingt — ein mit `--api-key` gestarteter vLLM-Server gibt sonst 401 zurück.
- Stelle sicher, dass Ollama läuft und das Modell geladen ist (`ollama pull qwen3:4b-instruct`), bevor du den LLM-Angriff verwendest — hate_crack lädt fehlende Modelle nicht mehr automatisch nach.

Der Angriff bietet drei Generierungsmodi:

1. **Zielinformationen** — Firma / Branche / Standort / Muttergesellschaft; das Modell leitet Kandidaten aus diesen Details ab.

   Nachdem du den Firmennamen eingegeben hast, fragt hate_crack dasselbe lokale Modell, was es bereits über diese Organisation weiß, und füllt die Prompts **Branche**, **Standort** und **Muttergesellschaft** mit den Antworten vor, die in Klammern angezeigt werden:   ```
   Company name: Acme Rail Services

   [!] The values in parentheses below are the local model's GUESSES, not verified OSINT.
       Press Enter to accept, or type your own value to override.
   Industry (freight rail maintenance):
   Location (Omaha, Nebraska):
   Parent company / acquired by:

Drücken Sie die Eingabetaste, um einen Vorschlag zu übernehmen, oder überschreiben Sie ihn. Diese Werte sind die Erinnerung des Modells, kein OSINT – behandeln Sie sie als Ausgangspunkt, nicht als Informationen über den Kunden. Die Suche verwendet nur den lokalen Ollama-Server, sodass der Kundenname den Host nie verlässt; es gibt keine Web- oder Drittanbieter-API-Aufrufe. Wenn das Modell die Organisation nicht erkennt (der häufige Fall bei kleinen Kunden), gibt es nichts zurück und Sie erhalten einfache leere Eingabeaufforderungen: ``` Company name: Acme Rail Services Industry: Location: Parent company / acquired by:

Ein Forschungsfehler — Timeout, Ollama läuft nicht, leere Antwort — blockiert den Angriff nie; er fällt einfach auf leere Prompts zurück. Setze `ollamaAutoResearch` auf `false`, um die Recherche vollständig zu überspringen.
2. **Wortliste** — leite Basiswörter aus einer Beispiel-Wortliste ab.
3. **Geknackte Passwörter** — füttere die in dieser Sitzung bereits wiederhergestellten Klartexte (`<hashfile>.out`) zurück an das Modell, damit es die eigenen Passwortkonventionen der Zielorganisation ableiten kann (Basiswörter, Jahreszeiten, Jahre, Suffixe, Leetspeak) und *neue* Kandidaten im gleichen Stil generiert. Diese Option wird nur aufgelistet, sobald mindestens ein Hash geknackt wurde; die gesamte Datei wird statistisch genau wie im Wortlisten-Modus analysiert (siehe `ollamaMaxSampleLines` oben).

#### PCFG-Konfiguration

Der PCFG-Angriff (Option 20) und der PRINCE-LING-Angriff (Option 21) verwenden das `pcfg_cracker`-Untermodul. Konfiguriere sie in `config.json`:```json
{
"pcfgRuleset": "DEFAULT",
"pcfgMaxCandidates": 50000000,
"pcfgPrinceLingMaxCandidates": 10000000
}

pcfgRuleset — Name des trainierten Grammatikmodells, das verwendet werden soll (Standard: DEFAULT), aufgelöst zu pcfg_cracker/Rules/<name>/. Trainiere dein eigenes mit trainer.py von pcfg_cracker und setze dies auf den Namen des Regelsatzes.
pcfgMaxCandidates — Maximale Kandidaten, die pcfg_guesser.py für den PCFG-Angriff ausgibt (Standard: 50000000).
pcfgPrinceLingMaxCandidates — Maximale Basiswörter, die prince_ling.py in die gecachte PRINCE-Basiswortliste schreibt (Standard: 10000000).

Optimierte Kernel (`optimizedKernelAttacks`)

Das -O-Flag von hashcat wählt optimierte Kernel aus, die erheblich schneller sind, aber die Kandidatenlänge begrenzen (etwa 31 Zeichen, bei einigen Modi weniger) und alles Längere stillschweigend überspringen. optimizedKernelAttacks in config.json listet die Angriffe auf, die mit -O laufen; lasse einen Angriff aus der Liste weg, um ihn mit Kerneln voller Länge auszuführen. Die Liste in config.json.example entspricht der integrierten Standardliste, die gilt, wenn keine config.json existiert.

Vier Angriffe berücksichtigen die Einstellung, sind aber standardmäßig nicht optimiert, weil sie Kandidaten einspeisen, die die -O-Obergrenze überschreiten können — füge sie zur Liste hinzu, um sie zu aktivieren:

hcatNgramX, hcatOllama, hcatOmen, hcatLMtoNT

Um -O für einen einzelnen Lauf überall zu deaktivieren, ohne die Konfiguration zu bearbeiten, übergib --no-optimized-kernel (Kurzform --no-optimize). Es überschreibt die Liste für jeden Angriff und entfernt auch ein -O, das in hcatTuning geschrieben wurde, das andernfalls unabhängig von der Liste hashcat erreichen würde.

Namen werden exakt abgeglichen, und ein nicht erkannter Eintrag wird beim Start gemeldet anstatt ignoriert. Beachte, dass Angriffe, die an einen anderen Angriff delegieren, von dem Angriff gesteuert werden, an den sie delegieren, nicht von ihrem eigenen Namen: PRINCE-LING folgt hcatPrince, während Spoonman, Rosetta und die LLM-Muster-Regelmodi hcatQuickDictionary folgen.

Verfolgung der Angriffsabdeckung (`coverage_enabled`)

Über ein langes Engagement hinweg wird dieselbe Hash-Datei in vielen Sitzungen mit einem rotierenden Satz von Wortlisten, Regeldateien und Maskenlisten angegriffen, und es ist leicht, Stunden damit zu verbrennen, bereits abgedecktes Terrain erneut zu bearbeiten — besonders, da dieselbe Regelzeile in mehr als einer Regeldatei vorkommt. hate_crack zeichnet auf, was es bereits gegen jede Hash-Datei ausgeführt hat, und bietet an, die Überschneidung zu überspringen.

Die Abdeckung wird pro Eintrag, nicht pro Datei aufgezeichnet: einzelne Regelzeilen und einzelne .hcmask-Zeilen, jeweils gepaart mit der Wortliste, gegen die sie liefen. Genau das ermöglicht es zu erkennen, dass eine benutzerdefinierte Regeldatei, die du heute ausführst, 40 der Regeln wiederholt, die best64.rule letzte Woche bereits abgedeckt hat, und es ist auch der Grund, warum eine Regel nur für die spezifische Wortliste „abgedeckt" ist, mit der sie ausprobiert wurde — dieselben Regeln über ein anderes Korpus erzeugen völlig andere Kandidaten.

Die Hash-Datei wird durch einen sha256 ihres Inhalts identifiziert, sodass die Abdeckung eine Umbenennung oder Verschiebung zwischen Sitzungen übersteht. Wortlisten werden auf dieselbe Weise identifiziert, wobei der Digest gegen Größe und mtime zwischengespeichert wird, sodass ein mehrere Gigabyte großes Korpus einmal statt bei jedem Angriff gehasht wird.

Du wirst nur dann aufgefordert, wenn es tatsächlich etwas zu überspringen gibt:``` [*] Coverage: 40 of 45 rules in this Dictionary have already been run against this hash file. [?] Skip them and run only the 5 new rules? [Y/n]:

Antworte mit `Y`, und hate_crack erstellt eine temporäre Regeldatei, die nur die noch nicht ausprobierten Einträge enthält; antworte mit `n`, um das Ganze trotzdem auszuführen. Wenn *jeder* Eintrag ein Wiederholung ist, wirst du gefragt, ob der Angriff komplett übersprungen werden soll, sodass ein bewusstes erneutes Ausführen bereits abgedeckter Bereiche nie einen Neustart des Tools erfordert.

Angriffe, die nie gefiltert werden, werden trotzdem als ausgeführt protokolliert – genau das ermöglicht dir die Antwort auf die Frage „Habe ich PRINCE gegen dieses Ziel schon ausgeführt?“.

Ein Angriff, der mehrere Regeldateien gleichzeitig auswählt (Quick Crack, Loopback), stellt die Überspringen-Frage **einmal für den gesamten Stapel, im Voraus**, vor jedem hashcat-Aufruf. Diese Frage ist bewusst günstig gehalten – sie liest oder hasht keine der ausgewählten Regeldateien, da ein YOLO-Stapel Millionen von Zeilen umfassen kann und du nicht darauf warten solltest, um eine Ja/Nein-Frage zu beantworten. Sie fragt den Speicher nur, ob dieser Angriff gegen diese Hash-Datei **mit einer dieser Wortlisten** bereits ausgeführt wurde; der Diff pro Eintrag erfolgt weiterhin verzögert, eine Regeldatei nach der anderen, und entscheidet, was tatsächlich übersprungen wird. Ein frischer Korpus wird also nie markiert, selbst wenn die Regeln darauf alle bereits gegen eine andere Datei ausgeführt wurden.

Drei bewusste Einschränkungen:

- **Die Abdeckung wird nur erfasst, wenn hashcat den Schlüsselraum erschöpft** (Exit 1). Ein Strg-C oder ein Fehler erfasst nichts, ebenso wenig wie Exit 0 – das bedeutet, dass jeder Hash geknackt wurde, was hashcat *ohne* Abschluss des Schlüsselraums meldet, und im degenerierten Fall „alle Hashes als Potfile-Einträge gefunden“, ohne einen einzigen Kandidaten zu versuchen. Eine Untererfassung kostet später nur einen redundanten Lauf.
- **Dynamische Kandidatengeneratoren werden nie gefiltert.** PRINCE, PCFG, OMEN, Markov-Brute-Force und die LLM-Modi haben keine feste Menge zum Diffen, daher werden sie als ausgeführt protokolliert und sonst in Ruhe gelassen. Verkettete Regeldateien (`-r a -r b`) werden als eine Einheit verfolgt und nicht pro Eintrag, da hashcat das *kartesische Produkt* der beiden Dateien anwendet und das Entfernen einer einzelnen Zeile stillschweigend jede Kombination entfernen würde, an der sie beteiligt war.
- **`--loopback`-Läufe werden erfasst, aber nie gefiltert.** hashcat speist frisch geknackte Klartexte als *zusätzliche* Kandidaten zurück, sodass ein solcher Lauf die vollständige Wortliste und den Regelsatz plus alles versucht, was diese recycelten Klartexte erreichen. Das macht die beiden Richtungen asymmetrisch: Das Erfassen ist solide, sodass ein späterer gewöhnlicher Lauf derselben Wortliste und Regeln korrekt als Wiederholung erkannt wird, aber ein zweiter Loopback-Lauf hat mehr zu recycelnde Cracks und wird nie übersprungen.

Setze `coverage_enabled` in `config.json` auf `false`, um dies zu deaktivieren, oder übergib `--no-coverage` für einen einzelnen Lauf – der weder den Speicher abfragt noch aktualisiert.

#### Abdeckung prüfen und zurücksetzen

Hauptmenü-Option **85 – Attack Coverage** zeigt, was gegen die geladene Hash-Datei ausgeführt wurde, deren Laufhistorie, und kann sie löschen. Dieselben drei Aktionen sind skriptbar:```bash
# What has already been run against this hash file?
hate_crack coverage status --hashfile hashes.txt

# Every attack that has run against it, oldest first
hate_crack coverage history --hashfile hashes.txt

# Start over for this hash file only (prompts unless --yes)
hate_crack coverage forget --hashfile hashes.txt --yes

Die Hash-Datei wird über ihren Inhalt identifiziert, sodass diese unabhängig davon funktionieren, wohin sie seitdem verschoben wurde. forget betrifft nur dieses eine Ziel – der Speicher liegt in ~/.hate_crack/coverage/attack_coverage.sqlite3, und das Löschen der Datei setzt die Abdeckung für jedes Ziel zurück.

Skriptgesteuerte Ausführungen

Ein skriptgesteuerter Angriff, der von der Abdeckung vollständig übersprungen wird, beendet sich standardmäßig weiterhin mit 0, sodass das Aktivieren der Abdeckung eine bestehende Testumgebung nicht zum Scheitern bringen kann. Übergeben Sie --exit-code-on-skip, um stattdessen den Exit-Code 3 zu erhalten, wenn nichts gestartet wurde:```bash hate_crack --exit-code-on-skip hashes.txt dict

0 = ran, 1 = bad input, 2 = unknown command, 3 = everything was already covered

Exit 3 bedeutet, dass *nichts* ausgeführt wurde. Ein Durchlauf, der teilweise gefiltert wurde – einige Einträge übersprungen, einige versucht – endet weiterhin mit `0`, weil der Angriff tatsächlich Arbeit geleistet hat.

### Benachrichtigungen (Menüoption 82)

hate_crack kann Pushover-Push-Benachrichtigungen senden, wenn Angriffe abgeschlossen sind, und optional, wenn einzelne Hashes geknackt wurden. Alle Steuerungen befinden sich unter Hauptmenü-Option `82 — Benachrichtigungen`:

1. **Pushover-Benachrichtigungen umschalten [EIN/AUS]** — Hauptschalter. Wird in `config.json` als `notify_enabled` gespeichert.
2. **Per-Crack-Benachrichtigungen umschalten [EIN/AUS]** — wenn EIN, überwacht ein Hintergrund-Tailer die `.out`-Datei und sendet eine Benachrichtigung pro geknacktem Hash (mit Burst-Aggregation pro Tick). Wird in `config.json` als `notify_per_crack_enabled` gespeichert. Kann nicht aktiviert werden, während der Hauptschalter AUS ist – aktivieren Sie zuerst Option 1.
3. **Test-Pushover-Benachrichtigung senden** — sendet eine vorgefertigte Push-Nachricht, damit Sie bestätigen können, dass Ihr Pushover-Token/Benutzer-Paar funktioniert. Funktioniert auch, wenn der Hauptschalter AUS ist.

Anmeldedaten befinden sich in `.env`; die übrigen Einstellungsmöglichkeiten sind nur über die Konfigurationsdatei `config.json` verfügbar:

- `NOTIFY_PUSHOVER_TOKEN`, `NOTIFY_PUSHOVER_USER` (in `.env`) — erforderlich, damit überhaupt eine Push-Nachricht gesendet wird. Nichts im Menü schreibt diese Werte; bearbeiten Sie `.env` selbst.
- `notify_attack_allowlist` — Angriffsnamen, die automatisch zustimmen, ohne die `[y/N/always]`-Abfrage. Wird automatisch befüllt, wenn Sie `always` antworten.
- `notify_suppress_in_orchestrators` (Standard `true`) — unterdrückt die einzelnen Angriffe, die von Extensive Crack verkettet werden, das stattdessen eine einzige Zusammenfassung sendet. Setzen Sie dies auf `false`, um eine Benachrichtigung pro verkettetem Angriff zu erhalten. Andere Menüeinträge, die mehrere Durchläufe ausführen (z. B. Quick Crack mit mehreren Regelketten), sind keine Orchestratoren und benachrichtigen immer pro Durchlauf.
- `notify_max_cracks_per_burst` (Standard `5`), `notify_poll_interval_seconds` (Standard `5.0`) — Abstimmung des Per-Crack-Tailers. Siehe `hate_crack/notify/tailer.py` für die Burst-Aggregationslogik.

### Wortlisten-Tools (Menüoption 80)

Das Untermenü Wortlisten-Tools bietet Vorverarbeitungsprogramme für Wortlisten, die auf hashcat-utils-Binärdateien basieren, sowie Wortlisten-Downloads von Hashmob.net und Weakpass. Zugriff über Option **80** im Hauptmenü.

| Option | Binärdatei | Funktion |
|--------|------------|----------|
| 1 | `len.bin` | Nach Länge filtern – nur Wörter zwischen einer Mindest- und Höchstlänge behalten |
| 2 | `req-include.bin` | Zeichenklassen erfordern – nur Wörter behalten, die alle erforderlichen Zeichentypen enthalten |
| 3 | `req-exclude.bin` | Zeichenklassen ausschließen – Wörter entfernen, die einen ausgeschlossenen Zeichentyp enthalten |
| 4 | `cutb.bin` | Teilstring extrahieren – einen Bytebereich aus jedem Wort ausschneiden |
| 5 | `splitlen.bin` | Nach Länge aufteilen – separate Dateien pro Wortlänge erstellen (Dateien mit Namen `01`–`64` in einem Ausgabeverzeichnis) |
| 6 | `rli.bin` / `rli2.bin` | Wörter subtrahieren – Einträge entfernen, die in einer oder mehreren anderen Dateien vorkommen |
| 7 | `gate.bin` | Sharding – jedes N-te Wort extrahieren für verteiltes Cracken über mehrere Maschinen |
| 8 | - | Wortlisten optimieren – deduplizieren und in Dateien pro Länge unter dem Verzeichnis für optimierte Wortlisten aufteilen |
| 9 | - | Wortlisten von Hashmob.net herunterladen |
| 10 | - | Wortlisten von Weakpass herunterladen (über BitTorrent) |

**Zeichenklassen-Maskenbits** (verwendet von Optionen 2 und 3): `1`=Kleinbuchstaben, `2`=Großbuchstaben, `4`=Ziffer, `8`=Symbol, `16`=Sonstiges. Werte addieren: `7` = Kleinbuchstaben+Großbuchstaben+Ziffer.

**So soll Sharding verwendet werden**: Sharding teilt eine Wortliste in N gleiche, nicht überlappende Teile auf, damit die Arbeit auf mehrere Maschinen oder GPUs verteilt werden kann. Jeder Teil ist *verschachtelt* (jede N-te Zeile), sodass jeder Shard eine repräsentative Stichprobe der gesamten Liste ist und nicht ein zusammenhängender Vorder-/Hinterteil – kein einzelner Knoten bleibt beim Cracken nur des unwahrscheinlichen Endes der Liste hängen.

Führen Sie Option 7 einmal aus, geben Sie eine Eingabe-Wortliste, einen Ausgabe-Basispfad und eine Shard-Anzahl (N) an. Sie schreibt alle N Teile in einem einzigen Durchlauf, benannt mit nullaufgefüllten Teilnummern (`base.001`, `base.002`, … bis `base.00N`). Kopieren Sie einen Teil auf jeden Knoten und richten Sie den hashcat-Lauf dieses Knotens darauf aus. Auf einem System mit einer einzelnen GPU bringt Sharding keine Beschleunigung, aber ein einzelner Teil ist dennoch eine schnelle, repräsentative Stichprobe für einen schnellen Triage-Durchlauf, bevor Sie sich der vollständigen Liste widmen.

#### Automatische Update-Prüfungen

hate_crack kann beim Start automatisch auf GitHub nach neueren Releases suchen. Diese Funktion wird über die Konfigurationsoption `check_for_updates` gesteuert:```json
{
  "check_for_updates": true
}

check_for_updates — Automatische Versionsprüfung beim Start aktivieren (Standard: true).
Wenn aktiviert, ruft hate_crack die neuesten Release-Informationen von GitHub ab und zeigt einen Hinweis an, falls ein Update verfügbar ist.
Die Prüfung läuft asynchron und blockiert den Start nicht. Netzwerkfehler werden stillschweigend ignoriert.

Update-Kanäle

Kanal	Flag	Quelle	Was du bekommst
Release	`--update`	`main`	Das neueste veröffentlichte Release. Dies ist die Standardeinstellung und das, was die Startprüfung anbietet.
Nightly	`--nightly`	`nightly-dev`	Arbeit, die CI bestanden hat, aber noch nicht veröffentlicht wurde.

Versionen folgen dem üblichen Semver, wobei die Erhöhung davon abgeleitet wird, was tatsächlich im Batch enthalten ist. Die zweite Komponente ändert sich nur für Features: Ein Zyklus mit einem feat-Commit geht auf X.(Y+1).0 zu, und ein Zyklus mit ausschließlich Fixes, Docs und Chores geht auf X.Y.(Z+1) zu.

nightly-dev taggt Release-Kandidaten für die Version, auf die der Batch zusteuert — v2.20.1rc1, v2.20.1rc2, … — und das Zusammenführen in main befördert dasselbe Ziel zu seinem finalen Release. Kandidaten sind echte PEP-440-Pre-Releases, sodass sie an beiden Enden korrekt sortiert werden:

2.20.0  <  2.20.1rc1  <  2.20.1rc2  <  2.20.1  <  2.21.0rc1  <  2.21.0

Das Ziel kann sich mitten im Zyklus ändern: Das erste eintreffende feat verschiebt es von X.Y.(Z+1) auf X.(Y+1).0, und die Kandidatennummerierung startet für das neue Ziel neu. Die Nummer benennt immer das, was der Batch heute ausliefern würde.

Die Hauptkomponente wird nie automatisch erhöht — ein !-Betreff oder eine BREAKING CHANGE:-Fußzeile zählt als Feature, denn ein automatisches Major-Update ist nur einen falsch getippten Betreff von einer unumkehrbaren veröffentlichten Version entfernt. Ein Major-Update ist eine bewusste menschliche Handlung: Tagge und pushe es manuell.

Die Richtlinie liegt in tools/next_version.py, geteilt von beiden Tagging-Workflows und unit-getestet in tests/test_next_version.py.

Die Startprüfung bietet nur Releases an, da Nightly-Builds überhaupt kein GitHub-Release veröffentlichen und die Prüfung den „Latest Release"-Endpunkt von GitHub liest — die Aktivierung von check_for_updates wird dich also nie auf ein Nightly ziehen. Zwei Dinge halten die Kanäle jetzt getrennt: das und die Tatsache, dass ein Kandidat ein echtes PEP-440-Pre-Release ist, sodass ein Tool, das rohe Versionsnummern sortiert, es ebenfalls als älter behandelt als das Release, zu dem es wird.

Beide Flags wechseln deinen Checkout zuerst auf den entsprechenden Branch (und verweigern dies, wenn du nicht committete Änderungen hast). Wenn du ein Nightly ausführst und zu veröffentlichtem Code zurückkehren möchtest, bringt dich --update zurück zu main.

Automatisches Zusammenführen gefundener Hashes (nur Download links)

Beim Herunterladen von linken Hashes (ungeknackte Hashes) führt hate_crack automatisch Folgendes aus:

Versucht, gefundene (geknackte) Hashes von Hashview als Hilfsoperation herunterzuladen
Führt gefundene Hashes mit lokalen .out-Dateien zusammen (z. B. left_1_123.txt.out oder left_1_123.nt.txt.out für das Pwdump-Format)
Entfernt doppelte Einträge
Bereinigt temporäre Split-Dateien nach dem Zusammenführen

Dadurch bleiben deine lokalen Knackergebnisse bei der Arbeit mit ungeknackten Hashes mit der zentralen Datenbank von Hashview synchronisiert.

Hinweis: Die Option „Download found" lädt bereits geknackte Hashes separat zu Referenzzwecken herunter und führt kein Zusammenführen durch und fragt nicht nach dem Knacken.

Der <hash_type> wird durch Ausführen von hashcat --help ermittelt.

Bitte fügen Sie den zu übersetzenden Markdown-Inhalt ein.```
$ ./hate_crack.py <hash file> 1000

  ___ ___         __             _________                       __
 /   |   \_____ _/  |_  ____     \_   ___ \____________    ____ |  | __
/    ~    \__  \\   __\/ __ \    /    \  \/\_  __ \__  \ _/ ___\|  |/ /
\    Y    // __ \|  | \  ___/    \     \____|  | \// __ \\  \___|    <
 \___|_  /(____  /__|  \___  >____\______  /|__|  (____  /\___  >__|_ \
       \/      \/          \/_____/      \/            \/     \/     \/
                          Version 2.0

Testen

Die Testsuite läuft größtenteils offline und verwendet Mocks/Fixtures. Live-Netzwerkprüfungen und Systemabhängigkeitsprüfungen sind optional über Umgebungsvariablen aktivierbar.

Tests lokal ausführen```bash

Run all tests

uv run pytest -v

Run specific test

uv run pytest tests/test_hashview.py -v

Sie können die vollständige Suite auch mit `make test` ausführen.

### Live-Tests (Opt-In)

Setzen Sie eine der folgenden Optionen, um Live-Checks zu aktivieren:

- `HASHMOB_TEST_REAL=1` — Live-Hashmob-Konnektivitäts-/CLI-Menüprüfung
- `HASHVIEW_TEST_REAL=1` — Live-Hashview-CLI-Menüprüfung
- `WEAKPASS_TEST_REAL=1` — Live-Weakpass-CLI-Menüprüfung
- `HATE_CRACK_REQUIRE_DEPS=1` — Fehlschlag, wenn `7z`, `transmission-daemon` oder `transmission-remote` fehlt

### Live-Hashview-Upload-Test

Der Live-Hashview-Upload-Test wird standardmäßig übersprungen. Um ihn auszuführen, setzen Sie die
Umgebungsvariable und geben Sie gültige Anmeldedaten in `.env` an:```bash
HATE_CRACK_RUN_LIVE_TESTS=1 uv run pytest tests/test_upload_cracked_hashes.py -v

Live-Hashview-Tests gegen einen lokalen Docker-Stack

Anstatt die Live-Tests auf einen entfernten Hashview-Server auszurichten, können Sie die Suite einen lokalen Hashview Docker-Stack hochfahren lassen, ihn seeden, die Live-Tests dagegen ausführen und ihn wieder herunterfahren. Setzen Sie HASHVIEW_TEST_LOCAL=1 und richten Sie HASHVIEW_REPO auf einen Hashview-Checkout aus:```bash HASHVIEW_TEST_LOCAL=1 HASHVIEW_REPO=~/projects/hashview
HATE_CRACK_SKIP_INIT=1 uv run pytest tests/test_hashview_cli_subcommands_subprocess.py -v

Dies bringt `docker compose` im Hashview-Repo hoch, seedet einen Admin-API-Key,
einen Kunden, eine Hashdatei und geknackte „Effective-Task“-Daten und exportiert dann
die `HASHVIEW_*`-Umgebungsvariablen, die die Tests lesen. Nützliche Umgebungsvariablen:

- `HASHVIEW_TEST_LOCAL=1` — aktiviert den lokalen Stack (ansonsten wirkungslos)
- `HASHVIEW_REPO=<Pfad>` — Hashview-Checkout (Standard: `~/projects/hashview`)
- `HASHVIEW_KEEP=1` — lässt Container nach der Sitzung laufen (schnellere Wiederholungsläufe)
- `HASHVIEW_LOCAL_PORT=5000` — Host-Port, auf dem die App veröffentlicht wird

Die hate_crack-CLI beachtet die Umgebungsvariablen `HASHVIEW_URL` / `HASHVIEW_API_KEY`
(die die `.env` überschreiben, in der diese beiden Schlüssel liegen), was es der
Suite ermöglicht, die CLI auf den lokalen Stack zu richten, ohne deine gespeicherte Konfiguration zu bearbeiten.

### End-to-End-Installationstests (Lokal + Docker)

Lokale uv-Tool-Installation + Skriptausführung (verwendet ein temporäres HOME):```bash
HATE_CRACK_RUN_E2E=1 uv run pytest tests/test_e2e_local_install.py -v

Docker-basierte End-to-End-Installation/-Ausführung (zwischengespeichert über Dockerfile.test):```bash HATE_CRACK_RUN_DOCKER_TESTS=1 uv run pytest tests/test_docker_script_install.py -v

Der Docker-E2E-Test lädt außerdem eine kleine Teilmenge von rockyou herunter und führt einen einfachen
Hashcat-Crack aus, um die Integration externer Tools zu validieren.

Lima-VM-End-to-End-Test (nur macOS):

Voraussetzungen: [Lima](https://lima-vm.io/) und `rsync` müssen installiert sein.```bash
brew install lima

The test-VM wird automatisch mit allen Linux-Abhängigkeiten bereitgestellt (hashcat, build-essential, curl, git, gzip, p7zip-full, transmission-daemon, ocl-icd-libopencl1, pocl-opencl-icd, uv).```bash HATE_CRACK_RUN_LIMA_TESTS=1 uv run pytest tests/test_lima_vm_install.py -v

Dieser Test validiert die Installation und Ausführung in einer leichtgewichtigen Linux-VM unter macOS.

### Teststruktur

- **tests/test_hashview.py**: Umfassende Testsuite für die HashviewAPI-Klasse mit simulierten API-Antworten, einschließlich:
  - Kundenauflistung und Datenvalidierung
  - Authentifizierungs- und Autorisierungstests
  - Hashfile-Upload-Funktionalität
  - Vollständiger Workflow zur Auftragserstellung

Alle Tests verwenden simulierte API-Aufrufe, sodass sie ohne Verbindung zu einem Hashview-Server ausgeführt werden können.

-------------------------------------------------------------------

  (1) Schneller Crack
  (2) Umfangreicher Pure_Hate-Methodik-Crack
  (3) Brute-Force-Angriff
  (4) Top-Mask-Angriff
  (5) Fingerprint-Angriff
  (6) Combinator-Angriffe
  (7) Hybrid-Angriff
  (8) Pathwell Top 100 Mask Brute-Force-Crack
  (9) PRINCE-Angriff
  (10) Bandrel-Methodik
  (11) Loopback-Angriff
  (12) LLM-Angriff
  (13) OMEN-Angriff
  (14) Ad-hoc-Mask-Angriff
  (15) Markov-Brute-Force-Angriff
  (16) N-Gramm-Angriff
  (17) Permutations-Angriff
  (18) Zufallsregeln-Angriff
  (19) Combipow-Passphrasen-Angriff
  (20) PCFG-Angriff
  (21) PRINCE-LING-Angriff
  (22) Spoonman-Angriff
  (23) Rosetta-Angriff
  (24) Unternehmens-Masken-Brute-Force
  (25) Smart-Mask-Angriff

  (80) Wortlistentools
  (81) Regeldatentools
  (82) Benachrichtigungen
  (83) Maskentools

  (93) .out aus POT-Datei neu generieren
  (94) Hashview-API
  (95) Hashes mit Pipal analysieren
  (96) Ausgabe in Excel-Format exportieren
  (97) Geknackte Hashes anzeigen
  (98) README anzeigen
  (99) Beenden

Aufgabe auswählen:```

Option `94 — Hashview API` is only listed when `HASHVIEW_API_KEY` is set in `.env`.

The YOLO, Middle, and Thorough Combinator attacks were previously at keys 10-12. They now live in the Combinator Attacks submenu (option 6) along with Combinator3 and CombinatorX.
-------------------------------------------------------------------
#### Quick Crack
Runs a dictionary attack against wordlists in your `hcatOptimizedWordlists` directory (falls back to `hcatWordlists` if not configured) and optionally applies rules. Multiple rules can be selected by comma-separated list, and chains can be created with the '+' symbol. Pressing Enter at the wordlist prompt uses the configured optimized wordlists directory as the default.

Selecting a directory — including that default — expands to the wordlists
directly inside it before hashcat runs. Subdirectories are not searched,
matching hashcat's own behaviour for a directory in the dictionary position, and
dot-files and `.7z`/`.torrent`/`.out` files are skipped, which hashcat would
otherwise try to read. The candidates are the same either way; the expansion is
what lets attack coverage track each wordlist separately, since a directory has
no content fingerprint to key on. If the expansion finds nothing — an empty
directory, or one holding only subdirectories or archives — the attack aborts
rather than launching hashcat with no wordlist, which would put it in stdin
mode and leave it reading the terminal.

Welche Regel(n) möchtest du ausführen? (1) best64.rule (2) d3ad0ne.rule (3) T0XlC.rule (4) dive.rule (99) YOLO...alle Regeln ausführen Gib eine kommagetrennte Liste der Regeln ein, die du ausführen möchtest. Um verkettete Regeln auszuführen, verwende das +-Symbol. Zum Beispiel führt 1+1 best64.rule zweimal verkettet aus, und 1,2 führt best64.rule und dann d3ad0ne.rule nacheinander aus. Wähle weise:```

Extensive Pure_Hate Methodology Crack

Runs several attack methods provided by Martin Bos (formerly known as pure_hate):

Brute Force Attack (7 characters)
Dictionary Attack
- All wordlists in hcatWordlists with best64.rule
- rockyou.txt with d3ad0ne.rule
- rockyou.txt with T0XlC.rule
Top Mask Attack (Target Time = 4 Hours)
Fingerprint Attack
Smart Mask Attack
Combinator Attack
Hybrid Attack
Extra - Just For Good Measure
- Runs a dictionary attack using rockyou.txt with chained combinator.rule and InsidePro-PasswordsPro.rule rules

Brute Force Attack

Brute forces all characters with the choice of a minimum and maximum password length.

Top Mask Attack

Uses StatsGen and MaskGen from PACK (https://thesprawl.org/projects/pack/) to perform a top mask attack using passwords already cracked for the current session. Presents the user a choice of target cracking time to spend (default 4 hours).

Fingerprint Attack

https://hashcat.net/wiki/doku.php?id=fingerprint_attack

Runs a fingerprint attack using passwords already cracked for the current session. Expander substring length escalates automatically (7, 14, 21, ... up to the chosen ceiling), and an optional wordlist can be combined against the expanded fragments in addition to self-combination. Set hcatFingerprintWordlist in config.json to a default wordlist path so the prompt offers it instead of asking for a path every time; leave it as "" to always ask (or skip).

Smart Mask Attack

Looks for literal "skeleton" patterns shared by 3+ already-cracked passwords for the current session -- e.g. a fixed stem like CrawlingHorse followed by a run of digits, or ChangeMe2day followed by digits and symbols drawn from a consistent charset. Every qualifying pattern runs against the full remaining hash list, so other accounts sharing a stem get swept up even though brute-forcing the stem itself was never tried.

Patterns with a fixed run at either end -- nearly all of them -- are grouped by mask and run as hybrid attacks (-a 6 when the mask trails the stem, -a 7 when it leads), with every pattern's literal stem a line in that group's wordlist. Dozens of patterns that vary the same way therefore become one hashcat pass over one wordlist rather than one mask line each. Whatever cannot be grouped that way -- variation at both ends, which leaves no fixed run to seed a wordlist with -- falls back to a single -a 3 mask file, and has its charsets widened (up to ?a) to compensate, as far as the guardrail below allows.

Prompts once, before the attack starts, for an optional per-pattern candidate-count guardrail (default 50,000,000,000; 0 disables it) that excludes any individual pattern whose keyspace is too large without blocking the rest.

Combinator Attack

https://hashcat.net/wiki/doku.php?id=combinator_attack

Runs a combinator attack using the "rockyou.txt" wordlist.

Hybrid Attack

https://hashcat.net/wiki/doku.php?id=hybrid_attack

Runs sixteen hybrid passes per wordlist, cheapest first. Each mask length from 1 to 4 is tried appended and then prepended, first over ?s?d and then over ?a, and a single ctrl-C abandons the whole attack rather than only the current pass.
- Hybrid Wordlist + Mask - ?s?d wordlists/rockyou.txt ?1
- Hybrid Mask + Wordlist - ?s?d ?1 wordlists/rockyou.txt
- ... the same for ?1?1, ?1?1?1 and ?1?1?1?1
- Hybrid Wordlist + Mask - wordlists/rockyou.txt ?a
- Hybrid Mask + Wordlist - ?a wordlists/rockyou.txt
- ... the same for ?a?a, ?a?a?a and ?a?a?a?a
?a is every printable character, so the second group is a superset of the first plus letters and roughly 24x the work at the longest mask — over rockyou.txt those passes alone are ~1.2e15 candidates, about ten hours for NTLM on hardware doing 32 GH/s. That is why the cheap ?s?d group runs first and why the attack as a whole is time-bounded:
- hcatHybridMaxRuntime in config.json, in seconds, default 3600, is the time the whole attack may spend — not the time one pass may spend. All sixteen passes share one deadline, and each is handed whatever is left of it as hashcat's --runtime. Any pass the budget does not reach is reported rather than skipped quietly. Set it to 0 for no limit, which runs every pass to exhaustion.
Within each group the order is by mask length across every wordlist rather than all lengths of one wordlist and then the next, so a budget that runs out has still given every wordlist its cheap passes.

Each pass declares what it covers to the attack-coverage store, so a repeat hybrid against the same hash file offers to skip the passes already run. A pass that runs out of budget is not recorded, so it will be retried. Wordlist entries may be glob patterns or directories; both are expanded before hashcat runs, a directory into the wordlists directly inside it. Subdirectories are not searched, matching hashcat's own behaviour, and dot-files and .7z/.torrent/.out files are skipped — a Weakpass download leaves archives in the wordlists directory and hashcat would otherwise try to read them.

Pathwell Top 100 Mask Brute Force Crack

Runs a brute force attack using the top 100 masks from KoreLogic: https://blog.korelogic.com/blog/2014/04/04/pathwell_topologies

PRINCE Attack

https://hashcat.net/events/p14-trondheim/prince-attack.pdf

Runs a PRINCE attack using wordlists/rockyou.txt

YOLO Combinator Attack

Runs a continuous combinator attack using random wordlists from the configured wordlists directory for the left and right sides.

Middle Combinator Attack

https://jeffh.net/2018/04/26/combinator_methods/

Runs a modified combinator attack adding a middle character mask: wordlists/rockyou.txt + masks + worklists/rockyou.txt

Where the masks are some of the most commonly used separator characters: 2 4 - _ , + . &

Thorough Combinator Attack

https://jeffh.net/2018/04/26/combinator_methods/

Runs many rounds of different combinator attacks with the rockyou list.
- Standard Combinator attack: rockyou.txt + rockyou.txt
- Middle Combinator attack: rockyou.txt + ?n + rockyou.txt
- Middle Combinator attack: rockyou.txt + ?s + rockyou.txt
- End Combinator attack: rockyou.txt + rockyou.txt + ?n
- End Combinator attack: rockyou.txt + rockyou.txt + ?s
- Hybrid middle/end attack: rockyou.txt + ?n + rockyou.txt + ?n
- Hybrid middle/end attack: rockyou.txt + ?s + rockyou.txt + ?s

Bandrel Methodology

Prompts for comma-separated names and creates a pseudo hybrid attack by capitalizing the first letter and adding up to six additional characters at the end. Each word is limited to a total of five minutes.

Built-in common words (seasons, months) included as a customizable config.json entry (bandrel_common_basedwords)
The default five-minute time limit is customizable via bandrelmaxruntime in config.json

Loopback Attack

https://hashcat.net/wiki/doku.php?id=loopback_attack

Uses hashcat's loopback mode to feed cracked passwords from the current session back into the attack pipeline with rules applied. This generates new password candidates based on variations of already-cracked passwords, which is particularly effective for finding related passwords that follow similar patterns.

Prompts for rule selection to apply to the loopback candidates
Uses an empty wordlist with the --loopback flag to process previously cracked passwords
Automatically downloads Hashmob rules if no rules are available locally

LLM Attack

Uses a local LLM — Ollama by default, or a vLLM / OpenAI-compatible server via LLM_BACKEND — to generate password candidates for a capture-the-flag scenario. Prompts for the fake company name, industry, location, and parent company / acquisition history, then sends these details to the configured LLM model to produce likely password candidates using industry terms and company name permutations. The generated candidates are fed into a hashcat wordlist+rules attack.

Requires a running server at OLLAMA_HOST (default: http://localhost:11434, Ollama's port; override in .env or the environment) already serving the model — hate_crack does not auto-pull
Candidate generation uses structured (JSON) output via Atomic Agents, so pick a model with good schema adherence (default: qwen3:4b-instruct)
Configurable backend, model, context window, request timeout, and sample size via .env (see LLM Configuration)
Prompts for target company name, industry, location, and parent company / acquisition history. The industry, location, and parent company prompts are pre-filled with the local model's guesses about the named organization (editable, and clearly labelled as guesses rather than verified OSINT); disable with ollamaAutoResearch: false
Alternatively derives basewords from a sample wordlist, or from the cracked passwords of the current session (<hashfile>.out) so the model mirrors the target organization's own password conventions and produces new candidates in that style (only offered once something has been cracked)
A live spinner with an elapsed-seconds counter runs during generation, and requests are bounded by ollamaTimeout so a model stuck loading into VRAM reports a timeout instead of hanging

Pattern rules mode (option 4 in the LLM submenu) takes the same shape as the Spoonman Attack — a baseword list run through a rule file, both derived from one corpus — but infers each side with the model instead of extracting it. Spoonman is exact and therefore bounded: its basewords all appear in the corpus and its rules only reproduce transformations the corpus already shows. This asks the model to generalize on both axes, so it can name the word families behind a sample (the company and its products, site names, local sports teams, seasons, mascots) and write decorations the corpus does not contain.

Pattern source is either the current session's cracked passwords (offered first, and only once something has been cracked, since those reveal the target's real conventions) or a sample wordlist
You are not asked to pick a rule file. The model writes one, from the same corpus statistics — a stock rule file encodes the internet's habits, and the point of spending a model round trip is to encode this organization's
Basewords are normalized to lowercase letters only, discarding anything under 3 characters, so the generated rules supply case, digits, and punctuation exactly once
Generated rules are validated before hashcat sees them, and anything using an op hashcat does not have, a position argument outside 0-9A-Z, more than 31 functions, or a stray comment or non-ASCII character is discarded. hashcat drops an invalid rule silently when valid rules share the file, so an unscreened line would become missing coverage rather than an error. The op table was established by testing hashcat itself, not from its rule documentation, which lists ops hashcat will not actually run
Local-model yield varies a lot run to run, so a thin answer is asked again once and the two rounds are merged — a handful of rules would waste the pass they are spent on
If no rule survives validation the basewords still run, unmutated, rather than throwing away the expensive half of the run
Output lands in <hashfile>.llm_patterns/ as basewords.txt and rules.rule — per-run scratch, laid out like .spoonman/ and removed on exit

OMEN Attack

Uses the Ordered Markov ENumerator (OMEN) to train a statistical password model from a wordlist and generate password candidates. This attack learns patterns from known passwords and generates new candidates based on those patterns.

Requires OMEN binaries (createNG and enumNG) to be built from the omen submodule
Interactive menu: use existing model, train new model, or cancel
Training wordlist picker shows available wordlists from configured directory or accepts a custom path
Validates all 5 required model files (createConfig, CP/IP/EP/LN.level) before running
Captures and reports enumNG errors instead of failing silently
Generates up to a specified number of password candidates (configurable via omenMaxCandidates)
Pipes generated candidates directly into hashcat for cracking
Model files and metadata are stored in ~/.hate_crack/omen/ for persistence across sessions

Combinator Attacks Submenu

Opens an interactive submenu with six combinator attack variants (formerly at menu keys 10-12). Consolidates related attacks for cleaner menu organization:

Combinator Attack - combines two wordlists
YOLO Combinator Attack - combines all permutations of multiple wordlists
Middle Combinator Attack - combines wordlists with an extra word in the middle
Thorough Combinator Attack - comprehensive combination of wordlists with rules
Combinator3 Attack - combines exactly 3 wordlists using combinator3.bin, generating all word1+word2+word3 combinations piped to hashcat
CombinatorX Attack - combines 2-8 wordlists using combinatorX.bin with optional --sepFill separator character between word segments

Ad-hoc Mask Attack

Runs hashcat mask attack (mode 3) with a user-specified custom mask string. Allows fine-grained control over character-set brute forcing.

Opens with a choice between typing a mask and selecting a mask file
Prompts for a hashcat mask (e.g., ?u?l?l?l?d?d for uppercase + lowercase + lowercase + lowercase + digit + digit)
Supports custom character sets for specialized character combinations: -1 through -4 on any hashcat, plus -5 through -8 on hashcat 7 and newer. A mask using ?5–?8 against an older hashcat is flagged before the run rather than failing inside it; if the version cannot be read, the mask is passed through and hashcat decides
Only prompts for the custom slots the mask actually references — ?1?3?d asks about -1 and -3 and nothing else, and a mask with no custom tokens is never asked at all. Detection is token-aware, so the escaped ??1 is a literal ?1 and prompts for nothing. A slot left blank is still skipped, with a warning that hashcat will reject a mask whose charset is undefined
Mask files (.hcmask) can be selected with tab completion, defaulting to the bundled masks/ directory; hashcat runs every mask in the file in order. Because a mask file defines its own charsets inline, the -1 through -4 prompts are skipped when one is chosen
Optionally runs the mask incrementally (--increment), trying shorter lengths before the full mask. Answering yes prompts for an increment minimum and maximum; either can be left blank, and leaving both blank increments over the mask's full keyspace with hashcat choosing the bounds. Offered for typed masks and mask files alike
Useful for targeted brute forcing when you know password structure patterns

Markov Brute Force Attack

Generates password candidates using Markov chain statistical models. Similar to OMEN but simpler and faster.

Checks for existing .hcstat2 Markov table from previous sessions (with option to reuse, regenerate, or cancel)
Generates table from training source if needed:
- Can use cracked passwords from current session (.out file) as training data
- Or select any wordlist from configured directory or custom path
Interactive menu: choose minimum and maximum password length
Uses --increment flag to test lengths in sequence
Markov table persists with hash file (filename.out.hcstat2) for fast subsequent runs
Faster than OMEN for general-purpose brute forcing

N-gram Attack

Generates n-gram candidates from a corpus file using ngramX.bin from hashcat-utils and pipes them into hashcat.

Prompts for a corpus file with tab completion, defaulting to the configured wordlist directory
Prompts for an n-gram group size (default 3)
Gzip-compressed corpus files are auto-detected and decompressed on the fly
Useful when you have target-relevant prose (scraped site copy, leaked documents, internal wiki exports) rather than a password list

Permutation Attack

Generates all character permutations of each word in a targeted wordlist and pipes them to hashcat via permute.bin from hashcat-utils.

Prompts for a single wordlist file (not a directory)
Effective against short targeted wordlists where the character set is known but the order is not (company abbreviations, name fragments, known tokens)
WARNING: Scales as N! per word - an 8-character word produces 40,320 permutations. Only practical for words up to ~8 characters.
Uses permute.bin < wordlist | hashcat pipeline pattern

Random Rules Attack

Generates a set of random hashcat mutation rules using generate-rules.bin, writes them to a temporary file, then runs hashcat against a chosen wordlist with those rules.

Prompts for rule count (default 65536)
Prompts for wordlist path with tab-completion and numbered selection
Temporary rules file is cleaned up after the run regardless of outcome
Useful when known rule sets are exhausted - explores random rule-space for additional cracks

Combipow Passphrase Attack

Generates all unique non-empty subset combinations from a short wordlist using combipow.bin and pipes them into hashcat. Designed for passphrase cracking when you know the pool of words a password was built from.

Prompts for a wordlist file (max 63 lines - combipow generates up to 2^n-1 combinations)
Optional space separator (-s flag) to insert spaces between words in each combination
Warns if the wordlist exceeds 20 lines (output volume may be large)
Aborts with a clear message if the wordlist exceeds 63 lines (hard limit)
Candidates are piped directly to hashcat stdin

PCFG Attack

Uses pcfg_cracker to generate candidates from a Probabilistic Context-Free Grammar, piping pcfg_guesser.py output directly into hashcat's stdin mode. A PCFG models password structure (baseword + digits + symbol, capitalization habits, keyboard walks) with learned probabilities, so candidates come out roughly in descending likelihood order.

Requires the pcfg_cracker submodule. Presence is checked at startup and reported non-fatally: if it is missing, the PCFG attacks are simply unavailable. Run make to fetch it.
Uses the trained grammar named by pcfgRuleset in config.json (default DEFAULT), read from pcfg_cracker/Rules/<name>/
Candidate count is capped by pcfgMaxCandidates (default 50,000,000)
hate_crack does not wrap grammar training. To build a grammar from a target-specific password set, run pcfg_cracker's own trainer.py and point pcfgRuleset at the resulting ruleset name

PRINCE-LING Attack

Uses pcfg_cracker's prince_ling.py to derive an optimized PRINCE base wordlist from a trained grammar, then hands it to the existing PRINCE attack. PRINCE-LING picks base words the grammar says are actually productive, so the PRINCE combination space is far less wasteful than pointing PRINCE at a generic wordlist.

Requires the pcfg_cracker submodule and a trained ruleset directory, same as the PCFG attack
The generated wordlist is cached at <hcatOptimizedWordlists>/pcfg_prince_ling_<ruleset>.txt and reused across sessions
Regenerates only when the ruleset directory is newer than the cached wordlist, so retraining a grammar invalidates the cache automatically
Generation is written to a temporary file and atomically moved into place; a failed or interrupted run cleans up its partial file and leaves any existing cache intact
Base wordlist size is capped by pcfgPrinceLingMaxCandidates (default 10,000,000)

Spoonman Attack

Derives a baseword list and a hashcat rule file from a corpus of known plaintext passwords — a previous engagement's cracked output, a leak dump, or any password list — such that the baseword x rule cross product reconstructs the corpus exactly (see the memory bound below for the one case where it does not). Contributed as issue #169 by @Spoonman1091.

Each password is split into its letters-only lowercased core (the baseword) plus a rule that rebuilds the original from it, using l/u/c for casing, T{p} toggles, ${x}/^{x} for trailing and leading characters, and i{p}{x} for interior ones.

When the current session already has cracked plaintexts (<hash file>.out exists and is non-empty), a picker offers those as the corpus ahead of a free-form path — the target's own recovered passwords derive rules describing that target's actual conventions, which is exactly what you want to fire back at the remaining uncracked hashes. Deriving from .out and then cracking the same hash file appends new plaintexts to that same file, growing the corpus for the next run; that is the intended feedback loop, not corruption. Sessions with no cracked output yet see no picker at all — just today's path prompt
Prompts for the corpus, then for how much of the rule file to run: top 50% coverage (listed first and recommended), top 75%, top 95%, top 99%, or the full set
Rules are sorted by how many passwords each one rebuilds, so a truncated file keeps the most productive rules. Coverage is extremely long-tailed: on a 98.2M-password sample, 50% coverage needed 4,120 rules while 95% needed 16,119,661 and 100% needed 21,029,696 — the last few percent typically costs orders of magnitude more rules than the first half, which is why the smallest tier is listed first and is usually the right choice
Output is written beside the hash file in <hash file>.spoonman/, alongside the other ephemeral wordlists: basewords.txt, rules.full.rule, the capped rule files, and coverage.txt with per-milestone rule counts. Derivation is skipped on later runs of the same hash file unless the corpus has been modified since, and the directory is removed on exit by the temp-file cleanup
Derivation is bounded in memory. Both counters would otherwise grow for the whole read with nothing written until the end, so a corpus large enough to exhaust RAM lost the entire pass to an OOM kill and produced no output; a measured run against a 31 GB corpus reached 14.1 GB resident at 11% of the file and was still accelerating. Each counter is now capped at 20 million distinct keys (about 1.6 GB apiece), and the lowest-frequency keys are discarded once it is exceeded. If that happens, the run says so on the console and in coverage.txt, the output reconstructs the retained keys rather than 100% of the corpus, and the coverage percentages are relative to those. Corpora below the cap are unaffected
Passwords that cannot be expressed as a rule are written verbatim as their own baseword with a : no-op, so coverage stays complete. This covers two hashcat limits: rule positions cannot address past index 35, and hashcat rejects any rule with more than 31 functions — silently, when valid rules share the file
A password carrying a literal CR or LF (which arrives hex-wrapped, as $HEX[...0a]) cannot go in a baseword at all, because a wordlist line has no escape syntax for one. The break is lifted out into an insert op instead, spelled \x0a/\x0d in the rule, which hashcat decodes to the byte. When the break sits past addressable index 35 the rule reverses the word first, inserts from the other end, and reverses back. One frame has to hold every break in the password, so what is still skipped is a password with one break outside the first 36 characters and another outside the last 36, or one needing more inserts than the 31-function cap leaves room for. Those are counted as unwritable basewords in coverage.txt and reported, never dropped silently
The derivation self-checks every password by reconstructing it in-process, and reports any failures rather than reporting success
Corpus lines may carry a hash in front of the password, as cracked output does. A leading field is dropped only when it has the shape of a hash (a hex digest at a known length, or a crypt-style $id$ string), so hash:salt:plain is handled while a plaintext or wordlist entry containing a colon survives intact. $HEX[...] plaintexts are decoded. If most lines look like an uncracked dump rather than cracked output, coverage.txt records the count and the attack warns — the derived basewords and rules would otherwise be meaningless without any error being raised

Rosetta Attack

Mines hashcat --debug-mode 5 logs for the basewords and rules that already cracked something, then runs their full cross product. Powered by HashcatRosetta, the same library behind Analyze Hashcat Rules.

No setup is needed to feed it: _add_debug_mode_for_rules appends --debug-mode 5 --debug-file to every rule-based hashcat invocation hate_crack makes, so the logs accumulate in hcatDebugLogPath (~/.hate_crack/hashcat_debug by default, one file per session) as a side effect of normal use. A mode 5 log records only candidates that cracked a hash, in the form baseword:rule:candidate:wordlist, which is what makes both halves known-productive against this target population; the trailing wordlist field also shows which list is earning its keep on a multi-wordlist run. HashcatRosetta parses mode 4 and mode 5 alike, so logs written before the switch are still read.

The value is in the cross product rather than the recorded pairs. A pair present in a log has already cracked its hash and will not crack another, but a rule that worked on one baseword has usually never been tried against the others — so N basewords and M rules yield close to N x M untried candidates.

The menu first asks how to rank rules — choices 1-3 below, plus a fourth, unrelated mode:

Rules can be ranked by application frequency, by how many distinct basewords each one worked on, or by how many unique candidates each one generated. Frequency is the default; baseword spread is the better choice when the goal is a rule set that generalizes past the specific words it was learned from
Only after one of those three is picked does hate_crack list the logs found in hcatDebugLogPath newest-first with their sizes; pick one, pick all of them (up to 20), or type a path to a log from elsewhere
Prompts for how many top rules to keep and how many top basewords. Both default to all — a blank answer keeps every winning rule the logs contain, and zero means the same thing. Enter a number to cap either. The keyspace is the product of the two and is printed before hashcat starts
Output is written beside the hash file in <hash file>.rosetta/ as basewords.txt and rules.rule, alongside the other ephemeral wordlists, and the directory is removed on exit by the temp-file cleanup
Reading stops at 1,000,000 debug lines, since the analyzer needs the whole batch in memory at once. Truncation is reported on the console rather than assumed harmless — logs from a long run routinely exceed this, in which case the newest log is the one worth selecting
LLM Mask Attack (4) - a different mode entirely, and the only one that needs no debug logs. Prompts for a natural-language description of the passwords you expect (length, character patterns, symbols, etc.), sends it to the locally configured Ollama model, writes the returned masks to <hash file>.hcmask, and runs a -a 3 hashcat mask attack against them

Corporate Masks Brute Force

Statistical masks (8-14 characters) derived from analysis of 3.2M NTLM hashes cracked on real engagements. Powered by Corporate_Masks, these masks encode realistic password patterns from successful penetration tests.

Prompts for minimum and maximum mask length (default 8-10)
Longer lengths cost exponentially more keyspace—start with 8-10 for speed, or 8-12 for thoroughness
Each mask file is run as a separate hashcat invocation in ascending length order
Gracefully handles missing mask files (skips them) and absent submodule (prints warning and returns)
Supports optimized kernels (-O flag) for faster cracking
Ctrl-C during one length aborts remaining lengths

Wordlist Tools (option 80)

A submenu of wordlist preprocessing utilities using hashcat-utils binaries. All tools read from and write to files on disk. All file and directory path prompts support tab completion.

Key	Tool	Description
1	Filter by Length	Keep only words between a min and max length (`len.bin`)
2	Require Char Classes	Keep words that include all char classes in mask (`req-include.bin`). Mask: 1=lower, 2=upper, 4=digit, 8=symbol (additive)
3	Exclude Char Classes	Remove words containing any char class in mask (`req-exclude.bin`). Same mask encoding
4	Extract Substring	Cut bytes from each word at a given offset and optional length (`cutb.bin`)
5	Split by Length	Create per-length files in an output directory (`splitlen.bin`)
6	Subtract Wordlist	Remove lines from a wordlist that appear in one or more remove files. Mode 1 uses `rli2.bin` (single file); mode 2 uses `rli.bin` (multiple files)
7	Shard Wordlist	Split a wordlist into N equal, interleaved parts in one run, written as `base.001`…`base.00N` for distributed cracking (`gate.bin`)
8	Optimize Wordlists	Dedupe and split the selected wordlists into per-length files under an output directory
9	Download from Hashmob.net	Browse and download wordlists from Hashmob.net into the configured wordlist directory
10	Download from Weakpass	Browse and download Weakpass wordlist torrents, with automatic extraction
11	Hashmob Downloads	Access a submenu for downloading Hashmob archives (yearly full-found corpora) and combined-left lists (per-mode uncracked hashes)

All binaries are in hate_crack/hashcat-utils/bin/.

Rule File Tools (option 81)

Preprocesses hashcat rule files using cleanup-rules.bin and rules_optimize.bin from hashcat-utils, and downloads rule files from Hashmob.net.

Clean (1) - removes invalid syntax and duplicate rules using cleanup-rules.bin. Useful after combining rule files or downloading rules from external sources.
Optimize (2) - consolidates redundant operations using rules_optimize.bin. Reduces rule file size and improves cracking speed.
Clean and optimize (3) - runs both operations in sequence via a temporary file, then writes the final result.
Download rules from Hashmob.net (4) - fetches rule files into the configured rulesDirectory.
Analyze Hashcat rules (5) - opcode frequency analysis of a rule file, powered by HashcatRosetta.

The three preprocessing operations read from an input file and write to a separate output file (original is never modified).

Download Rules from Hashmob.net (Rule File Tools option 4)

Downloads the latest rule files from Hashmob.net's rule repository. These rules are curated and optimized for password cracking and can be used with the Quick Crack and Loopback Attack modes.

Downloads rule sets in parallel using a thread pool (up to 4 concurrent downloads)
Skips rules already downloaded locally
Reports download summary with success/failure counts
Stores rules in the configured rules directory

Analyze Hashcat Rules (Rule File Tools option 5)

Powered by HashcatRosetta (https://github.com/bandrel/HashcatRosetta), this feature analyzes hashcat rule files to provide detailed insights into rule composition and complexity.

Prompts for a rule file path
Displays frequency analysis of rule opcodes (operations)
Helps understand what transformations a rule set performs
Useful for rule debugging and optimization

Mask Tools (option 83)

Downloads mask files from Hashmob.net. This is a minimal submenu today — masks have no local file-tooling counterpart to the rule/wordlist cleanup and optimization utilities, only a download capability.

Download masks from Hashmob.net (1) - fetches mask files into the hate_crack masks directory.

Download Masks from Hashmob.net (Mask Tools option 1)

Downloads mask files from Hashmob.net's mask repository into the hate_crack masks directory for use with mask-based attacks.

Downloads mask sets in parallel using a thread pool (up to 4 concurrent downloads)
Skips masks already downloaded locally
Reports download summary with success/failure counts
Stores masks in the configured masks directory used by the Ad-hoc Mask Attack
Supports interactive listing, range selection, and browsing of available mask files

Download Wordlists from Hashmob.net (Wordlist Tools option 9)

Downloads wordlists from Hashmob.net's collection of cracked passwords and commonly used wordlists.

Interactive menu for browsing available wordlists
Progress tracking for large downloads
Stores wordlists in configured wordlist directory

Interactive menu for downloading and managing wordlists from Weakpass.com via BitTorrent.

Browse available Weakpass wordlist torrents
Download specific wordlists or entire collections
Automatic extraction of compressed archives
Progress tracking for torrent downloads

Hashmob Downloads (Wordlist Tools option 11)

Access a submenu for downloading large-scale password corpora and specialized wordlists from Hashmob.net.

Archives - Downloads yearly full-found password corpora (multi-GB archives containing all cracked passwords from a given year)

Requires confirmation before downloading -- these archives are large (the listing may show "(unknown size)" since Hashmob's API doesn't currently report a file size per archive)
Lists all available archives across every year as one globally-numbered list to browse and pick from by index, rather than a per-year picker
Accepts a (or all) at the selection prompt to download every listed archive, one at a time. A single confirmation naming the archive count and the summed size covers the whole batch; an archive already on disk at its listed size is skipped, one whose size does not match is re-downloaded, and a failure is counted rather than aborting the rest
Stores archives in the configured wordlist directory for extraction and use

Combined Left Lists - Downloads per-hashcat-mode combined lists of uncracked ("left") hashes from Hashmob.net

Each list is a set of hashes, not plaintexts, still awaiting a crack for that hashcat mode
Useful for spotting overlap between your own hash list and hashes the community hasn't cracked yet
Supports mode selection from the listed hash counts per algorithm

Version History

The full, per-release changelog now lives in CHANGELOG.md.

hate_crack v2.36.1

Kategorien