[GH-ISSUE #6197] Ghidra provider ignores adjacent PDB companions for Windows PE targets (no symbol names without manual workaround) #3775

New issue

Open

opened 2026-10-31 00:43:56 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:43:56 +00:00

Owner

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

Problem

On Windows PE targets built with MSVC debug info (/Zi) and an adjacent PDB, the Ghidra provider's analysis surfaces no symbol-derived procedure names: every function appears as FUN_* auto-names, and name-based lookups fail:

rea decompile <path> transform_b --provider ghidra --format json
→ details.issues[0].message: "Unknown Ghidra procedure name or address: transform_b"

A stripped build of the same program behaves identically, so the symbol channel contributes nothing today.

Observed mechanism (v6.7.0, Ghidra 12.1.4, Windows x64)

Import always runs on the private snapshot copy (GhidraClient.ts → createGhidraTargetSnapshot → analyzeHeadless -import <runtimeRoot/target-<sha12>.exe), so the adjacent PDB never travels with the target.
The launch arguments carry no PDB-related options (GhidraLauncher.ts argument assembly), and no analyzer toggles touch PDB analyzers (ReaGhidraAnalysisOptions only applies caller-disabled analyzers).
The launch environment redirects HOME/APPDATA/TEMP to the private runtime root, which also neutralizes user-level symbol store configuration.
The current position is documented intentionally (docs/ghidra-provider.md: "REA imports a private executable copy and does not admit a caller-selected PDB companion. This reporting does not search symbol servers, copy a sibling PDB, or change analyzer settings.") — hence this is a policy question, not a bug claim.

Why it matters

Agent-driven reverse engineering evaluations (e.g., SRE-Bench-style symbol-dependence measurements, where removing symbols alone drops top-model scores dramatically) hinge on the symbol channel being present when it exists in the artifact. Today REA's Windows PE path is effectively always "stripped" from the agent's perspective regardless of the shipped debug info, which both loses legitimate information and makes symbol-dependent workflows impossible without manual pre-processing.

Question for maintainers

Would a narrowly-scoped policy change be acceptable — e.g., copying an adjacent PDB companion (matched by the PE code-view record's declared name) next to the snapshot copy before import, keeping provenance reporting unchanged (still reporting whether symbols were applied)? If yes, I can prepare a PR. Alternatives (opt-in env switch, search-path option) also work; happy to follow the maintainers' preferred shape.

Originally created by @KaronLabs on GitHub (Oct 22, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6197 ## Problem On Windows PE targets built with MSVC debug info (`/Zi`) and an adjacent PDB, the Ghidra provider's analysis surfaces no symbol-derived procedure names: every function appears as `FUN_*` auto-names, and name-based lookups fail: ``` rea decompile <path> transform_b --provider ghidra --format json → details.issues[0].message: "Unknown Ghidra procedure name or address: transform_b" ``` A stripped build of the same program behaves identically, so the symbol channel contributes nothing today. ## Observed mechanism (v6.7.0, Ghidra 12.1.4, Windows x64) - Import always runs on the private snapshot copy (`GhidraClient.ts` → `createGhidraTargetSnapshot` → `analyzeHeadless -import <runtimeRoot/target-<sha12>.exe`), so the adjacent PDB never travels with the target. - The launch arguments carry no PDB-related options (`GhidraLauncher.ts` argument assembly), and no analyzer toggles touch PDB analyzers (`ReaGhidraAnalysisOptions` only applies caller-disabled analyzers). - The launch environment redirects HOME/APPDATA/TEMP to the private runtime root, which also neutralizes user-level symbol store configuration. - The current position is documented intentionally (`docs/ghidra-provider.md`: "REA imports a private executable copy and does not admit a caller-selected PDB companion. This reporting does not search symbol servers, copy a sibling PDB, or change analyzer settings.") — hence this is a policy question, not a bug claim. ## Why it matters Agent-driven reverse engineering evaluations (e.g., SRE-Bench-style symbol-dependence measurements, where removing symbols alone drops top-model scores dramatically) hinge on the symbol channel being present when it exists in the artifact. Today REA's Windows PE path is effectively always "stripped" from the agent's perspective regardless of the shipped debug info, which both loses legitimate information and makes symbol-dependent workflows impossible without manual pre-processing. ## Question for maintainers Would a narrowly-scoped policy change be acceptable — e.g., copying an adjacent PDB companion (matched by the PE code-view record's declared name) next to the snapshot copy before import, keeping provenance reporting unchanged (still reporting whether symbols were applied)? If yes, I can prepare a PR. Alternatives (opt-in env switch, search-path option) also work; happy to follow the maintainers' preferred shape.

bsakaguchi referenced this issue

2026-10-31 01:10:12 +00:00

[PR #3775] feat(native): static packer identification for PE and ELF #5890

bsakaguchi referenced this issue

2026-11-01 21:10:57 +00:00

[GH-ISSUE #3796] [Tracker] Open feature requests by area (October 2026) #1471

bsakaguchi referenced this issue

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

[GH-ISSUE #5654] [Tracker] Open PRs that can't merge yet: conflicts and red CI (October 2026) #3425