[GH-ISSUE #2729] [Feature] PPEE MCP server as a lightweight static PE/.NET provider #985

New issue

Open

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

bsakaguchi commented

2026-10-15 18:30:08 +00:00

Owner

Originally created by @R00ke on GitHub (Oct 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2729

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This request does not include credentials, private samples, or sensitive target data.

Area

Native analysis or decompilation

Current limitation

What I'm trying to do: triage an unknown Windows PE with an agent. I want to know whether it is packed, what it imports, whether it is signed, and what is hiding in a resource or the overlay.
What is difficult today: REA's native PE path goes through Hopper, Ghidra or IDA... The agent needs one of those installed and a full analysis pass just to answer basic structural questions. There is also no way to address nested content, such as an embedded PE inside a resource or a .NET managed resource, without extracting it to disk first.

Use cases

PE structure parsing. Reading headers, data directories, sections, relocations and resources as structured fields, and checking for malformed or inconsistent values (for example a bad checksum, odd section flags or an entry point outside the code).
PE triage by an agent. The agent receives a file and must say what it is without running it. Written in Go, Nim or Rust, bundled with PyInstaller, or packed or protected. The first questions are structural (toolchain, packer, signature, overlay, embedded payload), not "what does sub_401000 do".
.NET assemblies. Listing types and managed resources, spotting obfuscated identifiers, and reading an resource.
Installers and droppers with nested layers. A self-extracting installer holding a second PE or a .NET loader, or a PE with an archive or encrypted blob in the overlay. The agent needs to walk down these layers without writing each one to disk.
Drivers and DLLs. Imports, exports and signature state decide whether a signed driver, or a DLL that side-loads under a system file name, is interesting.
PE patching (opt-in). Editing header fields or raw bytes of a copy, such as clearing DllCharacteristics flags or changing a few bytes at an RVA. A dry run shows the patched headers before anything is written. It is useful for building test files and for neutralising a sample's anti-analysis flags before opening it in another tool. It is off by default and only available when the server is started with --mcp-allow-write.

Desired outcome and success criteria

REA can call PPEE's MCP server as a provider for PE files.
One call returns a bounded structural summary (sections, imports, exports, signature, overlay).
Nested content such as a resource or the overlay can be analysed in place, without writing it to disk.
Truncated output is marked and can be paged.
Imports, exports and strings match.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

No response

Verification available so far

I can suggest a sample or manual check

Verification details (optional)

No response

Alternatives considered

No response

Possible direction

No response

References

PPEE Homepage: https://mzrst.com/
MCP docs: https://mzrst.com/puppy/docs/mcp/
Windows binary: https://mzrst.com/puppy/releases/2.0.0-pre/ppee-2.0.0-pre-windows.zip
Linux binary: https://mzrst.com/puppy/releases/2.0.0-pre/ppee-2.0.0-pre-linux-x64.tar.gz

Originally created by @R00ke on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2729 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This request does not include credentials, private samples, or sensitive target data. ### Area Native analysis or decompilation ### Current limitation **What I'm trying to do:** triage an unknown Windows PE with an agent. I want to know whether it is packed, what it imports, whether it is signed, and what is hiding in a resource or the overlay. **What is difficult today:** REA's native PE path goes through Hopper, Ghidra or IDA... The agent needs one of those installed and a full analysis pass just to answer basic structural questions. There is also no way to address nested content, such as an embedded PE inside a resource or a .NET managed resource, without extracting it to disk first. ### Use cases - **PE structure parsing.** Reading headers, data directories, sections, relocations and resources as structured fields, and checking for malformed or inconsistent values (for example a bad checksum, odd section flags or an entry point outside the code). - **PE triage by an agent.** The agent receives a file and must say what it is without running it. Written in Go, Nim or Rust, bundled with PyInstaller, or packed or protected. The first questions are structural (toolchain, packer, signature, overlay, embedded payload), not "what does `sub_401000` do". - **.NET assemblies.** Listing types and managed resources, spotting obfuscated identifiers, and reading an resource. - **Installers and droppers with nested layers.** A self-extracting installer holding a second PE or a .NET loader, or a PE with an archive or encrypted blob in the overlay. The agent needs to walk down these layers without writing each one to disk. - **Drivers and DLLs.** Imports, exports and signature state decide whether a signed driver, or a DLL that side-loads under a system file name, is interesting. - **PE patching (opt-in).** Editing header fields or raw bytes of a copy, such as clearing `DllCharacteristics` flags or changing a few bytes at an RVA. A dry run shows the patched headers before anything is written. It is useful for building test files and for neutralising a sample's anti-analysis flags before opening it in another tool. It is off by default and only available when the server is started with `--mcp-allow-write`. ### Desired outcome and success criteria 1. REA can call PPEE's MCP server as a provider for PE files. 2. One call returns a bounded structural summary (sections, imports, exports, signature, overlay). 3. Nested content such as a resource or the overlay can be analysed in place, without writing it to disk. 4. Truncated output is marked and can be paged. 5. Imports, exports and strings match. ### Expected interaction with targets Read existing files or captured data ### Target and scope details (optional) _No response_ ### Verification available so far I can suggest a sample or manual check ### Verification details (optional) _No response_ ### Alternatives considered _No response_ ### Possible direction _No response_ ### References PPEE Homepage: https://mzrst.com/ MCP docs: https://mzrst.com/puppy/docs/mcp/ Windows binary: https://mzrst.com/puppy/releases/2.0.0-pre/ppee-2.0.0-pre-windows.zip Linux binary: https://mzrst.com/puppy/releases/2.0.0-pre/ppee-2.0.0-pre-linux-x64.tar.gz

bsakaguchi added the

area: mcp

triage

enhancement

labels

2026-10-15 18:30:08 +00:00

bsakaguchi referenced this issue

2026-10-17 21:07:33 +00:00

[PR #989] [MERGED] docs(website): clarify guides and case studies #2558

bsakaguchi added

enhancement

and removed