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

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

إذا قمت بالاستنساخ بدون وحدات فرعية، فقم بتهيئتها:```bash
git submodule update --init --recursive

`.env.example` مُدرج في المستودع ويأتي وكل مفاتيح الاعتماد فيه فارغة. أما `.env` نفسه فيجب **أبدًا** عدم إضافته إلى المستودع — فهو مستبعد في git، إلى جانب صيغ النسخ الاحتياطي المعتادة له، وينشئه hate_crack دائمًا بصلاحيات `0600` (قراءة/كتابة للمالك فقط). `.env.example` يُولَّد من المخطط؛ أعد توليده بعد تعديل `hate_crack/config_schema.py` باستخدام `uv run python -m hate_crack.config_writer`.

### 3. تثبيت التبعيات و hate_crack

الطريقة الأسهل هي تشغيل `make` (أو `make install`)، إذ يكتشف نظام تشغيلك تلقائيًا ويقوم بتثبيت:
- التبعيات الخارجية (p7zip, transmission-daemon / transmission-remote)
- بناء الوحدات الفرعية (hashcat-utils, princeprocessor, pcfg_cracker, واختياريًا omen)
- تبعيات Python عبر uv ووسيط CLI في `~/.local/bin/hate_crack````bash
make

**أو ثبّت التبعيات يدويًا:**

### التبعيات الخارجية
هذه مطلوبة لبعض عمليات التنزيل/الاستخراج:

- `7z`/`7za` (p7zip) — تُستخدم لاستخراج أرشيفات `.7z`.
- `transmission-daemon` / `transmission-remote` — تُستخدم لتنزيل تورنتات Weakpass.

أوامر التثبيت اليدوي:

Ubuntu/Kali:```bash
sudo apt-get update
sudo apt-get install -y p7zip-full transmission-daemon

ثم قم بتثبيت تبعيات Python و CLI shim:```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

بدلاً من ذلك، قم بالتشغيل عبر `uv`:```bash
uv run hate_crack.py <hash_file> <hash_type>

يُنشئ أمر `make install` غلاف bash (shim) في `~/.local/bin/hate_crack` يعمل من دليل المستودع، لذا يتم العثور دائمًا على الإعدادات والموارد بغض النظر عن دليل العمل الحالي.

كما يتم البحث عن الإعدادات في:
- جذر المستودع ودليل الحزمة
- `~/.hate_crack`

**ملاحظة:** إن `hcatPath` في `config.json` مخصص لموقع ملف hashcat الثنائي فقط (اختياري إذا كان hashcat في PATH). يتم تحميل موارد Hate_crack (hashcat-utils، princeprocessor، pcfg_cracker، omen) من دليل المستودع وتضمينها تلقائيًا بواسطة `make install`.

### التشغيل كسكربت
يستخدم السكربت shebang الخاص بـ `uv`. اجعله قابلاً للتنفيذ ثم شغّله:```bash
chmod +x hate_crack.py
./hate_crack.py

### الاستخدام غير التفاعلي / عبر السكربتات

لأتمتة العمليات، يمكنك تشغيل هجوم واحد مباشرةً، متجاوزًا القائمة. اسم الهجوم هو الوسيط الأول، يليه ملف الهاش ونوع هاش hashcat. في هذا الوضع، تقبل مطالبات المعالجة المسبقة (تصفية حسابات الكمبيوتر، هجوم القوة العمياء بـ LM أولاً، إزالة تكرار الحسابات) قيمها الافتراضية تلقائيًا. تنتهي العملية برمز الخروج `0` عند النجاح، وبقيمة غير صفرية عند حدوث خطأ (ملف هاش مفقود، نوع هاش غير رقمي، قائمة كلمات مفقودة، أو اسم ملف قواعد غير معروف).```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

يؤثّر هذا على النسخ المُستنسَخة التي أُنشئت قبل يوليو 2026. أُعيدت كتابة التاريخ المنشور
آنذاك لإزالة بعض الملفات التي كان ينبغي ألا تُرسَل أبدًا، مما أعطى
كلّ commit مُعرّفًا جديدًا؛ لذلك تشير tags الخاصة بنسخة مستنسَخة أقدم إلى كائنات لم
يعد هذا المستودع يحتويها، ويرفض git نقل tag يملكه بالفعل.
لا يوجد خطأ في نسختك ولا توجد أي بيانات تكسير معرّضة للخطر.

استعد بإجراء reset لمرة واحدة. هذا يتجاهل الـ commits والتحريرات المحلية في
النسخة، لذا إذا كنت قد خصصت أي شيء يتتبّعه git (على عكس
`config.json`، الذي لا يتتبّعه git)، فقم بتسجيله في فرع أولًا:```bash
cd /path/to/hate_crack
git fetch --tags --force origin
git checkout -B main origin/main
make install

