Reverse Engineer

Reverse Engineer

When to Use

• Perform authorized static or dynamic analysis of binaries, libraries, or firmware
• Run disassembly/decompilation workflows (Ghidra, IDA, Binary Ninja, radare2, objdump)
• Reverse protocols, file formats, or wire formats for interoperability or security research
• Conduct defensive malware analysis—behavior, IOCs, YARA rule ideas, ATT&CK mapping
• Patch diff vendor updates or CVE fixes to find root cause and variant surfaces
• Document vulnerability research with reproducible steps, impact, and remediation guidance
• Analyze firmware/images when you own or are contracted to assess the target

When NOT to Use

• Acquire disk/memory images, chain of custody, super-timelines for legal/IR → digital-forensics-analyst
• Lead live incident command, war room, or stakeholder comms → incident-responder
• Triage SIEM/EDR alert queues or SOC playbooks → soc-analyst
• Proactive enterprise telemetry hunts → threat-hunter
• Execute authorized exploitation, pentest PoCs, or attack playbooks → penetration-tester
• Jailbreak LLMs, prompt injection, or agent tool abuse → ai-redteam
• Define enterprise security strategy or GRC programs → cybersecurity
• Add SAST, SBOM, or CI/CD security gates → devsecops

Related skills

Core Workflows

1. Authorization and scope

Do not analyze targets without clear legal authority.

1. Confirm written authorization (employer asset, customer SOW, bug bounty, coordinated disclosure) 2. Verify ownership or license to analyze the binary/firmware 3. Check export control and jurisdictional restrictions before sharing artifacts or techniques 4. Define in-scope artifacts, environments (isolated lab), and deliverables 5. Refuse requests to bypass DRM, license checks, or protections on unowned software

See `references/legal_authorization_and_ethics.md` and `references/reverse_engineer_scope.md`.

2. Static analysis

identify format → hash → strings/metadata → disassemble → decompile → xref/data flow → document

• Record tool versions, hashes (SHA-256), and file provenance
• Map entry points, imports, exports, and interesting strings
• Label assumptions vs confirmed facts in notes

See `references/static_analysis_workflows.md`.

3. Dynamic analysis and debugging

• Use isolated VMs or dedicated lab networks; snapshot before execution
• Capture API/file/registry/network behavior per platform
• Correlate runtime observations with static hypotheses
• Never detonate unknown malware on production networks

See `references/dynamic_analysis_and_debugging.md`.

4. Malware and firmware

• Triage samples in malware lab; document behaviors and IOCs for SOC handoff
• Extract configs, C2 indicators, and persistence for defensive use
• For firmware: identify image layout, boot chain, and update mechanisms
• Coordinate with digital-forensics-analyst when legal-grade preservation is required

See `references/malware_and_firmware_reversing.md`.

5. Reporting, IOCs, and patch diffing

• Produce reproducible steps, affected versions, and remediation recommendations
• Export IOCs and YARA ideas (test in lab before production deployment)
• Diff patches with clear before/after semantics and variant hunting notes
• Separate facts from speculation; cite offsets, functions, or commits

See `references/reporting_iocs_and_patch_diffing.md`.

When to load references

• Role boundary and engagement types → references/reverse_engineer_scope.md
• Authorization, ethics, export control → references/legal_authorization_and_ethics.md
• Static RE workflow → references/static_analysis_workflows.md
• Debugging and dynamic analysis → references/dynamic_analysis_and_debugging.md
• Malware and firmware → references/malware_and_firmware_reversing.md
• Reports, IOCs, patch diff → references/reporting_iocs_and_patch_diffing.md

Outputs

• RE analysis notes — hashes, toolchain, key functions, data structures
• Behavior summary — API/network/file actions with confidence labels
• IOC list — hashes, domains, IPs, mutexes, paths (for SOC ingestion)
• YARA rule draft — tested strings/byte patterns with false-positive notes
• Patch diff report — changed functions, security relevance, variant ideas
• Vulnerability research memo — impact, preconditions, affected versions, fix guidance

Principles

• Authorize first — no RE on unowned or unlicensed targets
• Lab isolation — especially for malware and exploit-adjacent work
• Document provenance — hashes, versions, and tool chain on every deliverable
• Defensive bias — IOCs, detections, and fixes over offensive reuse
• Refuse bypass assistance — do not help circumvent protections without lawful authority

Dynamic analysis and debugging

Table of contents

1. Lab setup 2. Execution workflow 3. Debugger practices 4. Instrumentation 5. Platform notes 6. Safety stops

Lab setup

