mscorwks
dll是dotNet的核心文件
尤其是在net
中
以前分散的功能都集中到了這個dll中
net
中
還有一個文件mscorsvr
dll 和 mscorwks
dll 是同等地位的
它們分別對應於 windows service程序以及 desktop 程序
在net
中
它們都統一到了 mscorwks
dll中
同時在net
中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的處理部分
net
的反射功能是在A區實現的
加密殼如果要實現完美的兼容性（即不破壞DotNet本身的任何功能和特性）就應該在 A 區掛入其內核
在A區有一個函數實現獲取方法體的內容
ee層需要取得方法體內容是通過這個函數來獲得的
因此完美的方法就是 替換這個函數
用加密殼的內核實現這個函數
這樣的最大缺點就是反射漏洞
因為反射也是調用這個函數取得方法體的
在這個基礎上要要破壞反射有什麼辦法呢？
在反射是需要調用Method的成員函數GetMethodBody
這個函數是native實現的
就在mscorwks
dll中
因此加密殼可以hook這個函數做一些預防處理
但是效果不理想
破解者可以恢復這個函數的原始實現
還有一個方法
不是完美
但是有效
即不直接替換獲取方法體的函數
而是只替換編譯前獲取方法體的地方
這樣只在要編譯方法時才提供內核解密服務
效果如何？也不太理想
破解這可以修改反射的實現函數
直接jmp到加密殼的內核服務
這種方式就是DNGuard v
采用的方法
似乎也是某殼目前版本的方法
當然
DNGuard
還簡單的加入了放內存修改
不過這個效果也能太樂觀
破解者也能夠把這部分屏蔽掉
因為反射在A區實現
如果殼的內核也掛接A區
反射就比較容易修復
在我做DNGuard
之前
我曾想過一種方法
能使反射無效
甚至難於修復
即同時在內核掛接在 A 區
和 B區
先來介紹一下一個函數要被執行是是怎麼個流程
首先
EE會檢查函數是否編譯？編譯了就直接調用了
沒有編譯就進行編譯
由一個prestub實現
然後EE取得方法體
對方法頭和SEH TAble進行簡單解析
轉換成結構
（這些在A區完成）
進入B區調用Jit進行編譯
在A區ee只關系方法頭和sehtable
而B區調用jit時 il字節碼才有實際意義
所以可以將內核分別掛接這兩個區
A區中只提供header和seh
B區中提供il字節碼
不過在我開始做DNGuard v
後就放棄了這個想法
因為這樣還是不安全
參考這裡
深入Jit
實現dotNet代碼的加解密
不管內核是在A區還是B區
如果一個加密殼的內核只限於在mscorwks
dll進行掛接實現
那麼都無法脫逃 jit層脫殼機的脫殼
我在寫文章
深入Jit
實現dotNet代碼的加解密
時已經進行過測試了
今回到這裡
下回介紹mscorjit
dll
From:http://tw.wingwit.com/Article/program/ASP/201311/21707.html