هذا يعني أن أصول hate_crack لم تُضمَّن في الحزمة المثبتة.

**فهم المسارات:**
- `hcatPath` في config.json → يشير إلى **موقع ملف hashcat التنفيذي** (اختياري، يمكن أن يكون في PATH)
- `hashcat-utils/` و `princeprocessor/` → مضمّنان في الحزمة عبر `make install`

**الحل:**
أعد التثبيت باستخدام Makefile، الذي يبني الوحدات الفرعية ويقوم بتثبيت الأداة:```bash
cd /path/to/hate_crack  # the repository checkout
make install

**تحميل الإعدادات:**
- أولوية كل مفتاح: `os.environ` > ملفّه الرئيسي الخاص (`.env` أو `config.json`) > القيمة الافتراضية المضمّنة
- المفاتيح المفقودة تعود إلى القيم الافتراضية المضمّنة؛ يوثّق `config.json.example` كل مفتاح في `config.json`
- يتم البحث عن كلا الملفين، بشكل مستقل عن بعضهما البعض، بهذا الترتيب: **جذر المستودع (repo root)**، ثم **دليل الحزمة المثبّتة**، ثم **`~/.hate_crack`**. الملف الأول الذي يُعثر عليه هو المستخدم؛ ومن الطبيعي أن يأتي الملفان من دليلين مختلفين.
- عند أول تشغيل، يتم إنشاء كليهما — `config.json` من `config.json.example`، و`.env` من القيم الافتراضية المضمّنة. إذا كان `config.json` قديمًا لا يزال يحتفظ بمفاتيح التكامل، فسيتم نسخها إلى `.env` الجديد، وسيخبرك hate_crack أيّها يجب حذفه من `config.json`؛ وهو لا يعدّل هذا الملف بنفسه أبدًا.
- في كل تشغيل، يطبع hate_crack الملفين اللذين حمّلهما فعليًا:  ```
  [*] config.json: /home/you/.hate_crack/config.json
  [*] .env:        /home/you/.hate_crack/.env

تمت إعادة تسمية الفرع الافتراضي من `master` إلى `main`. الإصلاح باستخدام:```bash
git remote set-head origin -a
git branch -m master main
git branch --set-upstream-to=origin/main main
git pull

هذه العملية idempotent - فهي تتخطى الأدوات المثبتة بالفعل.

**إعادة التثبيت النظيفة الإجبارية:**```bash
make reinstall

**إلغاء التثبيت** - يزيل تبعيات نظام التشغيل والأداة:```bash
make uninstall

**تشغيل الاختبارات** - يتعامل تلقائيًا مع HATE_CRACK_SKIP_INIT عند الحاجة:```bash
make test

**تنظيف مخرجات البناء/الاختبار:**```bash
make clean

### تشغيل أدوات الفحص والتحقق من الأنواع

قبل دفع التغييرات، قم بتشغيل هذه الفحوصات محليًا. استخدم `make lint` لكل شيء، أو قم بتشغيل فحوصات فردية:

**Ruff (الفحص والتنسيق):**```bash
make ruff
# or manually:
uv run ruff check hate_crack tests tools packaging hate_crack.py

**ty (التحقق من الأنواع):**```bash
make ty
# or manually:
uv run ty check hate_crack

### تشغيل الاختبارات

تكتشف الاختبارات تلقائيًا عندما لا تكون الوحدات الفرعية مبنية وتضبط `HATE_CRACK_SKIP_INIT=1` تلقائيًا.```bash
make test

مع التغطية:```bash
make coverage

### Git Hooks (prek)

تتم إدارة Git Hooks بواسطة [prek](https://github.com/j178/prek) (v0.3.3+). قم بتثبيت الخطافات باستخدام:```bash
prek install --hook-type pre-push --hook-type pre-commit

