Large EDR Prompt

EDR.md

EDR Reverse Engineering Workspace

Universal workflow for complete reverse engineering of endpoint detection and response (EDR) products. Every EDR dropped into this workspace gets the same systematic treatment: full decompilation, rule extraction, ML model extraction, vulnerability analysis, detection gap analysis, and tradecraft development.

Standardized Folder Structure

When given a new EDR product, create this structure under <product>/:

<product>/
├── CLAUDE.md                    # Product-specific notes, key addresses, build info
├── extracted/                   # Unpacked installer contents
│   ├── binaries/                # All extracted EXEs, DLLs, SYS files
│   ├── configs/                 # Configuration files, manifests, INIs
│   └── installers/              # MSI, CAB, bootstrapper artifacts
├── ghidra_output/               # Decompilation results (one set per binary)
│   ├── <binary>_decompiled.c    # Full pseudocode
│   ├── <binary>_functions.json  # Function listing with addresses
│   ├── <binary>_strings.txt     # Extracted strings
│   ├── <binary>_summary.txt     # Binary overview (arch, imports, exports)
│   └── <binary>_interesting.txt # Flagged findings (crypto, hardcoded keys, etc.)
├── rules/                       # Extracted detection rules
│   ├── yara/                    # YARA rules (compiled and decompiled)
│   ├── lua/                     # Lua behavioral scripts
│   ├── signatures/              # Vendor signature databases, pattern files
│   ├── behavioral/              # Behavioral IOA/IOC rule definitions
│   ├── exclusions/              # Hardcoded exclusions, allowlists, exemptions
│   └── README.md                # Rule inventory with counts and coverage
├── models/                      # Extracted ML models
│   ├── weights/                 # Raw model weights, decision trees, TFLite files
│   ├── features/                # Feature extraction logic (what attributes are scored)
│   ├── configs/                 # Model configs, thresholds, scoring parameters
│   ├── scanner/                 # Standalone scanner reimplementing the ML pipeline
│   └── README.md                # Model inventory (type, size, tree count, accuracy)
├── analysis/                    # Write-ups (numbered for reading order)
│   ├── 00_ARCHITECTURE.md
│   ├── 01_VULNERABILITY_ANALYSIS.md
│   ├── 02_DETECTION_GAP_ANALYSIS.md
│   ├── 03_RULE_EXTRACTION.md
│   ├── 04_ML_EXTRACTION.md
│   ├── 05_PREFILTER_EXCLUSION_ANALYSIS.md
│   ├── 06_PROTOCOL_COMMS_ANALYSIS.md
│   ├── 07_TRADECRAFT.md
│   └── 08_OBSERVATIONS.md
├── pocs/                        # Proof-of-concept code
│   ├── vulns/                   # Vulnerability PoCs (LPE, RCE, DoS)
│   ├── evasion/                 # Detection evasion PoCs
│   ├── ml_bypass/               # ML model bypass PoCs
│   └── combined/                # Multi-technique chains
├── probes/                      # Live environment interaction scripts
│   ├── protocol/                # Network protocol probes (HTTP, MQTT, gRPC, pipes)
│   ├── fuzzing/                 # Input fuzzing scripts (pipe, config, IPC)
│   ├── enumeration/             # System enumeration (pipes, procs, ports, ETW)
│   └── README.md                # Probe inventory and usage instructions
├── reports/                     # Executive deliverables
│   ├── technical_report.md      # Full technical write-up for stakeholders
│   ├── advisory.md              # Vulnerability disclosure / advisory format
│   └── slides.html              # Presentation deck (reveal.js or similar)
└── tools/                       # Product-specific utilities
    ├── decrypt.py               # Asset/config decryption (if encrypted)
    ├── download.py              # Signature/update downloader
    └── scanner.py               # Detection pipeline reimplementation

Empty subdirectory policy: If any subdirectory under rules/, models/, pocs/, or probes/ is intentionally empty because the product architecture doesn't use that category, add a README.md explaining why (e.g., "X uses cloud-based IOAs — no local YARA rules stored on disk"). Empty directories with no explanation look like incomplete work.