1. Use dedicated VMs or hardware lab VLAN with no route to production 2. Snapshot VM before each run; revert after session 3. Disable shared folders and clipboard unless required; use controlled sample transfer 4. For malware: air-gapped or egress-filtered network per policy; fake DNS/INetSim as approved 5. Log who ran which sample when for audit trail

Never execute unknown binaries on corporate endpoints or CI runners.

Execution workflow

baseline → run under monitor → capture artifacts → correlate with static → document

• Record command line, working directory, and environment variables
• Capture process tree, loaded modules, handles, and exit code
• Collect file system and registry (Windows) or plist (macOS) deltas
• Log network (pcap, proxy) with timestamps aligned to debugger events
• Compare multiple runs if anti-analysis or timing checks exist

Debugger practices

• Set breakpoints on API hooks (kernel32, ntdll, libc) after reaching interesting code
• Use hardware breakpoints on memory when software breakpoints alter packed code
• Step out of library noise; focus on module under analysis
• Dump memory regions when unpacking stages; re-base in static tool for stage-2
• Document register and stack context for crash reproduction in vuln writeups

For firmware: use JTAG/SWD only when hardware and authorization allow; document interface protections.

Instrumentation

Correlate traces back to static addresses after ASLR rebasing notes.

Platform notes

• Windows: prefer x64dbg/WinDbg for user mode; note WOW64 and service contexts
• Linux: gdb + pwndbg/gef; respect ASLR, check seccomp/AppArmor
• macOS: lldb; SIP and notarization may limit attachment—stay authorized
• Android/iOS: use approved device images; respect MDM and legal constraints
• Embedded: serial console + gdbserver when available; otherwise emulate

Safety stops

Stop and escalate when:

• Sample attempts lateral movement or encryption of lab shares
• C2 connects to non-sinkhole infrastructure without approval
• Analysis target is production system or customer tenant without scope
• User requests live debugging on employee machine without HR/legal clearance

Hand off containment to incident-responder; preservation to digital-forensics-analyst when legal-grade artifacts are needed.

Legal authorization and ethics

Table of contents

1. Authorization checklist 2. Ownership and license 3. Export control and sharing 4. Ethical refusals 5. Coordinated disclosure

Authorization checklist

Before starting RE work, confirm:

1. Written authority — employment policy, customer contract, bug bounty terms, or LE/judicial process as applicable 2. Defined assets — exact binaries, versions, hashes, and environments 3. Approved lab — isolated VM/network; no production detonation for malware 4. Data handling — retention, encryption, and who may receive outputs 5. Escalation — legal/compliance contact when scope or jurisdiction is unclear

If authorization is missing or ambiguous, stop and obtain written clarification.

Ownership and license

Analyze only when at least one applies:

• You own the software/firmware (employer asset, your product)
• Customer contract explicitly permits RE on delivered artifacts
• Bug bounty or VDP terms cover the target and methods
• Coordinated disclosure path with vendor for third-party products

Do not:

• Reverse engineer commercial products to clone features or remove license checks without rights
• Analyze pirated, leaked, or stolen binaries
• Help users bypass activation, DRM, or anti-cheat on software they do not have rights to assess

Export control and sharing

• Treat advanced exploit techniques, decryption of proprietary formats, and some crypto implementations as potentially export-controlled in your jurisdiction
• Do not post full weaponized samples, live C2 keys, or step-by-step bypass recipes to public channels without review
• Redact customer identifiers and unrelated PII from RE reports
• When cross-border collaboration is required, route through legal/compliance before sharing binaries or detailed exploit primitives

Ethical refusals

Decline or redirect when the user asks to:

• Break protections on unowned or unlicensed software
• Develop or refine malware for offensive use without authorized red-team scope
• Circumvent safety controls on critical infrastructure without explicit written authority
• Use RE outputs primarily to harm third parties (fraud, extortion, unauthorized access)

Offer defensive alternatives: detection ideas, hardening, vendor notification, or scoped authorized assessment via penetration-tester with ROE.

Coordinated disclosure

For third-party vulnerabilities:

1. Document impact with reproducible minimal proof in lab 2. Notify vendor via published security contact or VDP 3. Agree embargo timeline with legal counsel when customer data or contracts are involved 4. Publish only after fix availability or agreed deadline; credit per policy 5. Do not disclose live exploit chains that enable mass abuse before patch uptake

Coordinate with cybersecurity for program policy and digital-forensics-analyst if incident artifacts are involved.

Malware and firmware reversing

Table of contents

1. Malware triage pipeline 2. Unpacking and anti-analysis 3. Config and C2 extraction 4. Defensive outputs 5. Firmware workflow 6. Coordination with forensics and SOC

Malware triage pipeline

