EDR Skill

EDR_SKILL.md

name

edr-reverse-engineering

description

Standardized workflow for reverse engineering endpoint security products, including extraction, decompilation, rule and model recovery, vulnerability analysis, detection gap analysis, proof-of-concept planning, live probes, and stakeholder reports. Use when Claude is asked to analyze an endpoint detection and response product, endpoint protection agent, security sensor, antivirus engine, or similar endpoint security package from installer artifacts, extracted binaries, live systems, or prior workspace outputs.

EDR Reverse Engineering

Use this skill to run a complete, repeatable reverse-engineering workflow for endpoint security products. Apply the same structure to every product so outputs can be compared across analyses and future work can resume without rediscovery.

Folder Structure

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

<product>/
├── AGENT.md                     # Product-specific notes, key addresses, build info
├── extracted/                   # Unpacked installer contents
│   ├── binaries/                # Extracted EXEs, DLLs, SYS files, services, agents
│   ├── configs/                 # Configuration files, manifests, INIs, policy files
│   └── installers/              # MSI, CAB, bootstrapper, package 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
│   └── <binary>_interesting.txt # Flagged findings
├── rules/                       # Extracted detection logic
│   ├── yara/                    # YARA rules, compiled or source
│   ├── lua/                     # Lua behavioral scripts
│   ├── signatures/              # Signature databases and pattern files
│   ├── behavioral/              # Behavioral IOA/IOC definitions
│   ├── exclusions/              # Allow lists, trusted paths, exemptions
│   └── README.md                # Rule inventory and coverage notes
├── models/                      # Extracted ML models and scripted engines
│   ├── weights/                 # Raw weights, trees, TFLite, ONNX, scripts
│   ├── features/                # Feature extraction logic
│   ├── configs/                 # Thresholds and scoring parameters
│   ├── scanner/                 # Standalone scoring or rule-engine reimplementation
│   └── README.md                # Model and engine inventory
├── 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
│   ├── evasion/                 # Detection evasion PoCs
│   ├── ml_bypass/               # Model bypass PoCs
│   └── combined/                # Multi-technique chains
├── probes/                      # Live environment interaction scripts
│   ├── protocol/                # Network, IPC, pipe, RPC, HTTP, gRPC probes
│   ├── fuzzing/                 # Parser, config, IPC, and protocol fuzzers
│   ├── enumeration/             # Runtime state enumeration
│   └── README.md                # Probe inventory and usage instructions
├── reports/                     # Stakeholder deliverables
│   ├── technical_report.md
│   ├── advisory.md
│   └── slides.html
└── tools/                       # Product-specific utilities
    ├── decrypt.py
    ├── download.py
    └── scanner.py

If any subdirectory under rules/, models/, pocs/, or probes/ is intentionally empty because the architecture does not use that category, add a README.md explaining why. Empty unexplained directories look like incomplete work.

Phase 0: Setup And Extraction

Goal: unpack every binary, config, and asset file onto disk.

1. Identify the installer or package type: MSI, CAB, WiX Burn, NSIS, InnoSetup, archive, signed package, custom bootstrapper, or platform package.
2. Extract every layer: outer bootstrapper, inner packages, CAB payloads, nested archives, update bundles, and embedded resources.
3. Inventory every file with path, size, type, hash, signer, and notable metadata.
4. Identify encrypted or packed assets. Check magic bytes, entropy, XOR patterns, compression headers, and hardcoded keys in binaries.
5. Write extraction or decryption tools under <product>/tools/ when assets are not directly readable.
6. Record the extraction status and inventory summary in <product>/AGENT.md.

Phase 1: Complete Decompilation

Goal: produce pseudocode for every relevant native binary. Metadata without pseudocode is incomplete.

Use batch decompilation first for coverage, then interactive analysis for targeted follow-up. Place targeted results under ghidra_output/targeted/.

Batch Coverage

Use headless analysis to produce standardized outputs for each binary. The _decompiled.c file is mandatory.

<path-to-ghidra>/support/analyzeHeadless \
  /tmp/ghidra_project_<product> ProjectName \
  -import <binary> \
  -postScript DecompileAll.py \
  -scriptPath <path-to-scripts> \
  -deleteProject -overwrite \
  -max-cpu <cpu-count>

For large binaries, increase the heap according to local resources:

