원클릭으로
rev-struct
// Reconstruct data structures by analyzing memory access patterns across functions
// Reconstruct data structures by analyzing memory access patterns across functions
Dump decrypted iOS app binaries (砸壳) from jailbroken devices using frida-ios-dump. Activate when the user wants to decrypt an iOS app, dump an IPA from a device, or extract a decrypted Mach-O binary for reverse engineering.
Restore function symbols by analyzing code patterns, strings, constants, and cross-references
Generate Frida hook scripts using modern Frida API. Activate when the user wants to write Frida scripts, hook functions at runtime, trace calls or arguments or return values, intercept native or ObjC or Java methods, dump memory or exports, or handle native module load timing for Android and other targets.
IDAPython and IDALib script reference for reverse engineering. Activate when the user needs to write IDAPython scripts in IDA, use IDALib for headless analysis, operate on IDB databases, debug with IDA, manipulate memory/registers, traverse functions/blocks/instructions, work with Hex-Rays decompiler API, handle obfuscation, or batch-process binaries.
Dump Unity IL2CPP symbols from iOS/Android builds. Extract method names, addresses, and type info from IL2CPP binaries and global-metadata.dat, then generate IDA/Ghidra import scripts.
Dump DEX files from a running Android app for unpacking/deobfuscation. Activate when the user wants to unpack an Android APK, dump DEX from memory, extract decrypted DEX files, or defeat class-loading packing.
| name | rev-struct |
| description | Reconstruct data structures by analyzing memory access patterns across functions |
Recover data structure definitions by analyzing memory access patterns in functions and their call chains.
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:
decompile/ directory exists.c files insideIf 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
./
├── 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)
Each .c file contains function metadata comments and decompiled code:
/*
* 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...
}
decompile/<address>.cSearch for the following patterns in the target function:
Direct offset access:
*(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:
*(a1 + 8 * i) // array, element size 8 bytes
a1[i] // array access
Nested structures:
*(*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
...
Read each caller function and analyze:
Parameter passing: What is passed when calling?
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
Operations before/after the call:
v1 = malloc(0x40); // allocate 0x40 bytes
*v1 = 0; // offset 0x00 initialization
*(v1 + 8) = callback; // offset 0x08 is a function pointer
sub_401000(v1);
Collect more offset accesses
Read each callee function and analyze:
How parameters are used:
// In callee
int callee(void *a1) {
return *(a1 + 0x18); // accesses offset 0x18
}
Passed to other functions:
another_func(a1 + 0x20); // offset 0x20 might be a nested struct
strlen/printf → string pointer/*
* Structure Recovery Analysis
* Source function: <func_address>
* Analysis scope: <number of callers/callees analyzed>
*
* Functions using this struct:
* - 0x401000 (initialization)
* - 0x401100 (field access)
* - 0x401200 (destruction)
*/
// Estimated size: 0x48 bytes
// Confidence: High / Medium / Low
struct suggested_name {
/* 0x00 */ void *vtable; // vtable pointer, called: (*(*this))()
/* 0x08 */ int refcount; // reference count, has ++/-- operations
/* 0x0C */ int flags; // flags, AND with 0x1, 0x2
/* 0x10 */ char *name; // string, passed to strlen/printf
/* 0x18 */ void *data; // data pointer
/* 0x20 */ size_t size; // size field
/* 0x28 */ struct node *next; // linked list next pointer
/* 0x30 */ struct node *prev; // linked list prev pointer
/* 0x38 */ callback_fn handler; // callback function
/* 0x40 */ void *user_data; // user data
};
// Field access examples:
// 0x401000: *(this + 0x08) += 1; // refcount++
// 0x401100: printf("%s", *(this + 0x10)); // print name