.Net加密殼認識的一個誤區

自從.Net 2.0的新特性被公開用來擷取IL代碼後，加密殼就成了雞肋。
就如tankaiha所說“.net下逆向暫時沒啥新東西可搞，某軟體的版本升級是一次不如一次強”，由於先天不足，這成了加密殼強度的一個瓶頸。

但是還有相當一部分人認為1.1的程式集加密後是安全的。
其實不然，絕大部分1.1的程式集加密後也能用發射的方式進行脫殼。
（註：這裡的脫殼僅指加密保護殼，混淆是無法還原的，如某軟體現在同時提供了加密和混淆功能，脫殼僅能脫除加密保護部分）

.Net 1.1沒有 2.0中有的新特性，怎麼能用反射脫殼呢？原因很簡單，因為大部分1.1的程式集能在 2.0的架構中運行。
如加密的 dll，我們可以用2.0寫一個程式集來load它。我們就有了2.0的運行環境了。
那加密的 exe 呢，也好對付，微軟允許使用者通過修改程式配置來強制指定一個程式啟動並執行 .net framework版本。
假設 a.exe 是被加密的1.1程式集。
我們只要建一個檔案 a.exe.config 和它放在一起，檔案內容如下：

<configuration>
 <startup>
 <supportedRuntime version="v2.0.50727"/>
 <requiredRuntime version="v2.0.50727" safemode="false"/>
</startup>
</configuration>

這樣你再次運行a.exe時，系統就會自動啟用 .Net 2.0 framework 作為運行環境。

如果說只能一個一個函數的擷取IL代碼，那麼加密保護還有一定的利用價值。
然而反射脫殼已經有了成品離線了，這就使加密保護徹底成了雞肋。

對於反射，加密殼還是有一定作為空白間的，但是作用很有限，治標不治本。
那就是破壞反射，讓反射無法正常工作。
即通過破壞反射正常啟動並執行系統地層代碼或代碼路徑達到破壞反射的目的。
只要修複反射，就可以繼續使用離線脫殼。

這就將戰場轉移到了傳統的Win32層面。
然而受限於.Net核心架構，破壞總是有限的，熟悉一點彙編，瞭解一些.Net底層機制，要修複是很比較容易的事情。

當然要修複總得需要先找一個sample來分析才行，如果沒有sample神仙也沒有辦法。
這就有了某殼新版不再發布試用版本的事情出現。
這對於安全有那麼一點點作用，即不至於新版一發布別人就找到的patch修複的辦法。
但是只要有一個加密保護的程式發布，那就有了可分析的sample了，結果可想而知了。

單純的加密殼強度已經得不到保障了，當然多一層保護總是好的。在眾多的保護方式裡，加密反而成了最脆弱的環節。