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

Instalación

Instalar desde el código fuente es la única vía compatible. hate_crack no se distribuye en PyPI: pip install hate-crack resuelve a un marcador de posición 0.0.0 que falla a propósito y apunta de vuelta aquí. El nombre se mantiene solo para que nadie más pueda publicar un clon bajo él — consulte packaging/pypi-placeholder/.

1. Instalar hashcat

Hashcat debe estar instalado y disponible en tu PATH:

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

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

O descarga un binario precompilado desde https://hashcat.net/hashcat/ y establece hcatPath en config.json a su ubicación.

2. Descargar hate_crack

Clona con submódulos (requerido para hashcat-utils, princeprocessor, pcfg_cracker, Corporate_Masks y, opcionalmente, omen):```bash git clone --recurse-submodules https://github.com/trustedsec/hate_crack.git cd hate_crack

Si clonaste sin submódulos, inicialízalos:```bash
git submodule update --init --recursive

Luego personaliza la configuración si es necesario. hate_crack utiliza dos archivos de configuración, cada uno con un conjunto distinto de ajustes:

config.json — rutas de listas de palabras, máscaras, reglas, ajustes, potfile, ruta de hashcat, límites de candidatos, interruptores de notificaciones, preferencias predeterminadas de CLI (35 ajustes).
.env — solo ajustes de integración de terceros: credenciales de Hashview y Hashmob, credenciales de Pushover, Ollama y pipal (14 ajustes). No está rastreado por git, se crea con modo 0600.

La línea está ahí por una razón: .env es el archivo que puede contener secretos. Las credenciales y la configuración de servicios de terceros van en el archivo no rastreado con permisos 0600; todo lo que hate_crack hace localmente permanece en config.json, que es seguro de compartir, comparar y registrar en tus propias notas. Esa es también la razón por la que las credenciales de Pushover están en .env mientras que los interruptores de activación/desactivación de Pushover están en config.json — los interruptores son preferencias locales, no secretos.

Cada clave tiene exactamente un hogar. Una clave colocada en el otro archivo se ignora, y hate_crack imprime una advertencia indicando el archivo al que pertenece. Cualquier clave aún puede sobrescribirse para una sola ejecución exportando su variable de entorno. La mayoría de los usuarios pueden omitir este paso, ya que las rutas predeterminadas funcionan sin configuración adicional.

config.json es permanente y de primera clase — no está obsoleto y no hay un cronograma de eliminación para él. Solo se movieron los ajustes de integración.

¿Actualizando desde un único config.json? hate_crack lo migra por ti en la primera ejecución: los ajustes de integración se copian a un nuevo .env con permisos 0600, luego se eliminan de config.json para que ambos archivos no los reclamen. Imprime qué claves se movieron (nunca sus valores) y guarda tu original como config.json.pre-split.bak antes de modificarlo. Todo lo demás en config.json se deja exactamente como estaba, incluido el orden de las claves.

Primera ejecución: hate_crack crea ambos archivos por ti, así que no hay nada que hacer. Para configurar .env manualmente en su lugar, copia la plantilla rastreada:```bash cp .env.example .env chmod 600 .env

`.env.example` se incluye en el repositorio y se distribuye con cada clave de credencial vacía. `.env` en sí **nunca** debe incluirse en el repositorio — está en gitignore, junto con sus variantes habituales de respaldo, y hate_crack siempre lo crea con modo `0600` (solo lectura/escritura del propietario). `.env.example` se genera a partir del esquema; regenéralo después de modificar `hate_crack/config_schema.py` con `uv run python -m hate_crack.config_writer`.

### 3. Instalar dependencias y hate_crack

La forma más sencilla es ejecutar `make` (o `make install`), que detecta automáticamente tu sistema operativo e instala:
- Dependencias externas (p7zip, transmission-daemon / transmission-remote)
- Compila los submódulos (hashcat-utils, princeprocessor, pcfg_cracker y, opcionalmente, omen) y descarga el conjunto de máscaras Corporate_Masks solo de datos
- Dependencias de Python mediante uv y un enlace CLI en `~/.local/bin/hate_crack````bash
make

Esto es idempotente: omite las herramientas ya instaladas. Para forzar una reinstalación limpia:```bash make reinstall

**O instala las dependencias manualmente:**

### Dependencias externas
Estas son necesarias para ciertos flujos de descarga/extracción:

- `7z`/`7za` (p7zip) — se utiliza para extraer archivos `.7z`.
- `transmission-daemon` / `transmission-remote` — se utilizan para descargar torrents de Weakpass.

Comandos de instalación 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

Luego instala las dependencias de Python y el 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

Estructura del Proyecto

La lógica principal ahora está dividida en módulos bajo hate_crack/:

hate_crack/cli.py: ayudantes de argparse y anulaciones de configuración.
hate_crack/api.py: integraciones con Hashview, Weakpass y Hashmob (descargas/menús/ayudantes).
hate_crack/attacks.py: manejadores de ataques del menú.
hate_crack/corpus_stats.py: estadísticas de contraseñas de todo el corpus utilizadas para describir un corpus al LLM.
hate_crack/plaintext.py: recupera la contraseña de una línea del corpus (eliminación del prefijo hash, decodificación de $HEX[...]); compartido por los modos LLM, corpus_stats y rulegen.
hate_crack/llm.py: generación estructurada (JSON) de candidatos LLM mediante Atomic Agents.
hate_crack/menu.py: renderizador de menú compartido, incluida la navegación opcional con teclas de flecha.
hate_crack/noninteractive.py: despachador para los subcomandos de ataque con script.
hate_crack/notify/: paquete de notificaciones (backend Pushover, rastreador por crack).
hate_crack/username_detect.py: detecta archivos de entrada username:hash para decidir sobre --username de hashcat.
hate_crack/formatting.py, hate_crack/progress.py: ayudantes de formato de salida y visualización de progreso.
hate_crack/main.py: implementación principal de la CLI.

El hate_crack.py de nivel superior sigue siendo el punto de entrada principal y orquesta estos módulos.

Referencias y Agradecimientos

Este proyecto depende de y está inspirado en varios proyectos y servicios externos. Gracias a:

Uso

Después de instalar con make, ejecuta hate_crack desde cualquier lugar:```bash hate_crack

or with arguments:

hate_crack <hash_file> <hash_type> [options]

Alternativamente, ejecuta mediante `uv`:```bash
uv run hate_crack.py <hash_file> <hash_type>

Ejecutar como herramienta (recomendado)

Instala usando make desde la raíz del repositorio: esto compila los submódulos y agrupa los recursos:```bash cd /path/to/hate_crack make hate_crack

El comando `make install` crea un shim de bash en `~/.local/bin/hate_crack` que se ejecuta desde el directorio del repositorio, por lo que la configuración y los recursos siempre se encuentran independientemente de tu directorio de trabajo actual.

