morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 07:47:29 +00:00

[GH-ISSUE #2903] [Bug] Windows Ghidra verifiers omit search_bytes and fail the operation coverage gate #1021

New issue

Closed

opened 2026-10-15 18:30:26 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

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

Owner

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

Both Windows Ghidra verification workflows omit the newly added read-only search_bytes operation. Their existing completeness gates correctly fail after the previously covered 25 operations succeed, so the real-Windows lanes cannot complete their later reference/file-offset checks.

Reproduction and scope

Pinned main d4f0c5e664e26fe7ed1566dcc4b85ea9b57d52da, Windows 11 x64 22631, Node24.18.0, Ghidra12.1.4/JDK21, matching Windows native artifact and generated controlled x64 PE EXE:

node scripts/create-ghidra-windows-fixture.mjs
node scripts/verify-real-ghidra-windows.mjs

Observed: import/decompilation and all25 existing operations succeed; the verifier then exits1 at line249, Windows Ghidra operation proof was incomplete. Expected read-only operations now number26; the sole missing operation is search_bytes.

The same source omission is present in scripts/verify-packaged-ghidra-windows.mjs, whose dynamic completeness assertion will also reject its operation set. The relevant sources remain unchanged at fresh-main 7e3a19863835215491b55fba7127a78bad6a7709.

Producing boundary and correction

Commit 2a78763e2070d71818a44bd419df549e13ce203c (#2341) added the operation to the inventory contract, bridge dispatch, handshake and Windows read-only capability set, but did not update either Windows verifier. This finding demonstrates verification coverage drift; it does not establish a byte-search engine defect because byte search was not invoked.

Add bounded searches with independent source-file byte oracles to both actual-engine workflows, checking wildcard/mask selection, exact address/file offset, examined coverage and continuation. Validate public CLI/MCP parity in the installed workflow. Preserve all caller-selected explicit fixtures and both completeness gates; print missing/unexpected names when those gates fail. Update the stale25-operation documentation. Avoid increasing search scope or output just to fill the coverage set.

Fresh resource evidence

Serial x64 lane:255.15s elapsed,53.69s sampled family CPU,1545.7MiB peak native Job commit,836.9MiB sampled working set,zero owned processes remain. BelowNormal priority, two logical CPUs,512MiB JVM heap,2GiB enclosing Job commit limit. The failing coverage assertion stopped later compact-reference/CLI-MCP file-offset checks, which remain unverified by this run.

Raw receipts and logs are retained locally in /tmp/rea-windows-e2e-20261013/results/ghidra-x64.*. Other Windows fixtures and public workflows remain under audit; fixes will be handled serially after #2898.

Originally created by @N0zoM1z0 on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2903 Both Windows Ghidra verification workflows omit the newly added read-only `search_bytes` operation. Their existing completeness gates correctly fail after the previously covered 25 operations succeed, so the real-Windows lanes cannot complete their later reference/file-offset checks. ## Reproduction and scope Pinned main `d4f0c5e664e26fe7ed1566dcc4b85ea9b57d52da`, Windows 11 x64 22631, Node24.18.0, Ghidra12.1.4/JDK21, matching Windows native artifact and generated controlled x64 PE EXE: ``` node scripts/create-ghidra-windows-fixture.mjs node scripts/verify-real-ghidra-windows.mjs ``` Observed: import/decompilation and all25 existing operations succeed; the verifier then exits1 at line249, `Windows Ghidra operation proof was incomplete`. Expected read-only operations now number26; the sole missing operation is `search_bytes`. The same source omission is present in `scripts/verify-packaged-ghidra-windows.mjs`, whose dynamic completeness assertion will also reject its operation set. The relevant sources remain unchanged at fresh-main `7e3a19863835215491b55fba7127a78bad6a7709`. ## Producing boundary and correction Commit `2a78763e2070d71818a44bd419df549e13ce203c` (#2341) added the operation to the inventory contract, bridge dispatch, handshake and Windows read-only capability set, but did not update either Windows verifier. This finding demonstrates verification coverage drift; it does not establish a byte-search engine defect because byte search was not invoked. Add bounded searches with independent source-file byte oracles to both actual-engine workflows, checking wildcard/mask selection, exact address/file offset, examined coverage and continuation. Validate public CLI/MCP parity in the installed workflow. Preserve all caller-selected explicit fixtures and both completeness gates; print missing/unexpected names when those gates fail. Update the stale25-operation documentation. Avoid increasing search scope or output just to fill the coverage set. ## Fresh resource evidence Serial x64 lane:255.15s elapsed,53.69s sampled family CPU,1545.7MiB peak native Job commit,836.9MiB sampled working set,zero owned processes remain. BelowNormal priority, two logical CPUs,512MiB JVM heap,2GiB enclosing Job commit limit. The failing coverage assertion stopped later compact-reference/CLI-MCP file-offset checks, which remain unverified by this run. Raw receipts and logs are retained locally in `/tmp/rea-windows-e2e-20261013/results/ghidra-x64.*`. Other Windows fixtures and public workflows remain under audit; fixes will be handled serially after #2898.

bsakaguchi

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

closed this issue
added the
area: native

bug
labels

bsakaguchi commented

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

Author

Owner

@N0zoM1z0 commented on GitHub (Oct 14, 2026):

Current main4d4631ac9 adds the missing search_bytes operation to both Windows verifiers. Real Windows11/Ghidra12.1.4/JDK21 qualification on767fe0f0c reaches the direct26-operation and source byte-search gates, then exposes a later verification-budget mismatch.

The public file-offset helper gives both MCP and fresh CLI requests240000ms. Production Ghidra startup alone defaults330000ms and honors caller-selected REA_GHIDRA_STARTUP_TIMEOUT_MS. With two logical CPUs/BelowNormal/Java512MiB, x64DLL fails on the helper's240s SDK timer; x86DLL completes its first address_to_file_offset in225178ms, later warm requests in6–65ms, then a fresh decompile CLI is killed by the helper's240s timer. Whole x86DLL793.54s, Job0. These are not outer observation timeouts.

The issue branch now derives the enclosing verifier request deadline from the production configuration owner: selected startup budget plus the existing240s operation allowance, applied consistently to SDK/CLI paths. It rejects combinations exceeding Node's signed timer range. Every analysis/selector/assertion remains; the provider startup deadline is unchanged. No speedup claim is made. Real full-workflow correctness and resource measurements are still required before PR/merge; x64EXE also timed out in actual autoanalysis with512MiB heap, so that configuration cost remains under investigation. Related deadline-contract tracker#1720 concerns a different product/client60s limit.

All artifacts/diagnostics stay in the local Windows test root and /tmp report. No third-party target is executed or modified.

@N0zoM1z0 commented on GitHub (Oct 14, 2026): Current main4d4631ac9 adds the missing search_bytes operation to both Windows verifiers. Real Windows11/Ghidra12.1.4/JDK21 qualification on767fe0f0c reaches the direct26-operation and source byte-search gates, then exposes a later verification-budget mismatch. The public file-offset helper gives both MCP and fresh CLI requests240000ms. Production Ghidra startup alone defaults330000ms and honors caller-selected REA_GHIDRA_STARTUP_TIMEOUT_MS. With two logical CPUs/BelowNormal/Java512MiB, x64DLL fails on the helper's240s SDK timer; x86DLL completes its first address_to_file_offset in225178ms, later warm requests in6–65ms, then a fresh decompile CLI is killed by the helper's240s timer. Whole x86DLL793.54s, Job0. These are not outer observation timeouts. The issue branch now derives the enclosing verifier request deadline from the production configuration owner: selected startup budget plus the existing240s operation allowance, applied consistently to SDK/CLI paths. It rejects combinations exceeding Node's signed timer range. Every analysis/selector/assertion remains; the provider startup deadline is unchanged. No speedup claim is made. Real full-workflow correctness and resource measurements are still required before PR/merge; x64EXE also timed out in actual autoanalysis with512MiB heap, so that configuration cost remains under investigation. Related deadline-contract tracker#1720 concerns a different product/client60s limit. All artifacts/diagnostics stay in the local Windows test root and /tmp report. No third-party target is executed or modified.

bsakaguchi commented

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

Author

Owner

@morluto commented on GitHub (Oct 14, 2026):

Resolved on main by 4d4631ac9. Both Windows Ghidra verifiers now import and invoke the shared scripts/lib/ghidra-windows-byte-search.mjs search_bytes workflow while retaining the operation coverage gate. Current-main source wiring and syntax checks passed for both entrypoints and the helper. Real Windows/Ghidra verification was not run in this pass.

@morluto commented on GitHub (Oct 14, 2026): Resolved on main by 4d4631ac9. Both Windows Ghidra verifiers now import and invoke the shared scripts/lib/ghidra-windows-byte-search.mjs search_bytes workflow while retaining the operation coverage gate. Current-main source wiring and syntax checks passed for both entrypoints and the helper. Real Windows/Ghidra verification was not run in this pass.

bsakaguchi referenced this issue

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

[PR #1021] [CLOSED] docs(readme): polish the Arabic README and sync it with English #2587

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#1021

No description provided.

Rows
Columns