java混淆反編譯

Ⅰ 如何防止代碼被反編譯

由於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 *;
}

Ⅱ 如何防止class被反編譯，の頤塹鬧恫

可以使用代碼混淆是對Class文件進行重新組織和處理，使得處理後的代碼與處理前代碼完成相同的功能(語義)。但是混淆後的代碼很難被反編譯，即反編譯後得出的代碼是非常難懂、晦澀的，因此反編譯人員很難得出程序的真正語義。
從理論上來說，如果有足夠的時間，被混淆的代碼仍然可能被破解，甚至目前有些人正在研製反混淆的工具。但是從實際情況來看，由於混淆技術的多元化發展，混淆理論的成熟，經過混淆的Java代碼還是能夠很好地防止反編譯。
app開發完後，最好做一下掃描和加固，應用掃描可以通過靜態代碼分析、動態數據跟蹤，定位出風險代碼，同時監控敏感數據的異常行為。
加固可以在一定程度上保護自己核心代碼演算法,提高破解/盜版/二次打包的難度，緩解代碼注入/動態調試/內存注入攻擊等。
目前市面上有很多第三方加固的平台， 如果新應用發布前需要掃描或者加固的話，可以先試試免費的，例如騰訊御安全，建議自己先去掃描測試下。

Ⅲ java的class文件，經過反編譯以後獲得的源代碼是L(小寫)，1，i(大寫)，o(大寫和小寫),0的組合，是怎麼回事

你看到的已經是源碼了，沒有辦法看到開發時候寫的代碼，因為通過加密混淆軟體，已經把原來寫的代碼中的變數、類名、方法都改成了混亂的組合方式了，所以你看到的都是很混亂的東西，你其實可以自己做一次對自己Java代碼的混淆測試，看看源代碼，再看看混淆後的，你就知道了，根本還原不了

Ⅳ javacompile混淆器怎麼混淆後的class文件還是可以被反編譯出來呢求高手指點....

混淆的作用並不是使class文件不能被反編譯
混淆的作用是使反編譯的代碼更難讓人閱讀，比如一些計算金錢的敏感邏輯里有如下的代碼(新金額=舊金額*某個倍率)：
double newMoney=oldMoney*rate;
如果這樣的代碼直接編譯成class文件，別人反編譯這個class文件就能很清楚的看到金錢的計算關系，混淆後代碼可能就變成這樣的了：
double a=b*c;
這樣的代碼別人即使反編譯了，也是很難看懂其中的邏輯關系的

Ⅳ Java混淆編譯器

