Crow-Eye — Windows 포렌식 엔진

Windows를 위한 포렌식 타임머신.
Crow-Eye는 단순히 탐지만 하지 않습니다 — 수집부터 출처 기록까지 추적 가능한 판정에 이르기까지, 타임라인에서 실제로 일어난 일을 재구성합니다.

목차

• 개요
• ✨ 주요 기능
• 👥 Crow-Eye를 위한 사용자
• 🧭 하위 시스템 한눈에 보기
• 🏗️ 아키텍처
• 📥 다운로드 및 설치
• 🚀 빠른 시작
• 📂 지원 아티팩트
• 🔧 분석 모드
  • 📎 증거 가져오기(타사 데이터)
• 🧠 사용자 행동 분석(UBA)
• 🧩 상관관계 엔진
• 👁️ Eye — 포렌식 AI 어시스턴트
• 📖 Eye-Describe — 바이트 수준 아티팩트 지식 베이스
• 🧪 품질 및 검증
• 🔬 연구 플랫폼
• 🛠️ 기술 참고 사항
• 📸 스크린샷
• 🚧 로드맵
• 📚 문서
• 🤝 기여
• 🌐 웹사이트 및 커뮤니티
• 📄 라이선스
• 📝 Crow-Eye 인용
• 💖 지원
• 크레딧

개요

Crow-Eye는 수집, 분석, 검증, 인텔리전스, AI를 통합하는 오픈소스(GPL-3.0) Windows 포렌식 엔진입니다. 대부분의 보안 도구는 *"이것이 악성인가?"*라고 묻고 정상으로 보이는 것은 모두 걸러냅니다. Crow-Eye는 다른 질문을 던집니다: "무슨 일이 있었는가?" 의심스러운 활동이든 아니든 모든 활동을 상호 연관시키고 시스템에서 실제 발생한 사건의 순서를 재구성하므로, 조사의 진실은 알림에서 추측되는 것이 아니라 증거로부터 재구축됩니다.

이러한 재구성 우선 설계는 APT 및 국가 주도 위협을 사냥하는 데 정확히 필요한 것입니다: 정교한 공격자는 합법적인 도구(powershell.exe, PsExec, certutil)와 행동의 순서 속에 숨어 있습니다 — 정상으로 보이는 것을 걸러내는 도구에는 보이지 않습니다. Crow-Eye는 어떤 것도 걸러내지 않고 로그 변조와 안티-포렌식에서도 살아남는 실행 아티팩트를 기반으로 추론하므로, 공격은 숨을 수 없습니다. 동일한 엔진은 일상적인 DFIR 작업과 컴퓨터에서 무슨 일이 있었는지 알고 싶은 비전문가에게도 쉽게 접근할 수 있습니다.

• 🕰️ 탐지만 하지 말고 재구성하라 — 실제로 발생한 일의 타임라인을 재구축합니다.
• 🖥️ 크로스 플랫폼 — Windows에서 전체 라이브 + 오프라인 분석; Linux에서 오프라인 분석 및 포렌식 이미지 파싱(라이브 파서는 Windows 전용).
• 🔒 설계상 프라이버시 보호 — 데이터가 기기 외부로 전송되는 시간 0ms; Eye AI 어시스턴트는 완전히 에어갭 환경에서 실행 가능.
• 🧾 법정 등급 — 증거는 암호화로 봉인되며 모든 단계를 감사할 수 있습니다.
• 📦 현재 버전: 0.13.0 · 상관관계 엔진: 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 또는 기타 도구의 출력은 증거 가져오기를 통해 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

*증거 소스 → 수집 → 사례 데이터베이스 → 분석 → AI 계층 → 보고서*


**읽는 방법:**

