Crow-Eye — विंडोज़ फोरेंसिक इंजन

विंडोज़ के लिए एक फोरेंसिक टाइम मशीन।
Crow-Eye केवल पहचान नहीं करता — यह वास्तव में जो हुआ उसका पुनर्निर्माण समयरेखा पर करता है, अधिग्रहण से लेकर उस स्रोत रिकॉर्ड तक ट्रेसेबल निर्णय तक।

विषय-सूची

• अवलोकन
• ✨ मुख्य विशेषताएँ
• 👥 Crow-Eye किसके लिए है
• 🧭 एक नज़र में उपप्रणालियाँ
• 🏗️ आर्किटेक्चर
• 📥 डाउनलोड और इंस्टॉल
• 🚀 त्वरित प्रारंभ
• 📂 समर्थित आर्टिफैक्ट
• 🔧 विश्लेषण मोड
  • 📎 साक्ष्य आयात करें (थर्ड-पार्टी डेटा)
• 🧠 यूज़र व्यवहार विश्लेषण (UBA)
• 🧩 कोरिलेशन इंजन
• 👁️ Eye — फोरेंसिक AI सहायक
• 📖 Eye-Describe — बाइट-स्तरीय आर्टिफैक्ट ज्ञानकोश
• 🧪 गुणवत्ता और सत्यापन
• 🔬 शोध प्लेटफ़ॉर्म
• 🛠️ तकनीकी नोट्स
• 📸 स्क्रीनशॉट
• 🚧 रोडमैप
• 📚 दस्तावेज़ीकरण
• 🤝 योगदान
• 🌐 वेबसाइट और समुदाय
• 📄 लाइसेंस
• 📝 Crow-Eye का उद्धरण
• 💖 सहायता
• क्रेडिट्स

अवलोकन

Crow-Eye एक ओपन-सोर्स (GPL-3.0) विंडोज़ फोरेंसिक इंजन है जो अधिग्रहण, विश्लेषण, सत्यापन, खुफिया जानकारी और AI को एकीकृत करता है। अधिकांश सुरक्षा उपकरण पूछते हैं "क्या यह हानिकारक है?" और जो कुछ भी वैध दिखता है उसे साफ कर देते हैं। Crow-Eye एक अलग प्रश्न पूछता है: "क्या हुआ?" यह सभी गतिविधियों — संदिग्ध या नहीं — को सहसंबद्ध करता है और सिस्टम पर घटनाओं के वास्तविक अनुक्रम का पुनर्निर्माण करता है, ताकि जाँच की सच्चाई साक्ष्य से पुनर्निर्मित हो, न कि अलर्ट से अनुमानित।

यह पुनर्निर्माण-प्रथम डिज़ाइन ठीक वही है जो APT और राष्ट्र-राज्य खतरों का शिकार करने के लिए चाहिए: परिष्कृत विरोधी वैध टूल्स (powershell.exe, PsExec, certutil) के अंदर और क्रियाओं के अनुक्रम में रहते हैं — जो कुछ भी सामान्य दिखता है उसे साफ करने वाले उपकरणों के लिए अदृश्य। क्योंकि Crow-Eye कभी कुछ साफ नहीं करता और निष्पादन आर्टिफैक्ट्स (जो लॉग छेड़छाड़ और एंटी-फोरेंसिक से बचे रहते हैं) पर तर्क करता है, हमला छिप नहीं सकता। वही इंजन रोज़मर्रा के DFIR कार्य और उन गैर-विशेषज्ञों के लिए सुलभ रहता है जो बस जानना चाहते हैं कि कंप्यूटर पर क्या हुआ।

• 🕰️ पुनर्निर्माण करें, केवल पहचानें नहीं — वास्तव में जो हुआ उसकी समयरेखा का पुनर्निर्माण करें।
• 🖥️ क्रॉस-प्लेटफ़ॉर्म — विंडोज़ पर पूर्ण लाइव + ऑफ़लाइन विश्लेषण; लिनक्स पर ऑफ़लाइन विश्लेषण और फोरेंसिक-इमेज पार्सिंग (लाइव पार्सर केवल विंडोज़ के लिए हैं)।
• 🔒 डिज़ाइन से निजी — डिवाइस से बाहर 0 ms डेटा भेजा जाता है; Eye AI सहायक पूरी तरह air-gapped चल सकता है।
• 🧾 कोर्ट-ग्रेड — साक्ष्य क्रिप्टोग्राफ़िक रूप से सील होते हैं और हर कदम ऑडिटेबल है।
• 📦 वर्तमान संस्करण: 0.12.6 · कोरिलेशन इंजन: 1.7.0 · लाइसेंस: GPL-3.0।

✨ मुख्य विशेषताएँ

• पहचान से बेहतर पुनर्निर्माण। हर आर्टिफैक्ट को अलर्ट के ढेर के बजाय एक नेविगेट करने योग्य, प्रति-इकाई कहानी में सहसंबद्ध करता है।
• एकीकृत अंत-से-अंत — अधिग्रहण → कोरिलेशन → समयरेखा → व्यवहार विश्लेषण → AI → सील किया हुआ केस मेमोरी: एक पूर्ण पाइपलाइन जिसे कोई भी मौजूदा टूल कवर नहीं करता।
• आर्टिफैक्ट-गहरा, लॉग-उथला नहीं। Prefetch, Amcache, ShimCache, SRUM, MFT, USN, LNK/JumpLists और अन्य, लॉग साफ़ करने और "living-off-the-land" चालों से बच जाते हैं जो केवल-लॉग टूल्स को अंधा कर देती हैं।
• Eye AI सहायक — प्राकृतिक-भाषा फोरेंसिक जाँच, जिसमें ऑडिटेबल, छेड़छाड़-स्पष्ट चेन ऑफ कस्टडी होती है, और जिसे क्लाउड, निजी सर्वर, या पूरी तरह ऑफ़लाइन चलाया जा सकता है।
• यूज़र व्यवहार विश्लेषण (UBA) — कच्चे आर्टिफैक्ट्स को सरल अंग्रेज़ी, HR/परीक्षक-पठनीय गतिविधि कहानी में बदलता है।
• मुफ्त और ओपन-सोर्स (GPL-3.0) — कोई भी ऑडिट कर सकता है, सक्रिय शोध और दस्तावेज़ीकरण प्रयास के साथ।

👥 Crow-Eye किसके लिए है

Crow-Eye का उपयोग बहुत अलग वर्कफ़्लो में किया जाता है। प्रत्येक इंजन में एक अलग दरवाज़े से प्रवेश करता है:

कोई भी कलेक्टर काम करता है। Crow-Eye को अपने स्वयं के अधिग्रहण टूल की आवश्यकता नहीं है। ऑफ़लाइन इम्पोर्टर को Velociraptor, KAPE, किसी EDR संग्रह पैकेज, या किसी अन्य कलेक्टर द्वारा उत्पादित कच्चे आर्टिफैक्ट्स के फ़ोल्डर पर इंगित करें — यह समर्थित आर्टिफैक्ट्स को अनुक्रमित करता है और उन पर ऑफ़लाइन पार्सर चलाता है। अलग से, Plaso, Autopsy, Volatility या किसी अन्य टूल से आउटपुट को Import Evidence के माध्यम से 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

*साक्ष्य स्रोत → इन्जेस्ट → केस डेटाबेस → विश्लेषण → AI परत → रिपोर्ट*


**इसे कैसे पढ़ें:**

