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

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

جدول المحتويات

• نظرة عامة
• ✨ أبرز المزايا
• 👥 لمن صُمم 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.13.0 · محرك الارتباط: 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"]

REPLAY["DIRTY-HIVE REPLAY<br/>transaction logs applied to a working copy"]
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 -- "every registry hive,<br/>evidence never written to" --> REPLAY
REPLAY -- "the state Windows<br/>had not finished writing" --> 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). محرك الترابط (Correlation Engine) هو طبقة *إضافية*، وليس شرطًا مسبقًا. |
| ③ ← ④ | **الربط الديناميكي (Dynamic Linking) يجاور الخط الزمني و UBA** — قارئ رابع ومستقل لقواعد بيانات القضية (لا علاقة له بتصور الخط الزمني). يجمع خرائط الهوية (SID ← اسم المستخدم، MAC ← الشبكة، hash/GUID ← التطبيق) في قاعدة بيانات `Crow_Intelligence.db` خاصة بكل قضية، ثم يضيف هذا السياق **داخل جداول بيانات القطع الأثرية** عبر استعلامات `ATTACH` + `LEFT JOIN` غير مدمرة. يغيّر طريقة *قراءة* السجلات، ولا يمس الأدلة أبدًا. |
| ④ ← ⑤ | تستعلم العين (Eye) عن قواعد بيانات القضية مباشرة ويمكنها سحب نتائج الترابط **عند الطلب**. لا تلمس الأدلة نفسها أبدًا — بل تصدر استدعاءات أدوات (tool calls) ينفذها Crow-Eye ويسجلها. |
| ⑤ ← التقرير | **التقرير الحي (Living Report) يُبنى بواسطة العين وحدها**، عبر أدواتها `report_*`. الخط الزمني و UBA هما سطحا تحليل — لا يكتبان في التقرير. يمكن مع ذلك تصدير نتائج على مستوى القضية بشكل منفصل عبر [البحث والتصدير](#-search--export). |
| ⑤ ↔ | **الخريطة السردية (Narrative Map) ثنائية الاتجاه**: تكتب فيها العين، وتكتب أنت فيها، وتُحقن محتوياتها في موجه (prompt) العين في كل دورة. إنها الذاكرة، ويمكنك التحكم بها. |
| ⑤ ⟳ | **صفحة الامتثال (Compliance) تدقق في العين.** كل استدعاء أداة تقوم به العين مرتبط بسلسلة تجزئة **EvidenceSeal** المضادة للعبث؛ وتعرض الصفحة حالة **GEP** الحية لكل قاعدة (10 مبادئ) تم التحقق منها من تلك السلسلة ومن `EYE_Logs/`، وقابلة للتصدير كملف `audit_trail.json`. |

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

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

**محكوم بحكم التصميم.** كل إجراء تقوم به العين مرتبط بسلسلة تجزئة **EvidenceSeal** المضادة للعبث، وتتحقق صفحة **الامتثال** باستمرار من العين وفق [بروتوكول غسان السمان (GEP)](https://github.com/ghassan-elsman/crow-eye/blob/main/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 محدثة **في أقرب وقت ممكن** — الإصدار المُجمَّع هو المكان الذي تصل فيه الإصلاحات أولًا.
- 🔄 **تحديث تلقائي مدمج.** في التطبيق المُثبَّت، افتح **Settings ← Updates** **للتحقق من التحديثات وتثبيتها تلقائيًا** — دون إعادة تثبيت يدوية.
- 📦 **صفر إعداد.** لا حاجة لتثبيت 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** — مطلوبان لـ **تصور الخط الزمني**
- الحزم الرئيسية: PyQt5، python-registry، pywin32، pandas، streamlit، altair، olefile، windowsprefetch، sqlite3، colorama، setuptools

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

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

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

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

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

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

📂 الأدلة المدعومة

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

قوائم الانتقال و LNK يتم تحليلها بواسطة محلل LNK / قوائم الانتقال المخصص الخاص بـ Crow-Eye — وليس وحدة طرف ثالث.

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

تفاصيل لكل دليل

• قوائم الانتقال و LNK — تُحلل تلقائيًا من المواقع القياسية للنظام بواسطة المحلل المخصص الخاص بـ Crow-Eye (الوصول إلى الملفات، مسارات الأهداف، الطوابع الزمنية، والبيانات الوصفية).
• السجل — يحلل تلقائيًا خلايا النظام. للتحليل المخصص للسجل، انسخ ملفات الخلايا إلى 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، مستخرجًا سجل التنفيذ والبيانات الوصفية الجنائية (بما في ذلك الطوابع الزمنية لكل تشغيل).
• سجلات الأحداث — تحليل تلقائي لسجلات النظام/الأمان/التطبيقات في قاعدة بيانات لتحليل شامل.
• عمق السجل (0.13.0) — يقرأ المحلل ملف الخلية بالإضافة إلى السجل الحي، بحيث يصل إلى ما يرفضه winreg حتى للمسؤول (كل مفتاح فرعي Properties للجهاز، ومعه أوقات اتصال USB)، ويتنقل عبر مُخصص الخلية لاسترداد المفاتيح والقيم المحذوفة، ويقرأ أسماء الفئات وواصفات أمان المفاتيح. تسعة عشر مفتاحًا احتوت بيانات حقيقية ولم يقرأها أي شيء أصبحت الآن محللة — بما في ذلك StartupApproved الخاص بمستكشف الملفات، الذي يوضح ما إذا كان كل إدخال تشغيل تلقائي مسموحًا له بالفعل بالتشغيل.
• ShellBags — يكشف سجل الوصول إلى المجلدات وأنماط تنقل المستخدم.
• سلة المحذوفات — يحلل $RECYCLE.BIN لاسترداد أسماء الملفات المحذوفة والمسارات الأصلية وأوقات الحذف والأحجام (الأنظمة الحية وصور الأقراص).
• MFT — يحلل جدول الملفات الرئيسي للبيانات الوصفية للملفات والسمات والطوابع الزمنية ومعلومات الملفات المحذوفة (NTFS، ويندوز 7/10/11).
• دفتر يومية USN — يتتبع أحداث إنشاء/تعديل/حذف/إعادة تسمية الملفات مع الطوابع الزمنية وسجل الأسماء الكامل، لإعادة بناء الخط الزمني.
• SRUM — يعرض استخدام موارد التطبيق (أشرطة مدة للوقت الأمامي/الخلفي) ونشاط الشبكة لكل تطبيق.
• محلل جنائيات التخزين — عرض شجري كامل لكل قرص فعلي وأقسامه؛ أنواع أقسام مرمزة بالألوان (EFI، لينكس، الاسترداد، المخفي/المبادلة، …)؛ تحذيرات لأقراص USB القابلة للإقلاع، وجذور لينكس المخفية، وIntel Rapid Start؛ احتياطي فحص سحري للقطاعات الخام.

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

🦅 التقاط Crow-Claw

Crow-Claw هو محرك الالتقاط المتخصص في Crow-Eye لجمع الأدلة والحفاظ عليها من الأنظمة الحية أو الصور المُثبَّتة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يقرأ الخط الزمني قواعد بيانات الأدلة المحللة للقضية مباشرة وهو مستقل عن محرك الارتباط — لا تحتاج إلى بناء feathers أو تأليف أجنحة أو تشغيل خط أنابيب لاستخدامه. يطبق تجميعًا زمنيًا خفيفًا خاصًا به (ارتباط الطابع الزمني الدقيق ونافذة الوقت، التجميع حسب التطبيق أو المسار أو المستخدم) لربط الأحداث على الشبكة. الأدلة المُدخلة عبر استيراد الأدلة تظهر أيضًا على الخط الزمني كنوع أدلة 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 برنامج) · نطاق التاريخ والوقت مع إعدادات مسبقة سريعة (كل الوقت / اليوم الأول / اليوم الأخير / آخر ساعة من النشاط).

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

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

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

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

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

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

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

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

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

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

مرور دقة مركّز من دورة 0.11.0، تم التحقق منه من البداية إلى النهاية مقابل قضية ويندوز حقيقية بحوالي 700 ألف سجل ومبني فوق أعمال موثوقية سابقة. كل إصلاح أدناه مثبت بواسطة مجموعة اختبارات الانحدار pytest ويُتحقق منه بواسطة إطار تحقق شامل؛ وقد اختبر الأجنحة السبعة الافتراضية التي صدرت آنذاك — أحد عشر جناحًا تُصدر اليوم. أعداد التطابقات المذكورة أدناه قيست تحت قواعد ذلك الإصدار: 0.13.0 غيّر ما يُعد تطابقًا (يجب أن يمتد التطابق الآن عبر أكثر من feather واحد) وماذا تعني درجة الثقة، لذا تعامل معها كسجل لذلك المرور وليس كأرقام حالية.

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

• تم الإصلاح: كان محرك الهوية يكرر فقط الصف الأول من كل feather عند تفعيل فلتر الوقت (مقارنة طوابع زمنية واعية بالمنطقة مقابل ساذجة أثارت TypeError وأوقفت حلقة كل صف). قفزت السجلات المرئية من 3,558 → 745,615 في قضية التحقق.
• تم الإصلاح: كانت سجلات السجل تنهار كل حدث إلى موفر الحدث الخاص به كالهوية (جميع سجلات SecurityLogs البالغة 33,855 شاركت هوية واحدة). يعطي التعيين لكل دليل الآن الأولوية للكيانات الحقيقية لكل صف (User، ComputerName، NewProcessName، TargetUserName) قبل بيانات القناة/الموفر.
• تم الإصلاح: تعيين الحقول المدرك للدليل لم يعمل أبدًا لأن المحللات لا تختم عمود artifact على كل صف. يتراجع المحرك الآن إلى feather_metadata.artifact_type، بحيث تستخدم SecurityLogs / SystemLogs / ApplicationLogs أولوية الهوية الخاصة بدليلها.
• تم الإصلاح: أصبحت سلاسل العناصر النائبة هويات زائفة ('N/A'، 'Unknown'، '-'، GUIDs فارغة جمعت سجلات غير مرتبطة معًا). يرفض المُتحقق الآن أكثر من 30 متغيرًا نائبًا.
• النتيجة الصافية على نافذة كاملة واحدة، كما قيست آنذاك: كشف جناح إثبات التنفيذ عن 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، أشكال /device/harddiskvolumeN/... الخاصة بـ BAM/SRUM، …) أو مشبوه (Temp، Downloads، Public، AppData\Local\Temp، سلة المحذوفات، جذور قابلة للإزالة، مشاركات الشبكة). التطابق الممتد عبر كلا التصنيفين يرفع impersonation_alert (معدل ≈0.05%، كل منها مرشح حقيقي).محاسبة أدلة صادقة — سجل إسقاط لكل نافذة زمنية مع دلاء مسماة (no_identity_field, normalize_failure, below_threshold_skipped, …) بالإضافة إلى ملخص لكل خط معالجة (سجلات تمت رؤيتها، عالية/منخفضة تم إصدارها، بدون هوية، دلاء الإسقاط، وصلات الريشة الخالدة). كل سجل إما يصل إلى تطابق أو إلى دلو إسقاط مسمّى — "لا أدلة متبقية" يمكن التحقق منها من السجل. low_confidence_review_mode مفعّل افتراضيًا، لذا تتحول المجموعات الأقل من العتبة إلى تطابقات منخفضة الثقة بدلاً من الاختفاء بصمت.

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

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

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

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