خيارات القائمة:
- **(1) رفع الهاشات المكسورة** - رفع النتائج المكسورة من الجلسة الحالية إلى Hashview
- **(2) رفع قائمة الكلمات** - رفع ملف قائمة كلمات إلى Hashview
- **(3) تنزيل قائمة الكلمات** - تنزيل قائمة كلمات من Hashview
- **تنزيل القاعدة** - تنزيل ملف قواعد من Hashview (مفكوك الضغط إلى نص صريح، جاهز لـ `hashcat -r`)
- **(4) تنزيل الهاشات المتبقية** - تنزيل الهاشات غير المكسورة المتبقية (يطلب التبديل للكسر)
- **(5) تنزيل الهاشات التي تم العثور عليها** - تنزيل الهاشات المكسورة بالفعل مع كلمات المرور بنص واضح (للرجوع إليها/التحليل)
- **(6) رفع ملف هاش وإنشاء مهمة** - رفع ملف هاش جديد وإنشاء مهمة كسر
- **(99) العودة إلى القائمة الرئيسية** - العودة إلى القائمة الرئيسية

**مهم: تنزيل الهاشات التي تم العثور عليها مقابل تنزيل الهاشات المتبقية**
- **تنزيل الهاشات المتبقية (4)**: يقوم بتنزيل الهاشات غير المكسورة التي تحتاج إلى كسر. يدمج تلقائيًا مع أي هاشات تم العثور عليها إذا كانت متاحة، ويطلب التبديل إلى ملف الهاش هذا للكسر.
- **تنزيل الهاشات التي تم العثور عليها (5)**: يقوم بتنزيل الهاشات المكسورة بالفعل بتنسيق hash:cleartext. هذه للرجوع إليها ولا يمكن كسرها أكثر. لا تظهر رسالة تبديل.

#### واجهة سطر الأوامر

يمكن أيضًا تنفيذ عمليات Hashview عبر سطر الأوامر:

رفع الهاشات المكسورة:```bash
hate_crack.py --hashview upload-cracked --file <output_file>.out --hash-type 1000

قم بتنزيل ملف القواعد (محفوظًا وغير مضغوط، جاهزًا لـ `hashcat -r`):```bash
hate_crack.py --hashview download-rules --rules-id 4 --output best64.rule

تحميل الهاشات التي تم العثور عليها (هاشات تم كسرها بالفعل مع النص الصريح):```bash
hate_crack.py --hashview download-found --customer-id 1 --hashfile-id 123

#### الإعدادات

عيّن بيانات اعتماد Hashview في `.env` (هذه إعدادات تكامل، لذلك لا تُخزَّن في `config.json`):```
HASHVIEW_URL=https://hashview.example.com
HASHVIEW_API_KEY=your-api-key-here

- **`OLLAMA_MODEL`** — نموذج Ollama المستخدم لتوليد المرشّحات (الافتراضي: `qwen2.5:32b`). يعتمد هجوم LLM على مخرجات منظمة (JSON)، لذا اختر نموذجًا يتمتع بدعم جيد للأدوات/JSON.
- **`OLLAMA_NUM_CTX`** — حجم نافذة السياق للنموذج (الافتراضي: `8192`). كانت القيمة `2048` قبل إدخال إحصاءات المجموعة النصية، وكانت أصغر من أن تستوعب المطالبة المُعطاة له: 500 نص صريح مُنتقى تستهلك نحو 2,000–3,500 توكن قبل مطالبة النظام والاستجابة، لذا قام Ollama باقتطاع جزء من العينة بصمت، وهي العينة التي وزّعها المُنتقى بعناية عبر الملف.
- **`OLLAMA_TIMEOUT`** — عدد الثواني التي يُنتظر فيها استجابة التوليد قبل الاستسلام (الافتراضي: `300`). ارفع هذه القيمة إذا كان نموذج كبير لا يزال يُحمَّل في VRAM عند الطلب الأول، وإلا فقد يتجاوز المهلة؛ يطبع hate_crack قيمة المهلة المنقضية واسم هذا الإعداد عند حدوث ذلك.
- **`OLLAMA_MAX_SAMPLE_LINES`** — الحد الأدنى الذي دونه تقوم أوضاع LLM أيضًا بلصق النصوص الصريحة الحرفية في المطالبة (الافتراضي: `500`). القيم ≤ 0 تُعامل على أنها 500.

  الأوضاع المشتقة من المجموعة النصية (**Wordlist**, **Cracked passwords**, **Pattern rules**) تصف دائمًا المجموعة *كاملة* إحصائيًا — حصص الكلمات الأساسية، الأقنعة، حالة الأحرف، الأطوال، الأرقام والرموز اللاحقة، السنوات — بدلًا من لصق جزء منها. التجميع محدود، لذا فإن تفريغًا يحتوي 120,000 كلمة مرور يستهلك نفس مساحة المطالبة تقريبًا التي يستهلكها ملف من 500 سطر. عندما تتسع المجموعة كلها دون هذا الحد، تُضمَّن النصوص الصريحة الخام أيضًا، إذ لا فائدة من إخفاء مجموعة صغيرة عن النموذج.

  يحل هذا محل السلوك السابق المتمثل في لصق عينة موزعة بالتساوي تصل إلى `ollamaMaxSampleLines` كلمة مرور. لم تكن عينة من تفريغ كبير تنقل أي معلومات عن التكرار إطلاقًا: لم يستطع النموذج التمييز بين كلمة أساسية يستخدمها 8% من المؤسسة وكلمة يستخدمها شخص واحد، وهذا هو بالضبط الإشارة التي تجعل التخمين جديرًا بالتنفيذ.
