程序集防止反編譯

⑴ .net軟體,用什麼軟體加密狗加密,能防止代碼反編譯

.Net軟體的特點,一些強大的編譯工具可以對.Net可執行文件進行反編譯操作,並得出相應的IL代碼甚至是源代碼。即使是採用混淆工具以及強命名工具也不能從根本上解決問題,代碼依然會很容易地被Reflectoer等工具反編譯源代碼。 軟體加密狗：威步(WIBU)的CodeMeter,AxProtector(for.net)兩款軟體加密狗性能非常不錯 反編譯的問題,與傳統的代碼混淆工具（Obfuscator）不同,AxProtector可以完全阻止對.NET 程序集（由 C#, VB.NET, Delphi.NET, ASP.Net… 等語言編寫）的反編譯。通俗的講,AxProtector在破解者和您的 .NET 代碼之間構建了強大的防破解保護屏障,生成一個基於 Windows 的而不是基於 MSIL 的兼容格式文件。原始的 .NET 代碼完整的被加密後封裝在本地代碼內,無論何時都不會釋放到硬碟,對於破解者是不可見的。 與單純的.net加密軟體不同,AxProtector與CodeMeter硬體加密狗配套餐使用,採用了更為嚴密的密鑰管理,及最先進的AES、RSA、ECC等加密演算法存儲或傳輸密鑰,保證通訊安全。 .Net代碼編譯後生成的 .class 中包含有源代碼中的所有信息（不包括注釋）,尤其是在其中保存有調試信息的時候。所以一個按照正常方式編譯的.class 文件可以非常輕易地被反編譯。一般軟體開發商會採用一種叫做混淆器的工具。混淆器的作用是對編譯好的代碼進行混淆,使得其無法被反編譯或者反編譯後的代碼混亂難懂。由於混淆器只是混淆了方法名稱或流程,而不能防止源代碼被反編譯,因此混淆器的作用只是增加了反編譯的難度,最終的結果也是治標不治本。對於一些掌握工具的人來說幾乎還是透明的。AxProtector是一款真正意義的加密源代碼、防止反編譯的.net軟體加密軟體。 AxProtector加密了.net原代碼,任何時候原代碼都不可能被還原到硬碟當中。採用AxProtector加密後的.net代碼只有在程序調用或執行某一段函數的時候,才能通過AxProtectorClass在內存中解密後返回到程序中執行,運行之後迅速立即加密。這種隨機加密、按需解密原代碼的功能,能很好的防止.Net程序的反編譯,同時能夠很好地防止API加密點被摘除。有效地保證了源代碼的執行效率和安全性。

⑵ U3D如何做代碼混淆