محرك الارتباط جاهز للإنتاج ويُستخدم بنشاط في التحقيقات (Correlation Engine v1.7.0):

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

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

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

بنية النظام

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

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

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

• قواعد بيانات SQLite تحتوي على بيانات قطع أثرية جنائية مطبّعة — ريشة واحدة لكل نوع قطعة أثرية (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} ] }

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

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

**محرك فحص النافذة الزمنية** — الأفضل للتحليل القائم على الوقت والارتباط الزمني المنهجي. يفحص عبر الوقت بفواصل زمنية ثابتة، ويجمع السجلات من جميع الريشات لكل نافذة، ويطبق مطابقة الحقول الدلالية + التسجيل المرجح، ويمنع التكرار عبر تتبع MatchSet. **O(N log N)** (استعلامات الطابع الزمني المفهرسة)؛ معالجة دفعات (~٢٬٥٦٧ نافذة/ثانية).

**محرك الارتباط القائم على الهوية** — الأفضل لمجموعات البيانات الكبيرة (>١٬٠٠٠ سجل) وتتبع الهوية. يستخرج الهويات ويطبعها، ويجمع السجلات حسب الهوية، ويبني نقاط ارتكاز زمنية داخل كل مجموعة، ويصنف الأدلة كأولية/ثانوية/داعمة، ويبث لمجموعات كبيرة جدًا (>٥٬٠٠٠ نقطة ارتكاز) بذاكرة ثابتة. **O(N log N)**؛ أكثر من ٤٠ نمط حقل هوية لكل نوع.

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

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