| Stage | What matters |
|---|---|
| ① → ② | **केस में चार स्वतंत्र प्रवेश द्वार।** आपको कभी भी Crow-Eye के अपने कलेक्टर की आवश्यकता नहीं है — Velociraptor, KAPE, या किसी EDR पैकेज का फ़ोल्डर Offline Importer से गुजरता है, और तृतीय-पक्ष CSV/JSON/SQLite Import Evidence से गुजरता है। |
| ② → ③ | सब कुछ एक स्थान पर केंद्रित होता है: **केस डेटाबेस**। पार्स किए गए आर्टिफ़ैक्ट `Target_Artifacts/` में जाते हैं; आयातित तृतीय-पक्ष साक्ष्य `Imported_Evidence/` में जाता है और स्वतः खोजा जाता है। |
| ③ → ④ | **तीनों विश्लेषण मार्ग एक-दूसरे से स्वतंत्र हैं।** Timeline और UBA केस डेटाबेस को सीधे पढ़ते हैं — दोनों में से किसी को भी correlation run की आवश्यकता नहीं है। Correlation Engine एक *अतिरिक्त* परत है, कोई पूर्वापेक्षा नहीं। |
| ③ → ④ | **Dynamic Linking, Timeline और UBA के साथ स्थित है** — केस डेटाबेस का चौथा, स्वतंत्र पाठक (इसका Timeline विज़ुअलाइज़ेशन से कोई संबंध नहीं है)। यह पहचान मैपिंग (SID → उपयोगकर्ता नाम, MAC → नेटवर्क, hash/GUID → ऐप) को प्रति-केस `Crow_Intelligence.db` में एकत्र करता है, फिर उस संदर्भ को गैर-विनाशकारी `ATTACH` + `LEFT JOIN` के माध्यम से **आर्टिफ़ैक्ट डेटा तालिकाओं में इनलाइन** ओवरले करता है। यह बदलता है कि रिकॉर्ड *कैसे पढ़े जाते हैं*, कभी साक्ष्य को नहीं। |
| ④ → ⑤ | Eye केस डेटाबेस को सीधे क्वेरी करता है और correlation परिणाम **माँग पर** प्राप्त कर सकता है। यह स्वयं कभी साक्ष्य को नहीं छूता — यह टूल कॉल उत्सर्जित करता है जिन्हें Crow-Eye निष्पादित करता है और लॉग करता है। |
| ⑤ → Report | **Living Report अकेले Eye द्वारा निर्मित होता है**, उसके `report_*` टूल्स के माध्यम से। Timeline और UBA विश्लेषण सतहें हैं — वे रिपोर्ट में नहीं लिखते। केस-स्तरीय निष्कर्षों को अभी भी [Search & Export](#-search--export) के माध्यम से अलग से निर्यात किया जा सकता है। |
| ⑤ ↔ | **Narrative Map द्विदिशात्मक है**: Eye उसमें लिखता है, आप उसमें लिखते हैं, और उसकी सामग्री हर बारी Eye के प्रॉम्प्ट में इंजेक्ट होती है। यह स्मृति है, और आप इसे नियंत्रित कर सकते हैं। |
| ⑤ ⟳ | **Compliance पृष्ठ Eye का ऑडिट करता है।** Eye द्वारा किया गया हर टूल कॉल **EvidenceSeal** हैश चेन से जुड़ा होता है; पृष्ठ उस चेन और `EYE_Logs/` से सत्यापित लाइव प्रति-नियम **GEP** स्थिति (10 सिद्धांत) प्रस्तुत करता है, जिसे `audit_trail.json` के रूप में निर्यात किया जा सकता है। |

**स्वतंत्र चरण।** Timeline और UBA केस आर्टिफ़ैक्ट डेटाबेस को **सीधे** पढ़ते हैं — किसी को भी correlation run की आवश्यकता नहीं होती, और Timeline, Correlation Engine पर निर्भर नहीं होता (वह अपना स्वयं का हल्का समय-आधारित समूहन लागू करता है)। Correlation एक अतिरिक्त विश्लेषण परत है जिसके परिणामों को Eye क्वेरी कर सकता है।

**डिज़ाइन से केवल-पठनीय।** पार्सिंग केस डेटाबेस में लिखती है; प्रत्येक निचला चरण (UBA, Timeline, correlation व्यूअर, Eye) उन डेटाबेस को **केवल-पठनीय** खोलते हैं। मूल साक्ष्य कभी संशोधित नहीं होता — [Dynamic Linking](#-analysis-modes) पहचान मैपिंग का प्रति-केस `Crow_Intelligence.db` बनाने के लिए केस डेटाबेस पढ़ता है और पंक्तियों को पुनः लिखने के बजाय गैर-विनाशकारी `ATTACH` + `LEFT JOIN` क्वेरीज़ के माध्यम से आर्टिफ़ैक्ट डेटा तालिकाओं को इनलाइन समृद्ध करता है।

**डिज़ाइन से शासित।** Eye द्वारा उठाया गया प्रत्येक कार्य छेड़छाड़-स्पष्ट **EvidenceSeal** हैश चेन से जुड़ा होता है, और **Compliance** पृष्ठ [Ghassan Elsman Protocol (GEP)](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/eye/docs/GEP_standard.md) के विरुद्ध Eye का निरंतर सत्यापन करता है — लाइव प्रति-नियम स्थिति, जिसे `EYE_Logs/audit_trail.json` में निर्यात किया जा सकता है।

## 📥 डाउनलोड और इंस्टॉल

> **अनुशंसित:** आधिकारिक वेबसाइट से पैकेज्ड Windows बिल्ड (**MSI इंस्टॉलर / EXE**) प्राप्त करें — कोई Python सेटअप नहीं, बिना किसी अतिरिक्त सेटअप के चलता है।

### ▶️ [Windows के लिए Crow-Eye डाउनलोड करें → crow-eye.com/download](https://crow-eye.com/download)

**इंस्टॉल किया गया MSI/EXE बिल्ड Crow-Eye चलाने का अनुशंसित तरीका है**, और यह अपडेट के लिए हमारी **सर्वोच्च प्राथमिकता** है:

- 🛡️ **सबसे तेज़ सुधार।** जब कोई समस्या पाई जाती है या बग रिपोर्ट होता है, तो हम **जितनी जल्दी हो सके** एक अद्यतन EXE जारी करते हैं — पैकेज्ड बिल्ड वह है जहाँ सुधार सबसे पहले पहुँचते हैं।
- 🔄 **अंतर्निहित ऑटो-अपडेट।** इंस्टॉल किए गए ऐप में, **Settings → Updates** खोलकर **अपडेट जाँचें और उन्हें स्वचालित रूप से इंस्टॉल करें** — कोई मैन्युअल पुनः इंस्टॉल नहीं।
- 📦 **शून्य सेटअप।** Python, Node, या डिपेंडेंसी इंस्टॉलेशन की आवश्यकता नहीं है।

> सोर्स से चलाना पसंद करते हैं? नीचे **[Quick Start](#-quick-start)** देखें। सोर्स-से बिल्ड योगदानकर्ताओं के लिए है और इसमें **ऑटो-अपडेटर शामिल नहीं है** — स्वचालित अपडेट के लिए MSI/EXE का उपयोग करें।

## 🚀 Quick Start

### विकल्प A — इंस्टॉल किया गया बिल्ड (अनुशंसित)
**MSI/EXE** को [crow-eye.com/download](https://crow-eye.com/download) से डाउनलोड करें, इंस्टॉल करें, और **Crow-Eye** को व्यवस्थापक के रूप में लॉन्च करें। एक केस बनाएं और विश्लेषण शुरू करें।

### विकल्प B — सोर्स से चलाएँ (डेवलपर्स)

> योगदानकर्ताओं और उन्नत उपयोगकर्ताओं के लिए। इस मार्ग में **ऑटो-अपडेटर शामिल नहीं है** — स्वचालित अपडेट के लिए 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 GB | 16 GB+ (लाखों रिकॉर्ड के MFT/USN सेट) |
| **डिस्क** | 5 GB खाली | खाली स्थान ≥ 2× पार्स किए जा रहे साक्ष्य के आकार का |
| **CPU** | 4 कोर | 8+ कोर |
| **OS** | Windows 10/11 (पूर्ण) · Linux (ऑफ़लाइन और इमेज विश्लेषण) | — |

> बहुत बड़े डेटासेट के लिए Correlation स्थिर मेमोरी में स्ट्रीम होता है, इसलिए RAM शायद ही कठिन सीमा होती है — डिस्क थ्रूपुट और खाली स्थान आमतौर पर होते हैं।

**लॉन्च करें** (व्यवस्थापक के रूप में चलाएँ ताकि Crow-Eye सिस्टम आर्टिफ़ैक्ट तक पहुँच सके):```bash
python "Crow Eye.py"

मुख्य इंटरफ़ेस खुलता है, आप एक केस बनाते हैं, और सभी विश्लेषण आउटपुट उस केस निर्देशिका के अंतर्गत व्यवस्थित होते हैं, बाद में समीक्षा और रिपोर्टिंग के लिए।

🖥️ क्रॉस-प्लेटफ़ॉर्म नोट: Linux पर, लाइव पार्सर स्वचालित रूप से अक्षम हो जाते हैं और Crow-Eye ऑफ़लाइन / फोरेंसिक-इमेज मोड में चलता है। पूर्ण लाइव अधिग्रहण केवल Windows पर उपलब्ध है।

📂 समर्थित आर्टिफैक्ट

Crow-Eye Windows निष्पादन, फ़ाइल-सिस्टम और उपयोगकर्ता-गतिविधि आर्टिफैक्ट के एक व्यापक सेट को पार्स करता है, लाइव सिस्टम और ऑफ़लाइन स्रोतों (एकत्रित फ़ोल्डर्स या फोरेंसिक इमेज) दोनों से।

Jump Lists & LNK को Crow-Eye के स्वयं के उद्देश्य-निर्मित LNK / Jump List पार्सर द्वारा पार्स किया जाता है — न कि किसी तृतीय-पक्ष मॉड्यूल द्वारा।

कस्टम रेजिस्ट्री / लॉक की गई फ़ाइलें: Windows ऑपरेशन के दौरान लाइव रेजिस्ट्री हाइव्स (NTUSER.DAT, SOFTWARE, SYSTEM) को लॉक कर देता है। किसी लाइव सिस्टम के कस्टम विश्लेषण के लिए, बाहरी मीडिया (WinPE/Live CD) से बूट करें, फोरेंसिक अधिग्रहण टूल का उपयोग करें, या डिस्क इमेज का विश्लेषण करें।

प्रति-आर्टिफैक्ट विवरण

• Jump Lists & LNK — Crow-Eye के अपने समर्पित पार्सर द्वारा मानक सिस्टम स्थानों से स्वचालित रूप से पार्स किया जाता है (फ़ाइल एक्सेस, लक्ष्य पथ, टाइमस्टैम्प और मेटाडेटा)।
• Registry — सिस्टम हाइव्स को स्वचालित रूप से पार्स करता है। कस्टम रेजिस्ट्री विश्लेषण के लिए, हाइव फ़ाइलों को CrowEye/Artifacts Collectors/Target Artifacts (या आपके केस के registry/ फ़ोल्डर) में कॉपी करें:
  • NTUSER.DAT from C:\Users\<Username>\NTUSER.DAT
  • SOFTWARE from C:\Windows\System32\config\SOFTWARE
  • SYSTEM from C:\Windows\System32\config\SYSTEM
  • Windows ऑपरेशन के दौरान इन्हें लॉक कर देता है — लाइव सिस्टम के लिए, बाहरी मीडिया (WinPE/Live CD) से बूट करें, फोरेंसिक अधिग्रहण टूल का उपयोग करें, या डिस्क इमेज का विश्लेषण करें।
• Prefetch — C:\Windows\Prefetch को पार्स करता है, निष्पादन इतिहास और फोरेंसिक मेटाडेटा (प्रति-रन टाइमस्टैम्प सहित) निकालता है।
• Event Logs — व्यापक विश्लेषण के लिए System/Security/Application लॉग्स का डेटाबेस में स्वचालित पार्सिंग।
• ShellBags — फ़ोल्डर एक्सेस इतिहास और उपयोगकर्ता नेविगेशन पैटर्न प्रकट करता है।
• Recycle Bin — हटाई गई फ़ाइलों के नाम, मूल पथ, हटाने के समय और आकारों को पुनर्प्राप्त करने के लिए $RECYCLE.BIN को पार्स करता है (लाइव सिस्टम और डिस्क इमेज)।
• MFT — फ़ाइल मेटाडेटा, विशेषताओं, टाइमस्टैम्प और हटाई गई फ़ाइल जानकारी के लिए Master File Table को पार्स करता है (NTFS, Windows 7/10/11)।
• USN Journal — टाइमलाइन पुनर्निर्माण के लिए टाइमस्टैम्प और पूर्ण नाम इतिहास के साथ फ़ाइल बनाने/संशोधित/हटाने/नाम बदलने की घटनाओं को ट्रैक करता है।
• SRUM — ऐप संसाधन उपयोग (अग्रभूमि/पृष्ठभूमि समय के लिए अवधि बार) और प्रति एप्लिकेशन नेटवर्क गतिविधि को विज़ुअलाइज़ करता है।
• Storage Forensics Analyzer — हर भौतिक डिस्क और उसके पार्टीशन का पूर्ण ट्री दृश्य; रंग-कोडित पार्टीशन प्रकार (EFI, Linux, Recovery, Hidden/swap, …); बूट करने योग्य USB, छिपी Linux रूट्स और Intel Rapid Start के लिए चेतावनियाँ; रॉ सेक्टर मैजिक-स्कैनिंग फ़ॉलबैक।

🔧 विश्लेषण मोड

🦅 Crow-Claw अधिग्रहण

Crow-Claw, Crow-Eye का विशेष अधिग्रहण इंजन है जो लाइव सिस्टम या माउंटेड इमेज से आर्टिफैक्ट्स को एकत्र और संरक्षित करता है।

• चयनात्मक संग्रह — विशिष्ट आर्टिफैक्ट श्रेणियाँ चुनें (Registry, Event Logs, File System) या सब कुछ एकत्र करें।
• डीप स्कैनिंग — फोरेंसिक निशान खोजने के लिए निर्देशिकाओं और उपनिर्देशिकाओं में चलता है।
• सुरक्षित संरक्षण — आर्टिफैक्ट एक संरचित केस निर्देशिका में पहुँचते हैं जो फोरेंसिक अखंडता बनाए रखती है।

🔍 ऑफ़लाइन विश्लेषण (ऑफ़लाइन इम्पोर्टर)

लक्ष्य से लाइव कनेक्शन के बिना किसी भी स्रोत से एकत्र किए गए आर्टिफैक्ट का विश्लेषण करें — तीन स्पष्ट ऑपरेशन:

• SCAN (खोज) — स्रोत को चलें और प्रत्येक समर्थित आर्टिफैक्ट को फ़ाइलनाम और एक्सटेंशन पैटर्न द्वारा अनुक्रमित करें (तेज़, केवल-पठनीय; इस चरण में कोई फ़ाइल सामग्री नहीं पढ़ी जाती और कोई मैजिक-बाइट जाँच नहीं की जाती)। कुछ भी स्थानांतरित नहीं होता।
• COLLECT (अधिग्रहण) — पहचानी गई फ़ाइलों को प्रकार के अनुसार व्यवस्थित करके केस के live_acquisition फ़ोल्डर में भौतिक रूप से कॉपी करें।
• PARSE (ग्रैन्युलर) — पहचाने गए आइटम की समीक्षा करें प्रति प्रकार (AMCACHE, EVTX, PREFETCH, …) और चयनित फ़ाइलों (या सभी) को फोरेंसिक डेटाबेस में पार्स करें।

पार्सिंग Crow-Eye के समर्पित ऑफ़लाइन पार्सर द्वारा संभाली जाती है — लाइव मोड के समान आर्टिफैक्ट लॉजिक, एकत्रित फ़ाइलों पर कार्य करता है: Prefetch, Registry, MFT, USN (साथ ही MFT/USN कोरिलेटर), AmCache, ShimCache, SRUM, Event Logs, LNK/JumpLists, और Recycle Bin।

📎 साक्ष्य आयात करें (तृतीय-पक्ष डेटा)

कच्चे आर्टिफैक्ट के अलावा, Crow-Eye तृतीय-पक्ष फोरेंसिक आउटपुट को सीधे केस में ले सकता है — Plaso, Autopsy, Volatility, या कोई भी कस्टम एक्सपोर्ट — और इसे Eye और Timeline के लिए उपयोग योग्य बना सकता है, बिना पहले correlation रन की आवश्यकता के।

चूँकि केस डेटाबेस मैनेजर केस ट्री के अंतर्गत किसी भी .db को स्वतः खोज लेता है, आयातित साक्ष्य तुरंत उपलब्ध हो जाता है:

• The Eye — मूल आर्टिफैक्ट के साथ प्राकृतिक भाषा में पूछताछ योग्य (आयात पर स्कीमा मेनिफेस्ट रीफ्रेश होता है)।
• The Interactive Timeline — imported आर्टिफैक्ट प्रकार के रूप में परोसा जाता है, जिसमें कार्यशील समय-विंडो फ़िल्टरिंग और समय सीमाएँ होती हैं।
• The Correlation Engine — मूल आर्टिफैक्ट के खिलाफ क्रॉस-टूल सहसंबंध के लिए Feather के रूप में उपयोग योग्य।

इम्पोर्टर केवल stdlib-आधारित है (sqlite3 / csv / json) और एक बैकग्राउंड वर्कर पर चलता है, इसलिए बड़े इम्पोर्ट UI को ब्लॉक नहीं करते।

⚡ लाइव विश्लेषण

चालू Windows सिस्टम से सीधे आर्टिफैक्ट का विश्लेषण करता है, वास्तविक समय फोरेंसिक विश्लेषण के लिए उनके मानक स्थानों से स्वतः निकालता है।

🗂️ केस प्रबंधन

हर जाँच एक केस है: एक स्व-निहित निर्देशिका जो आर्टिफैक्ट डेटाबेस और विश्लेषण आउटपुट को व्यवस्थित करती है। Crow-Eye हाल के केसों को ट्रैक करता है (पसंदीदा, टैग और स्थिति के साथ), खोलने पर केस को मान्य करता है, कॉन्फ़िगरेशन को परमाणु रूप से लिखता है (क्रैश-सुरक्षित), और तैयार सिमेंटिक मैपिंग के साथ केस कॉन्फ़िग आयात/निर्यात और टेम्पलेट्स का समर्थन करता है।

🕰️ इंटरैक्टिव टाइमलाइन विज़ुअलाइज़ेशन

एकीकृत अस्थायी ग्रिड पर आर्टिफैक्ट्स के बीच घटनाओं को सहसंबंधित करें, Heat Map, Week, और Day दृश्यों के साथ — एक सपाट सुपर-टाइमलाइन के बजाय एक पहचान-थ्रेडेड, अदालत-ट्रेसेबल कहानी।

टाइमलाइन केस के पार्स किए गए आर्टिफैक्ट डेटाबेस को सीधे पढ़ती है और Correlation Engine से स्वतंत्र है — इसका उपयोग करने के लिए आपको feathers बनाने, wings लिखने या पाइपलाइन चलाने की आवश्यकता नहीं है। यह घटनाओं को ग्रिड पर संबंधित करने के लिए अपना स्वयं का हल्का अस्थायी समूहन (सटीक-टाइमस्टैम्प और समय-विंडो सहसंबंध, एप्लिकेशन, पथ या उपयोगकर्ता द्वारा समूहन) लागू करता है। Import Evidence के माध्यम से लाया गया साक्ष्य भी टाइमलाइन पर imported आर्टिफैक्ट प्रकार के रूप में दिखाई देता है, जिसमें कार्यशील समय-विंडो फ़िल्टरिंग और समय सीमाएँ होती हैं।

🔎 खोज और निर्यात

केस डेटाबेस में पूर्ण-पाठ खोज, साथ ही CSV (स्प्रेडशीट), JSON (अन्य टूल के साथ एकीकरण), और विस्तृत HTML रिपोर्ट (खोज शब्द से जुड़े हर आर्टिफैक्ट को समेकित करने वाले पूर्ण डोजियर) में निर्यात।

🔗 डायनामिक लिंकिंग

कच्चे तकनीकी पहचानकर्ताओं — SIDs, MAC पतों, हैश — को मानव-पठनीय संदर्भ में तुरंत अनुवादित करें। डायनामिक लिंकिंग गैर-विनाशकारी SQL ATTACH क्वेरीज़ का उपयोग करके दृश्य को समृद्ध करती है, इसलिए मूल साक्ष्य कभी संशोधित नहीं होता, और यह बल्क IOC खतरा फ़ीड को इन्जेस्ट कर सकता है ताकि ज्ञात-खराब संकेतकों को इनलाइन फ़्लैग किया जा सके।

🧠 उपयोगकर्ता व्यवहार विश्लेषण (UBA)

कच्चे आर्टिफैक्ट को सरल अंग्रेजी गतिविधि कहानी में बदलें — एक प्रबंधक/HR-पठनीय विवरण कि एक उपयोगकर्ता और उनके एप्लिकेशन ने वास्तव में क्या किया, प्रत्येक कथन के साथ सटीक स्रोत साक्ष्य तक ट्रेसेबल।

उपयोगकर्ता व्यवहार विश्लेषण (UBA) आपके केस के Target_Artifacts/ फ़ोल्डर में पार्स किए गए आर्टिफैक्ट डेटाबेस को पढ़ता है (सख्ती से केवल-पठनीय) और उन्हें एक घोषणात्मक नियम सेट के माध्यम से प्लेबैक करके एक स्पष्ट, कालानुक्रमिक गतिविधि कहानी उत्पन्न करता है। इसे "User Behavior" टूलबार बटन या Ctrl+Shift+B से खोलें (एक केस लोड होना चाहिए)।

• 🧩 40 घोषणात्मक व्यवहार डिटेक्शन (uba/config/behavior_rules.json) — बिना कोड के ट्यूनेबल — प्रत्येक गंभीरता द्वारा वर्गीकृत: routine · notable · suspicious · critical।
• 🕵️ मायने रखने वाले व्यवहार का पता लगाता है: साइन-इन / साइन-आउट / अनलॉक, प्रोग्राम लॉन्च · निष्पादन · इंस्टॉल, फ़ाइल खोलना / हटाना / अनुमानित कॉपी, USB डिवाइस कनेक्शन, नेटवर्क-शेयर एक्सेस, दृढ़ता और ऑटोस्टार्ट, स्पष्ट-क्रेडेंशियल उपयोग (runas), खाता और समूह परिवर्तन, सेवा परिवर्तन, सिस्टम-घड़ी छेड़छाड़ (संदिग्ध), और इवेंट-लॉग सफ़ाई (गंभीर)।
• 🗺️ तीन दृश्य — एक गतिविधि कहानी फ़ीड, एक गतिविधि मानचित्र हीटमैप (दिन × घंटा), और एक "What we can see" ईमानदारी रिपोर्ट जो इस केस के लिए प्रत्येक डिटेक्शन को Working / Limited / No data / By design लेबल करती है।
• 🔗 हर गतिविधि साक्ष्य-समर्थित है। किसी भी आइटम पर क्लिक करके सटीक समर्थन रिकॉर्ड (database : table : rowid) खोलें — बिना स्रोत के कुछ भी दावा नहीं किया जाता।
• 👤 ईमानदार आरोपण। अभिनेता User / Application / System में हल होते हैं (या खाली छोड़ दिए जाते हैं) — UBA कभी अनुमान नहीं लगाता कि किसने क्या किया।

डिटेक्शन कवरेज

40 डिटेक्शन चार गंभीरता वर्गों और पार्स किए गए आर्टिफैक्ट सेट की पूरी चौड़ाई में फैले हैं:

फ़िल्टर: मुफ़्त-पाठ खोज · उपयोगकर्ता/अभिनेता (जिसमें "Unattributed" और एक साइन-इन-सत्र टॉगल शामिल है) · व्यवहार वर्ग (उपयोगकर्ता / एप्लिकेशन / सिस्टम) · गंभीरता · एप्लिकेशन (200+ प्रोग्रामों में खोजने योग्य मल्टी-सेलेक्ट) · त्वरित प्रीसेट के साथ डेटटाइम रेंज (सभी समय / पहला दिन / अंतिम दिन / गतिविधि का अंतिम घंटा)।

डेटा स्रोत: Security, System और Application Event Logs · USN Journal · MFT · UserAssist · BAM · Prefetch · ShimCache · AmCache · MUICache · ShellBags · LNK / JumpLists · Recycle Bin · SRUM (एप्लिकेशन, नेटवर्क, कनेक्टिविटी) · रेजिस्ट्री हाइव्स।

फोरेंसिक गारंटी

• केवल-पठनीय। स्रोत डेटाबेस केवल-पठनीय खोले जाते हैं; विश्लेषण कभी साक्ष्य को नहीं छूता।
• पूर्ण प्रोवेनेंस। हर घटना database → table → rowid रखती है और मांग पर वास्तविक स्रोत पंक्तियाँ खोलती है।
• आरोपण कभी अनुमान नहीं लगाता। एक घटना किसी उपयोगकर्ता, एप्लिकेशन, सिस्टम — या खाली को आरोपित की जाती है। इंटरैक्टिव लॉगऑन सत्र केवल संदर्भ लेबल के रूप में उपयोग किए जाते हैं ("<user> के सत्र के दौरान"), कभी किसी क्रिया को आरोपित करने के लिए नहीं।
• ईमानदार शब्दावली। वाक्यांश जानबूझकर बातचीत (UserAssist, SRUM अग्रभूमि) को उन आर्टिफैक्ट्स से अलग करता है जिन्हें एक एप्लिकेशन भी उत्पन्न कर सकता है (ShellBags, LNK, JumpLists), कार्ड पर स्पष्ट चेतावनियों के साथ।
• अनुपस्थिति कही जाती है, निहित नहीं। What we can see रिपोर्ट इस विशिष्ट केस के लिए हर डिटेक्शन को लेबल करती है, इसलिए लापता डेटा को कभी चुपचाप "कुछ नहीं हुआ" के रूप में नहीं पढ़ा जाता।

UBA नियम-संचालित व्यवहार सहसंबंध और वर्गीकरण है, सांख्यिकीय/ML विसंगति स्कोरिंग नहीं — हर निष्कर्ष एक स्पष्ट, ऑडिटेबल नियम से मैप होता है। पूर्ण डिटेक्शन कैटलॉग के लिए RELEASE_NOTES.md देखें।

🧩 Correlation Engine

Correlation Engine v1.7.0 — पुनर्निर्माण कोर। रिलीज़ इतिहास के लिए RELEASE_NOTES.md देखें।

Crow-Eye Correlation Engine एक प्रोडक्शन-ग्रेड फोरेंसिक सहसंबंध प्रणाली है। यह किसी भी स्रोत से Windows आर्टिफैक्ट को ग्रहण करता है, उन्हें सामान्यीकृत करता है, और उन अस्थायी और पहचान संबंधों को सतह पर लाता है जो पृथक रिकॉर्ड को एक सुसंगत कथा में बदल देते हैं कि सिस्टम पर क्या हुआ, कब, और कौन शामिल था। यह सबसे सामान्य जाँच प्रश्नों के लिए अंतर्निहित सहसंबंध नियमों (Wings) के साथ आउट-ऑफ-द-बॉक्स काम करता है, विश्लेषकों को बिना कोड छुए कस्टम नियम लिखने देता है, और अर्थ को लेखकीय नियमों और अन्वेषक पर छोड़ देता है — कभी ब्लैक-बॉक्स स्कोर पर नहीं।

🎥 उपयोगकर्ता मार्गदर्शिका

यूनिवर्सल डेटा इम्पोर्ट: Correlation Engine किसी भी फोरेंसिक टूल के आउटपुट को CSV, JSON, या SQLite प्रारूप में ले सकता है और उसे Feather डेटाबेस में बदल सकता है। इसका मतलब है कि आप तृतीय-पक्ष टूल (Plaso, Autopsy, Volatility, आदि) के डेटा को Crow-Eye के मूल आर्टिफैक्ट के साथ सहसंबंधित कर सकते हैं, जिससे आपके सभी फोरेंसिक डेटा स्रोतों पर एक एकीकृत सहसंबंध विश्लेषण बनता है।

🎯 सटीकता और साक्ष्य-पूर्णता

एक केंद्रित सटीकता पास, जो पहले की विश्वसनीयता कार्य के ऊपर, एक वास्तविक ~700K-रिकॉर्ड Windows केस के खिलाफ एंड-टू-एंड मान्य किया गया है। नीचे दिया गया हर सुधार pytest रिग्रेशन सूट द्वारा लॉक किया गया है और एक समग्र सत्यापन हार्नेस द्वारा सत्यापित किया गया है जो दोनों इंजनों के खिलाफ सभी 7 डिफ़ॉल्ट wings चलाता है।

पहचान इंजन सभी साक्ष्य कैप्चर करता है

• फिक्स्ड: पहचान इंजन प्रत्येक feather की केवल पहली पंक्ति पर पुनरावृत्ति कर रहा था जब कोई समय फ़िल्टर सक्रिय था (timezone-aware बनाम naive datetime तुलना ने TypeError फेंका और प्रति-पंक्ति लूप को बाधित किया)। सत्यापन केस पर देखे गए रिकॉर्ड 3,558 → 745,615 तक बढ़ गए।
• फिक्स्ड: लॉग रिकॉर्ड हर घटना को उसके event PROVIDER के रूप में पहचान में बदल देते थे (सभी 33,855 SecurityLogs रिकॉर्ड एक ही पहचान साझा करते थे)। अब प्रति-आर्टिफैक्ट मैपिंग चैनल/प्रोवाइडर मेटाडेटा से पहले वास्तविक प्रति-पंक्ति संस्थाओं (User, ComputerName, NewProcessName, TargetUserName) को प्राथमिकता देती है।
• फिक्स्ड: आर्टिफैक्ट-जागरूक फ़ील्ड मैपिंग कभी नहीं चली क्योंकि पार्सर प्रत्येक पंक्ति पर artifact कॉलम स्टैम्प नहीं करते। इंजन अब feather_metadata.artifact_type पर वापस जाता है, इसलिए SecurityLogs / SystemLogs / ApplicationLogs अपनी आर्टिफैक्ट-विशिष्ट पहचान प्राथमिकता का उपयोग करते हैं।
• फिक्स्ड: प्लेसहोल्डर स्ट्रिंग्स झूठी पहचान बन गईं ('N/A', 'Unknown', '-', nil-GUIDs ने असंबंधित रिकॉर्ड एक साथ बंडल किए)। वैलिडेटर अब 30+ प्लेसहोल्डर वेरिएंट को अस्वीकार करता है।
• एक पूर्ण-रेंज विंडो पर शुद्ध परिणाम: Execution Proof wing पहचान इंजन में 2,856 क्रॉस-फ़ेदर (High) मैच और समय इंजन में 643 क्रॉस-फ़ेदर मैच सतह पर लाता है, अन्य 6 wings में प्रति wing 24–118 क्रॉस-फ़ेदर मैच के साथ।

अब नहीं "सब कुछ Low है — कुछ गड़बड़ है"

• फिक्स्ड: सिंगल-फ़ेदर मैच High टैग किए गए थे। feather_count == 1 वाले मैच अब confidence_category="Low - single feather" प्राप्त करते हैं, इसलिए High दृश्य वास्तविक क्रॉस-फ़ेदर सहसंबंध पर केंद्रित होता है।
• फिक्स्ड: एक पथ-जागरूक समग्र कुंजी एक ही पहचान को feathers के पार विभाजित कर रही थी (प्रत्येक feather पथ अलग तरह से संग्रहीत करता है, इसलिए chrome के 10+ कुंजियाँ थीं और कभी सहसंबंधित नहीं हुई)। कुंजी अब केवल-नाम है — क्रॉस-फ़ेदर सहसंबंध फिर से काम करता है।

पथ वर्गीकरण के माध्यम से प्रतिरूपण पहचान — मैच बनने के बाद, इंजन हर रिकॉर्ड के पथ को TRUSTED (Program Files, System32, WinSxS, BAM/SRUM /device/harddiskvolumeN/... फ़ॉर्म, …) या SUSPICIOUS (Temp, Downloads, Public, AppData\Local\Temp, Recycle Bin, हटाने योग्य रूट्स, नेटवर्क शेयर) के रूप में वर्गीकृत करता है। दोनों वर्गीकरणों में फैला एक मैच impersonation_alert उठाता है (≈0.05% दर, प्रत्येक एक वास्तविक उम्मीदवार)।

ईमानदार साक्ष्य लेखांकन — नामित बकेट (no_identity_field, normalize_failure, below_threshold_skipped, …) के साथ एक प्रति-विंडो ड्रॉप लेजर, साथ ही एक प्रति-पाइपलाइन सारांश (देखे गए रिकॉर्ड, उत्सर्जित high/low, no-identity, ड्रॉप बकेट, timeless-feather जॉइन)। हर रिकॉर्ड या तो मैच में या नामित ड्रॉप बकेट में जाता है — "कोई साक्ष्य नहीं बचा" लॉग से सत्यापन योग्य है। low_confidence_review_mode डिफ़ॉल्ट रूप से ON है, इसलिए थ्रेशोल्ड-से-नीचे समूह चुपचाप गायब होने के बजाय Low-कॉन्फिडेंस मैच बन जाते हैं।

टाइमलेस-फ़ेदर पहचान संवर्धन — बिना प्रति-पंक्ति टाइमस्टैम्प वाले feathers (AutoStartPrograms, MUICache, SystemServices, TypedPaths) अब हर पंक्ति पर नकली जनरेशन-टाइम स्टैम्प नहीं लगाते; इसके बजाय, समयबद्ध मैच बनने के बाद, इंजन प्रत्येक टाइमलेस feather से मेल खाने वाले रिकॉर्ड को पहचान के आधार पर पूरक साक्ष्य के रूप में जोड़ता है।

समेकित पहचान रजिस्ट्री — config/standard_fields/identities.json उन सभी कॉलमों के लिए एकल स्रोत है जिनसे इंजन और Eye को परामर्श लेना चाहिए: 98 श्रेणियाँ, 1,146 कॉलम पर्यायवाची (app/process, file, hash, user, host/device, network, registry, service/task, event, email, browser, cloud, Windows internals, certificate, container, OS objects)। नया कॉलम पर्यायवाची जोड़ना एक JSON संपादन है, कोड परिवर्तन नहीं।

सिमेंटिक-मैपिंग गलत-सकारात्मक फिक्स — मल्टी-इंडिकेटर गेटिंग अब वास्तव में लागू होती है (data-exfiltration-pattern के लिए ≥2 संकेतक आवश्यक हैं); असंभव AND नियम (4625 AND 4624) को OR के रूप में फिर से लिखा गया; wiper/remote-tool नियम हर Prefetch प्रविष्टि पर फायर करने के बजाय वास्तविक regex का उपयोग करते हैं; बेसलाइन-गतिविधि नियम high/critical से info/low तक अवनत किए गए (wing का भारित स्कोरिंग वास्तविक खतरों को बढ़ाता है)।

✅ उत्पादन स्थिति

Correlation Engine प्रोडक्शन-रेडी है और सक्रिय रूप से जाँचों में उपयोग किया जाता है (Correlation Engine v1.7.0):- ✅ Time-Window Scanning Engine — प्रोडक्शन-रेडी, समय-आधारित विश्लेषण के लिए अनुशंसित (O(N log N))

• ✅ Identity-Based Engine — प्रोडक्शन-रेडी, पहचान ट्रैकिंग के लिए अनुशंसित (O(N log N))
• ✅ Feather Builder / FeatherWriter — किसी भी टूल से CSV/JSON/SQLite आयात करता है; ट्रांज़ैक्शनल बैचिंग + स्कीमा मेटाडेटा
• ✅ Wings System & Pipeline Orchestration — सहसंबंध नियम बनाएं/प्रबंधित करें और वर्कफ़्लोज़ को स्वचालित करें
• ✅ Identity Grouping — इंजन, व्यूअर्स और सिमेंटिक चरण में एकीकृत
• ✅ Standard Fields Registry — केंद्रीकृत फ़ील्ड-समानार्थी सत्य स्रोत
• ✅ Multi-timestamp Fan-Out — हर JSON-सूची टाइमस्टैम्प सहसंबद्ध
• 🔄 Parallel Correlation — नींव मौजूद; आगे प्रोफाइलिंग + प्रोसेस-पूल प्रेषण
• 🔄 Semantic Mapping & Correlation Scoring — सक्रिय संवर्द्धन

मुख्य विशेषताएँ

• 🔄 Dual-Engine Architecture: Time-Window Scanning (O(N log N)) और Identity-Based (O(N log N)) सहसंबंध रणनीतियों के बीच चुनें।
• 📊 Multi-Artifact Support: Prefetch, ShimCache, AmCache, Event Logs, LNK files, Jumplists, MFT, USN, SRUM, Registry, RecycleBin और अधिक को सहसंबंधित करें।
• 🔌 Universal Import: किसी भी फॉरेंसिक टूल से CSV/JSON/SQLite आउटपुट आयात करें और Feather डेटाबेस में परिवर्तित करें।
• 🎯 Smart Identity Grouping: Chrome.exe/chrome.dll/Chrome.EXE जैसे वेरिएंट एक ही बकेट में समाहित हो जाते हैं; संस्करण और आर्किटेक्चरल क्वालीफायर अलग रहते हैं।
• 🕒 Tolerant Timestamps: FILETIME, ISO 8601, Unix epoch (s/ms/μs), YYYYMMDD, US स्लैश और एनोटेटेड स्ट्रिंग्स सभी पहली बार में सही ढंग से पार्स हो जाते हैं।
• 📈 Multi-Timestamp Fan-Out: JSON टाइमस्टैम्प सूचियाँ (Prefetch run_times) विस्तारित की जाती हैं ताकि हर निष्पादन को अपनी स्वयं की सहसंबंध घटना मिले।
• 🧰 One Source of Truth: फ़ील्ड समानार्थक शब्द config/standard_fields/*.json में; प्रति-तालिका मेटाडेटा correlation_engine/config/feather_schemas.json में; कोड नहीं, JSON संपादित करके विस्तार करें।
• ⚡ Streaming + Thread-Safe: O(1)-मेमोरी query_time_range_iter; लॉक-संरक्षित feather कैश; समानांतर सहसंबंध के लिए तैयार।
• 🔍 Flexible Rules: कॉन्फ़िगर करने योग्य पैरामीटर के साथ कस्टम सहसंबंध नियम (Wings) परिभाषित करें।
• 📋 Honest Diagnostics: प्रति-विंडो सांख्यिकी पंक्ति (records_in / no_identity / parse_cache_hits / below_threshold / matches_emitted) ताकि आपको हमेशा पता रहे कि साक्ष्य ड्रॉप हुआ या नहीं।
• 🧪 Locked-In Quality: एक pytest रिग्रेशन सूट जो टाइमस्टैम्प पार्सिंग, पहचान सामान्यीकरण, फैन-आउट, राइटर कॉन्ट्रैक्ट, Eye लेखन (राइट-साइड GEP गवर्नेंस) और स्टैंडर्ड-फ़ील्ड्स रजिस्ट्री को कवर करता है।

सिस्टम आर्किटेक्चर

सहसंबंध इंजन में चार मुख्य घटक होते हैं:

1. 🗄️ Feathers (डेटा सामान्यीकरण)

उद्देश्य: कच्चे फॉरेंसिक आर्टिफैक्ट्स को एक मानकीकृत, क्वेरी योग्य प्रारूप में बदलना।

• सामान्यीकृत फॉरेंसिक आर्टिफैक्ट डेटा वाले SQLite डेटाबेस — प्रत्येक आर्टिफैक्ट प्रकार (Prefetch, ShimCache, Event Logs, …) के लिए एक feather, कुशल क्वेरी के लिए मानकीकृत स्कीमा और मेटाडेटा के साथ।
• एक सार्वभौमिक प्रारूप जो किसी भी फॉरेंसिक टूल से डेटा स्वीकार करता है।``` 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. 🎯 Wings (सहसंबंध नियम)

उद्देश्य: यह परिभाषित करना कि कौन-से आर्टिफैक्ट्स को सहसंबंधित किया जाए और कैसे।

• JSON/YAML नियम जो एक समय विंडो, न्यूनतम मिलान, एंकर प्राथमिकता, और सहसंबंधित करने के लिए feathers (वज़न सहित) निर्दिष्ट करते हैं — केसों में पुन: उपयोग योग्य। प्रत्येक Wing लेखन योग्य और सीलबंद होता है (यह रिकॉर्ड करता है कि इसे किसने लिखा, क्यों, और कौन-सा साक्ष्य इसके लिए प्रेरणा था)।```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. ⚙️ इंजन (सहसंबंध रणनीतियाँ)

**उद्देश्य**: आर्टिफैक्ट्स के बीच संबंध खोजने के लिए सहसंबंध तर्क निष्पादित करना। संरचनात्मक लिंक **पहले** आते हैं; एक टियर-भारित स्कोर *व्याख्या/रैंकिंग* के रूप में ऊपर जोड़ा जाता है, न कि मिलान के आधार के रूप में।

**टाइम-विंडो स्कैनिंग इंजन** — समय-आधारित विश्लेषण और व्यवस्थित अस्थायी सहसंबंध के लिए सर्वोत्तम। निश्चित अंतरालों में समय के माध्यम से स्कैन करता है, प्रति विंडो सभी फेदर से रिकॉर्ड एकत्र करता है, सिमेंटिक फील्ड मैचिंग + भारित स्कोरिंग लागू करता है, और MatchSet ट्रैकिंग के माध्यम से डुप्लिकेट रोकता है। **O(N log N)** (अनुक्रमित टाइमस्टैम्प क्वेरीज़); बैच प्रोसेसिंग (~2,567 विंडो/सेकंड)।

**आइडेंटिटी-आधारित सहसंबंध इंजन** — बड़े डेटासेट (>1,000 रिकॉर्ड) और आइडेंटिटी ट्रैकिंग के लिए सर्वोत्तम। आइडेंटिटीज़ निकालता और सामान्यीकृत करता है, रिकॉर्ड को आइडेंटिटी द्वारा समूहित करता है, प्रत्येक क्लस्टर के भीतर अस्थायी एंकर बनाता है, साक्ष्य को प्राथमिक/द्वितीयक/सहायक के रूप में वर्गीकृत करता है, और बहुत बड़े सेट (>5,000 एंकर) के लिए स्थिर मेमोरी पर स्ट्रीम करता है। **O(N log N)**; प्रति प्रकार 40+ आइडेंटिटी फील्ड पैटर्न।

**इंजन चयन:** समय-आधारित विश्लेषण के लिए टाइम-विंडो इंजन का उपयोग करें और आइडेंटिटी ट्रैकिंग के लिए आइडेंटिटी-आधारित इंजन का — दोनों प्रोडक्शन-रेडी हैं और अनुक्रमित क्वेरीज़ के साथ बड़े डेटासेट के लिए अनुकूलित हैं।

#### 4. 🔄 पाइपलाइन (वर्कफ़्लो ऑर्केस्ट्रेशन)

**उद्देश्य**: फेदर निर्माण से परिणाम निर्माण तक पूर्ण विश्लेषण वर्कफ़्लो को स्वचालित करना। एक पाइपलाइन अपना कॉन्फ़िगरेशन (इंजन प्रकार, विंग्स, फेदर) पढ़ती है, EngineSelector के माध्यम से सही इंजन को इंस्टैंशिएट करती है, प्रत्येक विंग को निष्पादित करती है, मैच एकत्र करती है, परिणाम सहेजती है (DB + JSON), और उन्हें GUI में फ़िल्टरिंग और विज़ुअलाइज़ेशन के साथ प्रदर्शित करती है।```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"]
}

[No content provided to translate.]```python from correlation_engine.pipeline import PipelineExecutor executor = PipelineExecutor(pipeline_config) results = executor.execute()

[सामग्री अनुपलब्ध है / Content not provided]```
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. Feather बनाएँ: अपने फोरेंसिक आर्टिफैक्ट आयात करें (Prefetch, ShimCache, …)।
3. Wing बनाएँ: अपनी जांच के लिए कोरिलेशन नियम परिभाषित करें।
4. Pipeline बनाएँ: कॉन्फ़िगर करें कि कौन-से wings और feathers उपयोग करने हैं।
5. निष्पादित करें: pipeline चलाएँ और सहसंबद्ध परिणाम देखें।
6. विश्लेषण करें: परिणाम व्यूअर (Results Viewer) का उपयोग करके अस्थायी संबंधों का पता लगाएं।

📚 कोरिलेशन इंजन प्रलेखन

• Correlation Engine Overview — आर्किटेक्चर आरेखों के साथ सिस्टम अवलोकन
• Engine Documentation — दोहरे-इंजन आर्किटेक्चर, इंजन चयन, प्रदर्शन अनुकूलन
• Architecture — घटक एकीकरण और डेटा प्रवाह
• Feather Documentation — डेटा-सामान्यीकरण प्रणाली
• Wings Documentation — कोरिलेशन नियम
• Pipeline Documentation — कार्यप्रवाह व्यवस्थापन
• Adding an Artifact — इंजन में नया पार्सर जोड़ने का कार्यप्रवाह
• Standard Fields Registry — कैननिकल कॉलम-नाम समानार्थी, जो दोनों इंजनों और Eye द्वारा लोड होते हैं
• Contribution Guide — इंजन में योगदान कैसे करें
• त्वरित लिंक: Engine Selection · Troubleshooting · Performance Optimization

👁️ Eye — फोरेंसिक AI सहायक

एक शक्तिशाली सहायक, प्रतिस्थापन नहीं। Eye जांचकर्ता की परिकल्पनाओं को स्वचालित करता है और सत्यापित करता है — यह कभी भी आपकी ओर से निर्णय नहीं लेता।

Eye, Crow-Eye का अंतर्निर्मित फोरेंसिक AI सहायक है: एक कुशल फोरेंसिक जांचकर्ता, जो Windows आर्टिफैक्ट्स के वास्तविक ज्ञानकोष द्वारा समर्थित है। यह आपको एक प्राकृतिक-भाषा इंटरफ़ेस देता है, जिससे आप केस की हर चीज़ (Prefetch, MFT, Registry, Event Logs, AmCache, ShimCache, SRUM, और अन्य) को क्वेरी, सहसंबद्ध और प्रलेखित कर सकते हैं — साथ ही यह इसका एक ऑडिटेबल (auditable), छेड़छाड़-स्पष्ट (tamper-evident) रिकॉर्ड रखता है कि उसने वास्तव में क्या किया। Eye पूरी तरह आपके अपने हार्डवेयर पर चल सकता है (जिसमें पूर्णतः एयर-गैप्ड भी शामिल है), Crow-Eye की "0 ms डेटा डिवाइस से बाहर नहीं भेजा जाता" गोपनीयता नीति के अनुरूप। पूर्ण आर्किटेक्चर: eye/README.md।

Eye बातचीत के सवालों ("दिखाएँ कि C:\Temp से 22:00 के बाद क्या निष्पादित हुआ") को वास्तविक फोरेंसिक कार्य में बदल देता है: यह एक दृष्टिकोण की योजना बनाता है, प्रासंगिक आर्टिफैक्ट ज्ञान प्राप्त करता है, आपके केस डेटाबेस में SQL और क्रॉस-आर्टिफैक्ट खोज चलाता है, और एक सत्यापित उत्तर संश्लेषित करता है। हर उत्तर एक साथ दो स्थानों पर उत्पन्न होता है — आपके लिए एक चैट उत्तर, और Living Report कार्यक्षेत्र में लिखा गया एक संरचित ब्लॉक, ताकि जांच आगे बढ़ने पर दस्तावेज़ स्वयं निर्मित होता रहे।

घासान एल्समैन प्रोटोकॉल (GEP)

Eye जो कुछ भी करता है वह घासान एल्समैन प्रोटोकॉल (GEP) पर आधारित है — एक विक्रेता-तटस्थ, टूल-अज्ञेयवादी मानक कि डिजिटल फोरेंसिक्स में किसी भी AI का उपयोग कैसे किया जाना चाहिए। यह 10 सिद्धांत हैं जिन्हें एक अनुरूप प्रणाली को बनाए रखना चाहिए ताकि AI-सहायता प्राप्त निष्कर्ष सत्य, स्रोत रिकॉर्ड से अनुरेखणीय, और एक ऑडिटेबल, छेड़छाड़-स्पष्ट श्रृंखला द्वारा समर्थित बने रहें, जिसमें मानव जांचकर्ता नियंत्रण में हो:

Crow-Eye का Eye, GEP का संदर्भ कार्यान्वयन है; इसे बनाए रखने वाले इन-प्रोडक्ट व्यवहार संचालन नियम (Operating Rules) कहलाते हैं। 📜 मानक पढ़ें: eye/docs/GEP_standard.md।

परिनियोजन मोड

Eye आपके खतरे-मॉडल के अनुसार तीन परिनियोजन मोड में ढल जाता है:

CLI-एजेंट मोड में, Crow-Eye किसी मौजूदा AI टर्मिनल/कमांड-लाइन एजेंट को मॉडल के रूप में चलाता है — क्लाउड API या स्थानीय ऑफ़लाइन सर्वर के बजाय — ताकि आप उसी एजेंट के साथ जांच कर सकें जिसे आप पहले से उपयोग करते हैं।

जांच लूप:

1. केस खोलें या बनाएँ — Eye स्वयं को उस केस के आर्टिफैक्ट डेटाबेस और इतिहास तक सीमित कर लेता है।
2. प्राकृतिक भाषा में प्रश्न पूछें, या एक-क्लिक व्यापक ट्राइएज शुरू करें।
3. Eye अपनी pipeline चलाता है — इरादा पहचानें → ज्ञान प्राप्त करें → उपकरण निष्पादित करें → संश्लेषित करें।
4. आपको दोहरा आउटपुट मिलता है — एक सीधा चैट उत्तर और Living Report में एक नया ब्लॉक।
5. गेटेड क्रियाओं को स्वीकृत करें — निर्यात और अन्य महत्वपूर्ण चरण आपके हस्ताक्षर की प्रतीक्षा करते हैं।

आप switch_model टूल से रनटाइम पर मॉडल बदल सकते हैं। स्विचिंग उसी बैकएंड तक सीमित है, इसलिए साक्ष्य कभी भी आपके चुने गए प्रदाता के अलावा किसी अन्य प्रदाता को चुपचाप नहीं भेजा जाता।

LLM विचार-प्रक्रिया का अनुरेखण

Eye इस प्रकार बनाया गया है कि आप देख सकते हैं — और बाद में सिद्ध कर सकते हैं — कि यह कैसे किसी निष्कर्ष पर पहुँचा। जब Eye कार्य करता है, तो यह वास्तविक समय में UI पर संरचित ThinkingStep अपडेट स्ट्रीम करता है; प्रत्येक अपडेट में step_id, type, मानव-पठनीय label, status (active → done, या error), और वैकल्पिक tool/params/detail होता है।

विशिष्ट क्वेरी thinking → rag → thinking → tool_call → synthesis के रूप में सामने आती है, और हर केस में डिस्क-आधारित ट्रेस आर्टिफैक्ट रहते हैं जिन्हें आप बाद में निरीक्षित कर सकते हैं:

टूल निष्पादन

Eye टूल-संचालित है: मॉडल कभी सीधे साक्ष्य को नहीं छूता। यह टूल कॉल उत्सर्जित करता है, और Eye उन्हें केस के डेटाबेस पर निष्पादित करता है और परिणाम लौटाता है — इसलिए हर क्रिया स्पष्ट, लॉग की गई और पुनरुत्पादनीय (reproducible) होती है। टूल configs/llm_config.json में परिभाषित होते हैं और eye/services/context_manager.py के माध्यम से भेजे जाते हैं।

जांच उपकरण — साक्ष्य पढ़ें और विश्लेषण करें:

रिपोर्टिंग उपकरण Living Report कार्यक्षेत्र का निर्माण करते हैं: 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। टूल कॉल को सक्रिय बैकएंड जो भी अपेक्षा करता है, उसमें अनुवादित किया जाता है — क्लाउड API और स्थानीय सर्वरों के लिए नेटिव function-calling, या CLI एजेंटों के लिए एक XML <tool_call> रैपर।

कोरिलेशन Wings और सिमेंटिक मैपिंग का निर्माण

Eye केवल Correlation Engine को क्वेरी नहीं करता — यह उसे विस्तारित करने में मदद कर सकता है। जब Eye कोई आवर्ती क्रॉस-आर्टिफैक्ट पैटर्न देखता है, तो वह नए Wings (कोरिलेशन नियम) और Semantic Mappings (तकनीकी-से-मानव अनुवाद) प्रस्तावित कर सकता है। यह शासित लेखन है: Eye प्रस्ताव करता है, विश्लेषक सहेजे गए आर्टिफैक्ट की समीक्षा करता है, और हर बदलाव उचित और साक्ष्य-समर्थित होता है।

एक Wing, किसी दावे को सिद्ध करने के लिए समय-विंडो और न्यूनतम-मिलान सीमा के भीतर feathers को एक साथ जोड़ता है:

A Semantic Mapping किसी कच्चे तकनीकी मान को मानव-पठनीय अर्थ में अनुवाद करता है (जैसे EventID 4624 → "Successful Logon")। यह दो रूपों में आता है: एक सरल mapping (एकल मान/regex → सिमेंटिक मान) या एक बहु-शर्त rule (शर्तें AND/OR से जुड़ी)। दोनों category, severity, confidence, और scope का समर्थन करते हैं, और दोनों को reason + related_evidence की आवश्यकता होती है।

शासन — लेखन-पक्ष नियम जो GEP को बनाए रखते हैं:

• Reason-Required (GEP-9 + GEP-2 का समर्थन करता है): हर निर्माण और संपादन में एक फोरेंसिक reason शामिल होना चाहिए।
• Evidence-Link (GEP-2 का समर्थन करता है): हर निर्माण को कम से कम एक database:table:rowid संदर्भ उद्धृत करना चाहिए।
• Eye-स्टैम्प्ड / अन्य पर केवल-पठनीय (GEP-7 + GEP-9 का समर्थन करता है): Eye अपने लेखकत्व + reason + संपादन इतिहास पर मुहर लगाता है और केवल उसी को संपादित कर सकता है जिसे Eye ने लिखा है — अंतर्निर्मित और मानव-लेखित नियम केवल-पठनीय रहते हैं।

स्व-उपचार संदर्भ

लंबी जांच किसी मॉडल की संदर्भ-विंडो से बाहर हो सकती है — विशेष रूप से छोटे ऑफ़लाइन मॉडल। क्रैश होने या साक्ष्य को चुपचाप हटाने के बजाय, Eye प्रत्येक मॉडल कॉल से पहले अपने स्वयं के संदर्भ को स्वतः-संपीड़ित करता है (अपने संरक्षित जनरेशन पथ के अंदर, पूरी तरह ऑडिट किया हुआ)।

प्रत्येक कॉल से पहले, Eye पूर्ण पेलोड को मापता है और उत्तर के लिए स्थान आरक्षित करता है (10% विंडो का, न्यूनतम 512 टोकन, कभी भी आधे से अधिक नहीं)। यदि यह फिर भी फिट नहीं होता, तो यह दो क्रमबद्ध पासों में स्व-उपचार करता है, संरक्षित संदेशों (पिन किए गए, स्वतः-पहचाने गए साक्ष्य, या एक टूल परिणाम) को कभी नहीं छूता:

1. संक्षेपण पास (एक बार) — गैर-संरक्षित इतिहास एक सारांश में संक्षेपित हो जाता है, SUMMARIZED लॉग किया जाता है।
2. हटाने का पास — सबसे पुराना गैर-संरक्षित संदेश एक-एक करके हटाया जाता है जब तक कि वह फिट न हो जाए, TRUNCATED लॉग किया जाता है।

यदि अपरिवर्तनीय साक्ष्य कोर (पिन किए गए + टूल परिणाम + वर्तमान प्रश्न) फिर भी अतिप्रवाहित होता है, तो Eye साक्ष्य को छाँटने के बजाय आगे बढ़ने से मना कर देता है (REFUSED_OVERFLOW) और आपसे क्वेरी को सीमित करने या analyze_large_dataset उपयोग करने के लिए कहता है। मॉडल के पास अंततः जो भी जाता है, वह सटीक पेलोड है जो अभिरक्षा श्रृंखला के लिए सील किया जाता है।

🗺️ Narrative Map — Eye की स्थायी केस मेमोरी

Eye प्रत्येक टर्न के बीच स्थितिहीन होता है — इसलिए Narrative Map वह जगह है जहाँ "हम क्या जानते हैं और क्या निष्कर्ष निकाला है" एक केस के लिए रहता है। यह Eye की स्थायी, ऑडिटेबल, छेड़छाड़-स्पष्ट कार्यशील मेमोरी है, और इसकी सामग्री हर टर्न पर Eye के प्रॉम्प्ट में इंजेक्ट होती है (नक्शा वस्तुतः मेमोरी ही है)।

• 🧭 Verdict → Narrative → Evidence. एक सख्त पदानुक्रम: एक केस Verdict, उसके नीचे Narratives (दावे, प्रत्येक की एक अवस्था — proven · open · negative · needs · absolute), और उनके नीचे आर्टिफैक्ट-समर्थित Evidence।
• 🪟 इसकी अपनी विंडो। Eye चैट विंडो में "Narrative Map" बटन से खुलती है, ताकि आप चैट, लिविंग रिपोर्ट और केस मेमोरी को एक साथ देख सकें; बदलाव होने पर यह लाइव-रीफ्रेश होती है।
• ↔️ द्विदिशात्मक — एक मेमोरी जिसे आप नियंत्रित करते हैं। Eye के संपादन और आपके अपने नोट्स दोनों एक ही GEP-मान्य कमिट से होकर गुजरते हैं और एक हैश-चेन ऑडिट लॉग (narrative_map_audit.jsonl) में सील होते हैं। आप इसके दावों और साक्ष्य को जोड़, संपादित और हटा सकते हैं, जिससे सीधे आकार मिलता है कि Eye केस को कैसे समझता और व्याख्या करता है।
• 🚫 असमर्थित का कभी दावा नहीं करता। एक Eye narrative जांच के दौरान बिना साक्ष्य के open रह सकती है, लेकिन वह बिना साक्ष्य के कभी proven नहीं हो सकती; एक थीम जिसे Eye ने जाँचा लेकिन खाली पाया, स्वतः negative में बदल जाती है — क्योंकि प्रलेखित अनुपस्थिति स्वयं एक निष्कर्ष है।

अनुपालन कैसे कार्य करता है

अनुपालन कोई ऊपर जोड़ी गई सुविधा नहीं है — इसे pipeline में लागू किया जाता है।

• 🔗 अभिरक्षा श्रृंखला (Evidence Seal)। Eye LLM को जो भी पेलोड भेजता है वह सील होता है: सटीक बाइट्स का SHA-256, टोकन गणना, मॉडल + उसकी संदर्भ सीमा, और प्रत्येक साक्ष्य पंक्ति की उत्पत्ति (database:table:rowid, साथ ही MFT रिकॉर्ड के लिए गणना किए गए ऑफसेट)। सीलें append-only और हैश-चेन होती हैं और <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 द्वारा लिखित किसी भी Wing या mapping में एक फोरेंसिक reason और related_evidence शामिल होना चाहिए; Eye के बाहर लिखे गए नियम केवल-पठनीय हैं और चुपचाप पुनः लिखे नहीं जा सकते।
• 🔐 गोपनीयता और एयर-गैपिंग। ऑफ़लाइन मोड में Eye शून्य आउटबाउंड कॉल करता है; क्लाउड API कुंजियाँ OS-नेटिव keychains में रहती हैं — कभी हार्डकोड नहीं, कभी लॉग में नहीं लिखी जातीं।

📖 पूर्ण Eye आर्किटेक्चर: eye/README.md।

📖 Eye-Describe — बाइट-स्तरीय आर्टिफैक्ट ज्ञानकोष

🔗 Eye-Describe एक्सप्लोर करें → crow-eye.com/eye-describe

ऐतिहासिक रूप से, जांचकर्ता अपने फोरेंसिक टूल पर भरोसा करने के जाल में फँसते थे, बिना यह समझे कि अंतर्निहित आर्टिफैक्ट कैसे व्यवहार करते हैं या टूल ने उन्हें कैसे पार्स किया। आज का जोखिम केवल "टूल" को "AI" से बदलना है। एक AI किसी रिकॉर्ड को पूर्ण तकनीकी सटीकता के साथ पार्स कर सकता है और फिर भी उसे गलत संदर्भ में रख सकता है — जिससे साक्ष्य का पूरा अर्थ बदल जाता है।

Eye-Describe इसलिए मौजूद है ताकि न तो मानव और न ही मॉडल को अनुमान लगाना पड़े। यह Windows आर्टिफैक्ट्स की कच्ची बाइनरी संरचनाओं के लिए एक इंटरैक्टिव, बाइट-स्तरीय संदर्भ है, और यह एक साथ दो भूमिकाएँ निभाता है:

AI परत को प्रलेखित आर्टिफैक्ट व्यवहार से जोड़कर, Crow-Eye आपसे किसी मॉडल पर भरोसा करने के लिए नहीं कह रहा — यह मॉडल को कच्चे फोरेंसिक्स का सम्मान करने के लिए बाध्य कर रहा है।

टूल विश्वास को AI विश्वास से मत बदलिए। डेटा को समझिए।

🧪 गुणवत्ता और सत्यापन

Read more