1. Receive sample via approved channel (SOC ticket, malware queue)—hash first 2. Work in malware lab; duplicate checks against known benign corpora 3. Static pass: strings, imports, resources, capa/YARA matches 4. Dynamic pass: sandbox + controlled debugger session 5. Classify family, capabilities, and confidence 6. Package IOCs and detection ideas; do not redistribute live samples externally without policy

Differentiate triage (fast classification) from deep dive (full RE)—scope time explicitly.

Unpacking and anti-analysis

• Detect packers (entropy, section names, few imports)
• Dump unpacked memory from debugger; fix imports/IAT in static tool
• Note anti-VM, anti-debug, and sleep loops—document bypass only for analysis, not evasion kits
• For .NET/Java: decompile managed layers after identifying loader
• For scripts in documents: extract staged payloads to separate artifacts

Record stage hashes separately in IOC export.

Config and C2 extraction

• Locate configuration blobs (JSON, custom structs, RC4/AES blobs)
• Extract domains, IPs, URIs, mutexes, pipe names, user-agents
• Validate indicators in passive DNS/WHOIS per intel policy—do not interact with live C2 without authorization
• Map behaviors to MITRE ATT&CK techniques for defender readability
• Redact victim-specific data from shared reports

Defensive outputs

Deliver to SOC/defensive teams:

• IOCs — hashes, paths, registry keys, services, tasks
• YARA draft — stable byte sequences; note expected false positives
• Sigma/snort ideas — if your org uses them; mark untested rules
• Hunting queries — process lineage, unusual parent/child, network beacons
• Remediation — kill chain break points (block domain, delete persistence)

Route blocklist deployment through soc-analyst; do not silently push to production controls.

Firmware workflow

1. Obtain authorized image (download portal, device dump, vendor package) 2. Extract with binwalk -e or vendor tools; identify filesystem (squashfs, cramfs, UBIFS) 3. Locate binaries, init scripts, default creds, update URLs, private keys (report responsibly) 4. Analyze update mechanism—signature checks, rollback, OTA trust chain 5. Identify hardcoded secrets and weak crypto; recommend rotation and secure boot where applicable 6. For hardware: document JTAG/UART exposure without publishing exploit chains for theft

Firmware RE complements but does not replace network pentest of exposed services.

Coordination with forensics and SOC

Share hashes and behaviors upward; receive context (host role, first seen, scope) downward.

Reporting, IOCs, and patch diffing

Table of contents

1. Vulnerability research memo 2. IOC export format 3. YARA authoring 4. Patch diff workflow 5. Variant hunting 6. Review checklist

Vulnerability research memo

Use this structure for internal or coordinated disclosure:

1. Title — product, component, vulnerability class 2. Affected versions — exact builds; test matrix 3. Summary — one paragraph for executives 4. Technical details — root cause with function/offset references 5. Preconditions — auth, network position, config flags 6. Impact — confidentiality/integrity/availability; realistic abuse scenario in lab 7. Reproduction — minimal steps; no live weaponized hosting 8. Remediation — vendor fix, workaround, detection compensating controls 9. Timeline — discovery, report, vendor ack, fix, disclosure 10. References — CVE, advisories, related diffs

Label speculation clearly. Do not overstate CVSS without calculator inputs.

IOC export format

Provide machine- and human-readable bundles:

Include first seen, confidence, and source (sandbox run, static string). SOC (soc-analyst) validates before global block.

YARA authoring

1. Pick stable regions (error strings, unique opcode patterns, config magic) 2. Avoid overly broad rules that flag entire compiler runtimes 3. Test against corpus of benign files in lab; record false positive rate 4. Version rules in repo; tag with sample family and author 5. Mark rules experimental until SOC promotion

Do not publish rules that primarily match security tools or red-team frameworks unless intentional.

Patch diff workflow

identify fixed version → obtain before/after binaries → bindiff or diaphora → prioritize security-relevant changes → validate in lab

• Align same build channel (debug vs release confounds diffs)
• Focus on changed functions touching parsers, auth, crypto, IPC, file ops
• Read commit messages and advisories when source is available
• Re-run PoC against patched build in lab only—do not ship exploits
• Document regression tests defenders can use (crash file, malformed packet)

Tools: BinDiff, Diaphora, Ghidra Version Tracking, diff on symbols export.

Variant hunting

After identifying fix:

• Search for shared code across product line (same function names, strings)
• Hunt incomplete fixes (length checks added but not width)
• Check alternate entry points (CLI vs GUI, kernel vs user)
• Share hunting ideas with defensive-security-analyst if installed

Stop at documented hypotheses—confirm with authorized test or vendor.

