mscorwks.dll是dotNet的核心文件，尤其是在net2.0中，以前分散的功能都集中到了這個dll中。
net1.1中，還有一個文件mscorsvr.dll 和 mscorwks.dll 是同等地位的。
它們分別對應(yīng)于 windows service程序以及 desktop 程序。
在net2.0中，它們都統(tǒng)一到了 mscorwks。dll中。
同時在net2.0中mscorsn.dll 的功能也合并到了 mscorwks.dll中。
它就是dotnet運行庫的核心。
DotNet的執(zhí)行引擎（ee）,內(nèi)部對象的實現(xiàn)都在這個dll里面。

在我們用reflector查看dotnet類庫源代碼時經(jīng)常會遇到一些函數(shù)看不到源代碼，只是標(biāo)記成內(nèi)部實現(xiàn)。這些函數(shù)基本上實際實現(xiàn)的代碼就在這個dll里面，是native實現(xiàn)的。如反射功能的相關(guān)對象以及實現(xiàn)就是這里面。

net程序的執(zhí)行主要由它來完成，還有另外一個重要的文件mscorjit.dll 被它所調(diào)用。
現(xiàn)在我們把 mscorwks.dll 分成兩個區(qū) A 和 B，
A 是主要執(zhí)行引擎（ee）和native 實現(xiàn)。
B 是ee調(diào)用jit的處理部分。

net2.0的反射功能是在A區(qū)實現(xiàn)的。加密殼如果要實現(xiàn)完美的兼容性（即不破壞DotNet本身的任何功能和特性）就應(yīng)該在 A 區(qū)掛入其內(nèi)核。
在A區(qū)有一個函數(shù)實現(xiàn)獲取方法體的內(nèi)容，ee層需要取得方法體內(nèi)容是通過這個函數(shù)來獲得的。因此完美的方法就是 替換這個函數(shù)，用加密殼的內(nèi)核實現(xiàn)這個函數(shù)。

這樣的最大缺點就是反射漏洞，因為反射也是調(diào)用這個函數(shù)取得方法體的。

在這個基礎(chǔ)上要要破壞反射有什么辦法呢？
在反射是需要調(diào)用Method的成員函數(shù)GetMethodBody，這個函數(shù)是native實現(xiàn)的，就在mscorwks。dll中，因此加密殼可以hook這個函數(shù)做一些預(yù)防處理。
但是效果不理想，破解者可以恢復(fù)這個函數(shù)的原始實現(xiàn)。

還有一個方法，不是完美，但是有效，即不直接替換獲取方法體的函數(shù)，
而是只替換編譯前獲取方法體的地方。這樣只在要編譯方法時才提供內(nèi)核解密服務(wù)。

效果如何？也不太理想，破解這可以修改反射的實現(xiàn)函數(shù)，直接jmp到加密殼的內(nèi)核服務(wù)。

這種方式就是DNGuard v1.0采用的方法，似乎也是某殼目前版本的方法。
當(dāng)然，DNGuard 1.0還簡單的加入了放內(nèi)存修改，不過這個效果也能太樂觀，破解者也能夠把這部分屏蔽掉。
因為反射在A區(qū)實現(xiàn)，如果殼的內(nèi)核也掛接A區(qū)，反射就比較容易修復(fù)。

在我做DNGuard 2.0之前，我曾想過一種方法，能使反射無效，甚至難于修復(fù)。
即同時在內(nèi)核掛接在 A 區(qū)，和 B區(qū)。
先來介紹一下一個函數(shù)要被執(zhí)行是是怎么個流程。
首先，EE會檢查函數(shù)是否編譯？編譯了就直接調(diào)用了。沒有編譯就進行編譯。由一個PRestub實現(xiàn)。
然后EE取得方法體，對方法頭和SEH TAble進行簡單解析，轉(zhuǎn)換成結(jié)構(gòu)。
（這些在A區(qū)完成），進入B區(qū)調(diào)用Jit進行編譯。

在A區(qū)ee只關(guān)系方法頭和sehtable，而B區(qū)調(diào)用jit時 il字節(jié)碼才有實際意義。
所以可以將內(nèi)核分別掛接這兩個區(qū)，A區(qū)中只提供header和seh，B區(qū)中提供il字節(jié)碼。

不過在我開始做DNGuard v2.0后就放棄了這個想法，因為這樣還是不安全。
參考這里：深入Jit，實現(xiàn)dotNet代碼的加解密

不管內(nèi)核是在A區(qū)還是B區(qū)，如果一個加密殼的內(nèi)核只限于在mscorwks.dll進行掛接實現(xiàn)。那么都無法脫逃 jit層脫殼機的脫殼。我在寫文章“深入Jit，實現(xiàn)dotNet代碼的加解密 ”時已經(jīng)進行過測試了。

今回到這里，下回介紹mscorjit。dll。