如何用實(shí)例探討.NET強(qiáng)命稱(chēng)的思路

如何用實(shí)例探討.NET強(qiáng)命稱(chēng)的思路，相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策，為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法，通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。

手頭有一個(gè)行業(yè)軟件，是需要插上加密狗才能正常運(yùn)行的，C# / .Net Framework 1.1環(huán)境開(kāi)發(fā)的。這是我們公司購(gòu)買(mǎi)的正版軟件，所以是能正常使用的，但是由于電腦多，加密狗難免要拔來(lái)拔去的。閑來(lái)無(wú)事，就研究研究吧，也好多學(xué)些調(diào)試知識(shí)。

PEiD可以“鑒定”出該軟件是Microsoft Visual C# / Basic .NET，新手不要以為脫殼查殼才用到PEiD啊。

那就用Reflector分析吧，注意到不插加密狗會(huì)彈出個(gè)對(duì)話框提示“*****未注冊(cè)*****”的字樣，部分功能受限。按F3顯示搜索窗口，輸入“未注冊(cè)”，點(diǎn)其右側(cè)“String Seach”圖標(biāo)進(jìn)行字符串搜索。找到一項(xiàng)，是程序啟動(dòng)的一個(gè)模塊，雙擊來(lái)到左側(cè)樹(shù)狀列表，再雙擊打開(kāi)代碼，我選的C#格式。一般我是IL和C#兩種結(jié)合對(duì)照使用。鑒于諸多原因，代碼已經(jīng)精簡(jiǎn)并修改，特此說(shuō)明。下同。

GlobalVariant.zhuce = Check.Textxyz;   if (!GlobalVariant.zhuce)                  {    MessageBox.Show(this, "*****未注冊(cè)*****");                  }

一看，里面沒(méi)有一個(gè)漢字，用許多“\u7237\u7016”之類(lèi)的字串，這就是漢字的Unicode了。把模塊代碼復(fù)制出來(lái)，找個(gè)Unicode轉(zhuǎn)換工具轉(zhuǎn)一下，現(xiàn)在一目了然了，直接找到彈出“*****未注冊(cè)*****”的條件判斷，該判斷調(diào)用了some.dll中的一個(gè)過(guò)程Check.Textxyz，點(diǎn)擊過(guò)程名字跟蹤過(guò)去，點(diǎn)開(kāi)如下：

public static bool Textxyz  {        get       {              return ((Check() != 0) ? 1 : 0);        }  }

再點(diǎn)擊追查Check()函數(shù)，除了定義什么都沒(méi)有，已經(jīng)是傳說(shuō)中的Native Code了(本機(jī)代碼)。[后來(lái)反編譯才發(fā)現(xiàn)的。

[PreserveSig, MethodImpl(MethodImplOptions.Unmanaged, MethodCodeType=MethodCodeType.Native), SuppressUnmanagedCodeSecurity]  public static int modopt(CallConvCdecl) Check();

但是無(wú)所謂了，分析一下，只需修改上面那個(gè)Textxyz中的return ((Check() != 0) ? 1 : 0);    根據(jù)判斷返回1(true)或0(false)，應(yīng)該是檢測(cè)軟件狗的Native Code為：return ((Check() != 0) ? 1 : 1);    不管怎么樣都返回1(true)

嗯，方案確定，那就干吧。。。。

程序有5個(gè)DLL和2個(gè).EXE，其中一個(gè).EXE不是C# .Net程序(Assembly)，只需解決這5個(gè)DLL和1個(gè)EXE就完了。簡(jiǎn)單！

全部ildasm出來(lái)，將some.il的代碼根據(jù)上面改法做了修改，很簡(jiǎn)單，就是把那段里的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

全部去掉強(qiáng)名稱(chēng)，用ilasm編譯回去。。。。。。。

到some.il卡殼了，我郁悶，還以為勝利在望了呢。這才注意到some.dll使用了本機(jī)代碼(Native Code)。some.dll中還有許多.NET代碼的軟件功能。大家一致認(rèn)為，混合了本機(jī)代碼的Assembly是無(wú)法重新編譯的，因?yàn)闊o(wú)法反編譯（不信你試試)

唉，怎么辦，查資料，眼都看暈了，結(jié)果還是NO WAY。PS 看來(lái)使用本機(jī)代碼混編譯.Net是保護(hù).Net Assembly程序很強(qiáng)的方法。

只能16進(jìn)制編輯了，弄了一份some.dll，對(duì)照some.il找到特征字串，在編輯器中搜索到以后16(false)就改成了17(true)。這里some.il在用ildasm導(dǎo)出（即轉(zhuǎn)儲(chǔ)）時(shí)一定要把那幾個(gè)方框打上勾，這樣反編譯出來(lái)的代碼就有IL指令對(duì)應(yīng)的some.dll中的16進(jìn)制代碼。很方便去編輯器中搜索定位。

保存后打開(kāi)軟件，看看能不能運(yùn)行－－－彈出公共語(yǔ)言運(yùn)行庫(kù)錯(cuò)誤提示！運(yùn)行.Net Framework SDK 1.1 的DbgCLR進(jìn)行調(diào)試，查到是強(qiáng)名稱(chēng)認(rèn)證出了問(wèn)題！對(duì)有強(qiáng)名稱(chēng)的Assembly.Net程序，只要用16進(jìn)制編輯器修改了任何字節(jié)，都會(huì)導(dǎo)致強(qiáng)名稱(chēng)驗(yàn)證失敗而使程序無(wú)法運(yùn)行。(不知道修改header會(huì)不會(huì)也這樣，沒(méi)試)

