[GH-ISSUE #1290] [Feature] Support native x86/x64 PE DLLs in the Windows Ghidra provider #461

New issue

Closed

opened 2026-10-15 18:25:15 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:25:15 +00:00

Owner

Originally created by @kvalls on GitHub (Oct 9, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1290

Before submitting

I searched open and closed issues and pull requests for related proposals.
I removed credentials, tokens, private paths and sensitive target data.

Area

Native analysis or decompilation — Windows Ghidra provider.

Current limitation

Please extend the Windows Ghidra read-only workflow to native x86 and x86-64 PE DLLs.

REA 6.1.0 still documents a non-DLL application boundary. At its release commit, inspectWindowsP0TargetSupport rejects every target whose executableRole is not application, returning target_role_unsupported with this reason:

Windows Ghidra P0 accepts PE applications, not DLL or non-executable images.

This is an explicit REA admission restriction; the Ghidra engine can statically import and decompile these DLLs. I am requesting a tested extension of REA's supported boundary, rather than treating the existing documented restriction as an accidental regression.

Version checked: rea-agents@6.1.0, release commit ae9aaee16b9c738d761d3938a3b34fdf37e581b5. The 6.1.0 check here is source/documentation inspection, not a new real-provider run.

Use cases

Research on an owned Windows game installation needs to inspect native client, engine and physics DLLs. The same applies to other Windows applications that ship most of their native implementation in libraries. Direct Ghidra works, but using it outside REA loses the shared MCP workflow and provider-scoped evidence handling.

A small source-authored fixture reproduces the relevant target role without redistributing any game files:

__declspec(noinline) int fixture_return42(void)
{
    return 42;
}

__declspec(noinline) int fixture_caller(void)
{
    return fixture_return42() + 1;
}

Build once in an MSVC x86 developer prompt and once in an x64 developer prompt, in separate output directories. Put the source in fixture.c and these names in fixture.def:

EXPORTS
    fixture_return42
    fixture_caller

cl /nologo /c /TC /Od /Ob0 /GS- /Zl /Fofixture.obj fixture.c
link /NOLOGO /DLL /NOENTRY /NODEFAULTLIB /OUT:fixture.dll /DEF:fixture.def fixture.obj

The fixture is a native DLL with two exports, no entry routine and no runtime imports. It is for static analysis only; there is no need to load or execute it. Use an absolute, fixed-local-NTFS path when selecting it:

{"name":"open_binary","arguments":{"path":"C:\\fixtures\\x86\\fixture.dll","provider_id":"ghidra"}}

Desired outcome and success criteria

Admit these native DLLs through the existing Windows Ghidra provider and preserve the current read-only contracts:

Both PE32/x86 and PE32+/x86-64 fixtures open with the correct observed Ghidra language width.
Procedure inventory, exact function selection, pseudocode, instructions, call references and loaded-memory/source-offset observations work through the existing CLI/MCP contracts.
The known callee returning 42 and caller adding one are recovered; source bytes, selected-target SHA-256 and imported-program identity agree.
Source files remain unchanged and close/cancellation/startup-failure cleanup retains the existing ownership guarantees.
Provider availability, analysis profiles, documentation and real-Windows/package verification describe DLL support consistently.

Authority boundaries and non-goals

Keep the current native authority, immutable snapshot, local NTFS/path admission, private runtime/DACL and Job Object requirements. Managed or unclassified PE images, unsupported architectures and malformed headers should retain their existing refusals.

This request covers static analysis of caller-selected native DLLs. It does not request target execution, DLL injection/loading, a GUI dependency, annotations, metadata-recovery parity or a claim that decompiled signatures are verified ABIs.

Alternatives considered and evidence

Direct Ghidra 12.1.4 is usable for the private research but bypasses REA's common interface.
A private extension based on REA 6.0.0 already passed production MCP checks for source-authored x86/x64 DLL fixtures on Windows 11 x64, Node 24.19.0, Ghidra 12.1.4 and JDK 25.0.4.1+1. It recovered 42 and the caller adding one, matched loaded bytes to source offsets, preserved input hashes and removed the owned temporary runtimes on close. Annotation remained disabled. This is evidence of feasibility, not upstream 6.1.0 acceptance or an exhaustive hostile-target/lifecycle audit.
The extension changed admission, capabilities and analysis-profile reporting, plus focused tests. It did not change the Java bridge or native filesystem/process implementation. The DLL profile was explicitly marked as private.
No proprietary DLLs, decompiled game code, private logs or machine paths are included here.

Possible direction

Agree on a narrow native-PE-library support boundary and add source-owned DLL fixtures to the real Windows and packed-artifact verification lanes. Preserve library role identity instead of disguising a DLL as an application or renaming its extension.

The private 6.0.0 experiment suggests the existing Ghidra/snapshot path can be reused. The 6.1.0 capability/profile files have also changed, so this is a proposal for a reviewed implementation, not a request to blindly copy the old patch.

References

6.1.0 release
Windows supported boundary at the release commit
Application-only role gate
Capability statement
#1030 added native x86 PE applications; this request extends the library role.
#38 and #287 are related Windows platform/native-authority work, rather than this specific DLL admission request.

Originally created by @kvalls on GitHub (Oct 9, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1290 ### Before submitting - [x] I searched open and closed issues and pull requests for related proposals. - [x] I removed credentials, tokens, private paths and sensitive target data. ### Area Native analysis or decompilation — Windows Ghidra provider. ### Current limitation Please extend the Windows Ghidra read-only workflow to native **x86 and x86-64 PE DLLs**. REA 6.1.0 still documents a non-DLL application boundary. At its release commit, `inspectWindowsP0TargetSupport` rejects every target whose `executableRole` is not `application`, returning `target_role_unsupported` with this reason: > Windows Ghidra P0 accepts PE applications, not DLL or non-executable images. This is an explicit REA admission restriction; the Ghidra engine can statically import and decompile these DLLs. I am requesting a tested extension of REA's supported boundary, rather than treating the existing documented restriction as an accidental regression. Version checked: `rea-agents@6.1.0`, release commit `ae9aaee16b9c738d761d3938a3b34fdf37e581b5`. The 6.1.0 check here is source/documentation inspection, **not a new real-provider run**. ### Use cases Research on an owned Windows game installation needs to inspect native client, engine and physics DLLs. The same applies to other Windows applications that ship most of their native implementation in libraries. Direct Ghidra works, but using it outside REA loses the shared MCP workflow and provider-scoped evidence handling. A small source-authored fixture reproduces the relevant target role without redistributing any game files: ```c __declspec(noinline) int fixture_return42(void) { return 42; } __declspec(noinline) int fixture_caller(void) { return fixture_return42() + 1; } ``` Build once in an MSVC **x86** developer prompt and once in an **x64** developer prompt, in separate output directories. Put the source in `fixture.c` and these names in `fixture.def`: ```text EXPORTS fixture_return42 fixture_caller ``` ```powershell cl /nologo /c /TC /Od /Ob0 /GS- /Zl /Fofixture.obj fixture.c link /NOLOGO /DLL /NOENTRY /NODEFAULTLIB /OUT:fixture.dll /DEF:fixture.def fixture.obj ``` The fixture is a native DLL with two exports, no entry routine and no runtime imports. It is for static analysis only; there is no need to load or execute it. Use an absolute, fixed-local-NTFS path when selecting it: ```json {"name":"open_binary","arguments":{"path":"C:\\fixtures\\x86\\fixture.dll","provider_id":"ghidra"}} ``` ### Desired outcome and success criteria Admit these native DLLs through the existing Windows Ghidra provider and preserve the current read-only contracts: 1. Both PE32/x86 and PE32+/x86-64 fixtures open with the correct observed Ghidra language width. 2. Procedure inventory, exact function selection, pseudocode, instructions, call references and loaded-memory/source-offset observations work through the existing CLI/MCP contracts. 3. The known callee returning 42 and caller adding one are recovered; source bytes, selected-target SHA-256 and imported-program identity agree. 4. Source files remain unchanged and close/cancellation/startup-failure cleanup retains the existing ownership guarantees. 5. Provider availability, analysis profiles, documentation and real-Windows/package verification describe DLL support consistently. ### Authority boundaries and non-goals Keep the current native authority, immutable snapshot, local NTFS/path admission, private runtime/DACL and Job Object requirements. Managed or unclassified PE images, unsupported architectures and malformed headers should retain their existing refusals. This request covers static analysis of caller-selected native DLLs. It does not request target execution, DLL injection/loading, a GUI dependency, annotations, metadata-recovery parity or a claim that decompiled signatures are verified ABIs. ### Alternatives considered and evidence - Direct Ghidra 12.1.4 is usable for the private research but bypasses REA's common interface. - A **private extension based on REA 6.0.0** already passed production MCP checks for source-authored x86/x64 DLL fixtures on Windows 11 x64, Node 24.19.0, Ghidra 12.1.4 and JDK 25.0.4.1+1. It recovered 42 and the caller adding one, matched loaded bytes to source offsets, preserved input hashes and removed the owned temporary runtimes on close. Annotation remained disabled. This is evidence of feasibility, **not upstream 6.1.0 acceptance or an exhaustive hostile-target/lifecycle audit**. - The extension changed admission, capabilities and analysis-profile reporting, plus focused tests. It did not change the Java bridge or native filesystem/process implementation. The DLL profile was explicitly marked as private. - No proprietary DLLs, decompiled game code, private logs or machine paths are included here. ### Possible direction Agree on a narrow native-PE-library support boundary and add source-owned DLL fixtures to the real Windows and packed-artifact verification lanes. Preserve library role identity instead of disguising a DLL as an application or renaming its extension. The private 6.0.0 experiment suggests the existing Ghidra/snapshot path can be reused. The 6.1.0 capability/profile files have also changed, so this is a proposal for a reviewed implementation, not a request to blindly copy the old patch. ### References - [6.1.0 release](https://github.com/morluto/rea/releases/tag/rea-agents-6.1.0) - [Windows supported boundary at the release commit](https://github.com/morluto/rea/blob/ae9aaee16b9c738d761d3938a3b34fdf37e581b5/docs/windows-ghidra-p0.md#supported-boundary) - [Application-only role gate](https://github.com/morluto/rea/blob/ae9aaee16b9c738d761d3938a3b34fdf37e581b5/src/ghidra/GhidraProvider.ts#L243-L250) - [Capability statement](https://github.com/morluto/rea/blob/ae9aaee16b9c738d761d3938a3b34fdf37e581b5/src/ghidra/GhidraProviderCapabilities.ts#L34) - #1030 added native x86 PE **applications**; this request extends the library role. - #38 and #287 are related Windows platform/native-authority work, rather than this specific DLL admission request.

bsakaguchi

2026-10-15 18:25:15 +00:00