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

Instalação

Instalar a partir do código-fonte é o único caminho suportado. hate_crack não é distribuído no PyPI: pip install hate-crack resolve para um placeholder 0.0.0 que falha de propósito e aponta de volta para cá. O nome é mantido apenas para que ninguém mais possa publicar um similar sob ele — veja packaging/pypi-placeholder/.

1. Instalar o hashcat

O Hashcat deve estar instalado e disponível no seu PATH:

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

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

Or baixe um binário pré-compilado de https://hashcat.net/hashcat/ e defina hcatPath em config.json para o seu local.

2. Baixar o hate_crack

Clone com submódulos (necessário para hashcat-utils, princeprocessor, pcfg_cracker, Corporate_Masks e, opcionalmente, omen):```bash git clone --recurse-submodules https://github.com/trustedsec/hate_crack.git cd hate_crack

Se você clonou sem submódulos, inicialize-os:```bash
git submodule update --init --recursive

Então personalize a configuração se necessário. O hate_crack usa dois arquivos de configuração, cada um com um conjunto distinto de configurações:

config.json — caminhos de wordlist, máscaras, regras, ajustes, potfile, caminho do hashcat, limites de candidatos, alternâncias de notificação, padrões de preferência de CLI (35 configurações).
.env — apenas configurações de integração de terceiros: credenciais do Hashview e Hashmob, credenciais do Pushover, Ollama e pipal (14 configurações). Não rastreado pelo git, criado no modo 0600.

A linha cai ali por um motivo: .env é o arquivo que pode conter segredos. Credenciais e configuração de serviços de terceiros vão no arquivo não rastreado, com permissão 0600; tudo o que o hate_crack faz localmente fica no config.json, que é seguro para compartilhar, comparar e registrar nas suas próprias anotações. É também por isso que as credenciais do Pushover estão no .env enquanto as alternâncias de ligar/desligar do Pushover estão no config.json — as alternâncias são preferências locais, não segredos.

Cada chave tem exatamente um lar. Uma chave colocada no outro arquivo é ignorada, e o hate_crack imprime um aviso nomeando o arquivo ao qual ela pertence. Qualquer chave ainda pode ser substituída para uma única execução exportando sua variável de ambiente. A maioria dos usuários pode pular esta etapa, pois os caminhos padrão funcionam imediatamente.

O config.json é permanente e de primeira classe — não está obsoleto e não há cronograma de remoção para ele. Apenas as configurações de integração foram movidas.

Atualizando a partir de um único config.json? O hate_crack o migra para você na primeira execução: as configurações de integração são copiadas para um novo .env com permissão 0600 e, em seguida, removidas do config.json para que os dois arquivos não as reivindiquem simultaneamente. Ele imprime quais chaves foram movidas (nunca seus valores) e salva seu original como config.json.pre-split.bak antes de tocá-lo. Todo o resto no config.json é deixado exatamente como estava, incluindo a ordem das chaves.

Primeira execução: o hate_crack cria ambos os arquivos para você, então não há nada a fazer. Para configurar o .env manualmente, copie o modelo rastreado:```bash cp .env.example .env chmod 600 .env

`.env.example` é enviado ao repositório e acompanha cada chave de credencial vazia. O `.env` em si **nunca** deve ser enviado — ele está no gitignore, junto com suas variações de backup usuais, e o hate_crack sempre o cria com modo `0600` (somente leitura/escrita do proprietário). O `.env.example` é gerado a partir do schema; regenere-o após alterar `hate_crack/config_schema.py` com `uv run python -m hate_crack.config_writer`.

### 3. Instalar dependências e o hate_crack

A maneira mais fácil é executar `make` (ou `make install`), que detecta automaticamente seu sistema operacional e instala:
- Dependências externas (p7zip, transmission-daemon / transmission-remote)
- Compila submódulos (hashcat-utils, princeprocessor, pcfg_cracker e, opcionalmente, omen) e faz o checkout do conjunto de máscaras Corporate_Masks apenas com dados
- Dependências Python via uv e um atalho de CLI em `~/.local/bin/hate_crack````bash
make

Isto é idempotente - ele ignora ferramentas já instaladas. Para forçar uma reinstalação limpa:```bash make reinstall

**Ou instale as dependências manualmente:**

### Dependências Externas
Estas são necessárias para determinados fluxos de download/extração:

- `7z`/`7za` (p7zip) — usado para extrair arquivos `.7z`.
- `transmission-daemon` / `transmission-remote` — usado para baixar torrents do Weakpass.

Comandos de instalação manual:

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

Em seguida, instale as dependências Python e o shim de 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

Estrutura do Projeto

A lógica principal agora está dividida em módulos sob hate_crack/:

hate_crack/cli.py: auxiliares do argparse e substituições de configuração.
hate_crack/api.py: integrações com Hashview, Weakpass e Hashmob (downloads/menus/auxiliares).
hate_crack/attacks.py: manipuladores de ataques do menu.
hate_crack/corpus_stats.py: estatísticas de senhas do corpus inteiro usadas para descrever um corpus ao LLM.
hate_crack/plaintext.py: recupera a senha de uma linha do corpus (remoção do prefixo de hash, decodificação de $HEX[...]); compartilhado pelos modos LLM, corpus_stats e rulegen.
hate_crack/llm.py: geração estruturada (JSON) de candidatos via LLM usando Atomic Agents.
hate_crack/menu.py: renderizador de menu compartilhado, incluindo navegação opcional por setas do teclado.
hate_crack/noninteractive.py: despachante para os subcomandos de ataque com script.
hate_crack/notify/: pacote de notificações (backend Pushover, rastreador por crack).
hate_crack/username_detect.py: detecta arquivos de entrada username:hash para decidir sobre o --username do hashcat.
hate_crack/formatting.py, hate_crack/progress.py: auxiliares de formatação de saída e exibição de progresso.
hate_crack/main.py: implementação principal da CLI.

O hate_crack.py de nível superior permanece como o ponto de entrada principal e orquestra esses módulos.

Referências e Agradecimentos

Este projeto depende e é inspirado por vários projetos e serviços externos. Agradecimentos a:

Uso

Após instalar com make, execute o hate_crack de qualquer lugar:```bash hate_crack

or with arguments:

hate_crack <hash_file> <hash_type> [options]

Alternativamente, execute via `uv`:```bash
uv run hate_crack.py <hash_file> <hash_type>

Executar como ferramenta (recomendado)

Instale usando make a partir da raiz do repositório - isto compila os submódulos e agrupa os assets:```bash cd /path/to/hate_crack make hate_crack

O comando `make install` cria um shim bash em `~/.local/bin/hate_crack` que é executado a partir do diretório do repositório, para que a configuração e os assets sejam sempre encontrados, independentemente do seu diretório de trabalho atual.

