手機腳本反編譯

❶ 安卓app360加固怎麼反編譯

1 對比

上傳demo進行加固，解包後對比下原包和加固包，發現加固包在assets文件夾下多了libjiagu.so，libjiagu_x86，lib文件夾下多了libjiagu_art.so，同時修改了dex文件和androidManifest文件

打開manifest文件，看到xxx加固對Application標簽做了修改，添加了殼入口，也就是我們反編譯後看到的StubApplication.smali這個文件。

相比於之前版本的加固，自從1.x.x.x加固版本之後，多了幾次反調試，使得動態難度稍微增大了一些，不過針對脫殼機脫殼，再多了反調試也是無用。或者通過修改系統源碼，也能達到消除反調試的作用。

2 動態調試

（1）把app安裝到手機，以調試模式打開app

（2）以shell模式root許可權打開IDA的android_server監聽

（3）tcp轉發

（4）打開IDA，修改配置為在進程開始時下斷

（5）搜索到進程後jdwp轉發，pid值即為我們進程號，並在命令行下附加。

成功附加後，可以下段了，打開Debugger Option

我們選擇在線程開始和庫載入時下斷，修改成功後，jdb附加，點擊運行

程序會斷在elf頭處，按下G鍵，搜索mmap，在mmap函數的段首和斷尾下段

F9運行，來到斷尾時F8單步，

來到此處時，在 BLunk_5C999C2C下斷，F9一下，F7跟進去

跟進去今後在BLX LR處進行下斷，此處就是進行反調試的地方，原理依然是獲取TracePid的值判斷當前是不是處於調試狀態，建議第一次調試的人在fgets和fopen處下斷，再f7跟進此調用就可以看到TracePid的值了。

跟進去之後，我們直接把方法移到最下方，就可以看到kill符號了，這就是殺進程的地方，如果當前處於調試狀態，則直接結束進程。

我們在此函數的所有cmpR0,#0處下斷，F9一下後即斷在斷點處，觀察寄存器窗口的R0值，實質就是當前的TracePid的16進制的值

不確定的可以使用cat /proc/pid/status進行對比一下，我們直接把R0置0，右鍵選擇Zero Value即可清0，繼續F9

我們看到程序又來到了mmap處，繼續f9

當繼續斷在調用反調試功能的方法時，繼續F7跟進，依然在所有的cmp R0，#0處下斷，斷下後把R0清0後繼續F9運行

目前的規律是，調用BLXLR的第一次，第二次和第四次是進行反調試判斷的，第三次並不影響，可以直接f9跳過去，三次反調試搞定後，就可以愉快的F9運行並觀察堆棧窗口了

當看到出現如下所示時：

說明殼已經開始解密並釋放dex文件了，我們直接F8單步十幾步，最後F9一下就可以看到我們需要的dex頭了

直接腳本mp出來即可，最後把libjiagu的所有文件刪除，並修復下Application標，如果存在則修復，不存在刪除即可

❷ Android反編譯（三）— 手動編譯

PS: 最近沒工作，沒工作就沒需求，沒需求就沒什麼技術總結的靈感，那就沒更新什麼。但是兩個月不更新了，要是三個月不更新就會出大事，所以這次打算做一件有意思又不難的事。
之前有發文章寫過反編譯，今天就來試試反編譯之正編譯，開玩笑的，就是試試手動編譯的過程， 平時我們在項目中編譯出包都是使用Gradle直接執行assemble任務就能解決，我打算試試手動模擬整個過程。當然我也是第一次這樣搞，所以如果有寫得不對的地方，還望指出。

眾所周知，apk實質上就是一個壓縮包。復習一下，我們寫個最簡單的Demo，然後打包，然解壓，注意是解壓，不是反編譯，意義是不同的。

注意我這個Demo很簡單，什麼都不引入

然後我們看看整個出包的過程，隨便從網上拿張圖

然後這里我們用Android SDK給我們提供的工具來完成整個流程，工具在sdk文件夾下的build-tools文件夾下，有什麼aapt.exe、dx.bat，用的就是這些

這步應該是整個流程最簡單的吧，我感覺，所以從最簡單的開始。
我們先看看生成的dex有什麼

對比項目，我是一開始最基本的項目，什麼都沒動，所以只有一個MainActivity.clas，所以這里肯定是要先想辦法得到BuildConfig.class和R.class。

輸入命令：
aapt p -f -m -J <輸出路徑> -S <res路徑> -I <android.jar路徑> -M <Manifest路徑>

