驗證.N“.NET研究”ET強命稱的思路和例項

　　手頭有一個行業軟體，是需要插上加密狗才能正常執行的，C# / .Net Framework 1.1環境開發的。這是我們公司購買的正版軟體，所以是能正常使用的，但是由於電腦多，加密狗難免要拔來拔去的。閒來無事，就研究研究吧，也好多學些除錯知識。PEiD可以“鑑定”出該軟體是Microsoft Visual C# / Basic .NET，新手不要以為脫殼查殼才用到PEiD啊。

　　那就用Reflector分析吧，注意到不插加密狗會彈出個對話方塊提示“*****未註冊*****”的字樣，部分功能受限。按F3顯示搜尋視窗，輸入“未註冊”，點其右側“String Seach”圖示進行字串搜尋。找到一項，是程式啟動的一個模組，雙擊來到左側樹狀列表，再雙擊開啟程式碼，我選的C#格式。一般我是IL和C#兩種結合對照使用。鑑於諸多原因，程式碼已經精簡併修改，特此說明。下同。

一看，裡面沒有一個漢字，用許多“u7237u7016”之類的字串，這就是漢字的Unicode了。把模組程式碼複製出來，找個Unicode轉換工具轉一下，現在一目瞭然了，直接找到彈出“*****未註冊*****”的條件判斷，該判斷呼叫了some.dll中的一個過程Check.Textxyz，點選過程名字跟蹤過去，點開如下：

　　再點選追查Check()函式，除了定義什麼都沒有，已經是傳說中的Native Code了(本機程式碼)。[後來反編譯才發現的]

　　但是無所謂了，分析一下，只需修改上面那個Textxyz中的return ((Check() != 0) ? 1 : 0); 根據判斷返回1(true)或0(false)，應該是檢測軟體狗的Native Code為：return ((Check() != 0) ? 1 : 1); 不管怎麼樣都返回1(true)嗯，方案確定，那就幹吧。

　　程式有5個DLL和2個.EXE，其中一個.EXE不是C# .Net程式(Assembly)，只需解決這5個DLL和1個EXE就完了。簡單！全部ildasm出來，將some.il的程式碼根據上面改法做了修改，很簡單，就是把那段裡的ldc.i4.0改為ldc.i4.1 L_0009: ldc.i4.0 /這裡改成ldc.i4.1 L_000a: br.s L_000d L_000c: ldc.i4.1 L_000d: ret全部去掉強名稱，用ilasm編譯回去。到some.il卡殼了，我#@#@$!%$#&^$%* 還以為勝利在望了呢。這才注意到some.dll使用了本機程式碼(Native Code)。

　　some.dll中還有許多.Net程式碼的軟體功能。大家一致認為，混合了本機程式碼的Assembly是無法重新編譯的，因為無法反編譯（不信你試試;)~）唉，怎麼辦，查資料，眼都看暈了，結果還是NO WAY。PS 看來使用本機程式碼混編譯.Net是保護.Net Assembly程式很強的方法。只能16進位制編輯了，弄了一份some.dll，對照some.il找到特徵字串，在編輯器中搜尋到以後16(false)就改成了17(true)。

　　這裡some.il在用ildasm匯出（即轉儲）時一定要把那幾個方框打上勾，這樣反編譯出來的程式碼就有IL指令對應的some.dll中的16進位制程式碼。很方便去編輯器中搜尋定位。儲存後開啟軟體，看看能不能執行－－－彈出公共語言執行庫錯誤提示！執行.Net Framewor上海網站建設k SDK 1.1 的DbgCLR進行除錯，查到是強名稱認證出了問題！對有強上海閔行企業網站設計與製作名稱的Assembly.Net程式，只要用16進位制編輯器修改了任何位元組，都會導致強名稱驗證失敗而使程式無法執行。(不知道修改header會不會也這樣，沒試)解決強名稱認證問題的常規方法就是重新編譯程式，可是剛才就試過了，不行！反編譯帶本機程式碼的Assembly？搜尋和研究了好久沒找到解決方案。那麼，能上海徐匯企業網站設計與製作不能將全部DLL/EXE強行去掉強名稱，試了一下不能執行，而且也不可能載入到GAC中執行。

　　那麼，怎麼根據演算法給some.dll“更新”成修改後的正確強名稱？沒有答案。這一點我很感興趣，以後還會留意。沒轍了，最後一招：怎麼欺騙Microsoft.Net讓它不去檢查強名稱，或者讓它怎麼看都是對的？網上找到寫登錄檔的方法，但我試了幾次都不行，懷疑是不是需要重新啟動一下電腦？沒再試。

　　乾脆，把.Net Framework 1.1的這個強名稱機制破解了算了，我是沒看到它到底有什麼用。破解系統的強名稱驗證機制：結合網上找到的資料，StrongName強名稱相關的操作在.Net Framework執行庫的檔案mscorsn.dll裡，具體位置，一般在系統目錄C:WINDOWSMicrosoft.NETFrameworkv1.1.4322下，自己找。涉及到的函式是StrongNameSignatureVerification和StrongNameSignatureVerificationFromImage。

　　於是複製了一份mscorsn.dll，用OD開啟，先點執行讓它執行一遍（管它執行不執行呢），然後點選單中 除錯 –> 呼叫DLL輸出，找到相關的函式並參照著找到函式入口點，修改一下讓它們直接返回一個True。修改儲存，覆蓋掉系統原來的那個檔案，注意先上海徐匯企業網站製作備份一下以防修改失敗或事後系統恢復。覆蓋時，要先覆蓋Windows/System32/dllcache/目錄下的那個，然後再覆蓋Windows/Microsoft.NET/下的目錄下的那個。

　　現在點選已經修改好的程式看看怎麼樣了？執行成功！無異常。同事說我把這個軟體和.Net一塊給Crack了。只可惜要替換.Net Framework的系統檔案mscorsn.dll才行，安全性是否下降尚不知道。這個系統檔案的替換做法，在.Net Framework 2.0中應該是一樣可以對付強名稱的。

　　最後總結：

　　1. 如果你都看到了這裡，證明你很有耐心，也很謙虛，麻煩不要挖苦我:-），請多多指點

　　2. .Net程式(Assembly)的逆向研究難點就在Native Code混編，這個應該是研究方向

　　3. 不可逆強名稱程式的強名稱驗證能否從正面解決能否“更新”強命名是不是不可完成的任務？

　　4. 這一點很重要：本文提出了一個強名稱驗證+編譯本機程式碼保護程式的一個Crack思路，只要找到需要修改的關鍵點，只要能用16進位制編輯器讓它突破限制，那麼程式也是可以照常使用 的。只不過再給系統打個免強名驗證補丁而已。雖然是有所得有所失，但反過來想想，對軟體到了 要Crack的地步的“強烈需求”，會在乎給系統打個並不是很令人討厭的補丁嗎?這個補丁怎 麼樣，還需要大家大面積的試驗，實踐出真知。

　　可能有人會說，你想的也太天真了，如果軟體的核心功能和驗證都是NativeCode那你怎麼辦？ 其實不用擔心，因為你說的程式已經算不上.Net程式了。只是披上.Net外衣欺騙使用者而已。 為什麼要使用.Net開發程式？答案很多，開發快捷，功能強大易用(上海閔行企業網站製作都是針對開發人員)等等 等等，所以呢，如果用.Net進行開發，肯定軟體的核心功能是靠.Net NonNative Code實現的， 至於驗證非法使用者的核心功能，就寫道Native Code中，然後混編一下。然後，這樣的程式 應該還是很容易Crack的。沒有強名稱驗證，Native Code作用有限。