
Rev Struct
Recover C struct layouts from decompiled functions when reversing a binary without full symbols.
Overview
rev-struct is an agent skill for the Ship phase that reconstructs data structures by analyzing memory access patterns in decompiled functions.
Install
npx skills add https://github.com/p4nda0s/reverse-skills --skill rev-structWhat is this skill?
- Prefers IDA Pro MCP when connected; falls back to IDA-NO-MCP `decompile/` export per-function `.c` files
- Traces memory access patterns across functions and call chains to infer field offsets and types
- Prompts with install steps for IDA-NO-MCP when neither MCP nor exports exist
- One decompiled file per function named by hex address (e.g. `0x401000.c`)
- Supports two IDA access paths: MCP preferred, IDA-NO-MCP export fallback
- Expects one `.c` file per function named by hex address under `decompile/`
Adoption & trust: 671 installs on skills.sh; 1.3k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have decompiled C without typedefs and cannot tell how arguments and globals map to real struct fields.
Who is it for?
Static RE on IDA decompilation or MCP-backed IDA when headers are missing but access patterns are consistent.
Skip if: Greenfield backend modeling, runtime-only fuzzing with no decompiler output, or teams that refuse to install IDA-MCP or export decompile artifacts.
When should I use this skill?
You need to reconstruct data structures by analyzing memory access patterns across decompiled functions.
What do I get? / Deliverables
You get documented struct candidates with offset rationale tied to observed accesses so you can rename types and continue call-chain analysis in IDA.
- Inferred struct definitions with field offsets and access evidence
- Notes linking callees and access sites used for layout proof
Recommended Skills
Journey fit
Structure recovery is a deep analysis step during security review and malware or firmware reverse engineering before patches or exploits are documented. Security subphase covers vulnerability analysis and binary comprehension where inferred types matter more than greenfield API design.
How it compares
Use for struct inference from decompilation patterns—not for deploying apps or generic debugging chat without a binary context.
Common Questions / FAQ
Who is rev-struct for?
Solo builders and indie security researchers doing static binary analysis with IDA and exported or MCP-linked decompilation.
When should I use rev-struct?
During Ship security work when you are reversing unknown structs from `.c` dumps; also in Build integrations when documenting legacy native components from disassembly.
Is rev-struct safe to install?
Review the Security Audits panel on this Prism page before installing; the skill guides file reads and IDA workflows but does not replace your malware-handling policies.
SKILL.md
READMESKILL.md - Rev Struct
# rev-struct - Structure Recovery Recover data structure definitions by analyzing memory access patterns in functions and their call chains. ## Pre-check **Determine which IDA access method is available:** **Option A — IDA Pro MCP (preferred if connected):** Check if the IDA Pro MCP server is connected (look for an active `ida-pro` or equivalent MCP connection). If connected, you can query IDA directly via MCP tools — no exported files needed. Proceed with the analysis using MCP. **Option B — IDA-NO-MCP exported data:** If MCP is not connected, check if IDA-NO-MCP exported data exists in the current directory: 1. Check if `decompile/` directory exists 2. Check if there are `.c` files inside If neither MCP nor exported data is available, prompt the user: ``` No IDA access method detected. Choose one of the following: Option A — IDA Pro MCP (recommended): Connect the IDA Pro MCP server so Claude can query IDA directly. Option B — IDA-NO-MCP export: 1. Download plugin: https://github.com/P4nda0s/IDA-NO-MCP 2. Copy INP.py to IDA plugins directory 3. Press Ctrl-Shift-E in IDA to export 4. Open the exported directory with Claude Code ``` --- ## Export Directory Structure ``` ./ ├── decompile/ # Decompiled C code directory │ ├── 0x401000.c # One file per function, named by hex address │ ├── 0x401234.c │ └── ... ├── decompile_failed.txt # Failed decompilation list ├── decompile_skipped.txt # Skipped functions list ├── strings.txt # String table (address, length, type, content) ├── imports.txt # Import table (address:function_name) ├── exports.txt # Export table (address:function_name) └── memory/ # Memory hexdump (1MB chunks) ``` ## Function File Format (decompile/*.c) Each `.c` file contains function metadata comments and decompiled code: ```c /* * func-name: sub_401000 * func-address: 0x401000 * callers: 0x402000, 0x403000 // List of functions that call this function * callees: 0x404000, 0x405000 // List of functions called by this function */ int __fastcall sub_401000(int a1, int a2) { // Decompiled code... } ``` --- ## Structure Recovery Steps ### Step 1: Read Target Function 1. Based on the user-provided address, read `decompile/<address>.c` 2. Parse function metadata, extract callers and callees lists 3. Identify pointer parameters in the function (potential structure pointers) ### Step 2: Collect Memory Access Patterns Search for the following patterns in the target function: **Direct offset access:** ```c *(a1 + 0x10) // offset 0x10 *(_DWORD *)(a1 + 8) // offset 0x8, DWORD type *(_QWORD *)(a1 + 0x20) // offset 0x20, QWORD type *(_BYTE *)(a1 + 4) // offset 0x4, BYTE type ``` **Array access:** ```c *(a1 + 8 * i) // array, element size 8 bytes a1[i] // array access ``` **Nested structures:** ```c *(*a1 + 0x10) // first field of struct pointed by a1 is a pointer ``` **Record format:** ``` offset=0x00, size=8, access=read/write, type=QWORD offset=0x08, size=4, access=read, type=DWORD ... ``` ### Step 3: Traverse Callers for Analysis Read each caller function and analyze: 1. **Parameter passing**: What is passed when calling? ```c sub_401000(v1); // v1 might be a struct pointer sub_401000(&v2); // v2 is a struct sub_401000(malloc(64)); // struct size is ~64 bytes ``` 2. **Operations before/after the call**: ```c v1 = malloc(0x40); // allocate 0x40 bytes *v1 = 0; // offset 0x00 initialization *(v1 + 8) = callback; // offset 0x08 is a function pointer sub_401000(v1); ``` 3. **Collect more offset accesses** ### Step 4: Traverse Callees for Analysis Read each callee function and analyze: 1. **How parameters are used**: ```c // In callee int callee(void