- **`OLLAMA_NO_CLOUD`** — عند القيمة `true`، يرفض إرسال أي شيء إلى نموذج Ollama *سحابي*. يقوم Ollama بتمرير نموذج موسوم بـ `-cloud` (`gpt-oss:120b-cloud`, `deepseek-v3.1:671b-cloud`) إلى ollama.com عبر نفس نقطة النهاية المحلية التي يستخدمها النموذج المحلي، لذا لا يبدو أي شيء مختلفًا في الطلب — لكن مطالبات hate_crack تحمل نصوصًا صريحة مستعادة، وإحصاءات المجموعة، واسم العميل، وقطاعه، وموقعه. مع تفعيل هذا الإعداد، يُرفض اسم النموذج السحابي قبل بناء أي طلب. الافتراضي هو `false`، لذا يستمر نموذج سحابي مُهيأ عمدًا في العمل؛ فعّله للمهام التي يجب ألا تغادر فيها بيانات العميل المضيف.
- **`OLLAMA_AUTO_RESEARCH`** — عند القيمة `true` (الافتراضي)، يطلب وضع **Target info** من النموذج المحلي اقتراح القطاع والموقع فور كتابتك لاسم الشركة، ويقدمهما كقيم افتراضية قابلة للتعديل في المطالبة. اضبطه على `false` للحصول دائمًا على مطالبات فارغة (مفيد مع نموذج بطيء، لأن البحث يكلف رحلة ذهاب-وإياب إضافية واحدة قبل بدء الهجوم).
- **`OLLAMA_HOST`** — حيث يستمع Ollama. يقبل `host:port` مجردًا (`theplague.lan:11434`) أو عنوان URL كاملًا بمخطط (`https://ollama.example.com`)؛ وفي كلتا الحالتين تتم تسوية عنوان URL الأساسي قبل الاستخدام. الافتراضي هو `localhost:11434`. عيّنه في `.env`، أو صدّره كمتغير بيئة حقيقي لتجاوزه لتشغيل واحد — وهو نفس اسم المتغير الذي يقرؤه واجهة أوامر Ollama نفسها.
- تأكد من أن Ollama يعمل وأن النموذج قد تم سحبه (`ollama pull qwen2.5:32b`) قبل استخدام هجوم LLM — لم يعد hate_crack يسحب النماذج المفقودة تلقائيًا.

يوفر الهجوم ثلاثة أوضاع للتوليد:

1. **Target info** — الشركة / القطاع / الموقع؛ يستخلص النموذج المرشّحات من هذه التفاصيل.

   بعد كتابة اسم الشركة، يسأل hate_crack نفس النموذج المحلي عمّا يعرفه بالفعل عن تلك المؤسسة، ويملأ مطالبتي **Industry** و**Location** مسبقًا بالإجابات، الموضحة بين قوسين:   ```
   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):

فشل البحث — مهلة زمنية، أو Ollama لا يعمل، أو إجابة فارغة — لا يمنع أبدًا الهجوم؛ بل يتراجع فقط إلى مطالبات فارغة. اضبط `ollamaAutoResearch` على `false` لتخطي البحث بالكامل.
2. **قائمة الكلمات** — اشتقاق الكلمات الأساسية من قائمة كلمات نموذجية.
3. **كلمات المرور المكسورة** — أعد تغذية النصوص الصريحة التي تم استردادها بالفعل في هذه الجلسة (`<hashfile>.out`) إلى النموذج ليتمكن من استنتاج اصطلاحات كلمات المرور الخاصة بالمؤسسة المستهدفة (الكلمات الأساسية، المواسم، السنوات، اللواحق، leetspeak) وتوليد مرشحات *جديدة* بنفس الأسلوب. يظهر هذا الخيار فقط بعد كسر تجزئة واحدة على الأقل؛ يتم تحليل الملف بأكمله إحصائيًا تمامًا مثل وضع قائمة الكلمات (انظر `ollamaMaxSampleLines` أعلاه).

#### إعداد PCFG

يستخدم هجوم PCFG (الخيار 20) وهجوم PRINCE-LING (الخيار 21) الوحدة الفرعية `pcfg_cracker`. قم بتكوينهما في `config.json`:```json
{
"pcfgRuleset": "DEFAULT",
"pcfgMaxCandidates": 50000000,
"pcfgPrinceLingMaxCandidates": 10000000
}

- **`check_for_updates`** — تفعيل الفحوصات التلقائية للنسخ عند بدء التشغيل (الافتراضي: `true`).
- عند التفعيل، يجلب hate_crack أحدث معلومات الإصدار من GitHub ويعرض إشعارًا إذا كان هناك تحديث متاح.
- يتم الفحص بشكل غير متزامن ولا يمنع بدء التشغيل. يتم تجاهل أخطاء الشبكة بصمت.

##### قنوات التحديث

| Channel | Flag | Source | What you get |
|---------|------|--------|--------------|
| Release | `--update` | `main` | أحدث إصدار مقطوع. هذا هو الافتراضي وما يقدمه فحص بدء التشغيل. |
| Nightly | `--nightly` | `nightly-dev` | العمل الذي اجتاز CI لكن لم يُطرح بعد. |

تتبع الإصدارات معايير semver العادية، حيث يُشتق رقم الترقية مما هو موجود فعليًا في الدفعة. يتحرك المكوّن الثاني **فقط للميزات**: الدورة التي تحتوي على أي commit من نوع `feat` تتجه إلى `X.(Y+1).0`، والدورة التي لا تحتوي إلا على إصلاحات ووثائق وأعمال صيانة تتجه إلى `X.Y.(Z+1)`.

`nightly-dev` يعلّم مرشحات الإصدار لأي نسخة تتجه إليها الدفعة — `v2.20.1rc1`, `v2.20.1rc2`، … — ودمجها في `main` يرفع ذلك الهدف نفسه إلى إصداره النهائي. المرشحات هي إصدارات تجريبية حقيقية وفق PEP 440، لذا تُرتَّب بشكل صحيح عند الطرفين:

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

يمكن أن يتغير الهدف في منتصف الدورة: أول `feat` يصل ينقله من `X.Y.(Z+1)` إلى `X.(Y+1).0`، ويبدأ ترقيم المرشحات من جديد للهدف الجديد. الرقم دائمًا يسمي ما ستصدره الدفعة اليوم.

لا يتم رفع المكوّن الرئيسي تلقائيًا أبدًا — سطر موضوع يحتوي `!` أو تذييل `BREAKING CHANGE:` يُعتبر ميزة، لأن الترقية الرئيسية التلقائية تفصلها سطر موضوع مكتوب خطأً عن إصدار منشور لا رجعة فيه. الترقية الرئيسية فعل بشري صريح: ضع وسمًا وادفعه يدويًا.

توجد السياسة في `tools/next_version.py`، وتشترك فيها كلتا سيرتَي وضع الوسوم، ومختبرة وحدويًا في `tests/test_next_version.py`.

فحص بدء التشغيل يقدم الإصدارات فقط دائمًا، لأن بنيات الليلي لا تنشر أي إصدار GitHub على الإطلاق، ويقرأ الفحص نقطة نهاية "أحدث إصدار" في GitHub — لذا تفعيل `check_for_updates` لن يجرّك أبدًا إلى نسخة ليلية. أمران يفصلان بين القناتين الآن: ذلك، وحقيقة أن المرشح هو إصدار تجريبي حقيقي وفق PEP 440، لذا فإن الأداة التي ترتب أرقام الإصدارات الخام تعامله أيضًا على أنه أقدم من الإصدار الذي يصبحه.