A configuração também é pesquisada em:
- A raiz do repositório e o diretório do pacote
- `~/.hate_crack`

**Nota:** O `hcatPath` em `config.json` é apenas para a localização do binário do hashcat (opcional se o hashcat estiver no PATH). Os assets do Hate_crack (hashcat-utils, princeprocessor, pcfg_cracker, Corporate_Masks, omen) são carregados do diretório do repositório e agrupados automaticamente pelo `make install`.

### Executar como script
O script usa um shebang `uv`. Torne-o executável e execute:```bash
chmod +x hate_crack.py
./hate_crack.py

Pode também usar Python diretamente:```bash python hate_crack.py

### Utilização não interativa / por script

Para automação, pode lançar um único ataque diretamente, contornando o menu. O nome do ataque é o primeiro argumento, seguido do ficheiro de hashes e do tipo de hash do hashcat. Os avisos de pré-processamento (filtragem de contas de computador, brute force LM em primeiro lugar, remoção de duplicados de contas) aceitam automaticamente os seus valores predefinidos neste modo. O processo termina com `0` em caso de sucesso e com valor não nulo em caso de erro (ficheiro de hashes em falta, tipo de hash não numérico, wordlist em falta ou nome de ficheiro de regra desconhecido).```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

Resolução de Problemas

Erro: "would clobber existing tag" ao atualizar

Um clone mais antigo pode se recusar a atualizar, exibindo uma longa lista de linhas como:``` ! [rejected] v2.5.0 -> v2.5.0 (would clobber existing tag)

Isto afeta clones criados antes de julho de 2026. O histórico publicado foi reescrito
então para remover alguns arquivos que nunca deveriam ter sido commitados, o que deu
a cada commit um novo ID; portanto, as tags de um clone mais antigo apontam para objetos que
este repositório não contém mais, e o git se recusa a mover uma tag que já possui.
Não há nada de errado com seu checkout e nenhum dado de cracking está em risco.

Recupere com um reset único. Isso descarta commits locais e edições no
checkout, então, se você personalizou qualquer coisa rastreada pelo git (ao contrário de
`config.json`, que não é rastreado), faça commit dela em um branch primeiro:```bash
cd /path/to/hate_crack
git fetch --tags --force origin
git checkout -B main origin/main
make install

--force aqui apenas atualiza as tags; ele não pode tocar nos seus commits. Depois disso, o atualizador integrado funciona normalmente. Versões anteriores à 2.18 não conseguiam realizar essa recuperação por conta própria, por isso ela precisa ser feita manualmente uma vez.

Erro: O diretório de build não existe

Se você vir um erro como:``` Error: Build directory /opt/hashcat/hashcat-utils does not exist. Expected to find expander at /opt/hashcat/hashcat-utils/bin/expander.

Isto significa que os assets do hate_crack não foram incluídos no pacote instalado.

**Compreendendo os caminhos:**
- `hcatPath` no config.json → aponta para a **localização do binário do hashcat** (opcional, pode estar no PATH)
- `hashcat-utils/` e `princeprocessor/` → incluídos no pacote pelo `make install`

**Solução:**
Reinstale usando o Makefile, que compila os submódulos e instala a ferramenta:```bash
cd /path/to/hate_crack  # the repository checkout
make install

Configuração padrão (config.json.example):

A maioria dos usuários pode usar os padrões sem personalização:

hcatWordlists: ./wordlists (relativo à raiz do repositório ou HOME/.hate_crack)
hcatOptimizedWordlists: ./optimized_wordlists (diretório usado pelo Quick Crack; usa hcatWordlists como fallback se não for encontrado)
rules_directory: ./hashcat/rules (inclui regras do submódulo)
hcatTuning: `` (string vazia - sem flags de ajuste padrão)

Exemplo de personalizações do 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) ... }

**Carregamento de configuração:**
- Precedência para cada chave: `os.environ` > o arquivo home da própria chave (`.env` ou `config.json`) > padrão embutido
- Chaves ausentes recorrem aos padrões embutidos; `config.json.example` documenta cada chave de `config.json`
- Ambos os arquivos são pesquisados, independentemente um do outro, nesta ordem: **raiz do repositório**, depois o **diretório do pacote instalado**, depois **`~/.hate_crack`**. A primeira correspondência vence; é normal que os dois arquivos venham de diretórios diferentes.
- Na primeira execução, ambos são criados — `config.json` a partir de `config.json.example`, `.env` a partir dos padrões embutidos. Se um `config.json` mais antigo ainda contiver chaves de integração, elas são copiadas para o novo `.env` e o hate_crack informa quais delas você deve excluir do `config.json`; ele nunca edita esse arquivo por conta própria.
- Em toda execução, o hate_crack imprime os dois arquivos que realmente carregou:  ```
  [*] config.json: /home/you/.hate_crack/config.json
  [*] .env:        /home/you/.hate_crack/.env

Leia essas duas linhas antes de depurar uma configuração que "não está surtindo efeito". Elas existem por causa de duas armadilhas na ordem de busca:

Um checkout tem precedência sobre o seu diretório inicial. A raiz do repositório é pesquisada primeiro, então um .env ou config.json em qualquer checkout de onde você executa a ferramenta vence o que está em ~/.hate_crack — e executar a ferramenta a partir de um checkout é exatamente o que cria esses arquivos lá em primeiro lugar. Se isso algum dia ofuscar uma configuração real de ~/.hate_crack, o hate_crack agora avisa com uma terceira linha [!] nomeando ambos os caminhos — trate essa linha como "o arquivo abaixo está sendo ignorado", não como uma segunda configuração igualmente válida.
O diretório de trabalho atual nunca é pesquisado. Um .env no diretório em que você está é ignorado, deliberadamente: diretórios de engajamento estão cheios de arquivos que ninguém pretendia que fossem configuração. Coloque-o na raiz do repositório ou em ~/.hate_crack.

Erro: merge com ref 'refs/heads/master' mas nenhuma ref desse tipo foi buscada

Se você vir:``` Your configuration specifies to merge with the ref 'refs/heads/master' from the remote, but no such ref was fetched.

A branch predefinida foi renomeada de `master` para `main`. Corrija com:```bash
git remote set-head origin -a
git branch -m master main
git branch --set-upstream-to=origin/main main
git pull

Alvos do Makefile

Padrão (instalação completa) - compila os submódulos, instala as dependências e instala a ferramenta:```bash make

or explicitly:

make install

Isto é idempotente - ele ignora ferramentas já instaladas.

**Forçar reinstalação limpa:**```bash
make reinstall

Atualização rápida - reconstrói os submódulos e reinstala a ferramenta (após puxar as alterações):```bash make update

**Desinstalar** - remove as dependências do SO e a ferramenta:```bash
make uninstall

