Crow-Eye — محرك فحوص جنائية لنظام ويندوز

آلة زمن جنائية لنظام ويندوز.
لا يكتفي Crow-Eye بالكشف — بل يعيد بناء ما حدث فعليًا على الخط الزمني، بدءًا من الاقتناء وصولًا إلى حكم يمكن تتبعه إلى سجلاته المصدرية.

Table of Contents

• نظرة عامة
• ✨ أبرز المزايا
• 👥 لمن صُمم Crow-Eye
• 🧭 الأنظمة الفرعية في لمحة
• 🏗️ البنية المعمارية
• 📥 التنزيل والتثبيت
• 🚀 البدء السريع
• 📂 الأدلة المدعومة
• 🔧 أوضاع التحليل
  • 📎 استيراد الأدلة (بيانات جهات خارجية)
• 🧠 تحليلات سلوك المستخدم (UBA)
• 🧩 محرك الربط
• 👁️ Eye — مساعد الذكاء الاصطناعي الجنائي
• 📖 Eye-Describe — قاعدة معرفة الأدلة على مستوى البايت
• 🧪 الجودة والتحقق
• 🔬 منصة الأبحاث
• 🛠️ ملاحظات تقنية
• 📸 لقطات الشاشة
• 🚧 خارطة الطريق
• 📚 التوثيق
• 🤝 المساهمة
• 🌐 الموقع والمجتمع
• 📄 الترخيص
• 📝 الاستشهاد بـ Crow-Eye
• 💖 الدعم
• الإسهامات

نظرة عامة

Crow-Eye هو محرك فحوص جنائية مفتوح المصدر (GPL-3.0) لنظام ويندوز يوحّد الاقتناء والتحليل والتحقق والاستخبارات والذكاء الاصطناعي. معظم أدوات الأمان تسأل "هل هذا ضار؟" وتغض الطرف عن كل ما يبدو شرعيًا. أما Crow-Eye فيطرح سؤالًا مختلفًا: "ماذا حدث؟" إنه يربط كل الأنشطة — سواء كانت مشبوهة أم لا — ويعيد بناء التسلسل الفعلي للأحداث على النظام، بحيث تكون حقيقة التحقيق مُعاد بناؤها من الأدلة وليست تخمينًا من التنبيهات.

هذا التصميم القائم على إعادة البناء أولًا هو بالضبط ما يلزم لملاحقة تهديدات APT والدول القومية: الخصوم المتطورون يعيشون داخل الأدوات الشرعية (powershell.exe, PsExec, certutil) وفي تسلسل الإجراءات — وهو ما لا تراه الأدوات التي تغض الطرف عن كل ما يبدو طبيعيًا. ولأن Crow-Eye لا يغض الطرف عن أي شيء ويعتمد في استدلاله على أدلة التنفيذ (التي تصمد أمام العبث بالسجلات ومكافحة الفحوص الجنائية)، فلا يمكن للهجوم أن يختفي. ويظل المحرك نفسه سهل الاستخدام لأعمال DFIR اليومية ولغير الخبراء الذين يريدون ببساطة معرفة ما حدث على جهاز كمبيوتر.

• 🕰️ أعد البناء، لا تكتفِ بالكشف — أعد بناء الخط الزمني لما حدث فعلًا.
• 🖥️ متعدد المنصات — تحليل كامل مباشر وغير متصل على ويندوز؛ التحليل غير المتصل وتحليل صور الفحوص الجنائية على لينكس (المحللات المباشرة خاصة بويندوز).
• 🔒 خاص بطبيعته — 0 مللي ثانية من البيانات تُرسل خارج الجهاز؛ يمكن لمساعد Eye بالذكاء الاصطناعي العمل معزولًا تمامًا عن الشبكة.
• 🧾 بمعايير المحاكم — الأدلة مختومة تشفيريًا وكل خطوة قابلة للتدقيق.
• 📦 الإصدار الحالي: 0.12.6 · محرك الربط: 1.7.0 · الترخيص: GPL-3.0.

✨ أبرز المزايا

• إعادة البناء بدلًا من الكشف. يربط كل أثر في قصة واحدة قابلة للتنقل لكل كيان بدلًا من كومة تنبيهات.
• متكامل من البداية إلى النهاية — اقتناء ← ربط ← خط زمني ← تحليلات سلوكية ← ذكاء اصطناعي ← ذاكرة قضية مختومة: خط أنابيب كامل لا يغطيه أي أداة تقليدية منفردة.
• عميق في الأدلة، لا سطحي في السجلات. Prefetch و Amcache و ShimCache و SRUM و MFT و USN و LNK/JumpLists وغيرها تصمد أمام مسح السجلات وحيل "العيش على أدوات النظام" التي تعمي الأدوات التي تعتمد على السجلات فقط.
• مساعد Eye بالذكاء الاصطناعي — تحقيق جنائي بلغة طبيعية مع سلسلة حيازة قابلة للتدقيق ومصممة لكشف العبث، ويعمل في السحابة أو على خادم خاص أو دون اتصال تمامًا.
• تحليلات سلوك المستخدم (UBA) — تحوّل الأدلة الخام إلى قصة نشاط بلغة إنجليزية بسيطة يقرؤها موظفو الموارد البشرية والمحققون.
• مجاني ومفتوح المصدر (GPL-3.0) — قابل للتدقيق من أي شخص، مع جهود بحثية وتوثيقية نشطة.

👥 لمن صُمم Crow-Eye

يُستخدم Crow-Eye عبر سير عمل مختلفة جدًا. كل واحد منها يدخل إلى المحرك من باب مختلف:

أي أداة جمع تعمل. لا يتطلب Crow-Eye أداة اقتناء خاصة به. وجّه المستورد غير المتصل إلى مجلد يحتوي أدلة خام أنتجتها Velociraptor أو KAPE أو حزمة جمع EDR أو أي جامع آخر — فهو يفهرس الأدلة المدعومة ويشغّل المحللات غير المتصلة عليها. وبشكل منفصل، يمكن استيراد مخرجات Plaso أو Autopsy أو Volatility أو أي أداة أخرى بصيغ CSV أو JSON أو SQLite عبر استيراد الأدلة وربطها إلى جانب الأدلة الأصلية.

🧭 الأنظمة الفرعية في لمحة

بُني Crow-Eye كحلقة متكاملة — كل مرحلة تغذي التالية، من القرص الخام إلى حكم قابل للدفاع عنه.

🏗️ البنية المعمارية

