目前大部分加密殼都直接利用了dotNet的元數據來保存這種對應關系,我們知道在元數據中每個方法都會對應一個RVA值,加密殼可以直接把這個關系記錄在RVA的地址處。在框架運行中RVA處的數據會被作為“方法體”在處理流程中直接傳遞,加密殼通過攔截框架處理流程中的函數,來對“方法體”進行分流處理。即先判斷RVA處的數據是否“方法體加密對應信息”,如果是進入加密殼運行庫的內部處理,不是則按原框架流程處理。
對于這個“方法體加密對應信息”,最簡單的方式是指記錄一個指針信息,指向另一處數據塊,四字節空間就夠了。但是為了和普通沒有加密的方法體進行區分,除了這個之外還需要增加一些唯一標識以便能被運行庫在運行時安全無誤的區分出來。
大家可以用UE打開,加密后的程序集,看看一個方法體RVA處的數據,應該能很容易分別出來哪些是記錄的“方法體加密對應信息”。
正是這個原因,所以DNGuard v1.0和同類處理方式的加密殼,對方法體小于某個指定字節數的,就不能進行加密。
因為“方法體加密對應信息”的大小超過的方法體的空間大小,寫入的話會覆蓋到后面方法體的信息。這實際上也是因為偷懶造成的??梢酝ㄟ^對方法體進行重排來解決這個問題,當然要麻煩很多了。
這種模式實際上就是在元數據保存了一個虛擬表實現了 MethodToken => “方法體加密對應信息” 的對應記錄。這個表可以看著是公開的。
原文轉自:http://www.anti-gravitydesign.com