morluto/rea

Fork 0

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

[GH-ISSUE #5168] [Bug] e_lfanew inside the DOS header (Tiny PE) is refused before provider admission #3175

New issue

Open

opened 2026-10-31 00:37:31 +00:00 by bsakaguchi · 5 comments

bsakaguchi commented

2026-10-31 00:37:31 +00:00

Owner

Originally created by @Endirdev on GitHub (Oct 19, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5168

Observed behavior

REA refuses MZ images whose Windows new-header pointer (e_lfanew) lies inside the 64-byte DOS header, before any provider is selected — even when a valid PE\0\0 signature sits at the declared offset. Canonical case: Sotirov's 97-byte Tiny PE (e_lfanew = 4).

MCP open_binary with provider_id: "ghidra" (paths redacted):

{"error":{"code":"target_unavailable","category":"unavailable","message":"Cannot open artifact: invalid Windows new-header offset in MZ image. Check that the path exists, is readable, and points to a supported file.","retryable":false,"remediation":{"action":"Cannot open artifact: invalid Windows new-header offset in MZ image. Check that the path exists, is readable, and points to a supported file."},"details":{"path":"<redacted>/tiny.97.exe","reason":"invalid Windows new-header offset in MZ image"}}}

rea inspect --provider ghidra --json ./tiny.97.exe exits 1 with the same reason. (The appended "Check that the path exists, is readable, and points to a supported file." wording is #1979, already fixed on main; it is not part of this report.)

The ghidra provider is available on this host: /bin/true opens through it on the same install (Ghidra 12.1.4 profile). observeMzWindowsHeader (src/domain/dosMz.ts:43) already computes signature: "PE" at the declared offset for this fixture; the guards cited below ignore that observation.

Interface: MCP (the CLI shows the same refusal)
Earliest failure stage: Request parsing or validation (target resolution, before provider selection)

Reproduction

Fixture: 97-byte Tiny PE (e_lfanew=4, 1 section, SizeOfOptionalHeader=4, COFF machine 0x014c, optional-header magic 0x10b):

echo 'TVoAAFBFAABMAQEAaipYwwAAAAAAAAAABAADAQsBCAAEAAAAAAAAAAQAAAAMAAAABAAAAAwAAAAAAEAABAAAAAQAAAAEAAAAAAAAAAQAAAAAAAAAaAAAAGQAAAAAAAAAAg==' | base64 -d > tiny.97.exe
sha256sum tiny.97.exe   # e872a508a28fe08ad4d309d6949e3dbe26efad305c2c114303e01af1241a6a67

rea inspect --provider ghidra --json ./tiny.97.exe → exit 1, reason invalid Windows new-header offset in MZ image
MCP: open_binary {path: "./tiny.97.exe"} → target_unavailable, same reason

Deterministic on this host across repeat runs. Alternative fixture source: http://www.phreedom.org/research/tinype/tinype.zip. A second fixture — 4KB.exe, the released executable of "Oscar's Chair" by Eos (4092 B, MZ20PE, e_lfanew=4, 0 sections, SizeOfOptionalHeader=8, sha256 d00f3da0e3a7ab0ecb43841cd922f6abcb1a40fae9c95f9f0ef38fe6aff1eea9; provenance in Additional context) — is refused identically.

Expected behavior

An overlapped-but-signature-confirmed PE should be admitted to the PE route. PE/COFF defines e_lfanew as a file offset and does not define a 64-byte floor; Windows reads the optional header at fixed offsets, and the smallest known working value (Sotirov, then-current non-2000 Windows) is 4. At minimum, the refusal should be an explicit unsupported-layout reason rather than an "invalid offset" error, so a caller can distinguish a malformed file from an unsupported layout.

Grounding: Sotirov's article (the 97-byte file ran on then-current non-2000 Windows); REA's own inspect_pe_resources route contains no e_lfanew floor (src/native/pe/PeResourceLayout.ts:65 fails later at optionalSize < 64); Ghidra 12.1.4 imports e_lfanew=4 PEs when file length permits (see Additional context); and a real-world production using this exact layout ("Oscar's Chair", shown at Revision 2018 and ranked 1st) is refused identically. I have not re-executed the files myself; direct execution is marked untested rather than claimed.

Impact and scope

A whole class (size-optimized/overlapped-header PEs, canonical Tiny PE included) is refused before provider admission; no analysis through native lanes.
Real-world production affected: the secondary fixture is byte-identical to the released executable of "Oscar's Chair" by Eos (Revision 2018 PC 4k compo, ranked 1st).
Available workarounds are semantically wrong (format:"dos-com" treats the PE bytes as a headerless 16-bit COM image, 1 segment / 1 procedure) or external.
Refusal is deterministic. No crash, data loss, or evidence-integrity issue observed.

REA version

rea --version → 6.4.0. Both guards verified present on main commit dfe8378cf5a727e3d93d47a5986233175c6ef898 (2026-10-19) and in the published 6.4.0 build.

Runtime and platform

Node v24.21.0; Ubuntu 24.04 x64 (distrobox container on Bazzite); Ghidra 12.1.4 PUBLIC; provider ghidra (hopper/ida not configured; not needed).

Target and artifact context

tiny.97.exe — x86 PE32, 97 bytes, sha256 e872a508a28fe08ad4d309d6949e3dbe26efad305c2c114303e01af1241a6a67. Secondary: 4KB.exe — the released executable of "Oscar's Chair" by Eos (Revision 2018 PC 4k compo, ranked 1st), 4092 B, sha256 d00f3da0e3a7ab0ecb43841cd922f6abcb1a40fae9c95f9f0ef38fe6aff1eea9; byte-identical to the official scene.org release member, uses the same e_lfanew=4 overlapped layout, and is refused identically.

Relevant output or evidence

Source refs at main@dfe8378 (BinaryTargetResolver.ts#L493-L494, binaryTarget.ts#L287-L288, dosMz.ts#L43, PeResourceLayout.ts#L65, binaryTarget.ts#L516):

Guard 1, application resolver — src/application/BinaryTargetResolver.ts#L493-L494:

if (windowsHeader.offset < 64)
  return err("invalid Windows new-header offset in MZ image");

Guard 2, domain — src/domain/binaryTarget.ts#L287-L288:

if (offset < 64 || offset > bytes.length - 24)
  return err("invalid or truncated Windows executable header in MZ image");

observeMzWindowsHeader computed signature: "PE" at offset=4 for this fixture (src/domain/dosMz.ts:43).
inspect_pe_resources on both fixtures → invalid_format: "Truncated PE optional header." — a distinct, later limitation (declared SizeOfOptionalHeader 4/8 B vs fixed-offset reads), not an offset refusal.
MCP refusal JSON and CLI JSON captured locally (redacted copies available on request).
Missing/uncertain: modern Windows-loader execution untested; Ghidra import logs captured locally (summarized in Additional context).

Typed outcome or recovery expected

Either pe/x86 classification admitted (optionally with a non-standard-layout warning), or a typed unsupported-layout reason distinct from an offset/path error.

Analysis or suspected cause

Source-derived (not a fix commitment): the two < 64 guards are the blocker on the resolver/domain routes. observeMzWindowsHeader already yields signature: "PE", so gating the guards on that observation with a minimum offset of 4 (or documenting the floor as deliberate) resolves the refusal. Follow-on if relaxed: peManagedStatus (src/domain/binaryTarget.ts:516) requires the declared SizeOfOptionalHeader to cover the standard fields, so expect a truncated PE optional header refusal next for these fixtures; Windows and Ghidra read those fields at fixed offsets regardless and only warn. Internally, readPeResourceLayout keeps no e_lfanew floor, so open_binary refusing what inspect_pe_resources accepts is inconsistent.

Additional context

Related: #2172 (fixed by c9fed506, short-DOS-stub classification), #1979 (fixed by f28f3382, path-advice wording), #2408 (NE-support proposal under review).
Ghidra 12.1.4 headless import, run locally on 2026-10-19:
- 4KB.exe (e_lfanew=4, 4092 B): import succeeded as x86:LE:32:default:windows, with WARN Non-standard optional header size: 8 bytes.
- tiny.97 padded to 512 B (same headers, trailing zeros): import succeeded, with WARN Non-standard optional header size: 4 bytes.
- Canonical 97-byte tiny.97.exe: does not import in Ghidra either — default loader selection is MZ (import fails), and forced -loader PeLoader reports "No load spec found" because its fixed-offset reads run past EOF. That is a file-length limitation, not an e_lfanew policy, so it does not weaken the inconsistency above but must not be glossed over.
Fixtures: Sotirov Tiny PE archive, http://www.phreedom.org/research/tinype/
Provenance of the secondary fixture (verified 2026-10-19): 4KB.exe is the
released executable of "Oscar's Chair" by Eos — pouët 75721
(Windows 4k, Revision 2018 PC 4k compo, ranked 1st; The Meteoriks 2019
winner, Best Small High-End Intro), Demozoo.
The scene.org release archive
member eos_-_oscar's_chair_1280x720.exe is byte-identical (sha256) to the
local fixture. It was downloaded, extracted, and hashed only — not executed.

🤖 Prepared with an AI agent (OpenCode) against REA 6.4.0 via MCP; commands were re-run and outputs captured locally.

Originally created by @Endirdev on GitHub (Oct 19, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5168 ## Observed behavior REA refuses MZ images whose Windows new-header pointer (`e_lfanew`) lies inside the 64-byte DOS header, before any provider is selected — even when a valid `PE\0\0` signature sits at the declared offset. Canonical case: Sotirov's 97-byte Tiny PE (`e_lfanew = 4`). MCP `open_binary` with `provider_id: "ghidra"` (paths redacted): ```json {"error":{"code":"target_unavailable","category":"unavailable","message":"Cannot open artifact: invalid Windows new-header offset in MZ image. Check that the path exists, is readable, and points to a supported file.","retryable":false,"remediation":{"action":"Cannot open artifact: invalid Windows new-header offset in MZ image. Check that the path exists, is readable, and points to a supported file."},"details":{"path":"<redacted>/tiny.97.exe","reason":"invalid Windows new-header offset in MZ image"}}} ``` `rea inspect --provider ghidra --json ./tiny.97.exe` exits 1 with the same `reason`. (The appended "Check that the path exists, is readable, and points to a supported file." wording is #1979, already fixed on main; it is not part of this report.) The `ghidra` provider is available on this host: `/bin/true` opens through it on the same install (Ghidra 12.1.4 profile). `observeMzWindowsHeader` (`src/domain/dosMz.ts:43`) already computes `signature: "PE"` at the declared offset for this fixture; the guards cited below ignore that observation. - Interface: MCP (the CLI shows the same refusal) - Earliest failure stage: Request parsing or validation (target resolution, before provider selection) ## Reproduction Fixture: 97-byte Tiny PE (`e_lfanew=4`, 1 section, `SizeOfOptionalHeader=4`, COFF machine `0x014c`, optional-header magic `0x10b`): ```sh echo 'TVoAAFBFAABMAQEAaipYwwAAAAAAAAAABAADAQsBCAAEAAAAAAAAAAQAAAAMAAAABAAAAAwAAAAAAEAABAAAAAQAAAAEAAAAAAAAAAQAAAAAAAAAaAAAAGQAAAAAAAAAAg==' | base64 -d > tiny.97.exe sha256sum tiny.97.exe # e872a508a28fe08ad4d309d6949e3dbe26efad305c2c114303e01af1241a6a67 ``` 1. `rea inspect --provider ghidra --json ./tiny.97.exe` → exit 1, reason `invalid Windows new-header offset in MZ image` 2. MCP: `open_binary {path: "./tiny.97.exe"}` → `target_unavailable`, same reason Deterministic on this host across repeat runs. Alternative fixture source: http://www.phreedom.org/research/tinype/tinype.zip. A second fixture — `4KB.exe`, the released executable of "Oscar's Chair" by Eos (4092 B, `MZ20PE`, `e_lfanew=4`, 0 sections, `SizeOfOptionalHeader=8`, sha256 `d00f3da0e3a7ab0ecb43841cd922f6abcb1a40fae9c95f9f0ef38fe6aff1eea9`; provenance in Additional context) — is refused identically. ## Expected behavior An overlapped-but-signature-confirmed PE should be admitted to the PE route. PE/COFF defines `e_lfanew` as a file offset and does not define a 64-byte floor; Windows reads the optional header at fixed offsets, and the smallest known working value (Sotirov, then-current non-2000 Windows) is 4. At minimum, the refusal should be an explicit unsupported-layout reason rather than an "invalid offset" error, so a caller can distinguish a malformed file from an unsupported layout. Grounding: Sotirov's article (the 97-byte file ran on then-current non-2000 Windows); REA's own `inspect_pe_resources` route contains no `e_lfanew` floor (`src/native/pe/PeResourceLayout.ts:65` fails later at `optionalSize < 64`); Ghidra 12.1.4 imports `e_lfanew=4` PEs when file length permits (see Additional context); and a real-world production using this exact layout ("Oscar's Chair", shown at Revision 2018 and ranked 1st) is refused identically. I have not re-executed the files myself; direct execution is marked untested rather than claimed. ## Impact and scope - A whole class (size-optimized/overlapped-header PEs, canonical Tiny PE included) is refused before provider admission; no analysis through native lanes. - Real-world production affected: the secondary fixture is byte-identical to the released executable of "Oscar's Chair" by Eos (Revision 2018 PC 4k compo, ranked 1st). - Available workarounds are semantically wrong (`format:"dos-com"` treats the PE bytes as a headerless 16-bit COM image, 1 segment / 1 procedure) or external. - Refusal is deterministic. No crash, data loss, or evidence-integrity issue observed. ## REA version `rea --version` → `6.4.0`. Both guards verified present on main commit `dfe8378cf5a727e3d93d47a5986233175c6ef898` (2026-10-19) and in the published 6.4.0 build. ## Runtime and platform Node v24.21.0; Ubuntu 24.04 x64 (distrobox container on Bazzite); Ghidra 12.1.4 PUBLIC; provider `ghidra` (hopper/ida not configured; not needed). ## Target and artifact context `tiny.97.exe` — x86 PE32, 97 bytes, sha256 `e872a508a28fe08ad4d309d6949e3dbe26efad305c2c114303e01af1241a6a67`. Secondary: `4KB.exe` — the released executable of "Oscar's Chair" by Eos (Revision 2018 PC 4k compo, ranked 1st), 4092 B, sha256 `d00f3da0e3a7ab0ecb43841cd922f6abcb1a40fae9c95f9f0ef38fe6aff1eea9`; byte-identical to the official scene.org release member, uses the same `e_lfanew=4` overlapped layout, and is refused identically. ## Relevant output or evidence Source refs at main@`dfe8378` ([BinaryTargetResolver.ts#L493-L494](https://github.com/morluto/rea/blob/dfe8378cf5a727e3d93d47a5986233175c6ef898/src/application/BinaryTargetResolver.ts#L493-L494), [binaryTarget.ts#L287-L288](https://github.com/morluto/rea/blob/dfe8378cf5a727e3d93d47a5986233175c6ef898/src/domain/binaryTarget.ts#L287-L288), [dosMz.ts#L43](https://github.com/morluto/rea/blob/dfe8378cf5a727e3d93d47a5986233175c6ef898/src/domain/dosMz.ts#L43), [PeResourceLayout.ts#L65](https://github.com/morluto/rea/blob/dfe8378cf5a727e3d93d47a5986233175c6ef898/src/native/pe/PeResourceLayout.ts#L65), [binaryTarget.ts#L516](https://github.com/morluto/rea/blob/dfe8378cf5a727e3d93d47a5986233175c6ef898/src/domain/binaryTarget.ts#L516)): - Guard 1, application resolver — `src/application/BinaryTargetResolver.ts#L493-L494`: ```ts if (windowsHeader.offset < 64) return err("invalid Windows new-header offset in MZ image"); ``` - Guard 2, domain — `src/domain/binaryTarget.ts#L287-L288`: ```ts if (offset < 64 || offset > bytes.length - 24) return err("invalid or truncated Windows executable header in MZ image"); ``` - `observeMzWindowsHeader` computed `signature: "PE"` at `offset=4` for this fixture (`src/domain/dosMz.ts:43`). - `inspect_pe_resources` on both fixtures → `invalid_format: "Truncated PE optional header."` — a distinct, later limitation (declared `SizeOfOptionalHeader` 4/8 B vs fixed-offset reads), not an offset refusal. - MCP refusal JSON and CLI JSON captured locally (redacted copies available on request). - Missing/uncertain: modern Windows-loader execution untested; Ghidra import logs captured locally (summarized in Additional context). ## Typed outcome or recovery expected Either `pe`/`x86` classification admitted (optionally with a non-standard-layout warning), or a typed unsupported-layout reason distinct from an offset/path error. ## Analysis or suspected cause Source-derived (not a fix commitment): the two `< 64` guards are the blocker on the resolver/domain routes. `observeMzWindowsHeader` already yields `signature: "PE"`, so gating the guards on that observation with a minimum offset of 4 (or documenting the floor as deliberate) resolves the refusal. Follow-on if relaxed: `peManagedStatus` (`src/domain/binaryTarget.ts:516`) requires the declared `SizeOfOptionalHeader` to cover the standard fields, so expect a `truncated PE optional header` refusal next for these fixtures; Windows and Ghidra read those fields at fixed offsets regardless and only warn. Internally, `readPeResourceLayout` keeps no `e_lfanew` floor, so `open_binary` refusing what `inspect_pe_resources` accepts is inconsistent. ## Additional context - Related: [#2172](https://github.com/morluto/rea/issues/2172) (fixed by `c9fed506`, short-DOS-stub classification), [#1979](https://github.com/morluto/rea/issues/1979) (fixed by `f28f3382`, path-advice wording), [#2408](https://github.com/morluto/rea/issues/2408) (NE-support proposal under review). - Ghidra 12.1.4 headless import, run locally on 2026-10-19: - `4KB.exe` (`e_lfanew=4`, 4092 B): **import succeeded** as `x86:LE:32:default:windows`, with `WARN Non-standard optional header size: 8 bytes`. - tiny.97 padded to 512 B (same headers, trailing zeros): **import succeeded**, with `WARN Non-standard optional header size: 4 bytes`. - Canonical 97-byte `tiny.97.exe`: does **not** import in Ghidra either — default loader selection is MZ (import fails), and forced `-loader PeLoader` reports "No load spec found" because its fixed-offset reads run past EOF. That is a file-length limitation, not an `e_lfanew` policy, so it does not weaken the inconsistency above but must not be glossed over. - Fixtures: Sotirov Tiny PE archive, http://www.phreedom.org/research/tinype/ - Provenance of the secondary fixture (verified 2026-10-19): `4KB.exe` is the released executable of "Oscar's Chair" by Eos — [pouët 75721](https://www.pouet.net/prod.php?which=75721) (Windows 4k, Revision 2018 PC 4k compo, ranked 1st; The Meteoriks 2019 winner, Best Small High-End Intro), [Demozoo](https://demozoo.org/productions/185233/). The [scene.org release archive](https://files.scene.org/view/parties/2018/revision18/pc-4k-intro/eos_-_oscars_chair_1280x720.zip) member `eos_-_oscar's_chair_1280x720.exe` is byte-identical (sha256) to the local fixture. It was downloaded, extracted, and hashed only — not executed. 🤖 Prepared with an AI agent (OpenCode) against REA 6.4.0 via MCP; commands were re-run and outputs captured locally.

bsakaguchi commented

2026-10-31 00:37:32 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 19, 2026):

The < 64 guard is a reasonable sanity check for ordinary images, but applying it before checking the PE signature does drop a real class of overlapped-header PEs (Sotirov's Tiny PE being the canonical one). Gating the guard on observeMzWindowsHeader's signature result — allowing e_lfanew >= 4 when the PE\0\0 magic is confirmed at the declared offset — looks like the right minimal fix, plus the typed unsupported-layout reason you propose would make the failure mode much clearer for callers.

I also agree the inconsistency with inspect_pe_resources (which keeps no e_lfanew floor) is worth aligning: open_binary refusing what another route accepts is surprising and hard to debug. The Ghidra comparison strengthens the case that this is a policy decision rather than a malformed-file case, and the 'Oscar's Chair' real-world fixture shows it isn't just synthetic. Good write-up.

@XinwangTao commented on GitHub (Oct 19, 2026): The < 64 guard is a reasonable sanity check for ordinary images, but applying it before checking the PE signature does drop a real class of overlapped-header PEs (Sotirov's Tiny PE being the canonical one). Gating the guard on observeMzWindowsHeader's signature result — allowing e_lfanew >= 4 when the PE\0\0 magic is confirmed at the declared offset — looks like the right minimal fix, plus the typed unsupported-layout reason you propose would make the failure mode much clearer for callers. I also agree the inconsistency with inspect_pe_resources (which keeps no e_lfanew floor) is worth aligning: open_binary refusing what another route accepts is surprising and hard to debug. The Ghidra comparison strengthens the case that this is a policy decision rather than a malformed-file case, and the 'Oscar's Chair' real-world fixture shows it isn't just synthetic. Good write-up.

bsakaguchi commented

2026-10-31 00:37:32 +00:00

Author

Owner

@vanshsharma3777 commented on GitHub (Oct 19, 2026):

I’d like to take this. I plan to go with option A (admit when PE signature confirmed at offset >= 4) and add tests with the Tiny PE fixture. Does that direction work, or do you prefer the typed unsupported-layout reason?

@vanshsharma3777 commented on GitHub (Oct 19, 2026): I’d like to take this. I plan to go with option A (admit when PE signature confirmed at offset >= 4) and add tests with the Tiny PE fixture. Does that direction work, or do you prefer the typed unsupported-layout reason?

bsakaguchi commented

2026-10-31 00:37:32 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 19, 2026):

Both, actually — they're complementary rather than competing. Option A (admit when the PE signature is confirmed at offset >= 4) is the primary fix, and the typed unsupported-layout reason is still worth adding because relaxing the guard doesn't make these fixtures fully analyzable: per the write-up, inspect_pe_resources then fails later on the truncated optional header (SizeOfOptionalHeader 4/8 B vs fixed-offset reads). A caller hitting that next stage should get a distinct reason, not a generic invalid-offset error. So: A for admission, and map the follow-on truncated-optional-header failure to the typed reason. The Tiny PE and 4KB.exe fixtures cover both stages nicely — one test for admission, one asserting the distinct later failure.

@XinwangTao commented on GitHub (Oct 19, 2026): Both, actually — they're complementary rather than competing. Option A (admit when the PE signature is confirmed at offset >= 4) is the primary fix, and the typed unsupported-layout reason is still worth adding because relaxing the guard doesn't make these fixtures fully analyzable: per the write-up, inspect_pe_resources then fails later on the truncated optional header (SizeOfOptionalHeader 4/8 B vs fixed-offset reads). A caller hitting that next stage should get a distinct reason, not a generic invalid-offset error. So: A for admission, and map the follow-on truncated-optional-header failure to the typed reason. The Tiny PE and 4KB.exe fixtures cover both stages nicely — one test for admission, one asserting the distinct later failure.

bsakaguchi commented

2026-10-31 00:37:32 +00:00

Author

Owner

@vanshsharma3777 commented on GitHub (Oct 19, 2026):

PR opened: #5216. It fixes the two offset guards (floor of 4 for signature-confirmed PE). tiny.97.exe is now refused later at peManagedStatus ("truncated PE optional header").

Should I also relax the SizeOfOptionalHeader check in this PR, or handle it in a separate PR?

@vanshsharma3777 commented on GitHub (Oct 19, 2026): PR opened: #5216. It fixes the two offset guards (floor of 4 for signature-confirmed PE). tiny.97.exe is now refused later at peManagedStatus ("truncated PE optional header"). Should I also relax the SizeOfOptionalHeader check in this PR, or handle it in a separate PR?

bsakaguchi commented

2026-10-31 00:37:33 +00:00

Author

Owner

@vanshsharma3777 commented on GitHub (Oct 20, 2026):

Pushed a follow-up commit applying the same minimumWindowsHeaderOffset rule to the independent guards Codex flagged: ArtifactGraphConstruction.ts (inventory now classifies a signature-confirmed overlapped PE as pe; the old “rejects” test is updated accordingly), GoPeImage.ts, and ElectronFuseReader.ts (new regression test with e_lfanew = 4). I did not add an overlapped-header test for the Go reader, because createGoBinaryFixture hardcodes the PE signature at offset 128 and an overlapped Go image would need a larger fixture change; happy to follow up if wanted. The 11 ElectronFuseProvider symlink tests fail on my Windows machine with EPERM both with and without my changes.

@vanshsharma3777 commented on GitHub (Oct 20, 2026): Pushed a follow-up commit applying the same minimumWindowsHeaderOffset rule to the independent guards Codex flagged: ArtifactGraphConstruction.ts (inventory now classifies a signature-confirmed overlapped PE as pe; the old “rejects” test is updated accordingly), GoPeImage.ts, and ElectronFuseReader.ts (new regression test with e_lfanew = 4). I did not add an overlapped-header test for the Go reader, because createGoBinaryFixture hardcodes the PE signature at offset 128 and an overlapped Go image would need a larger fixture change; happy to follow up if wanted. The 11 ElectronFuseProvider symlink tests fail on my Windows machine with EPERM both with and without my changes.

bsakaguchi referenced this issue

2026-10-31 00:40:35 +00:00

[GH-ISSUE #5695] [Bug] Compiled storyboard segues lack connections while connection coverage reports complete #3447

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

No description provided.

Rows
Columns