Crow-Eye خط أنابيب متكامل، وليس حقيبة محللات. الأدلة تتدفق في اتجاه واحد، وتحتفظ كل مرحلة برابط يعود إلى السجل المصدر.```mermaid %%{init: {"flowchart": {"nodeSpacing": 60, "rankSpacing": 70, "curve": "basis"}, "themeVariables": {"fontSize": "17px", "fontFamily": "system-ui, sans-serif"}} }%% flowchart TB

%% ═══════════ 1. EVIDENCE SOURCE ═══════════ S1["Live Windows system"] S2["Forensic image
E01 · VHDX · VMDK · Raw"] S3["Collected artifacts
Velociraptor · KAPE · EDR"] S4["Third-party output
Plaso · Autopsy · Volatility"]

%% ═══════════ 2. INGEST ═══════════ I1["CROW-CLAW
live acquisition"] I2["IMAGE PARSING
direct, no mounting"] I3["OFFLINE IMPORTER
SCAN → COLLECT → PARSE"] I4["IMPORT EVIDENCE
CSV · JSON · SQLite"]

PARSERS["ARTIFACT PARSERS<br/>18 artifact types · live and offline"]

%% ═══════════ 3. CASE ═══════════ CASE[("CASE DATABASES
Target_Artifacts/
Imported_Evidence/")]

%% ═══════════ 4. ANALYSIS ═══════════ TL["INTERACTIVE TIMELINE
heat map · week · day"] UB["USER BEHAVIOR ANALYTICS
40 detections · plain-English story"] CE["CORRELATION ENGINE
Feathers → Wings → Engines → Pipelines"] RES[("Correlation results")] DL["DYNAMIC LINKING
non-destructive enrichment overlay"] INTEL[("Crow_Intelligence.db
SID · MAC · hash · GUID → name")]

%% ═══════════ 5. AI LAYER ═══════════ EYE["EYE
GEP-governed AI assistant"] NM["NARRATIVE MAP
hash-chained case memory"] COMP["COMPLIANCE
live GEP status · EvidenceSeal audit"]

OUT["LIVING REPORT<br/>CSV · JSON · HTML"]

%% ═══════════ FLOW ═══════════ S1 --> I1 S2 --> I2 S3 --> I3 S4 --> I4

I1 --> PARSERS
I2 --> PARSERS
I3 --> PARSERS

PARSERS -- "parsed artifacts" --> CASE
I4 -- "verbatim copy or<br/>converted to feather" --> CASE

CASE -- "read-only" --> TL
CASE -- "read-only" --> UB
CASE -- "read-only" --> CE
CASE -- "read-only" --> DL
CE --> RES
DL --> INTEL

CASE -- "read-only queries" --> EYE
RES -. "queried on demand" .-> EYE
EYE <== "verdict · narrative · evidence" ==> NM

EYE -- "audited by" --> COMP

EYE -- "report_* tools" --> OUT

%% ═══════════ STYLE ═══════════ classDef src fill:#334155,stroke:#94a3b8,stroke-width:2px,color:#f1f5f9 classDef ing fill:#0f766e,stroke:#2dd4bf,stroke-width:2px,color:#f0fdfa classDef store fill:#92400e,stroke:#fbbf24,stroke-width:3px,color:#fffbeb classDef ana fill:#1e40af,stroke:#60a5fa,stroke-width:2px,color:#eff6ff classDef ai fill:#6b21a8,stroke:#c084fc,stroke-width:2px,color:#faf5ff classDef out fill:#166534,stroke:#4ade80,stroke-width:2px,color:#f0fdf4

class S1,S2,S3,S4 src
class I1,I2,I3,I4,PARSERS ing
class CASE,RES,INTEL store
class TL,UB,CE,DL ana
class EYE,NM,COMP ai
class OUT out

linkStyle default stroke-width:2px

*مصدر الأدلة ← الاستيعاب ← قواعد بيانات الحالة ← التحليل ← طبقة الذكاء الاصطناعي ← التقرير*


**كيفية قراءته:**

| المرحلة | ما المهم |
|---|---|
| ① → ② | **أربعة أبواب مستقلة إلى القضية.** لا تحتاج أبدًا إلى أداة الجمع الخاصة بـ Crow-Eye — فالمجلد القادم من Velociraptor أو KAPE أو حزمة EDR يمر عبر المستورد دون اتصال (Offline Importer)، وتدخل بيانات CSV/JSON/SQLite الخارجية عبر استيراد الأدلة (Import Evidence). |
| ② → ③ | كل شيء يتقارب في مكان واحد: **قواعد بيانات الحالة**. القطع الأثرية المُحلَّلة تصل إلى `Target_Artifacts/`؛ والأدلة الخارجية المستوردة تصل إلى `Imported_Evidence/` وتُكتشف تلقائيًا. |
| ③ → ④ | **مسارات التحليل الثلاثة مستقلة عن بعضها البعض.** يقرأ كلٌّ من الخط الزمني (Timeline) وUBA قواعد بيانات الحالة مباشرة — ولا يتطلب أيٌّ منهما تشغيل ترابط (correlation run). محرك الترابط (Correlation Engine) هو طبقة *إضافية*، وليس شرطًا مسبقًا. |
| ③ → ④ | **الربط الديناميكي (Dynamic Linking) يعمل جنبًا إلى جنب مع الخط الزمني وUBA** — قارئ رابع مستقل لقواعد بيانات الحالة (لا علاقة له بتصور الخط الزمني). يجمع خرائط الهوية (SID ← اسم المستخدم، MAC ← الشبكة، hash/GUID ← التطبيق) في قاعدة بيانات `Crow_Intelligence.db` خاصة بكل حالة، ثم يضيف هذا السياق **داخل جداول بيانات القطع الأثرية** عبر استعلامات `ATTACH` + `LEFT JOIN` غير مدمرة. يغيّر طريقة *قراءة* السجلات، ولا يمس الأدلة أبدًا. |
| ④ → ⑤ | **العين (Eye) تستعلم قواعد بيانات الحالة مباشرة ويمكنها سحب نتائج الترابط **عند الطلب**. إنها لا تلمس الأدلة نفسها أبدًا — بل تصدر استدعاءات أدوات ينفذها Crow-Eye ويسجلها. |
| ⑤ → Report | **التقرير الحي (Living Report) يُبنى بواسطة العين وحدها**، عبر أدوات `report_*` الخاصة بها. الخط الزمني وUBA سطحا تحليل — لا يكتبان في التقرير. يمكن مع ذلك تصدير نتائج مستوى الحالة بشكل منفصل عبر [البحث والتصدير](#-search--export). |
| ⑤ ↔ | **الخريطة السردية (Narrative Map) ثنائية الاتجاه**: تكتب فيها العين، وتكتب أنت فيها، وتُحقن محتوياتها في موجه (prompt) العين في كل جولة. إنها الذاكرة، ويمكنك التحكم بها. |
| ⑤ ⟳ | **صفحة الامتثال (Compliance) تدقق في العين.** كل استدعاء أداة تقوم به العين مرتبط بسلسلة تجزئة **EvidenceSeal**؛ وتعرض الصفحة حالة **GEP** الحية لكل قاعدة (10 مبادئ) تم التحقق منها من تلك السلسلة ومن `EYE_Logs/`، ويمكن تصديرها كـ `audit_trail.json`. |

**مراحل مستقلة.** يقرأ كلٌّ من الخط الزمني وUBA قواعد بيانات قطع الحالة **مباشرة** — ولا يتطلب أيٌّ منهما تشغيل ترابط، والخط الزمني لا يعتمد على محرك الترابط (فهو يطبق تجميعه الزمني الخفيف الخاص به). الترابط طبقة تحليل إضافية يمكن للعين الاستعلام عن نتائجها.

**للقراءة فقط بحكم التصميم.** التحليل (Parsing) يكتب في قاعدة بيانات الحالة؛ وكل مرحلة لاحقة (UBA، الخط الزمني، عارضات الترابط، العين) تفتح هذه القواعد **للقراءة فقط**. الأدلة الأصلية لا تُعدَّل أبدًا — [الربط الديناميكي](#-analysis-modes) يقرأ قواعد بيانات الحالة لبناء قاعدة بيانات `Crow_Intelligence.db` خاصة بكل حالة لخرائط الهوية، ويثري جداول بيانات القطع الأثرية داخل الصفوف عبر استعلامات `ATTACH` + `LEFT JOIN` غير مدمرة بدلًا من إعادة كتابة الصفوف.

**محكوم بالتصميم.** كل إجراء تقوم به العين مرتبط بسلسلة تجزئة **EvidenceSeal** المقاومة للعبث، وتتحقق صفحة **الامتثال (Compliance)** باستمرار من العين مقابل [بروتوكول غسان السمان (GEP)](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/eye/docs/GEP_standard.md) — حالة حية لكل قاعدة، قابلة للتصدير إلى `EYE_Logs/audit_trail.json`.

## 📥 التنزيل والتثبيت

> **موصى به:** احصل على نسخة Windows المجمّعة (**مثبّت MSI / EXE**) من الموقع الرسمي — لا حاجة لإعداد Python، تعمل مباشرة.

### ▶️ [تنزيل Crow-Eye لنظام Windows ← crow-eye.com/download](https://crow-eye.com/download)

**نسخة MSI/EXE المثبّتة هي الطريقة الموصى بها لتشغيل Crow-Eye**، وهي **أولوية قصوى لدينا للتحديثات**:

- 🛡️ **أسرع الإصلاحات.** عندما يُكتشف خلل أو يُبلَّغ عن خطأ، نصدر EXE محدّث **في أقرب وقت ممكن** — النسخة المجمّعة هي أول ما تصل إليه الإصلاحات.
- 🔄 **تحديث تلقائي مدمج.** في التطبيق المثبّت، افتح **الإعدادات ← التحديثات** لـ**التحقق من التحديثات وتثبيتها تلقائيًا** — لا حاجة لإعادة تثبيت يدوية.
- 📦 **إعداد صفري.** لا يلزم تثبيت Python أو Node أو أي تبعيات.

> تفضّل التشغيل من المصدر؟ انظر **[بدء سريع](#-quick-start)** أدناه. النسخة من المصدر مخصّصة للمساهمين و**لا تتضمن المحدّث التلقائي** — استخدم MSI/EXE للتحديثات التلقائية.

## 🚀 بدء سريع

### الخيار أ — النسخة المثبّتة (موصى به)
نزّل **MSI/EXE** من [crow-eye.com/download](https://crow-eye.com/download)، ثبّته، وشغّل **Crow-Eye** كمسؤول (Administrator). أنشئ حالة وابدأ التحليل.

### الخيار ب — التشغيل من المصدر (للمطوّرين)

> للمساهمين والمستخدمين المتقدمين. هذا المسار **لا يتضمن المحدّث التلقائي** — استخدم MSI/EXE للتحديثات التلقائية.

**المتطلبات** (تُثبَّت تلقائيًا عند أول تشغيل):
- Python 3.12.4
- **Node.js وnpm** — مطلوبان لـ**تصور الخط الزمني (Timeline Visualization)**
- الحزم الرئيسية: PyQt5, python-registry, pywin32, pandas, streamlit, altair, olefile, windowsprefetch, sqlite3, colorama, setuptools

**الأجهزة الموصى بها**

| | الحد الأدنى | الموصى به للحالات الكبيرة |
|---|---|---|
| **الذاكرة (RAM)** | 8 جيجابايت | 16 جيجابايت+ (مجموعات MFT/USN بملايين السجلات) |
| **القرص** | 5 جيجابايت مساحة حرة | مساحة حرة ≥ ضعف حجم الأدلة التي يتم تحليلها |
| **المعالج** | 4 أنوية | 8+ أنوية |
| **نظام التشغيل** | Windows 10/11 (كامل) · Linux (تحليل دون اتصال وتحليل صور) | — |

> يعمل الترابط (Correlation) بتدفق مستمر في الذاكرة لمجموعات البيانات الكبيرة جدًا، لذا نادرًا ما تكون الذاكرة هي الحد الأقصى — عادةً ما يكون إنتاجية القرص والمساحة الحرة هما الحد.

**الإطلاق** (شغّله كمسؤول حتى يتمكن Crow-Eye من الوصول إلى القطع الأثرية للنظام):```bash
python "Crow Eye.py"

تفتح الواجهة الرئيسية، وتنشئ قضية، وتُنظَّم جميع مخرجات التحليل تحت دليل تلك القضية للمراجعة وإعداد التقارير لاحقًا.

