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

Instalación

Instalar desde el código fuente es la única vía admitida. hate_crack no se distribuye en PyPI: pip install hate-crack se resuelve a un marcador de posición 0.0.0 que falla a propósito y apunta de nuevo 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 usa dos archivos de configuración, cada uno con un conjunto distinto de ajustes:

• config.json — rutas de diccionarios, máscaras, reglas, ajustes, potfile, ruta de hashcat, límites de candidatos, notificaciones activables, valores predeterminados de preferencias CLI (35 ajustes).
• .env — solo ajustes de integración con terceros: credenciales de Hashview y Hashmob, credenciales de Pushover, Ollama y pipal (14 ajustes). No está en el repositorio git, se crea con modo 0600.

La línea cae 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 modo 0600; todo lo que hate_crack hace localmente permanece en config.json, que es seguro para compartir, comparar e incluir 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 activar/desactivar 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 de serie.

config.json es permanente y de primera clase — no está obsoleto ni tiene un calendario de eliminación. Solo se movieron los ajustes de integración.

¿Actualizas desde un solo 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 modo 0600, luego se eliminan de config.json para que ambos archivos no los reclamen a la vez. 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, incluyendo 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, copia la plantilla rastreada:```bash cp .env.example .env chmod 600 .env

`.env.example` está confirmado en el repositorio y se distribuye con todas las claves de credenciales vacías. El propio `.env` **nunca** debe confirmarse: está en gitignore, junto con sus variantes habituales de respaldo, y hate_crack siempre lo crea con modo `0600` (solo lectura/escritura para el propietario). `.env.example` se genera a partir del esquema; regenéralo después de cambiar `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, que solo contiene datos
- Dependencias de Python mediante uv y un shim de 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 utiliza 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: helpers de argparse y anulaciones de configuración.
• hate_crack/api.py: integraciones con Hashview, Weakpass y Hashmob (descargas/menús/helpers).
• hate_crack/attacks.py: manejadores de ataques del menú.
• hate_crack/hashmob_wordlist.py: utilidades de listas de palabras de Hashmob (wrapper fino; llama a api.py).
• 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 a partir de una línea del corpus (eliminación del prefijo de hash, decodificación $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, incluyendo navegación opcional con teclas de flecha.
• hate_crack/noninteractive.py: despachador para los subcomandos de ataque automatizados.
• hate_crack/notify/: paquete de notificaciones (backend Pushover, tailer por crack).
• hate_crack/username_detect.py: detecta archivos de entrada username:hash para decidir el uso de --username de hashcat.
• hate_crack/formatting.py, hate_crack/progress.py: helpers 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 diversos proyectos y servicios externos. Gracias a:

• Hashview (http://github.com/hashview/)
• Weakpass (https://weakpass.com)
• Hashmob (https://hashmob.net)

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 con `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 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 sin importar 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 únicamente 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 utiliza un shebang `uv`. Hazlo ejecutable y ejecuta:```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 solo 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, imprimiendo 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 fue reescrito
entonces para eliminar algunos archivos que nunca deberían haberse confirmado, lo que asignó
a cada commit un nuevo ID; por lo tanto, las etiquetas de un clon 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 reset ú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), haz commit de ello 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 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 manualmente 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/` → incluidos 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 utilizado por Quick Crack; si no se encuentra, recurre a hcatWordlists)
• rules_directory: ./hashcat/rules (incluye reglas de submódulos)
• hcatTuning: `` (cadena vacía: sin flags de ajuste predeterminados)

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 (`.env` o `config.json`) > valor predeterminado integrado
- Las claves que falten recurren a los valores predeterminados integrados; `config.json.example` documenta cada clave de `config.json`
- Ambos archivos se buscan, independientemente entre sí, en este orden: **raíz del repositorio**, luego el **directorio del paquete instalado** y luego **`~/.hate_crack`**. Gana la primera coincidencia; 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` y `.env` a partir de los valores predeterminados integrados. Si un `config.json` anterior todavía contiene claves de integración, se copian al nuevo `.env` y hate_crack te indica cuáles eliminar de `config.json`; nunca edita ese archivo por sí mismo.
- En cada ejecución, hate_crack muestra 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:

• Una copia de trabajo tiene prioridad sobre tu directorio personal. La raíz del repositorio se busca primero, por lo que un .env o config.json situado en cualquier copia de trabajo desde la que ejecutes la herramienta gana sobre el que está en ~/.hate_crack — y ejecutar la herramienta desde una copia de trabajo es exactamente lo que crea esos archivos allí en primer lugar. Si esto alguna vez oculta 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 está siendo ignorado", 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 es ignorado deliberadamente: los directorios de engagement están llenos de archivos que nadie pretendía que fueran configuración. Ponlo en la raíz del repositorio o en ~/.hate_crack.

Error: merge con ref 'refs/heads/master' pero no se obtuvo dicha ref

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

La rama predeterminada se renombró 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 submódulos, instala dependencias e instala la herramienta:```bash make

or explicitly:

make install

Esto es idempotente - omite las herramientas ya instaladas.

**Forzar una 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

Compilar 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

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

Desarrollo

Configuración del entorno de desarrollo

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

### Ejecutando 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 formateo):**```bash
make ruff
# or manually:
uv run ruff check hate_crack tests tools packaging hate_crack.py

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

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

### Ejecutar pruebas

Las pruebas detectan automáticamente cuándo 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 pre-commit local-repo:

• pre-push (hooks locales): ruff, ruff-format, ty, pytest, pytest-lima, bandit
• pre-commit (desde 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-fixers de pre-commit reescriben los archivos en su lugar, así que vuelve a añadirlos al área de staging y haz commit 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.

Navegación por menú con teclas de flecha

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

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

Dependencias de desarrollo

El grupo opcional [dev] incluye:

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

Opciones comunes:

• --download-hashview: Descarga hashes de Hashview antes de crackear.
• --hashview: Menú interactivo de Hashview para gestionar hashes, wordlists y trabajos.
• --hashview --help: Muestra las opciones de línea de comandos de Hashview.
• --weakpass: Descarga wordlists de Weakpass.
• --hashmob: Descarga wordlists de Hashmob.net.
• --download-torrent <FILENAME>: Descarga un archivo torrent específico de Weakpass.
• --download-all-torrents: Descarga todos los torrents disponibles de Weakpass desde la caché.
• --wordlists-dir <PATH> / --optimized-wordlists-dir <PATH>: Sobrescribe los directorios de wordlists.
• --pipal-path <PATH>: Sobrescribe la ruta de pipal.
• --restore-potfile: Reconstruye <hashfile>.out a partir del archivo POT de hashcat al iniciar, reemplazando cualquier contenido existente, y luego continúa con el menú normal. Sin esta opción, 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 aviso de confirmación.
• --maxruntime <SECONDS>: Sobrescribe el tiempo máximo de ejecución.
• --bandrel-basewords <PATH>: Sobrescribe el archivo de basewords de bandrel.
• --update: Actualiza a la última versión y reinstala. Cambia el checkout a main si está en otra rama, ya que las etiquetas de lanzamiento viven allí.
• --nightly: Actualiza a la última versión nightly en su lugar, desde la rama nightly-dev. Las nightlies han pasado la CI pero no forman parte de un lanzamiento publicado. También se puede escribir --update --nightly.
• --no-optimized-kernel (o --no-optimize): No pases -O a hashcat en toda la ejecución. Sobrescribe optimizedKernelAttacks en config.json y elimina cualquier -O que pongas en hcatTuning. No se escribe nada de vuelta en la configuración, así que solo se aplica 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: Habilita 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.

Menú interactivo

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

Opciones del menú:
- **(1) Subir Hashes Crackeados** - Sube los resultados crackeados de la sesión actual a Hashview
- **(2) Subir Wordlist** - Sube un archivo de wordlist a Hashview
- **(3) Descargar Wordlist** - Descarga una wordlist de Hashview
- **Descargar Regla** - Descarga un archivo de reglas de Hashview (descomprimido a texto plano, listo para `hashcat -r`)
- **(4) Descargar Hashes Restantes** - Descarga los hashes que aún no han sido crackeados (pregunta si deseas cambiar para el crackeo)
- **(5) Descargar Hashes Encontrados** - Descarga los hashes ya crackeados con contraseñas en texto claro (para referencia/análisis)
- **(6) Subir Hashfile y Crear Trabajo** - Sube un nuevo hashfile y crea un trabajo de crackeo
- **(99) Volver al Menú Principal** - Regresa al menú principal

**Importante: Descargar encontrados vs descargar restantes**
- **Descargar Hashes Restantes (4)**: Descarga los hashes no crackeados que necesitan ser crackeados. Se combina automáticamente con cualquier hash encontrado si está disponible, y pregunta si deseas cambiar a este hashfile para el crackeo.
- **Descargar Hashes Encontrados (5)**: Descarga los hashes ya crackeados en formato hash:cleartext. Estos son solo para referencia y no se pueden crackear más. No se muestra ninguna solicitud de cambio.

#### Interfaz de Línea de Comandos

Las operaciones de Hashview también se pueden realizar desde la línea de comandos:

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

Subir una wordlist:```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

Descargar hashes restantes (hashes sin descifrar para crackear):```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

Cargar el archivo hash y crear 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 de Ollama

El ataque con LLM (opción 12) utiliza Ollama para generar candidatos de contraseña. Configure el modelo, la ventana de contexto y el tiempo de espera de solicitud en .env:``` OLLAMA_MODEL=qwen2.5:32b OLLAMA_NUM_CTX=8192 OLLAMA_TIMEOUT=300

- **`OLLAMA_MODEL`** — El modelo de Ollama utilizado para la generación de candidatos (por defecto: `qwen2.5:32b`). El ataque LLM utiliza salida estructurada (JSON), así que elige un modelo con buen soporte para herramientas/JSON.
- **`OLLAMA_NUM_CTX`** — Tamaño de la ventana de contexto para el modelo (por defecto: `8192`). Antes de que se introdujeran las estadísticas del corpus era `2048`, 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 que se espera una respuesta de generación antes de rendirse (por defecto: `300`). Auméntalo si un modelo grande todavía está cargándose en la 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 este ajuste cuando eso ocurre.
- **`OLLAMA_MAX_SAMPLE_LINES`** — El umbral por debajo del cual los modos LLM también pegan los textos planos literales en el prompt (por defecto: `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 un fragmento del mismo. La agregación está acotada, de modo que un volcado de 120.000 contraseñas ocupa aproximadamente el mismo espacio de prompt que uno de 500 líneas. Cuando todo el corpus cabe por debajo de este umbral, los textos planos crudos 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 ninguna información de frecuencia: 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 merezca la pena probar una conjetura.
- **`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 dependen de este único ajuste: Ollama proxifica un modelo con etiqueta `-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 configurada del backend: un destino que no sea loopback, privado o link-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 a prueba de fallos, en lugar de dejar pasar un destino no verificable. Los prompts de hate_crack contienen textos planos recuperados, estadísticas del corpus y el nombre, sector y ubicación del cliente, por lo que si cualquiera de las dos comprobaciones se activa, la solicitud se rechaza antes de construirse. El valor por defecto es `false`, para que un modelo en la nube o un servidor remoto configurado deliberadamente siga funcionando; actívalo para compromisos en los que los datos del cliente no deban salir del host.
- **`OLLAMA_AUTO_RESEARCH`** — Cuando es `true` (por defecto), el modo **Target info** pide al modelo local que sugiera el sector, la ubicación y la empresa matriz / historial de adquisiciones en cuanto has escrito el nombre de la empresa, y los ofrece como valores predeterminados editables del prompt. Ponlo en `false` para tener 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 Ollama. 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 por defecto es `localhost:11434`. 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.
- Asegúrate de que Ollama esté en ejecución y el modelo esté descargado (`ollama pull qwen2.5:32b`) antes de usar el ataque LLM: hate_crack ya no descarga automáticamente los modelos que faltan.

El ataque ofrece tres modos de generación:

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

   Después de que escribas el nombre de la empresa, hate_crack pregunta al mismo modelo local qué sabe ya sobre esa organización y rellena automáticamente 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:

Pulse Enter para aceptar una sugerencia o escriba sobre ella. Estos valores son el recuerdo del modelo, no OSINT — trátelos 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 habitual en clientes pequeños), no devuelve nada y obtiene simples prompts en blanco: ``` Company name: Acme Rail Services Industry: Location: Parent company / acquired by:

Un fallo de investigación — timeout, Ollama no ejecutándose, respuesta vacía — nunca bloquea el ataque; simplemente recurre a prompts en blanco. Configura `ollamaAutoResearch` en `false` para omitir la investigación por completo.
2. **Wordlist** — deriva palabras base de una wordlist de muestra.
3. **Contraseñas crackeadas** — alimenta al modelo con los textos planos ya recuperados en esta sesión (`<hashfile>.out`) para que pueda inferir las convenciones de contraseñas propias 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 crackeado al menos un hash; el archivo completo se analiza estadísticamente exactamente igual que en el modo Wordlist (ver `ollamaMaxSampleLines` arriba).

#### Configuración de PCFG

El ataque PCFG (opción 20) y el ataque PRINCE-LING (opción 21) usan 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 wordlist base de PRINCE cacheada (por defecto: 10000000).

Kernels optimizados (optimizedKernelAttacks)

La opción -O de hashcat selecciona kernels optimizados, que son sustancialmente más rápidos pero limitan la longitud del candidato (aproximadamente 31 caracteres, menos 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 el ajuste pero no están optimizados por defecto, porque alimentan candidatos que pueden superar el límite de -O — añádelos a la lista para optar por ello:

• hcatNgramX, hcatOllama, hcatOmen, hcatLMtoNT

Para desactivar -O en todas partes en una sola ejecución sin editar la configuración, pasa --no-optimized-kernel (forma corta --no-optimize). Esto 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 son 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 prolongado, el mismo archivo de hashes se ataca en muchas sesiones con un conjunto rotatorio de wordlists, archivos de reglas y listas de máscaras, y es fácil quemar horas reejecutando 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 hashes y ofrece omitir la superposición.

La cobertura se registra por entrada, no por archivo: líneas de regla individuales y líneas .hcmask individuales, cada una emparejada con la wordlist 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 lo que una regla solo está "cubierta" para la wordlist específica con la que se probó — las mismas reglas sobre un corpus diferente prueban candidatos completamente diferentes.

El archivo de hashes se identifica por un sha256 de su contenido, por lo que la cobertura sobrevive a renombrarlo o moverlo entre sesiones. Las wordlists se identifican de la misma manera, con el digest memorizado según tamaño y mtime para que un corpus de varios gigabytes se hashee una vez en lugar de en cada ataque.

Solo se te pregunta 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 crea un archivo de reglas temporal que contiene solo las entradas sin
probar; responde `n` para ejecutarlo de todos modos. Si *todas* las entradas son repetidas
se te pregunta si quieres omitir el ataque por completo, por lo que volver a ejecutar
terreno ya cubierto nunca requiere reiniciar la herramienta.

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

Tres límites deliberados:

- **La cobertura se registra solo cuando hashcat agota el espacio de claves** (exit 1). Un
  ctrl-C o un error no registra nada, y exit 0 tampoco — eso significa que cada
  hash descifrado, que hashcat reporta *sin* terminar el espacio de claves, y en
  el caso degenerado de "todos los hashes encontrados como entradas del potfile" sin probar un
  solo candidato. Registrar de menos 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 que comparar, por lo que se
  registran como ejecutados y por lo demás se les deja 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 todas las combinaciones en las que participaba.
- **Las ejecuciones con `--loopback` se registran pero nunca se filtran.** hashcat introduce los
  textos planos recién descifrados de nuevo como candidatos *extra*, por lo que esa ejecución prueba el
  diccionario y el conjunto de reglas completos más lo que puedan alcanzar esos textos planos reciclados. Eso hace
  que las dos direcciones sean asimétricas: registrarlo es correcto, así una ejecución ordinaria posterior
  con el mismo diccionario y reglas se reconoce correctamente como repetición, pero una
  segunda ejecución con 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.

#### Inspeccionar y restablecer la cobertura

La opción **85 — Attack Coverage** del menú principal muestra lo que se ha ejecutado contra el
archivo de hashes cargado, su historial de ejecuciones, y puede borrarlo. Las mismas tres acciones son
automatizables:```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, así que esto funciona sin importar dónde se haya movido desde entonces. forget afecta solo a ese objetivo concreto: el almacén vive 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 código 0 por defecto, por lo que activar 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 lanza nada:```bash hate_crack --exit-code-on-skip hashes.txt dict

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

El código de salida 3 significa que *nada* se ejecutó. Una pasada que fue filtrada parcialmente — algunas entradas omitidas, otras probadas — todavía sale 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 terminan y, opcionalmente, cuando se descifran hashes individuales. Todos los controles se encuentran en la opción `82 — Notifications` del menú principal:

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

Las credenciales se guardan en `.env`; los demás parámetros de ajuste solo están en el archivo de configuración `config.json`:

- `NOTIFY_PUSHOVER_TOKEN`, `NOTIFY_PUSHOVER_USER` (en `.env`) — necesarios para que se dispare cualquier push. Nada en el menú los escribe; edite `.env` usted mismo.
- `notify_attack_allowlist` — nombres de ataque que dan consentimiento automático sin la pregunta `[y/N/always]`. Se completa automáticamente cuando responde `always`.
- `notify_suppress_in_orchestrators` (predeterminado `true`) — silencia los ataques individuales encadenados por Extensive Crack, que dispara un único resumen en su lugar. Póngalo en `false` para recibir una notificación por cada ataque encadenado. Otras entradas del menú que ejecutan varias pasadas (por ejemplo, Quick Crack con múltiples cadenas de reglas) no son orquestadores y siempre notifican por pasada.
- `notify_max_cracks_per_burst` (predeterminado `5`), `notify_poll_interval_seconds` (predeterminado `5.0`) — ajuste del observador por crack. Consulte `hate_crack/notify/tailer.py` para la lógica de agregación de 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 basadas en los binarios de hashcat-utils, además de descargas de listas de palabras desde Hashmob.net y Weakpass. Acceso mediante la opción **80** del menú principal.

| Opción | Binario | Qué hace |
|--------|--------|--------------|
| 1 | `len.bin` | Filtrar por longitud: conservar solo las palabras entre una longitud mínima y máxima |
| 2 | `req-include.bin` | Requerir clases de caracteres: conservar solo las palabras que contienen todos los tipos de caracteres requeridos |
| 3 | `req-exclude.bin` | Excluir clases de caracteres: eliminar palabras que contienen 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 llamados `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 (shard): extraer cada N-ésima palabra para el descifrado distribuido entre varias 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 (a través de 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 (sharding)**: la fragmentación divide una lista de palabras en N partes iguales y no superpuestas para que el trabajo pueda distribuirse entre varias máquinas o GPUs. Cada parte está *intercalada* (cada N-ésima línea), de modo que cada fragmento es una muestra representativa de toda la lista en lugar de un bloque contiguo del principio/final — ningún nodo se queda atascado descifrando solo la cola de baja probabilidad.

Ejecute la opción 7 una vez, indique una lista de palabras de entrada, una ruta base de salida y un número de fragmentos (N). Escribe las N partes en una sola pasada, nombradas con números de parte con ceros a la izquierda (`base.001`, `base.002`, … hasta `base.00N`). Copie una parte a cada nodo y apunte la ejecución de hashcat de ese nodo a esa parte. 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 una pasada de triaje antes de comprometerse con la lista completa.

#### Comprobación automática de actualizaciones

hate_crack puede comprobar automáticamente en GitHub si hay versiones más recientes al inicio. Esta función se controla mediante 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 (por defecto: 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

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

nightly-dev etiqueta candidatos a release para la versión a 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 del 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 indica la versión que el lote publicaría hoy.

El componente major nunca se incrementa automáticamente — un asunto con ! o un pie con BREAKING CHANGE: cuenta como funcionalidad, porque un major automático está a una línea de asunto mal escrita de una publicación irreversible. Un major es un acto humano explícito: etiquetarlo y subirlo manualmente.

La política se encuentra en tools/next_version.py, compartida por ambos flujos de trabajo de etiquetado y probada mediante pruebas unitarias en tests/test_next_version.py.

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

Cualquiera de los dos flags cambia primero tu checkout a la rama correspondiente (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 al descargar left)

Al descargar hashes left (hashes sin descifrar), hate_crack automáticamente:

1. Intenta descargar los hashes encontrados (descifrados) de Hashview como operación auxiliar
2. Fusiona los hashes encontrados con los archivos .out locales (p. ej., left_1_123.txt.out o left_1_123.nt.txt.out para el formato pwdump)
3. Elimina las entradas duplicadas
4. Limpia los archivos divididos temporales después de la fusión

Esto garantiza que tus resultados de cracking locales permanezcan sincronizados con la base de datos centralizada de Hashview cuando trabajas con hashes sin descifrar.

Nota: La opción download-found descarga los hashes ya descifrados por separado con fines de referencia y no realiza ninguna fusión ni solicita el descifrado.

El <hash_type> se obtiene ejecutando hashcat --help

Hashes de ejemplo: http://hashcat.net/wiki/doku.php?id=example_hashes``` $ hashcat --help |grep -i ntlm 5500 | NetNTLMv1 | Network protocols 5500 | NetNTLMv1 + ESS | Network protocols 5600 | NetNTLMv2 | Network protocols 1000 | NTLM | Operating-Systems

I don't see any translation source text in your message. The input chunk appears to be empty. Please paste the source chunk content so I can translate it.```
$ ./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

También puedes ejecutar la suite completa con `make test`.

### Pruebas en vivo (opt-in)

Configura cualquiera de las siguientes opciones para habilitar las comprobaciones en vivo:

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

### Prueba de subida en vivo de Hashview

La prueba de subida en vivo de Hashview se omite por defecto. Para ejecutarla, define 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 de Hashview en vivo contra un stack Docker local

En lugar de apuntar las pruebas en vivo a un servidor Hashview remoto, puedes hacer que la suite levante un stack Docker local de Hashview, lo inicialice, ejecute las pruebas en vivo contra él y lo 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 hash y datos descifrados de "tarea efectiva", y luego exporta
las variables de entorno `HASHVIEW_*` que las pruebas leen. Variables de entorno útiles:

- `HASHVIEW_TEST_LOCAL=1` — habilita el stack local (no-op en caso contrario)
- `HASHVIEW_REPO=<path>` — 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 aplicación

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

### Pruebas 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

Instalación/ejecución de extremo a extremo basada en Docker (almacenada en caché mediante Dockerfile.test):```bash HATE_CRACK_RUN_DOCKER_TESTS=1 uv run pytest tests/test_docker_script_install.py -v

The Docker E2E test also downloads a small subset of rockyou and runs a basic
hashcat crack to validate external tool integration.

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

La 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 la prueba

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

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

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

  (1) Crack rápido
  (2) Crack extenso con la metodología Pure_Hate
  (3) Ataque de fuerza bruta
  (4) Ataque de máscara superior
  (5) Ataque de huella digital
  (6) Ataques combinatorios
  (7) Ataque híbrido
  (8) Crack de fuerza bruta con máscaras Top 100 de Pathwell
  (9) Ataque PRINCE
  (10) Metodología Bandrel
  (11) Ataque loopback
  (12) Ataque LLM
  (13) Ataque OMEN
  (14) Ataque de máscara ad hoc
  (15) Ataque de fuerza bruta Markov
  (16) Ataque de n-gramas
  (17) Ataque de permutación
  (18) Ataque de 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 de máscaras corporativas
  (25) Ataque de máscara inteligente

  (80) Herramientas de listas de palabras
  (81) Herramientas de archivos de reglas
  (82) Notificaciones

  (93) Regenerar .out a partir del archivo POT
  (94) API de Hashview
  (95) Analizar hashes con Pipal
  (96) Exportar la 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.

¿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. For each pattern found, runs a targeted -a 3 mask attack (using the exact observed literal text and an inferred charset for the varying part) against the full remaining hash list, so other accounts sharing that stem get swept up even though brute-forcing the stem itself was never tried. Prompts once, before the attack starts, for an optional candidate-count guardrail (default 50,000,000,000; 0 disables it).

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 several hybrid attacks using the "rockyou.txt" wordlists.
  • Hybrid Wordlist + Mask - ?s?d wordlists/rockyou.txt ?1?1
  • Hybrid Wordlist + Mask - ?s?d wordlists/rockyou.txt ?1?1?1
  • Hybrid Wordlist + Mask - ?s?d wordlists/rockyou.txt ?1?1?1?1
  • Hybrid Mask + Wordlist - ?s?d ?1?1 wordlists/rockyou.txt
  • Hybrid Mask + Wordlist - ?s?d ?1?1?1 wordlists/rockyou.txt
  • Hybrid Mask + Wordlist - ?s?d ?1?1?1?1 wordlists/rockyou.txt

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 Ollama instance to generate password candidates for a capture-the-flag scenario. Prompts for the fake company name, industry, location, and parent company / acquisition history, then sends these details to the configured LLM model to produce likely password candidates using industry terms and company name permutations. The generated candidates are fed into a hashcat wordlist+rules attack.

• Requires a running Ollama instance (default: http://localhost:11434, override with OLLAMA_HOST in .env or the environment) with the model already pulled — hate_crack does not auto-pull
• Candidate generation uses structured (JSON) output via Atomic Agents, so pick a model with good schema adherence (default: qwen2.5:32b)
• Configurable model, context window, request timeout, and sample size via .env (see Ollama Configuration below)
• 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
• 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.

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

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

Weakpass Wordlist Menu (Wordlist Tools option 10)

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

Version History

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