Phase 0: Setup and Extraction

Goal: Unpack everything. Get every binary, config, and asset file on disk.

1. Identify installer type — WiX Burn, MSI, NSIS, InnoSetup, self-extracting CAB, custom
2. Extract all layers:
   • Outer bootstrapper → inner MSI/CAB
   • MSI → individual files (use msiextract or lessmsi)
   • CAB → payload files
   • Any nested archives (ZIP, 7z, CAB within CAB)
3. Inventory everything — catalog every file with size, type, and SHA256
4. Identify encrypted assets — look for magic bytes, XOR patterns, custom encryption
   • Check for hardcoded keys in the main binary (search for key-length byte patterns)
   • Write decrypt.py if assets are encrypted
5. Output: extracted/ fully populated, file inventory in product CLAUDE.md

Phase 1: Complete Decompilation

Goal: Full pseudocode for EVERY binary. No exceptions. Use both decompilation methods for complete coverage.

Workflow: Headless First, MCP Second

1. Headless FIRST — batch-decompile every binary to produce the 5 standardized output files. This is the coverage pass. Every binary must have a _decompiled.c pseudocode file when done.
2. MCP SECOND — use interactive Ghidra MCP for targeted follow-up on interesting functions found in headless output. Place targeted decompilation files in ghidra_output/targeted/.

Ghidra Headless (Batch — Coverage Pass)

Use headless analysis for bulk decompilation of every binary. Produces the ghidra_output/ directory. The _decompiled.c pseudocode file is the mandatory deliverable — metadata files (strings, functions, imports) without actual decompiled C code do not count as "decompiled." If a binary fails headless decompilation, note it in the product CLAUDE.md and decompile it via MCP instead.

Ghidra MCP (Interactive — Targeted Analysis)

Use the Ghidra MCP server for targeted, interactive analysis AFTER headless coverage is complete. Best for:

• Following specific code paths and cross-references
• Renaming functions and variables as you understand them
• Tracing detection logic through call graphs
• Analyzing specific structures and data types

Workflow:
1. open_binary → load the target
2. triage_binary → get overview (sections, imports, exports, strings summary)
3. get_functions → enumerate all functions
4. decompile_function → work through functions systematically
5. get_xrefs_to / get_xrefs_from → trace call graphs
6. get_strings → extract all strings
7. rename_function / rename_variable → annotate as you go
8. set_comment → document findings inline

Place MCP-produced targeted analysis files in ghidra_output/targeted/ to distinguish them from headless batch output.

# Standard headless decompilation (adjust heap for binary size)
/opt/ghidra_12.0.3_PUBLIC/support/analyzeHeadless \
  /tmp/ghidra_project_<product> ProjectName \
  -import <binary> \
  -postScript DecompileAll.py \
  -scriptPath /tmp \
  -deleteProject -overwrite \
  -max-cpu $(nproc) \
  2>&1 | tail -50

# For large binaries (>20MB), increase heap:
MAXMEM=12G /opt/ghidra_12.0.3_PUBLIC/support/analyzeHeadless ...

Decompilation Targets (Priority Order)

1. Main agent/sensor binary — the core process (largest EXE or DLL)
2. Kernel drivers (.sys) — minifilters, ELAM, network monitors, device control
3. ML/AI DLLs — static analysis, behavioral analysis, language prediction
4. Detection engine DLLs — signature matching, YARA, behavioral engines
5. Communication DLLs — cloud API, telemetry, update protocol
6. Hooking/injection DLLs — usermode hooks, AMSI providers, .NET instrumentation
7. Helper services — scanner processes, remediation tools, UI components
8. Support DLLs — everything else

.NET Assemblies

For .NET binaries, use ilspycmd or dotPeek instead of Ghidra:

ilspycmd -p -o decompiled/<assembly_name>/ <assembly>.dll

Output Standard

Every binary produces these files in ghidra_output/. Two layout formats are acceptable:

Flat layout (default from headless scripts):