La configuración también se busca en:
- La raíz del repositorio y el directorio del paquete
- `~/.hate_crack`

**Nota:** El `hcatPath` en `config.json` es solo para la ubicación del binario de hashcat (opcional si hashcat está en PATH). Los recursos de Hate_crack (hashcat-utils, princeprocessor, pcfg_cracker, Corporate_Masks, omen) se cargan desde el directorio del repositorio y se incluyen automáticamente con `make install`.

### Ejecutar como script
El script usa un shebang de `uv`. Hazlo ejecutable y ejecútalo:```bash
chmod +x hate_crack.py
./hate_crack.py

También puedes usar Python directamente:```bash python hate_crack.py

### Uso no interactivo / mediante scripts

Para automatización, puedes lanzar un único ataque directamente, omitiendo el menú. El nombre del ataque es el primer argumento, seguido del archivo de hashes y el tipo de hash de hashcat. Los avisos de preprocesamiento (filtrado de cuentas de equipo, fuerza bruta LM primero, deduplicación de cuentas duplicadas) aceptan automáticamente sus valores predeterminados en este modo. El proceso sale con `0` en caso de éxito y con un valor distinto de cero en caso de error (archivo de hashes faltante, tipo de hash no numérico, lista de palabras faltante o nombre de archivo de regla desconocido).```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

Solución de problemas

Error: "would clobber existing tag" al actualizar

Un clon antiguo puede negarse a actualizar, mostrando una larga lista de líneas como:``` ! [rejected] v2.5.0 -> v2.5.0 (would clobber existing tag)

Esto afecta a los clones creados antes de julio de 2026. El historial publicado se reescribió
entonces para eliminar algunos archivos que nunca deberían haberse confirmado, lo que dio
a cada commit un nuevo ID; por lo tanto, las etiquetas de un clon más antiguo apuntan a objetos que
este repositorio ya no contiene, y git se niega a mover una etiqueta que ya tiene.
No hay nada malo en tu checkout y ningún dato de cracking está en riesgo.

Recupéralo con un restablecimiento único. Esto descarta commits locales y ediciones en el
checkout, así que si has personalizado algo rastreado por git (a diferencia de
`config.json`, que no está rastreado), confírmalo en una rama primero:```bash
cd /path/to/hate_crack
git fetch --tags --force origin
git checkout -B main origin/main
make install

--force aquí solo actualiza las etiquetas; no puede tocar tus commits. Después, el actualizador integrado funciona con normalidad. Las versiones anteriores a la 2.18 no podían realizar esta recuperación por sí mismas, por lo que debe hacerse a mano una vez.

Error: El directorio de compilación no existe

Si ves un error como:``` Error: Build directory /opt/hashcat/hashcat-utils does not exist. Expected to find expander at /opt/hashcat/hashcat-utils/bin/expander.

Esto significa que los recursos de hate_crack no se incluyeron en el paquete instalado.

**Entendiendo las rutas:**
- `hcatPath` en config.json → apunta a la **ubicación del binario de hashcat** (opcional, puede estar en PATH)
- `hashcat-utils/` y `princeprocessor/` → se incluyen en el paquete mediante `make install`

**Solución:**
Reinstale usando el Makefile, que compila los submódulos e instala la herramienta:```bash
cd /path/to/hate_crack  # the repository checkout
make install

Configuración predeterminada (config.json.example):

La mayoría de los usuarios pueden usar los valores predeterminados sin personalización:

hcatWordlists: ./wordlists (relativo a la raíz del repositorio o a HOME/.hate_crack)
hcatOptimizedWordlists: ./optimized_wordlists (directorio usado por Quick Crack; recurre a hcatWordlists si no se encuentra)
rules_directory: ./hashcat/rules (incluye reglas del submódulo)
hcatTuning: `` (cadena vacía - sin banderas de ajuste predeterminadas)

Ejemplo de personalizaciones de 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) ... }

**Carga de configuración:**
- Precedencia para cada clave: `os.environ` > el archivo propio de esa clave (`config.json` o `.env`) > valor predeterminado integrado
- Las claves faltantes recurren a los valores predeterminados integrados; `config.json.example` documenta cada clave de `config.json`
- Ambos archivos se buscan, de forma independiente entre sí, en este orden: **raíz del repositorio**, luego **directorio del paquete instalado**, y luego **`~/.hate_crack`**. La primera coincidencia gana; es normal que los dos archivos provengan de directorios distintos.
- En la primera ejecución, ambos se crean — `config.json` a partir de `config.json.example`, `.env` a partir de los valores predeterminados integrados. Si un `config.json` antiguo aún contiene claves de integración, estas se copian al nuevo `.env` y hate_crack te indica cuáles debes eliminar de `config.json`; nunca edita ese archivo por sí mismo.
- En cada ejecución, hate_crack imprime los dos archivos que realmente cargó:  ```
  [*] config.json: /home/you/.hate_crack/config.json
  [*] .env:        /home/you/.hate_crack/.env

Lee esas dos líneas antes de depurar un ajuste que "no está surtiendo efecto". Existen por dos trampas en el orden de búsqueda:

Un checkout tiene prioridad sobre tu directorio personal. La raíz del repositorio se busca primero, así que un .env o config.json que esté en cualquier checkout desde el que ejecutes la herramienta gana sobre el de ~/.hate_crack — y ejecutar la herramienta desde un checkout es exactamente lo que crea esos archivos allí en primer lugar. Si esto alguna vez eclipsa una configuración real de ~/.hate_crack, hate_crack ahora lo indica con una tercera línea [!] que nombra ambas rutas — trata esa línea como "el archivo de abajo se está ignorando", no como una segunda configuración igualmente válida.
El directorio de trabajo actual nunca se busca. Un .env en el directorio en el que te encuentras se ignora, deliberadamente: los directorios de compromiso están llenos de archivos que nadie pretendía que fueran configuración. Colócalo en la raíz del repositorio o en ~/.hate_crack.

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

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

La rama por defecto fue renombrada de `master` a `main`. Corrige con:```bash
git remote set-head origin -a
git branch -m master main
git branch --set-upstream-to=origin/main main
git pull

Objetivos del Makefile

Predeterminado (instalación completa) - compila los submódulos, instala las dependencias e instala la herramienta:```bash make

or explicitly:

make install

Esto es idempotente: omite las herramientas ya instaladas.

**Forzar reinstalación limpia:**```bash
make reinstall

Actualización rápida - reconstruye los submódulos y reinstala la herramienta (después de extraer los cambios):```bash make update

**Desinstalar** - elimina las dependencias del sistema operativo y la herramienta:```bash
make uninstall

Compila solo hashcat-utils:```bash make hashcat-utils

**Ejecutar pruebas** - maneja automáticamente HATE_CRACK_SKIP_INIT cuando sea necesario:```bash
make test

Informe de cobertura:```bash make coverage

