morluto/rea

Fork 0

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

[GH-ISSUE #8210] [Design] Clarify ARM-state raw entry errors when Thumb may be intended #6485

New issue

Open

opened 2026-11-01 21:11:32 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-11-01 21:11:32 +00:00

Owner

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

Before submitting

I searched open and closed issues and pull requests for a related discussion. #8175 covers a possible Kuna raw-image lane; #4246 covers independent base and entry selection.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This discussion does not include credentials, private samples, or sensitive target data.

Decision needed

Can the raw ARM entry-alignment error help an agent recognize that an odd entry might be a Thumb function pointer and that the current raw Thumb mode is unsupported, without assuming the user's target mode or silently changing the entry?

Context and evidence

I created the four bytes 2a 20 70 47 as a self-owned raw fixture (SHA-256 d29f8ddbf1e3e5e07abd19502b295f7e6e33b8aa76766263731f635105b94989), and did not execute it.

Direct Kuna 1.986, explicitly asked for --raw-image --target ARM:LE:32:v4t:default --base 0x4000 --isa thumb and entry 0x4001, normalized the function entry to 0x4000 and decompiled return 0x2a;.
Real REA MCP open_binary with format:"raw-binary", architecture:"arm", and entry_point:"0x4001" rejected it as not four-byte aligned. That is consistent with the current ARM-state raw boundary; the error's remediation said to correct the load argument, without identifying the separate unsupported Thumb mode.
When separately opened at 0x4000 under the caller-selected ARM mode with Ghidra 12.1.4, inspect_native_instruction reported TMode: 0 and decoded all four bytes as one ARM instruction; pseudocode warned about bad instruction data. The Evidence limitations correctly stated that Thumb-only raw analysis is unsupported. This is the expected consequence of selecting ARM for Thumb bytes, not evidence that REA promised to infer their mode.
REA/Kuna rejected the even raw target as unsupported under its documented thin Mach-O/ELF boundary.

Expected interaction with targets

Read caller-selected bytes and launch a static provider; no target execution or mutation.

Boundary details (optional)

Odd ARM addresses may encode Thumb state, but an odd invalid input does not itself prove the intended mode. Base mapping, actual entry, architecture, state and caller intent are distinct. Do not silently mask the low bit, reinterpret an ARM request, or change the selected provider. Keep the current unsupported-mode boundary unless separately designed and verified.

Options and tradeoffs

Consider context-specific diagnostics that mention the raw ARM-state scope and a possible Thumb pointer, with a clear unsupported/unknown result. Investigate an explicit mode selector separately, reusing typed target identity and byte/entry validation rather than just passing --isa. The reported user behavior is a scripted sequence, not an autonomous agent failure or prevalence claim.

Verification available so far

I have a prototype or observed results.

Success criteria and open questions

Exercise ARM and Thumb inputs, aligned and odd addresses, separate base/entry semantics, CLI/MCP parity, invalid mappings and unsupported hosts. Verify errors never instruct a caller to normalize an address without an explicit mode choice.

References

Related: #8175 and #4246. REA d48e472fa plus unrelated Kuna baseline changes from #8187; macOS arm64.

Originally created by @morluto on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8210 ### Before submitting - [x] I searched open and closed issues and pull requests for a related discussion. #8175 covers a possible Kuna raw-image lane; #4246 covers independent base and entry selection. - [x] I understand the contribution scope must be reviewed before integration; open questions are welcome here. - [x] This discussion does not include credentials, private samples, or sensitive target data. ### Decision needed Can the raw ARM entry-alignment error help an agent recognize that an odd entry might be a Thumb function pointer and that the current raw Thumb mode is unsupported, without assuming the user's target mode or silently changing the entry? ### Context and evidence I created the four bytes `2a 20 70 47` as a self-owned raw fixture (SHA-256 `d29f8ddbf1e3e5e07abd19502b295f7e6e33b8aa76766263731f635105b94989`), and did not execute it. - Direct Kuna 1.986, explicitly asked for `--raw-image --target ARM:LE:32:v4t:default --base 0x4000 --isa thumb` and entry `0x4001`, normalized the function entry to `0x4000` and decompiled `return 0x2a;`. - Real REA MCP `open_binary` with `format:"raw-binary"`, `architecture:"arm"`, and `entry_point:"0x4001"` rejected it as not four-byte aligned. That is consistent with the current ARM-state raw boundary; the error's remediation said to correct the load argument, without identifying the separate unsupported Thumb mode. - When separately opened at `0x4000` under the caller-selected ARM mode with Ghidra 12.1.4, `inspect_native_instruction` reported `TMode: 0` and decoded all four bytes as one ARM instruction; pseudocode warned about bad instruction data. The Evidence limitations correctly stated that Thumb-only raw analysis is unsupported. This is the expected consequence of selecting ARM for Thumb bytes, not evidence that REA promised to infer their mode. - REA/Kuna rejected the even raw target as unsupported under its documented thin Mach-O/ELF boundary. ### Expected interaction with targets Read caller-selected bytes and launch a static provider; no target execution or mutation. ### Boundary details (optional) Odd ARM addresses may encode Thumb state, but an odd invalid input does not itself prove the intended mode. Base mapping, actual entry, architecture, state and caller intent are distinct. Do not silently mask the low bit, reinterpret an ARM request, or change the selected provider. Keep the current unsupported-mode boundary unless separately designed and verified. ### Options and tradeoffs Consider context-specific diagnostics that mention the raw ARM-state scope and a possible Thumb pointer, with a clear unsupported/unknown result. Investigate an explicit mode selector separately, reusing typed target identity and byte/entry validation rather than just passing `--isa`. The reported user behavior is a scripted sequence, not an autonomous agent failure or prevalence claim. ### Verification available so far I have a prototype or observed results. ### Success criteria and open questions Exercise ARM and Thumb inputs, aligned and odd addresses, separate base/entry semantics, CLI/MCP parity, invalid mappings and unsupported hosts. Verify errors never instruct a caller to normalize an address without an explicit mode choice. ### References Related: #8175 and #4246. REA `d48e472fa` plus unrelated Kuna baseline changes from #8187; macOS arm64.

bsakaguchi added the

enhancement

triage

labels

2026-11-01 21:11:32 +00:00

bsakaguchi commented

2026-11-01 21:11:33 +00:00

Author

Owner

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

Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the Ghidra, Kuna, and REA tool-design investigation.

@morluto commented on GitHub (Oct 31, 2026): Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the Ghidra, Kuna, and REA tool-design investigation.

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

No description provided.

Rows
Columns