Carding 4 Carders
Professional
- Messages
- 2,724
- Reaction score
- 1,583
- Points
- 113
The case when you should not blindly trust the code debugger.
Researchers from Check Point identified a new method for covertly embedding code in binary files .NET files compiled using the Ahead-Of-Time (AOT) principle in ReadyToRun (R2R) format. The new implementation method is called "R2R Stomping".
The R2R compilation format allows you to speed up loading and reduce startup delays .NET applications by pre-compiling the code to native before the application is launched. However, the R2R Stomping technique uses features of working with R2R binaries to inject malicious code by modifying the source code of the assembly in an intermediate language (IL-code) so that it will differ from the precompiled native code inside the file.
Because of optimization .NET prioritizes precompiled code during execution, ignoring changes in the IL code. In addition, dnSpy debuggers suppress JIT optimization by default, which leads to differences in the code executed in normal mode and during debugging.
This principle of operation seriously complicates security analysis and reverse engineering of such R2R binaries using standard tools like dnSpy, which work only with IL code.
The researchers demonstrated two ways to implement R2R Stomping:
To analyze R2R binaries that have undergone such changes, you need to use specialized tools that allow you to work with native precompiled code directly, such as R2RDump and ILSpy. They can extract and display the disassembled native code of compiled methods.
Currently, there is no simple and reliable way to automatically detect the use of the R2R Stomping technique. However, if malicious code is introduced in this way, detection based on behavior analysis should work correctly.
So far, there is no evidence of using R2R Stomping in real attacks, but it cannot be ruled out that this technique can already be used in sophisticated attackers arsenals to inject hidden malicious code into seemingly secure applications.
Although at the moment this is more of a problem for reverse engineers than a real way to bypass security systems, the developed analysis methods will somehow help security specialists identify cases of R2R Stomping and respond to them accordingly.
Researchers from Check Point identified a new method for covertly embedding code in binary files .NET files compiled using the Ahead-Of-Time (AOT) principle in ReadyToRun (R2R) format. The new implementation method is called "R2R Stomping".
The R2R compilation format allows you to speed up loading and reduce startup delays .NET applications by pre-compiling the code to native before the application is launched. However, the R2R Stomping technique uses features of working with R2R binaries to inject malicious code by modifying the source code of the assembly in an intermediate language (IL-code) so that it will differ from the precompiled native code inside the file.
Because of optimization .NET prioritizes precompiled code during execution, ignoring changes in the IL code. In addition, dnSpy debuggers suppress JIT optimization by default, which leads to differences in the code executed in normal mode and during debugging.
This principle of operation seriously complicates security analysis and reverse engineering of such R2R binaries using standard tools like dnSpy, which work only with IL code.
The researchers demonstrated two ways to implement R2R Stomping:
- replacing the original IL code with a fake one, leaving the native precompiled code unchanged;
- replacing native precompiled code with malicious shellcode, leaving the original IL code.
To analyze R2R binaries that have undergone such changes, you need to use specialized tools that allow you to work with native precompiled code directly, such as R2RDump and ILSpy. They can extract and display the disassembled native code of compiled methods.
Currently, there is no simple and reliable way to automatically detect the use of the R2R Stomping technique. However, if malicious code is introduced in this way, detection based on behavior analysis should work correctly.
So far, there is no evidence of using R2R Stomping in real attacks, but it cannot be ruled out that this technique can already be used in sophisticated attackers arsenals to inject hidden malicious code into seemingly secure applications.
Although at the moment this is more of a problem for reverse engineers than a real way to bypass security systems, the developed analysis methods will somehow help security specialists identify cases of R2R Stomping and respond to them accordingly.