Compilar apenas o hashcat-utils:```bash make hashcat-utils

**Executar testes** - lida automaticamente com HATE_CRACK_SKIP_INIT quando necessário:```bash
make test

Relatório de cobertura:```bash make coverage

**Limpar artefatos de build/teste:**```bash
make clean

Desenvolvimento

Configurando o Ambiente de Desenvolvimento

Instale o projeto com as dependências de desenvolvimento opcionais (inclui linters e ferramentas de teste):```bash make dev-install

### Executar Linters e Verificações de Tipos

Antes de enviar alterações, execute estas verificações localmente. Use `make lint` para tudo, ou execute verificações individuais:

**Ruff (linting e formatação):**```bash
make ruff
# or manually:
uv run ruff check hate_crack tests tools packaging hate_crack.py

Auto-corrigir problemas:```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 (verificação de tipos):**```bash
make ty
# or manually:
uv run ty check hate_crack

Execute todas as verificações em conjunto:```bash make lint

### Executar Testes

Os testes detetam automaticamente quando os submódulos não estão compilados e definem `HATE_CRACK_SKIP_INIT=1` automaticamente.```bash
make test

Or execute o pytest diretamente:```bash uv run pytest -v

Com cobertura:```bash
make coverage

Ou com pytest:```bash uv run pytest --cov=hate_crack

### Git Hooks (prek)

Os Git hooks são gerenciados pelo [prek](https://github.com/j178/prek) (v0.3.3+). Instale os hooks com:```bash
prek install --hook-type pre-push --hook-type pre-commit

Isto instala os hooks definidos em prek.toml usando o esquema TOML de repositório local do pre-commit:

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

Os auto-corretores do pre-commit reescrevem os arquivos no lugar, então re-adicione ao stage e faça commit novamente após eles serem executados.

Nota: o prek 0.3.3 espera repos = [...] no nível superior. O formato antigo [hooks.<stage>] commands = [...] não é suportado.

Os menus usam por padrão a seleção clássica numerada com print() + input(), que aceita chaves completas de múltiplos dígitos.

Para ativar a navegação por setas via simple-term-menu, defina HATE_CRACK_ARROW_MENU=1. Nesse modo, apenas teclas de atalho de um único dígito funcionam; opções numeradas a partir de 10 devem ser alcançadas com as setas. O modo de setas também exige um TTY, então ele permanece desativado quando a saída é canalizada.

Dependências de Desenvolvimento

O grupo opcional [dev] inclui:

ty - Verificador de tipos estático
ruff - Linter e formatador Python rápido
pytest - Framework de testes
pytest-cov - Relatório de cobertura

Opções comuns:

--download-hashview: Baixar hashes do Hashview antes de quebrar.
--hashview: Menu interativo do Hashview para gerenciar hashes, wordlists e jobs.
--hashview --help: Mostrar opções de linha de comando do Hashview.
--weakpass: Baixar wordlists do Weakpass.
--hashmob: Baixar wordlists do Hashmob.net.
--hashmob-masks: Baixar masks do Hashmob.net.
--download-torrent <FILENAME>: Baixar um arquivo torrent específico do Weakpass.
--download-all-torrents: Baixar todos os torrents disponíveis do Weakpass a partir do cache.
--wordlists-dir <PATH> / --optimized-wordlists-dir <PATH>: Substituir diretórios de wordlists.
--pipal-path <PATH>: Substituir o caminho do pipal.
--restore-potfile: Reconstruir <hashfile>.out a partir do arquivo POT do hashcat na inicialização, substituindo qualquer conteúdo existente, e então continuar no menu normal. Sem essa flag, a consulta ao POT só é executada quando .out ainda não existe. A opção 93 do menu faz o mesmo sob demanda, com um prompt de confirmação.
--maxruntime <SECONDS>: Substituir o tempo máximo de execução.
--bandrel-basewords <PATH>: Substituir o arquivo de palavras-base do bandrel.
--update: Atualizar para a versão mais recente e reinstalar. Muda o checkout para main se estiver em outra branch, já que as tags de release ficam lá.
--nightly: Atualizar para o nightly mais recente, a partir da branch nightly-dev. Os nightlies passaram no CI, mas não fazem parte de um release cortado. Também pode ser escrito como --update --nightly.
--no-optimized-kernel (ou --no-optimize): Nunca passar -O ao hashcat durante toda a execução. Substitui optimizedKernelAttacks em config.json e remove qualquer -O que você colocar em hcatTuning. Nada é gravado de volta no config, então isso se aplica apenas a esta execução. Com um subcomando, coloque-o antes do subcomando: ./hate_crack.py --no-optimize quick hashes.txt 1000 --wordlist words.txt.
--debug: Ativar log de depuração (escreve em stderr).

Integração com Hashview

O hate_crack integra-se ao Hashview para gerenciamento centralizado de hashes e quebra distribuída.

Acesse o menu interativo do Hashview:```bash hate_crack.py --hashview

Opções do menu:
- **(1) Enviar Hashes Quebrados** - Envia resultados quebrados da sessão atual para o Hashview
- **(2) Enviar Wordlist** - Envia um arquivo de wordlist para o Hashview
- **(3) Baixar Wordlist** - Baixa uma wordlist do Hashview
- **Baixar Regra** - Baixa um arquivo de regra do Hashview (descomprimido para texto puro, pronto para `hashcat -r`)
- **Baixar Todas as Regras** - Baixa todos os arquivos de regra listados pelo Hashview de uma vez; falhas por regra são relatadas sem abortar o restante
- **(4) Baixar Hashes Restantes** - Baixa os hashes não quebrados restantes (solicita troca para quebra)
- **(5) Baixar Hashes Encontrados** - Baixa hashes já quebrados com senhas em texto claro (para referência/análise)
- **(6) Enviar Arquivo de Hash e Criar Job** - Envia novo arquivo de hash e cria um job de quebra
- **(99) Voltar ao Menu Principal** - Retorna ao menu principal

**Importante: Baixar Encontrados vs Baixar Restantes**
- **Baixar Hashes Restantes (4)**: Baixa hashes não quebrados que precisam ser quebrados. Mescla automaticamente com quaisquer hashes encontrados, se disponíveis, e solicita a troca para este arquivo de hash para quebra.
- **Baixar Hashes Encontrados (5)**: Baixa hashes já quebrados no formato hash:texto_claro. Estes são para referência e não podem ser quebrados novamente. Nenhum prompt de troca é exibido.

#### Interface de Linha de Comando

As operações do Hashview também podem ser realizadas via linha de comando:

Enviar hashes quebrados:```bash
hate_crack.py --hashview upload-cracked --file <output_file>.out --hash-type 1000

Carregar uma wordlist:```bash hate_crack.py --hashview upload-wordlist --file .txt --name "My Wordlist"

Baixe um arquivo de regras (salvo descompactado, pronto para `hashcat -r`):```bash
hate_crack.py --hashview download-rules --rules-id 4 --output best64.rule

