⑴ 如何解決.NET程序容易被反編譯的問題
阻止不了,任何一個程序都可以被反編譯 當然了,並不是說反編譯以後就是源代碼 不知道你用的什麼語言,在.net里,一般都是用Dotfuscator之類的工具進行混淆干擾
.NET有一種加密位元組碼的方式是通過hook住JIT編譯器的入口來做的:位元組碼經過加密/混淆存在文件里,等被CLR載入了,某個方法要執行而需要被JIT編譯時,hook住JIT編譯器的入口攔截住這個編譯請求,然後去把對應的位元組碼解密之後再傳給JIT編譯器。
這種做法基本上只能唬唬小朋友,知道了原理之後很好解,可以輕松的獲取解密後的位元組碼然後扔給常規的反編譯器去處理。但現實的說,大部分用戶在「試圖解密」方面都是小朋友,所以倒也算是一種可行方案。
⑵ 如何利用ILSPY反編譯工具重建C#NETWeb源碼解決方案
無論是VB.NET還是C#.NET語言開發的APS.NETWEB程序,發布在IIS的虛擬目錄下時,基本上會是三種文件類型(以C#為例):
1,aspx 頁面文件
2,.aspx.cs 頁面文件對應的代碼文件
3,Bin或Assembly 目錄下的.DLL類庫文件。
出於代碼的保密性或代碼源碼的管理需要,項目團隊開發時,會經常性的將一部分與資料庫打交道的代碼封裝到中間層,即.DLL層進行統一管理維護,這一部分.DLL是以文件的形式供調用,不象.aspx.cs文件可以直接用記事本打開進行查看源碼,給我們重新建解方案帶來了一定的困難。但只要能通過ILSPY對這部分.DLL代碼進行反編譯的話,可以很方便,也是很快的重新你的完整解決方案。(此方法也同樣適用於.NET開發的.exe文件)下面是是一些具體的反編譯與重建解決方案的步驟:
1,搜索並下載.NET 反編譯工具IL SPY 。
2,下載後,打開IL SPY的執行文件ILSpy.exe
接下來,需要的就是按步就搬的建立你的.sln方案,在.NET開發環境下添加反編譯出來的.csproj項目,並將原來web發布目錄下的文件加入解決方案中
6,重新解決方案的時間由系統的大小及對.NET開發環境的精通程度決定,一般該引用的引用,該反編譯的反編譯.
⑶ 請問怎樣將.Net程序反編譯為一個VS工程,可以正常運行調試
vs編寫程序是以項目為單位的(對小程序很不適合)。第一步是建里一個項目第二部是添加源代碼文件(.cpp)和頭文件(.h)在打開的空白文檔寫代碼按F5或者點擊面板上的啟動本地調試器添加源代碼文件的方法可以按快捷鍵也可以用下面的方法:在屏幕的左側或者右側有一個解決方案管理器,右點源文件-》添加-》新建項-》.cpp文件-》輸入文件名-》確定。
⑷ .net如何防反編譯
.net是中間語言十分容易被反編譯,通常都使用混淆作為一種加密手段。不過混淆不是真正防反編譯,只不過反編譯後代碼難讀懂而已,並且現在破解混淆的方式也比較多。所以真正要防反編譯還是需要通過加密代碼的方式。比如德國威步他們提供一種對.NET代碼完全加密保護的方式來防止反編譯的,曾經測試過用Reflector(.net反編譯工具)反編譯他們加密軟體加密的.NET程序,的確完全無法看到源代碼了。
⑸ 如何反編譯C#等net軟體類庫源代碼
這個需要看對方有沒有混淆,如果混淆了基本上反編譯出來都不便於閱讀。
1)如果沒有混淆且沒有加殼用Reflector.exe來反編譯;
2)如果沒有混淆但加了殼則用de4dot.exe來脫殼,脫殼後再用ILPsy.exe或Reflector.exe反編譯;
3)如果對方使用付費版且是最新版的Dotfuscator 來混淆,就算你反編譯後基本上閱讀不了。
⑹ .net開發的exe安裝文件可以反編譯嗎
可以,用reflector 及其它
用混淆器加密及數字簽名,可擋掉大部分dll文件被人家反編譯.但魔高一尺,道高一丈, 要做到完全加密是很難的.
有些Dotfuscator防反編譯軟體可以參考, 但那些功能強大的Dotfuscator都是商業軟體,要花銀子買.
總之,不管你加密的如何好,只是延長破解和反編譯成可閱讀代碼的時間而以,所以不要放太多的精力在上面
⑺ .net中反編譯過後代碼怎麼組合(c#)
[CompilerGenerated] 這個標志已經告訴你這個是編譯器生成的了,常規情況下你可以去掉這段代碼並重試。
反編譯過來的代碼通常是無法直接編譯的,需要你自己改寫
⑻ Net6編譯 ready to run aot 反編譯
可以使用反編譯程序來創建實際的源代碼
如 果您認為只有少數真正了解 IL 匯編語言的人才會看到並理解您的源代碼,請牢記反編譯並不會到此為止。我們可以使用反編譯程序來創建實際的源代碼。這些實用工具可以直接將 .NET 程序集反編譯為如 C#、 Visual Basic .NET 或 C++ 這樣的高級語言。
迄 今為止,從減輕部署和版本控制的負擔,到自描述二進制數據所實現的豐富 IDE 功能,您可能已經熟悉了這些元數據豐富的 Microsoft_ .NET Framework 體系結構帶來的所有好處。您可能不知道元數據的這種易用性帶來的一個目前對於大多數開發人員來說還沒有注意到的問題。為公共語言運行庫 (CLR) 編寫的程序更易於進行反相工程。不管怎麼說,這並不是 .NET Framework 設計中的缺陷;它只是一種現代的、中間編譯語言(Java 語言應用程序具有同樣的特徵)的現實狀況。Java 和 .NET Framework 都使用內嵌在可執行代碼中的豐富元數據:在 Java 中是位元組碼,在 .NET 中是 Microsoft 中間語言 (MSIL)。由於比二進制機器碼要高級很多,可執行文件充滿了可以輕松破解的信息。
⑼ .net網頁發布後進行反編譯
.Net有兩個很好的工具可以反編譯.NET程序集:Salamander .Net Decomplier和Reflector.Net ,Salamander .Net Decomplier功能非常強大,可以反編譯混淆過的.NE代碼,也可以直接將程序集中的類反編譯成一個文件,但是它是需要money的,試用版提供的功能又非常有限。相對而言呢,Reflector.net 是完全免費的,但是它只能一個方法一個方法的查看,不能將程序集直接反編譯成一個文件,這樣也比較麻煩,好就好在它支持插件add-in功能。針對它的缺點,很多人開發了很好用的插件,可以將整個程序集的代碼反編譯成源文件,比如說Reflector.FileDisassembler 、Reflector.FileGenerator 都是很好用的。
另外再提供一些Reflector的相關插件下載,enjoy!!!!
插件FileGenerator 使用方法:
最開始下載了FileGenerator插件不知如何使用,後來經過摸索,還是學會使用了,所以拿來和大家分享。
FileGenerator插件的作用是:根據dll文件,把裡面的源文件導出成文件,導出來的文件除了沒有注釋,變數名也變了,其它的可謂是沒有 差別。對於一些比較好的控制項,如果不是開源的,完全可以導出成文件,然後自己加上注釋,少許修改,很好的利用起來。(不開源的dll,用起來也不放心啊)
先根據上面的地址下載FileGenerator並解壓縮,然後運行Reflector.exe,然後點擊View->Add- Ins...,彈出一個窗口,然後點擊Add->選擇FileGenerator裡面的唯一一個dll文件: "FileGenerator.dll",點擊close.
然後回到Reflector窗口,Tool->Generator File(s)... 右邊就出現了插件的窗口,選中左邊的dll文件,點擊右邊的導出文件,源代碼就全部導出來了,真是爽啊!
使用.NET Reflector插件FileDisassembler還原源碼
.NET Reflector,它是一個類瀏覽器和反編譯器,可以分析程序集並向您展示它的所有秘密。.NET 框架向全世界引入了可用來分析任何基於 .NET 的代碼(無論它是單個類還是完整的程序集)的反射概念。反射還可以用來檢索有關特定程序集中包含的各種類、方法和屬性的信息。使用 .NET Reflector,您可以瀏覽程序集的類和方法,可以分析由這些類和方法生成的 Microsoft 中間語言 (MSIL),並且可以反編譯這些類和方法並查看 C# 或 Visual Basic ?.NET 中的等價類和方法。
為了演示 .NET Reflector 的工作方式,我將載入和分析前面已經顯示的 NUnitExample 程序集。下圖顯示了 .NET Reflector 中載入的該程序集。
在 .NET Reflector 內部,有各種可用來進一步分析該程序集的工具。要查看構成某個方法的 MSIL,請單擊該方法並從菜單中選擇 Disassembler。
除了能夠查看 MSIL 以外,您還可以通過選擇 Tools 菜單下的 Decompiler 來查看該方法的 C# 形式。通過在 Languages 菜單下更改您的選擇,您還可以查看該方法被反編譯到 Visual Basic .NET 或 Delphi 以後的形式。以下為 .NET Reflector 生成的代碼:
public void HashtableAddTest(){
Hashtable hashtable1;
hashtable1 = new Hashtable();
hashtable1.Add("Key1", "value1");
hashtable1.Add("Key2", "value2");
Assert.AreEqual("value1", hashtable1["Key1"], "Wrong object returned!");
Assert.AreEqual("value2", hashtable1["Key2"], "Wrong object returned!");
}
前面的代碼看起來非常像我為該方法實際編寫的代碼。以下為該程序集中的實際代碼:
public void HashtableAddTest(){
Hashtable ht = new Hashtable();
ht.Add("Key1", "value1");
ht.Add("Key2", "value2");
Assert.AreEqual("value1", ht["Key1"], "Wrong object returned!");
Assert.AreEqual("value2", ht["Key2"], "Wrong object returned!");
}
盡管上述代碼中存在一些小的差異,但它們在功能上是完全相同的。
雖然該示例是一種顯示實際代碼與反編譯代碼之間對比的好方法,但在我看來,它並不代表 .NET Reflector 所具有的最佳用途 — 分析 .NET 框架程序集和方法。.NET 框架提供了許多執行類似操作的不同方法。例如,如果您需要從 XML 中讀取一組數據,則存在多種使用 XmlDocument、XPathNavigator 或 XmlReader 完成該工作的不同方法。通過使用 .NET Reflector,您可以查看 Microsoft 在編寫數據集的 ReadXml 方法時使用了什麼,或者查看他們在從配置文件讀取數據時做了哪些工作。.NET Reflector 還是一個了解以下最佳實施策略的優秀方法:創建諸如 HttpHandlers 或配置處理程序之類的對象,因為您可以了解到 Microsoft 工作組實際上是如何在框架中生成這些對象的。
.NET Reflector 由 Lutz Roeder 編寫