Jump to content
Nytro

.NET Internals and Code Injection

Recommended Posts

.NET Internals and Code Injection

Introduction

What is .NET Code Injection?

How does .NET Code Injection work?

.NET Internals (Part 1: JIT)

The .NET Assembly Loader

JIT Hooking Example

The .NET Code Ejector

Code Ejection Demonstration

.NET Internals (Part 2: MethodDesc)

.NET Internals (Part 3: IEE, Internal Calls, etc.)

Other Injection/Ejection Approaches

Conclusions [h=2]Introduction[/h] This article is the obvious culmination of the previous effort of writing the Rebel.NET application and the first of a two series of articles about the .NET framework internals and the protections available for .NET assemblies. The next article will be about .NET native compiling. As the JIT inner workings haven't been analyzed yet, .NET protections are quite naïf nowadays. This situation will rapidly change as soon as the reverse engineering community will focus its attention on this technology. These two articles are aimed to raise the consiousness about the current state of .NET protections and what is possible to achieve but hasn't been done yet. In particular, the current article about .NET code injection represents, let's say, the present, whereas the next one about .NET native compiling represents the future. What I'm presenting in these two articles is new at the time I'm writing it, but I expect it to become obsolete in less than a year. Of course, this is obvious as I'm moving the first steps out from current .NET protections in the direction of better ones. But this article isn't really about protections: exploring the .NET framework internals can be useful for many purposes. So, talking about protections is just a means to an end.

[h=2]What is .NET Code Injection?[/h] .NET code injection is the "strong" brother of .NET packers (which unpack the entire assembly in memory). What .NET code injectors do is to hook the JIT and when the MSIL code of a method is requested they filter the request and provide the real MSIL instead of the MSIL contained in the assembly, which, most of the times, is just a ret. By injecting one (or quasi) method at a time, the MSIL code will remain conceiled. Even if one manages to dump the code, it isn't to be expected that the protection left the necessary space for the real MSIL code in the .NET assembly, although many commercial protections do so. Rebuilding the assembly from scratch is the universally valid way to proceed. This, of course, is not a problem with Rebel.NET.

It should be obvious to the reader that .NET code injectors aren't reliable protections. It's just playing hide and seek with the reverser. But, as many software producers are putting their intellectual property in the hands of such protections, it is necessary to analyze them throughout.

[h=2]How does .NET Code Injection work?[/h] One thing should be clear from the beginning: there isn't only one method to inject MSIL. Thus, to remove this kind of protection you have to evaluate the specific case.

A very clean approach, though unused yet, would be to inject the MSIL through the .NET profiling API. There's a very in depth article about the .NET profiling API by Aleksandr Mikunov on MSDN. Anyway, as I already said, this approach isn't used by .NET protections. I referred to this approach as clean, simply because it uses the API provided by the framework itself. Thus, it'll work on every .NET framework no matter what. Whereas .NET protections usually hook the JIT and this, although it might work just as well, it is not guaranteed to do so.

The .NET framework's JIT is contained in the mscorjit.dll module. To identify the part of the JIT being hooked by the .NET protection there's a very simple an effect way: dumping the mscorjit.dll module from the protection's process and comparing it to the original module on disk. I wrote a little CFF Explorer Script to make a comparision of a PE section which excludes the IAT in the comparision. This is especially useful when comparing the .text section of two executables.

-Download the Section Comparer script

It was a ten minutes job and it is extremely useful to identify the type of hook applied to the JIT. Let's look at a possible output of this script:

Comparision between section 0 of

C:\...\mscorjit.dll

and

C:\...\mscorjit_dumped.dll

Differences found at:

RVA1 RVA2

000460A0 000460A0

000460A1 000460A1

000460A2 000460A2

000460A3 000460A3

Number of differences found: 4

Tutorial:

http://www.ntcore.com/files/netint_injection.htm

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...