morluto/rea

Fork 0

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

[GH-ISSUE #527] Windows: Ghidra provider is hard-gated off via hasWindowsNativeAuthority, contradicting the advertised Windows x64 P0 #273

New issue

Closed

opened 2026-10-15 18:23:16 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-10-15 18:23:16 +00:00

Owner

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

Originally assigned to: @N0zoM1z0 on GitHub.

Summary

REA 3.2.1 cannot run the Ghidra provider on Windows at all, even when Ghidra is installed and detected perfectly. Every request is refused with unsupported_host.

This contradicts the advertised support in the README ("an experimental Windows x64 Ghidra P0 for approved native PE applications") and in docs/windows-ghidra-p0.md, which documents registration steps and acceptance gates for a lane that the shipped code refuses to enter.

Reproduction

With a conforming environment:

GHIDRA_INSTALL_DIR=C:\tools\ghidra_12.1.4_PUBLIC   # application.version=12.1.4
JAVA_HOME=C:\tools\jdk-21.0.12.1+1                 # Temurin 21.0.12.1, amd64, 64-bit, javac present

REA detects all of it correctly:

{
  "install_dir": "C:\\tools\\ghidra_12.1.4_PUBLIC",
  "analyze_headless_path": "C:\\tools\\ghidra_12.1.4_PUBLIC\\support\\analyzeHeadless.bat",
  "application_properties_path": "C:\\tools\\ghidra_12.1.4_PUBLIC\\Ghidra\\application.properties",
  "provider_version": "12.1.4",
  "java_command": "C:\\tools\\jdk-21.0.12.1+1\\bin\\java.exe",
  "java_home": "C:\\tools\\jdk-21.0.12.1+1"
}

…and then refuses anyway:

$ rea analyze "C:\Program Files\GitHub CLI\gh.exe" --provider ghidra

code: provider_unavailable
category: unavailable
operation: open_binary
requested_provider_id: ghidra
rejections:
  - provider_id: ghidra
    code: unsupported_host
    reason: "Verified Windows native authority is unavailable: Job Object process
             ownership, private runtime DACL enforcement, and reparse-safe path
             admission are not implemented; chmod(0700) is insufficient for
             Windows private DACL proof, and taskkill is not a Job Object
             security proof"

rea providers --json reports "available": false with the same reason.

Root cause

src/process/WindowsAuthority.ts returns notProven for all three required capabilities on win32, unconditionally:

const notProven = {
  available: false,
  reason: WINDOWS_NATIVE_AUTHORITY_UNAVAILABLE_REASON,
  proof: "not-proven",
} as const;

so hasWindowsNativeAuthority("win32") is always false. There is no opt-in, no environment variable, and no configuration path — the capability set is a constant.

That gate is enforced twice in src/ghidra/GhidraProvider.ts:

:104 — inspectAvailability() returns unavailable / unsupported_host
:372 — the session-open path, so even a manually-constructed provider cannot start

Because the check is on installation.platform === "win32" rather than on anything measured about the host, no amount of correct setup can satisfy it.

Questions

Is this intentional for 3.2.1? If so, the README's Windows Ghidra P0 claim and docs/windows-ghidra-p0.md overstate what the release can do, and rea providers / rea doctor should probably say "not implemented on this platform" rather than "verified authority unavailable" — the current wording implies the user could satisfy it somehow.
If it is intentional, would an explicit, clearly-labelled degraded mode be acceptable for the documented experimental P0? The docs already scope the lane as unproven with respect to Job Object ownership, private DACLs, and reparse-safe admission:

This proof does not establish Job Object ownership, private DACLs, or reparse-point-safe authority.

…which is exactly what the gate refuses. The docs describe the P0 as usable while the code treats the missing proof as disqualifying.
capabilities / rea doctor should probably distinguish "platform not implemented" from "platform implemented but prerequisites unmet", since they need different user actions.

Scope of impact

On Windows, everything requiring a deep-analysis provider is unavailable, including open_binary, binary_overview, batch_decompile, get_call_graph, xrefs, procedure_pseudo_code, analyze_function, trace_feature, and native function dossiers.

Provider-independent tooling is unaffected and does work on Windows — for example managed PE/CLI inspection succeeds:

$ rea inspect-managed-artifact "C:\Program Files\dotnet\shared\...\System.Text.Json.dll"
evidence_id: ev_12111b4b54a137657660cd601b27dec80c7d6cd99dbc6ffbe2c3b8015bb98528
provider: { id: rea-dotnet-static, name: REA managed static analysis provider }

So the Windows story is "managed/JS/artifacts yes, native no", which is worth stating plainly in the README rather than leading with the P0.

Reported from Windows 11 x64, REA 3.2.1, Node v24.19.0, Ghidra 12.1.4, Temurin JDK 21.0.12.1+1.

Originally created by @whft on GitHub (Oct 5, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/527 Originally assigned to: @N0zoM1z0 on GitHub. ## Summary REA 3.2.1 cannot run the Ghidra provider on Windows at all, even when Ghidra is installed and detected perfectly. Every request is refused with `unsupported_host`. This contradicts the advertised support in the README ("an experimental Windows x64 Ghidra P0 for approved native PE applications") and in `docs/windows-ghidra-p0.md`, which documents registration steps and acceptance gates for a lane that the shipped code refuses to enter. ## Reproduction With a conforming environment: ``` GHIDRA_INSTALL_DIR=C:\tools\ghidra_12.1.4_PUBLIC # application.version=12.1.4 JAVA_HOME=C:\tools\jdk-21.0.12.1+1 # Temurin 21.0.12.1, amd64, 64-bit, javac present ``` REA detects all of it correctly: ```json { "install_dir": "C:\\tools\\ghidra_12.1.4_PUBLIC", "analyze_headless_path": "C:\\tools\\ghidra_12.1.4_PUBLIC\\support\\analyzeHeadless.bat", "application_properties_path": "C:\\tools\\ghidra_12.1.4_PUBLIC\\Ghidra\\application.properties", "provider_version": "12.1.4", "java_command": "C:\\tools\\jdk-21.0.12.1+1\\bin\\java.exe", "java_home": "C:\\tools\\jdk-21.0.12.1+1" } ``` …and then refuses anyway: ``` $ rea analyze "C:\Program Files\GitHub CLI\gh.exe" --provider ghidra code: provider_unavailable category: unavailable operation: open_binary requested_provider_id: ghidra rejections: - provider_id: ghidra code: unsupported_host reason: "Verified Windows native authority is unavailable: Job Object process ownership, private runtime DACL enforcement, and reparse-safe path admission are not implemented; chmod(0700) is insufficient for Windows private DACL proof, and taskkill is not a Job Object security proof" ``` `rea providers --json` reports `"available": false` with the same reason. ## Root cause `src/process/WindowsAuthority.ts` returns `notProven` for all three required capabilities on `win32`, unconditionally: ```ts const notProven = { available: false, reason: WINDOWS_NATIVE_AUTHORITY_UNAVAILABLE_REASON, proof: "not-proven", } as const; ``` so `hasWindowsNativeAuthority("win32")` is always `false`. There is no opt-in, no environment variable, and no configuration path — the capability set is a constant. That gate is enforced twice in `src/ghidra/GhidraProvider.ts`: - `:104` — `inspectAvailability()` returns `unavailable` / `unsupported_host` - `:372` — the session-open path, so even a manually-constructed provider cannot start Because the check is on `installation.platform === "win32"` rather than on anything measured about the host, no amount of correct setup can satisfy it. ## Questions 1. Is this intentional for 3.2.1? If so, the README's Windows Ghidra P0 claim and `docs/windows-ghidra-p0.md` overstate what the release can do, and `rea providers` / `rea doctor` should probably say "not implemented on this platform" rather than "verified authority unavailable" — the current wording implies the user could satisfy it somehow. 2. If it is intentional, would an explicit, clearly-labelled degraded mode be acceptable for the documented experimental P0? The docs already scope the lane as unproven with respect to Job Object ownership, private DACLs, and reparse-safe admission: > This proof does not establish Job Object ownership, private DACLs, or reparse-point-safe authority. …which is exactly what the gate refuses. The docs describe the P0 as usable while the code treats the missing proof as disqualifying. 3. `capabilities` / `rea doctor` should probably distinguish "platform not implemented" from "platform implemented but prerequisites unmet", since they need different user actions. ## Scope of impact On Windows, everything requiring a deep-analysis provider is unavailable, including `open_binary`, `binary_overview`, `batch_decompile`, `get_call_graph`, `xrefs`, `procedure_pseudo_code`, `analyze_function`, `trace_feature`, and native function dossiers. Provider-independent tooling is unaffected and does work on Windows — for example managed PE/CLI inspection succeeds: ``` $ rea inspect-managed-artifact "C:\Program Files\dotnet\shared\...\System.Text.Json.dll" evidence_id: ev_12111b4b54a137657660cd601b27dec80c7d6cd99dbc6ffbe2c3b8015bb98528 provider: { id: rea-dotnet-static, name: REA managed static analysis provider } ``` So the Windows story is "managed/JS/artifacts yes, native no", which is worth stating plainly in the README rather than leading with the P0. Reported from Windows 11 x64, REA 3.2.1, Node v24.19.0, Ghidra 12.1.4, Temurin JDK 21.0.12.1+1.

bsakaguchi

2026-10-15 18:23:16 +00:00

closed this issue
added the
area: providers

enhancement
labels

bsakaguchi commented

2026-10-15 18:23:18 +00:00

Author

Owner

@whft commented on GitHub (Oct 5, 2026):

Additional finding: even with the Windows gate lifted, Ghidra never starts on Windows

While reproducing #527 I found a second, independent defect that blocks every Windows Ghidra session. It is reproducible without any opt-in, because it is a plain quoting bug in the launcher.

Symptom

Once the authority gate is bypassed, the headless launch fails immediately:

provider_id: ghidra
operation: search_strings
code: execution_failure
diagnostics:
  process_id: 12296
  exit_code: 255
  stderr:
    text: "The syntax of the command is incorrect.\r\n"
    bytes: 41

No Ghidra output, no auto-analysis, no bridge endpoint. cmd.exe fails to parse the command line before analyzeHeadless.bat does any work.

Root cause

ghidraLaunchEnvironment() in src/ghidra/GhidraLauncher.ts builds GHIDRA_HEADLESS_JAVA_OPTIONS with quoted values on Windows:

const javaOptions =
  platform === "win32"
    ? `"-Duser.home=${paths.homeRoot}" "-Djava.io.tmpdir=${paths.tempRoot}"`
    : `-Duser.home=${paths.homeRoot} -Djava.io.tmpdir=${paths.tempRoot}`;

Ghidra's own launcher already wraps that list in a pair of double quotes. support/analyzeHeadless.bat:36-39:

set VMARG_LIST=-XX:ParallelGCThreads=2 -XX:CICompilerCount=2
set VMARG_LIST=%VMARG_LIST% %GHIDRA_JAVA_OPTIONS% %GHIDRA_HEADLESS_JAVA_OPTIONS%

and then support/analyzeHeadless.bat:80:

call "%SCRIPT_DIR%launch.bat" %LAUNCH_MODE% jdk Ghidra-Headless "%GHIDRA_HEADLESS_MAXMEM%" "%VMARG_LIST%" ghidra.app.util.headless.AnalyzeHeadless %params%

"%VMARG_LIST%" supplies its own quotes, so the values arrive as:

"-XX:ParallelGCThreads=2 -XX:CICompilerCount=2  "-Duser.home=C:\...\home" "-Djava.io.tmpdir=C:\...\tmp""

Those nested, unescaped quotes break cmd's tokenizer and produce The syntax of the command is incorrect. with exit code 255. This is also why the failure looks like a REA problem while exit_code: 255 is specifically cmd's parse failure.

Isolated proof

Same target, same arguments, same environment, varying only the quoting:

`GHIDRA_HEADLESS_JAVA_OPTIONS`	result
`"-Duser.home=X" "-Djava.io.tmpdir=Y"` (current)	exit 255, `The syntax of the command is incorrect.`
`-Duser.home=X -Djava.io.tmpdir=Y`	exit 0, Ghidra starts
unset	exit 0, Ghidra starts

So GHIDRA_HEADLESS_JAVA_OPTIONS is the only variable involved; everything else in the launch environment is fine. Note the POSIX branch is already correct — only the Windows branch adds quotes.

Suggested fix

Emit the options unquoted on every platform, and note why:

export const ghidraLaunchEnvironment = (
  paths: ReturnType<typeof ghidraRuntimePaths>,
  javaHome: string | undefined,
  platform: NodeJS.Platform,
): NodeJS.ProcessEnv => {
  // analyzeHeadless.bat accumulates VMARG_LIST and hands it to launch.bat
  // already wrapped in one pair of double quotes. Emitting quoted values here
  // nests unescaped quotes inside that wrapper, which cmd rejects before
  // Ghidra starts with "The syntax of the command is incorrect." (exit 255).
  // These paths are provider-owned and already screened for command-interpreter
  // metacharacters, so they must stay unquoted on every platform.
  const javaOptions =
    `-Duser.home=${paths.homeRoot} -Djava.io.tmpdir=${paths.tempRoot}`;

This is safe because the values are already constrained: quoteWindowsBatchToken() rejects ", %, ^, !, &, |, <, >, CR/LF and NUL in every path that reaches the launcher, and the runtime root is provider-created under the OS temp directory. That screening is currently only applied to the command tokens, not to the environment values, so it would be worth asserting the same invariant for homeRoot/tempRoot — or better, deriving both from a single validated helper.

Verification after the fix

With the quoting corrected (and #527's gate separately bypassed), Windows Ghidra analysis works end to end against C:\Windows\System32\notepad.exe:

open_binary → format: pe, architecture: x86_64, provider ghidra
binary_overview → 9 segments (Headers, .text, .rdata, .data, .pdata, .didat, .rsrc, .reloc, tdb), 794 procedures, 557 strings
analyze_function(0x14000125c) → Ghidra pseudocode with FID library identification, instruction-level assembly, 6 callers, 1 callee, 7 incoming / 13 outgoing references, native_api and native_value_flow populated
search_strings("notepad") → 16 hits with exact addresses

One session took ~125 s wall clock for full auto-analysis on a 196 KB binary.

A note on test coverage

ghidraLaunchEnvironment has no test that exercises the Windows quoting shape — ghidraHeadlessCommand() is well covered (including the metacharacter rejection and the 30 000-character limit), but the environment half of the same invocation is not. A test asserting GHIDRA_HEADLESS_JAVA_OPTIONS contains no " on any platform would have caught this.

One more gate, for the record

There are two independent Windows gates, and lifting hasWindowsNativeAuthority() alone is not sufficient:

GhidraProvider inspectAvailability() and the session-open path — gated by hasWindowsNativeAuthority()
WINDOWS_P0_CAPABILITIES in GhidraProviderCapabilities.ts — a separate table that sets available: false and reason: WINDOWS_NATIVE_AUTHORITY_UNAVAILABLE_REASON on every Ghidra capability, independently of gate 1

Gate 2 is what BinarySessionExecution.prepareSessionExecution() consults, so it is the one that actually blocks operations. Any opt-in or capability work needs to cover both.

@whft commented on GitHub (Oct 5, 2026): ## Additional finding: even with the Windows gate lifted, Ghidra never starts on Windows While reproducing #527 I found a second, independent defect that blocks every Windows Ghidra session. It is reproducible without any opt-in, because it is a plain quoting bug in the launcher. ### Symptom Once the authority gate is bypassed, the headless launch fails immediately: ``` provider_id: ghidra operation: search_strings code: execution_failure diagnostics: process_id: 12296 exit_code: 255 stderr: text: "The syntax of the command is incorrect.\r\n" bytes: 41 ``` No Ghidra output, no auto-analysis, no bridge endpoint. `cmd.exe` fails to parse the command line before `analyzeHeadless.bat` does any work. ### Root cause `ghidraLaunchEnvironment()` in `src/ghidra/GhidraLauncher.ts` builds `GHIDRA_HEADLESS_JAVA_OPTIONS` with **quoted** values on Windows: ```ts const javaOptions = platform === "win32" ? `"-Duser.home=${paths.homeRoot}" "-Djava.io.tmpdir=${paths.tempRoot}"` : `-Duser.home=${paths.homeRoot} -Djava.io.tmpdir=${paths.tempRoot}`; ``` Ghidra's own launcher already wraps that list in a pair of double quotes. `support/analyzeHeadless.bat:36-39`: ```bat set VMARG_LIST=-XX:ParallelGCThreads=2 -XX:CICompilerCount=2 set VMARG_LIST=%VMARG_LIST% %GHIDRA_JAVA_OPTIONS% %GHIDRA_HEADLESS_JAVA_OPTIONS% ``` and then `support/analyzeHeadless.bat:80`: ```bat call "%SCRIPT_DIR%launch.bat" %LAUNCH_MODE% jdk Ghidra-Headless "%GHIDRA_HEADLESS_MAXMEM%" "%VMARG_LIST%" ghidra.app.util.headless.AnalyzeHeadless %params% ``` `"%VMARG_LIST%"` supplies its own quotes, so the values arrive as: ``` "-XX:ParallelGCThreads=2 -XX:CICompilerCount=2 "-Duser.home=C:\...\home" "-Djava.io.tmpdir=C:\...\tmp"" ``` Those nested, unescaped quotes break `cmd`'s tokenizer and produce `The syntax of the command is incorrect.` with exit code 255. This is also why the failure looks like a REA problem while `exit_code: 255` is specifically `cmd`'s parse failure. ### Isolated proof Same target, same arguments, same environment, varying only the quoting: | `GHIDRA_HEADLESS_JAVA_OPTIONS` | result | |---|---| | `"-Duser.home=X" "-Djava.io.tmpdir=Y"` (current) | **exit 255, `The syntax of the command is incorrect.`** | | `-Duser.home=X -Djava.io.tmpdir=Y` | exit 0, Ghidra starts | | unset | exit 0, Ghidra starts | So `GHIDRA_HEADLESS_JAVA_OPTIONS` is the only variable involved; everything else in the launch environment is fine. Note the POSIX branch is already correct — only the Windows branch adds quotes. ### Suggested fix Emit the options unquoted on every platform, and note why: ```ts export const ghidraLaunchEnvironment = ( paths: ReturnType<typeof ghidraRuntimePaths>, javaHome: string | undefined, platform: NodeJS.Platform, ): NodeJS.ProcessEnv => { // analyzeHeadless.bat accumulates VMARG_LIST and hands it to launch.bat // already wrapped in one pair of double quotes. Emitting quoted values here // nests unescaped quotes inside that wrapper, which cmd rejects before // Ghidra starts with "The syntax of the command is incorrect." (exit 255). // These paths are provider-owned and already screened for command-interpreter // metacharacters, so they must stay unquoted on every platform. const javaOptions = `-Duser.home=${paths.homeRoot} -Djava.io.tmpdir=${paths.tempRoot}`; ``` This is safe because the values are already constrained: `quoteWindowsBatchToken()` rejects `"`, `%`, `^`, `!`, `&`, `|`, `<`, `>`, CR/LF and NUL in every path that reaches the launcher, and the runtime root is provider-created under the OS temp directory. That screening is currently only applied to the command tokens, not to the environment values, so it would be worth asserting the same invariant for `homeRoot`/`tempRoot` — or better, deriving both from a single validated helper. ### Verification after the fix With the quoting corrected (and #527's gate separately bypassed), Windows Ghidra analysis works end to end against `C:\Windows\System32\notepad.exe`: - `open_binary` → `format: pe`, `architecture: x86_64`, provider `ghidra` - `binary_overview` → 9 segments (`Headers`, `.text`, `.rdata`, `.data`, `.pdata`, `.didat`, `.rsrc`, `.reloc`, `tdb`), **794 procedures**, **557 strings** - `analyze_function(0x14000125c)` → Ghidra pseudocode with FID library identification, instruction-level assembly, 6 callers, 1 callee, 7 incoming / 13 outgoing references, `native_api` and `native_value_flow` populated - `search_strings("notepad")` → 16 hits with exact addresses One session took ~125 s wall clock for full auto-analysis on a 196 KB binary. ### A note on test coverage `ghidraLaunchEnvironment` has no test that exercises the Windows quoting shape — `ghidraHeadlessCommand()` is well covered (including the metacharacter rejection and the 30 000-character limit), but the *environment* half of the same invocation is not. A test asserting `GHIDRA_HEADLESS_JAVA_OPTIONS` contains no `"` on any platform would have caught this. ### One more gate, for the record There are two independent Windows gates, and lifting `hasWindowsNativeAuthority()` alone is not sufficient: 1. `GhidraProvider` `inspectAvailability()` and the session-open path — gated by `hasWindowsNativeAuthority()` 2. `WINDOWS_P0_CAPABILITIES` in `GhidraProviderCapabilities.ts` — a **separate** table that sets `available: false` and `reason: WINDOWS_NATIVE_AUTHORITY_UNAVAILABLE_REASON` on every Ghidra capability, independently of gate 1 Gate 2 is what `BinarySessionExecution.prepareSessionExecution()` consults, so it is the one that actually blocks operations. Any opt-in or capability work needs to cover both.

bsakaguchi commented

2026-10-15 18:23:18 +00:00

Author

Owner

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

Confirmed that this blocker is still present in committed main at 92617f96.

The scope is Windows Ghidra deep analysis, not every REA operation on Windows. A correctly detected Ghidra 12.1.4/JDK 21 installation cannot enable this provider through configuration.

Current code evidence

WindowsAuthority.ts unconditionally reports Job Object process ownership, private runtime DACLs, and reparse-safe path admission as unavailable on Windows. Consequently, hasWindowsNativeAuthority("win32") is always false.
GhidraProvider.ts returns unsupported_host even when installation inspection succeeds. The client construction path independently refuses Windows startup.
WINDOWS_P0_CAPABILITIES independently marks every Ghidra operation unavailable.
PrivateRuntimeRoot.create also refuses allocation when Windows private-DACL authority is unavailable. This prevents the lower-level launcher from establishing its required runtime root.

The README and Windows P0 guide now explicitly describe the block. However, docs/provider-evaluation.md and docs/native-investigation.md still contain wording that implies usable Windows P0 analysis. The provider-evaluation guide also mixes 19 and 22 operations.

Existing implementation work

This report is linked to the already-open implementation issues:

#287: trusted Windows native authority and packaging boundary
#318: native Node-API implementation
#319: release integration and real Windows verification
#289: handle-based reparse-safe filesystem authority
#290: private runtime DACL creation and verification

Before closing this issue, implement and verify the native controls, connect them to provider availability, capability reporting, and runtime-root creation, and run the real Windows Ghidra workflow through the public CLI and MCP with source-owned fixtures, operation coverage, cancellation, and owned-resource cleanup. Correct setup should then permit the documented native x86-64 PE boundary. Until that verification passes, all status summaries should state that Windows Ghidra analysis is unavailable.

Verification for this update: source review of committed main and the four existing Windows capability conformance tests passed on macOS. This update does not claim a real Windows engine run or independently reproduce the separate launcher quoting report above.

@morluto commented on GitHub (Oct 5, 2026): Confirmed that this blocker is still present in committed `main` at [`92617f96`](https://github.com/morluto/rea/commit/92617f965720aaa74ec20ad67291adc5e83677a1). The scope is **Windows Ghidra deep analysis**, not every REA operation on Windows. A correctly detected Ghidra 12.1.4/JDK 21 installation cannot enable this provider through configuration. ### Current code evidence - [`WindowsAuthority.ts`](https://github.com/morluto/rea/blob/92617f965720aaa74ec20ad67291adc5e83677a1/src/process/WindowsAuthority.ts#L49-L65) unconditionally reports Job Object process ownership, private runtime DACLs, and reparse-safe path admission as unavailable on Windows. Consequently, `hasWindowsNativeAuthority("win32")` is always false. - [`GhidraProvider.ts`](https://github.com/morluto/rea/blob/92617f965720aaa74ec20ad67291adc5e83677a1/src/ghidra/GhidraProvider.ts#L98-L116) returns `unsupported_host` even when installation inspection succeeds. The [client construction path](https://github.com/morluto/rea/blob/92617f965720aaa74ec20ad67291adc5e83677a1/src/ghidra/GhidraProvider.ts#L370-L380) independently refuses Windows startup. - [`WINDOWS_P0_CAPABILITIES`](https://github.com/morluto/rea/blob/92617f965720aaa74ec20ad67291adc5e83677a1/src/ghidra/GhidraProviderCapabilities.ts#L159-L176) independently marks every Ghidra operation unavailable. - [`PrivateRuntimeRoot.create`](https://github.com/morluto/rea/blob/92617f965720aaa74ec20ad67291adc5e83677a1/src/process/PrivateRuntimeRoot.ts#L61-L64) also refuses allocation when Windows private-DACL authority is unavailable. This prevents the lower-level launcher from establishing its required runtime root. The README and Windows P0 guide now explicitly describe the block. However, `docs/provider-evaluation.md` and `docs/native-investigation.md` still contain wording that implies usable Windows P0 analysis. The provider-evaluation guide also mixes 19 and 22 operations. ### Existing implementation work This report is linked to the already-open implementation issues: - #287: trusted Windows native authority and packaging boundary - #318: native Node-API implementation - #319: release integration and real Windows verification - #289: handle-based reparse-safe filesystem authority - #290: private runtime DACL creation and verification Before closing this issue, implement and verify the native controls, connect them to provider availability, capability reporting, and runtime-root creation, and run the real Windows Ghidra workflow through the public CLI and MCP with source-owned fixtures, operation coverage, cancellation, and owned-resource cleanup. Correct setup should then permit the documented native x86-64 PE boundary. Until that verification passes, all status summaries should state that Windows Ghidra analysis is unavailable. Verification for this update: source review of committed `main` and the four existing Windows capability conformance tests passed on macOS. This update does not claim a real Windows engine run or independently reproduce the separate launcher quoting report above.

bsakaguchi commented

2026-10-15 18:23:18 +00:00

Author

Owner

@N0zoM1z0 commented on GitHub (Oct 5, 2026):

i'll work on this tmmr (if i have time)

@N0zoM1z0 commented on GitHub (Oct 5, 2026): i'll work on this tmmr (if i have time)

bsakaguchi commented

2026-10-15 18:23:18 +00:00

Author

Owner

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

Status update: the README and Windows Ghidra P0 guide now state plainly that Windows Ghidra is experimental and currently unavailable because Job Object process ownership, private runtime DACL enforcement, and reparse-safe path admission are not implemented. Manual installation or MCP registration does not enable the provider. The implementation gate remains in place; this issue should stay open to track the native controls and the controlled Windows/Ghidra verification required before enabling the P0.

@morluto commented on GitHub (Oct 5, 2026): Status update: the README and Windows Ghidra P0 guide now state plainly that Windows Ghidra is experimental and currently unavailable because Job Object process ownership, private runtime DACL enforcement, and reparse-safe path admission are not implemented. Manual installation or MCP registration does not enable the provider. The implementation gate remains in place; this issue should stay open to track the native controls and the controlled Windows/Ghidra verification required before enabling the P0.

bsakaguchi referenced this issue

2026-10-15 18:28:04 +00:00

[GH-ISSUE #2299] [Feature] Return optional decompiled C# for selected .NET members as reconstruction inference #761

bsakaguchi referenced this issue

2026-10-15 18:28:29 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-16 21:12:29 +00:00

[PR #273] [MERGED] feat(dotnet): import managed reconstructions #1915

bsakaguchi added

enhancement

and removed