最近試用了幾個Java混淆器(Java Obfuscator) 感覺沒有一個完全另人滿意的 於是想乾脆自己寫一個得了 翻了幾頁Java虛擬機規范之後突發奇想 別的混淆器都是在編譯好的byte code上做文章 能不能從源碼直接編譯成經過混淆的class文件呢？就這樣花了一個多星期的時間寫了一個Java混淆編譯器(Java Obfuscator Compiler) Q: 什麼是混淆器？ A: 由於Java程序運行時是動態連接的 因此編譯成的目標文件中包含有符號表 使得Java程序很容易被反編譯 混淆器可以打亂class文件中的符號信息 使反向工程變得非常困難 Q: 現有的混淆器有什麼問題？ A: 現有的混淆器都是對編譯好的class文件進行混淆 這樣就需要編譯和混淆兩個步驟 並不是所有的符號都需要混淆 如果你開發的是一個類庫 或者某些類需要動態裝載 那些公共API就必須保留符號不變 這樣別人才能使用你的類庫 現有的混淆器提供了GUI或腳本的方式來對那些需要保留的符號名稱進行配置 如果程序較大時配置工作變得很復雜 而程序一旦修改配置工作又要重新進行 某些混淆器能夠調整位元組碼的順序 使反編譯更加困難 但我經歷過混淆之後的程序運行出錯的情況 Q: Java混淆編譯器是如何工作的？ A: Java混淆編譯器是在Sun JDK中提供的Java編譯器(javac)的基礎上完成的 修改了代碼生成過程 對編譯器生成的中間代碼進行混淆 最後再生成class文件 這樣編譯和混淆只需要一個步驟就可以完成 另外可以在源程序中插入符號保留指令來控制哪些符號需要保留 不需要單獨的配置 Q: 如何安裝和運行JOC？ A: 下載joc jar () 運行java jar joc jar就可以啟動Java混淆編譯器 joc的命令行參數和javac完全相同 但增加了一個新的參數 Xobfuscate 它的用法如下 Xobfuscate:<level>其中<level>指定混淆級別 可以是以下幾種級別 Xobfuscate:none不進行混淆 Xobfuscate:private 對所有private訪問級別的元素進行混淆 Xobfuscate:package 對所有private或package private元素進行混淆 Xobfuscate:protected 對所有private package private protected元素進行混淆 Xobfuscate:public對所有的元素都進行混淆 Xobfuscate:all 相當於 Xobfuscate:public如果使用 Xobfuscate不帶級別參數 則相當於 Xobfuscate:package Q: 如何使用符號保留指令？ A: 除了在命令行用 Xobfuscate參數控制符號混淆級別外 還可以在源代碼中使用符號保留指令來控制那些符號需要保留 符號保留指令是一個Java文檔注釋指令 可以插入在類和類成員的文檔注釋中 例如 /*** This class should preserve * @preserve*/ public class Foo { /*** You can specify which field should be preserved * @preserve*/ private int x; /*** This field is not preserved */ private int y; /*** You can also preserve methods * @preserve*/ public void hello() {} /*** This method is not preserved */ private void collect() {} }如果沒有@preserve指令 則根據混淆級別及成員的訪問級別來確定符號是否保留 對於類的符號保留指令可以附帶一個保?留級別參數 來控制類成員的符號保留 包括 @preserve僅對類名進行保留 類成員的保留根據 Xobfuscate命令行參數決定 @preserve public 保留所有public成員 @preserve protected保留所有public和protected成員 @preserve package保留所有public protected package private成員 @preserve private保留所有成員 @preserve all相當於@preserve private Q: JOC有哪些限制？ A: 不支持分別編譯 必須對所有的源文件進行混淆編譯 最後給出一個JOC混淆的效果 源文件 import java awt event *;import javax swing *;public class AboutBox extends JDialog{ public AboutBox() { initform(); } JPanel panel = new JPanel(); JButton button = new JButton(); JLabel jLabel = new JLabel(); JTextArea jTextArea = new JTextArea(); /*** NOTE: The following code is required by the form designer * It can be modified using the form editor Do not* modify it using the code editor */ private void initform() { this setDefaultCloseOperation( WindowConstants DISPOSE_ON_CLOSE ); this getContentPane() setLayout( new java awt CardLayout()); this setModal( true ); this setResizable( false ); this setTitle( About ); panel setLayout( null ); button setText( OK ); button setBounds( ); panel add( button ); jLabel setText( File System Viewer for Swing ); jLabel setVerticalAlignment( SwingConstants TOP ); jLabel setBounds( ); panel add( jLabel ); jTextArea setFont( new java awt Font( Dialog )); jTextArea setLineWrap( true ); jTextArea setOpaque( false ); jTextArea setText( This puter program is protected by right law ); jTextArea setWrapstyleWord( true ); jTextArea setBounds( ); panel add( jTextArea ); this getContentPane() add( panel Card ); this setSize( ); button addActionListener( new java awt event ActionListener(){ public void actionPerformed( java awt event ActionEvent ev ){ ?button _actionPerformed( ev ); }}); } private void button _actionPerformed(ActionEvent ev) { this dispose(); }}經Javac編譯後用JAD反編譯的結果 import java awt *;import java awt event ActionEvent;import java awt event ActionListener;import javax swing *;import javax swing text JTextComponent;public class AboutBox extends JDialog{ JPanel panel ; JButton button ; JLabel jLabel ; JTextArea jTextArea ; public AboutBox() { panel = new JPanel(); button = new JButton(); jLabel = new JLabel(); jTextArea = new JTextArea(); initform(); } private void initform() { setDefaultCloseOperation( ); getContentPane() setLayout(new CardLayout()); setModal(true); setResizable(false); setTitle( About ); panel setLayout(null); button setText( OK ); button setBounds( ); panel add(button ); jLabel setText( File System Viewer for Swing ); jLabel setVerticalAlignment( ); jLabel setBounds( ); panel add(jLabel ); jTextArea setFont(new Font( Dialog )); jTextArea setLineWrap(true); jTextArea setOpaque(false); jTextArea setText( This puter program is protected by right law ); jTextArea setWrapstyleWord(true); jTextArea setBounds( ); panel add(jTextArea ); getContentPane() add(panel Card ); setSize( ); button addActionListener(new ActionListener() { public void actionPerformed(ActionEvent actionevent) { button _actionPerformed(actio lishixin/Article/program/Java/JSP/201311/19213

Ⅵ 如何混淆Java編譯後的類或jar，或將jar編譯成exe，使人無法反編譯獲得源代碼

混淆就可以了
我一直在用proguard4.5.1做Java項目的混淆

Ⅶ 如何防止程序員反編譯

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!」);

• }

• }

上面這段代碼，大家都認識。但我要問的是：如果我們使用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文件就行了，在這之前是什麼樣子無所謂！所以，我們的加密的整個邏輯就是：

• 在編譯代碼時（如使用ant或maven），使用插件將代碼進行加密（加密方式自己選），將class文件裡面的內容讀取成byte[]，然後進行加密後再寫回到class文件（這時候class文件裡面的內容不是標準的class，無法被反編譯了）

• 在啟動項目代碼時，指定使用我們自定義的ClassLoader就行了，而自定義的部分，主要就是在這里做解密工作！

如此，搞定！以上的做法比較完整的闡述，可以仔細閱讀一下這篇文章：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就得跟著這個項目到處走啊！

Ⅷ 我想反編譯 一個APK程序，但是那個APK程序的代碼被混淆了，導致APK反編譯失敗，請問這個問題怎麼解決

你的這個問題想想就知道不能解決的，為什麼？總所周知Java的代碼容易被反編譯，非常簡單，讓我自己寫反編譯工具我也能寫，如果市場上的軟體都這樣直接發布出去，那開發者的勞動成果怎麼保證？誰還願意開發？抄襲人家的就是了。正因為如此才誕生了代碼混淆，代碼混淆的作用就是防止apk被反編譯的。
我們假定混淆代碼也沒起作用，後面的災難性局面你自己去想像吧。。。