**Limpia los artefactos de compilación/prueba:**```bash
make clean

Desarrollo

Configuración del entorno de desarrollo

Instala el proyecto con las dependencias de desarrollo opcionales (incluye linters y herramientas de prueba):```bash make dev-install

### Ejecutar Linters y Comprobaciones de Tipos

Antes de enviar cambios, ejecuta estas comprobaciones localmente. Usa `make lint` para todo, o ejecuta comprobaciones individuales:

**Ruff (linting y formato):**```bash
make ruff
# or manually:
uv run ruff check hate_crack tests tools packaging hate_crack.py

Auto-fix issues:```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 (verificación de tipos):**```bash
make ty
# or manually:
uv run ty check hate_crack

Ejecutar todas las comprobaciones juntas:```bash make lint

### Ejecución de Pruebas

Las pruebas detectan automáticamente cuando los submódulos no están compilados y establecen `HATE_CRACK_SKIP_INIT=1` automáticamente.```bash
make test

O ejecuta pytest directamente:```bash uv run pytest -v

Con cobertura:```bash
make coverage

O con pytest:```bash uv run pytest --cov=hate_crack

### Git Hooks (prek)

Los hooks de Git son gestionados por [prek](https://github.com/j178/prek) (v0.3.3+). Instala los hooks con:```bash
prek install --hook-type pre-push --hook-type pre-commit

Esto instala los hooks definidos en prek.toml usando el esquema TOML de repositorio local de pre-commit:

pre-push (hooks locales): 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

Los auto-corrector de pre-commit reescriben los archivos en su lugar, así que vuelve a preparar y confirma de nuevo después de que se ejecuten.

Nota: prek 0.3.3 espera repos = [...] en el nivel superior. El formato antiguo [hooks.<stage>] commands = [...] no es compatible.

Los menús usan por defecto la selección clásica numerada con print() + input(), que acepta claves completas de varios dígitos.

Para habilitar la navegación con flechas mediante simple-term-menu, establece HATE_CRACK_ARROW_MENU=1. En ese modo solo funcionan las claves de acceso directo de un solo dígito; las opciones numeradas 10 o superiores deben alcanzarse con las teclas de flecha. El modo de flechas también requiere una TTY, por lo que permanece desactivado cuando la salida se canaliza.

Dependencias de Desarrollo

El grupo opcional [dev] incluye:

ty - Comprobador de tipos estático
ruff - Linter y formateador rápido de Python
pytest - Marco de pruebas
pytest-cov - Informes de cobertura

Opciones comunes:

--download-hashview: Descargar hashes de Hashview antes de crackear.
--hashview: Menú interactivo de Hashview para gestionar hashes, listas de palabras y trabajos.
--hashview --help: Mostrar las opciones de línea de comandos de Hashview.
--weakpass: Descargar listas de palabras de Weakpass.
--hashmob: Descargar listas de palabras de Hashmob.net.
--hashmob-masks: Descargar máscaras de Hashmob.net.
--download-torrent <FILENAME>: Descargar un archivo torrent específico de Weakpass.
--download-all-torrents: Descargar todos los torrents disponibles de Weakpass desde la caché.
--wordlists-dir <PATH> / --optimized-wordlists-dir <PATH>: Anular los directorios de listas de palabras.
--pipal-path <PATH>: Anular la ruta de pipal.
--restore-potfile: Reconstruir <hashfile>.out desde el archivo POT de hashcat al inicio, reemplazando cualquier contenido existente, y luego continuar con el menú normal. Sin esta bandera, la búsqueda en el POT solo se ejecuta cuando .out no existe ya. La opción 93 del menú hace lo mismo bajo demanda, con un mensaje de confirmación.
--maxruntime <SECONDS>: Anular el tiempo máximo de ejecución.
--bandrel-basewords <PATH>: Anular el archivo de palabras base de bandrel.
--update: Actualizar a la última versión y reinstalar. Cambia el checkout a main si está en otra rama, ya que las etiquetas de lanzamiento viven allí.
--nightly: Actualizar en su lugar a la última versión nocturna, desde la rama nightly-dev. Las versiones nocturnas han pasado CI pero no forman parte de un lanzamiento recortado. También se puede escribir --update --nightly.
--no-optimized-kernel (o --no-optimize): Nunca pasar -O a hashcat durante toda la ejecución. Anula optimizedKernelAttacks en config.json y elimina cualquier -O que pongas en hcatTuning. No se escribe nada de vuelta en la configuración, por lo que se aplica solo a esta ejecución. Con un subcomando, colócalo antes del subcomando: ./hate_crack.py --no-optimize quick hashes.txt 1000 --wordlist words.txt.
--debug: Habilitar el registro de depuración (escribe en stderr).

Integración con Hashview

hate_crack se integra con Hashview para la gestión centralizada de hashes y el crackeo distribuido.

Accede al menú interactivo de Hashview:```bash hate_crack.py --hashview

Opciones del menú:
- **(1) Subir hashes descifrados** - Sube los resultados descifrados de la sesión actual a Hashview
- **(2) Subir lista de palabras** - Sube un archivo de lista de palabras a Hashview
- **(3) Descargar lista de palabras** - Descarga una lista de palabras desde Hashview
- **Descargar regla** - Descarga un archivo de reglas desde Hashview (descomprimido a texto plano, listo para `hashcat -r`)
- **Descargar todas las reglas** - Descarga todos los archivos de reglas listados por Hashview de una sola vez; los fallos por regla se informan sin abortar el resto
- **(4) Descargar hashes restantes** - Descarga los hashes aún no descifrados (pregunta si se desea cambiar para descifrar)
- **(5) Descargar hashes encontrados** - Descarga los hashes ya descifrados con contraseñas en texto claro (para referencia/análisis)
- **(6) Subir archivo de hashes y crear trabajo** - Sube un nuevo archivo de hashes y crea un trabajo de descifrado
- **(99) Volver al menú principal** - Regresa al menú principal

**Importante: Descargar encontrados vs Descargar restantes**
- **Descargar hashes restantes (4)**: Descarga los hashes no descifrados que necesitan ser descifrados. Se fusiona automáticamente con los hashes encontrados si están disponibles, y pregunta si se desea cambiar a este archivo de hashes para descifrar.
- **Descargar hashes encontrados (5)**: Descarga los hashes ya descifrados en formato hash:texto_claro. Estos son solo para referencia y no pueden descifrarse más. No se muestra ninguna pregunta de cambio.

#### Interfaz de línea de comandos

Las operaciones de Hashview también pueden realizarse mediante la línea de comandos:

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

Sube una lista de palabras:```bash hate_crack.py --hashview upload-wordlist --file .txt --name "My Wordlist"

Descarga un archivo de reglas (guardado descomprimido, listo para `hashcat -r`):```bash
hate_crack.py --hashview download-rules --rules-id 4 --output best64.rule

Descarga los hashes restantes (hashes sin descifrar para el cracking):```bash hate_crack.py --hashview download-left --customer-id 1 --hashfile-id 123

Descargar hashes encontrados (hashes ya descifrados con texto en claro):```bash
hate_crack.py --hashview download-found --customer-id 1 --hashfile-id 123

Sube el archivo hash y crea el trabajo:```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"

#### Configuración

Establece las credenciales de Hashview en `.env` (son ajustes de integración, por lo que no viven en `config.json`):```
HASHVIEW_URL=https://hashview.example.com
HASHVIEW_API_KEY=your-api-key-here

Configuración del LLM

El Ataque LLM (opción 12) y el Ataque de Máscara Rosetta (opción 23) generan sus candidatos con un modelo local. Configura el modelo, la ventana de contexto y el tiempo de espera de la solicitud en .env:``` LLM_BACKEND=ollama OLLAMA_MODEL=qwen3:4b-instruct OLLAMA_NUM_CTX=8192 OLLAMA_TIMEOUT=300

**Las claves `OLLAMA_*` siguientes se aplican a todos los backends, no solo a Ollama.** Mantienen ese prefijo porque `OLLAMA_HOST` es la misma variable que lee el propio CLI de Ollama, y renombrarlas rompería todos los `.env` existentes sin ganancia funcional: un servidor vLLM o compatible con OpenAI quiere el mismo host, modelo, tiempo de espera, contexto y controles de muestreo bajo los mismos nombres. `LLM_BACKEND` solo selecciona cómo se forma la solicitud.

- **`OLLAMA_MODEL`** — El modelo de Ollama utilizado para la generación de candidatos (predeterminado: `qwen3:4b-instruct`). El ataque LLM usa salida estructurada (JSON), así que elige un modelo con buen soporte de herramientas/JSON.
- **`OLLAMA_NUM_CTX`** — Tamaño de la ventana de contexto para el modelo (predeterminado: `8192`). Antes era `2048` hasta que se introdujeron las estadísticas del corpus, lo cual era demasiado pequeño para contener el prompt que se le daba: 500 textos planos muestreados ocupan aproximadamente 2,000–3,500 tokens antes del prompt del sistema y la respuesta, por lo que Ollama truncaba silenciosamente parte de la muestra que el muestreador había distribuido cuidadosamente por el archivo.
- **`OLLAMA_TIMEOUT`** — Segundos de espera para una respuesta de generación antes de rendirse (predeterminado: `300`). Auméntalo si un modelo grande aún se está cargando en VRAM en la primera solicitud, lo que de otro modo puede superar el tiempo de espera; hate_crack imprime el tiempo de espera transcurrido y el nombre de esta configuración cuando se dispara.
- **`OLLAMA_MAX_SAMPLE_LINES`** — El umbral por debajo del cual los modos LLM también pegan los textos planos literales en el prompt (predeterminado: `500`). Los valores ≤ 0 se tratan como 500.

  Los modos derivados del corpus (**Wordlist**, **Cracked passwords**, **Pattern rules**) siempre describen el *corpus completo* estadísticamente — proporciones de palabras base, máscaras, mayúsculas/minúsculas, longitudes, dígitos y símbolos finales, años — en lugar de pegar una porción del mismo. La agregación está limitada, por lo que un volcado de 120,000 contraseñas cuesta aproximadamente el mismo espacio de prompt que uno de 500 líneas. Cuando todo el corpus cabe bajo este umbral, los textos planos sin procesar también se incluyen, ya que no se gana nada ocultando un corpus pequeño al modelo.

  Esto reemplaza el comportamiento anterior de pegar una muestra espaciada uniformemente de hasta `ollamaMaxSampleLines` contraseñas. Una muestra de un volcado grande no transmitía información de frecuencia alguna: el modelo no podía distinguir una palabra base usada por el 8% de la organización de una usada por una sola persona, que es precisamente la señal que hace que valga la pena probar una suposición.
- **`OLLAMA_NO_CLOUD`** — Cuando es `true`, se niega a enviar cualquier cosa fuera de este host, para cualquiera de los tres backends LLM (Ollama, vLLM o un servidor genérico compatible con OpenAI). Dos comprobaciones están controladas por esta única configuración: Ollama proxya un modelo etiquetado con `-cloud` (`gpt-oss:120b-cloud`, `deepseek-v3.1:671b-cloud`) a ollama.com a través del mismo endpoint local que usa un modelo local, por lo que nada en la solicitud parece diferente — eso se rechaza por nombre de modelo. También se comprueba la URL del backend configurado: un destino que no sea de bucle local, privado o enlace local (y que no sea `localhost` ni un nombre `.local`/`.internal`/`.lan`/`.localdomain`) se rechaza por destino, y un nombre de host que esta comprobación no pueda resolver también se rechaza, con cierre seguro, en lugar de dejar pasar un destino no verificable. Los prompts de hate_crack llevan textos planos recuperados, estadísticas del corpus y el nombre, la industria y la ubicación del cliente, por lo que si cualquiera de las comprobaciones se dispara, la solicitud se rechaza antes de construirse. El valor predeterminado es `false`, por lo que un modelo en la nube o un servidor remoto configurado deliberadamente sigue funcionando; actívalo para compromisos donde los datos del cliente no deban salir del host.
- **`OLLAMA_AUTO_RESEARCH`** — Cuando es `true` (predeterminado), el modo **Target info** pide al modelo local que sugiera la industria, la ubicación y la empresa matriz / historial de adquisiciones tan pronto como hayas escrito el nombre de la empresa, y los ofrece como valores predeterminados editables en los prompts. Establécelo en `false` para obtener siempre prompts en blanco (útil con un modelo lento, ya que la investigación cuesta un viaje de ida y vuelta adicional antes de que comience el ataque).
- **`OLLAMA_HOST`** — Dónde está escuchando el backend configurado. Acepta un `host:port` simple (`theplague.lan:11434`) o una URL completa con esquema (`https://ollama.example.com`); en cualquier caso, la URL base se normaliza antes de usarse. El valor predeterminado es `localhost:11434`, que es el puerto de Ollama — un servidor vLLM o compatible con OpenAI necesita que esto se configure en el suyo propio (vLLM suele escuchar en `:8000`). Configúralo en `.env`, o expórtalo como una variable de entorno real para sobrescribirlo en una sola ejecución — es el mismo nombre de variable que lee el propio CLI de Ollama.
- **`LLM_BACKEND`** — Con qué servidor compatible con OpenAI hablar: `ollama` (predeterminado), `vllm` u `openai` para uno genérico. Cada backend habla la misma API de chat-completions `/v1`, por lo que esto solo selecciona los dos detalles de formación de solicitudes en los que difieren: `ollama` recibe `options.num_ctx`, y `vllm` recibe `chat_template_kwargs={"thinking": false}` — sin lo cual un servidor vLLM que ejecuta un analizador de razonamiento enruta toda la respuesta estructurada hacia `message.reasoning`, deja `message.content` vacío y rompe el análisis JSON. `openai` no envía ninguno, ya que `num_ctx` no tiene equivalente allí. **No** cambia de dónde provienen el host, el modelo, el tiempo de espera, el contexto o los ajustes de muestreo — esos son las claves `OLLAMA_*` anteriores para los tres.
- **`LLM_API_KEY`** — La credencial enviada al backend configurado. El valor predeterminado es el literal `ollama`, el marcador de posición que ignora el propio servidor de Ollama, por lo que las solicitudes de una instalación existente no cambian; un valor vacío recurre a ese mismo marcador de posición porque el SDK de OpenAI rechaza `api_key=""`. Configúralo con el valor real si el servidor exige uno — un servidor vLLM iniciado con `--api-key` devuelve 401 de lo contrario.
- Asegúrate de que Ollama esté en ejecución y el modelo esté descargado (`ollama pull qwen3:4b-instruct`) antes de usar el ataque LLM — hate_crack ya no descarga automáticamente los modelos faltantes.

El ataque ofrece tres modos de generación:

1. **Target info** — empresa / industria / ubicación / empresa matriz; el modelo deriva candidatos a partir de esos detalles.

   Después de escribir el nombre de la empresa, hate_crack pregunta al mismo modelo local qué sabe ya sobre esa organización y rellena previamente los prompts de **Industry**, **Location** y **Parent Company** con las respuestas, mostradas entre paréntesis:   ```
   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:

Pulsa Enter para aceptar una sugerencia o escribe sobre ella. Estos valores son el recuerdo del modelo, no OSINT — trátalos como un punto de partida, no como inteligencia sobre el cliente. La búsqueda utiliza únicamente el servidor local de Ollama, por lo que el nombre del cliente nunca sale del host; no hay llamadas web ni a API de terceros. Si el modelo no reconoce la organización (el caso común para clientes pequeños), no devuelve nada y obtienes simples indicadores en blanco: ``` Company name: Acme Rail Services Industry: Location: Parent company / acquired by:

Un fallo de investigación — tiempo de espera agotado, Ollama no ejecutándose, respuesta vacía — nunca bloquea el ataque; simplemente recurre a prompts en blanco. Establece `ollamaAutoResearch` en `false` para omitir la investigación por completo.
2. **Wordlist** — deriva palabras base de una wordlist de muestra.
3. **Contraseñas descifradas** — alimenta al modelo con los textos planos ya recuperados en esta sesión (`<hashfile>.out`) para que pueda inferir las propias convenciones de contraseña de la organización objetivo (palabras base, estaciones, años, sufijos, leetspeak) y generar *nuevos* candidatos en el mismo estilo. Esta opción solo aparece una vez que se ha descifrado al menos un hash; el archivo completo se analiza estadísticamente exactamente igual que en el modo Wordlist (consulta `ollamaMaxSampleLines` más arriba).

#### Configuración de PCFG

El Ataque PCFG (opción 20) y el Ataque PRINCE-LING (opción 21) utilizan el submódulo `pcfg_cracker`. Configúralos en `config.json`:```json
{
"pcfgRuleset": "DEFAULT",
"pcfgMaxCandidates": 50000000,
"pcfgPrinceLingMaxCandidates": 10000000
}

pcfgRuleset — Nombre de la gramática entrenada a usar (por defecto: DEFAULT), resuelto a pcfg_cracker/Rules/<name>/. Entrena la tuya propia con trainer.py de pcfg_cracker y establece esto al nombre del ruleset.
pcfgMaxCandidates — Máximo de candidatos que pcfg_guesser.py emite para el ataque PCFG (por defecto: 50000000).
pcfgPrinceLingMaxCandidates — Máximo de palabras base que prince_ling.py escribe en la lista de palabras base PRINCE cacheada (por defecto: 10000000).

Kernels optimizados (`optimizedKernelAttacks`)

La bandera -O de hashcat selecciona kernels optimizados, que son sustancialmente más rápidos pero limitan la longitud del candidato (aproximadamente 31 caracteres, menor para algunos modos) y omiten silenciosamente cualquier cosa más larga. optimizedKernelAttacks en config.json lista los ataques que se ejecutan con -O; omite un ataque de la lista para ejecutarlo con kernels de longitud completa. La lista en config.json.example coincide con el valor predeterminado integrado que se aplica cuando no existe ningún config.json.

Cuatro ataques respetan la configuración pero no están optimizados por defecto, porque alimentan candidatos que pueden superar el límite de -O — agrégalos a la lista para optar por ellos:

hcatNgramX, hcatOllama, hcatOmen, hcatLMtoNT

Para desactivar -O en todas partes para una sola ejecución sin editar la configuración, pasa --no-optimized-kernel (forma corta --no-optimize). Anula la lista para cada ataque y también elimina un -O escrito en hcatTuning, que de otro modo llegaría a hashcat independientemente de la lista.

Los nombres se comparan exactamente, y una entrada no reconocida se informa al inicio en lugar de ignorarse. Ten en cuenta que los ataques que delegan en otro ataque están controlados por el ataque al que delegan, no por su propio nombre: PRINCE-LING sigue a hcatPrince, mientras que Spoonman, Rosetta y los modos de reglas de patrones LLM siguen a hcatQuickDictionary.

Seguimiento de cobertura de ataques (`coverage_enabled`)

A lo largo de un compromiso largo, el mismo archivo de hash se ataca en muchas sesiones con un conjunto rotativo de listas de palabras, archivos de reglas y listas de máscaras, y es fácil quemar horas re-ejecutando terreno que ya cubriste — especialmente porque la misma línea de regla vive en más de un archivo de reglas. hate_crack registra lo que ya ha ejecutado contra cada archivo de hash y ofrece omitir la superposición.

La cobertura se registra por entrada, no por archivo: líneas de reglas individuales y líneas .hcmask individuales, cada una emparejada con la lista de palabras contra la que se ejecutó. Eso es lo que le permite reconocer que un archivo de reglas personalizado que ejecutas hoy repite 40 de las reglas que best64.rule ya cubrió la semana pasada, y también es por qué una regla solo está "cubierta" para la lista de palabras específica con la que se probó — las mismas reglas sobre un corpus diferente prueban candidatos completamente distintos.

El archivo de hash se identifica mediante un sha256 de su contenido, por lo que la cobertura sobrevive al renombrado o movimiento entre sesiones. Las listas de palabras se identifican de la misma manera, con el digest memoizado contra tamaño y mtime para que un corpus de varios gigabytes se haga hash una vez en lugar de en cada ataque.

Solo se te solicita cuando hay genuinamente algo que omitir:``` [*] 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]:

Responde `Y` y hate_crack construye un archivo de reglas temporal que contiene solo las entradas no probadas; responde `n` para ejecutar todo de todos modos. Si *todas* las entradas son repetidas, se te pregunta si deseas omitir el ataque por completo, de modo que volver a ejecutar terreno ya cubierto nunca requiera reiniciar la herramienta.

Los ataques que nunca se filtran aún se registran como ejecutados, lo que te permite responder "¿ya ejecuté PRINCE contra este objetivo?".

Un ataque que selecciona varios archivos de reglas a la vez (Quick Crack, Loopback) hace la pregunta de omisión **una vez para todo el lote, por adelantado**, antes de cualquier invocación de hashcat. Esa pregunta es deliberadamente barata: no lee ni aplica hash a ninguno de los archivos de reglas seleccionados, ya que un lote YOLO puede llegar a millones de líneas y no deberías esperar a eso para responder un sí/no. Solo pregunta al almacén si este ataque ya se ha ejecutado contra este archivo de hash **con una de estas listas de palabras**; la diferencia por entrada aún ocurre de forma perezosa, un archivo de reglas a la vez, y decide qué se omite realmente. Así, un corpus nuevo nunca se marca, incluso cuando las reglas aplicadas a él ya se han ejecutado contra uno diferente.