解決強(qiáng)名稱(chēng)認(rèn)證問(wèn)題的常規(guī)方法就是重新編譯程序，可是剛才就試過(guò)了，不行！

反編譯帶本機(jī)代碼的Assembly？搜索和研究了好久沒(méi)找到解決方案。那么，能不能將全部DLL/EXE強(qiáng)行去掉強(qiáng)名稱(chēng)，試了一下不能運(yùn)行，而且也不可能加載到GAC中運(yùn)行。那么，怎么根據(jù)算法給some.dll“更新”成修改后的正確強(qiáng)名稱(chēng)？沒(méi)有答案。這一點(diǎn)我很感興趣，以后還會(huì)留意。

沒(méi)轍了，***一招：怎么欺騙Microsoft.Net讓它不去檢查強(qiáng)名稱(chēng)，或者讓它怎么看都是對(duì)的？網(wǎng)上找到寫(xiě)注冊(cè)表的方法，但我試了幾次都不行，懷疑是不是需要重新啟動(dòng)一下電腦？？沒(méi)再試。干脆，把.Net Framework 1.1的這個(gè)強(qiáng)名稱(chēng)機(jī)制破解了算了，我是沒(méi)看到它到底有什么用。

破解系統(tǒng)的強(qiáng)名稱(chēng)驗(yàn)證機(jī)制：

結(jié)合網(wǎng)上找到的資料，StrongName強(qiáng)名稱(chēng)相關(guān)的操作在.Net Framework運(yùn)行庫(kù)的文件mscorsn.dll里，具體位置，一般在系統(tǒng)目錄C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\下，自己找。涉及到的函數(shù)是StrongNameSignatureVerification和StrongNameSignatureVerificationFromImage。

于是復(fù)制了一份mscorsn.dll，用OD打開(kāi)，先點(diǎn)運(yùn)行讓它運(yùn)行一遍（管它運(yùn)行不運(yùn)行呢），然后點(diǎn)菜單中 調(diào)試 --> 調(diào)用DLL輸出，找到相關(guān)的函數(shù)并參照著找到函數(shù)入口點(diǎn)，修改一下讓它們直接返回一個(gè)True。修改保存，覆蓋掉系統(tǒng)原來(lái)的那個(gè)文件，注意先備份一下以防修改失敗或事后系統(tǒng)恢復(fù)。覆蓋時(shí)，要先覆蓋Windows/System32/dllcache/目錄下的那個(gè)，然后再覆蓋Windows/Microsoft.NET/下的目錄下的那個(gè)?，F(xiàn)在點(diǎn)擊已經(jīng)修改好的程序看看怎么樣了？

運(yùn)行成功！無(wú)異常。

同事說(shuō)我把這個(gè)軟件和.Net一塊給Crack了。只可惜要替換.Net Framework的系統(tǒng)文件mscorsn.dll才行，安全性是否下降尚不知道。這個(gè)系統(tǒng)文件的替換做法，在.Net Framework 2.0中應(yīng)該是一樣可以對(duì)付強(qiáng)名稱(chēng)的。

總結(jié)： （很重要）

1. 如果你都看到了這里，證明你很有耐心，也很謙虛，麻煩不要挖苦我:-），請(qǐng)多多指點(diǎn)

2. .Net程序(Assembly)的逆向研究難點(diǎn)就在Native Code混編，這個(gè)應(yīng)該是研究方向

3. 不可逆強(qiáng)名稱(chēng)程序的強(qiáng)名稱(chēng)驗(yàn)證能否從正面解決能否“更新”強(qiáng)命名是不是不可完成的任務(wù)？

4. 這一點(diǎn)很重要：本文提出了一個(gè)強(qiáng)名稱(chēng)驗(yàn)證+編譯本機(jī)代碼保護(hù)程序的一個(gè)Crack思路，只要找到需要修改的關(guān)鍵點(diǎn)，只要能用16進(jìn)制編輯器讓它突破限制，那么程序也是可以照常使用的。只不過(guò)再給系統(tǒng)打個(gè)免強(qiáng)名驗(yàn)證補(bǔ)丁而已。雖然是有所得有所失，但反過(guò)來(lái)想想，對(duì)軟件到了要Crack的地步的“強(qiáng)烈需求”，會(huì)在乎給系統(tǒng)打個(gè)并不是很令人討厭的補(bǔ)丁嗎?這個(gè)補(bǔ)丁怎么樣，還需要大家大面積的試驗(yàn)，實(shí)踐出真知。

可能有人會(huì)說(shuō)，你想的也太天真了，如果軟件的核心功能和驗(yàn)證都是NativeCode那你怎么辦？其實(shí)不用擔(dān)心，因?yàn)槟阏f(shuō)的程序已經(jīng)算不上.Net程序了。只是披上.Net外衣欺騙用戶(hù)而已。為什么要使用.Net開(kāi)發(fā)程序？答案很多，開(kāi)發(fā)快捷，功能強(qiáng)大易用(都是針對(duì)開(kāi)發(fā)人員)等等等等，所以呢。。。如果用.Net進(jìn)行開(kāi)發(fā)，肯定軟件的核心功能是靠.Net NonNative Code實(shí)現(xiàn)的，至于驗(yàn)證非法用戶(hù)的核心功能，就寫(xiě)道Native Code中，然后混編一下。然后，這樣的程序應(yīng)該還是很容易Crack的。沒(méi)有強(qiáng)名稱(chēng)驗(yàn)證，Native Code作用有限。

看完上述內(nèi)容，你們掌握如何用實(shí)例探討.NET強(qiáng)命稱(chēng)的思路的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！