
Uno strumento per automatizzare le metodologie di cracking tramite Hashcat del team TrustedSec.
```
___ ___ __ _________ __
/ | \_____ _/ |_ ____ \_ ___ \____________ ____ | | __
/ ~ \__ \\ __\/ __ \ / \ \/\_ __ \__ \ _/ ___\| |/ /
\ Y // __ \| | \ ___/ \ \____| | \// __ \\ \___| <
\___|_ /(____ /__| \___ >____\______ /|__| (____ /\___ >__|_ \
\/ \/ \/_____/ \/ \/ \/ \/
```
## Installazione
L'installazione da sorgente è l'unico percorso supportato. hate_crack **non** è
distribuito su PyPI: `pip install hate-crack` risolve a un placeholder `0.0.0`
che fallisce di proposito e rimanda qui. Il nome è riservato solo affinché nessun altro
possa pubblicare un clone sotto di esso — vedi
[`packaging/pypi-placeholder/`](https://github.com/trustedsec/hate_crack/blob/main/packaging/pypi-placeholder).
### 1. Installare hashcat
Hashcat deve essere installato e disponibile nel PATH:
Ubuntu/Kali:
```bash
sudo apt-get install -y hashcat
```
macOS (Homebrew):
```bash
brew install hashcat
```
Oppure scarica un binario precompilato da https://hashcat.net/hashcat/ e imposta `hcatPath` in `config.json` alla sua posizione.
### 2. Scarica hate_crack
Clona con i sottomoduli (richiesto 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 i sottomoduli, inizializzali:
```bash
git submodule update --init --recursive
```
Poi personalizza la configurazione se necessario. hate_crack utilizza due file di configurazione, ognuno dei quali possiede un insieme distinto di impostazioni:
- **`config.json`** — percorsi delle wordlist, maschere, regole, tuning, potfile, percorso di hashcat, limiti dei candidati, toggle delle notifiche, valori predefiniti delle preferenze 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`.
La linea di demarcazione è 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 con diff e inserire nelle tue note. Ecco anche perché le *credenziali* Pushover sono in `.env` mentre i *toggle* di attivazione/disattivazione di Pushover sono in `config.json` — i toggle 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 indicando 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 poiché i percorsi predefiniti funzionano out-of-the-box.
`config.json` è permanente e di prima classe — non è deprecato e non esiste una tempistica di rimozione per esso. Solo le impostazioni di integrazione sono state spostate.
**Stai aggiornando da un singolo `config.json`?** hate_crack lo migra per te alla prima esecuzione: le impostazioni di integrazione vengono copiate in un nuovo `.env` con permessi `0600`, poi rimosse da `config.json` in modo che i due file non le rivendichino entrambi. Stampa quali chiavi sono state spostate (mai i loro valori) e salva il tuo originale come `config.json.pre-split.bak` prima di modificarlo. Tutto il resto in `config.json` viene lasciato esattamente com'era, ordine delle chiavi incluso.
**Prima esecuzione:** hate_crack crea entrambi i file per te, quindi non c'è nulla da fare. Per configurare `.env` manualmente, invece, copia il template tracciato:
```bash
cp .env.example .env
chmod 600 .env
```
`.env.example` è committato e viene distribuito con ogni chiave di credenziale vuota. `.env` stesso non deve **mai** essere committato — è gitignored, insieme alle sue solite varianti di backup, e hate_crack lo crea sempre con modalità `0600` (solo lettura/scrittura per il proprietario). `.env.example` è generato dallo schema; rigeneralo 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 OS 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 di soli 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 manualmente le dipendenze:**
### Dipendenze esterne
Queste sono necessarie per alcuni flussi di download/estrazione:
- `7z`/`7za` (p7zip) — utilizzato per estrarre archivi `.7z`.
- `transmission-daemon` / `transmission-remote` — utilizzato per scaricare i torrent 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
```
-------------------------------------------------------------------
## Struttura del progetto
La logica principale è ora suddivisa in moduli sotto `hate_crack/`:
- `hate_crack/cli.py`: helper argparse e override della configurazione.
- `hate_crack/api.py`: integrazioni Hashview, Weakpass e Hashmob (download/menu/helper).
- `hate_crack/attacks.py`: gestori degli attacchi da menu.
- `hate_crack/corpus_stats.py`: statistiche sulle password dell'intero corpus utilizzate 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, corpus_stats e 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 singolo crack).
- `hate_crack/username_detect.py`: rileva i file di input `username:hash` per decidere l'uso di `--username` di hashcat.
- `hate_crack/formatting.py`, `hate_crack/progress.py`: helper per la formattazione dell'output e la visualizzazione del progresso.
- `hate_crack/main.py`: implementazione principale della CLI.
Il file di primo livello `hate_crack.py` rimane il punto di ingresso principale e orchestra questi moduli.
-------------------------------------------------------------------
## Riferimenti e ringraziamenti
Questo progetto dipende da e si ispira a numerosi progetti e servizi esterni. Grazie a:
- Hashview (http://github.com/hashview/)
- Weakpass (https://weakpass.com)
- Hashmob (https://hashmob.net)
-------------------------------------------------------------------
## Utilizzo
Dopo l'installazione con `make`, esegui hate_crack da qualsiasi posizione:
```bash
hate_crack
# or with arguments:
hate_crack <hash_file> <hash_type> [options]
```
In alternativa, esegui tramite `uv`:
```bash
uv run hate_crack.py <hash_file> <hash_type>
```
### Esegui come strumento (consigliato)
Installa usando `make` dalla radice del repository - questo compila i sottomoduli e raggruppa le risorse:
```bash
cd /path/to/hate_crack
make
hate_crack
```
Il comando `make install` crea un bash shim in `~/.local/bin/hate_crack` che viene eseguito dalla directory del repo, così config e asset vengono sempre trovati indipendentemente dalla directory di lavoro corrente.
La config viene cercata anche in:
- La root del repo e la directory del pacchetto
- `~/.hate_crack`
**Nota:** Il `hcatPath` in `config.json` è solo per la posizione del binario 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`.
### Esecuzione come script
Lo script usa uno shebang `uv`. Rendilo eseguibile ed eseguilo:
```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 avviare un singolo attacco direttamente, bypassando il menu. Il nome dell'attacco è il primo argomento, seguito dal file di hash e dal tipo di hash di hashcat. I prompt di preelaborazione (filtro degli account computer, brute force con LM per primo, deduplicazione degli account duplicati) accettano automaticamente i 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 di hash mancante, tipo di hash non numerico, wordlist mancante o nome di regola 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
```
La maggior parte degli attacchi del menu è disponibile allo stesso modo. Questi non richiedono
nulla oltre al file di hash e al tipo di hash:
```bash
hate_crack fingerprint hashes.txt 1000
hate_crack pathwell hashes.txt 1000
hate_crack prince hashes.txt 1000
hate_crack pcfg hashes.txt 1000
hate_crack princeling hashes.txt 1000
hate_crack smartmask hashes.txt 1000
hate_crack corporate hashes.txt 1000
hate_crack combinator hashes.txt 1000 # configured wordlists
hate_crack hybrid hashes.txt 1000 # configured wordlists
```
Ognuno accetta anche le impostazioni richieste dalla propria voce di menu:
```bash
# Fingerprint, tuned: escalate to 24-character fragments and cap the keyspace
hate_crack fingerprint hashes.txt 1000 --max-expander-len 24 \
--run-hybrid-on-expanded --keyspace-limit 50000000000
# Skip the fragment/wordlist combination step entirely
hate_crack fingerprint hashes.txt 1000 --no-dictionary-wordlist
# Override the configured wordlists (combinator needs at least two).
# Two wordlists use combinator, three use combinator3, more -- or any
# --separator -- use combinatorX, matching what the menu does.
hate_crack combinator hashes.txt 1000 --wordlist first.txt second.txt
hate_crack combinator hashes.txt 1000 --wordlist a.txt b.txt c.txt
hate_crack combinator hashes.txt 1000 --wordlist a.txt b.txt --separator -
hate_crack hybrid hashes.txt 1000 --wordlist rockyou.txt
# Corporate masks, lengths 8-12 only
hate_crack corporate hashes.txt 1000 --min 8 --max 12
# Smart mask, skipping templates over 10 billion candidates
hate_crack smartmask hashes.txt 1000 --keyspace-limit 10000000000
```
Il resto prende l'unico input richiesto dalla voce di menu:
```bash
# Bandrel methodology (comma-separate multiple companies)
hate_crack bandrel hashes.txt 1000 --company "Acme,Acme Corp"
# Permutation attack over a short targeted wordlist
hate_crack permute hashes.txt 1000 --wordlist names.txt
# Ad-hoc mask -- a literal mask or a .hcmask file, optionally incrementing
hate_crack adhocmask hashes.txt 1000 --mask '?u?l?l?l?d?d'
hate_crack adhocmask hashes.txt 1000 --mask masks/corporate.hcmask
hate_crack adhocmask hashes.txt 1000 --mask '?a?a?a?a?a?a?a?a' \
--increment-min 4 --increment-max 8
hate_crack adhocmask hashes.txt 1000 --mask '?a?a?a?a' --increment
# N-gram candidates from a corpus
hate_crack ngram hashes.txt 1000 --corpus corpus.txt --group-size 3
# Combipow passphrases (wordlist capped at 63 lines: it generates 2^n-1)
hate_crack combipow hashes.txt 1000 --wordlist words.txt
hate_crack combipow hashes.txt 1000 --wordlist words.txt --no-spaces
# Spoonman: basewords and rules derived from a corpus of known passwords
hate_crack spoonman hashes.txt 1000 --corpus previous-engagement.txt
hate_crack spoonman hashes.txt 1000 --corpus previous.txt --rule-coverage 95
# --rule-coverage accepts 50, 75, 95 or 99 -- the only capped rule files
# derived. Omit it for the full rule set.
# OMEN -- requires a model trained beforehand from the interactive menu
hate_crack omen hashes.txt 1000 --max-candidates 1000000
# Loopback: re-run rules against the plaintexts already cracked
hate_crack loopback hashes.txt 1000 --rules best64.rule
```
`fingerprint` è l'unico comando la cui forma nuda non è identica alla sua voce
di menu: l'opzione 5 del menu esegue sempre i passaggi ibridi su frammenti
espansi, mentre il sottocomando usa per impostazione predefinita il valore
predefinito di `hcatFingerprint`, ovvero disattivato. Passa
`--run-hybrid-on-expanded` per corrispondere al menu.
Cinque voci di menu sono ancora solo interattive, perché richiedono input che un
singolo flag non può trasportare: Markov brute force, Random Rules, l'attacco
Rosetta, l'attacco LLM e la metodologia Extensive Pure_Hate (un orchestratore
sugli altri piuttosto che un singolo attacco).
#### Codici di uscita
| Codice | Significato |
|---|---|
| `0` | L'attacco è stato eseguito |
| `1` | Input non valido — file hash o wordlist mancante, tipo di hash non numerico, nome file di regole sconosciuto, argomento fuori intervallo |
| `2` | Sottocomando sconosciuto — questa build di hate_crack non lo possiede |
| `3` | Solo con `--exit-code-on-skip`: la copertura aveva già visto ogni passaggio, quindi non è stato lanciato nulla |
L'uscita `2` e l'uscita `3` sono ciò che permette a un driver scriptato di
distinguere "questa versione non può eseguire quell'attacco" e "era ridondante"
da "è stato eseguito e non ha trovato nulla".
`--exit-code-on-skip` è opt-in, così abilitare la copertura non inizia a far
fallire harness che la precedono.
-------------------------------------------------------------------
## Risoluzione dei problemi
### Errore: "would clobber existing tag" durante l'aggiornamento
Un clone più vecchio può rifiutarsi di aggiornarsi, 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 essere committati, il che ha assegnato
a ogni commit un nuovo ID; i tag di un clone più vecchio puntano quindi a oggetti che questo
repository non contiene più, e git rifiuta di spostare un tag che possiede già.
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 e le modifiche locali nel
checkout, quindi se hai personalizzato qualcosa tracciato da git (al contrario di
`config.json`, che non è tracciato), committalo prima su un branch:
```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'updater integrato funziona normalmente. Le versioni precedenti alla 2.18 non potevano eseguire questo
recupero da sole, motivo per cui deve essere fatto manualmente una volta.
### Errore: la directory di build non esiste
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.
**Comprendere i percorsi:**
- `hcatPath` in config.json → punta alla **posizione del binario hashcat** (opzionale, può essere nel PATH)
- `hashcat-utils/` e `princeprocessor/` → inclusi nel pacchetto da `make install`
**Soluzione:**
Reinstalla 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ò utilizzare i valori predefiniti senza personalizzazioni:
- `hcatWordlists`: `./wordlists` (relativo alla radice del repo o HOME/.hate_crack)
- `hcatOptimizedWordlists`: `./optimized_wordlists` (directory utilizzata da Quick Crack; se non trovata, ricade su `hcatWordlists`)
- `rules_directory`: `./hashcat/rules` (include le regole del sottomodulo)
- `hcatTuning`: `` (stringa vuota - nessun flag di tuning predefinito)
**Esempi 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 proprio di quella 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: **radice del repo**, poi la **directory del pacchetto installato**, poi **`~/.hate_crack`**. Vince la prima corrispondenza; è normale che i due file provengano da directory diverse.
- Alla prima esecuzione, entrambi vengono creati — `config.json` da `config.json.example`, `.env` dai valori predefiniti integrati. Se un vecchio `config.json` contiene ancora chiavi di integrazione, vengono copiate nel nuovo `.env` e hate_crack ti indica quali eliminare da `config.json`; non modifica mai quel file da solo.
- 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 quelle due righe prima di fare debug di un'impostazione che "non ha effetto". Esistono a causa di due trappole nell'ordine di ricerca:
- **Un checkout ha precedenza sulla tua home directory.** La radice del repo viene cercata per prima, quindi un `.env` o `config.json` presente in *qualsiasi* checkout da cui esegui lo strumento ha la meglio su quello in `~/.hate_crack` — ed eseguire lo strumento da un checkout è esattamente ciò che crea quei file lì in primo luogo. Se questo dovesse mai oscurare una vera configurazione in `~/.hate_crack`, hate_crack ora lo segnala con una terza riga `[!]` che nomina entrambi i percorsi — considera quella riga come "il file sotto viene ignorato", non come una seconda configurazione altrettanto valida.
- **La directory di lavoro corrente non viene mai cercata.** Un `.env` nella directory in cui ti trovi viene ignorato, deliberatamente: le directory di engagement sono piene di file che nessuno intendeva come configurazione. Mettilo nella radice del repo o in `~/.hate_crack`.
### Errore: merge with ref 'refs/heads/master' but no such ref was fetched
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
```
-------------------------------------------------------------------
### Target Makefile
**Predefinito (installazione completa)** - compila i sottomoduli, installa le dipendenze e installa lo strumento:
```bash
make
# or explicitly:
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 scaricato le modifiche):
```bash
make update
```
**Disinstallazione** - rimuove le dipendenze del sistema operativo e lo strumento:
```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
```
**Report di copertura:**
```bash
make coverage
```
**Pulisci gli artefatti di build/test:**
```bash
make clean
```
## Sviluppo
### Configurazione dell'ambiente di sviluppo
Installa il progetto con le dipendenze opzionali di sviluppo (include linter e strumenti di testing):
```bash
make dev-install
```
### Esecuzione di Linter e Controlli di Tipo
Prima di effettuare il push delle 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
```
O con pytest:
```bash
uv run pytest --cov=hate_crack
```
### Git Hooks (prek)
Gli hook Git 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
```
Questo installa gli hook definiti in `prek.toml` usando lo schema TOML
local-repo di pre-commit:
- **pre-push** (hook locali): ruff, ruff-format, ty, pytest, pytest-lima, bandit
- **pre-commit** (da `pre-commit/pre-commit-hooks`): trailing-whitespace,
end-of-file-fixer, check-yaml, check-merge-conflict, check-added-large-files,
detect-private-key
Gli auto-fixer di pre-commit riscrivono i file sul posto, quindi riesegui lo stage e committa di nuovo
dopo che sono stati eseguiti.
Nota: prek 0.3.3 si aspetta `repos = [...]` al livello superiore. Il vecchio formato `[hooks.<stage>] commands = [...]` non è supportato.
### Navigazione dei menu con i tasti freccia
I menu usano di default la classica selezione numerata con `print()` + `input()`, che
accetta chiavi complete a più cifre.
Per abilitare la navigazione con i tasti freccia tramite `simple-term-menu`, imposta
`HATE_CRACK_ARROW_MENU=1`. In quella modalità puoi spostarti con i tasti
freccia oppure digitare il numero dell'opzione (anche a più cifre come `99`) e
premere Invio. Digitare qualsiasi altra cosa filtra la lista. La modalità con i tasti freccia richiede anche
un TTY, quindi resta disattivata quando l'output è reindirizzato tramite pipe.
I selettori che stampano una lista e poi accettano input digitato (wordlist, regole, la
lista Weakpass, wordlist e ID delle regole di Hashview) accettano Su/Giù su ogni backend,
senza `HATE_CRACK_ARROW_MENU`. Su inserisce l'ultima chiave elencata, Su di nuovo
quella precedente, Giù torna indietro; puoi comunque digitare un numero, un percorso o una lista
come `1,3`. Un `,`, `+` o `-` digitato subito dopo una chiave inserita con le frecce
la estende. Con i backend `plain` e `rich` questo funziona caricando
le chiavi elencate nella cronologia di readline per quel singolo prompt, così la tua cronologia
viene ripristinata in seguito e non è raggiungibile dall'interno di un prompt di lista.
### Dipendenze di sviluppo
Il gruppo opzionale `[dev]` include:
- **ty** - Controllore statico dei tipi
- **ruff** - Linter e formattatore Python veloce
- **pytest** - Framework di testing
- **pytest-cov** - Report di copertura
-------------------------------------------------------------------
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 da riga di comando di Hashview.
- `--weakpass`: Scarica le wordlist da Weakpass.
- `--rank`: Mostra solo le wordlist Weakpass con un tier specifico (0=tutti, -1=tier S/A/B). Rank: 7=S, 6=A, 5=B, 4=C, 3=D, 2=E, 1=F.
- `--hashmob`: Scarica le wordlist da Hashmob.net.
- `--hashmob-masks`: Scarica le mask 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>`: Sovrascrive le directory delle wordlist.
- `--pipal-path <PATH>`: Sovrascrive il percorso di pipal.
- `--restore-potfile`: Ricostruisce `<hashfile>.out` dal file POT di hashcat all'avvio, sostituendo qualsiasi contenuto esistente, poi prosegue nel menu normale. Senza questo flag la ricerca nel POT viene eseguita solo quando `.out` non esiste già. L'opzione 93 del menu fa la stessa cosa su richiesta, con un prompt di conferma.
- `--maxruntime <SECONDS>`: Sovrascrive il tempo massimo di esecuzione.
- `--bandrel-basewords <PATH>`: Sovrascrive il file bandrel basewords.
- `--update`: Aggiorna all'ultima release e reinstalla. Passa il checkout a `main` se si trova su un altro branch, poiché i tag di release risiedono lì.
- `--nightly`: Aggiorna invece all'ultima nightly, dal branch `nightly-dev`. Le nightly hanno superato la CI ma non fanno parte di una release pubblicata. Può anche essere scritto `--update --nightly`.
- `--no-optimized-kernel` (o `--no-optimize`): Non passa mai `-O` a hashcat per l'intera esecuzione. Sovrascrive `optimizedKernelAttacks` in `config.json` e rimuove qualsiasi `-O` che hai inserito in `hcatTuning`. Nulla viene riscritto nel config, quindi si applica solo a questa esecuzione. Con un sottocomando, mettilo prima del sottocomando: `./hate_crack.py --no-optimize quick hashes.txt 1000 --wordlist words.txt`.
- `--debug`: Abilita il logging di debug (scrive su stderr).
### Integrazione con Hashview
hate_crack si integra con Hashview per la gestione centralizzata degli hash e il cracking distribuito.
#### Menu interattivo
Per accedere al menu interattivo di Hashview:
```bash
hate_crack.py --hashview
```
Opzioni del menu:
- **(1) Upload Cracked Hashes** - Carica i risultati decifrati dalla sessione corrente su Hashview
- **(2) Upload Wordlist** - Carica un file wordlist su Hashview
- **(3) Download Wordlist** - Scarica una wordlist da Hashview
- **Download Rule** - Scarica un file di regole da Hashview (decompresso in testo semplice, pronto per `hashcat -r`). Inserisci `a` (o `all`) al prompt dell'ID regola per scaricare tutte le regole elencate invece di una sola
- **Download All Rules** - Scarica tutti i file di regole elencati da Hashview in un'unica operazione; gli errori relativi alle singole regole vengono segnalati senza interrompere le altre
- **(4) Download Left Hashes** - Scarica gli hash rimanenti non decifrati (chiede se passare alla decifratura)
- **(5) Download Found Hashes** - Scarica gli hash già decifrati con le password in chiaro (per riferimento/analisi)
- **(6) Upload Hashfile and Create Job** - Carica un nuovo hashfile e crea un job di decifratura
- **(99) Back to Main Menu** - Torna al menu principale
**Importante: Download Found vs Download Left**
- **Download Left Hashes (4)**: Scarica gli hash non decifrati che necessitano di decifratura. Si unisce automaticamente a eventuali hash trovati, se disponibili, e chiede se passare a questo hashfile per la decifratura.
- **Download Found Hashes (5)**: Scarica gli hash già decifrati nel formato hash:cleartext. Questi sono per riferimento e non possono essere ulteriormente decifrati. Non viene mostrato alcun prompt di cambio.
#### Interfaccia a riga di comando
Le operazioni di Hashview possono essere eseguite anche tramite riga di comando:
Carica gli hash decifrati:
```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 <wordlist>.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 rimasti (hash non craccati da craccare):
```bash
hate_crack.py --hashview download-left --customer-id 1 --hashfile-id 123
```
Scarica gli hash trovati (hash già craccati con testo in chiaro):
```bash
hate_crack.py --hashview download-found --customer-id 1 --hashfile-id 123
```
Carica il file di 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 nel file `.env` (sono impostazioni di integrazione, quindi non risiedono in `config.json`):
```
HASHVIEW_URL=https://hashview.example.com
HASHVIEW_API_KEY=your-api-key-here
HASHVIEW_VERIFY_TLS=true
```
`HASHVIEW_VERIFY_TLS` è impostato per impostazione predefinita su `true`: hate_crack verifica il certificato TLS del server Hashview, e la connessione a un Hashview con un certificato autofirmato o emesso da una CA interna fallirà finché quel certificato non sarà considerato attendibile (aggiungilo al trust store del tuo sistema, oppure usa un certificato emesso da una CA di cui il tuo sistema si fida già). Se ciò non è possibile, imposta `HASHVIEW_VERIFY_TLS=false` -- hate_crack stamperà un avviso di una riga che indica l'host a ogni avvio di processo quando la verifica è disattivata, poiché disattivarla rimuove la protezione contro un server contraffatto o un attaccante on-path che intercetta la connessione.
#### Configurazione LLM
L'LLM Attack (opzione 12) e il Rosetta Mask Attack (opzione 23) generano i loro candidati con un modello locale. Configura il modello, la finestra di contesto e il timeout delle richieste in `.env`:
```
LLM_BACKEND=ollama
OLLAMA_MODEL=qwen3:4b-instruct
OLLAMA_NUM_CTX=8192
OLLAMA_TIMEOUT=300
```
**Le chiavi `OLLAMA_*` riportate di seguito si applicano a ogni backend, non solo a Ollama.** Mantengono quel prefisso perché `OLLAMA_HOST` è la stessa variabile letta dalla CLI di Ollama stessa, e rinominarle romperebbe ogni `.env` esistente senza alcun guadagno funzionale — un server vLLM o compatibile con OpenAI vuole lo stesso host, modello, timeout, contesto e parametri di campionamento con gli stessi nomi. `LLM_BACKEND` seleziona solo il modo in cui la richiesta viene strutturata.
- **`OLLAMA_MODEL`** — Il modello Ollama usato per la generazione dei candidati (predefinito: `qwen3:4b-instruct`). L'attacco LLM usa output strutturato (JSON), quindi scegli un modello con un buon supporto a tool/JSON.
- **`OLLAMA_NUM_CTX`** — Dimensione della finestra di contesto per il modello (predefinito: `8192`). Era `2048` prima dell'introduzione delle statistiche del corpus, valore troppo piccolo per contenere il prompt che gli veniva fornito: 500 plaintext campionati occupano all'incirca 2.000–3.500 token prima del system prompt e della risposta, quindi Ollama troncava silenziosamente parte del campione che il sampler aveva distribuito con cura su tutto il file.
---
[Read more](https://github.com/trustedsec/hate_crack)