實例探討.NET強命稱的思路
手頭有一個行業軟件，是需要插上加密狗才能正常運行的，C# / .Net Framework 1.1環境開發的。這是我們公司購買的正版軟件，所以是能正常使用的，但是由于電腦多，加密狗難免要拔來拔去的。閑來無事，就研究研究吧，也好多學些調試知識。
PEiD可以“鑒定”出該軟件是Microsoft Visual C# / Basic .NET，新手不要以為脫殼查殼才用到PEiD啊。
那就用Reflector分析吧，注意到不插加密狗會彈出個對話框提示“*****未注冊*****”的字樣，部分功能受限。按F3顯示搜索窗口，輸入“未注冊”，點其右側“String Seach”圖標進行字符串搜索。找到一項，是程序啟動的一個模塊，雙擊來到左側樹狀列表，再雙擊打開代碼，我選的C#格式。一般我是IL和C#兩種結合對照使用。鑒于諸多原因，代碼已經精簡并修改，特此說明。下同。
- GlobalVariant.zhuce = Check.Textxyz;
- if (!GlobalVariant.zhuce)
- {
- MessageBox.Show(this, "*****未注冊*****");
- }
一看，里面沒有一個漢字，用許多“\u7237\u7016”之類的字串，這就是漢字的Unicode了。把模塊代碼復制出來，找個Unicode轉換工具轉一下，現在一目了然了，直接找到彈出“*****未注冊*****”的條件判斷，該判斷調用了some.dll中的一個過程Check.Textxyz，點擊過程名字跟蹤過去，點開如下：
- public static bool Textxyz
- {
- get
- {
- return ((Check() != 0) ? 1 : 0);
- }
- }
再點擊追查Check()函數，除了定義什么都沒有，已經是傳說中的Native Code了(本機代碼)。[后來反編譯才發現的。
- [PreserveSig, MethodImpl(MethodImplOptions.Unmanaged, MethodCodeType=MethodCodeType.Native), SuppressUnmanagedCodeSecurity]
- public static int modopt(CallConvCdecl) Check();
但是無所謂了，分析一下，只需修改上面那個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 Framework 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:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\下，自己找。涉及到的函數是StrongNameSignatureVerification和StrongNameSignatureVerificationFromImage。
于是復制了一份mscorsn.dll，用OD打開，先點運行讓它運行一遍（管它運行不運行呢），然后點菜單中 調試 --> 調用DLL輸出，找到相關的函數并參照著找到函數入口點，修改一下讓它們直接返回一個True。修改保存，覆蓋掉系統原來的那個文件，注意先備份一下以防修改失敗或事后系統恢復。覆蓋時，要先覆蓋Windows/System32/dllcache/目錄下的那個，然后再覆蓋Windows/Microsoft.NET/下的目錄下的那個?，F在點擊已經修改好的程序看看怎么樣了？
運行成功！無異常。
同事說我把這個軟件和.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作用有限。
原文鏈接：http://www.cnblogs.com/lsjwq/archive/2011/03/15/1985484.html
【編輯推薦】