MAXMEM=12G <path-to-ghidra>/support/analyzeHeadless ...

Interactive Follow-Up

Use interactive reverse-engineering tooling after batch coverage to follow specific code paths, rename symbols, trace references, and annotate findings. Save the resulting notes, targeted pseudocode, and address mappings under ghidra_output/targeted/.

Useful workflow:

1. Load the target binary.
2. Triage sections, imports, exports, strings, and compiler hints.
3. Enumerate functions.
4. Decompile interesting functions systematically.
5. Trace inbound and outbound cross-references.
6. Rename functions and variables as understanding improves.
7. Add comments for confirmed findings and unresolved hypotheses.

Target Priority

1. Main agent or sensor binary.
2. Kernel drivers, minifilters, boot drivers, network monitors, device-control components.
3. ML, AI, static-analysis, or behavioral-analysis libraries.
4. Detection engines and signature-matching components.
5. Communication, telemetry, update, and cloud client libraries.
6. Hooking, injection, instrumentation, AMSI, script, or runtime-monitoring components.
7. Helper services, scanners, remediation tools, UI components.
8. Support libraries.

For managed binaries, use an appropriate managed-code decompiler instead of native decompilation.

Output Standard

Flat layout:

• <name>_decompiled.c: full pseudocode, mandatory.
• <name>_functions.json: function names, addresses, sizes.
• <name>_strings.txt: ASCII, UTF-16, and other relevant strings.
• <name>_summary.txt: architecture, imports, exports, sections, mitigations.
• <name>_interesting.txt: crypto constants, endpoints, registry paths, named pipes, keys, format strings, unusual APIs.

Directory-per-binary layout is also acceptable:

ghidra_output/<name>/
├── pseudocode.c
├── functions.json
├── strings.txt
├── summary.txt
├── interesting.txt
├── imports.txt
├── exports.txt
└── sections.txt

If a file set or directory lacks decompiled pseudocode, rerun or document the failure and complete it with another method.

Phase 2: Analysis Write-Ups

Produce all nine analysis documents for every product.

00_ARCHITECTURE.md

Required sections:

• Executive summary: product name, version, build date, platform.
• Component inventory: every binary with size, purpose, privilege level.
• Process architecture: system services, user processes, parent-child relationships.
• IPC mechanisms: pipes, RPC, COM, sockets, shared memory, IOCTLs, registry, ETW, message queues.
• Kernel components: minifilter altitudes, callout drivers, boot drivers, ETW providers.
• Persistence mechanisms: services, drivers, scheduled tasks, registry, launch agents.
• Self-protection: protected process settings, driver signing, tamper protection, anti-debugging.
• Update and communication architecture: endpoints, protocols, certificate validation, pinning.
• Third-party libraries with versions.
• Dependency graph: what loads what and in what order.

01_VULNERABILITY_ANALYSIS.md

Required sections:

• Attack surface enumeration: files, network, IPC, registry, local users, configuration, update channels.
• Per-component vulnerability assessment with severity ratings.
• Confirmed findings table: ID, title, severity, CVSS, status, type.
• For each finding: root cause, decompiled code reference, reproduction steps, impact, affected versions, remediation.
• Unvalidated or potential findings that need live testing.
• Attack chains showing how findings combine.
• Security posture summary: DEP, ASLR, CFG, stack cookies, sandboxing, signing, hardening.

Look for:

• NULL or weak DACLs on kernel objects, pipes, sections, services, files.
• TOCTOU races in privileged file operations.
• DLL search-order issues, missing DLLs, unquoted paths, writable install paths.
• Parser memory-safety issues in PE, archive, script, config, and signature handling.
• Signature verification bypasses, weak certificate validation, incomplete chain checks.
• Privilege escalation via junction, symlink, hardlink, or mount-point behavior.
• Integer overflows, truncations, and size calculation errors.
• Format string issues.
• Command injection through config, registry, scripts, or update metadata.

02_DETECTION_GAP_ANALYSIS.md

Required sections:

• MITRE ATT&CK coverage matrix: tactic by technique, marked COVERED, PARTIAL, or GAP.
• Gap inventory table: technique, severity, evidence from decompiled code.
• Per-tactic gap analysis: Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact.
• Architectural limitations: what the sensor cannot observe.
• Comparison with prior analyses in the same workspace.

