Click here to Skip to main content
13,458,235 members
Click here to Skip to main content
Add your own
alternative version

Tagged as


337 bookmarked
Posted 21 Sep 2012

.Net CLR Injection : Modify IL Codes on Run-time

, 21 Sep 2012
Rate this:
Please Sign up or sign in to vote.
Modify methods' IL codes on runtime even if they have been jit-compiled, supports release mode, and variants of .Net versions, from 2.0 to 4.0
This is an old version of the currently published article.


Modifying .Net methods' MSIL codes during run-time is very cool, it helps to implement hooking, software protection and other amazing stuff. That's why I want it, but there is a big challenge on the road -- the MSIL code could have been complied to native code by JIT-complier before we have a chance to modify them; also the .Net CLR implantation is not documented and it changes during each version, we need a stable way. 

 Anyway, after more than one week research, finally I made it!
Here is a simple method in the demo problem  

protected string CompareOneAndTwo()
    int a = 1;
    int b = 2;
    if (a < b)
        return "Number 1 is less than 2";
        return "Number 1 is greater than 2 (O_o)";

 Certainly it returns "Number 1  is less than 2"; let's try to make it returns the incorrect result Smile | <img src= " src="" />  

Looking at the MSIL codes for this method, we can do it by changing the OpCode from Bge_S to Blt_S. and then the jump works in a different logic which returns wrong result, that is what I need.


After modifying the IL, it returns wrong answer as below.

 Here is the code replacing the IL, I assume there are enough comments between the lines.

 You can download the demo program and have a try.

  • Supports variants of .Net versions  from 2.0 to 4.0 
  • Supports variants of methods to be modifid, including dynamic method and generic method
  • Supports release mode .Net process.   

The demo contains the PDB files and its size exceeds 10MB, so can't be updated here. Here is the download link from 3rd-party file sharing service.

Using the code     

Source Code can be downloaded here : Download source
Copy the InjectionHelper.cs file into your project, it contains 3 methods.
 public static class InjectionHelper
    // Load the unmanaged injection.dll, the initlaization happens in a background thread
    // you can check if the initialization is completed by GetStatus()
    public static void Initialize()
    // Unload the unmanaged injection.dll
    public static void Uninitialize()
    // Update the IL Code of a Method.
    public static void UpdateILCodes(MethodInfo method, byte[] ilCodes) 
    // The method returns until the initialization is completed
    public static Status WaitForIntializationCompletion()
    // Query the current status of the unmanaged dll, returns immediately.
    public static Status GetStatus()

 The  InjectionHelper.Initialize method loads the unmanaged injection.dll from the directory of current Assembly directory, so all the related files need be there, or you can modify the code to change the location.

Here is the file list. 