Download hashes à esquerda (hashes não quebrados para cracking):```bash hate_crack.py --hashview download-left --customer-id 1 --hashfile-id 123

Baixar hashes encontrados (hashes já quebrados com texto claro):```bash
hate_crack.py --hashview download-found --customer-id 1 --hashfile-id 123

Carregar arquivo de hash e criar 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"

#### Configuração

Defina as credenciais do Hashview no `.env` (são definições de integração, portanto não ficam no `config.json`):```
HASHVIEW_URL=https://hashview.example.com
HASHVIEW_API_KEY=your-api-key-here

Configuração do LLM

O Ataque LLM (opção 12) e o Ataque de Máscara Rosetta (opção 23) geram seus candidatos com um modelo local. Configure o modelo, a janela de contexto e o tempo limite de solicitação no .env:``` LLM_BACKEND=ollama OLLAMA_MODEL=qwen3:4b-instruct OLLAMA_NUM_CTX=8192 OLLAMA_TIMEOUT=300

**As chaves `OLLAMA_*` abaixo se aplicam a todos os backends, não apenas ao Ollama.** Elas mantêm esse prefixo porque `OLLAMA_HOST` é a mesma variável que o próprio CLI do Ollama lê, e renomeá-las quebraria todos os `.env` existentes sem ganho funcional — um servidor vLLM ou compatível com OpenAI quer os mesmos controles de host, modelo, timeout, contexto e amostragem sob os mesmos nomes. `LLM_BACKEND` apenas seleciona como a requisição é moldada.

- **`OLLAMA_MODEL`** — O modelo Ollama usado para geração de candidatos (padrão: `qwen3:4b-instruct`). O ataque LLM usa saída estruturada (JSON), então escolha um modelo com bom suporte a ferramentas/JSON.
- **`OLLAMA_NUM_CTX`** — Tamanho da janela de contexto para o modelo (padrão: `8192`). Era `2048` antes da introdução das estatísticas de corpus, o que era pequeno demais para conter o prompt que estava sendo fornecido: 500 textos simples amostrados consomem cerca de 2.000–3.500 tokens antes do prompt do sistema e da resposta, então o Ollama truncava silenciosamente parte da amostra que o amostrador havia distribuído cuidadosamente pelo arquivo.
- **`OLLAMA_TIMEOUT`** — Segundos para aguardar uma resposta de geração antes de desistir (padrão: `300`). Aumente isso se um modelo grande ainda estiver carregando na VRAM na primeira requisição, o que pode exceder o timeout; o hate_crack imprime o timeout decorrido e o nome desta configuração quando isso ocorre.
- **`OLLAMA_MAX_SAMPLE_LINES`** — O limite abaixo do qual os modos LLM também colam os textos simples literais no prompt (padrão: `500`). Valores ≤ 0 são tratados como 500.

  Os modos derivados de corpus (**Wordlist**, **Senhas quebradas**, **Regras de padrão**) sempre descrevem o *corpus inteiro* estatisticamente — participações de palavras-base, máscaras, capitalização, comprimentos, dígitos e símbolos finais, anos — em vez de colar uma fatia dele. A agregação é limitada, então um dump de 120.000 senhas custa aproximadamente o mesmo espaço de prompt que um de 500 linhas. Quando o corpus inteiro cabe abaixo desse limite, os textos simples brutos também são incluídos, já que não há ganho em esconder um corpus pequeno do modelo.

  Isso substitui o comportamento anterior de colar uma amostra uniformemente espaçada de até `ollamaMaxSampleLines` senhas. Uma amostra de um dump grande não transmitia nenhuma informação de frequência: o modelo não conseguia distinguir uma palavra-base usada por 8% da organização de uma usada por uma única pessoa, que é exatamente o sinal que torna uma tentativa digna de ser executada.
- **`OLLAMA_NO_CLOUD`** — Quando `true`, recusa enviar qualquer coisa para fora deste host, para qualquer um dos três backends LLM (Ollama, vLLM ou um servidor genérico compatível com OpenAI). Duas verificações são controladas por esta única configuração: o Ollama faz proxy de um modelo com tag `-cloud` (`gpt-oss:120b-cloud`, `deepseek-v3.1:671b-cloud`) para ollama.com através do mesmo endpoint local que um modelo local usa, então nada na requisição parece diferente — isso é recusado pelo nome do modelo. A URL do backend configurado também é verificada: um destino que não seja loopback, privado ou link-local (e não seja `localhost` ou um nome `.local`/`.internal`/`.lan`/`.localdomain`) é recusado pelo destino, e um hostname que esta verificação não consegue resolver também é recusado, com falha segura, em vez de permitir a passagem de um destino não verificável. Os prompts do hate_crack carregam textos simples recuperados, estatísticas de corpus e o nome, setor e localização do cliente, então qualquer uma das verificações disparando significa que a requisição é recusada antes de ser construída. O padrão é `false`, então um modelo de nuvem ou servidor remoto configurado deliberadamente continua funcionando; ative-o para engajamentos onde os dados do cliente não devem sair do host.
- **`OLLAMA_AUTO_RESEARCH`** — Quando `true` (padrão), o modo **Target info** pede ao modelo local para sugerir o setor, a localização e a empresa controladora / histórico de aquisições assim que você digitar o nome da empresa, e os oferece como padrões editáveis nos prompts. Defina como `false` para sempre obter prompts em branco (útil com um modelo lento, já que a pesquisa custa uma ida e volta extra antes do ataque começar).
- **`OLLAMA_HOST`** — Onde o backend configurado está escutando. Aceita um `host:porta` simples (`theplague.lan:11434`) ou uma URL completa com esquema (`https://ollama.example.com`); de qualquer forma, a URL base é normalizada antes do uso. O padrão é `localhost:11434`, que é a porta do Ollama — um servidor vLLM ou compatível com OpenAI precisa que isso seja definido para a sua própria porta (o vLLM normalmente escuta em `:8000`). Defina-o no `.env`, ou exporte-o como uma variável de ambiente real para sobrescrever isso em uma única execução — é o mesmo nome de variável que o próprio CLI do Ollama lê.
- **`LLM_BACKEND`** — Com qual servidor compatível com OpenAI falar: `ollama` (padrão), `vllm` ou `openai` para um genérico. Todo backend fala a mesma API de chat-completions `/v1`, então isso seleciona apenas os dois detalhes de moldagem de requisição em que eles diferem: `ollama` recebe `options.num_ctx`, e `vllm` recebe `chat_template_kwargs={"thinking": false}` — sem o qual um servidor vLLM executando um parser de raciocínio roteia toda a resposta estruturada para `message.reasoning`, deixa `message.content` vazio e quebra o parsing JSON. `openai` não envia nenhum dos dois, já que `num_ctx` não tem equivalente lá. Isso **não** altera de onde vêm as configurações de host, modelo, timeout, contexto ou amostragem — essas são as chaves `OLLAMA_*` acima para todos os três.
- **`LLM_API_KEY`** — A credencial enviada ao backend configurado. O padrão é o literal `ollama`, o placeholder que o próprio servidor do Ollama ignora, então as requisições de uma instalação existente permanecem inalteradas; um valor vazio recai no mesmo placeholder porque o SDK OpenAI recusa `api_key=""`. Defina-o para o valor real se o servidor impuser um — um servidor vLLM iniciado com `--api-key` retorna 401 caso contrário.
- Garanta que o Ollama esteja em execução e o modelo baixado (`ollama pull qwen3:4b-instruct`) antes de usar o Ataque LLM — o hate_crack não baixa mais automaticamente modelos ausentes.

O ataque oferece três modos de geração:

1. **Target info** — empresa / setor / localização / empresa controladora; o modelo deriva candidatos desses detalhes.

   Depois que você digita o nome da empresa, o hate_crack pergunta ao mesmo modelo local o que ele já sabe sobre essa organização e pré-preenche os prompts de **Setor**, **Localização** e **Empresa Controladora** com as respostas, mostradas entre parênteses:   ```
   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:

Pressione Enter para aceitar uma sugestão ou digite por cima dela. Esses valores são a lembrança do modelo, não OSINT — trate-os como um ponto de partida, não como inteligência sobre o cliente. A consulta usa apenas o servidor Ollama local, portanto o nome do cliente nunca sai do host; não há chamadas web ou de API de terceiros. Se o modelo não reconhecer a organização (o caso comum para clientes pequenos), ele não retorna nada e você recebe prompts em branco simples: ``` Company name: Acme Rail Services Industry: Location: Parent company / acquired by:

Uma falha de pesquisa — timeout, Ollama não em execução, resposta vazia — nunca bloqueia o ataque; apenas recorre a prompts em branco. Defina `ollamaAutoResearch` como `false` para ignorar a pesquisa por completo.
2. **Wordlist** — derivar palavras-base a partir de uma wordlist de amostra.
3. **Senhas quebradas** — alimentar o modelo com os textos simples já recuperados nesta sessão (`<hashfile>.out`) para que ele possa inferir as próprias convenções de senha da organização alvo (palavras-base, estações do ano, anos, sufixos, leetspeak) e gerar *novos* candidatos no mesmo estilo. Esta opção só é listada depois que pelo menos um hash foi quebrado; o arquivo inteiro é analisado estatisticamente exatamente como no modo Wordlist (veja `ollamaMaxSampleLines` acima).

#### Configuração do PCFG

O Ataque PCFG (opção 20) e o Ataque PRINCE-LING (opção 21) usam o submódulo `pcfg_cracker`. Configure-os em `config.json`:```json
{
"pcfgRuleset": "DEFAULT",
"pcfgMaxCandidates": 50000000,
"pcfgPrinceLingMaxCandidates": 10000000
}

pcfgRuleset — Nome da gramática treinada a usar (padrão: DEFAULT), resolvido para pcfg_cracker/Rules/<name>/. Treine a sua própria com o trainer.py do pcfg_cracker e defina isto para o nome do ruleset.
pcfgMaxCandidates — Número máximo de candidatos que o pcfg_guesser.py emite para o ataque PCFG (padrão: 50000000).
pcfgPrinceLingMaxCandidates — Número máximo de palavras-base que o prince_ling.py escreve na wordlist base PRINCE em cache (padrão: 10000000).

Kernels otimizados (`optimizedKernelAttacks`)

A flag -O do hashcat seleciona kernels otimizados, que são substancialmente mais rápidos, mas limitam o comprimento dos candidatos (cerca de 31 caracteres, menos para alguns modos) e ignoram silenciosamente qualquer coisa mais longa. optimizedKernelAttacks em config.json lista os ataques que são executados com -O; omita um ataque da lista para o executar com kernels de comprimento total. A lista em config.json.example corresponde ao padrão integrado que se aplica quando não existe nenhum config.json.

Quatro ataques respeitam a definição, mas não são otimizados por padrão, porque alimentam candidatos que podem exceder o limite de -O — adicione-os à lista para optar por eles:

hcatNgramX, hcatOllama, hcatOmen, hcatLMtoNT

Para desligar -O em todo o lado numa única execução sem editar a configuração, passe --no-optimized-kernel (forma curta --no-optimize). Isto sobrepõe-se à lista para todos os ataques e também remove um -O escrito em hcatTuning, que de outra forma chegaria ao hashcat independentemente da lista.

Os nomes são correspondidos exatamente, e uma entrada não reconhecida é reportada no arranque em vez de ser ignorada. Note que os ataques que delegam noutro ataque são controlados pelo ataque em que delegam, não pelo seu próprio nome: PRINCE-LING segue hcatPrince, enquanto Spoonman, Rosetta e os modos de regras de padrão LLM seguem hcatQuickDictionary.

Monitorização da cobertura de ataques (`coverage_enabled`)

Ao longo de um envolvimento longo, o mesmo ficheiro de hashes é atacado em muitas sessões com um conjunto rotativo de wordlists, ficheiros de regras e listas de máscaras, e é fácil gastar horas a repetir terreno que já cobriu — especialmente porque a mesma linha de regra vive em mais do que um ficheiro de regras. O hate_crack regista o que já executou contra cada ficheiro de hashes e oferece-se para saltar a sobreposição.

A cobertura é registada por entrada, não por ficheiro: linhas de regra individuais e linhas .hcmask individuais, cada uma emparelhada com a wordlist contra a qual foi executada. É isto que lhe permite reconhecer que um ficheiro de regras personalizado que executa hoje repete 40 das regras que o best64.rule já cobriu na semana passada, e é também a razão pela qual uma regra só está "coberta" para a wordlist específica com que foi testada — as mesmas regras sobre um corpus diferente tentam candidatos completamente diferentes.

O ficheiro de hashes é identificado por um sha256 do seu conteúdo, pelo que a cobertura sobrevive a renomeações ou movimentos entre sessões. As wordlists são identificadas da mesma forma, com o digest memoizado contra tamanho e mtime, para que um corpus de vários gigabytes seja hasheado uma vez em vez de em cada ataque.

Só é solicitado quando há genuinamente algo para saltar:``` [*] 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]:

Responda `Y` e o hate_crack cria um ficheiro de regras temporário contendo apenas as entradas ainda não testadas; responda `n` para executar tudo na mesma. Se *todas* as entradas forem repetições, é-lhe perguntado se pretende saltar o ataque por completo, pelo que voltar a executar deliberadamente terreno já coberto nunca exige reiniciar a ferramenta.

