morluto/rea

Fork 0

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

[GH-ISSUE #8166] [Design] Allow analyst assertions in Kuna decompilation with explicit provenance #4690

New issue

Open

opened 2026-10-31 00:52:31 +00:00 by bsakaguchi · 6 comments

bsakaguchi commented

2026-10-31 00:52:31 +00:00

Owner

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

Before submitting

I searched the open and closed issues and pull requests for a related discussion.
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

Should REA offer a narrowly scoped way to supply analyst assertions to Kuna decompilation, and preserve their identity and application results in Evidence?

Context and evidence

REA's Kuna adapter at 47fa6ab3795d547207001ffb01643c0aa39dcad8 invokes single-function kuna decompile ... --addr and kuna decompile-project ... --jobs without assertions; its provider does not support annotation or type recovery. Kuna 1.833, the version REA has verified, documents --assert for caller-supplied function prototypes, names, types and other directives, including file input. It reports applied and rejected directives; some failures are nonfatal by default. These are per-run overrides, not a persisted editable Kuna database. See upstream 1.833 CLI documentation and REA's src/kuna/KunaSessionClient.ts, src/kuna/KunaProjectExport.ts, and docs/kuna-provider.md.

The missing REA assertion input is source-derived; the real-provider observations below exercise direct Kuna assertions. No demand measurement has been performed. Upstream also supports directives affecting control flow and image bytes; treating all assertions as harmless comments would be incorrect.

Expected interaction with targets

Read selected local binaries and possibly selected assertion files; launch a caller-supplied Kuna process; apply explicit overrides to analysis state. Not sure yet which assertion categories should be admitted. No executable modification is proposed.

Boundary details (optional)

Caller assertions must remain distinct from observed facts. Bind the exact assertion content and all referenced data to target/provider/profile and cache identity; report applied, rejected and unknown outcomes. Do not silently return an unmodified cached export. Upstream's --assert has interactions with parallel and streaming modes and can reference external files; consider a narrower typed subset before any general pass-through.

Options and tradeoffs

Compare a typed per-function prototype/name/type input, a reusable explicit assertion document, and use of the native Kuna CLI. Define which reads and workflows honor each input and whether edits should persist across session closure. Avoid conflating Kuna's C export with an editable Ghidra project.

Verification available so far

I can suggest a sample or manual check

Success criteria and open questions

Decide the capability and maintainer scope before substantial integration. On a self-owned fixture, verify a visible changed result, individual rejected and partial assertions, identity mismatch, version capability detection, cache separation, and both CLI/MCP paths. Report unverified upstream versions and effect boundaries.

References

Kuna provider: github.com/morluto/rea@47fa6ab379/docs/kuna-provider.md

Additional real-provider observation

On macOS arm64 with the official Kuna 1.833 release and a small self-built Mach-O, direct kuna decompile ... --json produced int _target(int a0). Adding --assert 'prototype target long target(long input)' produced long _target(long input) and reported that directive as applied. A deliberately nonexistent local rename was separately reported rejected and nonfatal. In a real REA stdio MCP session, annotate_native_function returned capability_unavailable for Kuna. REA pseudocode and assembly succeeded; the first pseudocode came from a single-function run and a later read from the completed export. This is a small fixture and does not verify assertion handling through REA, other directive kinds, or large-target behavior.

A further direct Kuna 1.833 check used a self-built function reading a volatile global initialized to 3. The readonly assertion for that global was reported applied and changed the decompiled expression from a0 + global_count to a0 + 3. Separate function-name and instruction-comment assertions were reflected in output, and an invalid local-name assertion was reported rejected without a nonzero exit. This demonstrates that assertions can change analysis interpretation, not merely display labels; it is not proof the asserted readonly assumption is true at runtime. Exact target bytes remained unchanged.

A separate direct bytes assertion replaced the first analyzed instruction with an ARM64 ret in the in-memory image. Kuna reported it applied and changed the pseudocode to an immediate return; the original fixture's SHA-256 remained unchanged. Such byte overlays are an analysis mutation with a distinct scope decision, not an ordinary naming annotation. No protected or packed code was involved.

On the same self-built fixture, a direct call combining typedef, prototype, type, and name assertions changed array-like a0[1]/*a0 pseudocode into record->flags/record->id and named the result variable; Kuna reported all four directives applied. This illustrates a concrete analyst task that changes interpretation and usability, but the asserted type layout remains caller-supplied rather than an independently established source fact.

For selection UX, direct Kuna JSON on _evaluate also returned variable records with name, kind, type, storage size, stack offset and associated instruction addresses. REA's Kuna pseudocode currently comes from text or cached export, so investigate whether the information needed to select and verify a typed hypothesis can be exposed with stable identities and explicit uncertainty rather than relying on the spelling of a decompiler temporary. No general stability or accuracy of those upstream records is established by this fixture.

Cross-provider analyst workflow to consider

The same analyst task can matter across providers even though their mechanisms differ. On a self-built arm64 Mach-O, a native Ghidra 12.1.4 headless script created a structure and applied a pointer parameter and function signature in a new project. Opening that selected project in REA then returned pseudocode using record->flags and record->id, and inspect_native_data_type returned the structure fields. This exercises Ghidra project reuse and type inspection, not type editing through REA. A first failed name lookup and a second attempt with an incorrect pointer width illustrate the need to report failures and use target-aware layouts; the corrected eight-byte pointer produced the result. A comparable direct Kuna assertion is described above.

Consider whether a common analyst-facing type/signature hypothesis can serve both engines, while preserving provider-specific capabilities, explicit caller provenance, application outcomes, target identity and effects on cached analysis. Do not assume a Ghidra project edit and a Kuna per-run assertion have the same lifecycle. Existing Ghidra project saving/reopening is separately discussed in #8165, and #6405 intentionally excludes types and prototypes. This is a design question, not an implementation or a request to expose arbitrary engine APIs; Windows P0 remains read-only and applicable scope decisions are required.

Kuna 1.989 assertion outcomes differ by invocation

On macOS arm64 with Kuna 1.989 and an unexecuted, source-built Mach-O (SHA-256 b814f3cc4226f9fe3788dedf8a14f869ca45339c5f49fc2a7709eddd2df0bd6b), I passed a prototype changing _evaluate to long _evaluate(long analyst_input) together with a deliberately nonexistent local rename. Single-function JSON returned the changed body and separate ordered assertion rows: prototype applied, rename rejected with fatal: false and a reason. The default run exited 0; --assert-strict exited 1 but still returned the changed body and the same two outcomes.

A serial decompile-project --jobs 1 with those assertions wrote the changed C export and emitted the rejected rename on stderr, while exiting 0. The strict project run wrote the export and exited 1. A project run with --jobs 2 rejected assertions before export because the worker pool cannot merge their outcomes. functions --json accepted a prototype assertion, but in this control its JSON had no per-assertion outcome array; even a prototype naming a nonexistent function exited 0 without an outcome or warning. That does not establish whether another inventory directive or invocation reports more information.

These observations suggest per-workflow outcomes cannot be inferred from exit status, artifact existence, or inventory alone. An REA design would need to preserve partial success and the actual producer's outcome channel, distinguish unobserved from applied, and account for concurrency before cache publication. No assertion was applied through REA, no target was executed, and the target digest was unchanged. Arbitrary analysis mutations remain a separate scope question.

Originally created by @morluto on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8166 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#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 Should REA offer a narrowly scoped way to supply analyst assertions to Kuna decompilation, and preserve their identity and application results in Evidence? ### Context and evidence REA's Kuna adapter at `47fa6ab3795d547207001ffb01643c0aa39dcad8` invokes single-function `kuna decompile ... --addr` and `kuna decompile-project ... --jobs` without assertions; its provider does not support annotation or type recovery. Kuna 1.833, the version REA has verified, documents `--assert` for caller-supplied function prototypes, names, types and other directives, including file input. It reports applied and rejected directives; some failures are nonfatal by default. These are per-run overrides, not a persisted editable Kuna database. See [upstream 1.833 CLI documentation](https://github.com/Noelo-Lab/kuna/blob/v1.833/docs/cli.md) and REA's `src/kuna/KunaSessionClient.ts`, `src/kuna/KunaProjectExport.ts`, and `docs/kuna-provider.md`. The missing REA assertion input is source-derived; the real-provider observations below exercise direct Kuna assertions. No demand measurement has been performed. Upstream also supports directives affecting control flow and image bytes; treating all assertions as harmless comments would be incorrect. ### Expected interaction with targets Read selected local binaries and possibly selected assertion files; launch a caller-supplied Kuna process; apply explicit overrides to analysis state. Not sure yet which assertion categories should be admitted. No executable modification is proposed. ### Boundary details (optional) Caller assertions must remain distinct from observed facts. Bind the exact assertion content and all referenced data to target/provider/profile and cache identity; report applied, rejected and unknown outcomes. Do not silently return an unmodified cached export. Upstream's `--assert` has interactions with parallel and streaming modes and can reference external files; consider a narrower typed subset before any general pass-through. ### Options and tradeoffs Compare a typed per-function prototype/name/type input, a reusable explicit assertion document, and use of the native Kuna CLI. Define which reads and workflows honor each input and whether edits should persist across session closure. Avoid conflating Kuna's C export with an editable Ghidra project. ### Verification available so far I can suggest a sample or manual check ### Success criteria and open questions Decide the capability and maintainer scope before substantial integration. On a self-owned fixture, verify a visible changed result, individual rejected and partial assertions, identity mismatch, version capability detection, cache separation, and both CLI/MCP paths. Report unverified upstream versions and effect boundaries. ### References Kuna provider: https://github.com/morluto/rea/blob/47fa6ab3795d547207001ffb01643c0aa39dcad8/docs/kuna-provider.md ### Additional real-provider observation On macOS arm64 with the official Kuna 1.833 release and a small self-built Mach-O, direct `kuna decompile ... --json` produced `int _target(int a0)`. Adding `--assert 'prototype target long target(long input)'` produced `long _target(long input)` and reported that directive as applied. A deliberately nonexistent local rename was separately reported rejected and nonfatal. In a real REA stdio MCP session, `annotate_native_function` returned `capability_unavailable` for Kuna. REA pseudocode and assembly succeeded; the first pseudocode came from a single-function run and a later read from the completed export. This is a small fixture and does not verify assertion handling through REA, other directive kinds, or large-target behavior. A further direct Kuna 1.833 check used a self-built function reading a volatile global initialized to 3. The `readonly` assertion for that global was reported applied and changed the decompiled expression from `a0 + global_count` to `a0 + 3`. Separate function-name and instruction-comment assertions were reflected in output, and an invalid local-name assertion was reported rejected without a nonzero exit. This demonstrates that assertions can change analysis interpretation, not merely display labels; it is not proof the asserted readonly assumption is true at runtime. Exact target bytes remained unchanged. A separate direct `bytes` assertion replaced the first analyzed instruction with an ARM64 `ret` in the in-memory image. Kuna reported it applied and changed the pseudocode to an immediate return; the original fixture's SHA-256 remained unchanged. Such byte overlays are an analysis mutation with a distinct scope decision, not an ordinary naming annotation. No protected or packed code was involved. On the same self-built fixture, a direct call combining `typedef`, `prototype`, `type`, and `name` assertions changed array-like `a0[1]`/`*a0` pseudocode into `record->flags`/`record->id` and named the result variable; Kuna reported all four directives applied. This illustrates a concrete analyst task that changes interpretation and usability, but the asserted type layout remains caller-supplied rather than an independently established source fact. For selection UX, direct Kuna JSON on `_evaluate` also returned variable records with name, kind, type, storage size, stack offset and associated instruction addresses. REA's Kuna pseudocode currently comes from text or cached export, so investigate whether the information needed to select and verify a typed hypothesis can be exposed with stable identities and explicit uncertainty rather than relying on the spelling of a decompiler temporary. No general stability or accuracy of those upstream records is established by this fixture. ### Cross-provider analyst workflow to consider The same analyst task can matter across providers even though their mechanisms differ. On a self-built arm64 Mach-O, a native Ghidra 12.1.4 headless script created a structure and applied a pointer parameter and function signature in a new project. Opening that selected project in REA then returned pseudocode using `record->flags` and `record->id`, and `inspect_native_data_type` returned the structure fields. This exercises Ghidra project reuse and type inspection, not type editing through REA. A first failed name lookup and a second attempt with an incorrect pointer width illustrate the need to report failures and use target-aware layouts; the corrected eight-byte pointer produced the result. A comparable direct Kuna assertion is described above. Consider whether a common analyst-facing type/signature hypothesis can serve both engines, while preserving provider-specific capabilities, explicit caller provenance, application outcomes, target identity and effects on cached analysis. Do not assume a Ghidra project edit and a Kuna per-run assertion have the same lifecycle. Existing Ghidra project saving/reopening is separately discussed in #8165, and #6405 intentionally excludes types and prototypes. This is a design question, not an implementation or a request to expose arbitrary engine APIs; Windows P0 remains read-only and applicable scope decisions are required. ### Kuna 1.989 assertion outcomes differ by invocation On macOS arm64 with Kuna 1.989 and an unexecuted, source-built Mach-O (SHA-256 `b814f3cc4226f9fe3788dedf8a14f869ca45339c5f49fc2a7709eddd2df0bd6b`), I passed a prototype changing `_evaluate` to `long _evaluate(long analyst_input)` together with a deliberately nonexistent local rename. Single-function JSON returned the changed body and separate ordered assertion rows: prototype `applied`, rename `rejected` with `fatal: false` and a reason. The default run exited 0; `--assert-strict` exited 1 but still returned the changed body and the same two outcomes. A serial `decompile-project --jobs 1` with those assertions wrote the changed C export and emitted the rejected rename on stderr, while exiting 0. The strict project run wrote the export and exited 1. A project run with `--jobs 2` rejected assertions before export because the worker pool cannot merge their outcomes. `functions --json` accepted a prototype assertion, but in this control its JSON had no per-assertion outcome array; even a prototype naming a nonexistent function exited 0 without an outcome or warning. That does not establish whether another inventory directive or invocation reports more information. These observations suggest per-workflow outcomes cannot be inferred from exit status, artifact existence, or inventory alone. An REA design would need to preserve partial success and the actual producer's outcome channel, distinguish unobserved from applied, and account for concurrency before cache publication. No assertion was applied through REA, no target was executed, and the target digest was unchanged. Arbitrary analysis mutations remain a separate scope question.

bsakaguchi added the

triage

enhancement

labels

2026-10-31 00:52:31 +00:00

bsakaguchi referenced this issue

2026-10-31 01:13:50 +00:00

[PR #4691] [MERGED] test(ci): align fixtures with runtime and evidence contracts #6359

bsakaguchi added

enhancement

and removed

enhancement

labels

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

bsakaguchi commented

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

Author

Owner

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

Additional isolated upstream Ghidra experiment on macOS arm64/Ghidra 12.1.4: a headless post-script imported the same small, self-owned Mach-O into a temporary project with -readOnly -deleteProject, cleared one instruction from the listing, changed four bytes in the in-memory Program, and disassembled again. A fresh decompiler interface changed the entry's pseudocode from return 0; to return 0x2a;. The script read back the modified Program bytes; the original file SHA-256 remained a6bd938bf4ae8031a33d270ca7698ee1ced5b78347a9c4fa3750b0e57f6b126c, and the temporary project directory was empty afterward. The target was not executed.

This is direct Ghidra API behavior, not an REA capability or a proposal to add arbitrary patching. In this headless experiment -readOnly prevented saving the project but did not make the in-memory Program immutable to a script. Together with the direct Kuna byte-overlay observation above, it illustrates that analysis-byte hypotheses alter interpretation and require distinct authority, provenance, cache and lifecycle decisions before any integration; unchanged source bytes alone do not make them equivalent to naming annotations.

@morluto commented on GitHub (Oct 30, 2026): Additional isolated upstream Ghidra experiment on macOS arm64/Ghidra 12.1.4: a headless post-script imported the same small, self-owned Mach-O into a temporary project with `-readOnly -deleteProject`, cleared one instruction from the listing, changed four bytes in the in-memory Program, and disassembled again. A fresh decompiler interface changed the entry's pseudocode from `return 0;` to `return 0x2a;`. The script read back the modified Program bytes; the original file SHA-256 remained `a6bd938bf4ae8031a33d270ca7698ee1ced5b78347a9c4fa3750b0e57f6b126c`, and the temporary project directory was empty afterward. The target was not executed. This is direct Ghidra API behavior, not an REA capability or a proposal to add arbitrary patching. In this headless experiment `-readOnly` prevented saving the project but did not make the in-memory Program immutable to a script. Together with the direct Kuna byte-overlay observation above, it illustrates that analysis-byte hypotheses alter interpretation and require distinct authority, provenance, cache and lifecycle decisions before any integration; unchanged source bytes alone do not make them equivalent to naming annotations.

bsakaguchi commented

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

Author

Owner

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

Further direct Kuna 1.986 checks on the owned arm64 Mach-O, not integrated into REA:

--assert 'param 0 x0 unsigned int *record' plus --assert 'return w0 int' reported both directives applied and rendered the corresponding parameter name/type and return type.
--assert 'data 0x100004000 int audit_counter' reported applied and rendered the global under that caller-supplied name.
--assert 'flow 0x100000458 return' exited 1 and returned an assertion row with status: rejected, fatal: true, and Do not currently support complex overrides. Its JSON also contained C that was produced without the requested flow override, and the run-level error said the directive was refused.

These checks are one fixture and do not establish general directive support or correctness. They illustrate why any analyst-hypothesis workflow must bind each directive's outcome and distinguish a fatal rejected flow change from an ordinary successful decompile, even if the provider emits text. No target bytes were changed or executed; a control-flow override remains a separate scope decision.

A mixed strict-mode run on 1.986 supplied an applicable parameter directive and a nonexistent local rename. Kuna emitted the applied parameter and rejected name as separate assertion rows, kept the applied parameter in the emitted signature, and exited 1 under --assert-strict; its JSON run-level error was null while stderr reported the rejection. Therefore a consumer cannot determine strict-mode success solely from that JSON field; it must preserve process outcome and per-directive facts. This differs from the fatal flow-refusal example above.

@morluto commented on GitHub (Oct 30, 2026): Further direct Kuna 1.986 checks on the owned arm64 Mach-O, not integrated into REA: - `--assert 'param 0 x0 unsigned int *record'` plus `--assert 'return w0 int'` reported both directives applied and rendered the corresponding parameter name/type and return type. - `--assert 'data 0x100004000 int audit_counter'` reported applied and rendered the global under that caller-supplied name. - `--assert 'flow 0x100000458 return'` exited 1 and returned an assertion row with `status: rejected`, `fatal: true`, and `Do not currently support complex overrides`. Its JSON also contained C that was produced **without** the requested flow override, and the run-level error said the directive was refused. These checks are one fixture and do not establish general directive support or correctness. They illustrate why any analyst-hypothesis workflow must bind each directive's outcome and distinguish a fatal rejected flow change from an ordinary successful decompile, even if the provider emits text. No target bytes were changed or executed; a control-flow override remains a separate scope decision. A mixed strict-mode run on 1.986 supplied an applicable parameter directive and a nonexistent local rename. Kuna emitted the applied parameter and rejected name as separate assertion rows, kept the applied parameter in the emitted signature, and exited 1 under `--assert-strict`; its JSON run-level `error` was null while stderr reported the rejection. Therefore a consumer cannot determine strict-mode success solely from that JSON field; it must preserve process outcome and per-directive facts. This differs from the fatal flow-refusal example above.

bsakaguchi commented

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

Author

Owner

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

A Ghidra type-discovery control is relevant before designing type hypotheses: in a selected read-only project, the same display name Record existed in two categories. inspect_native_api exposed a function parameter as Record * with its user-defined/locked provenance, but not which category it pointed to. Exact type inspection succeeded for both distinct structures; an independently typed data address identified the other structure. A real headless HighFunction control identified the parameter's wire-structure pointee, while its ephemeral pointer path differed from the saved pointer path. #8219 covers this existing read-only handoff separately from whether REA should apply type assertions; it does not propose automatic matching by type name or claim original-source authority.

@morluto commented on GitHub (Oct 30, 2026): A Ghidra type-discovery control is relevant before designing type hypotheses: in a selected read-only project, the same display name `Record` existed in two categories. `inspect_native_api` exposed a function parameter as `Record *` with its user-defined/locked provenance, but not which category it pointed to. Exact type inspection succeeded for both distinct structures; an independently typed data address identified the *other* structure. A real headless HighFunction control identified the parameter's wire-structure pointee, while its ephemeral pointer path differed from the saved pointer path. #8219 covers this existing read-only handoff separately from whether REA should apply type assertions; it does not propose automatic matching by type name or claim original-source authority.

bsakaguchi commented

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

Author

Owner

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

A direct Kuna 1.986 assertion-file control adds evidence about identity and export behavior. On the owned Mach-O, an @file contained a prototype assertion for _adjust and a deliberately invalid local-name assertion. Single-function JSON with alpha in the prototype returned alpha pseudocode and separate applied/rejected directive rows; non-strict exit was 0 and strict exit was 1 while still returning the applied prototype and code. Rewriting the same file path to use beta changed the file SHA-256 and the pseudocode to beta. This is why the content, not just the path, must be bound to any future result/cache identity.

With the beta file, direct decompile-project --jobs 1 completed with the prototype in .c/.h and the rejected directive warning on stderr. --assert-strict exited 1 but still wrote project artifacts; on this fixture I did not find the rejection in the emitted README, C or header, so process exit, diagnostics and per-directive outcomes must not be conflated with the existence of output files. --jobs 2 refused the combination with exit 2 and an explicit per-load assertion-state explanation; --stream likewise refused it with exit 2. Serial --progress succeeded and its .c, .h and .asm hashes matched the serial non-progress export on this fixture. These are direct upstream results, not REA support for assertions, nor proof for all versions/directive combinations. The target SHA-256 was unchanged and the target was not executed.

@morluto commented on GitHub (Oct 30, 2026): A direct Kuna 1.986 assertion-file control adds evidence about identity and export behavior. On the owned Mach-O, an `@file` contained a prototype assertion for `_adjust` and a deliberately invalid local-name assertion. Single-function JSON with `alpha` in the prototype returned `alpha` pseudocode and separate applied/rejected directive rows; non-strict exit was 0 and strict exit was 1 while still returning the applied prototype and code. Rewriting the *same file path* to use `beta` changed the file SHA-256 and the pseudocode to `beta`. This is why the content, not just the path, must be bound to any future result/cache identity. With the `beta` file, direct `decompile-project --jobs 1` completed with the prototype in `.c`/`.h` and the rejected directive warning on stderr. `--assert-strict` exited 1 but still wrote project artifacts; on this fixture I did not find the rejection in the emitted README, C or header, so process exit, diagnostics and per-directive outcomes must not be conflated with the existence of output files. `--jobs 2` refused the combination with exit 2 and an explicit per-load assertion-state explanation; `--stream` likewise refused it with exit 2. Serial `--progress` succeeded and its `.c`, `.h` and `.asm` hashes matched the serial non-progress export on this fixture. These are direct upstream results, not REA support for assertions, nor proof for all versions/directive combinations. The target SHA-256 was unchanged and the target was not executed.

bsakaguchi commented

2026-11-01 21:11:15 +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.

bsakaguchi commented

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

Author

Owner

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

I extended the selected-project control to a parameter rename and a local rename applied by native Ghidra on an owned project copy. REA's selected-project pseudocode reflected both, inspect_native_api surfaced the parameter name and user-defined signature source, and procedure_info displayed the local with its storage. Direct Ghidra inspection separately distinguished the original local's DEFAULT source from the renamed local's USER_DEFINED source, while REA's local projection reported database provenance for both. The source target and both selected projects stayed unchanged during the read-only REA runs.

This is a read-side representation question, not authorization for local/type edits or evidence that a caller's label is correct. Filed #8314 to examine structured selection and provenance alongside this broader analyst-hypothesis discussion. Direct headless changes were made only to the disposable project copy; no target ran.

@morluto commented on GitHub (Oct 31, 2026): I extended the selected-project control to a parameter rename and a local rename applied by native Ghidra on an owned project copy. REA's selected-project pseudocode reflected both, `inspect_native_api` surfaced the parameter name and user-defined signature source, and `procedure_info` displayed the local with its storage. Direct Ghidra inspection separately distinguished the original local's `DEFAULT` source from the renamed local's `USER_DEFINED` source, while REA's local projection reported database provenance for both. The source target and both selected projects stayed unchanged during the read-only REA runs. This is a read-side representation question, not authorization for local/type edits or evidence that a caller's label is correct. Filed #8314 to examine structured selection and provenance alongside this broader analyst-hypothesis discussion. Direct headless changes were made only to the disposable project copy; no target ran.

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-11-03 13:27:01 +00:00

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

No description provided.

Rows
Columns