其他

.Net 2.0開始提供了兩個混淆相關的屬性，ObfuscationAttribute 和 ObfuscateAssemblyAttribute

前面討論了 .Net 保護中的 native compile 方式 。提到了 native compile的兩種方式 偽編譯 和 ngen 編譯。仍然沒有像C++那樣的完全native的編譯。這裡要討論的就是 ngen編譯 產生的  ni 檔案。前面討論時我們提到了fetion架構中的 fetionvm.srm檔案。注意到它是使用了ngen編譯保護模式。Remotesoft在評論中予以了證實，今回就以

目前加密殼將核心轉移到Jit層後，核心模式的強度增加空間已經很小了。目前市面上的加密殼至少有一個共同的缺陷，無法防止Jit底層截獲IL位元組碼。有些殼採用從周邊增加強度（如 Anti Hook），由於hook的多樣性再加上殼又需要考慮自己的相容性，所以這個效果不是十分理想。從防止脫殼入手，通過保護局部變數簽名和異常處理表，來阻止方法體的脫殼還原。這樣雖然不能阻止截獲IL位元組碼，如果配合流程混淆還是能起到相對有效保護。這樣仍然有些遺憾，能實現阻止Jit層截獲完整的IL位元組碼就完美了。http:

本次脫殼的測試對象是CodeLib 2 V14.9.2468.42911 更新日期是2006-10-5 目前的最新版本。運行離線程式到如下介面：選中列表中的第二項，codelib.exe，選擇一個儲存路徑，點擊dump按鈕，即可完成脫殼。脫殼完的程式儲存到codedump.exe。注意這個檔案是直接dump脫殼的結果，不能直接運行。使用ildasm 反編譯，然後開啟il檔案尋找 IL_0000:  call       void InFaceMaxtoCode::Startup()替換為

首先感謝 Dudu 提供這麼好的學習交流平台，部落格園的確是非常榜的地方。關於 Jason.NET 的質問，我有幾點想說明關於我blog裡面的迴文，Jason.Net

程式採用的 VS2003 c++/mfc 編寫。使用了frame work 2.0 的api。這個是從DNGuard HVM的手動名稱混淆功能中剝離出來的副產品。可以用來協助手動 進行名稱 混淆/反混淆 。名稱混淆不是完全無法復原的，就目前的混淆工具來說，還有部分是可逆的。介面：查看次數: 92檔案大小: 69.4 KB" style="MARGIN: 2px; CURSOR: pointer"

忙了很長時間了，緩了一口氣，還要接著忙一兩個月。發兩張圖片玩玩。。。DNGuard v2.0 正式版1、檔案說明：/DNGuardCmd.exe    DNGuard命令列版本/DotNetGuard.exe    DNGuard圖形介面版本/DNGRuntime.dll    DNGuard運行庫檔案。2、命令列使用說明：Usage: DNGuardCmd [Options] <inputfile> <outputfile> [Options]Options:/EC 

運行庫相容性更新：調整了運行庫，修正了一處判斷DynamicMethod錯誤的bug。：http://www.redcheek.net/bbs/read.php?tid=5051重新下載壓縮包即可。介紹：.Net 核心級的加密保護工具。採用的是純虛擬機器處理層的核心。相容目前所有的32位 .Net 架構版本，Net 1.1, 2.0, 3.0, 3.5 以及其所有子版本（如beta x，CTP，RC，sp x等）。支援泛型方法的加密。加密保護過程不依賴 ildasm 和 ilasm 。支援 C+

看看下面的代碼:     sbyte sba, sbb,sbv;            sba = 1;            sbb = 2;            sbv = sba + sbb;            byte ba, bb, bv;            ba = 1;            bb = 2;            bv = ba + bb;            short sa, sb, sv;            sa = 1;           

DNGuard 新版核心架構基本定下來了。目前版本定為 beta1。綜合考慮，採用了相容所有 dotNet framework 版本的核心模式，Net 1.0, 1.1, 2.0, 3.0, 3.5 以及其所有子版本（如beta x，CTP，RC，sp

之前發了一個實驗品http://bbs.pediy.com/showthread.php?t=45184功能還不完善，這個是完整的版本。能脫壓縮殼，整體加密殼，有反射漏洞的加密殼。方法：採用的是注入方式，注入到目標進程。注入後會看到一個列表介面。在這個列表裡面會顯示出當前進程中的所有程式集。首先在列表裡面選擇一個要脫殼的程式集。然後選擇儲存路徑。（注1）在就脫殼。程式使用的是 VS2005 C++/CLI 需要相關運行庫 mfc80u.dll msvcr80.dll msvcm80.dll...

