morluto/rea

Fork 0

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

[GH-ISSUE #8185] [Design] Make native metadata recovery discoverable when class-label inventory is unavailable #6470

New issue

Open

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

bsakaguchi commented

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

Owner

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

Before submitting

I searched open and closed issues and pull requests for a related discussion. #5070 covered capability discovery for the metadata reader; #5424 covers the off-macOS symbol fallback, not this recovery path.
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

When class-label discovery is unavailable because a selected deep provider lacks list_names, should REA direct the caller to separately scoped native dispatch metadata when that reader is available, and clarify the metadata tool's advertised description?

Context and evidence

Observed with an authored, unexecuted arm64 Objective-C Mach-O app, macOS arm64, Ghidra 12.1.4, Kuna 1.986, and REA working tree based on 47fa6ab3795d547207001ffb01643c0aa39dcad8. In the same Kuna MCP session:

get_objc_classes({"pattern":"AuditController"}) fails with capability_unavailable, operation list_names, and generic remediation to choose another analysis or target.
inspect_native_dispatch_metadata({"max_records":100}) succeeds via the local Mach-O metadata reader and reports class AuditController, selector runAction:, and implementation 0x1000008a0, with binary metadata Evidence.
The live tool description starts by saying it inspects the bound provider's name inventory; that wording does not make the working local byte-reader route apparent.

Ghidra's get_objc_classes returns the class label for the same fixture. This is an observed scripted sequence, not an autonomous agent trial or a measured selection failure.

Expected interaction with targets

Read existing files or captured data.

Boundary details (optional)

Class symbols, imported labels, and decoded class records are different evidence and can have different coverage. A native metadata result should not be silently substituted as an equivalent complete name inventory. Preserve target/slice identity, bounded input and record limits, and unsupported or partial facets.

Options and tradeoffs

Consider a conditional recovery hint naming inspect_native_dispatch_metadata when available, plus an accurate description of both native-byte-reader and name-inventory routes. Alternatively expose a consciously scoped combined discovery workflow. The latter needs an explicit contract for labels versus metadata and partial coverage; it should not imply that all providers or formats support the same decoder.

Verification available so far

I have a prototype or observed results.

Success criteria and open questions

On a real or representative Mach-O session with no list_names, an agent should be able to discover a usable metadata route and understand its scope; unavailable readers should not be advertised as universal recovery. Verify symbol-only, metadata-only, unsupported, partial, and imported-class cases.

Originally created by @morluto on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8185 ### Before submitting - [x] I searched open and closed issues and pull requests for a related discussion. #5070 covered capability discovery for the metadata reader; #5424 covers the off-macOS symbol fallback, not this recovery path. - [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 When class-label discovery is unavailable because a selected deep provider lacks `list_names`, should REA direct the caller to separately scoped native dispatch metadata when that reader is available, and clarify the metadata tool's advertised description? ### Context and evidence Observed with an authored, unexecuted arm64 Objective-C Mach-O app, macOS arm64, Ghidra 12.1.4, Kuna 1.986, and REA working tree based on `47fa6ab3795d547207001ffb01643c0aa39dcad8`. In the same Kuna MCP session: 1. `get_objc_classes({"pattern":"AuditController"})` fails with `capability_unavailable`, operation `list_names`, and generic remediation to choose another analysis or target. 2. `inspect_native_dispatch_metadata({"max_records":100})` succeeds via the local Mach-O metadata reader and reports class `AuditController`, selector `runAction:`, and implementation `0x1000008a0`, with binary metadata Evidence. 3. The live tool description starts by saying it inspects the bound provider's name inventory; that wording does not make the working local byte-reader route apparent. Ghidra's `get_objc_classes` returns the class label for the same fixture. This is an observed scripted sequence, not an autonomous agent trial or a measured selection failure. ### Expected interaction with targets Read existing files or captured data. ### Boundary details (optional) Class symbols, imported labels, and decoded class records are different evidence and can have different coverage. A native metadata result should not be silently substituted as an equivalent complete name inventory. Preserve target/slice identity, bounded input and record limits, and unsupported or partial facets. ### Options and tradeoffs Consider a conditional recovery hint naming `inspect_native_dispatch_metadata` when available, plus an accurate description of both native-byte-reader and name-inventory routes. Alternatively expose a consciously scoped combined discovery workflow. The latter needs an explicit contract for labels versus metadata and partial coverage; it should not imply that all providers or formats support the same decoder. ### Verification available so far I have a prototype or observed results. ### Success criteria and open questions On a real or representative Mach-O session with no `list_names`, an agent should be able to discover a usable metadata route and understand its scope; unavailable readers should not be advertised as universal recovery. Verify symbol-only, metadata-only, unsupported, partial, and imported-class cases.

bsakaguchi added the

enhancement

triage

labels

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

bsakaguchi commented

2026-11-01 21:11:24 +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#6470

No description provided.

Rows
Columns