mscorwks.dll在.Net中的地位以及在.Net程式碼保護方面的應用

mscorwks.dll是dotNet的核心檔案，尤其是在net2.0中，以前分散的功能都集中到了這個dll中。
net1.1中，還有一個檔案mscorsvr.dll 和 mscorwks.dll 是同等地位的。
它們分別對應於 windows service程式以及 desktop 程式。
在net2.0中，它們都統一到了 mscorwks。dll中。
同時在net2.0中mscorsn.dll 的功能也合併到了 mscorwks.dll中。
它就是dotnet執行庫的核心。
DotNet的執行引擎（ee）,內部物件的實現都在這個dll裡面。

在我們用reflector檢視dotnet類庫原始碼時經常會遇到一些函式看不到原始碼，只是標記成內部實現。這些函式基本上實際實現的程式碼就在這個dll裡面，是native實現的。如反射功能的相關物件以及實現就是這裡面。

net程式的執行主要由它來完成，還有另外一個重要的檔案mscorjit.dll 被它所呼叫。
現在我們把 mscorwks.dll 分成兩個區 A 和 B，
A 是主要執行引擎（ee）和native 實現。
B 是ee呼叫jit的處理部分。

net2.0的反射功能是在A區實現的。加密殼如果要實現完美的相容性（即不破壞DotNet本身的任何功能和特性）就應該在 A 區掛入其核心。
在A區有一個函式實現獲取方法體的內容，ee層需要取得方法體內容是通過這個函式來獲得的。因此完美的方法就是 替換這個函式，用加密殼的核心實現這個函式。

這樣的最大缺點就是反射漏洞，因為反射也是呼叫這個函式取得方法體的。

在這個基礎上要要破壞反射有什麼辦法呢？
在反射是需要呼叫Method的成員函式GetMethodBody，這個函式是native實現的，就在mscorwks。dll中，因此加密殼可以hook這個函式做一些預防處理。
但是效果不理想，破解者可以恢復這個函式的原始實現。

還有一個方法，不是完美，但是有效，即不直接替換獲取方法體的函式，
而是隻替換編譯前獲取方法體的地方。這樣只在要編譯方法時才提供核心解密服務。

效果如何？也不太理想，破解這可以修改反射的實現函式，直接jmp到加密殼的核心服務。

這種方式就是DNGuard v1.0採用的方法，似乎也是某殼目前版本的方法。
當然，DNGuard 1.0還簡單的加入了放記憶體修改，不過這個效果也能太樂觀，破解者也能夠把這部分遮蔽掉。
因為反射在A區實現，如果殼的核心也掛接A區，反射就比較容易修復。

在我做DNGuard 2.0之前，我曾想過一種方法，能使反射無效，甚至難於修復。
即同時在核心掛接在 A 區，和 B區。
先來介紹一下一個函式要被執行是是怎麼個流程。
首先，EE會檢查函式是否編譯？編譯了就直接呼叫了。沒有編譯就進行編譯。由一個prestub實現。
然後EE取得方法體，對方法頭和SEH TAble進行簡單解析，轉換成結構。
（這些在A區完成），進入B區呼叫Jit進行編譯。

在A區ee只關係方法頭和sehtable，而B區呼叫jit時 il位元組碼才有實際意義。
所以可以將核心分別掛接這兩個區，A區中只提供header和seh，B區中提供il位元組碼。

不過在我開始做DNGuard v2.0後就放棄了這個想法，因為這樣還是不安全。
參考這裡：深入Jit，實現dotNet程式碼的加解密

不管核心是在A區還是B區，如果一個加密殼的核心只限於在mscorwks.dll進行掛接實現。那麼都無法脫逃 jit層脫殼機的脫殼。我在寫文章“深入Jit，實現dotNet程式碼的加解密 ”時已經進行過測試了。

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