下一步，我們需要BuildConfig.class
這個BuildConfig.java是由gradle在我們配置好gradle之後自己幫我們生成的，所以我們直接拿來用，然後再javac就得到class文件了

然後我們再編譯我們的MainActivity.java並將它們放到同一個文件夾下， MainActivity因為引用了Android.jar和R文件，所以編譯時注意點，我為此被動好好的復習了一遍javac，都是淚

最後一步，我們用dx工具就能打出dex文件了

然後執行命令就得到一個Dex文件，看看這個文件裡面和上面直接打出的apk中的Dex文件有什麼不同：

看圖，我們上一步已經生成.dex了，那麼我們需要和compiled Resource 還有 Other Resource 一起生成APK。

我們先來生成compiled Resource，也就是resources.arsc
發現之前使用aapt生成R文件的時候沒寫完整，當時可以加一個-F參數直接生成arsc和Manifest

導出的abc.zip裡面就有resources.arsc和AndroidManifest.xml。
因為之前寫漏了，所以肯定要重新編一次MainActivity.java和Dex

我們把剛才的dex文件和aapt生成的resources.arsc、AndroidManifest.xml和res放到一個文件夾裡面。
PS：res文件夾也是上面aapt的命令生成的
然後我們對比這個文件夾和之前apk解壓的文件夾

最後運行

看來是成功了。

再說說遇到的還有兩個問題，並說下我解決問題的思路
（1）我把它們都放到一個文件夾之後，我壓縮成壓縮包，然後改後綴成.apk，然後發現安裝不了，我就直接反編譯，發現發編譯失敗，提示包有問題，以我多點玩包的經驗，我感覺就是壓縮工具出了問題，然後我去下個「好壓」（這不是廣告啊），然後就能正常反編譯了。
（2）但是還是安裝不了，再根據我多年的玩包經驗，我感覺是簽名問題，然後我隨便給這個包上一個簽名，就能正常安裝得到上圖的結果了。

總體來說，還真挺好玩的，這整個過程，就是翻車了幾次。做完之後感覺非常牛逼，為什麼這樣說，因為我知道這整個過程，我就可以做到，我不經過gradle來打包，我自己寫個python腳本來調用aapt和dx來打包也是能做到的。
當然上面純屬異想天開，因為這是個什麼都沒有的Demo所以覺得簡單，要是一個真實的項目，我感覺肯定要有很多坑，別的先不說，一個項目那麼多依賴關系，我這javac要搞死人。
最後如果有不對的地方，希望有大佬能夠指出，畢竟能運行也不能證明完全沒問題。然後我使用的build-tools是28的，不敢保證其它版本包括以後版本的玩法都一樣。

❸ 如何實現APK的反編譯得到APK的源碼

最新的反編譯不用此方法， 有最新的一鍵自動反編譯工具：

這段時間在學Android應用開發，在想既然是用Java開發的應該很好反編譯從而得到源代碼吧，google了一下，確實很簡單，以下是我的實踐過程。

在此鄭重聲明，貼出來的目的不是為了去破解人家的軟體，完全是一種學習的態度，不過好像通過這種方式也可以去漢化一些外國軟體。

註：本Android反編譯教程，在Windows7-Ultimate-64bit操作系統上，測試通過！

下述所需的反編譯工具包 下載

一、反編譯Apk得到Java源代碼
首先要下載兩個工具：dex2jar和JD-GUI

前者dex2jar是將apk中的classes.dex轉化成Jar文件，而JD-GUI是一個反編譯工具，可以直接查看Jar包的源代碼。以下是下載地址：

dex2jar：http://laichao.googlecode.com/files/dex2jar-0.0.7-SNAPSHOT.zip

JD-GUI：http://laichao.googlecode.com/files/jdgui.zip

具體步驟：

首先將apk文件，將後綴改為zip，解壓，得到其中的classes.dex，它就是java文件編譯再通過dx工具打包而成的；

解壓下載的dex2jar，將classes.dex復制到dex2jar.bat所在目錄。在命令行下定位到dex2jar.bat所在目錄(在DOS命令下CD 目錄)

運行

dex2jar.bat classes.dex

生成

classes.dex.dex2jar.jar

生成jar文件的截圖如下：

運行JD-GUI（jd-gui.exe），打開上面生成的jar包，即可看到源代碼了

HelloAndroid源碼（編譯前的apk源碼對照）如下：

二、反編譯apk生成程序的源代碼和圖片、XML配置、語言資源等文件