🖥️ ملاحظة متعددة المنصات: على لينكس، تُعطَّل المحللات المباشرة تلقائيًا ويعمل Crow-Eye في وضع غير المتصل / صورة الأدلة الجنائية. الاستحواذ المباشر الكامل خاص بويندوز فقط.

📂 الآثار المدعومة

يحلل Crow-Eye مجموعة واسعة من آثار ويندوز المتعلقة بالتنفيذ ونظام الملفات ونشاط المستخدم، سواء من نظام مباشر أو من مصادر غير متصلة (مجلدات مجمعة أو صور أدلة جنائية).

يتم تحليل Jump Lists & LNK بواسطة محلل LNK / Jump List مخصص من تطوير Crow-Eye — وليس وحدة طرف ثالث.

السجل المخصص / الملفات المقفلة: يقفل ويندوز خلايا السجل المباشرة (NTUSER.DAT, SOFTWARE, SYSTEM) أثناء التشغيل. لتحليل مخصص لنظام مباشر، أقلع من وسائط خارجية (WinPE/Live CD)، أو استخدم أدوات الاستحواذ الجنائي، أو حلل صورة قرص.

تفاصiel كل أثر

• Jump Lists & LNK — تُحلل تلقائيًا من مواقع النظام القياسية بواسطة المحلل المخصص لـ Crow-Eye (الوصول إلى الملفات، مسارات الهدف، الطوابع الزمنية، والبيانات الوصفية).
• السجل (Registry) — يحلل خلايا النظام تلقائيًا. لـ تحليل سجل مخصص، انسخ ملفات الخلايا إلى CrowEye/Artifacts Collectors/Target Artifacts (أو مجلد registry/ الخاص بقضيتك):
  • NTUSER.DAT من C:\Users\<Username>\NTUSER.DAT
  • SOFTWARE من C:\Windows\System32\config\SOFTWARE
  • SYSTEM من C:\Windows\System32\config\SYSTEM
  • يقفل ويندوز هذه أثناء التشغيل — بالنسبة لنظام مباشر، أقلع من وسائط خارجية (WinPE/Live CD)، أو استخدم أدوات الاستحواذ الجنائي، أو حلل صورة قرص.
• Prefetch — يحلل C:\Windows\Prefetch، مستخرجًا سجل التنفيذ والبيانات الوصفية الجنائية (بما في ذلك الطوابع الزمنية لكل تشغيل).
• سجلات الأحداث — تحليل تلقائي لسجلات النظام/الأمان/التطبيق في قاعدة بيانات لتحليل شامل.
• ShellBags — يكشف سجل الوصول إلى المجلدات وأنماط تنقل المستخدم.
• سلة المحذوفات — يحلل $RECYCLE.BIN لاستعادة أسماء الملفات المحذوفة ومساراتها الأصلية وأوقات حذفها وأحجامها (الأنظمة المباشرة وصور الأقراص).
• MFT — يحلل جدول الملفات الرئيسي للحصول على البيانات الوصفية للملفات وسماتها والطوابع الزمنية ومعلومات الملفات المحذوفة (NTFS، ويندوز 7/10/11).
• USN Journal — يتتبع أحداث إنشاء/تعديل/حذف/إعادة تسمية الملفات مع الطوابع الزمنية وسجل الاسم الكامل، لإعادة بناء الخط الزمني.
• SRUM — يعرض استخدام موارد التطبيق (أشرطة مدة لوقت المقدمة/الخلفية) ونشاط الشبكة لكل تطبيق.
• محلل أدلة التخزين — عرض شجري كامل لكل قرص فعلي وأقسامه؛ أنواع أقسام مرمّزة بالألوان (EFI، لينكس، الاسترداد، المخفي/التبديل، …)؛ تحذيرات لأقراص USB القابلة للإقلاع، وجذور لينكس المخفية، وIntel Rapid Start؛ احتياطي بفحص سحري للقطاعات الخام.

🔧 أوضاع التحليل

🦅 الاستحواذ عبر Crow-Claw

Crow-Claw هو محرك الاستحواذ المتخصص في Crow-Eye لجمع الآثار والحفاظ عليها من الأنظمة المباشرة أو الصور المثبتة.

• جمع انتقائي — اختر فئات آثار محددة (السجل، سجلات الأحداث، نظام الملفات) أو اجمع كل شيء.
• فحص عميق — يتنقل عبر الدلائل والدلائل الفرعية للعثور على آثار جنائية.
• حفظ آمن — تصل الآثار إلى دليل قضية منظم يحافظ على السلامة الجنائية.

🔍 التحليل غير المتصل (المستورد غير المتصل)

حلل الآثار المجمعة من أي مصدر دون اتصال مباشر بالهدف — ثلاث عمليات واضحة:

• SCAN (الاكتشاف) — تجول في المصدر وفهرس كل أثر مدعوم وفق نمط اسم الملف والامتداد (سريع، للقراءة فقط؛ لا تُقرأ محتويات الملفات ولا يُجرى فحص البايتات السحرية في هذه المرحلة). لا يُنقل أي شيء.
• COLLECT (الاستحواذ) — انسخ الملفات المحددة فعليًا إلى مجلد live_acquisition الخاص بالقضية، منظمة حسب النوع.
• PARSE (دقيق) — راجع العناصر المحددة حسب النوع (AMCACHE, EVTX, PREFETCH, …) وحلل الملفات المختارة (أو كلها) في قاعدة البيانات الجنائية.

يتم التحليل بواسطة المحللات غير المتصلة المخصصة لـ Crow-Eye — نفس منطق الآثار في الوضع المباشر، وتعمل على الملفات المجمعة: Prefetch، السجل (Registry)، MFT، USN (بالإضافة إلى مقرن MFT/USN)، AmCache، ShimCache، SRUM، سجلات الأحداث، LNK/JumpLists، وسلة المحذوفات.

📎 استيراد الأدلة (بيانات طرف ثالث)

إلى جانب الآثار الخام، يمكن لـ Crow-Eye إدخال مخرجات جنائية من طرف ثالث مباشرة إلى قضية — Plaso أو Autopsy أو Volatility أو أي تصدير مخصص — وجعلها قابلة للاستخدام من قبل Eye والخط الزمني دون الحاجة إلى تشغيل ارتباط أولًا.

نظرًا لأن مدير قاعدة بيانات القضية يكتشف تلقائيًا أي .db ضمن شجرة القضية، تصبح الأدلة المستوردة متاحة فورًا إلى:

• Eye — قابلة للاستعلام باللغة الطبيعية إلى جانب الآثار الأصلية (يُحدَّث بيان المخطط عند الاستيراد).
• الخط الزمني التفاعلي — تُقدَّم كنوع آثار imported، مع تصفية نافذة زمنية وحدود زمنية فعالة.
• محرك الارتباط — قابلة للاستخدام كـ Feather للارتباط عبر الأدوات مع الآثار الأصلية.

يعتمد المستورد على المكتبة القياسية فقط (sqlite3 / csv / json) ويعمل على عامل خلفي، لذا لا تحجب الاستيرادات الكبيرة واجهة المستخدم.

⚡ التحليل المباشر

يحلل الآثار مباشرة من نظام ويندوز قيد التشغيل، مستخرجًا تلقائيًا من مواقعها القياسية لتحليل جنائي في الوقت الفعلي.

🗂️ إدارة القضايا

كل تحقيق هو قضية: دليل مكتفٍ ذاتيًا ينظم قواعد بيانات الآثار ومخرجات التحليل. يتتبع Crow-Eye القضايا الأخيرة (مع المفضلة والوسوم والحالة)، ويتحقق من صحة القضية عند فتحها، ويكتب الإعدادات بشكل ذري (آمن من الانهيار)، ويدعم استيراد/تصدير إعدادات القضايا والقوالب ذات التعيينات الدلالية الجاهزة.

🕰️ تصور الخط الزمني التفاعلي

اربط الأحداث عبر الآثار على شبكة زمنية موحدة، مع عروض الخريطة الحرارية والأسبوع واليوم — قصة مترابطة الهوية وقابلة للتتبع قضائيًا بدلًا من خط زمني فائق مسطح.

يقرأ الخط الزمني قواعد بيانات الآثار المحللة للقضية مباشرة وهو مستقل عن محرك الارتباط — لست بحاجة إلى بناء feathers أو تأليف wings أو تشغيل خط أنابيب لاستخدامه. يطبق تجميعًا زمنيًا خفيفًا خاصًا به (ارتباط بالطابع الزمني الدقيق ونافذة زمنية، وتجميع حسب التطبيق أو المسار أو المستخدم) لربط الأحداث على الشبكة. كما تظهر الأدلة المُدخلة عبر استيراد الأدلة على الخط الزمني كنوع آثار imported، مع تصفية نافذة زمنية وحدود زمنية فعالة.

🔎 البحث والتصدير

بحث نص كامل عبر قاعدة بيانات القضية، بالإضافة إلى التصدير إلى CSV (جداول بيانات)، وJSON (التكامل مع أدوات أخرى)، وتقارير HTML مفصلة (ملفات شاملة تجمع كل أثر مرتبط بمصطلح البحث).

🔗 الربط الديناميكي

ترجم المعرّفات التقنية الخام — SIDs وعناوين MAC والتجزئات — إلى سياق مفهوم بشريًا أثناء التنقل. يُثري الربط الديناميكي العرض باستخدام استعلامات SQL ATTACH غير مدمرة، فلا تُعدَّل الأدلة الأصلية أبدًا، ويمكنه استيعاب خلاصات تهديدات IOC المجمعة لتمييز المؤشرات الضارة المعروفة داخل العرض.

