morluto/rea

Fork 0

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

[GH-ISSUE #2078] decompile rejects file offsets — Ghidra image-base rebase is invisible to the caller #689

New issue

Closed

opened 2026-10-15 18:27:24 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

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

Owner

Originally created by @nosmile99 on GitHub (Oct 12, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2078

What I did

Analyzed a 368 KB stripped ELF (x86-64 PIE, Rust binary) with rea-agents@6.4.0 + Ghidra 12.1.2 (Temurin JDK 21). rea analyze returns a solid evidence envelope. Then:

rea decompile ./target 0x134e0
# -> "No procedure exists at the requested address"

0x134e0 is the true ELF entry point per readelf -h. The call only succeeds as 0x1134e0.

Root cause

Ghidra rebases the image to 0x100000, and nothing in analyze/decompile output tells the caller. I derived the rebase by hand from segment dumps + readelf. There is an address-to-file-offset command but no documented reverse mapping, so a caller working from readelf/objdump output (file offsets — the natural starting point) always hits this wall on the first try.

Why it matters

REA is pitched at coding agents. An agent will typically start from file offsets (entry point, symbol offsets from readelf -s, offsets from strings/xrefs) and has no reason to know about the silent rebase. This turns every first decompile attempt on a stripped binary into a guess-and-retry loop.

Suggestion

Either:

Accept file offsets in decompile and map them internally via the image base, or
Surface the image base in analyze output (e.g. an image_base field in the evidence envelope) and document the file-offset -> analysis-address mapping.

Option 1 is friendlier for agentic callers; option 2 is the minimal honest fix.

Originally created by @nosmile99 on GitHub (Oct 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2078 ## What I did Analyzed a 368 KB stripped ELF (x86-64 PIE, Rust binary) with `rea-agents@6.4.0` + Ghidra 12.1.2 (Temurin JDK 21). `rea analyze` returns a solid evidence envelope. Then: ``` rea decompile ./target 0x134e0 # -> "No procedure exists at the requested address" ``` `0x134e0` is the true ELF entry point per `readelf -h`. The call only succeeds as `0x1134e0`. ## Root cause Ghidra rebases the image to `0x100000`, and nothing in `analyze`/`decompile` output tells the caller. I derived the rebase by hand from segment dumps + readelf. There is an `address-to-file-offset` command but no documented reverse mapping, so a caller working from `readelf`/`objdump` output (file offsets — the natural starting point) always hits this wall on the first try. ## Why it matters REA is pitched at coding agents. An agent will typically start from file offsets (entry point, symbol offsets from `readelf -s`, offsets from strings/xrefs) and has no reason to know about the silent rebase. This turns every first `decompile` attempt on a stripped binary into a guess-and-retry loop. ## Suggestion Either: 1. Accept file offsets in `decompile` and map them internally via the image base, or 2. Surface the image base in `analyze` output (e.g. an `image_base` field in the evidence envelope) and document the file-offset -> analysis-address mapping. Option 1 is friendlier for agentic callers; option 2 is the minimal honest fix.

bsakaguchi

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

closed this issue
added the
area: native

P1: high

bug
labels

bsakaguchi commented

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

Author

Owner

@matbrgz commented on GitHub (Oct 12, 2026):

Address Translation & Rebasing Transparency Review

The discrepancy between raw ELF file offsets and Ghidra's virtual image base (0x100000 default rebase for PIE/position-independent executables) is a common point of friction for agents:

Address Transparency: REA must either:
1. Clearly report the effective loaded image base in the initial target metadata evidence (image_base: "0x100000", rebased: true).
2. Or enhance address parameter resolution in decompile to automatically translate raw file offsets to virtual addresses when the input matches a valid section file offset.

@matbrgz commented on GitHub (Oct 12, 2026): ### Address Translation & Rebasing Transparency Review The discrepancy between raw ELF file offsets and Ghidra's virtual image base (`0x100000` default rebase for PIE/position-independent executables) is a common point of friction for agents: - **Address Transparency:** REA must either: 1. Clearly report the effective loaded image base in the initial target metadata evidence (`image_base: "0x100000"`, `rebased: true`). 2. Or enhance address parameter resolution in `decompile` to automatically translate raw file offsets to virtual addresses when the input matches a valid section file offset.

bsakaguchi commented

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

Author

Owner

@nosmile99 commented on GitHub (Oct 13, 2026):

Thanks for the analysis — agree on both fronts. My preference is option 1 (accept file offsets in decompile and map internally) as the primary fix, since agentic callers naturally start from readelf/objdump output; the image_base field in the evidence envelope (option 2) is the minimal honest step either way. Also worth surfacing: the existing address-to-file-offset command already gives the reverse mapping, so documenting the pair would already remove the guess-and-retry loop.

@nosmile99 commented on GitHub (Oct 13, 2026): Thanks for the analysis — agree on both fronts. My preference is option 1 (accept file offsets in `decompile` and map internally) as the primary fix, since agentic callers naturally start from `readelf`/`objdump` output; the `image_base` field in the evidence envelope (option 2) is the minimal honest step either way. Also worth surfacing: the existing `address-to-file-offset` command already gives the reverse mapping, so documenting the pair would already remove the guess-and-retry loop.

bsakaguchi commented

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

Author

Owner

@nosmile99 commented on GitHub (Oct 13, 2026):

Noting the closure — thanks for triaging this as a P1. Is there a resolution path I should watch (fix commit, option 1 file-offset mapping or option 2 image_base in the evidence envelope)? Happy to re-test a build against the stripped-ELF repro from the original report.

@nosmile99 commented on GitHub (Oct 13, 2026): Noting the closure — thanks for triaging this as a P1. Is there a resolution path I should watch (fix commit, option 1 file-offset mapping or option 2 image_base in the evidence envelope)? Happy to re-test a build against the stripped-ELF repro from the original report.

bsakaguchi referenced this issue

2026-10-15 18:28:29 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-16 21:15:11 +00:00

[PR #689] [CLOSED] fix(browser): reject malformed indexed source-map offsets #2170

bsakaguchi referenced this issue

2026-10-16 21:15:24 +00:00

[PR #705] [MERGED] fix: integrate 14 approved fix PRs (668,671,673,675,678-681,685-690) #2185