在 per method 的(de)dotNet加密中，首要解決的(de)方法體對應關系，即在運行(xíng)時加密殼如(rú)何确定當前要解密的(de)方法體所對應的(de)加密信息。

　　目前大(dà)部分(fēn)加密殼都(dōu)直接利用(yòng)了dotNet的(de)元數據來保存這種對應關系，我們知道在元數據中每個(gè)方法都(dōu)會(huì)對應一個(gè)RVA值，加密殼可(kě)以直接把這個(gè)關系記錄在RVA的(de)地(dì)址處。在框架運行(xíng)中RVA處的(de)數據會(huì)被作爲“方法體”在處理(lǐ)流程中直接傳遞，加密殼通過攔截框架處理(lǐ)流程中的(de)函數，來對“方法體”進行(xíng)分(fēn)流處理(lǐ)。即先判斷RVA處的(de)數據是否“方法體加密對應信息”，如(rú)果是進入加密殼運行(xíng)庫的(de)内部處理(lǐ)，不是則按原框架流程處理(lǐ)。

　　對于這個(gè)“方法體加密對應信息”，最簡單的(de)方式是指記錄一個(gè)指針信息，指向另一處數據塊，四字節空間就夠了。但(dàn)是爲了和(hé)普通沒有(yǒu)加密的(de)方法體進行(xíng)區分(fēn)，除了這個(gè)之外還需要增加一些唯一标識以便能(néng)被運行(xíng)庫在運行(xíng)時安全無誤的(de)區分(fēn)出來。

　　大(dà)家可(kě)以用(yòng)UE打開(kāi)，加密後的(de)程序集，看看一個(gè)方法體RVA處的(de)數據，應該能(néng)很容易分(fēn)别出來哪些是記錄的(de)“方法體加密對應信息”。

　　正是這個(gè)原因，所以DNGuard v1.0和(hé)同類處理(lǐ)方式的(de)加密殼，對方法體小(xiǎo)于某個(gè)指定字節數的(de)，就不能(néng)進行(xíng)加密。

　　因爲“方法體加密對應信息”的(de)大(dà)小(xiǎo)超過的(de)方法體的(de)空間大(dà)小(xiǎo)，寫入的(de)話(huà)會(huì)覆蓋到(dào)後面方法體的(de)信息。這實際上(shàng)也(yě)是因爲偷懶造成的(de)。可(kě)以通過對方法體進行(xíng)重排來解決這個(gè)問題，當然要麻煩很多了。

　　這種模式實際上(shàng)就是在元數據保存了一個(gè)虛拟表實現了 MethodToken => “方法體加密對應信息” 的(de)對應記錄。這個(gè)表可(kě)以看著(zhe)是公開(kāi)的(de)。

　　在DNGuard 2007 中我沒有(yǒu)選擇使用(yòng)對方法體重排的(de)方式來解決這個(gè)問題，而是選擇了另一個(gè)方法，自己記錄一個(gè) 虛拟表實現：MethodToken => “方法體加密對應信息” 的(de)對應記錄。

　　因爲這樣有(yǒu)一個(gè)好處，就是 這個(gè)虛拟表也(yě)可(kě)以進行(xíng)加密後保存。另外就是“方法體加密對應信息”中不需要添加标識符 和(hé)普通沒有(yǒu)加密的(de)方法體進行(xíng)區分(fēn)。

　　在 DNGuard 2007 試用(yòng)版 中沒有(yǒu)使用(yòng)真正的(de)加密算法來對程序集加密，隻是采用(yòng)了“代碼直接挪位”的(de)方式，運行(xíng)庫的(de)“解密”操作隻是從另一個(gè)位置直接讀(dú)取的(de)操作。

　　有(yǒu)個(gè)朋友(yǒu)分(fēn)析到(dào)DNGuard 試用(yòng)版裏面有(yǒu)一個(gè)虛拟表記錄了：MethodRid => ILCode。這個(gè)就是 虛拟表：MethodToken => “方法體加密對應信息” 在 試用(yòng)版中退化的(de)模式。

　　另外因爲方法體隻是挪位，所以它實際上(shàng)還是在程序集文(wén)件(jiàn)内，加載到(dào)内存中後也(yě)在程序集模塊的(de)内存空間中。而不是那位朋友(yǒu)說的(de) 運行(xíng)庫在解密後将 IL代碼 填回到(dào)内存裏面去了。

　　試用(yòng)版隻是提供給用(yòng)戶驗證 DNGuard 是否适合自己的(de)軟件(jiàn)項目以及系統發布環境，請不要用(yòng)試用(yòng)版 加密程序集後直接分(fēn)發。