如果是漢化軟體，這將特別有用。首先還是下載工具，這次用到的是apktool

下載地址：http://code.google.com/p/android-apktool/downloads/list

下載：apktool1.4.1.tar.bz2 和 apktool-install-windows-r04-brut1.tar.bz2（兩個包都下載）

具體步驟：

將下載的兩個包解壓到同一個文件夾下，應該會有三個文件：aapt.exe，apktool.bat，apktool.jar

在命令行下定位到apktool.bat文件夾，輸入以下命令：apktool d C:\*.apk C:\*文件夾，如下圖：

命令行解釋：apktool d [apk文件 ] [輸出文件夾]

反編譯的文件如下（AndroidManifest.xml為例）：

特別注意：你要反編譯的文件一定要放在C盤的根目錄里（其實不用放在C盤根目錄也行）

例如：在D盤目錄D:\apktool1.4.1

cd /d D:\apktool1.4.1 //切換到D盤目錄，包含HelloAndroid.apk以及aapt.exe，apktool.bat，apktool.jar三個文件

apktool.bat d -f HelloAndroid.apk HelloAndroid // apktool反編譯命令，注意 d和
-f 的寫法

將反編譯完的文件重新打包成apk，很簡單，輸入apktool b c:\***文件夾（你編譯出來文件夾）即可，命令如下：這個主意你文件所在盤

打包apk後的文件在目錄C:\HelloAndroid下，生成了兩個文件夾：

build

dist

其中，打包生成的HelloAndroid.apk，在上面的dist文件夾下，Ok

最後，再介紹一款剛出來的反編譯工具 Androidfby ，它是一款對上述步驟進行了封裝的圖形界面工具，下載地址

但是，針對部分簽名的apk，無法實現反編譯，但本博客方法則仍然可以反編譯成功！僅供參考使用

另外，作為應用開發者，肯定不希望自己的代碼被反編譯的，下一遍博客將講述如何通過混淆代碼防止被別人反編譯

Android如何防止apk程序被反編譯

作為Android應用開發者，不得不面對一個尷尬的局面，就是自己辛辛苦苦開發的應用可以被別人很輕易的就反編譯出來。

Google似乎也發現了這個問題，從SDK2.3開始我們可以看到在android-sdk-windows\tools\下面多了一個proguard文件夾

proguard是一個java代碼混淆的工具，通過proguard，別人即使反編譯你的apk包，也只會看到一些讓人很難看懂的代碼，從而達到保護代碼的作用。

下面具體說一說怎麼樣讓SDK2.3下的proguard.cfg文件起作用，先來看看android-sdk-windows\tools\lib\proguard.cfg的內容：

[html] view
plainprint?

1. -optimizationpasses 5

2. -dontusemixedcaseclassnames

3. -

4. -dontpreverify

5. -verbose

6. -optimizations !code/simplification/arithmetic,!field/*,!class/merging/*

7.

8. -keep public class * extends android.app.Activity

9. -keep public class * extends android.app.Application

10. -keep public class * extends android.app.Service

11. -keep public class * extends android.content.BroadcastReceiver

12. -keep public class * extends android.content.ContentProvider

13. -keep public class * extends android.app.backup.BackupAgentHelper

14. -keep public class * extends android.preference.Preference

15. -keep public class com.android.vending.licensing.ILicensingService

16.

17. -keepclasseswithmembernames class * {

18. native <methods>;

19. }

20.

21. -keepclasseswithmembernames class * {

22. public <init>(android.content.Context, android.util.AttributeSet);

23. }

24.

25. -keepclasseswithmembernames class * {

26. public <init>(android.content.Context, android.util.AttributeSet, int);

27. }

28.

29. -keepclassmembers enum * {

30. public static **[] values();

31. public static ** valueOf(java.lang.String);

32. }

33.

34. -keep class * implements android.os.Parcelable {

35. public static final android.os.Parcelable$Creator *;

36. }

從腳本中可以看到，混淆中保留了繼承自Activity、Service、
Application、BroadcastReceiver、ContentProvider等基本組件以及
com.android.vending.licensing.ILicensingService，

並保留了所有的Native變數名及類名，所有類中部分以設定了固定參數格式的構造函數，枚舉等等。(詳細信息請參考<proguard_path>/examples中的例子及注釋。)

讓proguard.cfg起作用的做法很簡單，就是在eclipse自動生成的default.properties文件中加上一句「proguard.config=proguard.cfg」就可以了

完整的default.properties文件應該如下：

[html] view
plainprint?

1. # This file is automatically generated by Android Tools.

2. # Do not modify this file -- YOUR CHANGES WILL BE ERASED!

3. #

4. # This file must be checked in Version Control Systems.

5. #

6. # To customize properties used by the Ant build system use,

7. # "build.properties", and override values to adapt the script to your

8. # project structure.

9.

10. # Project target.

11. target=android-9

12. proguard.config=proguard.cfg

大功告成，正常的編譯簽名後就可以防止代碼被反編譯了。反編譯經過代碼混淆的apk得到的代碼應該類似於下面的效果，是很難看懂的：

如果您使用的是2.3之前的SDK版本也沒關系，把上面的proguard.cfg文件復制一份放到項目中，然後進行相同的操作即可

❹ 如何寫一個腳本，在手機上運行

第一種：破解apk，提取dex，反編譯jar，反混淆，瀏覽幾十個class文件尋找接單api，不停查找代碼然後自己再用java寫一個安卓應用後台運行
第二種：連點器

❺ app可以被反編譯到什麼程度

Android APK中的Java代碼可以被反編譯到什麼程度主要看APK的加密程度。

第一種情況：無混淆無加密無加殼。
直接利用Dex2jar和JD-GUI可把源碼從APK里摳出來，代碼邏輯清晰，基本上做到可復用，只是資源文件的引用需要計算一下。

第二種情況：混淆。
通常是利用Proguard做的防護。因為是對jar做的不可逆混淆（除非有mapping），因此不能還原成原來的代碼。但是代碼結構，代碼邏輯一致，只要花長時間對代碼進行梳理一樣可找准核心代碼，解密方法跟第一種一致。

第三種情況：加密。
這里以DexGuard為例。對於這種代碼加密的方法，在程序運行中必定會進行解密，只要抽出它解密的邏輯便可。PS：我自己做過DexGuard的解密，如果用Dex2jar反編譯看的話邏輯是不對的，一定要從Smali代碼看。後來發現網上已經有人做了。
解密的腳本：A look inside Dexguard

第四種情況：加殼。
這種情況跟第三種類似。無論你怎麼加殼，運行的時候必定是Dalvik可識別的Odex代碼，建議直接在內存里mp出來。這里推薦Xpose的ZjDroid。

加固可以在一定程度上保護自己核心代碼演算法,提高破解/盜版/二次打包的難度，緩解代碼注入/動態調試/內存注入攻擊等。
目前市面上有很多第三方加固的平台， 如果新應用發布前需要掃描或者加固的話，可以先試試免費的，例如騰訊御安全，建議自己先去掃描測試下。

❻ 如何防止unity3d代碼被反編譯

防止Unity3D代碼被反編譯是手游安全中常見的破解風險。Unity的破解風險主要體現在Unity mono腳本解密、Unity il2cpp腳本解析、Assetbundle資源篡改三項。mono腳本文件的二進制形式及源碼轉換圖示，展示了如何對mono腳本進行解密。Il2cpp腳本解析則需要使用Il2CppDumper工具，解析後能獲得類名、函數名以及對應偏移信息。盡管iOS中還無法解析為源碼，但Android的有效腳本加密對於防止破解尤為重要。Assetbundle資源篡改，如修改材質屬性，可實現透視效果，同時還有資源被競品盜取、分析的風險。存檔數據被修改也是安全問題，如果數據不進行服務端校驗或為單機游戲，游戲屬性修改風險巨大。保護Unity安全時，自研保護系統面臨高成本、兼容性問題、對抗破解的持續升級和第三方服務兼容性挑戰。網易雲易盾提供了Unity mono DLL腳本加密、IL2CPP加密、Assetbundle加密等解決方案，通過修改或HOOK mono_image_open_from_data_with_name函數，實現對CSharp DLL腳本的加密，以防止其被解密。Unity mono DLL腳本加密經歷了從直接文件加密到抹掉PE頭、再到方法級加密的三代技術演進。IL2CPP加密則需結合global-metadata.dat文件內的符號信息進行解析，通過SO加殼保護libil2cpp.so來實現。Assetbundle加密後，Unity Studio無法解析資源。網易易盾保護方案特點包括純Native保護、對引擎SO做加殼、兼容性和穩定性高、性能影響小，支持多平台加固。在選擇保護方案時，應考慮DEX加殼的兼容性和安全性問題，而網易易盾提供的純Native保護方案為手游提供了一種更加安全和兼容性強的解決方案。