.Net 加密原理，加密殼核心的相容性以及安全性討論(六)

前面我們介紹了目前主流的雙層加密殼核心實現原理，
同時提到了應對相容性，同時考慮安全性的前提下對加密殼核心進行簡化。
今回主要討論一下安全性、相容性需要注意哪些因素。

關於安全性，主要應對兩類破解者。
1、靜態分析脫殼
對於這一類，行之有效方法就是增加密碼編譯演算法的數量和複雜度。
加密殼核心的實現方式對其影響可忽略。

2、動態架構核心層攔截
對於這一類有兩種防範，一是針對架構核心層進行檢測，對Hook進行反制。
二是構造合理的加密殼核心模式，將核心資料局限在加密殼運行庫範圍內，
使破解者在加密殼運行庫範圍外攔截不到全部所需的資訊。

關於相容性，主要有兩類
1、對未知架構環境的相容
因為不同架構核心中各個函數的物理地址可能不一樣，這就是相容的最大麻煩，
所以儘可能少的hook架構核心函數能增加對未知架構的相容性。

2、和其它加密殼並存的相容性問題
這種情況比較少見，但也是不容忽視的。

如：某.Net中介軟體廠商使用A加密了其產品，另一家軟體公司使用了該中介軟體，而這家公司又要使用B加密自己的產品。
這時就出現了一個軟體環境中出現兩種加密殼核心的情況。
不過這種情況基本上可以不用太多顧慮，一般這兩家公司之間可以協調解決。

但是另外一種情況就比較難辦了：
Web應用在虛擬機器主機上的問題，如果在同一虛擬機器主機上部署兩種不同加密殼加密的web應用，也同樣要面臨這個問題。

怎麼處理這個問題？
在安全性方面對架構進行檢測，反制攔截破解者，這樣將對第2個相容性產生問題。

所以理想的方案是使用第二種構造合理加密殼核心來加強安全性，這樣不會對相容性造成負面影響。
當然，如果你決定不考慮和其它加密殼的相容性問題也就不用理會這個問題了。

撇開相容性的第二條，我們來看看第一條。
麻煩的根源是函數地址的未知性，尤其是對於mscorwks.dll中的函數地址，沒有任何參考點。
唯一的相容方法就是模糊搜尋，所以盡量減少對mscorwks.dll中的hook能在一定曾度上提高相容性。

mscorjit.dll中的函數比較容易準確確定，因為它又一個入口函數地址可以直接擷取到，
然後順藤摸瓜就能把下級函數地址擷取到，當然這需要一個小型的反組譯碼引擎。搜尋1到3層基本上是沒啥問題的了。

結論：mscorwks.dll是雙層加密殼相容性的瓶頸所在。

前面提到對架構進行檢測，會影響相容性，其實，這種方法對安全性的提高並沒有多大的實質性協助。
主要原因，加密殼要考慮相容性（相容未知架構）以及程式效率，所以不可能對架構進行全面檢測，檢測範圍有限，同時因為hook方式的多樣性，檢測成功率也比較低。
對付一些初級使用者也許能收到一點效果。

那麼怎麼辦呢？
下回我們將介紹加密殼核心相容性和安全性共贏的實現模式，純Jit層核心的實現。