أي من العلامتين يحوّل مستودعك المحلي إلى الفرع المقابل أولًا (ويرفض القيام بذلك إذا كانت لديك تغييرات غير ملتزمة). إذا كنت تشغّل نسخة ليلية وتريد العودة إلى الكود المُصدر، فإن `--update` يعيدك إلى `main`.

#### دمج الهاشات الموجودة تلقائيًا (تنزيل اليسار فقط)

عند تنزيل الهاشات اليسرى (هاشات غير مكسورة)، يقوم hate_crack تلقائيًا بما يلي:
1. محاولة تنزيل أي هاشات موجودة (مكسورة) من Hashview كعملية مساعدة
2. دمج الهاشات الموجودة مع ملفات `.out` المحلية (مثل `left_1_123.txt.out` أو `left_1_123.nt.txt.out` لصيغة pwdump)
3. إزالة الإدخالات المكررة
4. تنظيف ملفات التقسيم المؤقتة بعد الدمج

يضمن ذلك بقاء نتائج الكسر المحلية متزامنة مع قاعدة بيانات Hashview المركزية عند العمل مع الهاشات غير المكسورة.

**ملاحظة:** خيار تنزيل الموجودة يُنزّل الهاشات المكسورة بالفعل بشكل منفصل لأغراض مرجعية ولا يقوم بأي دمج أو يطلب الكسر.

يتم الحصول على <hash_type> بتشغيل `hashcat --help`

أمثلة الهاشات: 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

## الاختبار

مجموعة الاختبارات غير متصلة بالشبكة في الغالب وتستخدم mocks/fixtures. فحوصات الشبكة المباشرة وفحوصات تبعيات النظام اختيارية عبر متغيرات البيئة.

### تشغيل الاختبارات محليًا```bash
# Run all tests
uv run pytest -v

# Run specific test
uv run pytest tests/test_hashview.py -v

### اختبارات Hashview المباشرة ضد حزمة Docker محلية

بدلاً من توجيه الاختبارات المباشرة إلى خادم Hashview بعيد، يمكنك جعل
المجموعة تُشغّل حزمة [Hashview](https://github.com/hashview/hashview)
Docker محلية، وتعبئتها بالبيانات، ثم تشغيل الاختبارات المباشرة ضدها، وإيقافها بعد ذلك. اضبط
`HASHVIEW_TEST_LOCAL=1` ووجّه `HASHVIEW_REPO` إلى نسخة 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

التثبيت/التشغيل الشامل القائم على Docker (مخزَّن مؤقتًا عبر `Dockerfile.test`):```bash
HATE_CRACK_RUN_DOCKER_TESTS=1 uv run pytest tests/test_docker_script_install.py -v

يتم تجهيز جهاز VM الاختباري تلقائيًا بجميع تبعيات 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

أي قاعدة (قواعد) تريد تشغيلها؟
(1) best64.rule
(2) d3ad0ne.rule
(3) T0XlC.rule
(4) dive.rule
(99) YOLO... قم بتشغيل جميع القواعد
أدخل قائمة مفصولة بفواصل بالقواعد التي ترغب في تشغيلها. لتشغيل القواعد بشكل متسلسل استخدم الرمز +.
على سبيل المثال، 1+1 سيشغّل best64.rule مرتين متسلسلتين، و 1,2 سيشغّل best64.rule ثم d3ad0ne.rule بالتتابع.
اختر بحكمة:```




#### 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
  * 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.

#### 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 <space> - _ , + . &

#### 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, and location, 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, and location. The industry and location 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](#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 (`-1`, `-2`, `-3`, `-4`) for specialized character combinations
* Interactive charset entry with early exit on blank input
* 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
* 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](https://github.com/lakiw/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](https://github.com/bandrel/HashcatRosetta), the same library behind [Analyze Hashcat Rules](#analyze-hashcat-rules-rule-file-tools-option-5).

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 (default 100) and how many top basewords (default all). Zero means unlimited for 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

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

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](https://github.com/trustedsec/hate_crack/blob/HEAD/CHANGELOG.md).