morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[PR #5023] feat(kuna): admit Windows PE images through the verified provider lane #6741

New issue

Open

opened 2026-11-01 21:42:44 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-01 21:42:44 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/5023
Author: @BaaRai
Created: 10/18/2026
Status: 🔄 Open

Base: main ← Head: fix/kuna-pe-admission

📝 Commits (6)

b056865 feat(kuna): admit Windows PE images through the verified provider lane
5c3fbc8 fix(kuna): admit PE for the verified x86-64 architecture only
5c2a90a docs(kuna): separate PE architecture scope from the ELF and Mach-O set
d17faa9 chore: merge main before review continuation
5bdb09c fix(kuna): refuse managed PE images until they get a verified run
e2f5a9a ci: retrigger after runner-side heap OOM in test shard 7/8

📊 Changes

3 files changed (+35 additions, -5 deletions)

View changed files

📝 docs/kuna-provider.md (+1 -1)
📝 src/kuna/KunaProvider.ts (+21 -2)
📝 tests/boundary/providers/kuna/kunaProvider.test.ts (+13 -2)

📄 Description

Summary

Kuna already handles Windows PE images, but REA's Kuna provider refused them at target admission with target_format_unsupported, so the fastest verified decompiler lane was unavailable for every Windows executable. This admits PE through the same lane and documents it. No new capability is added: the provider already invokes kuna functions and kuna decompile-project, which parse PE natively.

Problem and expected behavior

Trigger: open_binary with provider_id: kuna on a valid PE image.

Observed before: typed refusal target_format_unsupported with "REA verified the Kuna provider on ELF and thin Mach-O images; pe is not admitted yet."

Expected: PE images are admitted for x86-64 only, the one architecture with a real verified run; inventory and pseudocode resolve absolute image addresses. PE on other architectures, and managed PE images such as .NET assemblies and normalized ReadyToRun images, are refused with typed reasons, and universal Mach-O keeps its existing refusal because slice selection is still unverified.

Change and scope

src/kuna/KunaProvider.ts: admit format: "pe" in inspectTargetSupport, update the remaining refusal text for other formats.
tests/boundary/providers/kuna/kunaProvider.test.ts: native PE on x86-64 is supported, managed PE on x86-64 is refused with the typed managed reason, and PE on ARM64 is refused with the typed architecture reason; universal Mach-O stays refused.
docs/kuna-provider.md: the provider now lists PE and states what was verified.

Not included: universal Mach-O slice selection (unchanged refusal), and any Kuna-side change. Kuna upstream already ships the PE loader (loader/format/coff.rs, pe_entry.rs).

Contract and boundary impact

Semantic owner and earliest changed stage: provider target admission in KunaProvider.inspectTargetSupport; no analysis-stage change.
Contribution scope fit and linked maintainer decision: extends an already-merged provider to a format the engine supports; no new provider, execution, injection, mutation, or protection recovery.
CLI and MCP/tool-catalog contract: unchanged; the same tools work once admission succeeds.
Provider, bridge, target-format, or platform compatibility: PE becomes admissible for native x86-64 targets only, the one architecture with a real verified run; PE on other architectures is refused with a typed architecture reason, and managed PE (for example a .NET assembly or a normalized ReadyToRun image) is refused with a typed managed reason, mirroring the Ghidra gate. Universal Mach-O unchanged.
Evidence, artifact, provenance, or reconstruction contract: unchanged. Evidence reports the target format: "pe" and the Kuna provider version as before.
Target selection, authority, upstream behavior, and cleanup details: unchanged; Kuna remains caller-supplied and REA still installs nothing.

Verification

Real run on Kali with Kuna 1.906 and a source-owned PE built from

__declspec(dllexport) int rea_pe_add(int left, int right) { return left + right; }
__declspec(dllexport) int rea_pe_scale(int value) { return rea_pe_add(value, value) * 3; }
void mainCRTStartup(void) { (void)rea_pe_scale(7); }

built with clang --target=x86_64-pc-windows-msvc -c -O0 -ffreestanding then lld-link /entry:mainCRTStartup /subsystem:console /nodefaultlib.

Through the real MCP server (node scripts/rea.mjs --mcp, REA_KUNA_COMMAND set):

open_binary with provider_id: kuna on the PE succeeded.
list_procedures returned 0x140001000 rea_pe_add, 0x140001020 rea_pe_scale, 0x140001040 sub_140001040.
procedure_pseudo_code at 0x140001000 returned int rea_pe_add(int a0,int a1) { return a0 + a1; } with raw_result.source.kind: "single-function".
Kuna's own decompile-project on the same PE wrote the C, header and assembly export with 3/3 functions.

Unit: tests/boundary/providers/kuna/kunaProvider.test.ts 31/31; typecheck clean.

Author readiness

Human owner: @BaaRai

I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
I declare this PR ready for initial maintainer review.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/5023 **Author:** [@BaaRai](https://github.com/BaaRai) **Created:** 10/18/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/kuna-pe-admission` --- ### 📝 Commits (6) - [`b056865`](https://github.com/morluto/rea/commit/b056865e943dd445cdddab9d0ca67d0225e0f36c) feat(kuna): admit Windows PE images through the verified provider lane - [`5c3fbc8`](https://github.com/morluto/rea/commit/5c3fbc82dcde8154aa140e4cb1ad5b36b9932e52) fix(kuna): admit PE for the verified x86-64 architecture only - [`5c2a90a`](https://github.com/morluto/rea/commit/5c2a90a3e6252530fb1559b0e17fc4c95aed3659) docs(kuna): separate PE architecture scope from the ELF and Mach-O set - [`d17faa9`](https://github.com/morluto/rea/commit/d17faa9ae46b463d1c11fae2799c27961633d849) chore: merge main before review continuation - [`5bdb09c`](https://github.com/morluto/rea/commit/5bdb09c8a80531e3f1f60f85dd33bfe870aacc20) fix(kuna): refuse managed PE images until they get a verified run - [`e2f5a9a`](https://github.com/morluto/rea/commit/e2f5a9a60016dab45a08721beb4fe8d4db2b47dc) ci: retrigger after runner-side heap OOM in test shard 7/8 ### 📊 Changes **3 files changed** (+35 additions, -5 deletions) <details> <summary>View changed files</summary> 📝 `docs/kuna-provider.md` (+1 -1) 📝 `src/kuna/KunaProvider.ts` (+21 -2) 📝 `tests/boundary/providers/kuna/kunaProvider.test.ts` (+13 -2) </details> ### 📄 Description ## Summary Kuna already handles Windows PE images, but REA's Kuna provider refused them at target admission with `target_format_unsupported`, so the fastest verified decompiler lane was unavailable for every Windows executable. This admits PE through the same lane and documents it. No new capability is added: the provider already invokes `kuna functions` and `kuna decompile-project`, which parse PE natively. ## Problem and expected behavior Trigger: `open_binary` with `provider_id: kuna` on a valid PE image. Observed before: typed refusal `target_format_unsupported` with "REA verified the Kuna provider on ELF and thin Mach-O images; pe is not admitted yet." Expected: PE images are admitted for x86-64 only, the one architecture with a real verified run; inventory and pseudocode resolve absolute image addresses. PE on other architectures, and managed PE images such as .NET assemblies and normalized ReadyToRun images, are refused with typed reasons, and universal Mach-O keeps its existing refusal because slice selection is still unverified. ## Change and scope - `src/kuna/KunaProvider.ts`: admit `format: "pe"` in `inspectTargetSupport`, update the remaining refusal text for other formats. - `tests/boundary/providers/kuna/kunaProvider.test.ts`: native PE on x86-64 is supported, managed PE on x86-64 is refused with the typed managed reason, and PE on ARM64 is refused with the typed architecture reason; universal Mach-O stays refused. - `docs/kuna-provider.md`: the provider now lists PE and states what was verified. Not included: universal Mach-O slice selection (unchanged refusal), and any Kuna-side change. Kuna upstream already ships the PE loader (`loader/format/coff.rs`, `pe_entry.rs`). ## Contract and boundary impact - Semantic owner and earliest changed stage: provider target admission in `KunaProvider.inspectTargetSupport`; no analysis-stage change. - Contribution scope fit and linked maintainer decision: extends an already-merged provider to a format the engine supports; no new provider, execution, injection, mutation, or protection recovery. - CLI and MCP/tool-catalog contract: unchanged; the same tools work once admission succeeds. - Provider, bridge, target-format, or platform compatibility: PE becomes admissible for native x86-64 targets only, the one architecture with a real verified run; PE on other architectures is refused with a typed architecture reason, and managed PE (for example a .NET assembly or a normalized ReadyToRun image) is refused with a typed managed reason, mirroring the Ghidra gate. Universal Mach-O unchanged. - Evidence, artifact, provenance, or reconstruction contract: unchanged. Evidence reports the target `format: "pe"` and the Kuna provider version as before. - Target selection, authority, upstream behavior, and cleanup details: unchanged; Kuna remains caller-supplied and REA still installs nothing. ## Verification Real run on Kali with Kuna 1.906 and a source-owned PE built from ```c __declspec(dllexport) int rea_pe_add(int left, int right) { return left + right; } __declspec(dllexport) int rea_pe_scale(int value) { return rea_pe_add(value, value) * 3; } void mainCRTStartup(void) { (void)rea_pe_scale(7); } ``` built with `clang --target=x86_64-pc-windows-msvc -c -O0 -ffreestanding` then `lld-link /entry:mainCRTStartup /subsystem:console /nodefaultlib`. Through the real MCP server (`node scripts/rea.mjs --mcp`, `REA_KUNA_COMMAND` set): - `open_binary` with `provider_id: kuna` on the PE succeeded. - `list_procedures` returned `0x140001000 rea_pe_add`, `0x140001020 rea_pe_scale`, `0x140001040 sub_140001040`. - `procedure_pseudo_code` at `0x140001000` returned `int rea_pe_add(int a0,int a1) { return a0 + a1; }` with `raw_result.source.kind: "single-function"`. - Kuna's own `decompile-project` on the same PE wrote the C, header and assembly export with 3/3 functions. Unit: `tests/boundary/providers/kuna/kunaProvider.test.ts` 31/31; typecheck clean. ## Author readiness Human owner: @BaaRai - [x] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [x] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [x] I declare this PR ready for initial maintainer review. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi added the

pull-request

label

2026-11-01 21:42:44 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#6741

No description provided.

Rows
Columns