From Static Artifacts to Behavioral Experiments

REA’s evidence model has to survive more than native binaries and JavaScript graphs. Managed assemblies, Android packages, firmware images, and process runs each expose a different boundary between bytes, interpretation, and behavior. This chapter compares those routes through one question: what does a provider own, what identity does it preserve, and what stronger claim remains unavailable? The answer shows why caller-supplied engines and behavioral captures can extend an investigation without turning every handoff into proof of equivalence or security isolation.

Managed code: readable reconstruction is not the canonical fact

A .NET assembly is easy to overread because a decompiler can produce familiar source-like syntax. REA’s managed provider begins elsewhere: it parses PE/CLI metadata and CIL from the artifact without loading or executing the assembly. Artifact identity includes the path, length, digest, module and MVID information, and a classification of the admitted form. Member observations retain declaring types, signatures, build-local tokens, method extents, and CIL-related digests where the body is available.

That byte-oriented foundation matters when the assembly is obfuscated, rebuilt, or packaged in a form that changes the relationship between metadata and native implementation. A metadata token is a precise coordinate inside one module, but it is not a cross-build identity. A name can change or be deliberately meaningless. A decompiler’s C# output can provide a useful reconstruction, but it is an analyst representation of cited metadata and CIL rather than original source. Even the deterministic decoded-instruction-tuple fingerprint has a limited meaning: it can support one structural comparison tier, but it is not a complete semantic identity.

REA keeps several evidence layers separate: static observation, source-like reconstruction, structural inference, independent validation, and runtime observation. That separation lets a reader say “these bytes decode to this member and body” without silently upgrading the statement to “this method ran” or “this is how the application behaved in production.” Managed inspection does not execute the assembly or observe CLR internals. If runtime behavior matters, it requires a separately authorized observation.

The same boundary governs managed/native composition. A declared P/Invoke or native boundary can be checked against supplied export or function Evidence, but a managed token is never treated as a native address by assumption. A NativeAOT or ReadyToRun-related clue may point toward native analysis, yet the bridge must be supported and authenticated before a native function can be linked to a managed identity. When that bridge is unavailable, the managed observation remains useful and the native question remains open.

Cross-build comparison follows the same caution. Exact CIL or signature evidence can be stronger than a name, while structural shape can help locate a likely counterpart when build-local tokens and MVIDs differ. Duplicate candidates stay ambiguous, and a method with a partial body can retain its observed signature while leaving body facets unknown. The practical output is not “these two decompiled methods are the same,” but a qualified match with the artifact commitments, candidate basis, and remaining uncertainty attached.