那就用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/下的目錄下的那個。現在點擊已經修改好的程序看看怎麽樣了？
    運行成功！無異常。
    同事說我把這個軟件和。Net壹塊給Crack了。只可惜要替換。Net Framework的系統文件mscorsn.dll才行，安全性是否下降尚不知道。這個系統文件的替換做法，在。Net Framework 2.0中應該是壹樣可以對付強名稱的。
    最後總結： （很重要）
    1. 如果妳都看到了這裏，證明妳很有耐心，也很謙虛，麻煩不要挖苦我：-），請多多指點
    2. .Net程序（Assembly）的逆向研究難點就在Native Code混編，這個應該是研究方向
    3. 不可逆強名稱程序的強名稱驗證能否從正面解決能否“更新”強命名是不是不可完成的任務？
    4. 這壹點很重要：本文提出了壹個強名稱驗證+編譯本機代碼保護程序的壹個Crack思路，只要找到需要修改的關鍵點，只要能用16進制編輯器讓它突破限制，那麽程序也是可以照常使用的。只不過再給系統打個免強名驗證補丁而已。雖然是有所得有所失，但反過來想想，對軟件到了要Crack的地步的“強烈需求”，會在乎給系統打個並不是很令人討厭的補丁嗎？這個補丁怎麽樣，還需要大家大面積的試驗，實踐出真知。