為什麼現在反編譯那麼難
由於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程序的重要技術。
② android反編譯怎麼修改游戲道具
需要的工具
jdk:必須的
baksmali：classes.dex反編譯為smali格式（文本文件，可修改）
smali：smali格式編譯打包為classes.dex
但由於smali格式類似匯編，比較難閱讀，所以用dex2jar進行輔助
dex2jar：classes.dex轉為jar包
jdgui：jar反編譯並閱讀
以上工具可以在 http://liye111111.ys168.com/ 下載
好了，順序就是把apk用zip解開，裡面的classes.dex分別用baksmali處理為smali，用dex2jar處理成jar，然後用jdgui看代碼，找好java文件中要改的位置後，在smali里找對應的位置修改，改完了用smali再編譯為classes.dex，覆蓋原來apk里的同名文件，最後重新簽名。注意安裝時要先刪除原來手機里的版本，因為簽名不同了，我第一次再這里卡了好久。
以「捕魚達人海底撈」為例
下載這個游戲的apk,fishing_joy_1.apk,和工具放在一起
用zip解開fishing_joy_1.apk
classes.dex到baksmali的同一目錄
用baksmali處理為smali
java -jar baksmali-1.2.6.jar -x classes.dex
得到out目錄，裡面是smali文件
用dex2jar處理classes.dex為jar包
dex2jar-0.0.7.10-SNAPSHOT\dex2jar.bat classes.dex
得到classes.dex.dex2jar.jar
這時我們的工作目錄下面是這樣
用jdgui打開classes.dex.dex2jar.jar
好了，可以看代碼，但還不能直接修改，需要對比著來修改smali文件
比如我們通過對比找到控制魚被打到幾率的代碼在FishLayer.smali
Java代碼
③ autoit v3 編寫的軟體反編譯,難度頗大,希望大大幫忙
雖然我以前是這么回答的，但實話說，不藉助autoit自帶的反編譯工具，也是有辦法反編譯的。
但網路知道平台上估計沒這種高人，或者說，有這種能力的高人一般沒時間泡在網路知道上。
所以，在這里提問是枉然的。建議去AutoIt中文論壇或官方論壇碰碰運氣吧，畢竟更專業一些。
不過話又說回來，就算去那裡也未必有人肯花時間幫你反編譯的（真的很費時間和精力）。一來防止引發版權問題，二來人家主要是來技術交流的，不是純粹為分數而幫人幹活的。所以，這個問題要得到解決，真的不容易。只能祝你好運了 ;-)
④ 任何程序都可以反編譯嗎為什麼有一些程序不可以反編譯
javap是用作反編譯的，但是javap只能給出你要反編譯的class的結構，比如有什麼方法，有什麼static或者非static的變數什麼，但不可能產生源代碼編譯後的文件不是原代碼文件，所以不能直接拿來編譯。希望樓主採納
⑤ windows系統的源代碼，為什麼沒人反編譯出來
原因：
一是代碼經過編譯後，反編譯是比較困難的。
二是代碼量超級大；
三是能夠反編譯的力量沒這么強大；
四是不是任何程序都能夠完整「還原」。
微軟現在也已經對部分代碼實行了公開，有他的公開網站，不過在上面我至今沒查到過我所需要的東西。
⑥ 用手機反編譯修改狀態欄怎麼那麼難啊！我都折騰幾天了都不行，有高人嗎指點指點吧
你想變回中文板嗎
⑦ 為什麼我反編譯一個exe文件原封不動轉為.exe就報錯了。
世界上的大多數事物都是存在不可逆特性的，比如說生雞蛋煮成熟雞蛋很容易，但把熟雞蛋再還原為生雞蛋就幾乎不可能了，也許將來的科技能夠實現，但至少現在還沒聽說過。
程序的編譯和反編譯也是一樣，一個電腦程序從供人類閱讀的高級語言編譯為供CPU解讀的機器語言，這是一個質變的過程，比方說某個運算結果可以用多種演算法實現，那麼你想往上回溯時，究竟選擇那種演算法呢？你可能會說，讓反編譯軟體隨便選一種吧，那麼問題來了，再繼續往上回溯的時候，很有可能就跟原程序完全不同了。所以，盡管「條條大路通羅馬」，但要想從羅馬回到原來的出發點就不是容易的事了。因此，到目前為止，尚未有反編譯軟體能夠把一個exe文件完整無誤地反編譯為源程序的（當然也許極簡單的程序可以，比如hello world），而程序本來就是嚴謹的東西，差一個字也可能會產生十萬八千里的誤差。所以，反編譯的結果只能用作參考，不能把它當作實際代碼。
⑧ .net,java都能被反編譯 那麼易語言為什麼不能反編譯
因為 .NET 也好 JAVA 也罷，為了跨平台，並沒有直接將源代碼編譯成機器碼（因為在不同硬體設備上的指令集是不同的），而是翻譯成了一個中間語言。
.NET 翻譯過的中間語言叫 IL，然後通過 JIT 來「解釋」執行。而 Java 的中間語言叫 Bytecode，通過 JVM 來「解釋」執行。
既然 JIT、JVM 是可以「看懂」中間語言，並在不同平台上「解釋」成對應的機器語言來執行，那麼中間語言就一定是可逆成高級語言的了。
而易語言這種東西是直接編譯成機器碼的了。不是不能反編譯，而是只能反編譯成匯編這種低級語言了。
⑨ APK 反編譯失敗 是為啥
1、反編譯=回編譯後分別是
smali目錄 回編譯為 classes.dex 文件
res目錄 回編譯為 resources.arsc 文件
2、回編譯順序
在回編譯時，會先檢查「源」即resources
當你漢化文件，修改出錯了（缺少一個符號也不行），
那麼回編譯會自動跳過編譯res文件夾，直接回編譯smali 。
所以，如果沒有對smali（classes.dex）漢化，那麼建議大家刪掉這個文件夾，
這要會大大加快回編譯速度。
3、出錯問題1
在漢化時，往往會不小心刪掉一些符號，如 "<" ">"符號等等。
<string name="app_name">File Manager</string>
<string name="app_name">文件管理器/string>
<string name="app_name"文件管理器</string>
這些小小的錯誤都會導致回編時譯檢查出錯。
所以漢化時，注意對校，然後再回編譯。
建議使用一些高級的文本編輯器，支持語法高亮視圖的。
4、出錯問題2
最近發現有些APK文件 反編譯後，就算不漢化直接回編譯，都會出錯。
有可能的原因1，反編譯後XML文件語法中@符號 前面多了"\" （\@ ），
用文本編輯工具 直接替換【\@】為【@】，應該可以解決。
建議使用最新版本的反編譯工具。
5、建議大家使用新版本的APKTool工具，
當然如果新的有問題也可以試試舊的一、系統文件漢化再次強調
1、漢化Settings.apk(系統設置)、MMS.apk（信息）、Phone.apk（電話）、
等等系統文件，一定要先 安裝構架，具體看另個文件
<關於APKTool工具反編譯Settings.apk問題>。
2、系統文件漢化完後不需要簽名，直接替換漢化後的文件，就可以了。
主要是，系統文件放在系統目錄，無需再次讀取簽名獲得許可權，已經是高級了。
二、打包說明
1、通常漢化完回編譯後，會自動生成所有APK內的文件，或者自動生成*.APK文件。
但是建議大家不要直接使用該文件，進了使用替換法，替換掉你漢化後的文件，
如：resources.arsc，如果修改過的圖片，等等…
2、很多人對於APK文件 解壓縮或壓縮 都用「WinRAR」或「好壓」，這里不推薦。
希望大家安裝7-Zip這個壓縮工具，對於zip格式的支持是最好的。而且很方便，
不需要重新關聯apk 直接右鍵打開就行了。替換直接拖拉進去，就OK了一、回編譯出錯問題
(1.提示 strings.xml 最後一行錯誤，檢查是否</string>符號錯誤；
在漢化時，往往會不小心刪掉一些符號，如 "<" ">"符號等等。
<string name="app_name">File Manager</string>
<string name="app_name">文件管理器/string>
<string name="app_name"文件管理器</string>
(2.提示 strings.xml 最頂部含中文代碼首行錯誤，編碼格式不對，轉換成 UTF-8；
(3.提示 public.xml 出錯，檢查改動過的 arrays.xml 是否代碼有錯誤的地方；
二、一切能正常但無法回編譯
還有一種情況，apktool最新版本能正常反編譯一個apk文件，在未做任何修改的情況下，無法回編譯。
這是就要注意了，可以嘗試一下用低版本的apktool進行【反編譯】，然後在用高版本的apktoo工具【回編譯】。
這里向大家推薦用 【APKDB】 這個工具，很方便，反編譯時可以選擇apktool的版本。
⑩ 我們可以很容易把源代碼編譯成機器代碼,為什麼就很難把機器代碼反編譯成源代碼
因為機器代碼太冗長腔梁敗伍顫，而且每一台電腦的機器代碼都不盡相渣塌同。
ps 這台電腦上A的機器代碼是101010101000，但在別的電腦上就不一定是這個了~