Os ataques que nunca são filtrados são ainda registados como tendo sido executados, o que é o que lhe permite responder "já executei o PRINCE contra este alvo?".

Um ataque que seleciona vários ficheiros de regras ao mesmo tempo (Quick Crack, Loopback) faz a pergunta de salto **uma única vez para todo o lote, antecipadamente**, antes de qualquer invocação do hashcat. Essa pergunta é deliberadamente barata — não lê nem calcula o hash de nenhum dos ficheiros de regras selecionados, uma vez que um lote YOLO pode chegar a milhões de linhas e não deve esperar por isso para responder a um sim/não. Pergunta apenas ao armazenamento se este ataque já foi executado contra este ficheiro de hashes **com uma destas wordlists**; a diferença por entrada continua a ser feita de forma preguiçosa, um ficheiro de regras de cada vez, e decide o que é efetivamente saltado. Assim, um corpus novo nunca é sinalizado, mesmo quando as regras aplicadas a ele já foram todas executadas contra um diferente.

Três limites deliberados:

- **A cobertura é registada apenas quando o hashcat esgota o espaço de chaves** (exit 1). Um ctrl-C ou um erro não regista nada, e o exit 0 também não — isso significa que todos os hashes foram quebrados, o que o hashcat reporta *sem* terminar o espaço de chaves, e no caso degenerado de "todos os hashes encontrados como entradas do potfile" sem tentar um único candidato. Sub-registar apenas custa uma execução redundante mais tarde.
- **Os geradores dinâmicos de candidatos nunca são filtrados.** PRINCE, PCFG, OMEN, brute force de Markov e os modos LLM não têm um conjunto fixo para comparar, pelo que são registados como tendo sido executados e, de resto, deixados em paz. Ficheiros de regras encadeados (`-r a -r b`) são acompanhados como uma unidade única em vez de por entrada, porque o hashcat aplica o *produto cartesiano* dos dois ficheiros e remover uma linha individual removeria silenciosamente todas as combinações em que ela participava.
- **As execuções com `--loopback` são registadas mas nunca filtradas.** O hashcat reintroduz plaintexts recém-quebrados como candidatos *extra*, pelo que essa execução tenta a wordlist e o conjunto de regras completos mais tudo o que esses plaintexts reciclados alcançam. Isso torna as duas direções assimétricas: registá-la é correto, pelo que uma execução normal posterior da mesma wordlist e regras é corretamente reconhecida como repetição, mas uma segunda execução loopback tem mais cracks para reciclar e nunca é saltada.

Defina `coverage_enabled` como `false` em `config.json` para desativar isto, ou passe `--no-coverage` para uma única execução — que nem consulta nem atualiza o armazenamento.

#### Inspecionar e repor a cobertura

A opção **85 — Attack Coverage** do menu principal mostra o que foi executado contra o ficheiro de hashes carregado, o seu histórico de execuções, e pode limpá-lo. As mesmas três ações são scriptáveis:```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

O ficheiro de hash é identificado pelo conteúdo, pelo que estes funcionam independentemente de onde tenham sido movidos desde então. forget afeta apenas esse alvo — o armazenamento reside em ~/.hate_crack/coverage/attack_coverage.sqlite3, e eliminar o ficheiro repõe a cobertura para todos os alvos.

Execuções com script

Uma execução com script que a cobertura ignore por completo ainda termina com 0 por predefinição, pelo que ativar a cobertura não pode começar a fazer falhar um harness existente. Passe --exit-code-on-skip para obter o código de saída 3 em vez disso, quando nada foi lançado:```bash hate_crack --exit-code-on-skip hashes.txt dict

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

Sair com código 3 significa que *nada* foi executado. Uma passagem parcialmente filtrada — algumas entradas
ignoradas, outras tentadas — ainda sai com `0`, porque o ataque de fato realizou trabalho.

### Notificações (opção 82 do menu)

O hate_crack pode enviar notificações push do Pushover quando os ataques terminam e,
opcionalmente, quando hashes individuais são quebrados. Todos os controles ficam na
opção `82 — Notificações` do menu principal:

1. **Alternar Notificações Pushover [LIGADO/DESLIGADO]** — interruptor principal. Persiste em `config.json` como `notify_enabled`.
2. **Alternar Notificações por Quebra [LIGADO/DESLIGADO]** — quando LIGADO, um monitor em segundo plano observa o arquivo `.out` e envia uma notificação por quebra (com agregação em rajadas por tick). Persiste em `config.json` como `notify_per_crack_enabled`. Não pode ser ativado enquanto o interruptor principal estiver DESLIGADO — ative a opção 1 primeiro.
3. **Enviar Notificação de Teste do Pushover** — dispara uma notificação padrão para você confirmar que o par token/usuário do Pushover funciona. Funciona mesmo quando o interruptor principal está DESLIGADO.

As credenciais ficam em `.env`; os demais ajustes são apenas via arquivo de configuração em `config.json`:

- `NOTIFY_PUSHOVER_TOKEN`, `NOTIFY_PUSHOVER_USER` (em `.env`) — obrigatórios para qualquer push ser disparado. Nada no menu grava esses valores; edite o `.env` você mesmo.
- `notify_attack_allowlist` — nomes de ataques que consentem automaticamente sem o prompt `[y/N/always]`. Preenchido automaticamente quando você responde `always`.
- `notify_suppress_in_orchestrators` (padrão `true`) — silencia os ataques individuais encadeados pelo Extensive Crack, que dispara um único resumo em vez disso. Defina como `false` para receber uma notificação por ataque encadeado. Outras entradas de menu que executam várias passagens (por exemplo, Quick Crack com múltiplas cadeias de regras) não são orquestradores e sempre notificam por passagem.
- `notify_max_cracks_per_burst` (padrão `5`), `notify_poll_interval_seconds` (padrão `5.0`) — ajustes do monitor por quebra. Veja `hate_crack/notify/tailer.py` para a lógica de agregação em rajadas.

### Ferramentas de Wordlist (opção 80 do menu)

O submenu Ferramentas de Wordlist fornece utilitários de pré-processamento de wordlists baseados nos binários do hashcat-utils, além de downloads de wordlists do Hashmob.net e do Weakpass. Acesse pela opção **80** no menu principal.

