[GH-ISSUE #1634] [Feature] Ghidra: admit set_address_name / set_addresses_names #555

New issue

Closed

opened 2026-10-15 18:26:07 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

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

Owner

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

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Native analysis or decompilation

Current limitation

With the Ghidra provider, set_address_name and set_addresses_names appear in the MCP catalog but fail:

capability_unavailable: operation is not declared by this provider (provider_id: ghidra, operation: set_address_name)

In a Ghidra session, the only way to name anything is annotate_native_function.

Use cases

An agent reverse-engineering a stripped binary names dozens of helpers and globals as it goes, so that later pseudocode reads better. Example: DAT_004642d8 becomes g_player_bike, and FUN_00409ad0 becomes melee_blow_landed.

annotate_native_function covers function entries, but it has two problems for this:

Every call returns a full function dossier. Renaming one function in a 1996 Win32 x86 game returned about 148k characters.
It cannot name data addresses at all.

Desired outcome and success criteria

set_address_name and set_addresses_names work for Ghidra with the same results as Hopper: a boolean, and a record of per-address booleans.

A function entry renames the function.
Any other mapped address gets a primary label.
The new names appear in later procedure_pseudo_code, address_name and list_names.
In a batch, an invalid entry returns false without affecting the other entries.

Authority boundaries and non-goals

These are mutating operations. Exclude them from read-only/Windows P0 handshakes and from snapshot replay, like annotate_native_function.
Source bytes are never written.
Out of scope: comments and bookmarks for Ghidra, and persisting the database across sessions.

Alternatives considered

Keep using annotate_native_function for functions only. That is costly per call, and globals stay unnamed.

Possible direction

The bridge does one transaction per address:

At a local function entry, Function.setName, using the existing namespace-aware annotationLeafName.
Otherwise, rename the non-dynamic primary symbol, or createLabel(..., USER_DEFINED).setPrimary().
Verify by primary-symbol readback.

On the adapter side, add both operations to the inventory with strict schemas. Use a single GHIDRA_MUTATING_OPERATIONS set for read-only filtering, mutatesArtifact and cache policy.

I have an implementation with tests that I verified against real Ghidra 12.1.4. A PR follows.

References

Related: #709 (annotate_native_function).

Originally created by @giri256 on GitHub (Oct 10, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1634 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Current limitation With the Ghidra provider, `set_address_name` and `set_addresses_names` appear in the MCP catalog but fail: ``` capability_unavailable: operation is not declared by this provider (provider_id: ghidra, operation: set_address_name) ``` In a Ghidra session, the only way to name anything is `annotate_native_function`. ### Use cases An agent reverse-engineering a stripped binary names dozens of helpers and globals as it goes, so that later pseudocode reads better. Example: `DAT_004642d8` becomes `g_player_bike`, and `FUN_00409ad0` becomes `melee_blow_landed`. `annotate_native_function` covers function entries, but it has two problems for this: - Every call returns a full function dossier. Renaming one function in a 1996 Win32 x86 game returned about 148k characters. - It cannot name data addresses at all. ### Desired outcome and success criteria `set_address_name` and `set_addresses_names` work for Ghidra with the same results as Hopper: a boolean, and a record of per-address booleans. - A function entry renames the function. - Any other mapped address gets a primary label. - The new names appear in later `procedure_pseudo_code`, `address_name` and `list_names`. - In a batch, an invalid entry returns `false` without affecting the other entries. ### Authority boundaries and non-goals - These are mutating operations. Exclude them from read-only/Windows P0 handshakes and from snapshot replay, like `annotate_native_function`. - Source bytes are never written. - Out of scope: comments and bookmarks for Ghidra, and persisting the database across sessions. ### Alternatives considered Keep using `annotate_native_function` for functions only. That is costly per call, and globals stay unnamed. ### Possible direction The bridge does one transaction per address: - At a local function entry, `Function.setName`, using the existing namespace-aware `annotationLeafName`. - Otherwise, rename the non-dynamic primary symbol, or `createLabel(..., USER_DEFINED).setPrimary()`. - Verify by primary-symbol readback. On the adapter side, add both operations to the inventory with strict schemas. Use a single `GHIDRA_MUTATING_OPERATIONS` set for read-only filtering, `mutatesArtifact` and cache policy. I have an implementation with tests that I verified against real Ghidra 12.1.4. A PR follows. ### References Related: #709 (`annotate_native_function`).

bsakaguchi

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