• <name>_decompiled.c — full pseudocode (MANDATORY — this is the primary deliverable)
• <name>_functions.json — [{"name": "...", "address": "0x...", "size": N}]
• <name>_strings.txt — all extracted strings (ASCII + wide)
• <name>_summary.txt — arch, compiler, imports, exports, sections, mitigations
• <name>_interesting.txt — flagged: crypto constants, hardcoded IPs/domains, registry paths, named pipes, encryption keys, format strings with %s/%n

Directory-per-binary layout (acceptable for large binary counts):

ghidra_output/<name>/
├── pseudocode.c          # MANDATORY — full decompiled pseudocode
├── functions.json        # Function listing with addresses
├── strings.txt           # Extracted strings
├── summary.txt           # Binary overview
├── interesting.txt       # Flagged findings
├── imports.txt           # Import table (optional bonus)
├── exports.txt           # Export table (optional bonus)
└── sections.txt          # Section layout (optional bonus)

Non-negotiable: Every directory or file set MUST include the decompiled pseudocode (.c file). Directories that contain only metadata files (strings, functions, imports) without pseudocode are incomplete and must be re-run.

Phase 2: Analysis Write-ups

Each write-up follows the same structure. Produce ALL of them for every product.

00_ARCHITECTURE.md

Map the complete system before diving into specifics.

Required sections:

• Executive summary (product name, version, build date, platform)
• Component inventory table (every binary with size, purpose, privilege level)
• Process architecture (what runs as SYSTEM, what as user, parent-child relationships)
• IPC mechanisms (named pipes, RPC, COM, shared memory, IOCTL, registry, MQTT, etc.)
• Kernel components (minifilter altitudes, ELAM, callout drivers, ETW providers)
• Persistence mechanisms (services, drivers, scheduled tasks, registry)
• Self-protection (PPL, driver signing, tamper protection, anti-debug)
• Update/communication architecture (endpoints, protocols, certificate pinning)
• Third-party libraries (with versions — OpenSSL, Boost, Protobuf, RocksDB, etc.)
• Dependency graph (what loads what, in what order)

01_VULNERABILITY_ANALYSIS.md

Systematic vulnerability assessment of every attack surface.

Required sections:

• Attack surface enumeration (every input: files, network, IPC, registry, user input)
• Per-component vulnerability assessment with severity ratings
• Confirmed findings table (ID, title, severity, CVSS, status, type)
• For each finding:
  • Root cause with decompiled code reference (file:function:offset)
  • Reproduction steps
  • Impact (what an attacker gains)
  • Affected versions
  • Remediation recommendation
• Unvalidated/potential findings (things that need live testing)
• Attack chains (how findings combine for escalation)
• Security posture summary (mitigations present: DEP, ASLR, CFG, stack cookies, PPL, signing)

What to look for:

• NULL DACLs on kernel objects, pipes, sections
• TOCTOU races in file operations (especially SYSTEM-level scanners)
• DLL hijacking (missing DLLs, unquoted paths, writable directories)
• Buffer overflows in parsers (PE, script, archive, signature)
• Signature verification bypasses (CN-only checks, missing chain validation)
• Privilege escalation via junction/symlink attacks on scan directories
• Integer overflows in size calculations
• Format string vulnerabilities
• Command injection via config files or registry values

02_DETECTION_GAP_ANALYSIS.md

Map what the EDR CAN and CANNOT detect, referenced against MITRE ATT&CK.

Required sections:

• MITRE ATT&CK coverage matrix (tactic × technique, with COVERED/PARTIAL/GAP)
• Gap inventory table (technique, severity, evidence from decompiled code)
• Per-tactic gap analysis:
  • Initial Access gaps
  • Execution gaps (what script types, what execution methods)
  • Persistence gaps (what registry keys, what scheduled task variants)
  • Privilege Escalation gaps
  • Defense Evasion gaps (what evasion techniques are NOT detected)
  • Credential Access gaps (what credential theft methods)
  • Discovery gaps
  • Lateral Movement gaps
  • Collection gaps
  • C2 gaps (what protocols, what channels)
  • Exfiltration gaps
  • Impact gaps
