diff --git a/docs/managed-code-analysis.md b/docs/managed-code-analysis.md index c0aca74e5..13bdd7bfd 100644 --- a/docs/managed-code-analysis.md +++ b/docs/managed-code-analysis.md @@ -90,6 +90,51 @@ coverage, and route while retaining the outer bundle commitment. | Obfuscated assembly | Same positive byte observations as its underlying deployment form | Meaning inferred only from names | | Malformed/unsupported | Exact admitted regions and failure locations | Completeness, successfully skipped rows, or semantics beyond the admitted parser boundary | +### NativeAOT metadata recovery + +NativeAOT removes the ordinary CIL method bodies, so a CIL decompiler cannot +reconstruct those bodies as C# source. The executable remains a native target +for Hopper or Ghidra, where decompilation produces pseudocode and analyst +inference. This is a different route from ordinary managed member inspection. + +NativeAOT is not limited to Windows `.exe` files. The native image can be PE, +ELF, or Mach-O, and NativeAOT can also publish shared libraries (PE DLL, ELF +`.so`, or Mach-O `.dylib`) with explicitly exported entry points. Identify the +image from its bytes and loader metadata, not its filename extension. When the +image is inside an application bundle, inventory or extract the bundle first +and carry the component identity into native analysis. Matching PDB, ELF debug, +or dSYM sidecars can add symbol evidence when the selected provider supports +them; verify their identity and keep them separate from observations made from +the executable itself. [Microsoft's NativeAOT overview](https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/) +lists supported OS/architecture targets and deployment limitations, while its +[native library guide](https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/libraries) +describes exported shared-library entry points. + +The [Ghidra NativeAOT analyzer](https://github.com/Washi1337/ghidra-nativeaot) +is a useful optional companion for recovering ReadyToRun metadata. It +rehydrates the `DEHYDRATED_DATA` section and annotates method tables, type +relationships, vtable slots, frozen objects, and strings. It does not recover +original C# method bodies. It is a separate Ghidra extension and interactive +metadata browser; REA does not currently install or invoke it through its +headless bridge. Its README describes ReadyToRun header discovery, including +symbol-based and heuristic paths, so a missed header or unsupported binary +should remain an explicit limitation rather than a failed claim about the +binary's contents. + +The upstream analyzer currently gates its own analysis to x86-64. NativeAOT's +broader platform matrix does not establish REA coverage: PE/COFF, ELF, Mach-O, +shared libraries, target architectures, and runtime metadata versions each need +their own provider verification. REA's experimental Windows Ghidra boundary is +limited to admitted native x86-64 PE applications, so it does not currently +establish coverage for PE DLLs. Mobile NativeAOT targets should remain +experimental until REA has a matching provider and package-level verification. + +For REA's native analysis, preserve the same artifact path and digest used by +`inspect_managed_artifact`, and report recovered type data as provider +observations. Linking those types to native function addresses requires verified +provider evidence; names or vtable similarity alone do not prove that a native +function implements a specific managed method. + ## Evidence record shape Every planned operation returns a provider result and Evidence with four diff --git a/docs/verification/managed-conformance-manifest.json b/docs/verification/managed-conformance-manifest.json index 8d5e0116f..04f610693 100644 --- a/docs/verification/managed-conformance-manifest.json +++ b/docs/verification/managed-conformance-manifest.json @@ -1,5 +1,5 @@ { - "manifest_id": "ecm_fbd47cbd3815d7e252ebcb60c4d086dcc1fc6b63f020e83513e28bf4d94c732c", + "manifest_id": "ecm_19cf4bddaf5311c3cda82a950883bbc028940ddae8a5e68eeb28374b88585095", "verifier": { "id": "rea-managed-conformance", "version": "1" @@ -13,7 +13,7 @@ "skill_digests": [ { "skill_id": "reverse-engineer-anything", - "sha256": "b317babebb82157b46b4dff698a170045490bcb21aaf9af582e20908ba2bb998" + "sha256": "57f5af72a8f387cbc5249455492297a087a5fff81a986d47f58a7fc879485aef" } ], "claims": [ diff --git a/skills/reverse-engineer-anything/references/native-and-artifacts.md b/skills/reverse-engineer-anything/references/native-and-artifacts.md index d7da85bcb..d53671454 100644 --- a/skills/reverse-engineer-anything/references/native-and-artifacts.md +++ b/skills/reverse-engineer-anything/references/native-and-artifacts.md @@ -37,29 +37,30 @@ assembly. Keep managed/native boundaries and unavailable reconstruction facts explicit. A bring-your-own reconstruction oracle is separate from the canonical parser and must not become an implicit setup dependency. -## .NET NativeAOT +### .NET NativeAOT -A NativeAOT PE/ELF contains native code. Absence of PE/CLI metadata does not mean -analysis must stop at assembly. Use native function analysis for recovered -pseudocode; it is not reconstructed original C#. +NativeAOT binaries contain native machine code, so ordinary CIL decompilers +cannot recover the original method bodies. When managed metadata/CIL is absent, +classify that as a native-analysis route rather than claiming source recovery. +Open the native image with the selected deep provider and inspect functions, +strings, calls, and references; describe decompiler output as pseudocode and +inference. -With an explicitly configured NativeAOT Ghidra adapter, call -`inspect_native_load_image` after opening the target. Its optional -`observations.metadata_recovery` returns the format, positive header evidence, -coverage, derived-memory identity and type addresses/category paths inline. -Then inspect a reported type with `inspect_native_data_type`, follow its -`metadata_recovery.related_type`, interfaces and virtual slot addresses, and use -`analyze_function` plus string/xref searches for implementation evidence. Keep -`not_applicable`, partial recovery and unsupported layouts explicit. Generated -`Class_address` names and inferred System.Object/String identities are not -original names; custom field layouts remain unknown. +NativeAOT images can be PE/COFF, ELF, or Mach-O executables and shared +libraries. Use file bytes and loader metadata rather than suffixes to identify +them. For packaged apps, inventory/extract with REA's artifact tools and retain +the exact contained image identity. PDB, ELF debug, or dSYM sidecars are +additional evidence only when the provider accepts and matches them. -Recovery modifies an ephemeral analysis database and may replace loaded metadata -bytes with derived content. Original executable files remain unchanged. Distinguish -original file offsets from derived analysis memory. Windows x64 PE **targets** -can be analyzed on a supported Linux host; Windows **host** P0 does not admit -this database recovery. See the [NativeAOT guide](https://github.com/morluto/rea/blob/main/docs/ghidra-nativeaot.md) -for the tested layout and optional bring-your-own adapter build. +For deeper type recovery, the optional third-party +[Ghidra NativeAOT analyzer](https://github.com/Washi1337/ghidra-nativeaot) +rehydrates ReadyToRun metadata and can recover method tables, type relationships, +frozen objects, and strings. This is a Ghidra extension with its own install and +interactive workflow; it is not currently part of REA's managed parser or +headless Ghidra bridge. Treat its annotations as analysis evidence, retain the +binary identity, and do not present recovered types as original source. Header +discovery may require a symbol or analyst identification of the ReadyToRun +header, depending on the binary and analyzer version. ## Packages and extraction