| Opção | Binário | O que faz |
|--------|--------|--------------|
| 1 | `len.bin` | Filtrar por comprimento — manter apenas palavras entre um comprimento mínimo e máximo |
| 2 | `req-include.bin` | Exigir classes de caracteres — manter apenas palavras contendo todos os tipos de caracteres exigidos |
| 3 | `req-exclude.bin` | Excluir classes de caracteres — remover palavras contendo qualquer tipo de caractere excluído |
| 4 | `cutb.bin` | Extrair substring — cortar um intervalo de bytes de cada palavra |
| 5 | `splitlen.bin` | Dividir por comprimento — criar arquivos separados por comprimento de palavra (arquivos nomeados `01`-`64` em um diretório de saída) |
| 6 | `rli.bin` / `rli2.bin` | Subtrair palavras — remover entradas que aparecem em um ou mais outros arquivos |
| 7 | `gate.bin` | Fragmentar — extrair cada N-ésima palavra para quebra distribuída em múltiplas máquinas |
| 8 | - | Otimizar wordlists — deduplicar e dividir em arquivos por comprimento no diretório de wordlists otimizadas |
| 9 | - | Baixar wordlists do Hashmob.net |
| 10 | - | Baixar wordlists do Weakpass (via BitTorrent) |

**Bits de máscara de classes de caracteres** (usados pelas opções 2 e 3): `1`=minúsculas, `2`=maiúsculas, `4`=dígito, `8`=símbolo, `16`=outro. Some os valores: `7` = minúsculas+maiúsculas+dígito.

**Como a fragmentação deve ser usada**: a fragmentação divide uma wordlist em N partes iguais e sem sobreposição para que o trabalho possa ser distribuído entre múltiplas máquinas ou GPUs. Cada parte é *intercalada* (cada N-ésima linha), então cada fragmento é uma amostra representativa da lista inteira, em vez de um bloco contíguo de início/fim — nenhum nó fica preso quebrando apenas a cauda de baixa probabilidade.

Execute a opção 7 uma vez, forneça uma wordlist de entrada, um caminho base de saída e uma contagem de fragmentos (N). Ela grava todas as N partes em uma única passagem, nomeadas com números de parte com zero à esquerda (`base.001`, `base.002`, … até `base.00N`). Copie uma parte para cada nó e aponte a execução do hashcat desse nó para ela. Em um sistema de GPU única, a fragmentação não traz ganho de velocidade, mas uma única parte ainda é uma amostra rápida e representativa para uma passagem rápida de triagem antes de se comprometer com a lista completa.

#### Verificações Automáticas de Atualização

O hate_crack pode verificar automaticamente no GitHub se há versões mais recentes na inicialização. Esse recurso é controlado pela opção de configuração `check_for_updates`:```json
{
  "check_for_updates": true
}

check_for_updates — Ativa verificações automáticas de versão na inicialização (padrão: true).
Quando ativado, o hate_crack busca as informações da versão mais recente no GitHub e exibe um aviso se houver uma atualização disponível.
A verificação é executada de forma assíncrona e não bloqueia a inicialização. Erros de rede são ignorados silenciosamente.

Canais de Atualização

Canal	Flag	Fonte	O que você obtém
Release	`--update`	`main`	A versão estável mais recente. Este é o padrão e o que a verificação de inicialização oferece.
Nightly	`--nightly`	`nightly-dev`	Trabalho que passou pela CI, mas ainda não foi lançado.

As versões seguem o semver comum, com o incremento derivado do que está realmente no lote. O segundo componente muda apenas para funcionalidades: um ciclo que contenha qualquer commit feat está indo para X.(Y+1).0, e um ciclo com apenas correções, documentação e tarefas está indo para X.Y.(Z+1).

As tags nightly-dev marcam candidatos a lançamento para a versão para a qual o lote está se encaminhando — v2.20.1rc1, v2.20.1rc2, … — e a fusão para main promove esse mesmo alvo ao seu lançamento final. Os candidatos são pré-lançamentos reais do PEP 440, portanto eles se ordenam corretamente em ambas as extremidades:

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

O alvo pode mudar no meio do ciclo: o primeiro feat a chegar o move de X.Y.(Z+1) para X.(Y+1).0, e a numeração dos candidatos é reiniciada para o novo alvo. O número sempre indica o que o lote lançaria hoje.

O componente principal nunca é incrementado automaticamente — um assunto com ! ou um rodapé BREAKING CHANGE: conta como funcionalidade, porque um incremento automático de versão principal está a uma linha de assunto mal digitada de um lançamento publicado irreversível. Uma versão principal é um ato humano explícito: marque a tag e envie o push manualmente.

A política está em tools/next_version.py, compartilhada por ambos os fluxos de trabalho de tagging e testada por unidade em tests/test_next_version.py.

A verificação de inicialização só oferece releases, pois as builds nightly não publicam nenhum release no GitHub e a verificação lê o endpoint de "último release" do GitHub — portanto, ativar check_for_updates nunca o levará para uma nightly. Duas coisas mantêm os canais separados agora: isso, e o fato de que um candidato é um pré-lançamento genuíno do PEP 440, então uma ferramenta que classifica números de versão brutos também o trata como mais antigo do que o release no qual ele se torna.

Qualquer uma das flags alterna seu checkout para o branch correspondente primeiro (e se recusa a fazê-lo se você tiver alterações não confirmadas). Se você estiver executando uma nightly e quiser voltar ao código lançado, --update o move de volta para main.

Mesclagem Automática de Hashes Encontrados (Somente Download da Esquerda)

Ao baixar hashes da esquerda (hashes não quebrados), o hate_crack automaticamente:

Tenta baixar quaisquer hashes encontrados (quebrados) do Hashview como uma operação auxiliar
Mescla os hashes encontrados com arquivos .out locais (por exemplo, left_1_123.txt.out ou left_1_123.nt.txt.out para o formato pwdump)
Remove entradas duplicadas
Limpa arquivos temporários divididos após a mesclagem

Isso garante que seus resultados locais de quebra permaneçam sincronizados com o banco de dados centralizado do Hashview ao trabalhar com hashes não quebrados.

Observação: A opção de download de encontrados baixa hashes já quebrados separadamente para fins de referência e não realiza nenhuma mesclagem nem solicita quebra.

O <hash_type> é obtido executando hashcat --help

I need the actual content of chunk 120 to translate it. Please provide the Markdown text you want translated.```
$ ./hate_crack.py <hash file> 1000

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

Testes

A suíte de testes é majoritariamente offline e usa mocks/fixtures. Verificações de rede ao vivo e verificações de dependências do sistema são opcionais, ativadas por variáveis de ambiente.

Executando Testes Localmente```bash

Run all tests

uv run pytest -v

Run specific test

uv run pytest tests/test_hashview.py -v

Você também pode executar a suíte completa com `make test`.

### Testes ao Vivo (Opt-In)

Defina qualquer um dos seguintes para habilitar verificações ao vivo:

- `HASHMOB_TEST_REAL=1` — verificação ao vivo de conectividade/menu CLI do Hashmob
- `HASHVIEW_TEST_REAL=1` — verificação ao vivo do menu CLI do Hashview
- `WEAKPASS_TEST_REAL=1` — verificação ao vivo do menu CLI do Weakpass
- `HATE_CRACK_REQUIRE_DEPS=1` — falha se `7z`, `transmission-daemon` ou `transmission-remote` estiver ausente

### Teste de Upload ao Vivo do Hashview

O teste de upload ao vivo do Hashview é ignorado por padrão. Para executá-lo, defina a
variável de ambiente e forneça credenciais válidas em `.env`:```bash
HATE_CRACK_RUN_LIVE_TESTS=1 uv run pytest tests/test_upload_cracked_hashes.py -v