• Architectural limitations (what the sensor physically cannot see)
• Comparison with previous EDR analyses in this workspace

Evidence standard: Every gap claim must reference decompiled code showing the absence of detection, or a specific threshold/condition that enables bypass.

03_RULE_EXTRACTION.md

Document every detection rule extracted and placed in rules/.

Required sections:

• Rule inventory (total count by type: YARA, Lua, behavioral, signature, etc.)
• Extraction methodology (how rules were found, decrypted, decompiled)
• Rule format documentation (how the vendor structures rules)
• Coverage analysis (what each rule set covers)
• Rule quality assessment (false positive potential, evasion difficulty)
• Cross-reference to gap analysis (which gaps have no rules)

Extraction targets:

• YARA rules (compiled → decompile with yarac or extract rule names)
• Lua/scripting rules (behavioral detection scripts)
• Signature patterns (hash-based, string-based, regex-based)
• Behavioral rules (IOA/IOC definitions, process behavior patterns)
• Network rules (IP/domain blocklists, protocol signatures)
• Driver/vulnerability rules (known-vulnerable driver lists)
• Exclusion rules (what is explicitly NOT detected — allowlists, exemptions)

04_ML_EXTRACTION.md

Document every ML model and scripted detection engine extracted and placed in models/.

Not all EDRs use traditional ML. Some use scripted engines (Lua VMs, JavaScript runtimes, embedded interpreters) that function as behavioral classifiers. Both types require full extraction.

Required sections:

• Model/engine inventory (name, type, size, purpose, location in binary)
• Architecture type:
  • Traditional ML: decision trees, neural networks, gradient boosted, TFLite, XGBoost, Bonsai
  • Scripted engines: Lua VM, JavaScript runtime, Python interpreter, custom DSL
  • Hybrid: ML models invoked from scripted decision logic
• Feature extraction (what file/behavior attributes are scored, with code references)
• Scoring thresholds (clean/suspicious/malicious boundaries)
• For traditional ML: tree/node statistics (count, depth, leaf distribution)
• For scripted engines: interpreter architecture, rule loading mechanism, event matching logic
• Training data indicators (what the model was trained to detect)
• Known blind spots (features NOT extracted, file types NOT covered, event types NOT monitored)
• Bypass techniques (how to manipulate features to flip verdicts, or evade scripted rules)
• Reimplementation status (standalone scanner in models/scanner/)

What to extract — Traditional ML:

• Decision tree weights and structure (serialize to JSON)
• Feature extraction functions (decompile the feature vector builder)
• Scoring/threshold logic (decompile the verdict function)
• Model metadata (version, training date, feature names if available)
• Any TFLite, ONNX, or custom model files embedded in binaries

What to extract — Scripted Engines:

• All script files (Lua, JS, etc.) — decrypted and saved as readable source in models/weights/
• Engine loader/interpreter (how scripts are loaded, sandboxed, and executed)
• Event matching primitives (what the scripts can observe — process events, file ops, network, registry)
• Rule expression format (how detection conditions are structured)
• Context/state management (how the engine tracks process trees, sessions, or sequences)

05_PREFILTER_EXCLUSION_ANALYSIS.md

Document everything the EDR silently ignores BEFORE detection runs.

Required sections:

• Prefilter inventory (every decision point that drops events before analysis)
• Exclusion types:
  • Path-based exclusions (trusted directories, filename patterns)
  • Process-based exclusions (trusted process names, publisher certificates)
  • File-based exclusions (size limits, extension filters, hash allowlists)
  • Certificate-based trust (what signatures bypass scanning)
  • Configuration kill switches (registry keys, config flags that disable features)
  • Cloud/connectivity dependencies (what happens when cloud is unreachable)
  • Load shedding (event dropping under volume pressure)
• For each exclusion:
  • Decompiled code reference
  • Bypass technique
  • Severity rating
• Hardcoded values (magic numbers, thresholds, timeout values)
• Exempt process lists (exact binary names/paths that get special treatment)