Evidence standard: every gap claim needs a decompiled-code reference showing absent detection, a narrow condition, a threshold, or an unmonitored event source.

03_RULE_EXTRACTION.md

Required sections:

• Rule inventory by type: YARA, Lua, scripts, behavioral rules, signatures, network indicators, driver rules, exclusions.
• Extraction methodology: how rules were found, decrypted, decoded, decompiled, or parsed.
• Rule format documentation.
• Coverage analysis for each rule set.
• Rule quality assessment: false-positive risk, evasion difficulty, maintenance signals.
• Cross-reference to gap analysis.

Extraction targets:

• YARA rules, including compiled rules if recoverable.
• Lua, JavaScript, Python, or custom DSL detection scripts.
• Hash, string, regex, byte-pattern, and structured signature formats.
• Behavioral IOA/IOC definitions and process/event patterns.
• Network blocklists and protocol signatures.
• Known-vulnerable driver or vulnerable-component lists.
• Exclusion logic, allow lists, trusted publishers, and exemption paths.

04_ML_EXTRACTION.md

Document every ML model and scripted detection engine. Scripted engines can function as behavioral classifiers and deserve the same level of analysis as traditional ML.

Required sections:

• Model or engine inventory: name, type, size, purpose, source location.
• Architecture: decision trees, boosted trees, neural networks, TFLite, ONNX, custom models, Lua/JS/Python/custom DSL engines, or hybrids.
• Feature extraction: file, process, behavior, network, registry, and context attributes.
• Scoring thresholds and verdict mapping.
• Traditional ML statistics: tree count, depth, leaf distribution, dimensions, layers.
• Scripted engine details: interpreter, loader, sandbox, event matching, state management.
• Training-data indicators, if visible.
• Known blind spots.
• Bypass techniques based on features, thresholds, or missing telemetry.
• Reimplementation status in models/scanner/.

Extract:

• Tree structures to JSON.
• Neural-network assets to original portable files or documented matrices.
• Feature builders and feature names.
• Script files as readable source.
• Loader, verifier, sandbox, and event-matching logic.
• Thresholds and aggregation logic.

05_PREFILTER_EXCLUSION_ANALYSIS.md

Document everything dropped before full detection runs.

Required sections:

• Prefilter inventory: every decision point that skips, suppresses, or downgrades events.
• Exclusion types: paths, processes, publishers, hashes, file sizes, extensions, config flags, cloud dependencies, load shedding.
• For each exclusion: decompiled code reference, bypass technique, severity.
• Hardcoded thresholds, timeouts, magic constants.
• Exempt process, path, publisher, and file lists.

06_PROTOCOL_COMMS_ANALYSIS.md

Document all network communication and management protocols.

Required sections:

• Endpoint inventory: domains, URLs, IPs, ports, paths.
• Protocol analysis: HTTP/S, WebSocket, MQTT, gRPC, Protobuf, custom binary, message queues.
• Authentication: API keys, certificates, tokens, HMAC, signed metadata.
• Certificate pinning and validation behavior.
• Telemetry format and serialization.
• Update protocol and verification.
• Command channel from management service to endpoint agent.
• Serialization formats and recovered schemas.
• Hardcoded credentials, keys, certificates, or secrets.
• Network attack surface.

07_TRADECRAFT.md

Synthesize actionable red-team guidance from the prior documents. Keep claims evidence-backed and mark anything requiring live validation.

Required sections:

• Quick reference table: technique, bypass, one-liner or minimal steps.
• Process execution evasion.
• Credential access evasion.
• Lateral movement evasion.
• Persistence evasion.
• Script execution evasion.
• Network and C2 evasion.
• File operation evasion.
• Sensor blinding and visibility loss.
• Threshold manipulation.
• Timing windows.
• Configuration tampering, if administrative access is available.
• Tool modification guidance for common offensive frameworks and scripts.
• Combined attack chains.
• Detection priority ranking.

08_OBSERVATIONS.md

Capture important details that do not fit elsewhere:

• Code quality observations.
• Error handling and crash potential.
• Unusual algorithms or implementation details.
• Third-party component risks.
• Comparison with other products analyzed in the workspace.
• Recommended further research.
• Debug strings, developer comments, internal names.
• Version-specific notes.

