在 per method 的dotNet加密中首要解決的方法體對應關系即在運行時加密殼如何確定當前要解密的方法體所對應的加密信息
目前大部分加密殼都直接利用了dotNet的元數據來保存這種對應關系我們知道在元數據中每個方法都會對應一個RVA值加密殼可以直接把這個關系記錄在RVA的地址處在框架運行中RVA處的數據會被作為方法體在處理流程中直接傳遞加密殼通過攔截框架處理流程中的函數來對方法體進行分流處理即先判斷RVA處的數據是否方法體加密對應信息如果是進入加密殼運行庫的內部處理不是則按原框架流程處理
對於這個方法體加密對應信息最簡單的方式是指記錄一個指針信息指向另一處數據塊四字節空間就夠了但是為了和普通沒有加密的方法體進行區分除了這個之外還需要增加一些唯一標識以便能被運行庫在運行時安全無誤的區分出來
大家可以用UE打開加密後的程序集看看一個方法體RVA處的數據應該能很容易分別出來哪些是記錄的方法體加密對應信息
正是這個原因所以DNGuard v和同類處理方式的加密殼對方法體小於某個指定字節數的就不能進行加密
因為方法體加密對應信息的大小超過的方法體的空間大小寫入的話會覆蓋到後面方法體的信息這實際上也是因為偷懶造成的可以通過對方法體進行重排來解決這個問題當然要麻煩很多了
這種模式實際上就是在元數據保存了一個虛擬表實現了 MethodToken => 方法體加密對應信息 的對應記錄這個表可以看著是公開的
在DNGuard 中我沒有選擇使用對方法體重排的方式來解決這個問題而是選擇了另一個方法自己記錄一個 虛擬表實現MethodToken => 方法體加密對應信息 的對應記錄
因為這樣有一個好處就是 這個虛擬表也可以進行加密後保存另外就是方法體加密對應信息中不需要添加標識符 和普通沒有加密的方法體進行區分
在 DNGuard 試用版 中沒有使用真正的加密算法來對程序集加密只是采用了代碼直接挪位的方式運行庫的解密操作只是從另一個位置直接讀取的操作
有個朋友分析到DNGuard 試用版裡面有一個虛擬表記錄了MethodRid => ILCode這個就是 虛擬表MethodToken => 方法體加密對應信息 在 試用版中退化的模式
另外因為方法體只是挪位所以它實際上還是在程序集文件內加載到內存中後也在程序集模塊的內存空間中而不是那位朋友說的 運行庫在解密後將 IL代碼 填回到內存裡面去了
試用版只是提供給用戶驗證 DNGuard 是否適合自己的軟件項目以及系統發布環境請不要用試用版 加密程序集後直接分發
From:http://tw.wingwit.com/Article/program/net/201311/15207.html