**الغرض**: أتمتة سير عمل التحليل الكامل من إنشاء الريشات إلى توليد النتائج. يقرأ خط الأنابيب إعداده (نوع المحرك، الأجنحة، الريشات)، ويستدعي المحرك الصحيح عبر EngineSelector، وينفذ كل جناح، ويجمع المطابقات، ويحفظ النتائج (قاعدة البيانات + 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 need the actual content of chunk 18 to translate it. Please provide the Markdown text you want translated from English to Arabic.```python from correlation_engine.pipeline import PipelineExecutor executor = PipelineExecutor(pipeline_config) results = executor.execute()

بعد اكتمال الفحص، سيعرض التقرير النتائج التفصيلية بما في ذلك:

- **الملخص التنفيذي**: نظرة عامة عالية المستوى على النتائج.
- **النتائج التفصيلية**: قائمة شاملة بكل ثغرة تم اكتشافها، مصنفة حسب الخطورة.
- **التوصيات**: خطوات قابلة للتنفيذ لمعالجة الثغرات المكتشفة.
- **المراجع**: روابط لموارد إضافية وقواعد بيانات الثغرات المعروفة.

يمكن تصدير التقرير بتنسيقات متعددة مثل HTML أو PDF أو JSON لسهولة المشاركة والتكامل مع أدوات أخرى في سير العمل الأمني لديك.```
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

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

البدء مع محرك الارتباط

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

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

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

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

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

Eye هو مساعد الطب الشرعي بالذكاء الاصطناعي المدمج في Crow-Eye: محقق جنائي ماهر مدعوم بقاعدة معرفية حقيقية للقطع الأثرية في Windows. يمنحك واجهة بلغة طبيعية للاستعلام والربط وتوثيق كل شيء في قضية — Prefetch، MFT، السجل، سجلات الأحداث، AmCache، ShimCache، SRUM، والمزيد — مع الحفاظ على سجل قابل للتدقيق ومقاوم للعبث لما فعله بالضبط. يمكن لـ Eye العمل بالكامل على أجهزتك الخاصة (بما في ذلك معزول تمامًا عن الشبكة)، بما يتماشى مع موقف Crow-Eye الخصوصي "0 مللي ثانية من البيانات تُرسل خارج الجهاز". المعمارية الكاملة: 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. التبديل مقيد بنفس الخلفية، بحيث لا تُرسل الأدلة بصمت إلى مزود مختلف عن الذي اخترته.

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

تم بناء 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 (يتطلب التصدير موافقة بشرية).

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

بناء أجنحة الارتباط والخرائط الدلالية

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

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

الخريطة الدلالية تترجم قيمة تقنية خام إلى معنى قابل للقراءة البشرية (مثل 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. مهما كان ما يصل أخيرًا إلى النموذج فهو الحمولة الدقيقة التي تُختم لسلسلة الحضانة.

🗺️ الخريطة السردية — ذاكرة القضية الدائمة لـ 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 الإجابة في المحادثة و إبقاء الأدلة الداعمة في التقرير؛ يُشار إلى الفشل في تسجيل الأدلة كانتهاك للبروتوكول.
• ⚖️ حوكمة الارتباط. أي جناح أو خريطة يؤلفها 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 يأتي مع مجموعته الخاصة، بما في ذلك تشغيل شامل من البداية إلى النهاية ضد قضية حقيقية.

• منصة التحقق الشاملة. منصة شاملة تختبر جميع الأجنحة السبعة الافتراضية ضد كلا المحركين على قضية Windows حقيقية تضم حوالي 700 ألف سجل.
• سجل العيوب المنشور. الانحدارات في الدقة وتأثيرها المُقاس موثقة علنًا في RELEASE_NOTES.md — بما في ذلك الحالات التي غيّر فيها الإصلاح عدد السجلات المرئية بمراتب حجمية. معرفة ما كان خاطئًا، ومتى، جزء مما يجعل النتيجة قابلة للدفاع عنها.
• محاسبة أدلة قابلة للتحقق. كل سجل إما يقع في تطابق أو في دلو إسقاط مُسمّى، وسجل الإسقاط لكل نافذة يجعل "عدم وجود أدلة متبقية" شيئًا يمكنك التحقق منه من السجل بدلاً من تصديقه دون دليل.
• سجلات مقاومة للعبث. verify_chain() يعيد اجتياز سجل تدقيق Narrative Map وسلسلة ختم الأدلة لاكتشاف أي تعديل — بما في ذلك الحقول القابلة للقراءة البشرية.

🔬 منصة بحثية

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

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

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

• تحليل السجل يتطلب ملفات خلية سجل كاملة.
• بعض الأدلة الرقمية تتطلب معالجة خاصة بسبب آليات قفل الملفات في Windows (انظر السجل المخصص / الملفات المقفلة).
• تحليل LNK وقوائم الانتقال يتم بواسطة محلل مخصص خاص بـ Crow-Eye.

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

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

🎥 فيديو توضيحي:

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

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

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

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

📚 التوثيق

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

🤝 المساهمة

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

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

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

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

📄 الترخيص

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: A Windows Forensics Engine* (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/main/eye/docs/GEP_standard.md).

## 💖 الدعم

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

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

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