File NameDescription
Injection.dllunmanaged dll to do the work in this article.
(x86 version, x64 version will be out sooner or later)
EasyHook32.dllx86 EasyHook dll from
(used by Injection.dll)
EasyHook64.dll x86 EasyHook dll from (will be used by x64 Injection.dll)
Tool to download PDB file from Windows Debug Tools.
dbg32.dllx86 version of dbghelp.dll 6.2.
used by Injection.dll and symchk.exe
I changed the file name to avoid version confliction.
Also The PE import table of symchk.exe is modied to link to this dll.
PDB_symbols/*The PDB symbol files local cache. can be removed but will slow down the intialization.
Test_x86_Net20_Release.exeTest program for x86 / .Net2.0 / Release mode, not required for distrubution
Test_x86_Net35_Release.exeTest program for x86 / .Net3.5 / Release mode, not required for distrubution 
Test_x86_Net40_Release.exeTest program for x86 / .Net4.0 / Release mode, not required for distrubution


Replace the IL code 

First, take a look at how the CLR & JIT works.

The JIT implementation dlls (clrjit.dll for .Net4.0+ / mscorjit.dll for .Net2.0+) expose a _stdcall method getJit, which returns the ICorJitCompiler interface. 

The CLR implementation dlls (clr.dll for .Net4.0+ / mscorwks.dll for .Net2.0+) invokes the getJit method to obtain ICorJitCompiler interface, then call its compileMethod method to complie MSIL code to native code.

CorJitResult compileMethod(ICorJitInfo * pJitInfo, CORINFO_METHOD_INFO * pMethodInfo, UINT nFlags, LPBYTE * pEntryAddress, ULONG * pSizeOfCode);

This part is quite easy, just find the location of the compileMethod method, replace the entry via EasyHook.

// define the interface method function pointer
typedef CorJitResult (__stdcall ICorJitCompiler::*PFN_compileMethod)(ICorJitInfo * pJitInfo
	, UINT nFlags
	, LPBYTE * pEntryAddress
	, ULONG * pSizeOfCode
// store the address of the real compileMethod
PFN_compileMethod_V4 s_pComplieMethod = ...; 
// hook the compileMethod with my own compileMethod
LhInstallHook( (PVOID&)s_pComplieMethod
		, &(PVOID&)CInjection::compileMethod
		, NULL
		, &s_hHookCompileMethod
// and here is my compileMethod
CorJitResult __stdcall CInjection::compileMethod(ICorJitInfo * pJitInfo
	, UINT nFlags
	, LPBYTE * pEntryAddress
	, ULONG * pSizeOfCode
	// TO DO: modify IL codes here 

	// Call real compileMethod
	CorJitResult result = (pCorJitCompiler->*s_pComplieMethod_V4)( pJitInfo, pCorMethodInfo, nFlags, pEntryAddress, pSizeOfCode);
	return result;

Modify IL code for jit-complied methods

Now we are here, the compileMethod method above won't be called by CLR for jit-compiled method. To solve this problem, my idea is to restore the data structures in CLR to previous status before jit-compliation. And in this case, the complileMethod will be called again and we can replace the IL

Thus, we have to look into the implementation of CLR a bit, SSCLI (Shared Source Common Language Infrastructure) is a good reference from Microsoft although it is quite out of date and we can't use it in our code.

The above diagram is a bit out of date, but the primary structure is the same. For each "class" in .Net, there is at least one MethodTable structure in memory. and each MethodTable is related to a EEClass, which stores the runtime type information for reflection and other use.  

For each "method", there is a MethodDesc data structure in memory, containing information of this method like flags / slot address / entry address / etc.  

Before a method is jitted-complied, the slot is pointed to a JMI thunk(Prestub), which triggers jit-compliation; When the IL code is complied, the slot is rewritten to point to the JMI thunk, which jumps to complied native code directly.

To restore the data structure, first clear the flags, then modify the entry address back to temporary entry address, and so on. I successfully did that in debugger by modifying the memory directly. but this is messy, it depends on the layout of the data structures, and the code is unreliable for different version of .Net.

Luckly, I found the method MethodDesc::Reset in SSCLI doing the same job.

void MethodDesc::Reset()
    // This method is not thread-safe since we are updating
    // different pieces of data non-atomically.
    // Use this only if you can guarantee thread-safety somehow.

    _ASSERTE(IsEnCMethod() || // The process is frozen by the debugger
             IsDynamicMethod() || // These are used in a very restricted way
             GetLoaderModule()->IsReflection()); // Rental methods                                                                 

    // Reset any flags relevant to the old code
    if (HasPrecode())
        // We should go here only for the rental methods
        InterlockedUpdateFlags2(enum_flag2_HasStableEntryPoint | enum_flag2_HasPrecode, FALSE);
        *GetAddrOfSlotUnchecked() = GetTemporaryEntryPoint();

As you can see above, it is doing the same thing for me. Hence, the target is changed to invoke this method to reset the MethodDesc status to Pre-Jitted.  

Certainly I can't use the MethodDesc from SSCLI, and the MethodDesc is internal used by MS, whose exact implmentation and layout are unknown to everyone except Microsoft. 

After endless mountains and rivers that leave doubt whether there is a path out, suddenly one encounters the shade of a willow, bright flowers and a lovely village.

Yes, luckly this internal method exists in the PDB symbol from Microsoft Symbol Server, and this solves my problem. Reset() method's address in the CLR dll can be known by parsing the PDB file,

Now only one mandatory parameter is left -- this pointer of MethodDesc.  it is not hard to obtain this pointer. actually MethodBase.MethodHandle.Value == CORINFO_METHOD_HANDLE == MethodDesc address == this pointer of MethodDesc .

Thus, I have my MethodDesc class below defined in unmanaged code.

typedef void (MethodDesc::*PFN_Reset)(void);
typedef BOOL (MethodDesc::*PFN_IsGenericMethodDefinition)(void);
typedef ULONG (MethodDesc::*PFN_GetNumGenericMethodArgs)(void);
typedef MethodDesc * (MethodDesc::*PFN_StripMethodInstantiation)(void);
typedef BOOL (MethodDesc::*PFN_HasClassOrMethodInstantiation)(void);
typedef BOOL (MethodDesc::*PFN_ContainsGenericVariables)(void);    
typedef DictionaryLayout * (MethodDesc::*PFN_GetDictionaryLayout)(void);
typedef Dictionary * (MethodDesc::*PFN_GetMethodDictionary)(void);
typedef MethodDesc * (MethodDesc::*PFN_GetWrappedMethodDesc)(void);
class MethodDesc
    void Reset(void) { (this->*s_pfnReset)(); }
    BOOL IsGenericMethodDefinition(void) { return (this->*s_pfnIsGenericMethodDefinition)(); }
    ULONG GetNumGenericMethodArgs(void) { return (this->*s_pfnGetNumGenericMethodArgs)(); }
    MethodDesc * StripMethodInstantiation(void) { return (this->*s_pfnStripMethodInstantiation)(); }
    BOOL HasClassOrMethodInstantiation(void)  { return (this->*s_pfnHasClassOrMethodInstantiation)(); }
    BOOL ContainsGenericVariables(void) { return (this->*s_pfnContainsGenericVariables)(); }
    DictionaryLayout * GetDictionaryLayout(void) { return (this->*s_pfnGetDictionaryLayout)(); }
    Dictionary * GetMethodDictionary(void) { return (this->*s_pfnGetMethodDictionary)(); }
    MethodDesc * GetWrappedMethodDesc(void) { return (this->*s_pfnGetWrappedMethodDesc)(); }
    static PFN_Reset s_pfnReset;
    static PFN_IsGenericMethodDefinition s_pfnIsGenericMethodDefinition;
    static PFN_GetNumGenericMethodArgs s_pfnGetNumGenericMethodArgs;
    static PFN_StripMethodInstantiation s_pfnStripMethodInstantiation;
    static PFN_HasClassOrMethodInstantiation s_pfnHasClassOrMethodInstantiation;
    static PFN_ContainsGenericVariables s_pfnContainsGenericVariables;
    static PFN_GetDictionaryLayout s_pfnGetDictionaryLayout;
    static PFN_GetMethodDictionary s_pfnGetMethodDictionary;
    static PFN_GetWrappedMethodDesc s_pfnGetWrappedMethodDesc;

The static variables above store the addresses of the internal methods from MethodDesc implmentation from CLR dll. and they are initialized when my unmanaged dll loaded. And the public members just call the internal method with this pointer. 

Now it becomes quite easy to invoke Microsoft's internal methods. like:

MethodDesc * pMethodDesc = (MethodDesc*)pMethodHandle;

Find internal methods' addresses from PDB Symbol file.

When the unmanaged dll is loaded, it checkes the environment to see which version of CLR/JIT is there. And try to seek the address for all the internal methods from PDB file; If the seek failed, it will try to launch symchk.exe from Windows Debug Tools to download the corresponding PDB symbol files from Microsoft Symbol Server. This procedure requires a bit long time from several seconds to several minutes.  Maybe we can optimize to cache the address of the CLR/JIT dlls by caculating their binary hash value.

You can see more details in the source code,  SearchMethodAddresses and Intialize method from unmanaged dll.

Reset the MethodDesc to Pre-Jitted Status 

Now everything is ready. The unmanaged dll exports an method for managed codes, accept the IL codes and  MethodBase.MethodHandle.Value from managed code.

BOOL CInjection::StartUpdateILCodes( MethodTable * pMethodTable
    , LPBYTE pBuffer
    , DWORD dwSize
    if( s_nStatus != Status_Ready || !pMethodHandle )
        return FALSE;
    MethodDesc * pMethodDesc = (MethodDesc*)pMethodHandle;
    MethodDesc * pStripMethodDesc = pMethodDesc->StripMethodInstantiation();
    if( pStripMethodDesc )
    // this is a generic method
    if( pMethodDesc->HasClassOrMethodInstantiation() )
        MethodDesc * pWrappedMethodDesc = pMethodDesc->GetWrappedMethodDesc();
        if( pWrappedMethodDesc )
    std::map< CORINFO_METHOD_HANDLE, ILCodeBuffer>::iterator iter = s_mpILBuffers.find(pMethodHandle);
    if( iter != s_mpILBuffers.end() )
    ILCodeBuffer tILCodeBuffer = { pBuffer, dwSize };
    s_mpILBuffers[pMethodHandle] = tILCodeBuffer;
    return TRUE;

The code above just call the Reset() method, and store the IL codes in a map, which will be used by complieMethod when method get complied.

And in complieMethod, just replace the ILCode, code like below.

 CorJitResult __stdcall CInjection::compileMethod(ICorJitInfo * pJitInfo
    , CORINFO_METHOD_INFO * pCorMethodInfo
    , UINT nFlags
    , LPBYTE * pEntryAddress
    , ULONG * pSizeOfCode
    ICorJitCompiler * pCorJitCompiler = (ICorJitCompiler *)this;
    LPBYTE pOriginalILCode = pCorMethodInfo->ILCode;
    unsigned int nOriginalSize = pCorMethodInfo->ILCodeSize;
    // find the method to be replaced
    std::map< CORINFO_METHOD_HANDLE, ILCodeBuffer>::iterator iter = s_mpILBuffers.end();
    if( pCorMethodInfo && GetStatus() == Status_Ready )
        MethodDesc * pMethodDesc = (MethodDesc*)pCorMethodInfo->ftn;
        std::map< CORINFO_METHOD_HANDLE, ILCodeBuffer>::iterator iter = s_mpILBuffers.find((CORINFO_METHOD_HANDLE)pMethodDesc);
        // if the current method is not found, try to search its generic definition method
        if( iter == s_mpILBuffers.end() &&
            pMethodDesc->HasClassOrMethodInstantiation() )
            pMethodDesc = pMethodDesc->StripMethodInstantiation();
            iter = s_mpILBuffers.find((CORINFO_METHOD_HANDLE)pMethodDesc);
        if( iter != s_mpILBuffers.end() )
            pCorMethodInfo->ILCode = iter->second.pBuffer;
            pCorMethodInfo->ILCodeSize = iter->second.dwSize;
    CorJitResult result = (pCorJitCompiler->*s_pComplieMethod_V4)( pJitInfo, pCorMethodInfo, nFlags, pEntryAddress, pSizeOfCode);
    if( iter != s_mpILBuffers.end() )
        pCorMethodInfo->ILCode = pOriginalILCode;
        pCorMethodInfo->ILCodeSize = nOriginalSize;
    return result;

Points of Interest

Compilation Optimizations

I found that -- if the method is too simple and the IL codes are only several bytes (Like the attributes), the method will be complied as inline mode. and in this case. Reset MethodDesc does not help anything because the execution even doesn't reach there. 

Dynamic Method 

To update the IL code of dynamic method need be very careful.
Filling incorrect IL code for other kind of methods only causes an InvalidApplicationException; but incorrect IL codes in dynamic method can crash CLR and the whole process!  And IL code for dynamic method is different than others. better to generate the IL codes from another dynamic method and then copy & update.

Generic Method 

I think this is the most complicated part. A generic definition method is mapped to a MethodDesc. but calling the generic method with different type parameters will cause the CLR create a series of instantiations of the definition method. Even more, different kind of generic method is implemented in different way.

// 1.   shared generic method instantiations
// 2.   unshared generic method instantiations
// 3.   instance methods in shared generic classes
// 4.   instance methods in unshared generic classes
// 5.   static methods in shared generic classes.
// 6.   static methods in unshared generic classes.

I don't find out a good way to get all the instantiations for a generic definition, so the code in the demo looks like:
MethodInfo destMethodInfo = type.GetMethod("GenericMethodToBeReplaced", BindingFlags.NonPublic | BindingFlags.Instance);

// reset the generic definition MethodInfo
InjectionHelper.UpdateILCodes(destMethodInfo, ilCodes);

// reset a specific instantiation  generic MethodInfo
destMethodInfo = destMethodInfo.MakeGenericMethod(new Type[] { typeof(string), typeof(int) });
InjectionHelper.UpdateILCodes(destMethodInfo, ilCodes);

The above code only works when you know the type parameter of the generic method. A jit-complied generic method with different type parameter won't be affected.

Anyway, it is not a perfect way, but works for most of cases.  I am still looking for a better way. hope you can give me some suggestions :)



This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Team Leader
China China
Jerry is from China. He was captivated by computer programming since 13 years old when first time played with Q-Basic.

  • Windows / Linux & C++
  • iOS & Obj-C
  • .Net & C#
  • Flex/Flash & ActionScript
  • HTML / CSS / Javascript
  • Gaming Server programming / video, audio processing / image & graphics

Contact: vcer(at)
Chinese Blog:

You may also be interested in...


Comments and Discussions

Discussions on this specific version of this article. Add your comments on how to improve this article here. These comments will not be visible on the final published version of this article.
GeneralSounds useful but limited Pin
UlyssesWu1-Nov-17 21:52
memberUlyssesWu1-Nov-17 21:52 
QuestionAssemblies from Current Domain Pin
Member 122867659-Oct-16 19:57
memberMember 122867659-Oct-16 19:57 
NewsProject for 2015VS Pin
MArtmath9-Jun-16 13:06
memberMArtmath9-Jun-16 13:06 
GeneralWork on > 4.6.1038 net and 2015VS Pin
MArtmath18-Apr-16 23:01
memberMArtmath18-Apr-16 23:01 
QuestionThis demo is not work Pin
Member 1106044328-Feb-16 19:39
memberMember 1106044328-Feb-16 19:39 
QuestionUpdating Exception Handler offsets Pin
d j30-May-15 0:59
memberd j30-May-15 0:59 
QuestionWould it be possible to also release the server source code? Pin
c63726973746910-Apr-15 5:46
memberc63726973746910-Apr-15 5:46 
AnswerRe: Would it be possible to also release the server source code? Pin
Dang Xuan Hieu29-Dec-15 19:01
memberDang Xuan Hieu29-Dec-15 19:01 
QuestionWhen i try to compile i always get a error Pin
tiktaktoe28-Nov-14 21:53
membertiktaktoe28-Nov-14 21:53 
AnswerRe: When i try to compile i always get a error Pin
tiktaktoe29-Nov-14 11:33
membertiktaktoe29-Nov-14 11:33 
Questionhelp me Pin
mohsen.keshavarzi9-Nov-14 7:10
membermohsen.keshavarzi9-Nov-14 7:10 
QuestionIl Call instruction Pin
Dmitry Post20-Oct-14 9:34
memberDmitry Post20-Oct-14 9:34 
QuestionAppears not to work in remote process Pin
c6372697374693-Oct-14 12:20
memberc6372697374693-Oct-14 12:20 
AnswerRe: Appears not to work in remote process Pin
Jerry.Wang3-Oct-14 16:20
memberJerry.Wang3-Oct-14 16:20 
GeneralRe: Appears not to work in remote process Pin
c6372697374693-Oct-14 20:56
memberc6372697374693-Oct-14 20:56 
GeneralRe: Appears not to work in remote process Pin
c6372697374695-Oct-14 6:30
memberc6372697374695-Oct-14 6:30 
GeneralRe: Appears not to work in remote process Pin
f3re14-Oct-14 14:28
memberf3re14-Oct-14 14:28 
QuestionRe: Appears not to work in remote process Pin
UlyssesWu9-Oct-15 2:14
memberUlyssesWu9-Oct-15 2:14 
AnswerRe: Appears not to work in remote process Pin
UlyssesWu10-Oct-15 3:04
memberUlyssesWu10-Oct-15 3:04 
QuestionCan't run in Win2003 Server SP2 Pin
iolir14-Aug-14 3:26
memberiolir14-Aug-14 3:26 
AnswerRe: Can't run in Win2003 Server SP2 Pin
iolir15-Aug-14 6:05
memberiolir15-Aug-14 6:05 
GeneralRe: Can't run in Win2003 Server SP2 Pin
Jerry.Wang16-Aug-14 2:10
memberJerry.Wang16-Aug-14 2:10 
QuestionCan inject in x64 but not in x86 Pin
iolir13-Aug-14 23:27
memberiolir13-Aug-14 23:27 
AnswerRe: Can inject in x64 but not in x86 Pin
Jerry.Wang16-Aug-14 2:12
memberJerry.Wang16-Aug-14 2:12 
QuestionMy Vote of 5++ Pin
2006 Flauzer7-Aug-14 8:15
professional2006 Flauzer7-Aug-14 8:15 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.180323.1 | Last Updated 22 Sep 2012
Article Copyright 2012 by Jerry.Wang
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid