伺服器程序包反編譯

① 安卓軟體反編譯後回編譯運行幾秒後閃退。怎麼解決 原文件直接反編譯然後回編譯出現閃退。 原文件反編

從前不久河南的一大學生，高額貸款無法償還，跳樓自殺，記者親身體驗，只要身份信息屬實，審核只需要半個小時就能通過。還會教你如何在電話號碼上作假，就即使填寫的真的是父母的電話，也不會把校園貸款的事告知父母。現在大學里校園貸款隨處可見，明知道是不合法的還在繼續給學生貸款，絲毫不去考慮學生的償還能力。這一系列的亂象，真的該去管管，治理一下了。不要再讓悲劇發生了

② 如何防止程序員反編譯

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就得跟著這個項目到處走啊！

③ .app程序（iphone程序安裝包）能不能重新用xcode編輯（就是指反編譯）

這個是不可能的，不過你可以顯示他的包內容，提取一些圖片，他們適用的png都是加過密的，你可以通過crunch還原。用Chalers做一些代碼還原，但是你要能做到這些你肯定就不需要破解他的程序，自己就能寫出高質量的程序。
所以還是好好的學些編程的知識吧！

④ EXE文件反編譯成源碼

EXE文件可以通過步驟來反編譯成源碼，具體步驟如下：

1、在網路上搜索下載反編譯工具ILSpy，ILspy是一個開源的.net反編譯軟體，使用十分方便。解壓後如圖，雙擊.exe文件打開解壓工具。

(4)伺服器程序包反編譯擴展閱讀：

反編譯也稱為計算機軟體還原工程，是指通過對他人軟體的目標程序（比如可執行程序）進行「逆向分析、研究」工作，以推導出他人的軟體產品所使用的思路、原理、結構、演算法、處理過程、運行方法等設計要素，某些特定情況下可能推導出源代碼。

exe是編譯好的程序文件 要看結構就得反編譯 但是通常不能把可執行文件變成高級語言源代碼，只能轉換成匯編程序。 所以要要看結構不止要會反編譯 還得精通匯編語言。

⑤ python寫的程序，轉成了exe文件，怎麼進行反編譯為python源碼

1、電腦桌面，輸入「win+R」組合鍵，在彈出窗口中輸入「cmd」，點擊確定。

⑥ 知道一個網站的網址能通過反編譯獲取源代碼嗎

網站整個源碼肯定是獲取不到的。當然，我說的是包括界面和後台程序功能代碼。
只能獲取界面html代碼，以及css樣式js和一些圖片。
主要的後台功能代碼是獲取不到的。

⑦ 如何反編譯exe文件

反編譯exe文件基本上是不可能的，因為反編譯過程由很多因素會干擾，反編譯過程：
1、檢測程序時候加殼了，如果加殼就必須先去殼。
2、去殼後需要猜測程序員採用的是什麼編程語言，編程語言有：java/c/c++/c#/vb/VC++等等。
3、猜測到程序員使用的語言後根據編程語言進行匯編，匯編需要考慮到語言中的語法問題，即使是同種語言，一種命令有多種說法，匯編成功率在20%左右。
4、匯編成功後基本就已經到反編譯的頂端了，要從匯編程序翻譯成源碼可能性為1%。

⑧ re從零開始的反編譯教程

寫在開頭，引用很喜歡的一句話： 要麼學！要麼不學！學和不學之間沒有中間值 不學就放棄,學就要去認真的學！ --致選擇

為了回溯編譯過程（或對程序進行逆向工程），我們使用各種工具來撤銷匯編和編譯過程，這些工具就叫反匯編器和反編譯器。反匯編器撤銷匯編過程，因此我們可以得到匯編語言形式的輸出結果。反編譯器則以匯編語言甚至是機器語言為輸入，其輸出結果為高級語言。

數組的表示方式是：在基本類型前加上前中括弧「[」，例如int數組和float數組分別表示為：[I、[F；對象的表示則以L作為開頭，格式是 LpackageName/objectName;

（注意必須有個分號跟在最後），例如String對象在smali中為： Ljava/lang/String; ，其中 java/lang 對應 java.lang 包，String就是定義在該包中的一個對象。或許有人問，既然類是用 LpackageName/objectName; 來表示，那類裡面的內部類又如何在smali中引用呢？
答案是：在 LpackageName/objectName/subObjectName 的 subObjectName 前加 $ 符號。

方法的定義一般為： Func-Name (Para-Type1Para-Type2Para-Type3...)Return-Type
注意參數與參數之間沒有任何分隔符，同樣舉幾個例子就容易明白

無序列表的使用，在符號"-"後加空格使用。如下：

https://www.jianshu.com/p/1c54c1ccf5cc

https://www.cnblogs.com/onelikeone/p/7594177.html

解決：點擊進去jd-gui，刪除試一試。再不行換最新版本

解析結束後進行編譯報錯
解決方法： https://blog.csdn.net/fuchaosz/article/details/104800802

Failed parse ring installPackageLI: Targeting R+ (version 30 and above) requires the resources.arsc of installed APKs to be stored uncompress

解決方法：

降低gradle里版本，若出現
signatures do not match the previously installed version; ，

使用adb install命令在手機上安裝app時，遇到這個報錯。原因是新裝的app和手機上現有的舊版app沖突了。
解決方法：刪除手機上原來的app，再重新安裝即可。

可是轉念一想如果反編譯的apk都是Version 30 R+以上，難道我解壓後挨個改一遍gradle？太徹淡了，一定有解決方法，所以有了下面探究出現這個問題的解決方法：既然報錯是資源文件高版本不支持，而且沒有4位對齊，那麼不編譯資源文件就好了

APK簽名工具之jarsigner和apksigner：

https://blog.csdn.net/xzytl60937234/article/details/89088215?utm_medium=distribute.pc_relevant.none-task-blog-js_landingword-1&spm=1001.2101.3001.4242

利用apktool反編譯apk，並且重新簽名打包：

https://blog.csdn.net/qq_21007661/article/details/109851522?utm_medium=distribute.pc_relevant.none-task-blog-js_title-4&spm=1001.2101.3001.4242

驗證apktool能否使用

apktool -r d apk名字.apk，不反編譯資源文件，為什麼這么做，先挖個坑

錯誤提示沒有4位對齊和不支持30版本以上的資源文件。所有嘗試不編譯資源文件

解決4位對齊的方法：

查看當前目錄，生成了新文件：abc.keystor

使用JarSigner對apk進行簽名，命令如下

jarsigner -verbose -keystore abc.keystore -signedjar testx.apk src.apk abc.keystore

直接反編譯的apk產生上述錯誤

但是只編譯資源文件的apk安裝時

發現沒有使用V2進行簽名，這時候進行V2簽名， (apksigner,默認同時使用V1和V2簽名 ）

所以先對只編譯資源文件的apk進行V2嘗試看能否成功

重復1（進行apktool -r d apk名字.apk）-->2 -->3 -->4( 不使用jarsigner而使用apksigner )

將生成的abc.keystore和打包回的apk（ apktoolapp-debugdist 里的app-debug.apk）放入 C:Users aowei.lianAppDataLocalAndroidSdkuild-tools30.0.3 下，因為Android studio的SDK下有apksigner.bat.

對jarsigner只是apk進行了V1簽名；在Android7.0引入了V2簽名，因此，當進入sdk25.0.0及後續版本，會發現一個apksigner.bat執行腳本。

我們可以通過apksigner進行V2簽名，當然，apksigner默認是同時支持V1與V2的，於是：

學習了公鑰和密鑰的使用和區別，使用私鑰的加密演算法稱為對稱加密演算法，這種演算法實現是接收方和發送方公用一道密鑰，優點是效率高，缺點是安全性差，如果被第三人得知密鑰則信息泄露，由此衍生了公鑰加密演算法，也就是非對稱加密演算法，這個演算法是接收方給發送方公鑰，發送方用公鑰加密後發給接收方，接受方再用私鑰解密。這樣即使所有人知道公鑰也不會造成信息泄露。缺點是效率非常低。

此外了解了RSA簽名的大致過程，發送方擁有公鑰和私鑰，對信息進行摘要然後把摘要通過密鑰進行簽名，然後把簽名和信息一起發出去，那麼如何驗證該信息就是發送方發出的呢，這時候就使用到了公鑰驗證，通過公鑰對信息進行解簽，然後使用一樣的摘要演算法得到摘要，如果得到的摘要和解簽後的內容一致則說明是發送方發出。
總結就是公鑰加密，私鑰解密。公鑰驗證，私鑰簽名

RSA 密碼體制是一種公鑰密碼體制，公鑰公開，私鑰保密，它的加密解密演算法是公開的。由公鑰加密的內容可以並且只能由私鑰進行解密，而由私鑰加密的內容可以並且只能由公鑰進行解密。也就是說，RSA 的這一對公鑰、私鑰都可以用來加密和解密，並且一方加密的內容可以由並且只能由對方進行解密。

因為公鑰是公開的，任何公鑰持有者都可以將想要發送給私鑰持有者的信息進行加密後發送，而這個信息只有私鑰持有者才能解密。

它和加密有什麼區別呢？因為公鑰是公開的，所以任何持有公鑰的人都能解密私鑰加密過的密文，所以這個過程並不能保證消息的安全性，但是它卻能保證消息來源的准確性和不可否認性，也就是說，如果使用公鑰能正常解密某一個密文，那麼就能證明這段密文一定是由私鑰持有者發布的，而不是其他第三方發布的，並且私鑰持有者不能否認他曾經發布過該消息。故此將該過程稱為「簽名」。

Android 簽名機制 v1、v2、v3

進入JDK/bin, 輸入命令

參數:

進入Android SDK/build-tools/SDK版本, 輸入命令

參數:

例如:

最後安裝加 -t ：

附上參考鏈接：

https://blog.csdn.net/A807296772/article/details/102298970

配置NDK的時候如果按鈕是灰色的，手動配置

直接在javac後面指定編碼是UTF-8就是了。

需要注意的是要加上* -classpath .其中classpath後面的一個黑點是不能省略的。

編譯好後如何導入so庫

成功運行後發現lib目錄下已經apk編進去so了

https://www.52pojie.cn/thread-732298-1-1.html
本節所有到的工具和Demo

IDA
鏈接： https://pan..com/s/15uCX8o6tTSSelgG_RN7kBQ

密碼：ftie

Demo
鏈接： https://pan..com/s/1vKC1SevvHfeI7f0d2c6IqQ

密碼：u1an

找到so並打開它 因為我的機型是支持arm的所以我這里打開的是armeabi文件夾下的so 如果機型是x86模式的那麼這里要打開x86模式下的libJniTest.so

編譯過程：

按住鍵盤組合鍵 shift + f12 打開字元串窗口 這個窗口將會列舉出so中所包含的所有字元串 因為上節課我們只編寫了一個字元串 所以這里只有一個hello 52pojie! 如果打開的是x86的so這里還會有一些.so 但是字元串只有這一個

滑鼠點在hello 52pojie!字元串上,打開 Hex mp窗口,修改hello 52pojie!對應內存地址的內容
關於字元對應的16進制可以在網路搜索ascii碼表 找到字元所對應的16進制

因為我要把hello 52pojie！修改成hello world! 是不是只要找到每個字元所對應的hex修改就好了
這里我看到 hello 52pojie!對應的hex是:68 65 6C 6C 6F 20 35 32 70 6F 6A 69 65 21
我在ascii碼表上找到world所對應的十六進制是:77 6F 72 6C 64
所以hello world! 對應的十六進制是:68 65 6C 6C 6F 20 77 6F 72 6C 64 21

注意編輯的時候游標暫停的位置只有先輸入字母才能更改成功，修改好後 右鍵Apply changes應用

退出後保存

此時已經so修改完畢

大功告成，hello 52pojie! --> hello world!

⑨ 剛接觸J2ME，網上下載了一個程序，反編譯jar包出現許多錯誤，好多錯誤不 知怎麼改，誰有空，能幫我修改一

一般軟體都有混淆器編譯，就是為了防止反編譯。
所以你反編譯出來，就不會得到預期的結果，比如類名為a,b,c,這樣的代碼是沒法看的

推薦下載開源的

⑩ exe的安裝包，如何反編譯查看代碼

1、首先新建一個android項目，裡面只有一個mainactivity，而且主界面只會顯示一個字元串：你好。
2、下面，切換到這個項目生成的apk文件所在的目錄，可以看到有一個hellodemo.apk。
3、在命令行輸入：apktool
d
-r
hellodemo.apk。可以看到在當前目錄下生成了一個hellodemo文件夾。
4、進入到hellodemo\smali\com\example\hello，打開mainactivity.smali。找到：
const-string
v1,
"\u4f60\u597d"，
修改為：
const-string
v1,
"hello"，
5、然後在命令行輸入：apktool
b
hellodemo
hellodemo1.apk。這回重新打包成hellodemo1.apk。
6、然後給新生成的apk進行簽名。把這個apk拷貝到autosign的目錄下面，然後切換過去，在命令行輸入：java
-jar
signapk.jar
testkey.x509.pem
testkey.pk8
hellodemo1.apk
hellodemo.apk。
7、把生成的hellodemo.apk安裝到手機，可以看到主界面上已經顯示的是hello，而不再是你好。說明反編譯重新打包成功！