trustedsec/hate_crackUno strumento per automatizzare le metodologie di cracking tramite Hashcat del team TrustedSec.
___ ___ __ _________ __
/ | \_____ _/ |_ ____ \_ ___ \____________ ____ | | __
/ ~ \__ \\ __\/ __ \ / \ \/\_ __ \__ \ _/ ___\| |/ /
\ Y // __ \| | \ ___/ \ \____| | \// __ \\ \___| <
\___|_ /(____ /__| \___ >____\______ /|__| (____ /\___ >__|_ \
\/ \/ \/_____/ \/ \/ \/ \/
L'installazione dal sorgente è l'unica modalità supportata. hate_crack non è
distribuito su PyPI: pip install hate-crack risolve a un segnaposto 0.0.0
che fallisce di proposito e rimanda qui. Il nome è tenuto solo affinché nessun altro
possa pubblicare un clone con lo stesso nome — vedi
packaging/pypi-placeholder/.
Hashcat deve essere installato e disponibile nel tuo PATH:
Ubuntu/Kali:```bash sudo apt-get install -y hashcat
macOS (Homebrew):```bash
brew install hashcat
Or download a pre-built binary from https://hashcat.net/hashcat/ and set hcatPath in config.json to its location.
Clona con i sottomoduli (richiesti per hashcat-utils, princeprocessor, pcfg_cracker, Corporate_Masks e opzionalmente omen):```bash git clone --recurse-submodules https://github.com/trustedsec/hate_crack.git cd hate_crack
Se hai clonato senza sottomoduli, inizializzali:```bash
git submodule update --init --recursive
Poi personalizza la configurazione se necessario. hate_crack usa due file di configurazione, ciascuno con un proprio set distinto di impostazioni:
config.json — percorsi delle wordlist, maschere, regole, tuning, potfile, percorso di hashcat, limiti dei candidati, interruttori di notifica, impostazioni predefinite della CLI (35 impostazioni)..env — solo impostazioni di integrazione di terze parti: credenziali Hashview e Hashmob, credenziali Pushover, Ollama e pipal (14 impostazioni). Non tracciato da git, creato con modalità 0600.Il confine sta lì per un motivo: .env è il file che può contenere segreti. Le credenziali per i servizi di terze parti, e la loro configurazione, vanno nel file non tracciato con permessi 0600; tutto ciò che hate_crack fa localmente rimane in config.json, che è sicuro da condividere, confrontare (diff) e includere nei propri appunti. È anche per questo che le credenziali Pushover stanno in .env, mentre gli interruttori on/off di Pushover stanno in config.json — gli interruttori sono preferenze locali, non segreti.
Ogni chiave ha esattamente una collocazione. Una chiave inserita nell'altro file viene ignorata e hate_crack stampa un avviso che indica il file a cui appartiene. Qualsiasi chiave può comunque essere sovrascritta per una singola esecuzione esportando la sua variabile d'ambiente. La maggior parte degli utenti può saltare questo passaggio perché i percorsi predefiniti funzionano subito.
config.json è permanente e di prima classe — non è deprecato e non è prevista alcuna rimozione futura. Solo le impostazioni di integrazione sono state spostate.
Passando da un singolo config.json? hate_crack lo migra automaticamente al primo avvio: le impostazioni di integrazione vengono copiate in un nuovo .env con permessi 0600, poi rimosse da config.json così i due file non le rivendicano entrambi. Stampa quali chiavi sono state spostate (mai i loro valori) e salva l'originale come config.json.pre-split.bak prima di toccarlo. Tutto il resto in config.json rimane esattamente com'era, incluso l'ordine delle chiavi.
Primo avvio: hate_crack crea entrambi i file per te, quindi non c'è nulla da fare. Per configurare .env a mano, invece, copia il template tracciato:```bash
cp .env.example .env
chmod 600 .env
`.env.example` è committato e viene distribuito con tutte le chiavi di credenziali vuote. `.env` stesso non deve **mai** essere committato — è in gitignore, insieme alle sue tipiche varianti di backup, e hate_crack lo crea sempre con modalità `0600` (solo lettura/scrittura del proprietario). `.env.example` viene generato dallo schema; rigenera il file dopo aver modificato `hate_crack/config_schema.py` con `uv run python -m hate_crack.config_writer`.
### 3. Installa le dipendenze e hate_crack
Il modo più semplice è eseguire `make` (o `make install`), che rileva automaticamente il tuo sistema operativo e installa:
- Dipendenze esterne (p7zip, transmission-daemon / transmission-remote)
- Compila i sottomoduli (hashcat-utils, princeprocessor, pcfg_cracker e opzionalmente omen) e fa il checkout del set di maschere Corporate_Masks, contenente solo dati
- Dipendenze Python tramite uv e uno shim CLI in `~/.local/bin/hate_crack````bash
make
Questo è idempotente - salta gli strumenti già installati. Per forzare una reinstallazione pulita:```bash make reinstall
**Oppure installa le dipendenze manualmente:**
### Dipendenze esterne
Queste sono necessarie per alcuni flussi di download/estrazione:
- `7z`/`7za` (p7zip) — usato per estrarre archivi `.7z`.
- `transmission-daemon` / `transmission-remote` — usato per scaricare i torrent di Weakpass.
Comandi di installazione manuale:
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
Poi installa le dipendenze Python e lo shim CLI:```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
La logica principale è ora suddivisa in moduli sotto hate_crack/:
hate_crack/cli.py: helper argparse e override di configurazione.hate_crack/api.py: integrazioni con Hashview, Weakpass e Hashmob (download/menu/helper).hate_crack/attacks.py: gestori degli attacchi dal menu.hate_crack/hashmob_wordlist.py: utilità per le wordlist di Hashmob (wrapper sottile; richiama api.py).hate_crack/corpus_stats.py: statistiche delle password dell'intero corpus, usate per descrivere un corpus all'LLM.hate_crack/plaintext.py: recupera la password da una riga del corpus (rimozione del prefisso hash, decodifica $HEX[...]); condiviso dalle modalità LLM, da corpus_stats e da rulegen.hate_crack/llm.py: generazione strutturata (JSON) di candidati LLM tramite Atomic Agents.hate_crack/menu.py: renderer di menu condiviso, inclusa la navigazione opzionale con i tasti freccia.hate_crack/noninteractive.py: dispatcher per i sottocomandi di attacco scriptati.hate_crack/notify/: pacchetto di notifiche (backend Pushover, tailer per-crack).Il file hate_crack.py di livello superiore rimane il punto di ingresso principale e orchestra questi moduli.
Questo progetto dipende da ed è ispirato a numerosi progetti e servizi esterni. Grazie a:
Dopo l'installazione con make, esegui hate_crack da qualsiasi posizione:```bash
hate_crack
hate_crack <hash_file> <hash_type> [options]
In alternativa, esegui tramite `uv`:```bash
uv run hate_crack.py <hash_file> <hash_type>
Installa usando make dalla root del repository - questo compila i sottomoduli e impacchetta le risorse:```bash
cd /path/to/hate_crack
make
hate_crack
Il comando `make install` crea uno shim bash in `~/.local/bin/hate_crack` che viene eseguito dalla directory del repository, così config e asset vengono sempre trovati indipendentemente dalla tua directory di lavoro corrente.
La configurazione viene cercata anche in:
- La radice del repository e la directory del pacchetto
- `~/.hate_crack`
**Nota:** Il campo `hcatPath` in `config.json` indica solo la posizione del binario di hashcat (opzionale se hashcat è nel PATH). Gli asset di Hate_crack (hashcat-utils, princeprocessor, pcfg_cracker, Corporate_Masks, omen) vengono caricati dalla directory del repository e inclusi automaticamente da `make install`.
### Esegui come script
Lo script utilizza uno shebang `uv`. Rendilo eseguibile ed esegui:```bash
chmod +x hate_crack.py
./hate_crack.py
Puoi anche usare Python direttamente:```bash python hate_crack.py
### Utilizzo non interattivo / scriptato
Per l'automazione puoi lanciare un singolo attacco direttamente, bypassando il menu. Il nome dell'attacco è il primo argomento, seguito dal file hash e dal tipo di hash di hashcat. I prompt di preelaborazione (filtraggio degli account computer, forza bruta LM-first, deduplicazione degli account duplicati) accettano automaticamente i propri valori predefiniti in questa modalità. Il processo termina con `0` in caso di successo e con un valore diverso da zero in caso di errore (file hash mancante, tipo di hash non numerico, wordlist mancante o nome del file di regole sconosciuto).```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
Un clone più vecchio può rifiutare l'aggiornamento, stampando una lunga lista di righe come:``` ! [rejected] v2.5.0 -> v2.5.0 (would clobber existing tag)
Questo riguarda i cloni creati prima di luglio 2026. La cronologia pubblicata è stata riscritta
allora per rimuovere alcuni file che non avrebbero mai dovuto finire in un commit, il che ha dato
a ogni commit un nuovo ID; di conseguenza i tag di un clone più vecchio puntano a oggetti che
questo repository non contiene più, e git rifiuta di spostare un tag che già possiede.
Non c'è nulla di sbagliato nel tuo checkout e nessun dato di cracking è a rischio.
Recupera con un reset una tantum. Questo scarta i commit locali e le modifiche nel
checkout, quindi se hai personalizzato qualcosa tracciato da git (a differenza di
`config.json`, che non è tracciato), esegui il commit su un branch prima:```bash
cd /path/to/hate_crack
git fetch --tags --force origin
git checkout -B main origin/main
make install
--force qui aggiorna solo i tag; non può toccare i tuoi commit. Successivamente
l'aggiornatore integrato funziona normalmente. Le versioni precedenti alla 2.18 non
potevano eseguire questo ripristino da sole, motivo per cui va fatto manualmente una volta.
Se vedi un errore come:``` Error: Build directory /opt/hashcat/hashcat-utils does not exist. Expected to find expander at /opt/hashcat/hashcat-utils/bin/expander.
Questo significa che gli asset di hate_crack non sono stati inclusi nel pacchetto installato.
**Capire i percorsi:**
- `hcatPath` in config.json → punta a **posizione del binario di hashcat** (opzionale, può essere nel PATH)
- `hashcat-utils/` e `princeprocessor/` → inclusi nel pacchetto da `make install`
**Soluzione:**
Reinstallare usando il Makefile, che compila i sottomoduli e installa lo strumento:```bash
cd /path/to/hate_crack # the repository checkout
make install
Configurazione predefinita (config.json.example):
La maggior parte degli utenti può usare i valori predefiniti senza personalizzazioni:
hcatWordlists: ./wordlists (relativo alla radice del repository o a HOME/.hate_crack)hcatOptimizedWordlists: ./optimized_wordlists (directory usata da Quick Crack; ripiega su hcatWordlists se non trovata)rules_directory: ./hashcat/rules (include le regole dei sottomoduli)hcatTuning: `` (stringa vuota - nessun flag di ottimizzazione predefinito)Esempio di personalizzazioni di config.json:```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) ... }
**Caricamento della configurazione:**
- Precedenza per ogni chiave: `os.environ` > il file home della chiave (`.env` o `config.json`) > valore predefinito integrato
- Le chiavi mancanti ricadono sui valori predefiniti integrati; `config.json.example` documenta ogni chiave di `config.json`
- Entrambi i file vengono cercati, indipendentemente l'uno dall'altro, in questo ordine: **root del repository**, poi la **directory del pacchetto installato**, poi **`~/.hate_crack`**. La prima corrispondenza vince; è normale che i due file provengano da directory diverse.
- Al primo avvio, entrambi vengono creati — `config.json` da `config.json.example`, `.env` dai valori predefiniti integrati. Se un `config.json` più vecchio contiene ancora chiavi di integrazione, queste vengono copiate nel nuovo `.env` e hate_crack ti dice quali eliminare da `config.json`; non modifica mai quel file stesso.
- A ogni esecuzione, hate_crack stampa i due file che ha effettivamente caricato: ```
[*] config.json: /home/you/.hate_crack/config.json
[*] .env: /home/you/.hate_crack/.env
Leggi queste due righe prima di eseguire il debug di un'impostazione che "non ha effetto". Esistono a causa di due insidie nell'ordine di ricerca:
.env o config.json che si trova in qualsiasi checkout da cui esegui lo strumento ha la precedenza su quello in ~/.hate_crack — e lanciare lo strumento da un checkout è esattamente ciò che crea quei file lì in primo luogo. Se questo dovesse mai oscurare una vera configurazione ~/.hate_crack, hate_crack ora lo segnala con una terza riga [!] che indica entrambi i percorsi — tratta quella riga come "il file qui sotto viene ignorato," non come una seconda configurazione altrettanto valida..env nella directory in cui ti trovi viene ignorato, deliberatamente: le directory degli engagement sono piene di file che nessuno intendeva come configurazione. Mettilo nella root del repository o in ~/.hate_crack.Se vedi:``` Your configuration specifies to merge with the ref 'refs/heads/master' from the remote, but no such ref was fetched.
Il branch predefinito è stato rinominato da `master` a `main`. Correggi con:```bash
git remote set-head origin -a
git branch -m master main
git branch --set-upstream-to=origin/main main
git pull
Default (installazione completa) - compila i sottomoduli, installa le dipendenze e installa lo strumento:```bash make
make install
Questo è idempotente: salta gli strumenti già installati.
**Forza la reinstallazione pulita:**```bash
make reinstall
Aggiornamento rapido - ricompila i sottomoduli e reinstalla lo strumento (dopo aver eseguito il pull delle modifiche):```bash make update
**Disinstallazione** - rimuove le dipendenze del sistema operativo e il tool:```bash
make uninstall
Compila solo hashcat-utils:```bash make hashcat-utils
**Esegui i test** - gestisce automaticamente HATE_CRACK_SKIP_INIT quando necessario:```bash
make test
Rapporto di copertura:```bash make coverage
**Pulire gli artefatti di build/test:**```bash
make clean
Installa il progetto con le dipendenze di sviluppo opzionali (include linter e strumenti di test):```bash make dev-install
### Esecuzione di Linter e Controlli dei Tipi
Prima di inviare le modifiche, esegui questi controlli in locale. Usa `make lint` per tutto, oppure esegui i singoli controlli:
**Ruff (linting e formattazione):**```bash
make ruff
# or manually:
uv run ruff check hate_crack tests tools packaging hate_crack.py
Correzione automatica dei problemi:```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 (controllo dei tipi):**```bash
make ty
# or manually:
uv run ty check hate_crack
Esegui tutti i controlli insieme:```bash make lint
### Esecuzione dei test
I test rilevano automaticamente quando i sottomoduli non sono compilati e impostano `HATE_CRACK_SKIP_INIT=1` automaticamente.```bash
make test
Oppure esegui pytest direttamente:```bash uv run pytest -v
Con copertura:```bash
make coverage
Oppure con pytest:```bash uv run pytest --cov=hate_crack
### Git Hooks (prek)
I Git hook sono gestiti da [prek](https://github.com/j178/prek) (v0.3.3+). Installa gli hook con:```bash
prek install --hook-type pre-push --hook-type pre-commit
Questa installa gli hook definiti in prek.toml usando lo schema TOML local-repo di pre-commit:
pre-commit/pre-commit-hooks): trailing-whitespace,
end-of-file-fixer, check-yaml, check-merge-conflict, check-added-large-files,
detect-private-keyGli auto-fixer di pre-commit riscrivono i file sul posto, quindi rimetti in staging ed esegui di nuovo il commit dopo la loro esecuzione.
Nota: prek 0.3.3 si aspetta repos = [...] al livello superiore. Il vecchio formato [hooks.<stage>] commands = [...] non è supportato.
I menu usano di default la classica selezione numerata tramite print() + input(), che accetta tasti completi a più cifre.
Per abilitare la navigazione con tasti freccia tramite simple-term-menu, imposta HATE_CRACK_ARROW_MENU=1. In questa modalità funzionano solo i tasti di scelta rapida a una cifra; le opzioni numerate da 10 in su devono essere raggiunte con i tasti freccia. La modalità con tasti freccia richiede anche una TTY, quindi rimane disattivata quando l'output è reindirizzato a pipe.
Il gruppo facoltativo [dev] include:
Opzioni comuni:
--download-hashview: Scarica gli hash da Hashview prima del cracking.--hashview: Menu interattivo di Hashview per gestire hash, wordlist e job.--hashview --help: Mostra le opzioni della riga di comando di Hashview.--weakpass: Scarica le wordlist da Weakpass.--hashmob: Scarica le wordlist da Hashmob.net.--download-torrent <FILENAME>: Scarica uno specifico file torrent di Weakpass.--download-all-torrents: Scarica tutti i torrent Weakpass disponibili dalla cache.--wordlists-dir <PATH> / --optimized-wordlists-dir <PATH>: Sostituisci le directory delle wordlist.--pipal-path <PATH>: Sostituisci il percorso di pipal.--restore-potfile: Ricostruisce <hashfile>.out dal file POT di hashcat all'avvio, sostituendo eventuali contenuti esistenti, quindi continua nel menu normale. Senza questo flag, la ricerca del POT viene eseguita solo quando non esiste già. L'opzione 93 del menu fa la stessa cosa su richiesta, con una richiesta di conferma.hate_crack si integra con Hashview per la gestione centralizzata degli hash e il cracking distribuito.
Accedi al menu interattivo di Hashview:```bash hate_crack.py --hashview
Menu options:
- **(1) Carica hash craccati** - Carica i risultati craccati dalla sessione corrente su Hashview
- **(2) Carica wordlist** - Carica un file wordlist su Hashview
- **(3) Scarica wordlist** - Scarica una wordlist da Hashview
- **Scarica regola** - Scarica un file di regole da Hashview (decompresso in testo semplice, pronto per `hashcat -r`)
- **(4) Scarica hash rimanenti** - Scarica gli hash rimanenti non craccati (chiede di passare a questi per il cracking)
- **(5) Scarica hash trovati** - Scarica gli hash già craccati con password in chiaro (per riferimento/analisi)
- **(6) Carica hashfile e crea job** - Carica un nuovo hashfile e crea un job di cracking
- **(99) Torna al menu principale** - Ritorna al menu principale
**Importante: Scarica hash trovati vs Scarica hash rimanenti**
- **Scarica hash rimanenti (4)**: Scarica gli hash non craccati che devono essere craccati. Unisce automaticamente eventuali hash trovati, se disponibili, e chiede di passare a questo hashfile per il cracking.
- **Scarica hash trovati (5)**: Scarica gli hash già craccati in formato hash:cleartext. Questi sono di riferimento e non possono essere craccati ulteriormente. Nessuna richiesta di passaggio viene mostrata.
#### Interfaccia a riga di comando
Le operazioni Hashview possono essere eseguite anche tramite riga di comando:
Carica hash craccati:```bash
hate_crack.py --hashview upload-cracked --file <output_file>.out --hash-type 1000
Carica una wordlist:```bash hate_crack.py --hashview upload-wordlist --file .txt --name "My Wordlist"
Scarica un file di regole (salvato decompresso, pronto per `hashcat -r`):```bash
hate_crack.py --hashview download-rules --rules-id 4 --output best64.rule
Scarica gli hash rimanenti (hash non craccati per il cracking):```bash hate_crack.py --hashview download-left --customer-id 1 --hashfile-id 123
Scarica gli hash trovati (hash già decifrati con testo in chiaro):```bash
hate_crack.py --hashview download-found --customer-id 1 --hashfile-id 123
Carica il file hash e crea il job:```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"
#### Configurazione
Imposta le credenziali di Hashview in `.env` (sono impostazioni di integrazione, quindi non vivono in `config.json`):```
HASHVIEW_URL=https://hashview.example.com
HASHVIEW_API_KEY=your-api-key-here
L'attacco LLM (opzione 12) utilizza Ollama per generare candidati password. Configura il modello, la finestra di contesto e il timeout della richiesta in .env:```
OLLAMA_MODEL=qwen2.5:32b
OLLAMA_NUM_CTX=8192
OLLAMA_TIMEOUT=300
- **`OLLAMA_MODEL`** — Il modello Ollama usato per la generazione dei candidati (default: `qwen2.5:32b`). L'attacco LLM usa un output strutturato (JSON), quindi scegli un modello con un buon supporto per strumenti/JSON.
- **`OLLAMA_NUM_CTX`** — Dimensione della finestra di contesto per il modello (default: `8192`). Prima dell'introduzione delle statistiche sul corpus era `2048`, troppo piccola per contenere il prompt che le veniva fornito: 500 testi in chiaro campionati occupano circa 2.000–3.500 token prima del prompt di sistema e della risposta, quindi Ollama troncava silenziosamente parte del campione che il campionatore aveva distribuito attentamente nel file.
- **`OLLAMA_TIMEOUT`** — Secondi di attesa per una risposta di generazione prima di abbandonare (default: `300`). Aumentalo se un modello grande è ancora in caricamento in VRAM alla prima richiesta, il che altrimenti potrebbe superare il timeout; hate_crack stampa il timeout trascorso e il nome di questa impostazione quando scatta.
- **`OLLAMA_MAX_SAMPLE_LINES`** — La soglia al di sotto della quale le modalità LLM includono anche i testi in chiaro letterali nel prompt (default: `500`). Valori ≤ 0 vengono trattati come 500.
Le modalità basate sul corpus (**Wordlist**, **Password crackate**, **Regole di pattern**) descrivono sempre l'*intero* corpus in modo statistico — percentuali di baseword, maschere, uso di maiuscole/minuscole, lunghezze, cifre e simboli finali, anni — invece di incollarne una fetta. L'aggregazione è limitata, quindi un dump di 120.000 password costa più o meno lo stesso spazio nel prompt di uno da 500 righe. Quando l'intero corpus rientra in questa soglia, vengono inclusi anche i testi in chiaro grezzi, poiché non c'è nulla da guadagnare nascondendo un piccolo corpus al modello.
Questo sostituisce il precedente comportamento che incollava un campione equidistante di massimo `ollamaMaxSampleLines` password. Un campione di un grande dump non forniva alcuna informazione sulla frequenza: il modello non poteva distinguere una baseword usata dall'8% dell'organizzazione da una usata da una singola persona, che è proprio il segnale che rende un tentativo degno di essere eseguito.
- **`OLLAMA_NO_CLOUD`** — Quando è `true`, rifiuta di inviare qualsiasi cosa fuori da questo host, per uno qualsiasi dei tre backend LLM (Ollama, vLLM o un server compatibile OpenAI generico). Due controlli sono legati a questa singola impostazione: Ollama inoltra un modello con tag `-cloud` (`gpt-oss:120b-cloud`, `deepseek-v3.1:671b-cloud`) a ollama.com attraverso lo stesso endpoint locale che usa un modello locale, quindi nulla nella richiesta appare diverso — questo viene rifiutato in base al nome del modello. Viene controllato anche l'URL del backend configurato: una destinazione che non è loopback, privata o link-local (e non è `localhost` o un nome `.local`/`.internal`/`.lan`/`.localdomain`) viene rifiutata in base alla destinazione, e anche un hostname che questo controllo non riesce a risolvere viene rifiutato, fail-closed, piuttosto che lasciar passare una destinazione non verificabile. I prompt di hate_crack contengono testi in chiaro recuperati, statistiche sul corpus e il nome, il settore e la località del cliente, quindi se uno dei due controlli scatta, la richiesta viene rifiutata prima di essere costruita. Il default è `false`, quindi un modello cloud o un server remoto configurato deliberatamente continua a funzionare; attivalo per gli incarichi in cui i dati del cliente non devono lasciare l'host.
- **`OLLAMA_AUTO_RESEARCH`** — Quando è `true` (default), la modalità **Info sul target** chiede al modello locale di suggerire settore, località e società madre / cronologia delle acquisizioni non appena hai digitato il nome dell'azienda, e li offre come default modificabili dei prompt. Imposta a `false` per ottenere sempre prompt vuoti (utile con un modello lento, poiché la ricerca costa un round-trip extra prima che l'attacco inizi).
- **`OLLAMA_HOST`** — Dove Ollama è in ascolto. Accetta un semplice `host:port` (`theplague.lan:11434`) o un URL completo con schema (`https://ollama.example.com`); in entrambi i casi l'URL di base viene normalizzato prima dell'uso. Il default è `localhost:11434`. Impostalo in `.env`, oppure esportalo come vera variabile d'ambiente per sovrascriverlo per una singola esecuzione — è lo stesso nome di variabile che legge la CLI di Ollama stessa.
- Assicurati che Ollama sia in esecuzione e che il modello sia scaricato (`ollama pull qwen2.5:32b`) prima di usare l'Attacco LLM — hate_crack non scarica più automaticamente i modelli mancanti.
L'attacco offre tre modalità di generazione:
1. **Info sul target** — azienda / settore / località / società madre; il modello deriva i candidati da questi dettagli.
Dopo aver digitato il nome dell'azienda, hate_crack chiede allo stesso modello locale cosa sa già di quell'organizzazione e precompila i prompt **Settore**, **Località** e **Società madre** con le risposte, mostrate tra parentesi: ```
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:
Premi Invio per accettare un suggerimento o digita sopra. Questi valori sono il ricordo del modello, non OSINT — trattali come un punto di partenza, non come informazioni sul cliente. La ricerca utilizza solo il server Ollama locale, quindi il nome del cliente non lascia mai l'host; non ci sono chiamate API web o di terze parti. Se il modello non riconosce l'organizzazione (il caso comune per piccoli clienti), non restituisce nulla e ottieni semplici prompt vuoti: ``` Company name: Acme Rail Services Industry: Location: Parent company / acquired by:
Un errore di ricerca — timeout, Ollama non in esecuzione, risposta vuota — non blocca mai l'attacco; semplicemente ripiega su prompt vuoti. Imposta `ollamaAutoResearch` a `false` per saltare del tutto la ricerca.
2. **Wordlist** — ricava basewords da una wordlist campione.
3. **Password crackate** — fornisci al modello i testi in chiaro già recuperati in questa sessione (`<hashfile>.out`) così che possa dedurre le convenzioni di password dell'organizzazione bersaglio (basewords, stagioni, anni, suffissi, leetspeak) e generare *nuovi* candidati nello stesso stile. Questa opzione viene elencata solo dopo che almeno un hash è stato crackato; l'intero file viene analizzato statisticamente esattamente come nella modalità Wordlist (vedi `ollamaMaxSampleLines` sopra).
#### Configurazione PCFG
L'attacco PCFG (opzione 20) e l'attacco PRINCE-LING (opzione 21) utilizzano il sottomodulo `pcfg_cracker`. Configurali in `config.json`:```json
{
"pcfgRuleset": "DEFAULT",
"pcfgMaxCandidates": 50000000,
"pcfgPrinceLingMaxCandidates": 10000000
}
pcfgRuleset — Nome della grammatica addestrata da usare (default: DEFAULT), risolta in pcfg_cracker/Rules/<name>/. Addestra la tua con trainer.py di pcfg_cracker e imposta questo parametro sul nome del ruleset.pcfgMaxCandidates — Numero massimo di candidati che pcfg_guesser.py emette per l'attacco PCFG (default: 50000000).pcfgPrinceLingMaxCandidates — Numero massimo di parole base che prince_ling.py scrive nella wordlist base PRINCE memorizzata in cache (default: 10000000).optimizedKernelAttacks)Il flag -O di hashcat seleziona i kernel ottimizzati, che sono sostanzialmente più veloci
ma limitano la lunghezza dei candidati (circa 31 caratteri, meno per alcune modalità) e
saltano silenziosamente qualsiasi cosa più lunga. optimizedKernelAttacks in config.json elenca
gli attacchi che vengono eseguiti con -O; ometti un attacco dall'elenco per eseguirlo con
kernel a lunghezza completa. L'elenco in config.json.example corrisponde al default
integrato che si applica quando non esiste alcun config.json.
Quattro attacchi rispettano l'impostazione ma non sono ottimizzati di default, perché
alimentano candidati che possono superare il limite di -O — aggiungili all'elenco per
scegliere di abilitarli:
hcatNgramX, hcatOllama, hcatOmen, hcatLMtoNTPer disattivare -O ovunque per una singola esecuzione senza modificare la configurazione, passa
--no-optimized-kernel (forma breve --no-optimize). Questo sovrascrive l'elenco per
ogni attacco e rimuove anche un -O scritto in hcatTuning, che altrimenti
raggiungerebbe hashcat indipendentemente dall'elenco.
I nomi vengono confrontati esattamente e una voce non riconosciuta viene segnalata all'avvio
piuttosto che ignorata. Nota che gli attacchi che delegano a un altro attacco sono
controllati dall'attacco a cui delegano, non dal proprio nome: PRINCE-LING
segue hcatPrince, mentre Spoonman, Rosetta e le modalità pattern-rule LLM
seguono hcatQuickDictionary.
coverage_enabled)Nel corso di un impegno lungo, lo stesso file di hash viene attaccato in molte sessioni con un set rotante di wordlist, file di regole e liste di maschere, ed è facile bruciare ore ripetendo terreno già coperto — soprattutto perché la stessa riga di regola vive in più di un file di regole. hate_crack registra ciò che ha già eseguito contro ciascun file di hash e offre di saltare la sovrapposizione.
La copertura è registrata per voce, non per file: singole righe di regola e
singole righe .hcmask, ciascuna abbinata alla wordlist con cui è stata eseguita. Questo
è ciò che le consente di riconoscere che un file di regole personalizzato che esegui oggi ripete 40
delle regole che best64.rule ha già coperto la scorsa settimana, ed è anche il motivo per cui una regola è
"coperta" solo per la specifica wordlist con cui è stata provata — le stesse regole su
un corpus diverso provano candidati completamente diversi.
Il file di hash è identificato da uno sha256 del suo contenuto, quindi la copertura sopravvive alla rinomina o allo spostamento tra sessioni. Le wordlist sono identificate allo stesso modo, con il digest memoizzato rispetto a dimensione e mtime, così un corpus di diversi gigabyte viene sottoposto a hash una volta sola invece che a ogni attacco.
Ti viene chiesto solo quando c'è realmente qualcosa da saltare:``` [*] 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]:
Rispondi `Y` e hate_crack crea un file di regole temporaneo contenente solo le voci non ancora provate;
rispondi `n` per eseguire comunque l'intera operazione. Se *ogni* voce è una ripetizione,
ti viene chiesto se saltare del tutto l'attacco, così ri-eseguire deliberatamente terreno già coperto non richiede mai di riavviare lo strumento.
Gli attacchi che non vengono mai filtrati vengono comunque registrati come eseguiti, ed è
questo che ti permette di rispondere a "ho già eseguito PRINCE contro questo obiettivo?".
Tre limiti deliberati:
- **La copertura viene registrata solo quando hashcat esaurisce il keyspace** (exit 1). Un
ctrl-C o un errore non registra nulla, e nemmeno l'exit 0 — che significa che tutte le hash
sono state crackate, cosa che hashcat riporta *senza* completare il keyspace, e nel caso
degenere "tutte le hash trovate come voci nel potfile" senza provare nemmeno un
candidato. Una sottoregistrazione costa solo una riesecuzione ridondante in seguito.
- **I generatori dinamici di candidati non vengono mai filtrati.** PRINCE, PCFG, OMEN,
brute force di Markov e le modalità LLM non hanno un insieme fisso da confrontare, quindi
vengono registrati come eseguiti e per il resto lasciati in pace. I file di regole concatenati
(`-r a -r b`) vengono tracciati come un'unica unità piuttosto che per singola voce, perché hashcat
applica il *prodotto cartesiano* dei due file e rimuovere una singola riga eliminerebbe
silenziosamente ogni combinazione a cui partecipava.
- **Le esecuzioni con `--loopback` vengono registrate ma mai filtrate.** hashcat reinserisce
i plaintext appena crackati come *candidati extra*, quindi un'esecuzione del genere prova
l'intera wordlist e il set di regole più tutto ciò che quei plaintext riciclati raggiungono.
Questo rende le due direzioni asimmetriche: registrarlo è corretto, quindi un'esecuzione
ordinaria successiva della stessa wordlist e regole viene riconosciuta correttamente come
ripetizione, ma una seconda esecuzione loopback ha più crack da riciclare e non viene mai saltata.
Imposta `coverage_enabled` su `false` in `config.json` per disattivare questa funzione, oppure passa
`--no-coverage` per una singola esecuzione — che non consulta né aggiorna il registro.
#### Ispezione e ripristino della copertura
L'opzione del menu principale **85 — Attack Coverage** mostra cosa è stato eseguito contro il
file di hash caricato, la sua cronologia delle esecuzioni, e può cancellarla. Le stesse tre azioni sono
scriptabili:```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
Il file hash è identificato dal contenuto, quindi questi funzionano indipendentemente da dove è stato spostato. forget influisce solo su quel singolo bersaglio — l'archivio si trova in ~/.hate_crack/coverage/attack_coverage.sqlite3, e l'eliminazione del file azzera la copertura per ogni bersaglio.
Un attacco con script che la copertura salta completamente esce comunque con 0 di default, quindi abilitare la copertura non può far fallire un harness esistente. Passa --exit-code-on-skip per ottenere invece il codice di uscita 3 quando non è stato lanciato nulla:```bash
hate_crack --exit-code-on-skip hashes.txt dict
Uscita 3 significa che *niente* è stato eseguito. Un passaggio parzialmente filtrato — alcune voci
saltate, altre provate — esce comunque con `0`, perché l'attacco ha effettivamente svolto lavoro.
### Notifiche (opzione 82 del menu)
hate_crack può inviare notifiche push Pushover quando gli attacchi vengono completati e, opzionalmente, quando vengono trovati singoli hash. Tutti i controlli si trovano sotto l'opzione `82 — Notifications` del menu principale:
1. **Attiva/disattiva notifiche Pushover [ON/OFF]** — interruttore principale. Persiste in `config.json` come `notify_enabled`.
2. **Attiva/disattiva notifiche per-crack [ON/OFF]** — quando ON, un tailer in background osserva il file `.out` e invia una notifica per ogni crack (con aggregazione a burst per tick). Persiste in `config.json` come `notify_per_crack_enabled`. Non può essere abilitata mentre l'interruttore principale è OFF — abilita prima l'opzione 1.
3. **Invia notifica Pushover di prova** — invia una push preconfigurata per confermare che la coppia token/utente Pushover funzioni. Funziona anche quando l'interruttore principale è OFF.
Le credenziali si trovano in `.env`; i restanti parametri di regolazione sono disponibili solo tramite file di configurazione in `config.json`:
- `NOTIFY_PUSHOVER_TOKEN`, `NOTIFY_PUSHOVER_USER` (in `.env`) — necessarie affinché qualsiasi push venga inviata. Nessuna voce del menu scrive questi valori; modifica tu stesso `.env`.
- `notify_attack_allowlist` — nomi degli attacchi che danno il consenso automaticamente senza la richiesta `[y/N/always]`. Viene popolato automaticamente quando rispondi `always`.
- `notify_suppress_in_orchestrators` (default `true`) — silenzia i singoli attacchi concatenati da Extensive Crack, che invece invia un unico riepilogo. Impostalo a `false` per ricevere una notifica per ogni attacco concatenato. Altre voci del menu che eseguono più passaggi (ad esempio Quick Crack con più catene di regole) non sono orchestratori e inviano sempre una notifica per passaggio.
- `notify_max_cracks_per_burst` (default `5`), `notify_poll_interval_seconds` (default `5.0`) — regolazione del tailer per-crack. Vedi `hate_crack/notify/tailer.py` per la logica di aggregazione a burst.
### Strumenti per Wordlist (opzione 80 del menu)
Il sottomenu Strumenti per Wordlist fornisce utilità di pre-elaborazione delle wordlist basate sui binari di hashcat-utils, oltre al download di wordlist da Hashmob.net e Weakpass. L'accesso avviene tramite l'opzione **80** nel menu principale.
| Option | Binary | What it does |
|--------|--------|--------------|
| 1 | `len.bin` | Filtra per lunghezza - mantieni solo le parole tra una lunghezza minima e massima |
| 2 | `req-include.bin` | Richiedi classi di caratteri - mantieni solo le parole che contengono tutti i tipi di carattere richiesti |
| 3 | `req-exclude.bin` | Escludi classi di caratteri - rimuovi le parole che contengono qualsiasi tipo di carattere escluso |
| 4 | `cutb.bin` | Estrai sottostringa - taglia un intervallo di byte da ogni parola |
| 5 | `splitlen.bin` | Dividi per lunghezza - crea file separati per ogni lunghezza di parola (file nominati `01`-`64` in una directory di output) |
| 6 | `rli.bin` / `rli2.bin` | Sottrai parole - rimuovi le voci che compaiono in uno o più altri file |
| 7 | `gate.bin` | Shard - estrai ogni N-esima parola per cracking distribuito su più macchine |
| 8 | - | Ottimizza le wordlist - deduplica e dividi in file per lunghezza nella directory delle wordlist ottimizzate |
| 9 | - | Scarica wordlist da Hashmob.net |
| 10 | - | Scarica wordlist da Weakpass (tramite BitTorrent) |
**Bit della maschera delle classi di caratteri** (usati dalle opzioni 2 e 3): `1`=minuscolo, `2`=maiuscolo, `4`=cifra, `8`=simbolo, `16`=altro. Somma i valori: `7` = minuscolo+maiuscolo+cifra.
**Come deve essere usato lo sharding**: lo sharding divide una wordlist in N parti uguali e non sovrapposte, così il lavoro può essere distribuito su più macchine o GPU. Ogni parte è *intervallata* (ogni N-esima riga), quindi ogni shard è un campione rappresentativo dell'intera lista piuttosto che un blocco contiguo iniziale/finale — nessun singolo nodo rimane bloccato a craccare solo la coda a bassa probabilità.
Esegui l'opzione 7 una volta, fornisci una wordlist di input, un percorso di base di output e un numero di shard (N). Scrive tutte le N parti in un'unica passata, con nomi che usano numeri di parte con zeri iniziali (`base.001`, `base.002`, … fino a `base.00N`). Copia una parte su ogni nodo e punta l'esecuzione di hashcat di quel nodo su di essa. Su un sistema a GPU singola lo sharding non offre alcun aumento di velocità, ma una singola parte è comunque un campione rapido e rappresentativo per una rapida passata di triage prima di dedicarsi all'intera lista.
#### Controlli automatici degli aggiornamenti
hate_crack può controllare automaticamente GitHub per nuove release all'avvio. Questa funzionalità è controllata dall'opzione di configurazione `check_for_updates`:```json
{
"check_for_updates": true
}
check_for_updates — Abilita i controlli automatici della versione all'avvio (default: true).| Canale | Flag | Sorgente | Cosa ottieni |
|---|---|---|---|
| Release |
Le versioni seguono il normale semver, con l'incremento di versione derivato da ciò che è effettivamente presente nel batch. La seconda componente si sposta solo per le funzionalità: un ciclo che contiene un commit feat è diretto verso X.(Y+1).0, mentre un ciclo composto solo da fix, docs e chore è diretto verso X.Y.(Z+1).
nightly-dev tagga i release candidate per la versione verso cui il batch è diretto — v2.20.1rc1, v2.20.1rc2, … — e il merge su main promuove quello stesso target alla release finale. I release candidate sono vere pre-release PEP 440, quindi si ordinano correttamente a entrambe le estremità:
2.20.0 < 2.20.1rc1 < 2.20.1rc2 < 2.20.1 < 2.21.0rc1 < 2.21.0
Il target può cambiare a metà ciclo: il primo feat che arriva lo sposta da X.Y.(Z+1) a X.(Y+1).0 e la numerazione dei release candidate riparte per il nuovo target. Il numero indica sempre ciò che il batch rilascerebbe oggi.
La componente major non viene mai incrementata automaticamente — un subject ! o un footer BREAKING CHANGE: conta come funzionalità, perché un major automatico dista solo una riga di subject scritta male da una release pubblicata irreversibile. Un major è un atto esplicitamente umano: taggarlo e pusharlo a mano.
La policy si trova in tools/next_version.py, condivisa da entrambi i workflow di tagging e coperta da test unitari in tests/test_next_version.py.
Il controllo all'avvio offre solo release, perché le build nightly non pubblicano alcuna release su GitHub e il controllo legge l'endpoint "latest release" di GitHub — quindi abilitare check_for_updates non ti porterà mai su una nightly. Due cose tengono separati i canali: questo, e il fatto che un release candidate è una vera pre-release PEP 440, quindi anche uno strumento che ordina i numeri di versione grezzi lo tratta come più vecchio della release in cui si trasforma.
Entrambi i flag commutano prima il checkout sul branch corrispondente (e rifiutano di farlo se ci sono modifiche non committate). Se stai eseguendo una nightly e vuoi tornare al codice rilasciato, --update ti riporta su main.
Quando si scaricano gli hash left (hash non decifrati), hate_crack automaticamente:
.out locali (ad es., left_1_123.txt.out o left_1_123.nt.txt.out per il formato pwdump)Questo garantisce che i risultati locali di cracking restino sincronizzati con il database centralizzato di Hashview quando si lavora con hash non decifrati.
Nota: L'opzione download-found scarica separatamente gli hash già decifrati a scopo di riferimento e non esegue alcuna unione né richiede di avviare un cracking.
L'<hash_type> si ottiene eseguendo hashcat --help
Hash di esempio: http://hashcat.net/wiki/doku.php?id=example_hashes``` $ hashcat --help |grep -i ntlm 5500 | NetNTLMv1 | Network protocols 5500 | NetNTLMv1 + ESS | Network protocols 5600 | NetNTLMv2 | Network protocols 1000 | NTLM | Operating-Systems
Please provide the Markdown content to translate.```
$ ./hate_crack.py <hash file> 1000
___ ___ __ _________ __
/ | \_____ _/ |_ ____ \_ ___ \____________ ____ | | __
/ ~ \__ \\ __\/ __ \ / \ \/\_ __ \__ \ _/ ___\| |/ /
\ Y // __ \| | \ ___/ \ \____| | \// __ \\ \___| <
\___|_ /(____ /__| \___ >____\______ /|__| (____ /\___ >__|_ \
\/ \/ \/_____/ \/ \/ \/ \/
Version 2.0
La suite di test è per lo più offline e utilizza mocks/fixtures. I controlli di rete live e i controlli delle dipendenze di sistema sono attivabili tramite variabili d'ambiente.
uv run pytest -v
uv run pytest tests/test_hashview.py -v
Puoi anche eseguire l'intera suite con `make test`.
### Test Live (Opt-In)
Imposta uno dei seguenti per abilitare i controlli live:
- `HASHMOB_TEST_REAL=1` — controllo live della connettività/menu CLI di Hashmob
- `HASHVIEW_TEST_REAL=1` — controllo live del menu CLI di Hashview
- `WEAKPASS_TEST_REAL=1` — controllo live del menu CLI di Weakpass
- `HATE_CRACK_REQUIRE_DEPS=1` — fallisce se `7z`, `transmission-daemon` o `transmission-remote` è mancante
### Test live di upload di Hashview
Il test live di upload di Hashview viene saltato di default. Per eseguirlo, imposta la
variabile d'ambiente e fornisci credenziali valide in `.env`:```bash
HATE_CRACK_RUN_LIVE_TESTS=1 uv run pytest tests/test_upload_cracked_hashes.py -v
Invece di puntare i test live a un server Hashview remoto, puoi far sì che la suite avvii uno stack Docker locale di Hashview, lo popoli, esegua i test live contro di esso e poi lo smonti. Imposta HASHVIEW_TEST_LOCAL=1 e punta HASHVIEW_REPO a un checkout di Hashview:```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
Questo avvia `docker compose` nel repository Hashview, inizializza una chiave API admin,
un cliente, un file di hash e dati di "attività effettiva" craccati, quindi esporta le
variabili d'ambiente `HASHVIEW_*` lette dai test. Variabili d'ambiente utili:
- `HASHVIEW_TEST_LOCAL=1` — abilita lo stack locale (nessuna operazione altrimenti)
- `HASHVIEW_REPO=<path>` — checkout di Hashview (default `~/projects/hashview`)
- `HASHVIEW_KEEP=1` — lascia i container in esecuzione dopo la sessione (riesecuzioni più rapide)
- `HASHVIEW_LOCAL_PORT=5000` — porta host su cui è pubblicata l'app
La CLI hate_crack rispetta le variabili d'ambiente `HASHVIEW_URL` / `HASHVIEW_API_KEY`
(sovrascrivendo il `.env` in cui risiedono queste due chiavi), ed è ciò che consente alla
suite di puntare la CLI allo stack locale senza modificare la configurazione persistente.
### Test di installazione end-to-end (Locale + Docker)
Installazione dello strumento uv locale + esecuzione dello script (usa una HOME temporanea):```bash
HATE_CRACK_RUN_E2E=1 uv run pytest tests/test_e2e_local_install.py -v
Installazione/esecuzione end-to-end basata su Docker (con cache tramite Dockerfile.test):```bash
HATE_CRACK_RUN_DOCKER_TESTS=1 uv run pytest tests/test_docker_script_install.py -v
The Docker E2E test also downloads a small subset of rockyou and runs a basic
hashcat crack to validate external tool integration.
Lima VM end-to-end test (macOS only):
Prerequisites: [Lima](https://lima-vm.io/) and `rsync` must be installed.```bash
brew install lima
La VM di test viene configurata automaticamente con tutte le dipendenze Linux (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
This test validates installation and execution within a lightweight Linux VM on macOS.
### Test Structure
- **tests/test_hashview.py**: Suite di test completa per la classe HashviewAPI con risposte API simulate, che include:
- Elenco clienti e validazione dei dati
- Test di autenticazione e autorizzazione
- Funzionalità di caricamento degli hashfile
- Workflow completo di creazione dei job
Tutti i test utilizzano chiamate API simulate, quindi possono essere eseguiti senza connettività a un server Hashview.
-------------------------------------------------------------------
(1) Crack rapido
(2) Crack estensivo con metodologia Pure_Hate
(3) Attacco a forza bruta
(4) Attacco Top Mask
(5) Attacco Fingerprint
(6) Attacchi Combinator
(7) Attacco ibrido
(8) Crack a forza bruta con maschere Top 100 di Pathwell
(9) Attacco PRINCE
(10) Metodologia Bandrel
(11) Attacco Loopback
(12) Attacco LLM
(13) Attacco OMEN
(14) Attacco con maschera ad hoc
(15) Attacco a forza bruta Markov
(16) Attacco N-gram
(17) Attacco a permutazione
(18) Attacco con regole casuali
(19) Attacco a passphrase Combipow
(20) Attacco PCFG
(21) Attacco PRINCE-LING
(22) Attacco Spoonman
(23) Attacco Rosetta
(24) Forza bruta con Corporate Masks
(25) Attacco Smart Mask
(80) Strumenti per wordlist
(81) Strumenti per file di regole
(82) Notifiche
(93) Rigenera .out dal file POT
(94) Hashview API
(95) Analizza hash con Pipal
(96) Esporta output in formato Excel
(97) Visualizza hash craccati
(98) Visualizza README
(99) Esci
Seleziona un'attività:```
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.
Which rule(s) would you like to run? (1) best64.rule (2) d3ad0ne.rule (3) T0XlC.rule (4) dive.rule (99) YOLO...run all of the rules Enter Comma separated list of rules you would like to run. To run rules chained use the + symbol. For example 1+1 will run best64.rule chained twice and 1,2 would run best64.rule and then d3ad0ne.rule sequentially. Choose wisely:```
Runs several attack methods provided by Martin Bos (formerly known as pure_hate):
hcatWordlists with best64.rulerockyou.txt with d3ad0ne.rulerockyou.txt with T0XlC.rulerockyou.txt with chained combinator.rule and InsidePro-PasswordsPro.rule rulesBrute forces all characters with the choice of a minimum and maximum password length.
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).
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).
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. For each pattern found, runs a targeted -a 3 mask attack (using the exact observed literal text and an inferred charset for the varying part) against the full remaining hash list, so other accounts sharing that stem get swept up even though brute-forcing the stem itself was never tried. Prompts once, before the attack starts, for an optional candidate-count guardrail (default 50,000,000,000; 0 disables it).
https://hashcat.net/wiki/doku.php?id=combinator_attack
Runs a combinator attack using the "rockyou.txt" wordlist.
https://hashcat.net/wiki/doku.php?id=hybrid_attack
Runs a brute force attack using the top 100 masks from KoreLogic: https://blog.korelogic.com/blog/2014/04/04/pathwell_topologies
https://hashcat.net/events/p14-trondheim/prince-attack.pdf
Runs a PRINCE attack using wordlists/rockyou.txt
Runs a continuous combinator attack using random wordlists from the configured wordlists directory for the left and right sides.
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 - _ , + . &
https://jeffh.net/2018/04/26/combinator_methods/
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.
config.json entry (bandrel_common_basedwords)bandrelmaxruntime in config.jsonhttps://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.
Uses a local Ollama instance 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.
http://localhost:11434, override with OLLAMA_HOST in .env or the environment) with the model already pulled — hate_crack does not auto-pullqwen2.5:32b).env (see Ollama Configuration below)ollamaAutoResearch: false<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)ollamaTimeout so a model stuck loading into VRAM reports a timeout instead of hangingPattern 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.
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<hashfile>.llm_patterns/ as basewords.txt and rules.rule — per-run scratch, laid out like .spoonman/ and removed on exitUses 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.
omenMaxCandidates)~/.hate_crack/omen/ for persistence across sessionsOpens an interactive submenu with six combinator attack variants (formerly at menu keys 10-12). Consolidates related attacks for cleaner menu organization:
combinator3.bin, generating all word1+word2+word3 combinations piped to hashcatcombinatorX.bin with optional --sepFill separator character between word segmentsRuns hashcat mask attack (mode 3) with a user-specified custom mask string. Allows fine-grained control over character-set brute forcing.
?u?l?l?l?d?d for uppercase + lowercase + lowercase + lowercase + digit + digit)-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?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 undefinedGenerates password candidates using Markov chain statistical models. Similar to OMEN but simpler and faster.
.hcstat2 Markov table from previous sessions (with option to reuse, regenerate, or cancel).out file) as training data--increment flag to test lengths in sequenceGenerates n-gram candidates from a corpus file using ngramX.bin from hashcat-utils and pipes them into hashcat.
Generates all character permutations of each word in a targeted wordlist and pipes them to hashcat via permute.bin from hashcat-utils.
permute.bin < wordlist | hashcat pipeline patternGenerates 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.
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.
-s flag) to insert spaces between words in each combinationUses 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.
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.pcfgRuleset in config.json (default DEFAULT), read from pcfg_cracker/Rules/<name>/pcfgMaxCandidates (default 50,000,000)trainer.py and point pcfgRuleset at the resulting ruleset nameUses 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.
pcfg_cracker submodule and a trained ruleset directory, same as the PCFG attack<hcatOptimizedWordlists>/pcfg_prince_ling_<ruleset>.txt and reused across sessionspcfgPrinceLingMaxCandidates (default 10,000,000)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.
<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<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 cleanupMines 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:
hcatDebugLogPath newest-first with their sizes; pick one, pick all of them (up to 20), or type a path to a log from elsewhere<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<hash file>.hcmask, and runs a -a 3 hashcat mask attack against themStatistical 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.
-O flag) for faster crackingA 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.
All binaries are in hate_crack/hashcat-utils/bin/.
Preprocesses hashcat rule files using cleanup-rules.bin and rules_optimize.bin from hashcat-utils, and downloads rule files from Hashmob.net.
cleanup-rules.bin. Useful after combining rule files or downloading rules from external sources.rules_optimize.bin. Reduces rule file size and improves cracking speed.rulesDirectory.The three preprocessing operations read from an input file and write to a separate output file (original is never modified).
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.
Powered by HashcatRosetta (https://github.com/bandrel/HashcatRosetta), this feature analyzes hashcat rule files to provide detailed insights into rule composition and complexity.
Downloads wordlists from Hashmob.net's collection of cracked passwords and commonly used wordlists.
Interactive menu for downloading and managing wordlists from Weakpass.com via BitTorrent.
The full, per-release changelog now lives in CHANGELOG.md.
hate_crack/username_detect.py: rileva i file di input username:hash per decidere se usare --username di hashcat.hate_crack/formatting.py, hate_crack/progress.py: helper per la formattazione dell'output e la visualizzazione dell'avanzamento.hate_crack/main.py: implementazione principale della CLI..out--maxruntime <SECONDS>: Sostituisci il tempo massimo di esecuzione.--bandrel-basewords <PATH>: Sostituisci il file basewords di bandrel.--update: Aggiorna all'ultima release e reinstalla. Passa il checkout al ramo main se si trova su un altro branch, poiché i tag di release vivono lì.--nightly: Aggiorna invece all'ultima nightly, dal ramo nightly-dev. Le nightly hanno superato la CI ma non fanno parte di una release tagliata. Può anche essere scritto come --update --nightly.--no-optimized-kernel (o --no-optimize): Non passare mai -O a hashcat per l'intera esecuzione. Ignora optimizedKernelAttacks in config.json e rimuove qualsiasi -O impostato in hcatTuning. Non viene scritto nulla nella configurazione, quindi si applica solo a questa esecuzione. Con un sottocomando, posizionalo prima del sottocomando: ./hate_crack.py --no-optimize quick hashes.txt 1000 --wordlist words.txt.--debug: Abilita il logging di debug (scrive su stderr).--update |
main |
| L'ultima release tagliata. È quella predefinita e quella offerta dal controllo all'avvio. |
| Nightly | --nightly | nightly-dev | Il lavoro che ha superato la CI ma non è stato ancora rilasciato. |
.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--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 alikecoverage.txt: 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$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| 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 |