遭遇未知.Net加密殼

今天晚上朋友找我，說他用的OA系統(ASP.Net的)今天更新了，註冊演算法好像變了，好像加密殼也換了，找我幫他看看。
是DLL的程式而且是net2.0的，感覺應該很好弄。資源管理員中用大表徵圖視圖模式看了一下所有的dll檔案的版本資訊沒有發現可疑檔案。先拿ildasm看看結構，分析一下有什麼保護方式。結果出來一個 紅叉的對話方塊，說什麼是受保護的模組。
用reflector不能看是預料之中的，這個工具太脆弱了。用9ray的能看到部分。
不過這些工具都太弱，還是Dis＃比較強悍，就用它了，開啟一幕瞭然，看得清清楚楚。
有名稱混淆，名字都被混淆成了類似這樣 "o10l1o0l" 的名稱。還沒有見過什麼混淆器有這樣的名稱混淆特徵。
除了部分方法能看到代碼，大部分方法都看不到代碼，應該是有加密殼。
發現有pinvoke調用。汗，調用的是一個資料庫訪問層的dll（從dll的檔案名稱來看），實際分析一下這個檔案，發現原來是一個native的dll。隱藏得這麼深，看來這個檔案有陷阱。
看了一下匯出表，你面有幾個函數是在maxtocode的運行庫中看到過的。但這個庫匯出的函數比以前看到的maxtocode運行庫匯出函數多了很多，而且運行庫的大小明顯要大很多。

先不管它是什麼殼，姑且用反射方式脫試試，結果顯然不行，這個殼 anti 反射了。
我懷疑這個是不是最新版的maxtocode，上它網站下了一份說明文檔，看看更新記錄。
* 增加了對ILdasm以及使用API 訪問來源資料的反編譯工具的反制功能
（後來發現它實際上只是anti了 ildasm 2.0，嚴格的說只對ms官方的有效）
* 經測試,目前沒有一種反編譯工具可以完整的讀取加密後的結構,更不用說加密後的代碼了
(看說明文檔介紹了ildasm,reflector,spices 無法讀取，似乎沒有介紹其它工具，尤其是Dis＃。這三個不能 就算 沒有一種 :P)

先就按maxtocode來治，試試用maxtocode 3.16的方式反射，似乎有一點效果，能得到一些方法屬性，但還是沒有IL代碼。
看說明文檔，裡面提到 maxtocode 3.2企業版用了多核分段保護，會不會是在jit層中也有掛接服務呢？先掃了一面jit領域，沒有發現異常。

那就應該是在mscorwks.dll領域了。
我在想它會不會是用的我在前一篇文章 "mscorwks.dll在.Net中的地位以及在.Net代碼保護方面的應用" 中提到的 第三種方式或者類似方式？雖然那個方案已經被我否定掉了，這個殼也許就是這樣的。
掃了一下A區，和B區，果然在這兩個區都發現了異常。看起來反射的路是不太好走了。

直接拿jit層脫殼的方式試試，OK，可以正確擷取到方法體代碼。
因為是脫dll，所以可以先把jithook安裝好後再載入加密的程式集，不會有方法從jit中漏掉，如果是exe可能需要hook全域的loadlibrary之類的函數，在mscorjit.dll載入時完成jithook。另外hook的位置也需要注意可靈活多變，防止殼有反hook機制。

進到Jit層裡面方法的內容已經被轉換成了幾個類結構，好在在sscli中可以找到它們的定義，這就使方法體的重建簡單很多了。
一直在做hvm，都是jit層的東西，所以對這部分非常熟悉。重建就只是sehtable稍麻煩一點。

朋友只需要幾個關鍵函數的代碼，這工作量就少很多了。上看雪下了一個修改版的 ildasm，因為ms官方版的被anti了。
開啟程式集，查到所需方法的token值，記下來。通過反射找到方法並invoke，讓它經過jit，jithook(根據token過慮)把擷取的方法體dump出來。為了省事，首先拿反射脫殼dump一個空殼程式集下來。再手動把jithook取到的方法體填充回去（現在還沒做自動回填的工具）。
如果要做成自動離線，得在jithook裡面把所有方法體按模組合計存起來，然後做個自動回填的工具填到程式集中。

看這個殼的特徵很像maxtocode新版所描敘的，從運行庫的匯出表來看原始模組名稱是 attick.dll，好像就是maxtocode運行庫原始名稱。而且匯出函數包含了以往maxtocode運行庫的匯出函數，多出了Getcpuid,getdiskid,getmacid等函數。
另外在裡面也看到了一些和DNGuard v1.0相似的結構混亂以及靜態建構函式的處理方式。
中繼資料頭也是和DNGuard v1.0處理後的相似，估計也用了framework api來處理。
這種方式能使加密速度提升很多。冒似maxtocode 3.16的更新記錄也有說大幅提供加密速度。

雖然很像，暫且還是稱之為未知殼吧。