maddo/Crusader_Decomp
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

deepened understanding

Browse source
This commit is contained in:
Maddo 2026-04-05 18:27:09 +02:00
commit 73931629ae
32 changed files with 5011 additions and 259 deletions
Download patch file Download diff file Expand all files Collapse all files

25
ghidra_mcp_wishlist.md
View file

@ -267,4 +267,27 @@ Short, concrete gaps hit during live Crusader work. Each entry records what MCP
- `list_project_programs(project_dir?, project_name?, folder_path?, recursive=true)`
- returns folder path, program name, read-only/writable/versioned state, and whether it is currently open
- Why it matters: comparing or porting across programs is awkward without a discoverable inventory of assemblies already in the Ghidra project.
- Status update (2026-03-26): local fork now exposes `list_project_programs(project_dir?, project_name?, folder_path?, recursive=true)` plus a `project_programs` alias; it walks project folders and returns machine-friendly program inventory lines with folder path, program name, content type, read-only/versioned flags, and current-open state.
- Status update (2026-03-26): local fork now exposes `list_project_programs(project_dir?, project_name?, folder_path?, recursive=true)` plus a `project_programs` alias; it walks project folders and returns machine-friendly program inventory lines with folder path, program name, content type, read-only/versioned flags, and current-open state.
### Class / namespace authoring for C++ lifting
- Missing MCP capability: create and manage Ghidra class or namespace symbols, then move existing functions under those owners as methods.
- Current fallback: manual Ghidra GUI edits in the Symbol Tree or one-off local scripts outside the normal MCP workflow.
- Why it matters: the Remorse binary already shows repeated ctor/dtor patterns, stable vtable roots, and class-like object families, but the current MCP workflow can only rename flat functions. That blocks a disciplined shift from procedural naming toward grouped C++-style ownership.
- Proposed MCP addition:
- `create_namespace(name, parent_path?, kind=namespace|class)`
- `move_symbol_to_namespace(symbol_address_or_name, namespace_path, new_name?)`
- `set_function_class(function_address, class_path, method_name?, this_param_name?, calling_convention?)`
- machine-friendly responses that include the final symbol path and any rename collisions.
### Vtable / OO recovery helpers for class reconstruction
- Missing MCP capability: first-class helpers for identifying vtables, attaching function slots to candidate classes, and materializing class/instance layouts from evidence-backed data.
- Current fallback: manual note collation from decompiler/disassembly output plus ad hoc datatype work in the GUI.
- Why it matters: the repo already has enough evidence to start lifting major families into C++ classes, but a recompilable source path needs more than renamed functions. It needs reproducible vtable maps, `this`-pointer typing, field layouts, inheritance guesses, and explicit provenance for each class model.
- Proposed MCP addition:
- `analyze_vtable(address, slot_count?, namespace_path?)`
- `create_or_update_struct(name, size?, fields)`
- `set_function_this_type(function_address, struct_name, this_storage=stack|register|farptr)`
- `apply_class_layout(class_path, instance_struct, vtable_struct?, methods)`
- optional dry-run output showing inferred slots, unresolved targets, and conflicting field/size evidence.