Tres límites deliberados:

- **La cobertura se registra solo cuando hashcat agota el espacio de claves** (salida 1). Un ctrl-C o un error no registra nada, y tampoco lo hace la salida 0 — eso significa que todos los hashes se descifraron, lo que hashcat informa *sin* terminar el espacio de claves, y en el caso degenerado de "todos los hashes encontrados como entradas de potfile" sin probar un solo candidato. Un registro insuficiente solo cuesta una ejecución redundante más adelante.
- **Los generadores dinámicos de candidatos nunca se filtran.** PRINCE, PCFG, OMEN, la fuerza bruta de Markov y los modos LLM no tienen un conjunto fijo para comparar, por lo que se registran como ejecutados y por lo demás se dejan en paz. Los archivos de reglas encadenados (`-r a -r b`) se rastrean como una sola unidad en lugar de por entrada, porque hashcat aplica el *producto cartesiano* de los dos archivos y eliminar una línea individual eliminaría silenciosamente cada combinación en la que participara.
- **Las ejecuciones con `--loopback` se registran pero nunca se filtran.** hashcat reintroduce los textos planos recién descifrados como *candidatos adicionales*, por lo que dicha ejecución prueba la lista de palabras y el conjunto de reglas completos más lo que esos textos planos reciclados alcancen. Eso hace que las dos direcciones sean asimétricas: registrarlo es correcto, por lo que una ejecución ordinaria posterior de la misma lista de palabras y reglas se reconoce correctamente como una repetición, pero una segunda ejecución de loopback tiene más descifrados para reciclar y nunca se omite.