| 단계 | 핵심 내용 |
|---|---|
| ① → ② | **사례로 들어가는 4개의 독립적인 경로.** Crow-Eye 자체 수집기를 사용할 필요가 없습니다. Velociraptor, KAPE 또는 EDR 패키지의 폴더는 오프라인 가져오기(Offline Importer)를 통해 처리되고, 타사 CSV/JSON/SQLite는 증거 가져오기(Import Evidence)를 통해 처리됩니다. |
| ② → ③ | 모든 것이 한곳, 즉 **사례 데이터베이스**로 수렴됩니다. 파싱된 아티팩트는 `Target_Artifacts/`에 저장되고, 가져온 타사 증거는 `Imported_Evidence/`에 저장되어 자동으로 검색됩니다. |
| ③ → ④ | **세 가지 분석 경로는 서로 독립적입니다.** 타임라인과 UBA는 사례 데이터베이스를 직접 읽습니다. 둘 다 상관관계 실행이 필요하지 않습니다. 상관관계 엔진은 전제 조건이 아닌 *추가* 계층입니다. |
| ③ → ④ | **동적 연결(Dynamic Linking)은 타임라인 및 UBA와 나란히 위치** — 사례 데이터베이스의 네 번째 독립적 읽기 도구입니다(타임라인 시각화와는 무관합니다). ID 매핑(SID → 사용자 이름, MAC → 네트워크, 해시/GUID → 앱)을 사례별 `Crow_Intelligence.db`로 수집한 다음, 비파괴적 `ATTACH` + `LEFT JOIN`을 통해 해당 컨텍스트를 **아티팩트 데이터 테이블에 인라인으로** 오버레이합니다. 레코드가 *읽히는 방식*을 변경할 뿐, 증거 자체는 절대 변경하지 않습니다. |
| ④ → ⑤ | Eye는 사례 데이터베이스를 직접 쿼리하며 상관관계 결과를 **요청 시** 가져올 수 있습니다. 증거 자체에는 절대 접근하지 않습니다. Crow-Eye가 실행하고 기록하는 도구 호출을 생성할 뿐입니다. |
| ⑤ → 보고서 | **라이브 보고서(Living Report)는 Eye만이** `report_*` 도구를 통해 작성합니다. 타임라인과 UBA는 분석 표면일 뿐이며 보고서에 기록하지 않습니다. 사례 수준의 결과는 [검색 및 내보내기](#-search--export)를 통해 별도로 내보낼 수 있습니다. |
| ⑤ ↔ | **내러티브 맵(Narrative Map)은 양방향입니다.** Eye가 기록하고, 사용자가 기록하며, 그 내용은 매 턴마다 Eye의 프롬프트에 주입됩니다. 그것은 메모리이며, 사용자가 명령할 수 있습니다. |
| ⑤ ⟳ | **규정 준수(Compliance) 페이지는 Eye를 감사합니다.** Eye가 수행하는 모든 도구 호출은 **EvidenceSeal** 해시 체인에 고정되며, 페이지는 해당 체인과 `EYE_Logs/`에서 검증된 규칙별 **GEP** 상태(10가지 원칙)를 실시간으로 렌더링하고 `audit_trail.json`으로 내보낼 수 있습니다. |

**독립적인 단계.** 타임라인과 UBA는 사례 아티팩트 데이터베이스를 **직접** 읽습니다. 둘 다 상관관계 실행이 필요하지 않으며, 타임라인은 상관관계 엔진에 의존하지 않습니다(자체적인 경량 시간 그룹화를 적용합니다). 상관관계는 Eye가 쿼리할 수 있는 결과를 제공하는 추가 분석 계층입니다.

**설계상 읽기 전용.** 파싱은 사례 데이터베이스에 기록하며, 모든 하위 단계(UBA, 타임라인, 상관관계 뷰어, Eye)는 해당 데이터베이스를 **읽기 전용**으로 엽니다. 원본 증거는 절대 수정되지 않습니다. [동적 연결](#-analysis-modes)은 사례 데이터베이스를 읽어 ID 매핑의 사례별 `Crow_Intelligence.db`를 구축하고, 행을 다시 쓰는 대신 비파괴적 `ATTACH` + `LEFT JOIN` 쿼리를 통해 아티팩트 데이터 테이블을 인라인으로 강화합니다.

**설계상 관리됨.** Eye가 수행하는 모든 작업은 변조 방지 **EvidenceSeal** 해시 체인에 고정되며, **규정 준수(Compliance)** 페이지는 [Ghassan Elsman 프로토콜(GEP)](https://github.com/ghassan-elsman/crow-eye/blob/main/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를 출시합니다. 패키지된 빌드에 수정 사항이 가장 먼저 적용됩니다.
- 🔄 **내장 자동 업데이트.** 설치된 앱에서 **설정 → 업데이트**를 열어 **업데이트를 확인하고 자동으로 설치**하세요. 수동 재설치가 필요 없습니다.
- 📦 **설정 불필요.** Python, Node 또는 종속성 설치가 필요 없습니다.

> 소스에서 실행하는 것을 선호하시나요? 아래 **[빠른 시작](#-quick-start)** 을 참조하세요. 소스 빌드는 기여자를 위한 것이며 **자동 업데이트 프로그램이 포함되어 있지 않습니다.** 자동 업데이트를 원하면 MSI/EXE를 사용하세요.

## 🚀 빠른 시작

### 옵션 A — 설치 빌드(권장)
[crow-eye.com/download](https://crow-eye.com/download)에서 **MSI/EXE**를 다운로드하고, 설치한 후 **Crow-Eye**를 관리자 권한으로 실행하세요. 사례를 만들고 분석을 시작합니다.

### 옵션 B — 소스에서 실행(개발자용)

> 기여자 및 고급 사용자용입니다. 이 경로에는 **자동 업데이트 프로그램이 포함되어 있지 않습니다.** 자동 업데이트를 원하면 MSI/EXE를 사용하세요.

**요구 사항**(첫 실행 시 자동 설치):
- Python 3.12.4
- **Node.js 및 npm** — **타임라인 시각화**에 필요
- 주요 패키지: 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(오프라인 및 이미지 분석) | — |

> 상관관계는 매우 큰 데이터 세트에 대해 일정한 메모리로 스트리밍되므로 RAM이 하드 제한이 되는 경우는 드뭅니다. 디스크 처리량과 여유 공간이 일반적으로 제한 요소입니다.

**실행**(시스템 아티팩트에 접근할 수 있도록 관리자 권한으로 실행):```bash
python "Crow Eye.py"

주요 인터페이스가 열리면 케이스를 생성하고, 모든 분석 출력은 추후 검토와 보고를 위해 해당 케이스 디렉터리 아래에 정리됩니다.

🖥️ 크로스 플랫폼 참고: Linux에서는 라이브 파서가 자동으로 비활성화되며 Crow-Eye는 오프라인 / 포렌식 이미지 모드로 실행됩니다. 전체 라이브 수집은 Windows 전용입니다.

📂 지원 아티팩트

Crow-Eye는 라이브 시스템과 오프라인 소스(수집된 폴더 또는 포렌식 이미지) 모두에서 광범위한 Windows 실행, 파일 시스템 및 사용자 활동 아티팩트를 파싱합니다.

점프 목록 및 LNK는 타사 모듈이 아닌 Crow-Eye 자체의 전용 LNK / 점프 목록 파서에 의해 파싱됩니다.

사용자 지정 레지스트리 / 잠긴 파일: Windows는 작동 중에 라이브 레지스트리 하이브(NTUSER.DAT, SOFTWARE, SYSTEM)를 잠급니다. 라이브 시스템의 사용자 지정 분석을 위해서는 외부 미디어(WinPE/Live CD)에서 부팅하거나, 포렌식 수집 도구를 사용하거나, 디스크 이미지를 분석하십시오.

아티팩트별 세부 정보

• 점프 목록 및 LNK — Crow-Eye 자체 전용 파서에 의해 표준 시스템 위치에서 자동으로 파싱됩니다(파일 액세스, 대상 경로, 타임스탬프 및 메타데이터).
• 레지스트리 — 시스템 하이브를 자동으로 파싱합니다. 사용자 지정 레지스트리 분석의 경우 하이브 파일을 CrowEye/Artifacts Collectors/Target Artifacts(또는 케이스의 registry/ 폴더)에 복사하십시오:
  • C:\Users\<Username>\NTUSER.DAT의 NTUSER.DAT
  • C:\Windows\System32\config\SOFTWARE의 SOFTWARE
  • C:\Windows\System32\config\SYSTEM의 SYSTEM
  • Windows는 작동 중에 이를 잠급니다 — 라이브 시스템의 경우 외부 미디어(WinPE/Live CD)에서 부팅하거나, 포렌식 수집 도구를 사용하거나, 디스크 이미지를 분석하십시오.
• 프리페치(Prefetch) — C:\Windows\Prefetch를 파싱하여 실행 기록과 포렌식 메타데이터(실행별 타임스탬프 포함)를 추출합니다.
• 이벤트 로그 — 포괄적인 분석을 위해 시스템/보안/애플리케이션 로그를 데이터베이스로 자동 파싱합니다.
• 레지스트리 깊이(0.13.0) — 파서는 라이브 레지스트리뿐만 아니라 하이브 파일도 읽으므로 winreg가 관리자에게도 거부하는 항목(모든 장치 Properties 하위 키 및 이를 통한 USB 연결 시간)에 도달하고, 하이브의 할당자를 탐색하여 삭제된 키와 값을 복구하며, 클래스 이름과 키 보안 설명자를 읽습니다. 실제 데이터를 보유하고 있었지만 아무것도 읽지 않던 19개의 키가 이제 파싱됩니다 — 각 자동 시작 항목이 실제로 실행이 허용되는지 여부를 알려주는 Explorer의 를 포함합니다.

🔧 분석 모드

🦅 Crow-Claw 수집

Crow-Claw는 라이브 시스템 또는 마운트된 이미지에서 아티팩트를 수집하고 보존하기 위한 Crow-Eye의 특수 수집 엔진입니다.

• 선택적 수집 — 특정 아티팩트 범주(레지스트리, 이벤트 로그, 파일 시스템)를 선택하거나 모든 것을 수집합니다.
• 심층 스캔 — 포렌식 흔적을 찾기 위해 디렉터리와 하위 디렉터리를 탐색합니다.
• 안전한 보존 — 아티팩트는 포렌식 무결성을 유지하는 구조화된 케이스 디렉터리에 저장됩니다.

🔍 오프라인 분석(오프라인 가져오기)

대상에 대한 라이브 연결 없이 모든 소스에서 수집된 아티팩트를 분석합니다 — 세 가지 명확한 작업:

• SCAN(검색) — 소스를 탐색하고 파일 이름 및 확장자 패턴으로 지원되는 모든 아티팩트를 인덱싱합니다(빠르고 읽기 전용; 이 단계에서는 파일 내용을 읽지 않으며 매직 바이트 검사도 수행하지 않음). 아무것도 이동되지 않습니다.
• COLLECT(수집) — 식별된 파일을 유형별로 구성하여 케이스의 live_acquisition 폴더에 물리적으로 복사합니다.
• PARSE(세부 파싱) — 유형별(AMCACHE, EVTX, PREFETCH, …)로 식별된 항목을 검토하고 선택한 파일(또는 전체)을 포렌식 데이터베이스로 파싱합니다.

파싱은 Crow-Eye의 전용 오프라인 파서에 의해 처리됩니다 — 라이브 모드와 동일한 아티팩트 로직으로 수집된 파일에 대해 작동합니다: 프리페치, 레지스트리, MFT, USN(MFT/USN 상관기 포함), AmCache, ShimCache, SRUM, 이벤트 로그, LNK/점프 목록 및 휴지통.

📎 증거 가져오기(타사 데이터)

원시 아티팩트 외에도 Crow-Eye는 타사 포렌식 출력을 케이스에 직접 가져올 수 있습니다 — Plaso, Autopsy, Volatility 또는 모든 사용자 지정 내보내기 — 상관 실행을 먼저 요구하지 않고 Eye와 타임라인에서 사용할 수 있게 만듭니다.

케이스 데이터베이스 관리자가 케이스 트리 아래의 모든 .db를 자동으로 검색하므로 가져온 증거는 즉시 다음에서 사용할 수 있습니다:

• The Eye — 기본 아티팩트와 함께 자연어로 쿼리 가능(가져오기 시 스키마 매니페스트가 새로 고쳐짐).
• 대화형 타임라인 — 작동하는 시간 창 필터링과 시간 범위를 갖춘 imported 아티팩트 유형으로 제공.
• 상관 엔진 — 기본 아티팩트에 대한 교차 도구 상관을 위한 Feather로 사용 가능.

가져오기는 표준 라이브러리 전용(sqlite3 / csv / json)이며 백그라운드 작업자에서 실행되므로 대규모 가져오기가 UI를 차단하지 않습니다.

⚡ 라이브 분석

실행 중인 Windows 시스템에서 직접 아티팩트를 분석하여 표준 위치에서 자동으로 추출하여 실시간 포렌식 분석을 수행합니다.

🗂️ 케이스 관리

모든 조사는 케이스입니다: 아티팩트 데이터베이스와 분석 출력을 구성하는 독립적인 디렉터리입니다. Crow-Eye는 최근 케이스를 추적하고(즐겨찾기, 태그 및 상태 포함), 열 때 케이스를 검증하며, 구성을 원자적으로 작성하고(충돌 안전), 케이스 구성 가져오기/내보내기와 사전 준비된 의미 매핑이 포함된 템플릿을 지원합니다.

🕰️ 대화형 타임라인 시각화

통합 시간 그리드에서 아티팩트 간 이벤트를 상호 연관시키며, 히트 맵, 주, 일 보기를 제공합니다 — 평면적인 슈퍼 타임라인이 아닌 ID 스레드로 연결되고 법정에서 추적 가능한 스토리입니다.

타임라인은 케이스의 파싱된 아티팩트 데이터베이스를 직접 읽으며 상관 엔진과 독립적입니다 — feather를 구축하거나, wing을 작성하거나, 파이프라인을 실행할 필요 없이 사용할 수 있습니다. 그리드에서 이벤트를 연결하기 위해 자체적인 경량 시간 그룹화(정확한 타임스탬프 및 시간 창 상관, 애플리케이션/경로/사용자별 그룹화)를 적용합니다. **증거 가져오기**를 통해 가져온 증거도 작동하는 시간 창 필터링과 시간 범위를 갖춘 imported 아티팩트 유형으로 타임라인에 나타납니다.

🔎 검색 및 내보내기

케이스 데이터베이스 전체에서 전체 텍스트 검색과 함께 CSV(스프레드시트), JSON(다른 도구와의 통합) 및 상세 HTML 보고서(검색어에 연결된 모든 아티팩트를 통합한 전체 도시에)로 내보내기를 지원합니다.

🔗 동적 연결

SID, MAC 주소, 해시와 같은 원시 기술 식별자를 즉시 사람이 읽을 수 있는 컨텍스트로 변환합니다. 동적 연결은 비파괴적 SQL ATTACH 쿼리를 사용하여 보기를 강화하므로 원본 증거는 절대 수정되지 않으며, 대량 IOC 위협 피드를 수집하여 알려진 악성 지표를 인라인으로 플래그할 수 있습니다.

🧠 사용자 행동 분석(UBA)

원시 아티팩트를 평이한 영어 활동 스토리로 변환 — 사용자와 해당 애플리케이션이 실제로 수행한 작업에 대한 관리자/HR가 읽을 수 있는 설명으로, 모든 진술은 정확한 소스 증거로 추적 가능합니다.

**사용자 행동 분석(UBA)**은 케이스의 Target_Artifacts/ 폴더에 있는 파싱된 아티팩트 데이터베이스를 읽고(엄격히 읽기 전용) 선언적 규칙 집합을 통해 재생하여 명확하고 시간순의 활동 스토리를 생성합니다. "User Behavior" 도구 모음 버튼 또는 **Ctrl+Shift+B**로 엽니다(케이스가 로드되어 있어야 함).

• 🧩 40개의 선언적 행동 감지(uba/config/behavior_rules.json) — 코드 없이 조정 가능 — 각각 심각도로 분류: 일상 · 주목할 만함 · 의심스러움 · 심각.
• 🕵️ 중요한 행동 감지: 로그인 / 로그아웃 / 잠금 해제, 프로그램 실행 · 실행 · 설치, 파일 열기 / 삭제 / 추론된 복사, USB 장치 연결, 네트워크 공유 액세스, 지속성 및 자동 시작, 명시적 자격 증명 사용(runas), 계정 및 그룹 변경, 서비스 변경, 시스템 시계 변조(의심스러움) 및 이벤트 로그 지우기(심각).
• 🗺️ 세 가지 보기 — 활동 스토리 피드, 활동 맵 히트맵(일 × 시간) 및 이 케이스에 대한 각 감지를 작동 중 / 제한적 / 데이터 없음 / 설계상으로 표시하는 "볼 수 있는 것" 정직성 보고서.
• 🔗 모든 활동은 증거로 뒷받침됩니다. 항목을 클릭하면 정확한 뒷받침 레코드(database : table : rowid)가 열립니다 — 소스 없이 주장되는 것은 없습니다.
• 👤 정직한 귀속. 행위자는 사용자 / 애플리케이션 / 시스템으로 해석되거나(또는 비워 둠) — UBA는 누가 무엇을 했는지 추측하지 않습니다.

감지 범위

40개의 감지는 네 가지 심각도 클래스와 파싱된 아티팩트 집합의 전체 범위에 걸쳐 있습니다:

필터: 자유 텍스트 검색 · 사용자/행위자("미귀속" 및 로그인 세션 토글 포함) · 행동 클래스(사용자 / 애플리케이션 / 시스템) · 심각도 · 애플리케이션(200개 이상의 프로그램에서 검색 가능한 다중 선택) · 빠른 사전 설정이 있는 날짜/시간 범위(전체 시간 / 첫날 / 마지막 날 / 활동의 마지막 시간).

데이터 소스: 보안, 시스템 및 애플리케이션 이벤트 로그 · USN 저널 · MFT · UserAssist · BAM · 프리페치 · ShimCache · AmCache · MUICache · ShellBags · LNK / 점프 목록 · 휴지통 · SRUM(애플리케이션, 네트워크, 연결) · 레지스트리 하이브.

포렌식 보장

• 읽기 전용. 소스 데이터베이스는 읽기 전용으로 열리며 분석은 증거를 절대 건드리지 않습니다.
• 전체 출처 추적. 모든 이벤트는 database → table → rowid를 전달하며 요청 시 실제 소스 행을 엽니다.
• 귀속은 추측하지 않습니다. 이벤트는 사용자, 애플리케이션, 시스템에 귀속되거나 비워 둡니다. 대화형 로그온 세션은 컨텍스트 레이블("<user>의 세션 동안")로만 사용되며 작업을 귀속하는 데는 절대 사용되지 않습니다.
• 정직한 표현. 문구는 의도적인 상호 작용(UserAssist, SRUM 포그라운드)과 애플리케이션이 생성할 수도 있는 아티팩트(ShellBags, LNK, 점프 목록)를 구분하며 카드에 명시적 주의 사항을 표시합니다.
• 부재는 명시되며 암시되지 않습니다. 볼 수 있는 것 보고서는 이 특정 케이스에 대한 모든 감지를 표시하므로 누락된 데이터가 "아무 일도 없었다"로 조용히 읽히지 않습니다.

UBA는 규칙 기반 행동 상관 및 분류이며 통계/ML 이상 징후 점수가 아닙니다 — 모든 발견은 명시적이고 감사 가능한 규칙에 매핑됩니다. 전체 감지 카탈로그는 RELEASE_NOTES.md를 참조하십시오.

🧩 상관 엔진

상관 엔진 v1.7.0 — 재구성 코어. 릴리스 기록은 RELEASE_NOTES.md를 참조하십시오.

Crow-Eye 상관 엔진은 프로덕션 등급의 포렌식 상관 시스템입니다. 모든 소스에서 Windows 아티팩트를 수집하고, 정규화하며, 고립된 레코드를 시스템에서 발생한 일, 시기 및 관련된 사람에 대한 일관된 서사로 전환하는 시간 및 ID 관계를 표면화합니다. 가장 일반적인 조사 질문에 대한 기본 제공 상관 규칙(Wing)으로 즉시 작동하며, 분석가가 코드를 건드리지 않고 사용자 지정 규칙을 작성할 수 있게 하고, 의미 해석을 블랙박스 점수가 아닌 작성 가능한 규칙과 조사자에게 위임합니다.

🎥 사용자 가이드

범용 데이터 가져오기: 상관 엔진은 CSV, JSON 또는 SQLite 형식의 모든 포렌식 도구 출력을 가져와 Feather 데이터베이스로 변환할 수 있습니다. 즉, 타사 도구(Plaso, Autopsy, Volatility 등)의 데이터를 Crow-Eye의 기본 아티팩트와 상호 연관시켜 모든 포렌식 데이터 소스에 걸친 통합 상관 분석을 만들 수 있습니다.

🎯 정확성 및 증거 완전성

0.11.0 주기부터의 집중된 정확성 검증으로, 실제 약 70만 개 레코드 Windows 케이스에 대해 종단 간 검증되었으며 이전 안정성 작업 위에 계층화되었습니다. 아래의 모든 수정 사항은 pytest 회귀 테스트 스위트에 의해 고정되고 전체론적 검증 하네스로 검증되었습니다; 당시 제공된 7개의 기본 wing을 실행했으며 오늘은 11개가 제공됩니다. 아래 인용된 일치 수는 해당 릴리스의 규칙에 따라 측정되었습니다: 0.13.0은 일치로 간주되는 항목을 변경했습니다(일치는 이제 둘 이상의 feather에 걸쳐 있어야 함) 및 신뢰도 점수의 의미를 변경했습니다, 따라서 이를 현재 수치가 아닌 해당 검증의 기록으로 취급하십시오.

ID 엔진은 모든 증거를 포착합니다

• 수정됨: 시간 필터가 활성화된 경우 ID 엔진이 모든 feather의 첫 번째 행만 반복했습니다(시간대 인식 vs 순진한 datetime 비교가 TypeError를 발생시키고 행별 루프를 중단). 검증 케이스에서 기록 수가 3,558 → 745,615로 증가했습니다.
• 수정됨: 로그 레코드가 모든 이벤트를 이벤트 공급자로 축소했습니다(33,855개의 SecurityLogs 레코드가 하나의 ID를 공유). 아티팩트별 매핑은 이제 채널/공급자 메타데이터보다 실제 행별 엔터티(User, ComputerName, NewProcessName, TargetUserName)를 우선시합니다.
• 수정됨: 아티팩트 인식 필드 매핑이 실행되지 않았습니다 — 파서가 각 행에 artifact 열을 스탬프하지 않기 때문입니다. 엔진은 이제 feather_metadata.artifact_type으로 폴백하므로 SecurityLogs / SystemLogs / ApplicationLogs는 아티팩트별 ID 우선순위를 사용합니다.
• 수정됨: 자리 표시자 문자열이 잘못된 ID가 되었습니다('N/A', 'Unknown', '-', nil-GUID가 관련 없는 레코드를 함께 묶음). 검증기는 이제 30개 이상의 자리 표시자 변형을 거부합니다.
• 당시 측정된 전체 범위 창 하나의 순 결과: 실행 증명 wing은 ID 엔진에서 2,856개의 교차 feather(높음) 일치와 시간 엔진에서 643개의 교차 feather 일치를 표면화했으며, 해당 릴리스의 다른 6개 wing에 걸쳐 wing당 24–118개의 교차 feather 일치가 있었습니다.

더 이상 "모든 것이 낮음 — 뭔가 잘못됨" 없음

• 수정됨: 단일 feather 일치가 높음으로 태그되었습니다. feather_count == 1인 일치는 이제 confidence_category="낮음 - 단일 feather"를 얻으므로 높음 보기는 실제 교차 feather 상관에 집중합니다.
• 수정됨: 경로 인식 복합 키가 동일한 ID를 feather 간에 분할했습니다(각 feather는 경로를 다르게 저장하므로 chrome은 10개 이상의 키를 가지며 결코 상호 연관되지 않음). 키는 이제 이름 전용입니다 — 교차 feather 상관이 다시 작동합니다.

경로 분류를 통한 가장 탐지 — 일치가 형성된 후 엔진은 모든 레코드의 경로를 신뢰됨(Program Files, System32, WinSxS, BAM/SRUM /device/harddiskvolumeN/... 형식, …) 또는 의심스러움(Temp, Downloads, Public, AppData\Local\Temp, 휴지통, 이동식 루트, 네트워크 공유)으로 분류합니다. 두 분류에 걸친 일치는 impersonation_alert를 발생시킵니다(≈0.05% 비율, 각각 실제 후보).정직한 증거 회계 — 명명된 버킷(no_identity_field, normalize_failure, below_threshold_skipped, …)이 있는 창별 드롭 원장과 파이프라인별 요약(확인된 레코드, high/low 방출, no-identity, 드롭 버킷, timeless-feather 조인)을 제공합니다. 모든 레코드는 매치 또는 명명된 드롭 버킷에 들어갑니다. 즉, "남는 증거 없음"이 로그에서 검증 가능합니다. low_confidence_review_mode는 기본적으로 ON이므로 임계값 미만 그룹은 조용히 사라지는 대신 Low-confidence 매치가 됩니다.

Timeless-feather 신원 강화 — 행별 타임스탬프가 없는 feather(AutoStartPrograms, MUICache, SystemServices, TypedPaths)는 더 이상 모든 행에 가짜 생성 시간을 찍지 않습니다. 대신 시간 기반 매치가 형성된 후, 엔진이 모든 timeless feather의 일치 레코드를 신원 기준으로 보충 증거로 조인합니다.

통합 신원 레지스트리 — config/standard_fields/identities.json은 엔진과 Eye가 참조해야 하는 모든 열에 대한 단일 진실 소스입니다: 98개 범주, 1,146개 열 동의어(앱/프로세스, 파일, 해시, 사용자, 호스트/디바이스, 네트워크, 레지스트리, 서비스/작업, 이벤트, 이메일, 브라우저, 클라우드, Windows 내부, 인증서, 컨테이너, OS 객체). 새 열 동의어를 추가하는 것은 코드 변경이 아닌 JSON 편집입니다.

의미 매핑 오탐 수정 — 다중 지표 게이팅이 이제 실제로 적용됩니다(data-exfiltration-pattern은 ≥2개 지표 필요). 불가능한 AND 규칙(4625 AND 4624)은 OR로 재작성되었습니다. wiper/원격 도구 규칙은 모든 Prefetch 항목에서 발화하는 대신 실제 정규식을 사용합니다. 기준 활동 규칙은 high/critical에서 info/low로 강등되었습니다(윙의 가중 점수화가 실제 위협을 상향 조정합니다).

✅ 프로덕션 상태

Correlation Engine은 프로덕션 준비 완료 상태이며 조사에 적극적으로 사용됩니다(Correlation Engine v1.7.0):

• ✅ 시간 창 스캔 엔진 — 프로덕션 준비 완료, 시간 기반 분석에 권장(O(N log N))
• ✅ 신원 기반 엔진 — 프로덕션 준비 완료, 신원 추적에 권장(O(N log N))
• ✅ Feather Builder / 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(s/ms/μs), YYYYMMDD, 미국식 슬래시 및 주석 문자열이 모두 첫 시도에 올바르게 파싱됩니다.
• 📈 다중 타임스탬프 팬아웃: JSON 타임스탬프 목록(Prefetch run_times)이 확장되어 모든 실행이 자체 상관 이벤트를 갖습니다.
• 🧰 단일 진실 소스: 필드 동의어는 config/standard_fields/*.json에, 테이블별 메타데이터는 correlation_engine/config/feather_schemas.json에 있습니다. 코드가 아닌 JSON 편집으로 확장합니다.
• ⚡ 스트리밍 + 스레드 안전: O(1) 메모리 query_time_range_iter. 잠금 보호 feather 캐시. 병렬 상관 처리 준비 완료.
• 🔍 유연한 규칙: 구성 가능한 매개변수로 사용자 정의 상관 규칙(윙)을 정의합니다.
• 📋 정직한 진단: 창별 통계 라인(records_in / no_identity / parse_cache_hits / below_threshold / matches_emitted)으로 증거가 드롭되었는지 항상 알 수 있습니다.
• 🧪 품질 고정: 타임스탬프 파싱, 신원 정규화, 팬아웃, writer 계약, Eye 작성(쓰기 측 GEP 거버넌스) 및 표준 필드 레지스트리를 다루는 pytest 회귀 테스트 스위트.

시스템 아키텍처

Correlation Engine은 네 가지 주요 구성 요소로 구성됩니다:

1. 🗄️ Feathers(데이터 정규화)

목적: 원시 포렌식 아티팩트를 표준화된 쿼리 가능 형식으로 변환합니다.

• 정규화된 포렌식 아티팩트 데이터를 포함하는 SQLite 데이터베이스 — 아티팩트 유형(Prefetch, ShimCache, 이벤트 로그, …)당 하나의 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 (상관 관계 규칙)

목적: 어떤 아티팩트를 상관 관계로 연결할지, 그리고 그 방법을 정의합니다.

• 시간 창, 최소 일치 횟수, 앵커 우선순위, 그리고 상관 관계로 연결할 feathers(가중치 포함)를 지정하는 JSON/YAML 규칙 — 여러 사례에 걸쳐 재사용 가능합니다. 모든 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. ⚙️ 엔진(상관관계 전략)

**목적**: 아티팩트 간의 관계를 찾기 위한 상관관계 로직을 실행합니다. 구조적 연결이 **먼저** 이루어지며, 계층 가중치 점수는 *해석/순위*로 그 위에 적용됩니다. 매칭의 근거가 아닙니다.

**시간 창 스캔 엔진** — 시간 기반 분석 및 체계적인 시간적 상관관계에 가장 적합합니다. 고정된 간격으로 시간을 스캔하며, 창마다 모든 feather의 레코드를 수집하고, 의미론적 필드 매칭 + 가중치 점수를 적용하며, MatchSet 추적을 통해 중복을 방지합니다. **O(N log N)**(인덱싱된 타임스탬프 쿼리); 배치 처리(초당 약 2,567개 창).

**신원 기반 상관관계 엔진** — 대규모 데이터셋(1,000개 이상의 레코드) 및 신원 추적에 가장 적합합니다. 신원을 추출하고 정규화하며, 신원별로 레코드를 그룹화하고, 각 클러스터 내에서 시간적 앵커를 구축하며, 증거를 1차/2차/보조로 분류하고, 매우 큰 집합(5,000개 이상의 앵커)의 경우 일정한 메모리로 스트리밍합니다. **O(N log N)**; 유형당 40개 이상의 신원 필드 패턴.

**엔진 선택**: 시간 기반 분석에는 시간 창 엔진을, 신원 추적에는 신원 기반 엔진을 사용하세요. 두 엔진 모두 프로덕션 준비가 완료되었으며 인덱싱된 쿼리로 대규모 데이터셋에 최적화되어 있습니다.

#### 4. 🔄 파이프라인(워크플로 오케스트레이션)

**목적**: feather 생성부터 결과 생성까지 완전한 분석 워크플로를 자동화합니다. 파이프라인은 구성(엔진 유형, wings, feathers)을 읽고, EngineSelector를 통해 적절한 엔진을 인스턴스화하고, 각 wing을 실행하며, 매치를 집계하고, 결과를 저장한 후(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"]
}

I notice you haven't provided the actual content to translate. Please paste the Markdown content for chunk 18 of 25, and I'll translate it from English to Korean following all the specified rules.```python from correlation_engine.pipeline import PipelineExecutor executor = PipelineExecutor(pipeline_config) results = executor.execute()

`--no-ignore` 플래그를 사용하면 `.gitignore` 파일을 무시하고 모든 파일을 검사할 수 있습니다. 이는 숨겨진 파일이나 무시된 파일에서도 취약점을 찾고자 할 때 유용합니다.

`--no-config` 플래그를 사용하면 기본 설정 파일을 로드하지 않고 도구를 실행할 수 있습니다. 이는 사용자 정의 설정을 테스트하거나 기본 설정이 문제를 일으키는 경우에 유용합니다.

`--no-cache` 플래그를 사용하면 캐시를 사용하지 않고 모든 검사를 처음부터 수행합니다. 이는 캐시된 결과가 오래되었거나 손상된 경우에 유용합니다.

`--no-update` 플래그를 사용하면 도구가 시작될 때 자동으로 업데이트를 확인하지 않도록 합니다. 이는 오프라인 환경에서 작업하거나 업데이트 확인으로 인한 지연을 피하고자 할 때 유용합니다.

`--no-banner` 플래그를 사용하면 도구가 시작될 때 배너를 표시하지 않도록 합니다. 이는 출력을 더 깔끔하게 유지하거나 스크립트에서 도구를 사용할 때 유용합니다.

`--no-color` 플래그를 사용하면 출력에서 색상을 비활성화합니다. 이는 색상 코드가 문제를 일으키는 터미널이나 CI/CD 파이프라인에서 유용합니다.

`--no-emoji` 플래그를 사용하면 출력에서 이모지를 비활성화합니다. 이는 이모지를 지원하지 않는 터미널이나 더 전문적인 출력을 원할 때 유용합니다.

`--no-progress` 플래그를 사용하면 진행률 표시줄을 비활성화합니다. 이는 출력을 더 간결하게 유지하거나 로그 파일에 출력을 기록할 때 유용합니다.

`--no-spinner` 플래그를 사용하면 로딩 스피너를 비활성화합니다. 이는 출력을 더 간결하게 유지하거나 스크립트에서 도구를 사용할 때 유용합니다.

`--no-verbose` 플래그를 사용하면 상세 출력을 비활성화합니다. 이는 출력을 더 간결하게 유지하거나 오류 메시지만 보고자 할 때 유용합니다.

`--no-debug` 플래그를 사용하면 디버그 출력을 비활성화합니다. 이는 출력을 더 간결하게 유지하거나 디버그 정보가 필요하지 않을 때 유용합니다.

`--no-trace` 플래그를 사용하면 추적 출력을 비활성화합니다. 이는 출력을 더 간결하게 유지하거나 추적 정보가 필요하지 않을 때 유용합니다.

`--no-quiet` 플래그를 사용하면 조용한 모드를 비활성화합니다. 이는 출력을 더 자세하게 유지하거나 모든 정보를 보고자 할 때 유용합니다.

`--no-interactive` 플래그를 사용하면 대화형 모드를 비활성화합니다. 이는 스크립트에서 도구를 사용하거나 자동화된 환경에서 작업할 때 유용합니다.

`--no-tty` 플래그를 사용하면 TTY(터미널) 감지를 비활성화합니다. 이는 터미널이 아닌 환경에서 도구를 사용할 때 유용합니다.

`--no-ansi` 플래그를 사용하면 ANSI 이스케이프 코드를 비활성화합니다. 이는 ANSI 코드를 지원하지 않는 터미널이나 출력을 파일로 리디렉션할 때 유용합니다.

`--no-unicode` 플래그를 사용하면 유니코드 문자를 비활성화합니다. 이는 유니코드를 지원하지 않는 터미널이나 더 호환성 있는 출력을 원할 때 유용합니다.

`--no-utf8` 플래그를 사용하면 UTF-8 인코딩을 비활성화합니다. 이는 UTF-8을 지원하지 않는 시스템이나 다른 인코딩을 사용해야 할 때 유용합니다.

`--no-emoji` 플래그와 유사하게 `--no-symbols` 플래그를 사용하면 출력에서 특수 기호를 비활성화합니다. 이는 특수 기호가 문제를 일으키는 터미널이나 더 간결한 출력을 원할 때 유용합니다.

`--no-icons` 플래그를 사용하면 출력에서 아이콘을 비활성화합니다. 이는 아이콘을 지원하지 않는 터미널이나 더 전문적인 출력을 원할 때 유용합니다.

`--no-glyphs` 플래그를 사용하면 출력에서 글리프(특수 문자)를 비활성화합니다. 이는 글리프가 문제를 일으키는 터미널이나 더 간결한 출력을 원할 때 유용합니다.

`--no-pager` 플래그를 사용하면 출력을 페이지 단위로 표시하는 페이저를 비활성화합니다. 이는 출력을 한 번에 모두 표시하거나 페이저가 문제를 일으키는 환경에서 유용합니다.

`--no-less` 플래그를 사용하면 `less` 명령을 사용한 페이징을 비활성화합니다. 이는 `less`가 설치되지 않은 환경이나 다른 페이저를 사용하고자 할 때 유용합니다.

`--no-more` 플래그를 사용하면 `more` 명령을 사용한 페이징을 비활성화합니다. 이는 `more`가 설치되지 않은 환경이나 다른 페이저를 사용하고자 할 때 유용합니다.

`--no-head` 플래그를 사용하면 출력의 처음 부분만 표시하는 기능을 비활성화합니다. 이는 전체 출력을 보고자 할 때 유용합니다.

`--no-tail` 플래그를 사용하면 출력의 마지막 부분만 표시하는 기능을 비활성화합니다. 이는 전체 출력을 보고자 할 때 유용합니다.

`--no-grep` 플래그를 사용하면 출력에서 특정 패턴을 검색하는 기능을 비활성화합니다. 이는 검색 기능이 필요하지 않을 때 유용합니다.

`--no-sed` 플래그를 사용하면 출력에서 텍스트를 치환하는 기능을 비활성화합니다. 이는 치환 기능이 필요하지 않을 때 유용합니다.

`--no-awk` 플래그를 사용하면 출력에서 텍스트를 처리하는 기능을 비활성화합니다. 이는 처리 기능이 필요하지 않을 때 유용합니다.

`--no-cut` 플래그를 사용하면 출력에서 특정 필드를 추출하는 기능을 비활성화합니다. 이는 필드 추출 기능이 필요하지 않을 때 유용합니다.

`--no-sort` 플래그를 사용하면 출력을 정렬하는 기능을 비활성화합니다. 이는 정렬 기능이 필요하지 않거나 원래 순서를 유지하고자 할 때 유용합니다.

`--no-uniq` 플래그를 사용하면 출력에서 중복된 줄을 제거하는 기능을 비활성화합니다. 이는 중복 제거 기능이 필요하지 않을 때 유용합니다.

`--no-wc` 플래그를 사용하면 출력에서 줄 수, 단어 수, 문자 수를 세는 기능을 비활성화합니다. 이는 카운트 기능이 필요하지 않을 때 유용합니다.

`--no-md5` 플래그를 사용하면 MD5 해시 계산 기능을 비활성화합니다. 이는 MD5 해시가 필요하지 않을 때 유용합니다.

`--no-sha1` 플래그를 사용하면 SHA-1 해시 계산 기능을 비활성화합니다. 이는 SHA-1 해시가 필요하지 않을 때 유용합니다.

`--no-sha256` 플래그를 사용하면 SHA-256 해시 계산 기능을 비활성화합니다. 이는 SHA-256 해시가 필요하지 않을 때 유용합니다.

`--no-sha512` 플래그를 사용하면 SHA-512 해시 계산 기능을 비활성화합니다. 이는 SHA-512 해시가 필요하지 않을 때 유용합니다.

`--no-base64` 플래그를 사용하면 Base64 인코딩/디코딩 기능을 비활성화합니다. 이는 Base64 기능이 필요하지 않을 때 유용합니다.

`--no-hex` 플래그를 사용하면 16진수 인코딩/디코딩 기능을 비활성화합니다. 이는 16진수 기능이 필요하지 않을 때 유용합니다.

`--no-url` 플래그를 사용하면 URL 인코딩/디코딩 기능을 비활성화합니다. 이는 URL 기능이 필요하지 않을 때 유용합니다.

`--no-html` 플래그를 사용하면 HTML 인코딩/디코딩 기능을 비활성화합니다. 이는 HTML 기능이 필요하지 않을 때 유용합니다.

`--no-xml` 플래그를 사용하면 XML 인코딩/디코딩 기능을 비활성화합니다. 이는 XML 기능이 필요하지 않을 때 유용합니다.

`--no-json` 플래그를 사용하면 JSON 인코딩/디코딩 기능을 비활성화합니다. 이는 JSON 기능이 필요하지 않을 때 유용합니다.

`--no-yaml` 플래그를 사용하면 YAML 인코딩/디코딩 기능을 비활성화합니다. 이는 YAML 기능이 필요하지 않을 때 유용합니다.

`--no-csv` 플래그를 사용하면 CSV 인코딩/디코딩 기능을 비활성화합니다. 이는 CSV 기능이 필요하지 않을 때 유용합니다.

`--no-tsv` 플래그를 사용하면 TSV 인코딩/디코딩 기능을 비활성화합니다. 이는 TSV 기능이 필요하지 않을 때 유용합니다.

`--no-regex` 플래그를 사용하면 정규 표현식 기능을 비활성화합니다. 이는 정규 표현식 기능이 필요하지 않을 때 유용합니다.

`--no-glob` 플래그를 사용하면 글로브 패턴 매칭 기능을 비활성화합니다. 이는 글로브 패턴 기능이 필요하지 않을 때 유용합니다.

`--no-fnmatch` 플래그를 사용하면 파일 이름 매칭 기능을 비활성화합니다. 이는 파일 이름 매칭 기능이 필요하지 않을 때 유용합니다.

`--no-path` 플래그를 사용하면 경로 처리 기능을 비활성화합니다. 이는 경로 처리 기능이 필요하지 않을 때 유용합니다.

`--no-file` 플래그를 사용하면 파일 처리 기능을 비활성화합니다. 이는 파일 처리 기능이 필요하지 않을 때 유용합니다.

`--no-dir` 플래그를 사용하면 디렉토리 처리 기능을 비활성화합니다. 이는 디렉토리 처리 기능이 필요하지 않을 때 유용합니다.

`--no-link` 플래그를 사용하면 심볼릭 링크 처리 기능을 비활성화합니다. 이는 심볼릭 링크 처리 기능이 필요하지 않을 때 유용합니다.

`--no-symlink` 플래그를 사용하면 심볼릭 링크 처리 기능을 비활성화합니다. 이는 심볼릭 링크 처리 기능이 필요하지 않을 때 유용합니다.

`--no-hardlink` 플래그를 사용하면 하드 링크 처리 기능을 비활성화합니다. 이는 하드 링크 처리 기능이 필요하지 않을 때 유용합니다.

`--no-mount` 플래그를 사용하면 마운트 포인트 처리 기능을 비활성화합니다. 이는 마운트 포인트 처리 기능이 필요하지 않을 때 유용합니다.

`--no-device` 플래그를 사용하면 장치 파일 처리 기능을 비활성화합니다. 이는 장치 파일 처리 기능이 필요하지 않을 때 유용합니다.

`--no-fifo` 플래그를 사용하면 FIFO(명명된 파이프) 처리 기능을 비활성화합니다. 이는 FIFO 처리 기능이 필요하지 않을 때 유용합니다.

`--no-socket` 플래그를 사용하면 소켓 처리 기능을 비활성화합니다. 이는 소켓 처리 기능이 필요하지 않을 때 유용합니다.

`--no-block` 플래그를 사용하면 블록 장치 처리 기능을 비활성화합니다. 이는 블록 장치 처리 기능이 필요하지 않을 때 유용합니다.

`--no-char` 플래그를 사용하면 문자 장치 처리 기능을 비활성화합니다. 이는 문자 장치 처리 기능이 필요하지 않을 때 유용합니다.

`--no-pipe` 플래그를 사용하면 파이프 처리 기능을 비활성화합니다. 이는 파이프 처리 기능이 필요하지 않을 때 유용합니다.

`--no-proc` 플래그를 사용하면 프로세스 처리 기능을 비활성화합니다. 이는 프로세스 처리 기능이 필요하지 않을 때 유용합니다.

`--no-thread` 플래그를 사용하면 스레드 처리 기능을 비활성화합니다. 이는 스레드 처리 기능이 필요하지 않을 때 유용합니다.

`--no-signal` 플래그를 사용하면 신호 처리 기능을 비활성화합니다. 이는 신호 처리 기능이 필요하지 않을 때 유용합니다.

`--no-timer` 플래그를 사용하면 타이머 기능을 비활성화합니다. 이는 타이머 기능이 필요하지 않을 때 유용합니다.

`--no-clock` 플래그를 사용하면 시계 기능을 비활성화합니다. 이는 시계 기능이 필요하지 않을 때 유용합니다.

`--no-date` 플래그를 사용하면 날짜 처리 기능을 비활성화합니다. 이는 날짜 처리 기능이 필요하지 않을 때 유용합니다.

`--no-time` 플래그를 사용하면 시간 처리 기능을 비활성화합니다. 이는 시간 처리 기능이 필요하지 않을 때 유용합니다.

`--no-timestamp` 플래그를 사용하면 타임스탬프 처리 기능을 비활성화합니다. 이는 타임스탬프 처리 기능이 필요하지 않을 때 유용합니다.

`--no-duration` 플래그를 사용하면 기간 처리 기능을 비활성화합니다. 이는 기간 처리 기능이 필요하지 않을 때 유용합니다.

`--no-interval` 플래그를 사용하면 간격 처리 기능을 비활성화합니다. 이는 간격 처리 기능이 필요하지 않을 때 유용합니다.

`--no-period` 플래그를 사용하면 기간 처리 기능을 비활성화합니다. 이는 기간 처리 기능이 필요하지 않을 때 유용합니다.

`--no-frequency` 플래그를 사용하면 빈도 처리 기능을 비활성화합니다. 이는 빈도 처리 기능이 필요하지 않을 때 유용합니다.

`--no-rate` 플래그를 사용하면 비율 처리 기능을 비활성화합니다. 이는 비율 처리 기능이 필요하지 않을 때 유용합니다.

`--no-speed` 플래그를 사용하면 속도 처리 기능을 비활성화합니다. 이는 속도 처리 기능이 필요하지 않을 때 유용합니다.

`--no-velocity` 플래그를 사용하면 속도 처리 기능을 비활성화합니다. 이는 속도 처리 기능이 필요하지 않을 때 유용합니다.

`--no-acceleration` 플래그를 사용하면 가속도 처리 기능을 비활성화합니다. 이는 가속도 처리 기능이 필요하지 않을 때 유용합니다.

`--no-force` 플래그를 사용하면 힘 처리 기능을 비활성화합니다. 이는 힘 처리 기능이 필요하지 않을 때 유용합니다.

`--no-energy` 플래그를 사용하면 에너지 처리 기능을 비활성화합니다. 이는 에너지 처리 기능이 필요하지 않을 때 유용합니다.

`--no-power` 플래그를 사용하면 전력 처리 기능을 비활성화합니다. 이는 전력 처리 기능이 필요하지 않을 때 유용합니다.

`--no-voltage` 플래그를 사용하면 전압 처리 기능을 비활성화합니다. 이는 전압 처리 기능이 필요하지 않을 때 유용합니다.

`--no-current` 플래그를 사용하면 전류 처리 기능을 비활성화합니다. 이는 전류 처리 기능이 필요하지 않을 때 유용합니다.

`--no-resistance` 플래그를 사용하면 저항 처리 기능을 비활성화합니다. 이는 저항 처리 기능이 필요하지 않을 때 유용합니다.

`--no-capacitance` 플래그를 사용하면 커패시턴스 처리 기능을 비활성화합니다. 이는 커패시턴스 처리 기능이 필요하지 않을 때 유용합니다.

`--no-inductance` 플래그를 사용하면 인덕턴스 처리 기능을 비활성화합니다. 이는 인덕턴스 처리 기능이 필요하지 않을 때 유용합니다.

`--no-impedance` 플래그를 사용하면 임피던스 처리 기능을 비활성화합니다. 이는 임피던스 처리 기능이 필요하지 않을 때 유용합니다.

`--no-frequency` 플래그를 사용하면 주파수 처리 기능을 비활성화합니다. 이는 주파수 처리 기능이 필요하지 않을 때 유용합니다.

`--no-wavelength` 플래그를 사용하면 파장 처리 기능을 비활성화합니다. 이는 파장 처리 기능이 필요하지 않을 때 유용합니다.

`--no-amplitude` 플래그를 사용하면 진폭 처리 기능을 비활성화합니다. 이는 진폭 처리 기능이 필요하지 않을 때 유용합니다.

`--no-phase` 플래그를 사용하면 위상 처리 기능을 비활성화합니다. 이는 위상 처리 기능이 필요하지 않을 때 유용합니다.

`--no-polarity` 플래그를 사용하면 극성 처리 기능을 비활성화합니다. 이는 극성 처리 기능이 필요하지 않을 때 유용합니다.

`--no-charge` 플래그를 사용하면 전하 처리 기능을 비활성화합니다. 이는 전하 처리 기능이 필요하지 않을 때 유용합니다.

`--no-mass` 플래그를 사용하면 질량 처리 기능을 비활성화합니다. 이는 질량 처리 기능이 필요하지 않을 때 유용합니다.

`--no-weight` 플래그를 사용하면 무게 처리 기능을 비활성화합니다. 이는 무게 처리 기능이 필요하지 않을 때 유용합니다.

`--no-density` 플래그를 사용하면 밀도 처리 기능을 비활성화합니다. 이는 밀도 처리 기능이 필요하지 않을 때 유용합니다.

`--no-volume` 플래그를 사용하면 부피 처리 기능을 비활성화합니다. 이는 부피 처리 기능이 필요하지 않을 때 유용합니다.

`--no-area` 플래그를 사용하면 면적 처리 기능을 비활성화합니다. 이는 면적 처리 기능이 필요하지 않을 때 유용합니다.

`--no-length` 플래그를 사용하면 길이 처리 기능을 비활성화합니다. 이는 길이 처리 기능이 필요하지 않을 때 유용합니다.

`--no-width` 플래그를 사용하면 너비 처리 기능을 비활성화합니다. 이는 너비 처리 기능이 필요하지 않을 때 유용합니다.

`--no-height` 플래그를 사용하면 높이 처리 기능을 비활성화합니다. 이는 높이 처리 기능이 필요하지 않을 때 유용합니다.

`--no-depth` 플래그를 사용하면 깊이 처리 기능을 비활성화합니다. 이는 깊이 처리 기능이 필요하지 않을 때 유용합니다.

`--no-size` 플래그를 사용하면 크기 처리 기능을 비활성화합니다. 이는 크기 처리 기능이 필요하지 않을 때 유용합니다.

`--no-dimension` 플래그를 사용하면 차원 처리 기능을 비활성화합니다. 이는 차원 처리 기능이 필요하지 않을 때 유용합니다.

`--no-unit` 플래그를 사용하면 단위 처리 기능을 비활성화합니다. 이는 단위 처리 기능이 필요하지 않을 때 유용합니다.

`--no-measure` 플래그를 사용하면 측정 처리 기능을 비활성화합니다. 이는 측정 처리 기능이 필요하지 않을 때 유용합니다.

`--no-calculate` 플래그를 사용하면 계산 처리 기능을 비활성화합니다. 이는 계산 처리 기능이 필요하지 않을 때 유용합니다.

`--no-compute` 플래그를 사용하면 컴퓨팅 처리 기능을 비활성화합니다. 이는 컴퓨팅 처리 기능이 필요하지 않을 때 유용합니다.

`--no-process` 플래그를 사용하면 프로세스 처리 기능을 비활성화합니다. 이는 프로세스 처리 기능이 필요하지 않을 때 유용합니다.

`--no-analyze` 플래그를 사용하면 분석 처리 기능을 비활성화합니다. 이는 분석 처리 기능이 필요하지 않을 때 유용합니다.

`--no-evaluate` 플래그를 사용하면 평가 처리 기능을 비활성화합니다. 이는 평가 처리 기능이 필요하지 않을 때 유용합니다.

`--no-parse` 플래그를 사용하면 파싱 처리 기능을 비활성화합니다. 이는 파싱 처리 기능이 필요하지 않을 때 유용합니다.

`--no-compile` 플래그를 사용하면 컴파일 처리 기능을 비활성화합니다. 이는 컴파일 처리 기능이 필요하지 않을 때 유용합니다.

`--no-interpret` 플래그를 사용하면 인터프리트 처리 기능을 비활성화합니다. 이는 인터프리트 처리 기능이 필요하지 않을 때 유용합니다.

`--no-execute` 플래그를 사용하면 실행 처리 기능을 비활성화합니다. 이는 실행 처리 기능이 필요하지 않을 때 유용합니다.

`--no-run` 플래그를 사용하면 실행 처리 기능을 비활성화합니다. 이는 실행 처리 기능이 필요하지 않을 때 유용합니다.

`--no-launch` 플래그를 사용하면 실행 처리 기능을 비활성화합니다. 이는 실행 처리 기능이 필요하지 않을 때 유용합니다.

`--no-start` 플래그를 사용하면 시작 처리 기능을 비활성화합니다. 이는 시작 처리 기능이 필요하지 않을 때 유용합니다.

`--no-stop` 플래그를 사용하면 중지 처리 기능을 비활성화합니다. 이는 중지 처리 기능이 필요하지 않을 때 유용합니다.

`--no-pause` 플래그를 사용하면 일시 중지 처리 기능을 비활성화합니다. 이는 일시 중지 처리 기능이 필요하지 않을 때 유용합니다.

`--no-resume` 플래그를 사용하면 재개 처리 기능을 비활성화합니다. 이는 재개 처리 기능이 필요하지 않을 때 유용합니다.

`--no-restart` 플래그를 사용하면 재시작 처리 기능을 비활성화합니다. 이는 재시작 처리 기능이 필요하지 않을 때 유용합니다.

`--no-reload` 플래그를 사용하면 리로드 처리 기능을 비활성화합니다. 이는 리로드 처리 기능이 필요하지 않을 때 유용합니다.

`--no-refresh` 플래그를 사용하면 새로고침 처리 기능을 비활성화합니다. 이는 새로고침 처리 기능이 필요하지 않을 때 유용합니다.

`--no-update` 플래그를 사용하면 업데이트 처리 기능을 비활성화합니다. 이는 업데이트 처리 기능이 필요하지 않을 때 유용합니다.

`--no-upgrade` 플래그를 사용하면 업그레이드 처리 기능을 비활성화합니다. 이는 업그레이드 처리 기능이 필요하지 않을 때 유용합니다.

`--no-install` 플래그를 사용하면 설치 처리 기능을 비활성화합니다. 이는 설치 처리 기능이 필요하지 않을 때 유용합니다.

`--no-uninstall` 플래그를 사용하면 제거 처리 기능을 비활성화합니다. 이는 제거 처리 기능이 필요하지 않을 때 유용합니다.

`--no-remove` 플래그를 사용하면 제거 처리 기능을 비활성화합니다. 이는 제거 처리 기능이 필요하지 않을 때 유용합니다.

`--no-delete` 플래그를 사용하면 삭제 처리 기능을 비활성화합니다. 이는 삭제 처리 기능이 필요하지 않을 때 유용합니다.

`--no-create` 플래그를 사용하면 생성 처리 기능을 비활성화합니다. 이는 생성 처리 기능이 필요하지 않을 때 유용합니다.

`--no-make` 플래그를 사용하면 생성 처리 기능을 비활성화합니다. 이는 생성 처리 기능이 필요하지 않을 때 유용합니다.

`--no-build` 플래그를 사용하면 빌드 처리 기능을 비활성화합니다. 이는 빌드 처리 기능이 필요하지 않을 때 유용합니다.

`--no-construct` 플래그를 사용하면 구성 처리 기능을 비활성화합니다. 이는 구성 처리 기능이 필요하지 않을 때 유용합니다.

`--no-destroy` 플래그를 사용하면 파괴 처리 기능을 비활성화합니다. 이는 파괴 처리 기능이 필요하지 않을 때 유용합니다.

`--no-clean` 플래그를 사용하면 정리 처리 기능을 비활성화합니다. 이는 정리 처리 기능이 필요하지 않을 때 유용합니다.

`--no-purge` 플래그를 사용하면 제거 처리 기능을 비활성화합니다. 이는 제거 처리 기능이 필요하지 않을 때 유용합니다.

`--no-reset` 플래그를 사용하면 리셋 처리 기능을 비활성화합니다. 이는 리셋 처리 기능이 필요하지 않을 때 유용합니다.

`--no-initialize` 플래그를 사용하면 초기화 처리 기능을 비활성화합니다. 이는 초기화 처리 기능이 필요하지 않을 때 유용합니다.

`--no-init` 플래그를 사용하면 초기화 처리 기능을 비활성화합니다. 이는 초기화 처리 기능이 필요하지 않을 때 유용합니다.

`--no-setup` 플래그를 사용하면 설정 처리 기능을 비활성화합니다. 이는 설정 처리 기능이 필요하지 않을 때 유용합니다.

`--no-configure` 플래그를 사용하면 구성 처리 기능을 비활성화합니다. 이는 구성 처리 기능이 필요하지 않을 때 유용합니다.

`--no-config` 플래그를 사용하면 구성 처리 기능을 비활성화합니다. 이는 구성 처리 기능이 필요하지 않을 때 유용합니다.

`--no-option` 플래그를 사용하면 옵션 처리 기능을 비활성화합니다. 이는 옵션 처리 기능이 필요하지 않을 때 유용합니다.

`--no-parameter` 플래그를 사용하면 매개변수 처리 기능을 비활성화합니다. 이는 매개변수 처리 기능이 필요하지 않을 때 유용합니다.

`--no-argument` 플래그를 사용하면 인수 처리 기능을 비활성화합니다. 이는 인수 처리 기능이 필요하지 않을 때 유용합니다.

`--no-value` 플래그를 사용하면 값 처리 기능을 비활성화합니다. 이는 값 처리 기능이 필요하지 않을 때 유용합니다.

`--no-variable` 플래그를 사용하면 변수 처리 기능을 비활성화합니다. 이는 변수 처리 기능이 필요하지 않을 때 유용합니다.

`--no-constant` 플래그를 사용하면 상수 처리 기능을 비활성화합니다. 이는 상수 처리 기능이 필요하지 않을 때 유용합니다.

`--no-literal` 플래그를 사용하면 리터럴 처리 기능을 비활성화합니다. 이는 리터럴 처리 기능이 필요하지 않을 때 유용합니다.

`--no-string` 플래그를 사용하면 문자열 처리 기능을 비활성화합니다. 이는 문자열 처리 기능이 필요하지 않을 때 유용합니다.

`--no-char` 플래그를 사용하면 문자 처리 기능을 비활성화합니다. 이는 문자 처리 기능이 필요하지 않을 때 유용합니다.

`--no-byte` 플래그를 사용하면 바이트 처리 기능을 비활성화합니다. 이는 바이트 처리 기능이 필요하지 않을 때 유용합니다.

`--no-bit` 플래그를 사용하면 비트 처리 기능을 비활성화합니다. 이는 비트 처리 기능이 필요하지 않을 때 유용합니다.

`--no-bool` 플래그를 사용하면 불리언 처리 기능을 비활성화합니다. 이는 불리언 처리 기능이 필요하지 않을 때 유용합니다.

`--no-int` 플래그를 사용하면 정수 처리 기능을 비활성화합니다. 이는 정수 처리 기능이 필요하지 않을 때 유용합니다.

`--no-float` 플래그를 사용하면 부동 소수점 처리 기능을 비활성화합니다. 이는 부동 소수점 처리 기능이 필요하지 않을 때 유용합니다.

`--no-double` 플래그를 사용하면 더블 처리 기능을 비활성화합니다. 이는 더블 처리 기능이 필요하지 않을 때 유용합니다.

`--no-decimal` 플래그를 사용하면 십진수 처리 기능을 비활성화합니다. 이는 십진수 처리 기능이 필요하지 않을 때 유용합니다.

`--no-number` 플래그를 사용하면 숫자 처리 기능을 비활성화합니다. 이는 숫자 처리 기능이 필요하지 않을 때 유용합니다.

`--no-numeric` 플래그를 사용하면 숫자 처리 기능을 비활성화합니다. 이는 숫자 처리 기능이 필요하지 않을 때 유용합니다.

`--no-integer` 플래그를 사용하면 정수 처리 기능을 비활성화합니다. 이는 정수 처리 기능이 필요하지 않을 때 유용합니다.

`--no-float` 플래그를 사용하면 부동 소수점 처리 기능을 비활성화합니다. 이는 부동 소수점 처리 기능이 필요하지 않을 때 유용합니다.

`--no-real` 플래그를 사용하면 실수 처리 기능을 비활성화합니다. 이는 실수 처리 기능이 필요하지 않을 때 유용합니다.

`--no-complex` 플래그를 사용하면 복소수 처리 기능을 비활성화합니다. 이는 복소수 처리 기능이 필요하지 않을 때 유용합니다.

`--no-imaginary` 플래그를 사용하면 허수 처리 기능을 비활성화합니다. 이는 허수 처리 기능이 필요하지 않을 때 유용합니다.

`--no-vector` 플래그를 사용하면 벡터 처리 기능을 비활성화합니다. 이는 벡터 처리 기능이 필요하지 않을 때 유용합니다.

`--no-matrix` 플래그를 사용하면 행렬 처리 기능을 비활성화합니다. 이는 행렬 처리 기능이 필요하지 않을 때 유용합니다.

`--no-array` 플래그를 사용하면 배열 처리 기능을 비활성화합니다. 이는 배열 처리 기능이 필요하지 않을 때 유용합니다.

`--no-list` 플래그를 사용하면 리스트 처리 기능을 비활성화합니다. 이는 리스트 처리 기능이 필요하지 않을 때 유용합니다.

`--no-set` 플래그를 사용하면 집합 처리 기능을 비활성화합니다. 이는 집합 처리 기능이 필요하지 않을 때 유용합니다.

`--no-map` 플래그를 사용하면 맵 처리 기능을 비활성화합니다. 이는 맵 처리 기능이 필요하지 않을 때 유용합니다.

`--no-dict` 플래그를 사용하면 사전 처리 기능을 비활성화합니다. 이는 사전 처리 기능이 필요하지 않을 때 유용합니다.

`--no-hash` 플래그를 사용하면 해시 처리 기능을 비활성화합니다. 이는 해시 처리 기능이 필요하지 않을 때 유용합니다.

`--no-table` 플래그를 사용하면 테이블 처리 기능을 비활성화합니다. 이는 테이블 처리 기능이 필요하지 않을 때 유용합니다.

`--no-record` 플래그를 사용하면 레코드 처리 기능을 비활성화합니다. 이는 레코드 처리 기능이 필요하지 않을 때 유용합니다.

`--no-field` 플래그를 사용하면 필드 처리 기능을 비활성화합니다. 이는 필드 처리 기능이 필요하지 않을 때 유용합니다.

`--no-column` 플래그를 사용하면 열 처리 기능을 비활성화합니다. 이는 열 처리 기능이 필요하지 않을 때 유용합니다.

`--no-row` 플래그를 사용하면 행 처리 기능을 비활성화합니다. 이는 행 처리 기능이 필요하지 않을 때 유용합니다.

`--no-cell` 플래그를 사용하면 셀 처리 기능을 비활성화합니다. 이는 셀 처리 기능이 필요하지 않을 때 유용합니다.

`--no-key` 플래그를 사용하면 키 처리 기능을 비활성화합니다. 이는 키 처리 기능이 필요하지 않을 때 유용합니다.

`--no-index` 플래그를 사용하면 인덱스 처리 기능을 비활성화합니다. 이는 인덱스 처리 기능이 필요하지 않을 때 유용합니다.

`--no-pointer` 플래그를 사용하면 포인터 처리 기능을 비활성화합니다. 이는 포인터 처리 기능이 필요하지 않을 때 유용합니다.

`--no-reference` 플래그를 사용하면 참조 처리 기능을 비활성화합니다. 이는 참조 처리 기능이 필요하지 않을 때 유용합니다.

`--no-object` 플래그를 사용하면 객체 처리 기능을 비활성화합니다. 이는 객체 처리 기능이 필요하지 않을 때 유용합니다.

`--no-class` 플래그를 사용하면 클래스 처리 기능을 비활성화합니다. 이는 클래스 처리 기능이 필요하지 않을 때 유용합니다.

`--no-struct` 플래그를 사용하면 구조체 처리 기능을 비활성화합니다. 이는 구조체 처리 기능이 필요하지 않을 때 유용합니다.

`--no-union` 플래그를 사용하면 공용체 처리 기능을 비활성화합니다. 이는 공용체 처리 기능이 필요하지 않을 때 유용합니다.

`--no-enum` 플래그를 사용하면 열거형 처리 기능을 비활성화합니다. 이는 열거형 처리 기능이 필요하지 않을 때 유용합니다.

`--no-interface` 플래그를 사용하면 인터페이스 처리 기능을 비활성화합니다. 이는 인터페이스 처리 기능이 필요하지 않을 때 유용합니다.

`--no-module` 플래그를 사용하면 모듈 처리 기능을 비활성화합니다. 이는 모듈 처리 기능이 필요하지 않을 때 유용합니다.

`--no-package` 플래그를 사용하면 패키지 처리 기능을 비활성화합니다. 이는 패키지 처리 기능이 필요하지 않을 때 유용합니다.

`--no-library` 플래그를 사용하면 라이브러리 처리 기능을 비활성화합니다. 이는 라이브러리 처리 기능이 필요하지 않을 때 유용합니다.

`--no-framework` 플래그를 사용하면 프레임워크 처리 기능을 비활성화합니다. 이는 프레임워크 처리 기능이 필요하지 않을 때 유용합니다.

`--no-platform` 플래그를 사용하면 플랫폼 처리 기능을 비```
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. 파이프라인 생성: 사용할 Wing과 Feather를 구성합니다.
5. 실행: 파이프라인을 실행하고 상관관계 결과를 확인합니다.
6. 분석: 결과 뷰어를 사용하여 시간적 관계를 탐색합니다.

📚 상관관계 엔진 문서

• 상관관계 엔진 개요 — 아키텍처 다이어그램이 포함된 시스템 개요
• 엔진 문서 — 이중 엔진 아키텍처, 엔진 선택, 성능 최적화
• 아키텍처 — 컴포넌트 통합 및 데이터 흐름
• Feather 문서 — 데이터 정규화 시스템
• Wings 문서 — 상관관계 규칙
• 파이프라인 문서 — 워크플로 오케스트레이션
• 아티팩트 추가 — 엔진에 새 파서를 연결하는 워크플로
• 표준 필드 레지스트리 — 두 엔진과 Eye가 로드하는 표준 열 이름 동의어
• 기여 가이드 — 엔진에 기여하는 방법
• 빠른 링크: 엔진 선택 · 문제 해결 · 성능 최적화

👁️ Eye — 포렌식 AI 어시스턴트

강력한 어시스턴트이지 대체재가 아닙니다. Eye는 조사자의 가설을 자동화하고 검증합니다 — 결코 당신을 대신해 판단을 내리지 않습니다.

Eye는 Crow-Eye에 내장된 포렌식 AI 어시스턴트입니다. Windows 아티팩트에 대한 실제 지식 베이스를 기반으로 하는 숙련된 포렌식 조사자입니다. Prefetch, MFT, 레지스트리, 이벤트 로그, AmCache, ShimCache, SRUM 등을 사례에서 조회, 상관분석, 문서화할 수 있는 자연어 인터페이스를 제공하며, 수행한 작업에 대한 감사 가능하고 변조 방지된 기록을 유지합니다. Eye는 Crow-Eye의 "기기 외부로 전송되는 데이터 0ms" 개인정보 보호 원칙에 따라 자체 하드웨어에서(완전히 air-gapped 포함) 완전히 실행할 수 있습니다. 전체 아키텍처: eye/README.md.

Eye는 대화형 질문("C:\Temp에서 22:00 이후 실행된 것을 보여줘")을 실제 포렌식 작업으로 전환합니다. 접근 방식을 계획하고, 관련 아티팩트 지식을 검색하고, 사례 데이터베이스에 대해 SQL 및 교차 아티팩트 검색을 실행하고, 검증된 답변을 종합합니다. 모든 답변은 동시에 두 곳에서 생성됩니다 — 사용자를 위한 채팅 응답과 라이브 보고서 작업 공간에 기록되는 구조화된 블록으로, 조사가 진행됨에 따라 문서가 자동으로 구축됩니다.

Ghassan Elsman 프로토콜 (GEP)

Eye가 수행하는 모든 작업은 Ghassan Elsman 프로토콜 (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가 파이프라인 실행 — 의도 감지 → 지식 검색 → 도구 실행 → 종합.
4. 이중 출력 수신 — 직접적인 채팅 답변 및 라이브 보고서의 새 블록.
5. 게이트 작업 승인 — 내보내기 및 기타 중요한 단계는 승인을 기다립니다.

switch_model 도구로 런타임에 모델을 변경할 수 있습니다. 전환은 동일한 백엔드로 제한되므로 증거가 선택한 공급자와 다른 공급자로 조용히 전송되지 않습니다.

LLM 사고 과정 추적

Eye는 어떻게 결론에 도달했는지 확인하고 나중에 증명할 수 있도록 설계되었습니다. Eye가 작업하는 동안 실시간으로 구조화된 ThinkingStep 업데이트를 UI에 스트리밍합니다. 각 단계에는 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(내보내기는 인간 승인 필요).

작성 도구(관리 대상 — 상관관계 Wing 및 의미론적 매핑 구축 참조): correlation_create_wing, correlation_edit_wing, correlation_create_semantic_mapping, correlation_edit_semantic_mapping. 도구 호출은 활성 백엔드가 기대하는 형식으로 변환됩니다 — 클라우드 API 및 로컬 서버의 경우 네이티브 함수 호출, CLI 에이전트의 경우 XML <tool_call> 래퍼.

상관관계 Wing 및 의미론적 매핑 구축

Eye는 상관관계 엔진을 조회할 뿐만 아니라 확장하는 데도 도움을 줄 수 있습니다. Eye가 반복적인 교차 아티팩트 패턴을 발견하면 새 Wing(상관관계 규칙)과 의미론적 매핑(기술-인간 번역)을 제안할 수 있습니다. 이는 관리되는 작성입니다. Eye가 제안하고, 분석가가 저장된 아티팩트를 검토하며, 모든 변경은 정당화되고 증거로 뒷받침됩니다.

Wing은 시간 창과 최소 일치 임계값 내에서 Feather를 연결하여 주장을 증명합니다:

의미론적 매핑은 원시 기술 값을 사람이 읽을 수 있는 의미로 변환합니다(예: 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. 요약 단계 (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가 LLM에 보내는 모든 페이로드는 봉인됩니다: 정확한 바이트의 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가 작성하는 모든 Wing 또는 매핑에는 포렌식 reason과 가 포함되어야 합니다. Eye 외부에서 작성된 규칙은 읽기 전용이며 조용히 다시 작성될 수 없습니다.

📖 전체 Eye 아키텍처: eye/README.md.

📖 Eye-Describe — 바이트 수준 아티팩트 지식 베이스

🔗 Eye-Describe 탐색 → crow-eye.com/eye-describe

역사적으로 조사자들은 기본 아티팩트가 어떻게 동작하는지 또는 도구가 이를 어떻게 파싱했는지 이해하지 못한 채 포렌식 도구를 신뢰하는 함정에 빠졌습니다. 오늘날의 위험은 단순히 *"도구"*를 *"AI"*로 대체하는 것입니다. AI는 완벽한 기술적 정확성으로 레코드를 파싱하면서도 잘못된 컨텍스트에 배치할 수 있습니다 — 증거의 전체 의미를 바꿔버립니다.

Eye-Describe는 인간과 모델 모두 추측할 필요가 없도록 존재합니다. Windows 아티팩트의 원시 바이너리 구조에 대한 대화형 바이트 수준 참조이며, 동시에 두 가지 역할을 수행합니다:

AI 계층을 문서화된 아티팩트 동작에 고정함으로써 Crow-Eye는 모델을 신뢰하라고 요구하지 않습니다 — 모델이 원시 포렌식을 존중하도록 제약하는 것입니다.

도구 신뢰를 AI 신뢰로 대체하지 마세요. 데이터를 이해하세요.

🧪 품질 및 검증

포렌식 도구는 출력이 방어 가능할 때만 유용합니다. Crow-Eye의 정확성 작업은 의도적으로 투명하게 공개됩니다:- 회귀 테스트 스위트. Correlation Engine은 타임스탬프 파싱, ID 정규화, 다중 타임스탬프 팬아웃, writer 계약, Eye 작성(쓰기 측 GEP 거버넌스), 표준 필드 레지스트리를 다루는 pytest 스위트로 잠겨 있습니다. UBA 엔진은 실제 사례에 대한 종단 간 실행을 포함한 자체 스위트를 제공합니다.

• 검증 하네스. 통합 하네스는 실제 약 70만 개 레코드의 Windows 사례에서 두 엔진 모두에 대해 7개의 기본 wings를 모두 실행합니다.
• 공개된 결함 이력. 정확성 회귀와 그 측정된 영향은 RELEASE_NOTES.md에 공개적으로 문서화되어 있습니다 — 수정으로 인해 레코드 수가 수십 배로 변경된 사례를 포함합니다. 무엇이, 언제 잘못되었는지 아는 것은 결과를 방어 가능하게 만드는 요소의 일부입니다.
• 검증 가능한 증거 회계. 모든 레코드는 매치 또는 명명된 드롭 버킷에 들어가며, 창별 드롭 원장은 "남은 증거 없음"을 맹목적으로 믿는 대신 로그에서 확인할 수 있게 합니다.
• 변조 방지 로그. verify_chain()은 Narrative Map 감사 로그와 Evidence Seal 체인을 다시 탐색하여 수정(사람이 읽을 수 있는 필드 포함)을 감지합니다.

🔬 연구 플랫폼

Crow-Eye는 단순한 소프트웨어 그 이상입니다 — Windows 포렌식 분야 전체를 가속화하는 오픈 연구 플랫폼입니다. 이 프로젝트는 다음에 중점을 둡니다:

• 내부 아티팩트 구조에 대한 상세 문서 게시.
• 상관관계 로직 및 방법론 공유.
• 동료 검토, 투명성, 학술 협업 지원.
• 포렌식 커뮤니티의 집단 지식에 기여.

🛠️ 기술 참고 사항

• 레지스트리 파싱에는 완전한 레지스트리 하이브 파일이 필요합니다.
• 일부 아티팩트는 Windows 파일 잠금 메커니즘으로 인해 특별한 처리가 필요합니다 (사용자 정의 레지스트리 / 잠긴 파일 참조).
• LNK 및 Jump List 파싱은 Crow-Eye 자체 전용 파서가 처리합니다.

📸 스크린샷

Crow-Eye의 인터페이스 및 분석 뷰 모음입니다.

🎥 데모 비디오:

🚧 로드맵

계획 및 진행 중인 작업 (출시된 변경 사항은 RELEASE_NOTES.md 참조):

• 📊 고급 GUI 뷰 및 보고서 — 더 풍부한 시각화 및 보고.
• 🔄 향상된 검색 대화상자 — 자연어 지원을 포함한 고급 필터링.
• 🎯 향상된 의미 매핑 — 모든 아티팩트 유형에 걸친 포괄적인 필드 매핑.
• 📈 고급 상관관계 점수화 — 정교하고 설명 가능한 신뢰도 점수화.
• ⚡ 병렬 상관관계 — 대규모 워크로드에 기본 활성화되는 프로세스 풀 디스패치.

아이디어가 있거나 아티팩트를 추가하고 싶으신가요? 이슈 열기 또는 기여를 참조하세요.

📚 문서

• TECHNICAL_DOCUMENTATION.md — 아키텍처, 구성 요소 및 개발 가이드.
• RELEASE_NOTES.md — 각 릴리스의 새로운 기능 (UBA, Narrative Map, 클라우드 Eye 백엔드, 사례 관리 강화, …).
• Correlation Engine 문서 — 개요, 엔진, feathers, wings, 파이프라인.
• 타임라인 아키텍처 — 타임라인 모듈 내부 구조.
• Eye 아키텍처 및 GEP 표준 — AI 어시스턴트와 이를 규율하는 프로토콜.

🤝 기여

Crow-Eye는 오픈 연구 플랫폼으로 구축되었으며, 새로운 파서, 상관관계 규칙, 문서 및 아티팩트 연구 등 기여를 환영합니다.

• 일반 기여: CONTRIBUTING.md
• Correlation Engine (우선 영역): correlation_engine/CONTRIBUTING.md
• 연락처: [email protected] · 또는 이슈 / 풀 리퀘스트를 열어주세요.

🌐 웹사이트 및 커뮤니티

• 🌍 공식 웹사이트: crow-eye.com — 리소스, 문서 및 다운로드.
• 💬 Discord: Crow-Eye Discord 참여 — 직접 지원, 아티팩트 연구 및 릴리스 공지.

📄 라이선스

Crow-Eye는 GNU General Public License v3.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**이 만들고 유지 관리합니다.