Phase 3: Rule And Model Extraction

Rules

Every rule must be human-readable when feasible. Binary blobs alone are not sufficient unless conversion is impossible and clearly documented.

1. Search for yara, lua, rule, signature, pattern, detection, behavioral, indicator, ioc, ioa, and product-specific synonyms.
2. Check for encryption, compression, obfuscation, checksums, and container formats.
3. Extract to readable source: scripts, YARA, JSON/YAML/pseudocode, parsed signatures, driver lists, network rules.
4. Preserve metadata: names, severity, mapping, enable flags, version identifiers, timestamps.
5. Document counts, coverage, format, encoding, versioning, and extraction method in rules/README.md.
6. Cross-reference uncovered techniques with the gap analysis.
7. Separate exclusions and allow lists into rules/exclusions/.

Models

Every model or scripted engine should be deserializable and independently executable when feasible.

1. Search for model signatures, embedded interpreters, serialized trees, neural network files, large numeric arrays, script containers, and model configs.
2. Extract decision trees, neural networks, feature maps, scripts, thresholds, and model metadata to portable formats.
3. Decompile feature extraction or event matching logic.
4. Map scoring thresholds and verdict classification.
5. Build a standalone scanner or evaluator in models/scanner/.
6. Document inventory, features, thresholds, blind spots, and bypass difficulty in models/README.md.

Phase 4: Proofs Of Concept

Write PoCs for findings and gaps, prioritized by severity:

• Critical and high findings require a PoC unless blocked by missing live access.
• Medium findings should get PoCs when feasible.
• Low findings and detection gaps can be documented with a reproduction plan when implementation is not worthwhile.

PoC standards:

• Self-contained and reproducible.
• Clear header with finding ID, description, expected result, and safety notes.
• No unnecessary destructive behavior or live payloads.
• Categorized by type under pocs/.
• Tracked in pocs/README.md with status: COMPLETE, NEEDS_LIVE_ENV, STATIC_ANALYSIS_ONLY, or NOT_STARTED.

Phase 4b: Live Probes

When a live environment is available, build scripts in probes/:

• Protocol probes for network endpoints and IPC.
• Fuzzing scripts for parsers, pipes, RPC, configs, and protocols.
• Enumeration scripts for pipes, ports, loaded drivers, ETW providers, services, policies, and running processes.

Store results and captured artifacts alongside the scripts. Use live probes to validate static findings and identify timing, fallback, and error-handling behavior not visible in decompiled code.

Phase 4c: Reports

Produce stakeholder-ready outputs in reports/:

• technical_report.md: comprehensive technical write-up.
• advisory.md: disclosure-ready vulnerability advisory.
• slides.html: presentation deck summarizing key findings.

Reports should synthesize the nine analysis documents instead of introducing unsupported new claims.

Phase 5: Product-Specific Tools

Build utilities as soon as the analysis reveals reusable formats or protocols:

Tool	Build When
decrypt.py	Assets are encrypted, packed, or obfuscated
download.py	Rules, signatures, engines, or packages are available from update infrastructure
scanner.py	A model, scripted engine, or detection pipeline can be reimplemented
parser.py	Config, rule, signature, or telemetry formats are custom
protocol client	Reputation, telemetry, update, or command protocols can be queried directly

Prioritize rule extractors and decryptors first because they unlock rule and gap analysis. Then build downloaders, scanners, parsers, and protocol clients as evidence supports them.

Workflow Summary

When told to analyze a new endpoint security product:

1. Create the folder structure.
2. Extract and inventory every file.
3. Decompile every binary, using batch coverage first and targeted interactive analysis second.
4. Write all nine analysis documents.
5. Extract all readable rules and all models or scripted engines.
6. Write PoCs by severity.
7. Build live probes when an environment exists.
8. Produce stakeholder reports.
9. Build product-specific tools as needed.
10. Update the workspace inventory if one exists.

Quality Standards

• Every claim must cite evidence: function name, address, file path, or file line.
• Every gap must cite the code path, threshold, or missing telemetry that supports it.
• Every PoC must be tested or clearly marked as static-analysis-only.
• Prefer pseudocode for detection logic.
• Map techniques to MITRE ATT&CK IDs where possible.
• Assign severity ratings with justification.
• Compare findings across products already analyzed in the workspace.