Establece `coverage_enabled` en `false` en `config.json` para desactivar esto, o pasa `--no-coverage` para una sola ejecución, que ni consulta ni actualiza el almacén.

#### Inspección y restablecimiento de la cobertura

La opción **85 — Attack Coverage** del menú principal muestra lo que se ha ejecutado contra el archivo de hash cargado, su historial de ejecuciones y puede borrarlo. Las mismas tres acciones se pueden automatizar:```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

El archivo hash se identifica por su contenido, por lo que esto funciona sin importar dónde se haya movido desde entonces. forget afecta solo a ese objetivo concreto: el almacén reside en ~/.hate_crack/coverage/attack_coverage.sqlite3, y eliminar el archivo restablece la cobertura para todos los objetivos.

Ejecuciones con script

Un ataque con script que la cobertura omite por completo sigue saliendo con 0 por defecto, por lo que habilitar la cobertura no puede empezar a hacer fallar un harness existente. Pasa --exit-code-on-skip para obtener el código de salida 3 en su lugar cuando no se haya lanzado nada:```bash hate_crack --exit-code-on-skip hashes.txt dict

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

Salida 3 significa que *nada* se ejecutó. Un pase parcialmente filtrado — algunas entradas
omitidas, algunas probadas — sigue saliendo con `0`, porque el ataque sí hizo trabajo.

### Notificaciones (opción de menú 82)

hate_crack puede enviar notificaciones push de Pushover cuando los ataques se completan y,
opcionalmente, cuando se descifran hashes individuales. Todos los controles viven bajo la
opción del menú principal `82 — Notificaciones`:

1. **Alternar Notificaciones Pushover [ON/OFF]** — interruptor principal. Se guarda en `config.json` como `notify_enabled`.
2. **Alternar Notificaciones por Descifrado [ON/OFF]** — cuando está ON, un observador en segundo plano vigila el archivo `.out` y envía una notificación por cada descifrado (con agregación por ráfagas por tick). Se guarda en `config.json` como `notify_per_crack_enabled`. No se puede activar mientras el interruptor principal esté OFF — active primero la opción 1.
3. **Enviar Notificación de Prueba Pushover** — dispara un push predefinido para que pueda confirmar que su par de token/usuario de Pushover funciona. Funciona incluso cuando el interruptor principal está OFF.

Las credenciales viven en `.env`; los demás ajustes de configuración son solo de archivo de configuración en `config.json`:

- `NOTIFY_PUSHOVER_TOKEN`, `NOTIFY_PUSHOVER_USER` (en `.env`) — requeridos para que cualquier push se dispare. Nada en el menú los escribe; edite `.env` usted mismo.
- `notify_attack_allowlist` — nombres de ataques que dan consentimiento automático sin el prompt `[y/N/always]`. Se rellena automáticamente cuando responde `always`.
- `notify_suppress_in_orchestrators` (por defecto `true`) — silencia los ataques individuales encadenados por Extensive Crack, que dispara un único resumen en su lugar. Establézcalo en `false` para recibir una notificación por ataque encadenado. Otras entradas de menú que ejecutan varios pases (por ejemplo Quick Crack con múltiples cadenas de reglas) no son orquestadores y siempre notifican por pase.
- `notify_max_cracks_per_burst` (por defecto `5`), `notify_poll_interval_seconds` (por defecto `5.0`) — ajustes del observador por descifrado. Consulte `hate_crack/notify/tailer.py` para la lógica de agregación por ráfagas.

### Herramientas de Listas de Palabras (opción de menú 80)

El submenú de Herramientas de Listas de Palabras proporciona utilidades de preprocesamiento de listas de palabras respaldadas por binarios de hashcat-utils, además de descargas de listas de palabras desde Hashmob.net y Weakpass. Acceso mediante la opción **80** en el menú principal.