Unity代碼混淆方案
內容提要：Unity引擎下的代碼保護，由於Unity引擎的一些特殊性，實行起來較為復雜，在國內外業界並沒有現成的方案。筆者通過在《QQ樂團》項目上的實際嘗試，得出了一種具體可行，能夠有效保護代碼邏輯的方案。特此分享給關注Unity引擎的項目，希望能提供一些的參考。
背景
Unity引擎上的程序執行在Mono運行時上，使用Mono編譯出的程序集格式與.NET標准一致。C#是Unity引擎下主要的開發語言，它具備不少高級語言特性，如反射、元數據、內置序列化等。但C#同時也是很容易被反編譯的語言，如果不採用任何保護措施，使用常用的工具（.NET Reflector）便能很容易得到可二次編譯的代碼。對項目運營帶來了比較大的風險。
.NET平台下通常的保護手段是混淆編譯出的程序集。VisualStudio自帶了一個混淆工具Dotfuscator可以對程序集進行混淆。功能包括名稱修改，流程混淆，字元串加密等。經過Dotfuscator混淆後的程序集，能夠避免被常用反編譯工具破解。變數的表意性被破壞，同時函數的內部流程也被混淆（如下[B1] ）。能有效起到保護源代碼的效果。
publicclass181: 218
{
// Fields
publicuint0;
publicushort1;
publicstaticreadonlyuint2;
publicstaticreadonlyuint3;
// Methods
static181();
public181();
public95.02();
public95.02(ref515A_0, uintA_1);
public95.02(79A_0, refuintA_1);
public95.02(ref79A_0, uintA_1);
public95.02(byte[] A_0, intA_1, refuintA_2);
public95.02(ref481A_0, intA_1, charA_2);
public95.02(refstringA_0, intA_1, charA_2);
public95.02(refbyte[] A_0, intA_1, refintA_2, uintA_3);
public95.03(ref79A_0, uintA_1);
public95.03(refbyte[] A_0, intA_1, refintA_2, uintA_3);
public95.04(refbyte[] A_0, intA_1, refintA_2, uintA_3);
}
public95.00(refsbyteA_0, intA_1)
{
// This item is obfuscated and can not be translated.
goto Label_0006;
if(1!= 0)
{
}
95.0local= 95.0.0;
bytenum= 0;
local = this.0(refnum,A_1);
A_0 = (sbyte) num;
returnlocal;
Unity引擎下，Mono編譯出的程序集，由於採用與.NET相同的格式標准。能夠直接被Dotfuscator混淆。但Unity引擎有一些特殊的地方，使混淆工作與一般的.NET程序存在差異。第三節將主要討論這些特殊點。
Unity引擎下代碼混淆的特殊性
代碼被資源引用[B2] 。Unity的可視化編輯特性在設計上的關鍵之處在於使代碼能夠以組件的形式依附到資源實例上。相比傳統游戲，Unity的兩類資源（scene和prefab）不僅包括數據，還包括附加在資源上的類對象。也就是說，這兩類資源的存儲格式中存在唯一標識某代碼類型的數據。混淆流程必須不破環這種對應關系才能使資源上的代碼邏輯正確被執行。（Unity這樣設計的意義並不是本文討論的重點，而另一篇分享個人對Unity可視化編輯的理解的文章中將會詳細說明。）
發布到Web的Unity項目，在生成播放器可執行包（*.unity）的介面中，將編譯程序集和打包這兩個步驟捆綁在的一起。我們沒辦法像普通.NET程序那樣，對編譯出的程序集進行混淆後再打到播放器可執行包中。
UnityEngine按函數名進行調用。MonoBehaviour是Unity引擎的一個重要的組件基類。其上的很多方法，Unity是通過方法名稱進行訪問的，如Awake、Start、Update等等。這些方法如果在混淆中被改名，將使方法調用失敗。這個問題相對比較好處理，Dotfuscator的重命名功能提供了排除配置。我們只要得到繼承於MonoBehaviour的所有類型，就能生成相應的排除配置，告知Dotfuscator不要對這些方法進行重命名。生成的配置節選如下[B3] ：
<option>xmlserialization</option>
<excludelist>
<type name="CEventMgr|CGameRoot|…|…" regex="true" excludetype="false">
<method name="Update"regex="true" />
<method name="LateUpdate"regex="true" />
<method name="FixedUpdate"regex="true" />
<methodname="Awake" regex="true" />
<customattributename="System.Runtime.CompilerServices.CompilerGeneratedAttribute"regex="true" />
<method name=".*"regex="true" />
<field name=".*"regex="true" />
</type>
<type name=".*"regex="true">
<customattributename="ANoRenameInObfuscate" regex="true" />
</type>
<type name=".*"excludetype="false" regex="true">
<method name=".*"regex="true">
<customattributename="ANoRenameInObfuscate" regex="true" />
</method>
</type>
思路
何時混淆？由於Web項目編譯和打包的過程是捆綁在一起的，官方沒有提供獨立的介面。（之前有跟官方反饋，但目前官方並沒有提供具體計劃。）想自己來分析官方的打包格式是行不通並且不太科學的。僅剩的辦法就是自己將代碼編譯成DLL，混淆之後再添加到Unity項目中。
順著這條思路，筆者在《QQ樂團》項目上作了嘗試。將項目中所有執行相關的代碼（不包括編輯器擴展的代碼）移出，指定相關的Unity依賴庫，編譯成DLL。再將此DLL復制到原項目中。這時意料之中的事情發生了——項目中所有資源上的代碼引用全部丟失。為了找到資源對代碼的映射形式，筆者調整Unity編輯器的設定，將資源的序列化格式改為文本格式，並進行對比分析。發現資源中是通過一個GUID來對應具體代碼的[B4] 。（如下）
m_ObjectHideFlags: 1
m_PrefabParentObject: {fileID: 0}
m_PrefabInternal: {fileID: 100100000}
m_GameObject: {fileID: 100000}
m_Enabled: 1
m_EditorHideFlags: 0
m_Script: {fileID:11500000, guid: , type: 1}
m_Name:
mInt: 1
mFloat: .5
中的類型雖然還沒有進行過混淆，但GUID已經發生了變化。將新的GUID替換到資源文件中，引用關系果然恢復了。
Unity引擎下的特殊問題都是可以解決的。於是順著這思路，開發了若干工具，得到了前後GUID的對應關系，並掃描所有資源以進行GUID的替換。另一方面，在混淆之後，類型的變數名發生了改變，資源中變數名賦有具體的值，也需要替換資源中的變數名對應到混淆後的變數名。這一切花費了不少的精力，終於是把工具都做成了。
然而人算不如天算，最終導致此方案走進死角的是一個之前很難意料到的問題：Unity引擎在處理DLL中的模版類型時存在缺陷——DLL中的模版類型沒有GUID，不能被資源所引用。這個問題在Unity官方網站上有少量反饋，而官方承認了這個bug，且沒有給出解決方案。而《QQ樂團》的項目在UI操作上比較廣泛地使用了模版類型，去除模版的使用談何容易。就這樣，這么一個不經意的問題為這個嘗試的方向畫上了句號。
「系著枷鎖跳舞」，這句話是形容的是在各種條件約束下盡可能的追求解決方案的一種狀態。總結之前的失敗，最終還是找到了實際可行的改進方案，並成功應用到《QQ樂團》的Web版本和微客戶端版本上。
最終的思路是將項目進行分層。獨立出一個不被資源引用的，包含最敏感的協議解析和各個系統模塊的「邏輯層」，將邏輯層的代碼獨立編譯成一個DLL，進行混淆再包含到項目中。邏輯層之外的代碼主要包括被資源引用到的，或是系統模塊部分介面定義這樣的不太敏感的內容，姑且稱為「行為層」。為了讓邏輯層可以獨立編譯，我們要求邏輯層可對行為層進行引用，而行為層則只能通過留在行為層的邏輯層介面訪問邏輯層。這樣我們就保護了我們最重要的代碼，同時繞過了資源引用代碼的問題。
這個方案對項目架構提出了一定的要求。一是要求敏感代碼和資源保持獨立，需要一個框架來載入各個模塊，而不是直接將模塊代碼直接附在場景物體的資源中。二是要求層次清晰，不允許反向依賴。有利於《QQ樂團》項目的消息是，《QQ樂團》從最早期就實現了一個較清晰的架構管理方法。因此花費了一定的時間進行分層，和實現介面訪問機制後，就成功執行了這個方案。
實際混淆步驟。《QQ樂團》是使用VisualBuild來執行版本構建和發布流程的。以下介紹版本構建中混淆相關的流程：
從Unity項目的Assets目錄中拷貝出邏輯層的代碼目錄（CodeGameLogic）。和編輯器擴展代碼（避免混淆後編輯器擴展代碼對邏輯層的依賴丟失導致編譯出錯）。
調用Unity.exe命令行編譯剩餘的行為層部分：
這個函數實際執行了：
BuildPipeline.BuildPlayer(new string[] {"Assets/obfuscated.unity" }, "WebPlayerObfuscated",
BuildTarget.WebPlayer, BuildOptions.None);
Editor程序集（也就是編輯器擴展程序集）時編譯失敗，中斷編譯過程，避免在BuildPlayer過程結束時構建生成的DLL被清理掉。BuildPlayer之前故意在Editor目錄下弄一個錯誤的代碼文件即可。
將生成的行為層DLL拷貝到邏輯層構建目錄。行為層DLL的路徑是在項目的Library/ScriptAssemblies下，有Assembly-CSharp.dll和Assembly-CSharp-firstpass.dll兩個文件。另外也拷貝邏輯層依賴的其它DLL到構建目錄，包括UnityEngine.dll，以及項目Plugins目錄下的依賴庫。
調用Mono的編譯器mcs編譯邏輯層DLL——CodeGameLogic.dll。編譯命令如下：
生成DotObfuscator的配置文件」WebCfg.xml」。這里是用自己編寫的工具，掃描CodeGameLogic.dll中的類型，得到不能被混淆的類型名和方法名，加入到配置文件的排出列表中。如「三。3」小節所示。
調用DotObfuscator對CodeGameLogic.dll執行混淆，得到混淆後的CodeGameLogic.dll：
將混淆後的CodeGameLogic.dll拷貝到項目中，然後構建項目。這里要注意的是，如果是構建Web項目，需要將dll拷貝到Plugins目錄。如果是Standalone（即客戶端）項目，直接拷貝到Assets目錄下即可。另外，這次構建是不可以有編譯錯誤的，所以第1部需要移除Editor目錄下的編輯器擴展的代碼。
接下來將構建好的項目與資源合並，就可以得到完整的混淆版本。
總結：
Unity項目的代碼反編譯較為容易。需要在重視代碼混淆工作。
Unity項目的代碼混淆方案實施起來限制較多。本文介紹的方案是筆者知曉的目前唯一可用的混淆方案。對項目的架構分層有強制性的要求。最好是在項目初期就考慮如何對項目進行分層，將需要保護的內容放置在被混淆的層中。

⑶ .net軟體,用什麼軟體加密狗加密,能防止代碼反編譯

.Net軟體
特點,
些強
編譯工具
.Net
執行文件進行反編譯操作,並
相應
IL代碼甚至
源代碼
即使
採用混淆工具
及強命名工具
能
根本
解決問題,代碼依
容易
Reflectoer等工具反編譯源代碼
軟體加密狗：威步(WIBU)
CodeMeter,AxProtector(for.net)兩款軟體加密狗性能非
錯
反編譯
問題,與傳統
代碼混淆工具（Obfuscator）
同,AxProtector
完全阻止
.NET
程序集（由
C#,
VB.NET,
Delphi.NET,
ASP.Net…
等語言編寫）
反編譯
通俗
講,AxProtector
破解者
您
.NET
代碼
間構建
強
防破解保護屏障,
基於
Windows
基於
MSIL
兼容格式文件
原始
.NET
代碼完整
加密
封裝
本
代碼內,
論何
都
釋放
硬碟,
於破解者
見
與單純
.net加密軟體
同,AxProtector與CodeMeter硬體加密狗配套餐使用,採用
更
嚴密
密鑰管理,及
先進
AES、RSA、ECC等加密算
存儲或傳輸密鑰,保證通訊安全
.Net代碼編譯
.class
包含
源代碼
所
信息（
包括注釋）,尤其
其
保存
調試信息
候
所
按照
式編譯
.class
文件
非
輕易
反編譯
般軟體
發商
採用
種叫做混淆器
工具
混淆器
作用
編譯
代碼進行混淆,使
其
反編譯或者反編譯
代碼混亂難懂
由於混淆器
混淆
名稱或流程,
能防止源代碼
反編譯,
混淆器
作用
增加
反編譯
難度,
終
結
治標
治本
於
些掌握工具
說幾乎
透明
AxProtector
款真
意義
加密源代碼、防止反編譯
.net軟體加密軟體
AxProtector加密
.net原代碼,任何
候原代碼都
能
原
硬碟
採用AxProtector加密
.net代碼
程序調用或執行某
段函數
候,才能通
AxProtectorClass
內存
解密
返
程序
執行,運行
迅速立即加密
種隨機加密、按需解密原代碼
功能,能
防止.Net程序
反編譯,同
能夠
防止API加密點
摘除
效
保證
源代碼
執行效率
安全性

⑷ VS怎樣給項目加強名稱，怎樣防止反編譯

.net 生成的dll 反編譯很簡單的
一般.net的dll防止反編譯 採用 加殼和混淆 兩種方案
加殼我沒怎麼研究過,一般加殼工具使用後會造成dll不能使用
最常用的就是混淆了,工具也很多 我一般使用Xenocode進行混淆
可以對 類名,變數名,屬性 等命名進行混淆 減小其反編譯後的可讀性
你可以自己嘗試一下 基本混淆後的程序 反編譯後 很難自己解讀出來

⑸ C#怎樣防止反編譯

我使用的方法是利用加殼工具：virboxProtectorStandalone。直接進行加殼。高級混淆、虛擬化代碼、智能壓縮等加密策略。如果要授權控制，可使用許可版本的virboxProtector。

未經加殼保護的 ILspy 反編譯效果如下：

public int add(int a, int b){
return a + b;}public int div(int a, int b){
return a / b;}public int mul(int a, int b){
return a * b;}public int sub(int a, int b){
return a - b;}

解決方案：

深思自主研發了為 C# .net 語言做保護的外殼（Virbox Protector）。將C# .net 編譯成的執行程序（.exe），動態庫（.dll）直接拖入加殼工具即可完成保護操作，十分方便。並且在效果上已經完全看不到源碼中的邏輯。

加密後的效果

public int add(int a, int b){
return (int)dm.dynamic_method((object)this, System.Reflection.MethodBase.GetCurrentMethod(), 16416u, 21, 16384u, 32u, 31516u, 5).Invoke(this, new object[]
{
this,
a,
b
});}
public int div(int a, int b){
return (int)dm.dynamic_method((object)this, System.Reflection.MethodBase.GetCurrentMethod(), 16956u, 21, 16924u, 32u, 31516u, 2).Invoke(this, new object[]
{
this,
a,
b
});}
public int mul(int a, int b){
return (int)dm.dynamic_method((object)this, System.Reflection.MethodBase.GetCurrentMethod(), 16776u, 21, 16744u, 32u, 31516u, 3).Invoke(this, new object[]
{
this,
a,
b
});}
public int sub(int a, int b){
return (int)dm.dynamic_method((object)this, System.Reflection.MethodBase.GetCurrentMethod(), 16596u, 21, 16564u, 32u, 31516u, 4).Invoke(this, new object[]
{
this,
a,
b
});}

架構支持

IIS 服務架構的後台邏輯 DLL 文件

windows PC 應用程序 EXE 文件

windows PC 應用程序動態庫 DLL 文件

UG等第三方繪圖工具使用的 DLL 文件

Unity3d 編譯使用的 DLL 文件

⑹ C#如何防止被別人反編譯

C#
編寫的代碼通過VS編譯器生成
dll
或
exe
，很容易被一些反編譯工具查看到源碼或對源碼進行修改。
為防止代碼被反編譯或被篡改，我們可以進行一定的防範措施。但不能杜絕，因為DotNet編寫代碼運行必須編譯成IL
中間語言，IL是很規則，同時也很好反編譯。
反編譯防範措施：
設置項目代碼反匯編屬性
混淆
方法一：防止
Ildasm.exe（MSIL
反匯編程序）
反匯編程序集
方法很簡單在項目文件AssemblyInfo.cs中增加SuppressIldasm屬性。
當項目中增加SuppressIldasm屬性後在使用ildasm.exe反編譯代碼，會提示:"受保護的模塊
--
無法進行反匯編"
ildasm.exe
讀取項目中包含
SuppressIldasm
屬性就不對此程序集進行反編譯。但ILSyp，Reflector等反編譯工具針對程序集設置SuppressIldasm屬性置之不理，一樣可以反編譯源碼。
缺點：
可見SuppressIldasm
屬性只針對ildasm.exe工具起效果，同時也能刪除ildasm.exe工具的此項限制。參考：《去掉ILDasm的SuppressIldasmAttribute限制》
方法二：混淆
混淆原理：將VS編譯出的文件(exe
或
dll)通過ildasm對文件進行重命名,字元串加密，移動等方式將原始代碼打亂。這種方式比較常見。
VS2013
自帶混淆工具：工具-->PreEmptive
Dotfuscator
and
Analytics
但VS2013自帶Dotfuscator
5.5
需購買激活才能使用全部功能。目前網路提供
DotfuscatorPro
4.9
破解版版本下載。
打開
DotfuscatorPro
4.9
主界面
Settings->Global
Options
全局配置
常用功能配置：Disable
String
Encryption=NO
啟用字元串加密
選擇需混淆C#編譯代碼(dll
或
exe)
其中Library不要勾選，否則有些類、變數等等不會混淆；
Rename
重命名配置
常用功能配置：
勾選
=
use
enhanced
overload
inction
使用增強模式
重命名方案
Renaming
Scheme
=
Unprintable
（不可列印字元，即亂碼），也可以選擇其他如小寫字母、大寫字元、數字的方式。
String
Encryption
字元串加密
勾選需要加密字元串文件(exe
或
dll)
可根據各自需求可進行其他相關配置。（如：control
flow,Output,Setting
->Build
Settings,Settings
-->
Project
Properties等）
最後生成混淆文件
Build
Project。
Build
Project
生成混淆項目錯誤：
Could
not
find
a
compatible
version
of
ildasm
to
run
on
assembly
C:Users***.exe.??This
assembly
was
originally
built
with
.NET
Framework
v4.0.30319.
Build
Error.
處理方法:
ILASM_v4.0.30319
=
C:WindowsMicrosoft.NETFrameworkv4.0.30319ilasm.exe
ILDASM_v4.0.30319
=
C:Program
Files
(x86)Microsoft
SDKsWindowsv8.1AinNETFX
4.5.1
Toolsildasm.exe
[安裝VS版本不同對應目錄會有所變化]
混淆代碼對比
未使用混淆工具，反編譯出的源碼：
使用混淆工具，反編譯出的源碼：
效果很明顯，很難看出反編譯代碼所寫的真正邏輯。
缺點：
C#代碼通過混淆工具生成後，增加了很多轉換過程。這使得反編譯工具無法很直觀看到源碼真正邏輯。但源碼代碼過多轉換會使軟體本身運行效率降低，甚至會出現報錯情況。