[GH-ISSUE #1244] feat(native): surface instruction conflicts with inferred function prototypes #439

New issue

Open

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

bsakaguchi commented

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

Owner

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

Current limitation

The dossier preserves instructions and identifies Ghidra types as inferred, but leaves concrete stack/cleanup conflicts in a confident-looking signature for the analyst to discover manually. Generic decompiler limitations are useful but do not identify the conflicting locations.

Current observations

Two cases remain on both audited versions:

Function 0x406400 has a no-argument inferred signature and an empty native_api.parameters array, while instructions read the first stack argument and perform x87 arithmetic before a conversion helper. native_api reports signature source analysis and medium return-type confidence; those existing provenance facts must remain.
Function 0x401b10 has four inferred x86 stdcall arguments while its instruction sequence ends with stack cleanup of 20 bytes. This is conflicting evidence, not automatic proof of a five-argument source declaration.

The old log's literal void signature for allocation wrapper 0x417770 is now undefined on this provider run; do not freeze the old wording as a current defect. Forwarded return-register observations still need corroboration.

Required behavior

Expose focused diagnostics with the inferred claim, observed stack/return/call-site locations and unresolved assumptions. Preserve x87 inputs and expression completeness as observations/unknowns; do not invent missing multipliers, types or a compiler identity. Follow shared epilogues without expanding owned-body ranges.

Start with the observed stack-read and cleanup conflicts, and evaluate bounded return-register forwarding and x87 conversion cases. CLI/MCP and selected dossier views should carry the same diagnostics. Assembly remains available even when a consistency check cannot establish a conflict.

Source

src/domain/native/nativeApiBoundary.ts:91 and bridge/ghidra/ReaGhidraBridge.java:1675 already provide inferred-type provenance. This request builds on that representation; it is not a claim that REA changed target behavior.

Verification and scope

The two stack/prototype cases were reproduced with real Ghidra on published/main. Wider return-path, signedness and unwritten-buffer suggestions in the working log have not all been re-executed on this baseline; they are follow-up candidates, not confirmed regressions.

Audit date: 2026-10-09. Latest npm dist-tag verified as rea-agents@6.1.0; current main tested at f4c99ab8a53806dd57dc24b3d5a600905bcb4686. Linux x64, Node 24.18.0, MCP client SDK 2.3.1. Native observations use unmodified Ghidra 12.1.4 and JDK 21, two CPUs and a 512 MiB Java heap. No target execution or executable mutation was used for the static native checks.

Originally created by @N0zoM1z0 on GitHub (Oct 9, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1244 ### Current limitation The dossier preserves instructions and identifies Ghidra types as inferred, but leaves concrete stack/cleanup conflicts in a confident-looking signature for the analyst to discover manually. Generic decompiler limitations are useful but do not identify the conflicting locations. ### Current observations Two cases remain on both audited versions: - Function `0x406400` has a no-argument inferred signature and an empty `native_api.parameters` array, while instructions read the first stack argument and perform x87 arithmetic before a conversion helper. `native_api` reports signature source `analysis` and medium return-type confidence; those existing provenance facts must remain. - Function `0x401b10` has four inferred x86 stdcall arguments while its instruction sequence ends with stack cleanup of 20 bytes. This is conflicting evidence, not automatic proof of a five-argument source declaration. The old log's literal `void` signature for allocation wrapper `0x417770` is now `undefined` on this provider run; do not freeze the old wording as a current defect. Forwarded return-register observations still need corroboration. ### Required behavior Expose focused diagnostics with the inferred claim, observed stack/return/call-site locations and unresolved assumptions. Preserve x87 inputs and expression completeness as observations/unknowns; do not invent missing multipliers, types or a compiler identity. Follow shared epilogues without expanding owned-body ranges. Start with the observed stack-read and cleanup conflicts, and evaluate bounded return-register forwarding and x87 conversion cases. CLI/MCP and selected dossier views should carry the same diagnostics. Assembly remains available even when a consistency check cannot establish a conflict. ### Source [src/domain/native/nativeApiBoundary.ts:91](https://github.com/morluto/rea/blob/f4c99ab8a53806dd57dc24b3d5a600905bcb4686/src/domain/native/nativeApiBoundary.ts#L91) and [bridge/ghidra/ReaGhidraBridge.java:1675](https://github.com/morluto/rea/blob/f4c99ab8a53806dd57dc24b3d5a600905bcb4686/bridge/ghidra/ReaGhidraBridge.java#L1675) already provide inferred-type provenance. This request builds on that representation; it is not a claim that REA changed target behavior. ### Verification and scope The two stack/prototype cases were reproduced with real Ghidra on published/main. Wider return-path, signedness and unwritten-buffer suggestions in the working log have not all been re-executed on this baseline; they are follow-up candidates, not confirmed regressions. Audit date: 2026-10-09. Latest npm dist-tag verified as `rea-agents@6.1.0`; current main tested at `f4c99ab8a53806dd57dc24b3d5a600905bcb4686`. Linux x64, Node 24.18.0, MCP client SDK 2.3.1. Native observations use unmodified Ghidra 12.1.4 and JDK 21, two CPUs and a 512 MiB Java heap. No target execution or executable mutation was used for the static native checks.

bsakaguchi added the

area: domain

enhancement

P2: medium

labels

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

bsakaguchi referenced this issue

2026-10-16 21:13:07 +00:00

[PR #440] [MERGED] fix(setup): refresh stale local npx bootstrap #1988

bsakaguchi added

enhancement

and removed