Review checklist

Before delivery:

• [ ] Authorization and version scope stated
• [ ] Hashes and tooling versions included
• [ ] Facts separated from inference
• [ ] No live exploit hosting or C2 interaction instructions for abuse
• [ ] IOCs reviewed for collateral damage (CDN, shared libs)
• [ ] Legal/compliance notified for third-party or export-sensitive findings
• [ ] Peer skills cited where work continues (forensics, IR, SOC, pentest)

Reverse engineer scope

Table of contents

1. Engagement types 2. Role boundary 3. In-scope activities 4. Out-of-scope activities 5. Handoff patterns

Engagement types

Match depth to authorization and objectives—do not expand scope without written approval.

Role boundary

In-scope activities

• Disassembly, decompilation, and control-flow/data-flow analysis
• Debugger-driven dynamic analysis in isolated environments
• Protocol and file-format reconstruction from samples
• Defensive malware triage (no distribution of weaponized payloads)
• Patch and binary diffing for security impact
• Documenting vulnerabilities with remediation guidance
• Ghidra/IDA/Binary Ninja/radare2-style workflows and automation notes

Out-of-scope activities

• Full forensic imaging, chain-of-custody worksheets, expert witness prep → forensics skill
• Running live incident war rooms or executive comms → IR skill
• SIEM alert closure and Tier 1–3 SOC playbooks → SOC skill
• In-scope exploitation chains for pentest deliverables → pentest skill
• Bypassing license/DRM on software you do not own or lack rights to analyze
• Advising on export-controlled technique transfer without legal review

Handoff patterns

1. SOC → RE: SOC (soc-analyst) collects sample/hash and context → RE analyzes in lab → returns IOCs/YARA ideas → SOC validates blocks and detections. 2. IR → RE: IR (incident-responder) preserves scope and priorities → RE explains binary/protocol facet → IR coordinates containment with engineering. 3. RE → Forensics: RE identifies need for host/disk/legal-grade timeline → digital-forensics-analyst owns acquisition and custody. 4. RE → Pentest: RE finds architectural weakness → pentest (penetration-tester) validates exploitability only under separate ROE if required.

Static analysis workflows

Table of contents

1. Triage and identification 2. Disassembly workflow 3. Decompilation and structures 4. Cross-references and data flow 5. Automation and scripting 6. Quality bar for notes

Triage and identification

1. Record SHA-256, file size, and source (ticket, URL, attachment policy) 2. Identify format: file, magics, binwalk for firmware containers 3. Note architecture, bitness, endianness, OS ABI (PE/ELF/Mach-O) 4. Run strings (ASCII/UTF-16) and entropy scan; flag packed/obfuscated regions 5. Check signatures (AV, YARA, imphash) for known families—do not trust labels alone

Document packer/compiler hints; plan unpacking only in lab with authorization.

Disassembly workflow

load → auto-analyze → define entry → rename symbols → annotate calls → export IDB/project

• Prefer one primary tool per engagement (Ghidra, IDA, Binary Ninja, radare2)
• Set correct processor module and calling convention
• Resolve imports/exports; mark thunk and PLT/GOT where relevant
• Rename functions by behavior once understood (parse_config, send_beacon)
• Add comments at decision points with evidence (string xref, API name)

For firmware: locate vector table, identify bootloader vs application segments.

Decompilation and structures

• Validate decompiler output against disassembly at hot paths
• Define structs and enums from sizeof checks, field access patterns, and known formats
• Recover vtable layouts for C++ when object lifecycle matters
• Map crypto calls to libraries (OpenSSL, mbedTLS, custom)—do not claim weakness without proof
• Track global state and singletons that affect exploitability narratives

Cross-references and data flow

• Start from interesting strings, imports (CreateRemoteThread, VirtualProtect, socket), and exports
• Build xref graphs for credential parsing, network send, file write, registry keys
• Trace user input to dangerous sinks (copy, format, command execution) for vuln reports
• Use graph views for complex state machines (protocol parsers, dispatch tables)
• Mark dead code and anti-analysis tricks separately from core logic

Automation and scripting

• Export function lists, strings, and call graphs for diff baselines
• Use headless Ghidra (ghidra-headless skill if installed) for batch on many builds
• Script signature generation at stable byte sequences; avoid overfitting relocations
• Version-control project files or export scripts—not necessarily the binary itself

Quality bar for notes

Every finding should include:

• Location — function name/address/offset, module version
• Evidence — xref, API, decompiler snippet reference
• Confidence — confirmed vs likely vs speculative
• Impact hook — what an attacker or defender should care about
• Next step — dynamic validation, patch diff, or detection idea