Testes Live do Hashview Contra uma Stack Docker Local

Em vez de apontar os testes live para um servidor Hashview remoto, você pode fazer com que a suíte inicie uma stack Docker local do Hashview, a popule, execute os testes live contra ela e a derrube. Defina HASHVIEW_TEST_LOCAL=1 e aponte HASHVIEW_REPO para um checkout do 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

Isto inicia o `docker compose` no repositório Hashview, semeia uma chave de API de administrador,
um cliente, um arquivo de hash e dados de "tarefa efetiva" quebrados, e então exporta
as variáveis de ambiente `HASHVIEW_*` que os testes leem. Variáveis de ambiente úteis:

- `HASHVIEW_TEST_LOCAL=1` — ativa a stack local (sem efeito caso contrário)
- `HASHVIEW_REPO=<caminho>` — checkout do Hashview (padrão `~/projects/hashview`)
- `HASHVIEW_KEEP=1` — mantém os contêineres em execução após a sessão (re-execuções mais rápidas)
- `HASHVIEW_LOCAL_PORT=5000` — porta do host na qual o aplicativo é publicado

O CLI hate_crack honra as variáveis de ambiente `HASHVIEW_URL` / `HASHVIEW_API_KEY`
(substituindo o `.env` onde essas duas chaves residem), que é o que permite à
suíte apontar o CLI para a stack local sem editar sua configuração persistida.

### Testes de Instalação de Ponta a Ponta (Local + Docker)

Instalação da ferramenta uv local + execução de script (usa um HOME temporário):```bash
HATE_CRACK_RUN_E2E=1 uv run pytest tests/test_e2e_local_install.py -v

Docker-based end-to-end install/run (em cache via Dockerfile.test):```bash HATE_CRACK_RUN_DOCKER_TESTS=1 uv run pytest tests/test_docker_script_install.py -v

O teste E2E do Docker também baixa um pequeno subconjunto do rockyou e executa uma
quebra básica com o hashcat para validar a integração com ferramentas externas.

Teste de ponta a ponta da VM Lima (somente macOS):

Pré-requisitos: [Lima](https://lima-vm.io/) e `rsync` devem estar instalados.```bash
brew install lima

O VM de teste é provisionado automaticamente com todas as dependências 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

Este teste valida a instalação e execução dentro de uma VM Linux leve no macOS.

### Estrutura do Teste

- **tests/test_hashview.py**: Suíte de testes abrangente para a classe HashviewAPI com respostas de API simuladas, incluindo:
  - Listagem de clientes e validação de dados
  - Testes de autenticação e autorização
  - Funcionalidade de upload de arquivos de hash
  - Fluxo completo de criação de jobs

Todos os testes usam chamadas de API simuladas, portanto podem ser executados sem conectividade com um servidor Hashview.

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

  (1) Crack Rápido
  (2) Crack Extensivo pela Metodologia Pure_Hate
  (3) Ataque de Força Bruta
  (4) Ataque de Máscara Principal
  (5) Ataque de Impressão Digital
  (6) Ataques de Combinador
  (7) Ataque Híbrido
  (8) Crack de Força Bruta com Máscara Top 100 do Pathwell
  (9) Ataque PRINCE
  (10) Metodologia Bandrel
  (11) Ataque Loopback
  (12) Ataque LLM
  (13) Ataque OMEN
  (14) Ataque de Máscara Ad-hoc
  (15) Ataque de Força Bruta Markov
  (16) Ataque N-gram
  (17) Ataque de Permutação
  (18) Ataque de Regras Aleatórias
  (19) Ataque de Frase-secreta Combipow
  (20) Ataque PCFG
  (21) Ataque PRINCE-LING
  (22) Ataque Spoonman
  (23) Ataque Rosetta
  (24) Força Bruta com Máscaras Corporativas
  (25) Ataque de Máscara Inteligente

  (80) Ferramentas de Wordlist
  (81) Ferramentas de Arquivos de Regras
  (82) Notificações
  (83) Ferramentas de Máscara

  (93) Regenerar .out a partir do arquivo POT
  (94) API Hashview
  (95) Analisar hashes com Pipal
  (96) Exportar Saída para Formato Excel
  (97) Exibir Hashes Quebrados
  (98) Exibir README
  (99) Sair

Selecione uma tarefa:```

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

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

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

Qual(is) regra(s) gostaria de executar? (1) best64.rule (2) d3ad0ne.rule (3) T0XlC.rule (4) dive.rule (99) YOLO...executar todas as regras Digite uma lista separada por vírgulas das regras que deseja executar. Para executar regras encadeadas, use o símbolo +. Por exemplo, 1+1 executará best64.rule encadeada duas vezes e 1,2 executará best64.rule e depois d3ad0ne.rule sequencialmente. Escolha com sabedoria:```

Extensive Pure_Hate Methodology Crack

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

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

Brute Force Attack

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

Top Mask Attack

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

Fingerprint Attack

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

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

Smart Mask Attack

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

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

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

Combinator Attack

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

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

Hybrid Attack

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

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

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

Pathwell Top 100 Mask Brute Force Crack

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

PRINCE Attack

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

Runs a PRINCE attack using wordlists/rockyou.txt

YOLO Combinator Attack

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

Middle Combinator Attack

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

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

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

Thorough Combinator Attack

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

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

Bandrel Methodology

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

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

Loopback Attack

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

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

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

LLM Attack

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

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

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

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

OMEN Attack

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

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

Combinator Attacks Submenu

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

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

Ad-hoc Mask Attack

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

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

Markov Brute Force Attack

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

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

N-gram Attack

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

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

Permutation Attack

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

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

Random Rules Attack

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

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

Combipow Passphrase Attack

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

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

PCFG Attack

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

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

PRINCE-LING Attack

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

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

Spoonman Attack

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

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

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

Rosetta Attack

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

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

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

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

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

Corporate Masks Brute Force

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

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

Wordlist Tools (option 80)

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

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

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

Rule File Tools (option 81)

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

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

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

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

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

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

Analyze Hashcat Rules (Rule File Tools option 5)

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

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

Mask Tools (option 83)

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

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

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

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

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

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

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

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

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

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

Hashmob Downloads (Wordlist Tools option 11)

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

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

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

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

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

Version History

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

Ler mais

hate_crack v2.36.1

Categorias