R2R Stomping – New Method to Run the Hidden Code in Binaries

Your perceived reality can differ from the .NET code you observe in debuggers like dnSpy, raising questions about its behavior beyond debugging.

Enhance .NET app startup and latency by using ReadyToRun (R2R) format for AOT compilation, creating larger binaries with both IL code and native versions for improved performance.

CheckPoint researchers recently unveiled a novel method to execute hidden code in ReadyToRun (R2R) .NET binaries by altering the IL code to diverge from pre-compiled native code, leveraging .NET optimization.

R2R stomping

Originally Microsoft’s, the Dotnet framework is now open-source and cross-platform, supporting languages like C#, F#, VB.NET, and PowerShell. It began with Windows-only closed-source in 2002, but in 2004 the open-source “Mono Project” emerged. 

Microsoft later introduced its own open-source version, .NET Core (2016), evolving into .NET 5 (2020). This research targets .NET Core 3.0+ to .NET 5+ due to the ReadyToRun format.

The traditional .NET assemblies rely on JIT for code execution, causing latency. As dotnet usage grows, solutions focus on reducing JIT reliance and improving startup times through ahead-of-time (AOT) compilation.

Here below, we have mentioned all the primary formats of AOT compilation:-

ReadyToRun (R2R) compiled assemblies include both IL code and native code, conforming to CLI format enriched with a “ManagedNativeHeader” pointing to a “READYTORUN_HEADER” with the signature “0x00525452,” distinguishing them from other CLI images.

R2R stomping alters R2R binaries to make IL code differ from pre-compiled native code, prioritizing native execution. 

However, managed debuggers like dnSpy/dnSpyEx have different optimization settings, leading to distinct code execution, and this method is similar to VBA stomping in MS Office.

R2R Stomping

R2R stomping modifies assembly code to make method IL behavior differ from pre-compiled native code.

Here below, we have mentioned the modification methods:-

• Compile real – Replace with decoy
• Compile decoy – Replace with real

Most researchers analyze dotnet assembly at the IL or decompiled C# code level, often using tools like dnSpy/dnSpyEx. However, R2R stomped assembly analysis requires delving deeper into native code.

The R2R stomped assembly analysis demands a unique approach and toolset compared to standard dotnet assembly analysis, with various tools serving specific tasks.

Here, these specific tasks are divided into:-

• Parsing the ReadyToRun assembly structure (R2RDump, dotPeek)
• Showing the IL code and interpreted decompiled C# code (ILSpy, dnSpyEx, dotPeek)
• Locating and disassembling the pre-compiled native code (R2RDump, ILSpy)

Detecting ReadyToRun compilation is straightforward, whether manually or with tools like dotPeek or ILSpy, which can also handle dotnet bundle file formats.

While static, automated detection for production isn’t available, behavioral-based detection remains unaffected by R2R stomping.

Protect yourself from vulnerabilities using Patch Manager Plus to patch over 850 third-party applications quickly. Take advantage of the free trial to ensure 100% security.