在 per method

v1.85+支援nested class的全名解析v1.8+支援 欄位，和方法的簽名解析。解碼效果如下基本上和

學習過了名稱混淆，最近又看了一些字串加密方面的東西。在混淆保護和加密殼中都有字串加密保護功能。總體上字串加密可以分為兩類，第一類是混淆保護中的字串加密技術。主要特徵是修改代碼執行路徑。大部分混淆保護工具的字串加密都是這一類。第二類就是加密殼中的字串加密技術。這種不用修改IL代碼，直接對中繼資料中的字串加密。這一類以remotesoft,maxtocode為代表。先看第一類，加密實現大致如下。加密前：MessageBox.Show("Hellow

在 net 2.0 中 ngen 能產生 native code 的 image，但是它同時會保留原始程式集的 MetaData 和ILCode 。這就是還原的關鍵。同樣的，知道了還原方法後加強保護也很容易實現。ni 檔案中的中繼資料和普通中繼資料相比多包含了一個 NativeHeader。在 NativeHeader 中第12個入口是 OrgMetaData的 RVA和Size，第13個入口是 OrgILcode的 RVA

前面介紹了 “讓 .Net 程式 脫離 .net framework架構 啟動並執行方法”，該方法主要是利用了Fetion的架構來實現的，今天我們要介紹的是不使用Fetion的架構，自己來實現Fetion架構的相關功能，並給出相關實現代碼。關於Fetion架構它主要是有兩個檔案，FetionVM.exe和FetionVM.rsm。其中對於第二個檔案，我們在介紹 native compile 保護的dotNet本地程式還原成dotNet IL程式集 時已經給出了其實現的原始碼。今回就給出

首先，我在此申明，此文並不是教別人突破限制，我們只是用學習的眼光看問題 大家都知道ILDasm是。NET程式的反編譯工具，它是由Microsoft提供的反編譯工具。 它可以直接把。NET程式反編譯為IL檔案及資源檔，這樣即可以非常容易的讓駭客進行修改，刪除強命名，修改註冊碼演算法等等。。。並且Ilasm再次編譯,得到一個正確的,可發布的程式集並且，這個功能是其它反編譯器所不能替代的功能，因為ILDasm真的太重要了。也許有的朋友能理解，有的朋友不能理解，但沒關係，我們今天的重點並不是這個。

正如前面提到的DotNet 程式的脫殼和普通PE檔案的脫殼是有密切關係的。傳統PE檔案dump大部分都是進程外dump，這裡我們介紹的DotNet程式集的脫殼使用進程內dump。所以第一步就是注入問題，如何讓我們的程式在目標進程內運行？傳統的win32 注入dll，相信大家都熟悉了吧，得益於C++/CLI的特性，我們能依靠傳統的方式注入我們的程式到目標進程中。用VS2005建立一個mfc dll，然後在工程屬性裡面開啟 clr支援，這樣在這個dll就能使用 CLR

應使用者的要求，增加了反制靜態編譯工具查看程式集完整結構的功能。當然首當其衝的就是Reflector了。個人認為，加密最主要的就是加密方法代碼，結構啥的並不是重點，如果是做中介軟體、類庫啥的，結構還非得給使用者看不可。試用版開放了 常規模式的 使用者字串加密 功能。標準版將會提供名稱自動混淆功能。具體詳情可參考軟體介面中的即時提示資訊。程式中灰色停用選項是標準版或者專業版才提供的功能。標準版將在這個周末正式發布。注意：RC1和RC2的運行庫可以通用， RC3 以及 Release

提到 .Net 的保護，首推就是混淆保護了，而名稱混淆基本上是所有混淆保護工具都具有的功能。可以說不支援名稱混淆的工具稱不上混淆保護工具。對於混淆保護，大家有一個認識，就是 混淆是一個無法復原的過程。而加密保護是一個可逆的過程。名稱混淆真的完全無法復原嗎？答案是否定的。名稱混淆有一部分是可以精確還原的。.Net的名稱混淆在 剖析DotNet的名稱混淆保護技術 中有詳細介紹。今回注意介紹名稱混淆中可逆的部分，以及還原的方法。一. 屬性名稱 以及 getter 和 setter