| Opción | Binario | Qué hace |
|--------|---------|----------|
| 1 | `len.bin` | Filtrar por longitud - conservar solo palabras entre una longitud mínima y máxima |
| 2 | `req-include.bin` | Requerir clases de caracteres - conservar solo palabras que contengan todos los tipos de caracteres requeridos |
| 3 | `req-exclude.bin` | Excluir clases de caracteres - eliminar palabras que contengan cualquier tipo de carácter excluido |
| 4 | `cutb.bin` | Extraer subcadena - cortar un rango de bytes de cada palabra |
| 5 | `splitlen.bin` | Dividir por longitud - crear archivos separados por longitud de palabra (archivos nombrados `01`-`64` en un directorio de salida) |
| 6 | `rli.bin` / `rli2.bin` | Restar palabras - eliminar entradas que aparecen en uno o más archivos |
| 7 | `gate.bin` | Fragmentar - extraer cada N-ésima palabra para descifrado distribuido entre múltiples máquinas |
| 8 | - | Optimizar listas de palabras - deduplicar y dividir en archivos por longitud bajo el directorio de listas de palabras optimizadas |
| 9 | - | Descargar listas de palabras desde Hashmob.net |
| 10 | - | Descargar listas de palabras desde Weakpass (vía BitTorrent) |

**Bits de máscara de clases de caracteres** (usados por las opciones 2 y 3): `1`=minúsculas, `2`=mayúsculas, `4`=dígito, `8`=símbolo, `16`=otro. Sume los valores: `7` = minúsculas+mayúsculas+dígito.

**Cómo se debe usar la fragmentación**: la fragmentación divide una lista de palabras en N partes iguales y no superpuestas para que el trabajo pueda distribuirse entre múltiples máquinas o GPUs. Cada parte está *entrelazada* (cada N-ésima línea), por lo que cada fragmento es una muestra representativa de toda la lista en lugar de un bloque contiguo de inicio/fin — ningún nodo queda atascado descifrando solo la cola de baja probabilidad.

Ejecute la opción 7 una vez, proporciónele una lista de palabras de entrada, una ruta base de salida y un número de fragmentos (N). Escribe todas las N partes en un solo pase, nombradas con números de parte rellenados con ceros (`base.001`, `base.002`, … hasta `base.00N`). Copie una parte a cada nodo y apunte la ejecución de hashcat de ese nodo hacia ella. En un sistema de una sola GPU la fragmentación no da aceleración, pero una sola parte sigue siendo una muestra rápida y representativa para un pase de triaje antes de comprometerse con la lista completa.

#### Comprobaciones Automáticas de Actualizaciones

hate_crack puede comprobar automáticamente en GitHub si hay versiones más recientes al iniciar. Esta función está controlada por la opción de configuración `check_for_updates`:```json
{
  "check_for_updates": true
}

check_for_updates — Habilita la comprobación automática de versiones al inicio (predeterminado: true).
Cuando está habilitado, hate_crack obtiene la información de la última versión desde GitHub y muestra un aviso si hay una actualización disponible.
La comprobación se ejecuta de forma asíncrona y no bloquea el inicio. Los errores de red se ignoran silenciosamente.

Canales de Actualización

Canal	Flag	Fuente	Qué obtienes
Release	`--update`	`main`	La última versión publicada. Este es el predeterminado y lo que ofrece la comprobación de inicio.
Nightly	`--nightly`	`nightly-dev`	Trabajo que ha pasado CI pero aún no ha sido publicado.

Las versiones siguen el semver ordinario, con el incremento derivado de lo que realmente hay en el lote. El segundo componente se mueve solo para características: un ciclo que contenga cualquier commit feat se dirige a X.(Y+1).0, y un ciclo de solo correcciones, documentación y tareas menores se dirige a X.Y.(Z+1).

nightly-dev etiqueta candidatos de release para la versión hacia la que se dirige el lote — v2.20.1rc1, v2.20.1rc2, … — y la fusión hacia main promueve ese mismo objetivo a su release final. Los candidatos son pre-releases reales de PEP 440, por lo que se ordenan correctamente en ambos extremos:

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

El objetivo puede cambiar a mitad de ciclo: el primer feat que llegue lo mueve de X.Y.(Z+1) a X.(Y+1).0, y la numeración de candidatos se reinicia para el nuevo objetivo. El número siempre nombra lo que el lote publicaría hoy.

El componente mayor nunca se incrementa automáticamente — un asunto con ! o un pie de página BREAKING CHANGE: cuenta como una característica, porque un mayor automático está a una línea de asunto mal escrita de una publicación irreversible. Un mayor es un acto humano explícito: etiquétalo y envíalo manualmente.

La política reside en tools/next_version.py, compartida por ambos flujos de etiquetado y probada por unit tests en tests/test_next_version.py.

La comprobación de inicio solo ofrece releases, porque las compilaciones nightly no publican ningún release de GitHub y la comprobación lee el endpoint de "última release" de GitHub — por lo que habilitar check_for_updates nunca te llevará a una nightly. Dos cosas mantienen los canales separados ahora: eso, y el hecho de que un candidato es una pre-release genuina de PEP 440, por lo que una herramienta que clasifica números de versión crudos también lo trata como más antiguo que la release en la que se convierte.

Cualquiera de los dos flags cambia tu checkout a la rama correspondiente primero (y se niega a hacerlo si tienes cambios sin confirmar). Si estás ejecutando una nightly y quieres volver al código publicado, --update te devuelve a main.

Fusión Automática de Hashes Encontrados (Solo Descarga de Izquierda)

Al descargar hashes de la izquierda (hashes sin descifrar), hate_crack automáticamente:

Intenta descargar cualquier hash encontrado (descifrado) desde Hashview como una operación auxiliar
Fusiona los hashes encontrados con los archivos .out locales (p. ej., left_1_123.txt.out o left_1_123.nt.txt.out para formato pwdump)
Elimina entradas duplicadas
Limpia los archivos temporales divididos después de la fusión

Esto asegura que tus resultados de descifrado locales se mantengan sincronizados con la base de datos centralizada de Hashview cuando trabajas con hashes sin descifrar.

Nota: La opción de descargar encontrados descarga hashes ya descifrados por separado con fines de referencia y no realiza ninguna fusión ni solicita descifrado.

El <hash_type> se obtiene ejecutando 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

Pruebas

La suite de pruebas es mayormente offline y utiliza mocks/fixtures. Las comprobaciones de red en vivo y las comprobaciones de dependencias del sistema son opcionales mediante variables de entorno.

Ejecutar Pruebas Localmente```bash

Run all tests

uv run pytest -v

Run specific test

uv run pytest tests/test_hashview.py -v

Puedes ejecutar también la suite completa con `make test`.

### Pruebas en Vivo (Opt-In)

Establece cualquiera de las siguientes variables para habilitar comprobaciones en vivo:

- `HASHMOB_TEST_REAL=1` — comprobación en vivo de conectividad/menú CLI de Hashmob
- `HASHVIEW_TEST_REAL=1` — comprobación en vivo del menú CLI de Hashview
- `WEAKPASS_TEST_REAL=1` — comprobación en vivo del menú CLI de Weakpass
- `HATE_CRACK_REQUIRE_DEPS=1` — falla si falta `7z`, `transmission-daemon` o `transmission-remote`

### Prueba de Carga en Vivo de Hashview

La prueba de carga en vivo de Hashview se omite por defecto. Para ejecutarla, establece la
variable de entorno y proporciona credenciales válidas en `.env`:```bash
HATE_CRACK_RUN_LIVE_TESTS=1 uv run pytest tests/test_upload_cracked_hashes.py -v

Pruebas en Vivo de Hashview Contra una Pila Docker Local

En lugar de apuntar las pruebas en vivo a un servidor Hashview remoto, puedes hacer que el conjunto levante una pila Docker local de Hashview, la inicialice, ejecute las pruebas en vivo contra ella y la derribe. Establece HASHVIEW_TEST_LOCAL=1 y apunta HASHVIEW_REPO a un checkout de 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

Esto levanta `docker compose` en el repositorio de Hashview, siembra una clave de API de administrador,
un cliente, un archivo de hashes y datos de "tarea efectiva" crackeados, y luego exporta
las variables de entorno `HASHVIEW_*` que los tests leen. Variables de entorno útiles:

- `HASHVIEW_TEST_LOCAL=1` — habilita el stack local (sin efecto de otro modo)
- `HASHVIEW_REPO=<ruta>` — checkout de Hashview (por defecto `~/projects/hashview`)
- `HASHVIEW_KEEP=1` — deja los contenedores en ejecución tras la sesión (re-ejecuciones más rápidas)
- `HASHVIEW_LOCAL_PORT=5000` — puerto del host en el que se publica la app

El CLI de hate_crack respeta las variables de entorno `HASHVIEW_URL` / `HASHVIEW_API_KEY`
(anulando el `.env` donde viven esas dos claves), que es lo que permite a la
suite apuntar el CLI al stack local sin editar tu configuración persistida.

### Tests de Instalación de Extremo a Extremo (Local + Docker)

Instalación de la herramienta uv local + ejecución de scripts (usa un HOME temporal):```bash
HATE_CRACK_RUN_E2E=1 uv run pytest tests/test_e2e_local_install.py -v

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

La prueba E2E de Docker también descarga un pequeño subconjunto de rockyou y ejecuta un crack básico con hashcat para validar la integración con herramientas externas.

Prueba de extremo a extremo de la VM de Lima (solo macOS):

Requisitos previos: [Lima](https://lima-vm.io/) y `rsync` deben estar instalados.```bash
brew install lima

El VM de prueba se aprovisiona automáticamente con todas las dependencias de 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

Esta prueba valida la instalación y ejecución dentro de una VM Linux ligera en macOS.

### Estructura de pruebas

- **tests/test_hashview.py**: Suite de pruebas integral para la clase HashviewAPI con respuestas API simuladas, incluyendo:
  - Listado de clientes y validación de datos
  - Pruebas de autenticación y autorización
  - Funcionalidad de carga de archivos hash
  - Flujo completo de creación de trabajos

Todas las pruebas utilizan llamadas API simuladas, por lo que pueden ejecutarse sin conectividad a un servidor Hashview.

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

  (1) Crack rápido
  (2) Crack extenso con metodología Pure_Hate
  (3) Ataque de fuerza bruta
  (4) Ataque con máscara superior
  (5) Ataque de huella digital
  (6) Ataques combinatorios
  (7) Ataque híbrido
  (8) Crack de fuerza bruta con máscara Top 100 de Pathwell
  (9) Ataque PRINCE
  (10) Metodología Bandrel
  (11) Ataque de bucle invertido
  (12) Ataque LLM
  (13) Ataque OMEN
  (14) Ataque con máscara ad-hoc
  (15) Ataque de fuerza bruta Markov
  (16) Ataque N-gram
  (17) Ataque de permutación
  (18) Ataque con reglas aleatorias
  (19) Ataque de frase de contraseña Combipow
  (20) Ataque PCFG
  (21) Ataque PRINCE-LING
  (22) Ataque Spoonman
  (23) Ataque Rosetta
  (24) Fuerza bruta con máscaras corporativas
  (25) Ataque con máscara inteligente

  (80) Herramientas de listas de palabras
  (81) Herramientas de archivos de reglas
  (82) Notificaciones
  (83) Herramientas de máscaras

  (93) Regenerar .out desde archivo POT
  (94) API de Hashview
  (95) Analizar hashes con Pipal
  (96) Exportar salida a formato Excel
  (97) Mostrar hashes descifrados
  (98) Mostrar README
  (99) Salir

Seleccione una tarea:```

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.

¿Qué regla(s) te gustaría ejecutar? (1) best64.rule (2) d3ad0ne.rule (3) T0XlC.rule (4) dive.rule (99) YOLO...ejecutar todas las reglas Introduce una lista separada por comas de las reglas que te gustaría ejecutar. Para ejecutar reglas encadenadas usa el símbolo +. Por ejemplo, 1+1 ejecutará best64.rule encadenada dos veces y 1,2 ejecutará best64.rule y luego d3ad0ne.rule secuencialmente. Elige sabiamente:```

Extensive Pure_Hate Methodology Crack

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

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

Brute Force Attack

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

Top Mask Attack

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

Fingerprint Attack

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

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

Smart Mask Attack

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

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

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

Combinator Attack

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

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

Hybrid Attack

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

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

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

Pathwell Top 100 Mask Brute Force Crack

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

PRINCE Attack

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

Runs a PRINCE attack using wordlists/rockyou.txt

YOLO Combinator Attack

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

Middle Combinator Attack

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

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

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

Thorough Combinator Attack

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

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

Bandrel Methodology

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

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

Loopback Attack

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

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

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

LLM Attack

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

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

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

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

OMEN Attack

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

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

Combinator Attacks Submenu

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

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

Ad-hoc Mask Attack

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

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

Markov Brute Force Attack

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

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

N-gram Attack

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

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

Permutation Attack

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

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

Random Rules Attack

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

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

Combipow Passphrase Attack

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

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

PCFG Attack

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

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

PRINCE-LING Attack

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

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

Spoonman Attack

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

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

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

Rosetta Attack

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

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

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

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

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

Corporate Masks Brute Force

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

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

Wordlist Tools (option 80)

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

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

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

Rule File Tools (option 81)

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

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

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

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

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

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

Analyze Hashcat Rules (Rule File Tools option 5)

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

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

Mask Tools (option 83)

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

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

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

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

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

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

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

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

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

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

Hashmob Downloads (Wordlist Tools option 11)

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

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

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

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

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

Version History

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

hate_crack v2.19.0

Categorías