06_PROTOCOL_COMMS_ANALYSIS.md

Document all network communication for attack surface and intelligence value.

Required sections:

• Endpoint inventory (every URL, domain, IP the product contacts)
• Protocol analysis (HTTP/S, MQTT, WebSocket, Protobuf, Bond, custom binary)
• Authentication mechanisms (API keys, certificates, JWT, HMAC)
• Certificate pinning analysis (what's pinned, can it be bypassed)
• Telemetry format (what data is sent to the cloud, serialization format)
• Update protocol (how signatures/engines are downloaded, verification)
• Command channel (how the management server sends commands to the agent)
• Serialization formats (Protobuf schemas, Bond schemas, custom formats)
• Hardcoded credentials or keys (API keys, encryption keys, certificates)
• Network-based attack surface (what can a network attacker manipulate)

07_TRADECRAFT.md

Actionable red team guide synthesized from ALL other analyses.

Required sections:

• Quick reference table (technique → bypass → one-liner)
• Per-category evasion techniques:
  • Process execution evasion
  • Credential access evasion
  • Lateral movement evasion
  • Persistence evasion
  • Script execution evasion
  • Network/C2 evasion
  • File operation evasion
• Sensor blinding techniques (what makes the sensor lose visibility)
• Threshold manipulation (staying under detection thresholds)
• Timing windows (when the sensor is weakest)
• Configuration tampering (if admin access is available)
• Tool modification guides (what to change in common tools: Impacket, Rubeus, Mimikatz, Cobalt Strike, Sliver, etc.)
• Combined attack chains (multi-technique sequences)
• Detection priority ranking (what triggers fastest alert vs what is ignored)

08_OBSERVATIONS.md

Everything that doesn't fit elsewhere but matters.

Required sections:

• Code quality observations (memory safety, error handling, crash potential)
• Interesting implementation details (unusual algorithms, clever tricks)
• Third-party component risks (outdated libraries, known CVEs)
• Comparison with other analyzed EDRs (relative strengths/weaknesses)
• Recommended further research (what needs live testing, fuzzing targets)
• Artifacts of interest (debug strings, developer comments, internal tool names)
• Version-specific notes (what changed from previous versions if known)

Phase 3: Rule and Model Extraction

Rules (rules/)

Goal: Every rule must be human-readable. Compiled/encrypted rules are extracted AND converted to readable source. Binary blobs alone are not acceptable.

1. Find all rule storage — search strings for YARA, Lua, "rule", "signature", "pattern", "detection", "behavioral"
2. Decrypt if needed — check for XOR, AES, custom encryption on rule files
   • Look for: hardcoded keys in .rdata, magic byte headers, entropy anomalies in data sections
3. Extract to readable source:
   • Lua scripts → save as .lua files, one per rule, preserve original filenames
   • YARA compiled → decompile to .yar source (extract rule names at minimum)
   • Behavioral rules → convert to readable format (JSON, YAML, or pseudocode)
   • Signature patterns → parse vendor format into documented structure
   • Driver blocklists → extract to JSON with driver name, hash, action
4. Preserve rule metadata — rule names, severity levels, MITRE mappings, enable/disable flags
5. Document in rules/README.md:
   • Total counts by type
   • Coverage summary (what attack categories each rule set covers)
   • Format documentation (how the vendor structures and stores rules)
   • Encryption/obfuscation details (key, algorithm, location)
   • Version identifiers (rule pack version, update date if available)
6. Cross-reference with gap analysis — identify techniques with no corresponding rules
7. Identify exclusion rules separately — allowlists, exemptions, GROUP_OK returns, trusted-process lists go in rules/exclusions/ with full documentation of what each exclusion permits

Models (models/)

Goal: Every model and scripted engine must be deserializable and independently executable. Extract weights, features, and thresholds so the ML pipeline can be run standalone outside the EDR. For scripted engines, extract all scripts as readable source so behavioral detection logic can be studied and tested independently.

1. Find embedded models and scripted engines — search for:
   • TFLite headers (\x18\x00\x00\x00TFL3)
   • Large .rdata sections with floating-point arrays
   • Serialized tree structures (Bonsai, XGBoost, LightGBM, gradient boosted trees)
   • Custom binary formats (look for tree node counts, depth values, leaf arrays)
   • Named model files in extracted assets (.tflite, .onnx, .bin, .model)
   • Embedded Lua VMs (luaL_newstate, lua_pcall, .lua file references)
   • Embedded JavaScript/Python interpreters
   • Encrypted script containers (entropy anomalies in data sections, XOR patterns)
   • Custom DSL interpreters (rule expression parsers, pattern matchers)
2. Extract to portable format:
   • Decision trees → JSON with node structure (feature_index, threshold, left/right children, leaf values)
   • Neural networks → TFLite or ONNX files, or weight matrices as NumPy arrays
   • Feature vectors → document every attribute extracted (PE headers, entropy, imports, strings, etc.)
   • Scripted engines → readable source files (.lua, .js, etc.) in models/weights/
3. Decompile feature extraction — the function that builds the feature vector from a file (traditional ML) or the event matching primitives available to scripts (scripted engines). Produce pseudocode showing exactly what attributes are measured or observable.
4. Map scoring thresholds — decompile verdict/classification logic:
   • Score ranges for clean/PUP/suspicious/malicious
   • Aggregation method (sum, average, weighted vote, confidence)
   • Cloud escalation triggers (when local ML defers to cloud)
   • For scripted engines: rule severity mapping, alert vs block thresholds
5. Build standalone scanner in models/scanner/:
   • Python reimplementation of the full ML pipeline or scripted engine
   • Load extracted weights/scripts, extract features from test files, produce scores
   • Validate against known samples to confirm accuracy
   • Include evasion testing capability (mutate features, measure score changes)
6. Document in models/README.md:
   • Model/engine inventory table (name, type, size, tree/layer count or script count, feature dimensions)
   • Feature list with descriptions (what each feature index measures, or what events scripts observe)
   • Threshold table (score → verdict mapping)
   • Known blind spots (features NOT extracted, file types NOT modeled, events NOT monitored)
   • Bypass difficulty rating per model/engine

Phase 4: Proof-of-Concept Development

Write PoCs for findings and gaps, prioritized by severity:

• CRITICAL/HIGH findings: PoC required — demonstrate the vulnerability or bypass
• MEDIUM findings: PoC recommended — write if feasible from static analysis alone
• LOW findings / detection gaps: Document in pocs/README.md with reproduction approach, mark as "static analysis only" or "requires live environment"

Track coverage in pocs/README.md — list every finding ID from 01_VULNERABILITY_ANALYSIS.md and every significant gap from 02_DETECTION_GAP_ANALYSIS.md with its PoC status (COMPLETE, NEEDS_LIVE_ENV, NOT_STARTED).

PoC standards:

• Self-contained (no external dependencies beyond standard tooling)
• Documented (header comment with finding ID, description, expected result)
• Safe (no actual malicious payload — demonstrate the bypass, not the attack)
• Categorized in pocs/ subdirectories by type

Phase 4b: Live Probes and Testing

When a live environment is available (Ludus range, VM, physical install), build interaction scripts in probes/:

• Protocol probes (probes/protocol/) — test network endpoints, named pipes, IPC channels discovered during RE
• Fuzzing scripts (probes/fuzzing/) — fuzz parsers, pipe commands, config inputs
• Enumeration scripts (probes/enumeration/) — discover runtime state (open pipes, listening ports, loaded drivers, ETW providers, running processes)

These probes validate static analysis findings and often reveal behaviors not visible in decompiled code (timing, error handling, cloud fallback). Place results and captured artifacts alongside the scripts.

Phase 4c: Executive Deliverables

Produce stakeholder-ready outputs in reports/:

• technical_report.md — comprehensive write-up suitable for a security team or vendor disclosure
• advisory.md — vulnerability advisory format (affected versions, CVSS, remediation)
• slides.html — presentation deck summarizing key findings (reveal.js or similar)

These synthesize from the 9 analysis documents but are formatted for different audiences.

Phase 5: Product-Specific Tools

Build utilities as needed for each product:

Tool	When to Build	Template From
decrypt.py	Assets are encrypted
download.py	Signatures available online
scanner.py	ML pipeline can be reimplemented
parser.py	Custom signature format

Shared Tools

Reusable utilities live in /home/justin/vibe/tools/:

Tool	Purpose
ghidra_headless/decompile_all.sh	Decompile a single binary → 5 standardized output files
ghidra_headless/decompile_product.sh	Batch decompile ALL binaries in a product's extracted/ dir

Product-Specific Tools

During analysis, build tools specific to the EDR being reversed and place them in <product>/tools/. These emerge organically from the RE work — every product has unique protocols, formats, and encryption.

Examples from previous work:

Attempt to build tools in these categories if possible — not every EDR will need all of them, but check for each during analysis:

1. Rule extractor/decryptor — If detection rules are encrypted, packed, or in a proprietary format, build a tool that takes raw assets and produces human-readable rules (Lua scripts, YARA source, behavioral definitions, signature patterns). Every EDR we've analyzed has had some form of this. (Highest priority — unlocks Phase 3.)

2. Signature/rule downloader — Almost every EDR has an update server or CDN for signature databases, pattern files, engine updates, or rule packs. Find the update URLs (hardcoded in binaries, config files, or registry), reverse the update protocol (auth, versioning, delta vs full), and build a downloader that pulls the latest detection content. This is high value — it lets us track what the vendor is detecting over time.

3. ML model scanner — If the EDR uses ML models or scripted engines for classification, build a standalone Python scanner that loads the extracted weights/scripts, extracts features from files, and produces scores. This enables evasion testing without the full EDR installed.

4. Custom format parser — If the EDR uses proprietary signature or config formats, build a parser that converts them to standard formats (JSON, YARA, etc.).

5. Cloud protocol client — If the EDR communicates with a cloud backend for reputation, telemetry, or dynamic signatures, build a client that can query it directly. (Lowest priority — requires network access and often auth tokens.)

Don't wait to be asked — if you see an update URL, a signature database, or an encrypted asset during analysis, build the tool proactively and put it in <product>/tools/.

Existing EDR Analyses

See INVENTORY.md for the product inventory with directories, versions, and key findings. Keep CLAUDE.md focused on the workflow; keep product-specific data in INVENTORY.md.

Workflow Summary

When told "here is a new EDR":

1. Create folder structure per the template above
2. Phase 0 — Extract and inventory every file
3. Phase 1 — Decompile EVERY binary (headless first for coverage, MCP second for targeted analysis, ilspycmd for .NET)
4. Phase 2 — Write all 9 analysis documents (00-08)
5. Phase 3 — Extract all rules into rules/, all models/engines into models/
6. Phase 4 — Write PoCs (prioritized by severity: CRITICAL/HIGH required, MEDIUM recommended)
7. Phase 4b — Build live probes in probes/ (when environment available)
8. Phase 4c — Produce executive deliverables in reports/
9. Phase 5 — Build product-specific tools as applicable
10. Update this workspace — add to INVENTORY.md

Quality Standards

• Every claim must cite decompiled code — function name, address, or file:line
• Every gap must have evidence — show the code path that misses the technique
• Every PoC must be tested — or clearly marked as "static analysis only"
• Pseudocode over prose — when explaining detection logic, show the simplified code
• MITRE ATT&CK IDs on everything — every technique gets its T-number
• Severity ratings on everything — CRITICAL/HIGH/MEDIUM/LOW with justification
• Compare across products — note when one EDR catches what another misses

User Preferences

• Never include "Co-Authored-By" lines in git commit messages
• Use Ghidra MCP for interactive RE, headless for batch decompilation — both required
• Complete coverage: decompile every binary, extract every rule, extract every model
• Produce all 9 analysis documents for every product, no exceptions