預防反編譯
Ⅰ 如何防止代碼被反編譯
由於apk是Android虛擬機載入的，它有一定的規范，加密apk後Dalvik無法識別apk了。完全避免是不可能的，總有人能夠破解你的代碼。但是有幾種方式來提高被反編譯取代碼的難度。
1 關鍵代碼使用jni調用本地代碼，用c或者c++編寫，因此相對比較難於反編譯
2 混淆java代碼。混淆是不改變代碼邏輯的情況下，增加無用代碼，或者重命名，使反編譯後的源代碼難於看懂。 網上開源的java代碼混淆工具較多，一般是用ant的方式來編譯的。
1 . 在工程文件project.properties中加入下proguard.config=proguard.cfg ， 如下所示：
target=android-8
proguard.config=proguard.cfg
Eclipse會通過此配置在工程目錄生成proguard.cfg文件
2 . 生成keystore (如已有可直接利用)
按照下面的命令行 在D:\Program Files\Java\jdk1.6.0_07\bin>目錄下，輸入keytool -genkey -alias android.keystore -keyalg RSA -validity 100000 -keystore android.keystore
參數意義：-validity主要是證書的有效期，寫100000天；空格，退格鍵 都算密碼。
命令執行後會在D:\Program Files\Java\jdk1.6.0_07\bin>目錄下生成 android.keystore文件。
3. 在Eclipce的操作
File -> Export -> Export Android Application -> Select project -> Using the existing keystore , and input password -> select the destination APK file
經過混淆後的源代碼，原先的類名和方法名會被類似a,b,c。。。的字元所替換，混淆的原理其實也就是類名和方法名的映射。
但4大組件並沒有混淆（所有在清單文件定義的組件不能被混淆），因為系統需要通過清單文件來查找和運行應用程序。
proguard.cfg 文件代碼解讀
-optimizationpasses 5 ->設置混淆的壓縮比率 0 ~ 7
-dontusemixedcaseclassnames -> Aa aA
- ->如果應用程序引入的有jar包,並且想混淆jar包裡面的class
-dontpreverify
-verbose ->混淆後生產映射文件 map 類名->轉化後類名的映射
-optimizations !code/simplification/arithmetic,!field/*,!class/merging/* ->混淆採用的演算法.
-keep public class * extends android.app.Activity ->所有activity的子類不要去混淆
-keep public class * extends android.app.Application
-keep public class * extends android.app.Service
-keep public class * extends android.content.BroadcastReceiver
-keep public class * extends android.content.ContentProvider
-keep public class * extends android.app.backup.BackupAgentHelper
-keep public class * extends android.preference.Preference
-keep public class com.android.vending.licensing.ILicensingService
-keepclasseswithmembernames class * {
native <methods>; -> 所有native的方法不能去混淆.
}
-keepclasseswithmembers class * {
public <init>(android.content.Context, android.util.AttributeSet);
-->某些構造方法不能去混淆
}
-keepclasseswithmembers class * {
public <init>(android.content.Context, android.util.AttributeSet, int);
}
-keepclassmembers class * extends android.app.Activity {
public void *(android.view.View);
}
-keepclassmembers enum * { -> 枚舉類不能去混淆.
public static **[] values();
public static ** valueOf(java.lang.String);
}
-keep class * implements android.os.Parcelable { -> aidl文件不能去混淆.
public static final android.os.Parcelable$Creator *;
}
Ⅱ 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屬性。
效果很明顯，很難看出反編譯代碼所寫的真正邏輯。
缺點：
C#代碼通過混淆工具生成後，增加了很多轉換過程。這使得反編譯工具無法很直觀看到源碼真正邏輯。但源碼代碼過多轉換會使軟體本身運行效率降低，甚至會出現報錯情況。
Ⅳ class怎麼防止被反編譯
任何加密都沒有用只要能本地運行的java程序就一定有辦法反編譯。
因為java最終總是要編程位元組碼的，自己實現classLoader或者直接hack JVM，
就一定能拿到位元組碼，然後反編譯。
不過混淆過的代碼反編譯出來沒有可讀性。。
Ⅳ 如何防止代碼被反編譯
針對代碼反編譯，推薦使用CBS賽博鎖，通過把安全容器內嵌到操作系統中，對容器內的應用和數據進行加鎖，程序和數據在容器內運行，實現最後一米數據安全，防止核心數據被泄露，防止伺服器終端中病毒，防止反編譯，反破解。
Ⅵ 怎樣防止.class文件被反編譯
使用混淆器，如RetroGuard。很多開發工具里都有集成。
Ⅶ 如何保護Java程序 防止Java反編譯
常用的保護技術 由於Java位元組碼的抽象級別較高，因此它們較容易被反編譯。本節介紹了幾種常用的方法，用於保護Java位元組碼不被反編譯。通常，這些方法不能夠絕對防止程序被反編譯，而是加大反編譯的難度而已，因為這些方法都有自己的使用環境和弱點。 隔離Java程序 最簡單的方法就是讓用戶不能夠訪問到Java Class程序，這種方法是最根本的方法，具體實現有多種方式。例如，開發人員可以將關鍵的Java Class放在伺服器端，客戶端通過訪問伺服器的相關介面來獲得服務，而不是直接訪問Class文件。這樣黑客就沒有辦法反編譯Class文件。目前，通過介面提供服務的標准和協議也越來越多，例如 HTTP、Web Service、RPC等。但是有很多應用都不適合這種保護方式，例如對於單機運行的程序就無法隔離Java程序。這種保護方式見圖1所示。 圖1隔離Java程序示意圖 對Class文件進行加密 為了防止Class文件被直接反編譯，許多開發人員將一些關鍵的Class文件進行加密，例如對注冊碼、序列號管理相關的類等。在使用這些被加密的類之前，程序首先需要對這些類進行解密，而後再將這些類裝載到JVM當中。這些類的解密可以由硬體完成，也可以使用軟體完成。 在實現時，開發人員往往通過自定義ClassLoader類來完成加密類的裝載(注意由於安全性的原因，Applet不能夠支持自定義的ClassLoader)。自定義的ClassLoader首先找到加密的類，而後進行解密，最後將解密後的類裝載到JVM當中。在這種保護方式中，自定義的ClassLoader是非常關鍵的類。由於它本身不是被加密的，因此它可能成為黑客最先攻擊的目標。如果相關的解密密鑰和演算法被攻克，那麼被加密的類也很容易被解密。這種保護方式示意圖見圖2。 圖2 對Class文件進行加密示意圖 轉換成本地代碼 將程序轉換成本地代碼也是一種防止反編譯的有效方法。因為本地代碼往往難以被反編譯。開發人員可以選擇將整個應用程序轉換成本地代碼，也可以選擇關鍵模塊轉換。如果僅僅轉換關鍵部分模塊，Java程序在使用這些模塊時，需要使用JNI技術進行調用。 當然，在使用這種技術保護Java程序的同時，也犧牲了Java的跨平台特性。對於不同的平台，我們需要維護不同版本的本地代碼，這將加重軟體支持和維護的工作。不過對於一些關鍵的模塊，有時這種方案往往是必要的。 為了保證這些本地代碼不被修改和替代，通常需要對這些代碼進行數字簽名。在使用這些本地代碼之前，往往需要對這些本地代碼進行認證，確保這些代碼沒有被黑客更改。如果簽名檢查通過，則調用相關JNI方法。這種保護方式示意圖見圖3。 代碼混淆 圖3 轉換成本地代碼示意圖 代碼混淆是對Class文件進行重新組織和處理，使得處理後的代碼與處理前代碼完成相同的功能(語義)。但是混淆後的代碼很難被反編譯，即反編譯後得出的代碼是非常難懂、晦澀的，因此反編譯人員很難得出程序的真正語義。從理論上來說，黑客如果有足夠的時間，被混淆的代碼仍然可能被破解，甚至目前有些人正在研製反混淆的工具。但是從實際情況來看，由於混淆技術的多元化發展，混淆理論的成熟，經過混淆的Java代碼還是能夠很好地防止反編譯。下面我們會詳細介紹混淆技術，因為混淆是一種保護Java程序的重要技術。圖4是代碼混淆的示意圖。 圖4 代碼混淆示意圖 幾種技術的總結 以上幾種技術都有不同的應用環境，各自都有自己的弱點，表1是相關特點的比較。 混淆技術介紹 表1 不同保護技術比較表 到目前為止，對於Java程序的保護，混淆技術還是最基本的保護方法。Java混淆工具也非常多，包括商業的、免費的、開放源代碼的。Sun公司也提供了自己的混淆工具。它們大多都是對Class文件進行混淆處理，也有少量工具首先對源代碼進行處理，然後再對Class進行處理，這樣加大了混淆處理的力度。目前，商業上比較成功的混淆工具包括JProof公司的1stBarrier系列、Eastridge公司的JShrink和4thpass.com的SourceGuard等。主要的混淆技術按照混淆目標可以進行如下分類，它們分別為符號混淆(Lexical Obfuscation)、數據混淆(Data Obfuscation)、控制混淆(Control Obfuscation)、預防性混淆(Prevent Transformation)。 符號混淆 在Class中存在許多與程序執行本身無關的信息，例如方法名稱、變數名稱，這些符號的名稱往往帶有一定的含義。例如某個方法名為getKeyLength()，那麼這個方法很可能就是用來返回Key的長度。符號混淆就是將這些信息打亂，把這些信息變成無任何意義的表示，例如將所有的變數從vairant_001開始編號；對於所有的方法從method_001開始編號。這將對反編譯帶來一定的困難。對於私有函數、局部變數，通常可以改變它們的符號，而不影響程序的運行。但是對於一些介面名稱、公有函數、成員變數，如果有其它外部模塊需要引用這些符號，我們往往需要保留這些名稱，否則外部模塊找不到這些名稱的方法和變數。因此，多數的混淆工具對於符號混淆，都提供了豐富的選項，讓用戶選擇是否、如何進行符號混淆。 數據混淆 圖5 改變數據訪問 數據混淆是對程序使用的數據進行混淆。混淆的方法也有多種，主要可以分為改變數據存儲及編碼(Store and Encode Transform)、改變數據訪問(Access Transform)。 改變數據存儲和編碼可以打亂程序使用的數據存儲方式。例如將一個有10個成員的數組，拆開為10個變數，並且打亂這些變數的名字；將一個兩維數組轉化為一個一維數組等。對於一些復雜的數據結構，我們將打亂它的數據結構，例如用多個類代替一個復雜的類等。 另外一種方式是改變數據訪問。例如訪問數組的下標時，我們可以進行一定的計算，圖5就是一個例子。 在實踐混淆處理中，這兩種方法通常是綜合使用的，在打亂數據存儲的同時，也打亂數據訪問的方式。經過對數據混淆，程序的語義變得復雜了，這樣增大了反編譯的難度。 控制混淆 控制混淆就是對程序的控制流進行混淆，使得程序的控制流更加難以反編譯，通常控制流的改變需要增加一些額外的計算和控制流，因此在性能上會給程序帶來一定的負面影響。有時，需要在程序的性能和混淆程度之間進行權衡。控制混淆的技術最為復雜，技巧也最多。這些技術可以分為如下幾類： 增加混淆控制 通過增加額外的、復雜的控制流，可以將程序原來的語義隱藏起來。例如，對於按次序執行的兩個語句A、B，我們可以增加一個控制條件，以決定B的執行。通過這種方式加大反匯編的難度。但是所有的干擾控制都不應該影響B的執行。圖6就給出三種方式，為這個例子增加混淆控制。 圖6 增加混淆控制的三種方式 控制流重組 重組控制流也是重要的混淆方法。例如，程序調用一個方法，在混淆後，可以將該方法代碼嵌入到調用程序當中。反過來，程序中的一段代碼也可以轉變為一個函數調用。另外，對於一個循環的控制流，為可以拆分多個循環的控制流，或者將循環轉化成一個遞歸過程。這種方法最為復雜，研究的人員也非常多。 預防性混淆 這種混淆通常是針對一些專用的反編譯器而設計的，一般來說，這些技術利用反編譯器的弱點或者Bug來設計混淆方案。例如，有些反編譯器對於Return後面的指令不進行反編譯，而有些混淆方案恰恰將代碼放在Return語句後面。這種混淆的有效性對於不同反編譯器的作用也不太相同的。一個好的混淆工具，通常會綜合使用這些混淆技術。 案例分析 在實踐當中，保護一個大型Java程序經常需要綜合使用這些方法，而不是單一使用某一種方法。這是因為每種方法都有其弱點和應用環境。綜合使用這些方法使得Java程序的保護更加有效。另外，我們經常還需要使用其它的相關安全技術，例如安全認證、數字簽名、PKI等。 本文給出的例子是一個Java應用程序，它是一個SCJP(Sun Certificate Java Programmer)的模擬考試軟體。該應用程序帶有大量的模擬題目，所有的題目都被加密後存儲在文件中。由於它所帶的題庫是該軟體的核心部分，所以關於題庫的存取和訪問就成為非常核心的類。一旦這些相關的類被反編譯，則所有的題庫將被破解。現在，我們來考慮如何保護這些題庫及相關的類。 在這個例子中，我們考慮使用綜合保護技術，其中包括本地代碼和混淆技術。因為該軟體主要發布在Windows上，因此轉換成本地代碼後，僅僅需要維護一個版本的本地代碼。另外，混淆對Java程序也是非常有效的，適用於這種獨立發布的應用系統。 在具體的方案中，我們將程序分為兩個部分，一個是由本地代碼編寫的題庫訪問的模塊，另外一個是由Java開發的其它模塊。這樣可以更高程度地保護題目管理模塊不被反編譯。對於Java開發的模塊，我們仍然要使用混淆技術。該方案的示意圖參見圖7。 圖7 SCJP保護技術方案圖 對於題目管理模塊，由於程序主要在Windows下使用，所以使用C++開發題庫訪問模塊，並且提供了一定的訪問介面。為了保護題庫訪問的介面，我們還增加了一個初始化介面，用於每次使用題庫訪問介面之前的初始化工作。它的介面主要分為兩類： 1． 初始化介面 在使用題庫模塊之前，我們必須先調用初始化介面。在調用該介面時，客戶端需要提供一個隨機數作為參數。題庫管理模塊和客戶端通過這個隨機數，按一定的演算法同時生成相同的SessionKey，用於加密以後輸入和輸出的所有數據。通過這種方式，只有授權(有效)的客戶端才能夠連接正確的連接，生成正確的SessionKey，用於訪問題庫信息。非法的客戶很難生成正確的SessionKey，因此無法獲得題庫的信息。如果需要建立更高的保密級別，也可以採用雙向認證技術。 2． 數據訪問介面 認證完成之後，客戶端就可以正常的訪問題庫數據。但是，輸入和輸出的數據都是由SessionKey所加密的數據。因此，只有正確的題庫管理模塊才能夠使用題庫管理模塊。圖8時序圖表示了題庫管理模塊和其它部分的交互過程。 圖8 題庫管理模塊和其它部分的交互過程圖
Ⅷ 如何有效的防止Java程序被反編譯和破解
由於Java位元組碼的抽象級別較高，因此它們較容易被反編譯。下面介紹了幾種常用的方法，用於保護Java位元組碼不被反編譯。通常，這些方法不能夠絕對防止程序被反編譯，而是加大反編譯的難度而已，因為這些方法都有自己的使用環境和弱點。
1.隔離Java程序
最簡單的方法就是讓用戶不能夠訪問到Java Class程序，這種方法是最根本的方法，具體實現有多種方式。例如，開發人員可以將關鍵的Java Class放在伺服器端，客戶端通過訪問伺服器的相關介面來獲得服務，而不是直接訪問Class文件。這樣黑客就沒有辦法反編譯Class文件。目前，通過介面提供服務的標准和協議也越來越多，例如 HTTP、Web Service、RPC等。但是有很多應用都不適合這種保護方式，例如對於單機運行的程序就無法隔離Java程序。
2.對Class文件進行加密
為了防止Class文件被直接反編譯，許多開發人員將一些關鍵的Class文件進行加密，例如對注冊碼、序列號管理相關的類等。在使用這些被加密的類之前，程序首先需要對這些類進行解密，而後再將這些類裝載到JVM當中。這些類的解密可以由硬體完成，也可以使用軟體完成。
在實現時，開發人員往往通過自定義ClassLoader類來完成加密類的裝載(注意由於安全性的原因，Applet不能夠支持自定義的ClassLoader)。自定義的ClassLoader首先找到加密的類，而後進行解密，最後將解密後的類裝載到JVM當中。在這種保護方式中，自定義的ClassLoader是非常關鍵的類。由於它本身不是被加密的，因此它可能成為黑客最先攻擊的目標。如果相關的解密密鑰和演算法被攻克，那麼被加密的類也很容易被解密。
3.轉換成本地代碼
將程序轉換成本地代碼也是一種防止反編譯的有效方法。因為本地代碼往往難以被反編譯。開發人員可以選擇將整個應用程序轉換成本地代碼，也可以選擇關鍵模塊轉換。如果僅僅轉換關鍵部分模塊，Java程序在使用這些模塊時，需要使用JNI技術進行調用。當然，在使用這種技術保護Java程序的同時，也犧牲了Java的跨平台特性。對於不同的平台，我們需要維護不同版本的本地代碼，這將加重軟體支持和維護的工作。不過對於一些關鍵的模塊，有時這種方案往往是必要的。為了保證這些本地代碼不被修改和替代，通常需要對這些代碼進行數字簽名。在使用這些本地代碼之前，往往需要對這些本地代碼進行認證，確保這些代碼沒有被黑客更改。如果簽名檢查通過，則調用相關JNI方法。
4.代碼混淆
代碼混淆是對Class文件進行重新組織和處理，使得處理後的代碼與處理前代碼完成相同的功能(語義)。但是混淆後的代碼很難被反編譯，即反編譯後得出的代碼是非常難懂、晦澀的，因此反編譯人員很難得出程序的真正語義。從理論上來說，黑客如果有足夠的時間，被混淆的代碼仍然可能被破解，甚至目前有些人正在研製反混淆的工具。但是從實際情況來看，由於混淆技術的多元化發展，混淆理論的成熟，經過混淆的Java代碼還是能夠很好地防止反編譯。下面我們會詳細介紹混淆技術，因為混淆是一種保護Java程序的重要技術。
Ⅸ 怎麼防止開發出來的程序被別人反編譯
1.本地數據加密
iOS應用防反編譯加密技術之一：對NSUserDefaults，sqlite存儲文件數據加密，保護帳號和關鍵信息
2.URL編碼加密
iOS應用防反編譯加密技術之二：對程序中出現的URL進行編碼加密，防止URL被靜態分析
3.網路傳輸數據加密
iOS應用防反編譯加密技術之三：對客戶端傳輸數據提供加密方案，有效防止通過網路介面的攔截獲取數據
4.方法體，方法名高級混淆
iOS應用防反編譯加密技術之四：對應用程序的方法名和方法體進行混淆，保證源碼被逆向後無法解析代碼
5.程序結構混排加密
iOS應用防反編譯加密技術之五：對應用程序邏輯結構進行打亂混排，保證源碼可讀性降到最低
Ⅹ 如何防止程序員反編譯
Java從誕生以來，其基因就是開放精神，也正因此，其可以得到廣泛愛好者的支持和奉獻，最終很快發展壯大，以至於有今天之風光！但隨著java的應用領域越來越廣，特別是一些功能要發布到終端用戶手中（如Android開發的app），有時候，公司為了商業技術的保密考慮，不希望這裡面的一些核心代碼能夠被人破解（破解之後，甚至可以被簡單改改就發布出去，說嚴重點，就可能會擾亂公司的正常軟體的市場行為），這時候就要求這些java代碼不能夠被反編譯。
這里要先說一下反編譯的現象。因為java一直秉持著開放共享的理念，所以大家也都知道，我們一般共享一個自己寫的jar包時，同時會共享一個對應的source包。但這些依然與反編譯沒有什麼關系，但java的共享理念，不只是建議我們這樣做，而且它自己也在底層上「強迫」我們這么做！在java寫的.java文件後，使用javac編譯成class文件，在編譯的過程，不像C/C++或C#那樣編譯時進行加密或混淆，它是直接對其進行符號化、標記化的編譯處理，於是，也產生了一個逆向工程的問題：可以根據class文件反向解析成原來的java文件！這就是反編譯的由來。
但很多時候，有些公司出於如上述的原因考慮時，真的不希望自己寫的代碼被別人反編譯，尤其是那些收費的app或桌面軟體（甚至還有一些j2ee的wen項目）！這時候，防止反編譯就成了必然！但前面也說過了，因為開放理念的原因，class是可以被反編譯的，那現在有這樣的需求之後，有哪些方式可以做到防止反編譯呢？經過研究java源代碼並進行了一些技術實現（結果發現，以前都有人想到過，所以在對應章節的時候，我會貼出一些寫得比較細的文章，而我就簡單闡述一下，也算偷個懶吧），我總共整理出以下這幾種方式：
代碼混淆
這種方式的做法正如其名，是把代碼打亂，並摻入一些隨機或特殊的字元，讓代碼的可讀性大大降低，「曲線救國」似的達到所謂的加密。其實，其本質就是打亂代碼的順序、將各類符號（如類名、方法名、屬性名）進行隨機或亂命名，使其無意義，讓人讀代碼時很累，進而讓人乍一看，以為這些代碼是加過密的！
由其實現方式上可知，其實現原理只是擾亂正常的代碼可讀性，並不是真正的加密，如果一個人的耐心很好，依然可以理出整個程序在做什麼，更何況，一個應用中，其核心代碼才是人們想去了解的，所以大大縮小了代碼閱讀的范圍！
當然，這種方式的存在，而且還比較流行，其原因在於，基本能防範一些技術人員進行反編譯（比如說我，讓我破解一個混淆的代碼，我寧願自己重寫一個了）！而且其實現較為簡單，對項目的代碼又無開發上的侵入性。目前業界也有較多這類工具，有商用的，也有免費的，目前比較流行的免費的是：proguard（我現象臨時用的就是這個）。
上面說了，這種方式其實並不是真正加密代碼，其實代碼還是能夠被人反編譯（有人可能說，使用proguard中的optimize選項，可以從位元組流層面更改代碼，甚至可以讓JD這些反編譯軟體可以無法得到內容。說得有點道理，但有兩個問題：1、使用optimize對JDK及環境要求較高，容易造成混淆後的代碼無法正常運行；2、這種方式其實還是混淆，JD反編譯有點問題，可以有更強悍的工具，矛盾哲學在哪兒都是存在的^_^）。那如何能做到我的class代碼無法被人反編譯呢？那就需要我們下面的「加密class」！
加密class
在說加密class之前，我們要先了解一些java的基本概念，如：ClassLoader。做java的人已經或者以後會知道，java程序的運行，是類中的邏輯在JVM中運行，而類又是怎麼載入到JVM中的呢（JVM內幕之類的，不在本文中闡述，所以點到為止）？答案是：ClassLoader。JVM在啟動時是如何初始化整個環境的，有哪些ClassLoader及作用是什麼，大家可以自己問度娘，也不在本文中討論。
讓我們從最常見的代碼開始，揭開一下ClassLoader的一點點面紗！看下面的代碼：
Java代碼
publicclassDemo{
publicstaticvoidmain(String[]args){
System.out.println(「helloworld!」);
}
}
在編譯代碼時（如使用ant或maven），使用插件將代碼進行加密（加密方式自己選），將class文件裡面的內容讀取成byte[]，然後進行加密後再寫回到class文件（這時候class文件裡面的內容不是標準的class，無法被反編譯了）
在啟動項目代碼時，指定使用我們自定義的ClassLoader就行了，而自定義的部分，主要就是在這里做解密工作！
上面這段代碼，大家都認識。但我要問的是：如果我們使用javac對其進行編譯，然後使用java使其運行（為什麼不在Eclipse中使用Runas功能呢？因為Eclipse幫我們封閉，從而簡化了太多東西，使我們忽略了太多的底層細節，只有從原始的操作上，我們才能看到本質），那麼，它是怎麼載入到JVM中的？答案是：通過AppClassLoader載入的（相關知識點可以參考：http://hxraid.iteye.com/blog/747625）！如果不相信的話，可以輸出一下System.out.println(Thread.currentThrea().getContextLoader());看看。
那又有一個新的問題產生了：ClassLoader又是怎樣載入class的呢？其實，AppClassLoader繼承自java.lang.ClassLoader類，所以，基本操作都在這個類裡面，讓我們直接看下面這段核心代碼吧：
看到這里，已經沒有必要再往下面看了（再往下就是native方法了，這是一個重大伏筆哦），我們要做的手腳就在這里！
手腳怎麼做呢？很簡單，上面的代碼邏輯告訴我們，ClassLoader只是拿到class文件中的內容byte[]，然後交給JVM初始化！於是我們的邏輯就簡單了：只要在交給JVM時是正確的class文件就行了，在這之前是什麼樣子無所謂！所以，我們的加密的整個邏輯就是：
如此，搞定！以上的做法比較完整的闡述，可以仔細閱讀一下這篇文章：https://www.ddtsoft.com/#developerworks/cn/java/l-secureclass/文章中的介紹。
通過這個方法貌似可以解決代碼反編譯的問題了！錯！這里有一個巨大的坑！因為我們自定義的ClassLoader是不能加密的，要不然JVM不認識，就全歇菜了！如果我來反編譯，呵呵，我只要反編譯一下這個自定義的ClassLoader，然後把裡面解密後的內容寫到指定的文件中保存下來，再把這個加了邏輯的自定義ClassLoader放回去運行，你猜結果會怎樣？沒錯，你會想死！因為你好不容易想出來的加密演算法，結果人家根本不需要破解，直接就繞過去了！
現在，讓我們總結一下這個方法的優缺點：實現方式簡單有效，同時對代碼幾乎沒有侵入性，不影響正常開發與發布。缺點也很明顯，就是很容易被人破解！
當然啦，關於缺點問題，你也可以這么干：先對所有代碼進行混淆、再進行加密，保證：1、不容易找到我們自定義的那個ClassLoader；2、就算找到了，破解了，代碼可讀性還是很差，讓你看得吐血！（有一篇文章，我覺得寫得不錯，大家可以看一看：http://www.scjgcj.com/#blog/851544）
嗯，我覺得這個方法很好，我自己也差點被這個想法感動了，但是，作為一個嚴謹的程序員，我真的不願意留下一個隱患在這里！所以，我繼續思索！
高級加密class
前面我們說過有個伏筆來著，還記得吧？沒錯，就是那個native！native定義的方法是什麼方法？就是我們傳說中的JNI調用！前面介紹過的有一篇文章中提到過，其實jvm的真實身份並不是java，而是c++寫的jvm.dll（windows版本下），java與dll文件的調用就是通過JNI實現的！於是，我們就可以這樣想：JNI可以調用第三方語言的類庫，那麼，我們可不可以把解密與裝載使用第三方語言寫（如C++，因為它們生成的庫是不好反編譯的），這樣它可以把解密出來的class內容直接調jvm.dll的載入介面進行初始化成class，再返回給我們的ClassLoader？這樣，我們自定義的ClassLoader只要使用JNI調用這個第三方語言寫的組件，整個解密過程，都在黑盒中進行，別人就無從破解了！
嗯，這個方法真的很不錯的！但也有兩個小問題：1.使用第三方語言寫，得會第三方語言，我說的會，是指很溜！2.對於不同的操作系統，甚至同一操作系統不同的版本，都可能要有差異化的代碼生成對應環境下的組件（如window下是exe，linux是so等）！如果你不在乎這兩個問題，我覺得，這個方式真的挺不錯的。但對於我來說，我的信條是，越復雜的方式越容易出錯！我個人比較崇尚簡潔的美，所以，這個方法我不會輕易使用！
對了，如果大家覺得這個方法還算可行的話，可以推薦一個我無意中看到的東西給大家看看（我都沒有用過的）：jinstall，
更改JVM
看到這個標題，我想你可能會震驚。是的，你沒看錯，做為一個程序員，是應該要具有懷疑一切、敢想敢做的信念。如果你有意留心的話，你會發現JVM版本在業界其實也有好幾個版本的，如：Sun公司的、IBM的、Apache的、Google的……
所以，不要阻礙自己的想像力，現在沒有這個能力，並不代表不可能。所以，我想到，如果我把jvm改了，在裡面對載入的類進行解密，那不就可以了嗎？我在設計構思過程中，突然發現：人老了就是容易糊塗！前面使用第三方語言實現解密的兩個問題，正好也是更改JVM要面對的兩個問題，而且還有一個更大的問題：這個JVM就得跟著這個項目到處走啊！