🧠 تحليلات سلوك المستخدم (UBA)

حوّل الآثار الخام إلى قصة نشاط بلغة بسيطة — سرد قابل للقراءة من قبل المديرين/الموارد البشرية لما فعله المستخدم وتطبيقاته فعليًا، مع إمكانية تتبع كل عبارة إلى دليل المصدر الدقيق.

تحليلات سلوك المستخدم (UBA) تقرأ قواعد بيانات الآثار المحللة في مجلد Target_Artifacts/ الخاص بقضيتك (للقراءة فقط بشكل صارم) وتعيد تشغيلها عبر مجموعة قواعد تعريفية لإنتاج قصة نشاط زمنية واضحة. افتحها من زر شريط الأدوات "User Behavior" أو باستخدام Ctrl+Shift+B (يجب تحميل قضية).

• 🧩 40 كشفًا سلوكيًا تعريفيًا (uba/config/behavior_rules.json) — قابل للضبط دون برمجة — كل منها مصنف حسب الخطورة: روتيني · ملحوظ · مشبوه · حرج.
• 🕵️ يكشف السلوك المهم: تسجيل الدخول / تسجيل الخروج / فتح القفل، إطلاق البرامج · تنفيذها · تثبيتها، فتح / حذف الملفات / النسخ المستنتج، اتصال أجهزة USB، الوصول إلى مشاركات الشبكة، الاستمرارية والتشغيل التلقائي، استخدام بيانات الاعتماد الصريحة (runas)، تغييرات الحسابات والمجموعات، تغييرات الخدمات، التلاعب بساعة النظام (مشبوه)، ومسح سجلات الأحداث (حرج).
• 🗺️ ثلاثة عروض — خلاصة قصة النشاط، وخريطة نشاط حرارية (يوم × ساعة)، وتقرير شفافية بعنوان "ما يمكننا رؤيته" يسمي كل كشف يعمل / محدود / لا بيانات / حسب التصميم لهذه القضية.
• 🔗 كل نشاط مدعوم بأدلة. انقر على أي عنصر لفتح السجل الداعم الدقيق (database : table : rowid) — لا يُدَّعى شيء دون مصدر.
• 👤 إسناد صادق. تُحل الفاعلون إلى مستخدم / تطبيق / نظام (أو تُترك فارغة) — لا تخمّن UBA أبدًا من فعل ماذا.

تغطية الكشف

تغطي الكشوفات الأربعون أربع فئات خطورة والمدى الكامل لمجموعة الآثار المحللة:

الفلاتر: بحث نص حر · المستخدم/الفاعل (بما في ذلك "غير منسوب" وتبديل الجلسة المسجلة الدخول) · فئة السلوك (مستخدم / تطبيق / نظام) · الخطورة · التطبيق (تحديد متعدد قابل للبحث عبر أكثر من 200 برنامج) · نطاق التاريخ والوقت مع إعدادات مسبقة سريعة (كل الوقت / اليوم الأول / اليوم الأخير / آخر ساعة من النشاط).

مصادر البيانات: سجلات أحداث Security وSystem وApplication · USN Journal · MFT · UserAssist · BAM · Prefetch · ShimCache · AmCache · MUICache · ShellBags · LNK / JumpLists · سلة المحذوفات · SRUM (التطبيق، الشبكة، الاتصال) · خلايا السجل.

الضمانات الجنائية

• للقراءة فقط. تُفتح قواعد بيانات المصدر للقراءة فقط؛ ولا يلمس التحليل الأدلة أبدًا.
• سلسلة تتبع كاملة. يحمل كل حدث database → table → rowid ويفتح صفوف المصدر الفعلية عند الطلب.
• الإسناد لا يخمن أبدًا. يُنسب الحدث إلى مستخدم أو تطبيق أو النظام — أو يُترك فارغًا. تُستخدم جلسات تسجيل الدخول التفاعلية فقط كتسميات سياقية ("خلال جلسة <user>")، ولا تُستخدم أبدًا لإسناد إجراء.
• صياغة صادقة. تميز العبارات التفاعل المتعمد (UserAssist، بيانات المقدمة في SRUM) عن الآثار التي يمكن للتطبيق توليدها أيضًا (ShellBags، LNK، JumpLists)، مع تحفظات صريحة معروضة على البطاقة.
• الغياب مُعلن، لا مُلمَّح. يسمي تقرير ما يمكننا رؤيته كل كشف لهذه القضية تحديدًا، فلا تُقرأ البيانات المفقودة أبدًا ضمنيًا على أنها "لم يحدث شيء".

UBA هي ارتباط وتصنيف سلوكي مدفوع بالقواعد، وليس تقييمًا للشذوذ إحصائيًا أو بتعلم الآلة — كل نتيجة تُربط بقاعدة صريحة قابلة للتدقيق. راجع RELEASE_NOTES.md للكتالوج الكامل للكشوفات.

🧩 محرك الارتباط

محرك الارتباط v1.7.0 — نواة إعادة البناء. راجع RELEASE_NOTES.md لتاريخ الإصدارات.

محرك الارتباط في Crow-Eye هو نظام ارتباط جنائي بجودة إنتاجية. يستوعب آثار ويندوز من أي مصدر، ويعيد تطبيعها، ويُبرز العلاقات الزمنية والهوية التي تحول السجلات المعزولة إلى سرد متماسك لما حدث على النظام، ومتى، ومن كان متورطًا. يعمل مباشرة بقواعد ارتباط مدمجة (Wings) لأكثر أسئلة التحقيق شيوعًا، ويسمح للمحللين بتأليف قواعد مخصصة دون لمس البرمجة، ويُحيل المعنى إلى قواعد قابلة للتأليف وإلى المحقق — وليس أبدًا إلى درجة صندوق أسود.

🎥 دليل المستخدم

استيراد البيانات الشامل: يمكن لمحرك الارتباط أخذ مخرجات أي أداة جنائية بصيغة CSV أو JSON أو SQLite وتحويلها إلى قاعدة بيانات Feather. هذا يعني أنه يمكنك ربط البيانات من أدوات طرف ثالث (Plaso, Autopsy, Volatility, إلخ) مع الآثار الأصلية لـ Crow-Eye، مما ينشئ تحليل ارتباط موحدًا عبر جميع مصادر بياناتك الجنائية.

🎯 الدقة واكتمال الأدلة

مراجعة دقة مركّزة، تم التحقق منها من البداية إلى النهاية مقابل قضية ويندوز حقيقية تضم ~700 ألف سجل، مبنية فوق أعمال الموثوقية السابقة. كل إصلاح أدناه مُثبت بواسطة مجموعة اختبارات الانحدار pytest ويُتحقق منه بواسطة إطار تحقق شامل يختبر جميع الأجنحة الافتراضية السبعة ضد المحركين.

محرك الهوية يلتقط كل الأدلة

• تم الإصلاح: كان محرك الهوية يكرر فقط الصف الأول من كل feather عند تفعيل مرشح وقت (مقارنة datetime واعية بالمنطقة الزمنية مقابل ساذجة أثارت TypeError وأوقفت حلقة كل صف). قفز عدد السجلات المرئية من 3,558 إلى 745,615 في قضية التحقق.
• تم الإصلاح: كانت سجلات السجل تطوي كل حدث إلى موفر الحدث الخاص به كهوية (جميع سجلات SecurityLogs البالغة 33,855 تشترك في هوية واحدة). يعطي التعيين الخاص بكل أثر الآن الأولوية للكيانات الحقيقية لكل صف (User, ComputerName, NewProcessName, TargetUserName) قبل البيانات الوصفية للقناة/الموفر.
• تم الإصلاح: تعيين الحقول المدرك للأثر لم يكن يعمل أبدًا لأن المحللات لا تختم عمود artifact على كل صف. يعود المحرك الآن إلى feather_metadata.artifact_type، لذا تستخدم SecurityLogs / SystemLogs / ApplicationLogs أولوية الهوية الخاصة بأثرها.
• تم الإصلاح: أصبحت سلاسل العناصر النائبة هويات زائفة ('N/A', 'Unknown', '-', ومعرفات GUID الصفرية جمعت سجلات غير مرتبطة معًا). يرفض المُتحقق الآن أكثر من 30 صيغة عنصر نائب.
• النتيجة الصافية على نافذة كاملة المدى واحدة: يُظهر جناح Execution Proof 2,856 تطابقًا عبر feathers (عالٍ) في محرك الهوية و643 تطابقًا عبر feathers في محرك الوقت، مع 24–118 تطابقًا عبر feathers لكل جناح عبر الأجنحة الستة الأخرى.

لا مزيد من "كل شيء منخفض — هناك شيء خاطئ"

• تم الإصلاح: كانت التطابقات أحادية feather موسومة High. التطابقات ذات feather_count == 1 تحصل الآن على confidence_category="Low - single feather"، لذا يركز عرض High على الارتباط الحقيقي عبر feathers.
• تم الإصلاح: كان مفتاح مركب مدرك للمسار يقسم الهوية نفسها عبر feathers (يخزن كل feather المسارات بشكل مختلف، لذا كان لـ chrome أكثر من 10 مفاتيح ولم يرتبط أبدًا). المفتاح الآن بالاسم فقط — يعمل الارتباط عبر feathers مجددًا.

كشف الانتحال عبر تصنيف المسار — بعد تكوين التطابق، يصنف المحرك مسار كل سجل على أنه موثوق (Program Files, System32, WinSxS, صيغ BAM/SRUM /device/harddiskvolumeN/..., …) أو مشبوه (Temp, Downloads, Public, AppData\Local\Temp, سلة المحذوفات, الجذور القابلة للإزالة, مشاركات الشبكة). يثير التطابق الذي يمتد عبر التصنيفين impersonation_alert (معدل ≈0.05%، كل منها مرشح حقيقي).

محاسبة أدلة صادقة — دفتر إسقاط لكل نافذة بحاويات مسماة (no_identity_field, normalize_failure, below_threshold_skipped, …) بالإضافة إلى ملخص لكل خط أنابيب (السجلات المرئية، العالي/المنخفض المُخرَج، بدون هوية، حاويات الإسقاط، وصلات feathers الخالدة). كل سجل إما يصل إلى تطابق أو إلى حاوية إسقاط مسماة — "لا أدلة متبقية" قابل للتحقق من السجل. low_confidence_review_mode مفعل افتراضيًا، لذا تصبح المجموعات دون العتبة تطابقات منخفضة الثقة بدلًا من الاختفاء بصمت.

إثراء هوية feathers الخالدة — feathers دون طوابع زمنية لكل صف (AutoStartPrograms, MUICache, SystemServices, TypedPaths) لم تعد تحصل على وقت توليد وهمي مختم على كل صف؛ بدلًا من ذلك، بعد تكوين التطابقات الموقوتة، يضم المحرك السجلات المتطابقة من كل feather خالد حسب الهوية كأدلة تكميلية.

سجل هوية موحد — config/standard_fields/identities.json هو المصدر الوحيد للحقيقة لكل عمود يجب أن تراجعه المحركات + Eye: 98 فئة، 1,146 مرادف عمود (تطبيق/عملية، ملف، تجزئة، مستخدم، مضيف/جهاز، شبكة، سجل، خدمة/مهمة، حدث، بريد إلكتروني، متصفح، سحابة، دواخل ويندوز، شهادة، حاوية، كائنات نظام التشغيل). إضافة مرادف عمود جديد هي تعديل JSON، وليس تغيير برمجة.

إصلاحات الإيجابيات الزائفة في التعيين الدلالي — أصبحت بوابات المؤشرات المتعددة مُطبقة فعليًا الآن (data-exfiltration-pattern يتطلب مؤشرين على الأقل)؛ أُعيدت كتابة قواعد AND المستحيلة (4625 AND 4624) كـ OR؛ تستخدم قواعد أدوات المحو/الوصول عن بُعد تعبيرات regex حقيقية بدلًا من الانطلاق عند كل إدخال Prefetch؛ خُفِّضت قواعد النشاط الأساسي من high/critical إلى info/low (التسجيل المرجح للجناح يُصعّد التهديدات الحقيقية).

✅ حالة الإنتاج

محرك الارتباط جاهز للإنتاج ويُستخدم بنشاط في التحقيقات (محرك الارتباط v1.7.0):- ✅ محرك المسح بنافذة زمنية — جاهز للإنتاج، مُوصى به للتحليل الزمني (O(N log N))

• ✅ المحرك المعتمد على الهوية — جاهز للإنتاج، مُوصى به لتتبّع الهوية (O(N log N))
• ✅ Feather Builder / FeatherWriter — يستورد CSV/JSON/SQLite من أي أداة؛ معالجة دفعية معاملاتية + بيانات وصفية للمخطط
• ✅ نظام Wings وتنسيق خطوط المعالجة — إنشاء/إدارة قواعد الربط وأتمتة سير العمل
• ✅ تجميع الهوية — موحّد عبر المحرك والعارضين والمرحلة الدلالية
• ✅ سجل الحقول القياسية — مصدر حقيقة مركزي لمرادفات الحقول
• ✅ التفرّع متعدد الطوابع الزمنية — كل طابع زمني في قوائم JSON يتم ربطه
• 🔄 الربط المتوازي — الأساس جاهز؛ ملفات التعريف + إرسال مجمع العمليات لاحقًا
• 🔄 التعيين الدلالي وتقييم الربط — تحسينات نشطة

الميزات الرئيسية

• 🔄 بنية مزدوجة المحرك: اختر بين استراتيجيتي الربط: المسح بنافذة زمنية (O(N log N)) والربط المعتمد على الهوية (O(N log N)).
• 📊 دعم متعدد القطع الأثرية: اربط بين Prefetch، ShimCache، AmCache، سجلات الأحداث، ملفات LNK، Jumplists، MFT، USN، SRUM، Registry، سلة المحذوفات، والمزيد.
• 🔌 استيراد شامل: استيراد مخرجات CSV/JSON/SQLite من أي أداة تحقيق جنائي وتحويلها إلى قواعد بيانات Feather.
• 🎯 تجميع هوية ذكي: المتغيرات مثل Chrome.exe/chrome.dll/Chrome.EXE تنكمش في مجموعة واحدة؛ بينما تبقى الإصدارات ومؤهلات البنية المعمارية متميزة.
• 🕒 طوابع زمنية متسامحة: FILETIME، ISO 8601، حقبة يونكس (s/ms/μs)، YYYYMMDD، التنسيق الأمريكي بالشرطة المائلة، والسلاسل المشروحة تُحلَّل بشكل صحيح من المحاولة الأولى.
• 📈 التفرّع متعدد الطوابع الزمنية: قوائم الطوابع الزمنية JSON (Prefetch run_times) تُوسَّع بحيث يحصل كل تنفيذ على حدث الربط الخاص به.
• 🧰 مصدر حقيقة واحد: مرادفات الحقول في config/standard_fields/*.json؛ بيانات وصفية لكل جدول في correlation_engine/config/feather_schemas.json — وسّع بتحرير JSON وليس الكود.
• ⚡ تدفّق + آمن للخيوط: query_time_range_iter بذاكرة O(1)؛ مخابئ feather محمية بالأقفال؛ جاهز للربط المتوازي.
• 🔍 قواعد مرنة: حدد قواعد ربط مخصصة (Wings) بمعاملات قابلة للتهيئة.
• 📋 تشخيصات صادقة: سطر إحصاءات لكل نافذة (records_in / no_identity / parse_cache_hits / below_threshold / matches_emitted) لتعرف دائمًا ما إذا كان قد تم إسقاط دليل.
• 🧪 جودة مضمونة: مجموعة اختبارات انحدار pytest تغطي تحليل الطوابع الزمنية، وتسوية الهوية، والتفرّع، وعقد الكاتب، وتأليف Eye (حوكمة GEP لجهة الكتابة)، وسجل الحقول القياسية.

بنية النظام

يتكون محرك الربط من أربعة مكونات رئيسية:

1. 🗄️ Feathers (تطبيع البيانات)

الغرض: تحويل القطع الأثرية الجنائية الخام إلى تنسيق موحّد قابل للاستعلام.

• قواعد بيانات SQLite تحتوي على بيانات قطع أثرية جنائية مطبّعة — feather واحد لكل نوع قطع أثرية (Prefetch، ShimCache، سجلات الأحداث، …) مع مخطط موحّد وبيانات وصفية لاستعلام فعال.
• تنسيق عام يقبل البيانات من أي أداة تحقيق جنائي.``` Any Tool Output → Feather Builder → Normalized Feather Database (CSV/JSON/SQLite) (SQLite with standard schema)

Examples:

• Plaso CSV → Feather Builder → timeline.db
• Autopsy JSON → Feather Builder → autopsy_artifacts.db
• Volatility CSV → Feather Builder → memory_artifacts.db
• Custom Output → Feather Builder → custom.db

**صيغ الاستيراد المدعومة:** CSV (أي ملف بترويسة)، JSON (مسطّح أو متداخل)، وSQLite (استيراد مباشر). تعيين تلقائي للأعمدة، كشف نوع البيانات، تطبيع الطوابع الزمنية إلى ISO، التحقق من الصحة، وفهارس محسّنة.```
prefetch.db (Feather)
├── feather_metadata (artifact type, source, record count)
├── prefetch_data (executable_name, path, last_executed, hash)
└── Indexes (timestamp, name, path)

2. 🎯 الأجنحة (قواعد الارتباط)

الغرض: تحديد القطع الأثرية التي يجب ربطها وكيفية ذلك.

• قواعد JSON/YAML تحدد نافذة زمنية، والحد الأدنى من التطابقات، وأولوية الارتكاز، والريش (مع الأوزان) التي سيتم ربطها — قابلة لإعادة الاستخدام عبر القضايا. كل جناح قابل للإنشاء ومختوم (يسجّل من أنشأه، ولماذا، والدليل الذي دفع إلى إنشائه).```json { "wing_id": "execution-proof", "wing_name": "Execution Proof", "correlation_rules": { "time_window_minutes": 5, "minimum_matches": 2, "anchor_priority": ["Prefetch", "SRUM", "AmCache"] }, "feathers": [ {"feather_id": "prefetch", "weight": 0.4}, {"feather_id": "shimcache", "weight": 0.3}, {"feather_id": "amcache", "weight": 0.3} ] }

#### 3. ⚙️ المحركات (استراتيجيات الارتباط)

**الغرض**: تنفيذ منطق الارتباط للعثور على العلاقات بين العناصر. تأتي الروابط البنيوية **أولاً**؛ وتُضاف درجة مرجحة بالمستويات فوقها كـ *تفسير/ترتيب*، وليس كأساس للمطابقة.

**محرك المسح عبر النوافذ الزمنية (Time-Window Scanning Engine)** — الأفضل للتحليل الزمني والارتباط الزمني المنهجي. يمسح عبر الزمن بفواصل ثابتة، ويجمع السجلات من جميع الـ feathers لكل نافذة، ويطبّق مطابقة الحقول الدلالية + التسجيل الموزون، ويمنع التكرار عبر تتبع MatchSet. **O(N log N)** (استعلامات طوابع زمنية مفهرسة)؛ معالجة دفعية (~2,567 نافذة/ثانية).

**محرك الارتباط المعتمد على الهوية (Identity-Based Correlation Engine)** — الأفضل لمجموعات البيانات الكبيرة (>1,000 سجل) وتتبع الهوية. يستخرج الهويات ويوحّدها، ويجمع السجلات حسب الهوية، ويبني مراسي زمنية داخل كل عنقود، ويصنّف الأدلة كأولية/ثانوية/داعمة، ويُدفق البيانات للمجموعات الكبيرة جدًا (>5,000 مرساة) بذاكرة ثابتة. **O(N log N)**؛ أكثر من 40 نمطًا لحقول الهوية لكل نوع.

**اختيار المحرك:** استخدم محرك النافذة الزمنية للتحليل الزمني ومحرك الهوية لتتبع الهوية — كلاهما جاهز للإنتاج ومحسّن لمجموعات البيانات الكبيرة باستعلامات مفهرسة.

#### 4. 🔄 خطوط الأنابيب (تنسيق سير العمل)

**الغرض**: أتمتة سير عمل التحليل الكامل من إنشاء الـ feathers إلى توليد النتائج. يقرأ خط الأنابيب إعداداته (نوع المحرك، الـ wings، الـ feathers)، ويستدعي المحرك الصحيح عبر الـ EngineSelector، وينفّذ كل wing، ويجمّع المطابقات، ويحفظ النتائج (DB + JSON)، ويعرضها في واجهة المستخدم الرسومية مع التصفية والتصور.```json
{
  "pipeline_name": "Investigation Pipeline",
  "engine_type": "identity_based",
  "wings": [{"wing_id": "execution-proof"}, {"wing_id": "file-access"}],
  "feathers": [
    {"feather_id": "prefetch", "database_path": "data/prefetch.db"},
    {"feather_id": "srum", "database_path": "data/srum.db"},
    {"feather_id": "eventlogs", "database_path": "data/eventlogs.db"}
  ],
  "filters": {
    "time_period_start": "2024-01-01T00:00:00",
    "time_period_end": "2024-12-31T23:59:59"
  }
}

كيف يعمل كل ذلك معًا```

1. Data Preparation Raw Forensic Data → Feather Builder → Feather Databases
2. Configuration Wing Configs + Feather References → Pipeline Config
3. Execution Pipeline Executor → Engine Selector → Correlation Engine
4. Correlation Engine loads Feathers + applies Wing rules → Correlation Results
5. Visualization Results Database → Results Viewer GUI

### مثال استخدام: إيجاد دليل التنفيذ

**السيناريو**: إثبات أن `malware.exe` تم تنفيذه على النظام.```json
{
  "wing_id": "malware-execution",
  "correlation_rules": { "time_window_minutes": 5, "minimum_matches": 2 },
  "feathers": ["prefetch", "shimcache", "amcache"]
}

I don't see any source content to translate in this chunk. The input appears to be empty. Please provide the chunk text so I can translate it into Arabic.```python from correlation_engine.pipeline import PipelineExecutor executor = PipelineExecutor(pipeline_config) results = executor.execute()

json:'{"params":{"event":"sitedata","data":{"channel":"dropzone-id","fetch_config":{"fields":["id","length"]}}}}' \```
Identity: malware.exe
  Anchor 1 (2024-01-15 10:30:00):
    ✓ Prefetch: malware.exe executed at 10:30:00
    ✓ ShimCache: malware.exe modified at 10:30:15
    ✓ AmCache:  malware.exe installed at 10:29:45

  Conclusion: Execution proven with 3 corroborating artifacts

معايير الأداء

البدء مع محرك الارتباط (Correlation Engine)

1. الإطلاق: python -m correlation_engine.main
2. إنشاء Feathers: استيراد آثارك الجنائية (Prefetch، ShimCache، …).
3. إنشاء Wings: تعريف قواعد الارتباط لتحقيقك.
4. إنشاء Pipeline: تكوين الـ Wings والـ Feathers التي تريد استخدامها.
5. التنفيذ: تشغيل الـ Pipeline وعرض النتائج المترابطة.
6. التحليل: استخدام عارض النتائج لاستكشاف العلاقات الزمنية.

📚 وثائق محرك الارتباط

• نظرة عامة على محرك الارتباط — نظرة عامة على النظام مع مخططات معمارية
• وثائق المحرك — معمارية المحرك المزدوج، اختيار المحرك، تحسين الأداء
• المعمارية — تكامل المكونات وتدفق البيانات
• وثائق Feather — نظام تطبيع البيانات
• وثائق Wings — قواعد الارتباط
• وثائق Pipeline — تنسيق سير العمل
• إضافة أثر — سير العمل لتوصيل محلل جديد بالمحرك
• سجل الحقول القياسية — المرادفات الأساسية لأسماء الأعمدة التي يحمّلها كلا المحركين و Eye
• دليل المساهمة — كيفية المساهمة في المحرك
• روابط سريعة: اختيار المحرك · استكشاف الأخطاء وإصلاحها · تحسين الأداء

👁️ Eye — مساعد الطب الشرعي بالذكاء الاصطناعي

مساعد قوي، وليس بديلاً. يقوم Eye بأتمتة فرضيات المحقق والتحقق منها — ولا يتخذ القرار نيابة عنك أبدًا.

Eye هو مساعد الطب الشرعي بالذكاء الاصطناعي المدمج في Crow-Eye: محقق جنائي ماهر مدعوم بقاعدة معرفية حقيقية لآثار Windows. يمنحك واجهة بلغة طبيعية للاستعلام عن كل شيء في القضية وربطه وتوثيقه — Prefetch، MFT، السجل (Registry)، سجلات الأحداث (Event Logs)، AmCache، ShimCache، SRUM، والمزيد — مع الحفاظ على سجل قابل للتدقيق ومقاوم للعبث يوضح بالضبط ما فعله. يمكن تشغيل Eye بالكامل على أجهزتك الخاصة (بما في ذلك معزول تمامًا عن الشبكة)، تماشيًا مع موقف الخصوصية الخاص بـ Crow-Eye: «0 ms من البيانات تُرسل خارج الجهاز». المعمارية الكاملة: eye/README.md.

يحوّل Eye الأسئلة المحادَثاتية («أرني ما تم تنفيذه من C:\Temp بعد الساعة 22:00») إلى عمل جنائي حقيقي: يخطط لنهج، ويسترجع المعرفة ذات الصلة بالآثار، وينفذ استعلامات SQL وبحوثًا عبر الآثار ضد قواعد بيانات قضيتك، ويولّف إجابة مُتحقَّقًا منها. يُنتَج كل إجابة في مكانين في الوقت نفسه — رد محادثة لك، وكتلة منظمة تُكتب في مساحة عمل التقرير الحي بحيث يبني الملف نفسه مع تقدم التحقيق.

بروتوكول غسان إلزمان (GEP)

كل ما يفعله Eye مرتبط بـ بروتوكول غسان إلزمان (GEP) — وهو معيار محايد تجاه البائعين ومستقل عن الأدوات حول كيف ينبغي استخدام أي ذكاء اصطناعي في الطب الشرعي الرقمي. وهو 10 مبادئ يجب أن يلتزم بها أي نظام مطابق بحيث تظل النتائج المدعومة بالذكاء الاصطناعي صادقة، وقابلة للتتبع إلى السجلات المصدرية، ومدعومة بسلسلة قابلة للتدقيق ومقاومة للعبث، مع بقاء المحقق البشري مسيطرًا:

Eye الخاص بـ Crow-Eye هو التنفيذ المرجعي لبروتوكول GEP؛ والسلوكيات داخل المنتج التي تدعمه هي قواعد التشغيل. 📜 اقرأ المعيار: eye/docs/GEP_standard.md.

أوضاع النشر

يتكيف Eye مع نموذج التهديد الخاص بك من خلال ثلاثة أوضاع للنشر:

في وضع وكيل CLI، يقود Crow-Eye وكيلًا طرفيًا/سطر أوامر للذكاء الاصطناعي موجودًا مسبقًا كنموذج — بدلاً من واجهة برمجة تطبيقات سحابية أو خادم محلي دون اتصال — بحيث يمكنك التحقيق باستخدام الوكيل الذي تستخدمه بالفعل.

حلقة التحقيق:

1. افتح قضية أو أنشئها — يحدد Eye نطاقه على قواعد بيانات الآثار الخاصة بتلك القضية وتاريخها.
2. اطرح سؤالاً باللغة الطبيعية، أو شغّل فرزًا شاملاً بنقرة واحدة.
3. يشغّل Eye خط أنابيبه — اكتشاف النية ← استرجاع المعرفة ← تنفيذ الأدوات ← التوليف.
4. تحصل على مخرجات مزدوجة — إجابة محادثة مباشرة و كتلة جديدة في التقرير الحي.
5. وافق على الإجراءات المقيدة — عمليات التصدير والخطوات الحاسمة الأخرى تنتظر موافقتك.

يمكنك تغيير النماذج في وقت التشغيل باستخدام أداة switch_model. التبديل مقصور على نفس الواجهة الخلفية، لذا لا تُرسل الأدلة بصمت أبدًا إلى مزود مختلف عن الذي اخترته.

تتبع عملية تفكير نموذج اللغة الكبير (LLM)

تم بناء Eye بحيث يمكنك رؤية — وإثبات لاحقًا — كيف وصل إلى استنتاج. أثناء عمل Eye، يبث تحديثات ThinkingStep منظمة إلى الواجهة في الوقت الفعلي؛ يحمل كل تحديث step_id وtype وlabel قابلًا للقراءة البشرية وstatus (active → done أو error)، وtool/params/detail اختياريًا.

يتكشف الاستعلام النموذجي على النحو thinking → rag → thinking → tool_call → synthesis، وكل قضية تحتفظ بآثار تتبع على القرص يمكنك فحصها بعد ذلك:

تنفيذ الأدوات

Eye مبني على الأدوات: النموذج لا يلمس الأدلة مباشرة أبدًا. يصدر استدعاءات أدوات، وينفذها Eye ضد قواعد بيانات القضية ويعيد النتائج — لذا كل إجراء صريح ومسجل وقابل لإعادة الإنتاج. تُعرَّف الأدوات في configs/llm_config.json وتُوجَّه عبر eye/services/context_manager.py.

الأدوات الاستقصائية — قراءة الأدلة وتحليلها:

أدوات إعداد التقارير تبني مساحة عمل التقرير الحي: report_append_section، وreport_add_data_table، وreport_add_chart، وreport_add_timeline، وreport_add_heatmap، وreport_add_chain_of_custody، وreport_add_chat_transcript، وreport_add_image، وreport_edit_section، وreport_delete_section، وchat_add_table، وexport_report (يتطلب التصدير موافقة بشرية).

أدوات التأليف (خاضعة للحوكمة — راجع بناء Wings الارتباط والخرائط الدلالية): correlation_create_wing، وcorrelation_edit_wing، وcorrelation_create_semantic_mapping، وcorrelation_edit_semantic_mapping. تُترجم استدعاءات الأدوات إلى ما تتوقعه الواجهة الخلفية النشطة — استدعاء الدوال الأصلي لواجهات برمجة التطبيقات السحابية والخوادم المحلية، أو غلاف XML <tool_call> لوكلاء CLI.

بناء Wings الارتباط والخرائط الدلالية

لا يستعلم Eye فقط من محرك الارتباط — بل يمكنه المساعدة في توسيعه. عندما يكتشف Eye نمطًا متكررًا عبر الآثار، يمكنه اقتراح Wings جديدة (قواعد ارتباط) وخرائط دلالية (ترجمات من التقني إلى البشري). هذا تأليف خاضع للحوكمة: يقترح Eye، ويراجع المحلل الأثر المحفوظ، وكل تغيير مبرر ومدعوم بالأدلة.

الـ Wing يربط الـ Feathers معًا ضمن نافذة زمنية وعتبة حد أدنى للتطابق لإثبات ادعاء:

الخريطة الدلالية تترجم قيمة تقنية خام إلى معنى قابل للقراءة البشرية (مثل EventID 4624 → «تسجيل دخول ناجح»). تأتي بنوعين: mapping بسيط (قيمة/تعبير نمطي واحد → قيمة دلالية) أو rule متعدد الشروط (شروط مربوطة بـ AND/OR). كلاهما يدعم category وseverity وconfidence وscope، وكلاهما يتطلب reason + related_evidence.

الحوكمة — قواعد جهة الكتابة التي تدعم GEP:

• السبب مطلوب (يدعم GEP-9 + GEP-2): كل عملية إنشاء وتعديل يجب أن تتضمن reason جنائيًا.
• ربط الأدلة (يدعم GEP-2): كل عملية إنشاء يجب أن تستشهد بمرجع database:table:rowid واحد على الأقل.
• ختم Eye / للقراءة فقط للآخرين (يدعم GEP-7 + GEP-9): يختم Eye تأليفه + السبب + سجل التعديلات، ولا يجوز له تعديل إلا ما ألفه Eye — القواعد المدمجة والقواعد التي ألفها البشر تظل للقراءة فقط.

السياق ذاتي الإصلاح

يمكن للتحقيقات الطويلة أن تتجاوز نافذة سياق النموذج — خاصة النماذج الأصغر دون اتصال. بدلاً من الانهيار أو إسقاط الأدلة بصمت، يقوم Eye بضغط سياقه تلقائيًا قبل كل استدعاء نموذج (داخل مسار التوليد المحمي الخاص به، مع تدقيق كامل).

قبل كل استدعاء، يقيس Eye الحمولة الكاملة ويحجز مساحة للرد (10% من النافذة، بحد أدنى 512 توكنًا، ولا يزيد أبدًا عن النصف). إذا لم تكن لا تزال مناسبة، فإنه يعالج الأمر في مرحلتين مرتبتين، دون لمس الرسائل المحمية أبدًا (المثبتة، أو الأدلة المكتشفة تلقائيًا، أو نتيجة أداة):

1. مرحلة التلخيص (مرة واحدة) — يُدمج السجل غير المحمي في ملخص واحد، مع تسجيل SUMMARIZED.
2. مرحلة الإسقاط — تُزال أقدم رسالة غير محمية واحدة تلو الأخرى حتى يصبح مناسبًا، مع تسجيل TRUNCATED.

إذا كان جوهر الأدلة غير القابل للاختزال (المثبت + نتائج الأدوات + السؤال الحالي) لا يزال يفيض، فإن Eye يرفض المتابعة بدلاً من اقتطاع الأدلة (REFUSED_OVERFLOW) ويطلب منك تضييق نطاق الاستعلام أو استخدام analyze_large_dataset. وأي شيء يصل في النهاية إلى النموذج هو الحمولة الدقيقة التي تُختتم لسلسلة الحيازة.

🗺️ الخريطة السردية (Narrative Map) — ذاكرة القضية الدائمة للـ Eye

يكون الـ Eye عديم الحالة بين الجولات — لذا فإن الخريطة السردية هي المكان الذي تعيش فيه «ما نعرفه وما خلصنا إليه» لقضية ما. إنها ذاكرة عمل دائمة، قابلة للتدقيق، ومقاومة للعبث تخص الـ Eye، ومحتوياتها تُحقن في موجه الـ Eye في كل جولة (الخريطة حرفيًا هي الذاكرة).

• 🧭 الحكم ← السرد ← الأدلة. تسلسل هرمي صارم: حكم واحد للقضية، والسرديات تحته (ادعاءات، لكل منها حالة — proven · open · negative · needs · absolute)، وتحتها الأدلة المدعومة بالآثار.
• 🪟 نافذتها الخاصة. تُفتح من زر «الخريطة السردية» في نافذة محادثة الـ Eye، بحيث يمكنك مشاهدة المحادثة والتقرير الحي وذاكرة القضية جنبًا إلى جنب؛ وتُحدَّث تلقائيًا مع تغير الأمور.
• ↔️ ثنائية الاتجاه — ذاكرة تتحكم بها أنت. تتدفق كل من تعديلات الـ Eye وملاحظاتك أنت عبر التزام واحد مُتحقق عبر GEP وتُختتم في سجل تدقيق مترابط بالتجزئة (narrative_map_audit.jsonl). يمكنك إضافة وتعديل وإزالة ادعاءاتها وأدلتها، مما يشكّل مباشرةً كيفية فهم الـ Eye للقضية وتفسيرها.
• 🚫 لا تدّعي أبدًا ما هو غير مدعوم. قد يظل سرد الـ Eye open دون أدلة أثناء تحقيقه، لكنه لا يمكن أبدًا أن يصبح proven دون أدلة؛ والموضوع الذي فحصه الـ Eye ووجده فارغًا يتحول تلقائيًا إلى negative — لأن الغياب الموثق هو بحد ذاته نتيجة.

كيف يعمل الامتثال

الامتثال ليس ميزة تُثبَّت فوق النظام — بل يُفرض داخل خط الأنابيب.

• 🔗 سلسلة الحيازة (ختم الأدلة). كل حمولة يرسلها الـ Eye إلى نموذج لغة كبير تُختتم: SHA-256 للبايتات الدقيقة، وعدد التوكنات، والنموذج + حد سياقه، ومصدر كل صف أدلة (database:table:rowid، بالإضافة إلى الإزاحات المحسوبة لسجلات MFT). الأختام للإلحاق فقط ومترابطة بالتجزئة في <case>/EYE_Logs/eye_payload_seal.jsonl — أي سجل واحد معدَّل أو محذوف يكسر السلسلة، لذا يثبت السجل رياضيًا البايتات التي حللها النموذج.
• 🚫 لا اقتطاع صامت. عندما يضيق السياق، يلجأ الـ Eye إلى الإصلاح الذاتي ويعيد تخصيص الميزانيات بترتيب صارم: الأولوية 1 (غير قابلة للتحريك): الأدلة الخام + موجه النظام › الأولوية 2 (قابلة للتضحية): المحادثة العابرة › الأولوية 3 (مرنة): سياق RAG. إذا لم تتسع الأدلة الأساسية بعد، يرفض الـ Eye بدلاً من إسقاط الأدلة بهدوء.
• 🧾 مسار تدقيق الاقتطاع. يُسجل كل قرار يتعلق بالسياق في <case>/EYE_Logs/truncation_audit.log (SUMMARIZED، TRUNCATED، PRESERVED، PINNED، UNPINNED، BUDGET_REDUCED)، كل منها مع تجزئة. يتم تثبيت الأدلة المكتشفة تلقائيًا فوق حد ثقة معين؛ ويمكنك أيضًا تثبيت الرسائل يدويًا.
• 📑 إلزامية نقل الأدلة إلى التقرير. يجب على الـ Eye الإجابة في المحادثة و حفظ الأدلة الداعمة في التقرير؛ والفشل في تسجيل الأدلة يُعلَّم كانتهاك للبروتوكول.
• ⚖️ حوكمة الارتباط. أي Wing أو خريطة يؤلفها الـ Eye يجب أن تتضمن reason جنائيًا وrelated_evidence؛ والقواعد المؤلفة خارج الـ Eye للقراءة فقط ولا يمكن إعادة كتابتها بصمت.
• 🔐 الخصوصية والعزل عن الشبكة. في الأوضاع دون اتصال، لا يجري الـ Eye أي استدعاءات صادرة؛ مفاتيح واجهات برمجة التطبيقات السحابية تعيش في سلاسل المفاتيح الأصلية لنظام التشغيل — غير مكتوبة بشكل ثابت في الكود أبدًا، ولا تُكتب في السجلات أبدًا.

📖 معمارية الـ Eye الكاملة: eye/README.md.

📖 Eye-Describe — قاعدة معرفة الآثار على مستوى البايت

🔗 استكشف Eye-Describe ← crow-eye.com/eye-describe

تاريخيًا، وقع المحققون في فخ الثقة بأدواتهم الجنائية دون فهم كيف تتصرف الآثار الأساسية أو كيف حللتها الأداة. الخطر اليوم هو ببساطة استبدال «الأداة» بـ «الذكاء الاصطناعي». يمكن للذكاء الاصطناعي تحليل سجل بدقة تقنية مثالية ومع ذلك وضعه في سياق خاطئ — مما يغير المعنى الكامل للدليل.

Eye-Describe موجود بحيث لا يضطر لا الإنسان ولا النموذج إلى التخمين. إنه مرجع تفاعلي على مستوى البايت للهياكل الثنائية الخام لآثار Windows، ويخدم دورين في الوقت نفسه:

من خلال تثبيت طبقة الذكاء الاصطناعي على سلوك الآثار الموثق، لا يطلب منك Crow-Eye أن تثق بنموذج — بل يقيد النموذج لاحترام الطب الشرعي الخام.

لا تستبدل الثقة بالأداة بثقة بالذكاء الاصطناعي. افهم البيانات.

🧪 الجودة والتحقق

الأدوات الجنائية مفيدة فقط إذا كان يمكن الدفاع عن مخرجاتها. جهود Crow-Eye في مجال الصحة مرئية عن قصد:

• مجموعات اختبار الانحدار. يُثبَّت محرك الارتباط بمجموعة اختبارات pytest تغطي تحليل الطوابع الزمنية، وتطبيع الهوية، والتوزيع متعدد الطوابع الزمنية، وعقد الكاتب، وتأليف الـ Eye (حوكمة GEP لجهة الكتابة)، وسجل الحقول القياسية. ويشحن محرك UBA مجموعته الخاصة، بما في ذلك تشغيل شامل من البداية إلى النهاية ضد قضية حقيقية.
• منصة التحقق. منصة شاملة تختبر الـ Wings الافتراضية السبعة ضد كلا المحركين على قضية Windows حقيقية تضم ~700 ألف سجل.
• تاريخ العيوب المنشور. الانحدارات في الدقة وتأثيرها المُقاس موثقة علنًا في RELEASE_NOTES.md — بما في ذلك حالات غيّر فيها إصلاح ما السجلات المرئية بعدة مراتب حجمية. معرفة ما كان خاطئًا ومتى يُعد جزءًا مما يجعل النتيجة قابلة للدفاع.
• محاسبة أدلة قابلة للتحقق. كل سجل إما يستقر في تطابق أو في دلو إسقاط مسمى، ودفتر الإسقاط لكل نافذة يجعل من «لا أدلة متبقية» شيئًا يمكنك التحقق منه من السجل بدلاً من تصديقه.
• سجلات مقاومة للعبث. تعيد verify_chain() اجتياز سجل تدقيق الخريطة السردية وسلسلة ختم الأدلة لاكتشاف التعديل — بما في ذلك الحقول القابلة للقراءة البشرية.

🔬 منصة الأبحاثCrow-Eye هو أكثر من مجرد برنامج — إنه منصة بحث مفتوحة تعمل على تسريع مجال تحليل الأدلة الرقمية في ويندوز (Windows Forensics) بالكامل. يركز المشروع على:

• نشر توثيق مفصّل حول البنى الداخلية للـ artifacts.
• مشاركة منطق الارتباط (correlation logic) والمنهجيات.
• تمكين مراجعة الأقران والشفافية والتعاون الأكاديمي.
• المساهمة في المعرفة الجماعية لمجتمع التحليل الرقمي.

🛠️ ملاحظات تقنية

• يتطلب تحليل الـ Registry ملفات كاملة لقاعدة بيانات الـ Registry hive.
• تتطلب بعض الـ artifacts معالجة خاصة بسبب آليات قفل الملفات في ويندوز (انظر قاعدة بيانات مؤمّلة / ملفات مقفلة).
• يتم تحليل LNK و Jump List بواسطة محلل مخصص خاص بـ Crow-Eye.

📸 لقطات الشاشة

مجموعة من واجهات Crow-Eye وطرق العرض التحليلية.

🎥 فيديو تجريبي:

🚧 خارطة الطريق

الأعمال المخطط لها والجارية (انظر RELEASE_NOTES.md للتغييرات المنشورة):

• 📊 طرق عرض وتقارير متقدمة للواجهة — تصور وإعداد تقارير أكثر ثراءً.
• 🔄 حوار بحث محسّن — تصفية متقدمة مع دعم اللغة الطبيعية.
• 🎯 تخطيط دلالي محسّن — تغطية شاملة لحقول جميع أنواع الـ artifacts.
• 📈 تسجيل ارتباط متقدم — تسجيل ثقة دقيق وقابل للتفسير.
• ⚡ ربط متوازٍ — توزيع عبر معالجات متعددة، مفعّل افتراضيًا لأحمال العمل الكبيرة.

لديك فكرة أو تريد إضافة artifact؟ افتح issue أو راجع المساهمة.

📚 التوثيق

• TECHNICAL_DOCUMENTATION.md — البنية، المكونات، ودليل التطوير.
• RELEASE_NOTES.md — ما الجديد في كل إصدار (UBA، Narrative Map، الخلفيات السحابية لـ Eye، تقوية إدارة القضايا، …).
• توثيق محرك الارتباط — نظرة عامة، المحرك، feathers، wings، خطوط المعالجة.
• بنية الخط الزمني — تفاصيل وحدة الخط الزمني الداخلية.
• بنية Eye و معيار GEP — المساعد الذكي والبروتوكول الذي يحكمه.

🤝 المساهمة

تم بناء Crow-Eye كمنصة بحث مفتوحة، والمساهمات مرحّب بها — محللات جديدة، قواعد ارتباط، توثيق، وأبحاث حول الـ artifacts.

• المساهمات العامة: CONTRIBUTING.md
• محرك الارتباط (منطقة ذات أولوية): correlation_engine/CONTRIBUTING.md
• التواصل: [email protected] · أو افتح issue / pull request.

🌐 الموقع والمجتمع

• 🌍 الموقع الرسمي: crow-eye.com — الموارد والتوثيق والتنزيلات.
• 💬 Discord: انضم إلى Discord الخاص بـ Crow-Eye — مساعدة مباشرة، أبحاث الـ artifacts، وإعلانات الإصدارات.

📄 الترخيص

يُصدر Crow-Eye بموجب رخصة GNU العمومية العامة الإصدار 3.0 (GPL-3.0). وهو مجاني للاستخدام والدراسة والمشاركة والتعديل وفقًا لشروط تلك الرخصة.

📝 الاستشهاد بـ Crow-Eye

إذا كنت تستخدم Crow-Eye في عمل أكاديمي، أو بحث منشور، أو تقرير حالة، يرجى الاستشهاد به:```bibtex @software{elsman_crow_eye, author = {Elsman, Ghassan}, title = {Crow-Eye: A Windows Forensics Engine}, url = {https://github.com/Ghassan-elsman/Crow-Eye}, license = {GPL-3.0}, year = {2026} }

نص عادي: Elsman, G. *Crow-Eye: محرك تحليل جنائي لنظام ويندوز* (GPL-3.0). https://github.com/Ghassan-elsman/Crow-Eye

للاستشهادات المنهجية، يتم توثيق بروتوكول Ghassan Elsman بشكل منفصل في [`eye/docs/GEP_standard.md`](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/eye/docs/GEP_standard.md).

## 💖 الدعم

Crow-Eye مجاني ومفتوح المصدر، تم بناؤه وصيانته بواسطة شخص واحد. إذا كان يساعدك في عملك، فيرجى التفكير في رعايته — فهو يمول مباشرةً محللات وأبحاثًا جديدة: **[SPONSORS.md](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/SPONSORS.md)** · **[GitHub Sponsors](https://github.com/sponsors/Ghassan-elsman)**.

## الاعتمادات

تم إنشاؤه وصيانته بواسطة **Ghassan Elsman**.