arm指令反編譯

1. 如何反編譯 android 中 /data/dalvik-cache/arm 下的文件

所有的 apk 內包含一個 classes.dex 文件。在 Dalvik上，apk包里的 dex文件在安裝的時候會通過 dexopt 轉化成另一個格式，叫odex（Opitimized dex），然後存在 /data/dalvik-cache裡面，如：

/data/dalvik-cache/data@[email protected]@classes.dex
雖然文件後綴還是 .dex，但是這個dex和apk內的那個已經不一樣了。這個文件是針對當前機器的硬體對 dex 文件進行了定製化，也就是說把這個放到別的設備上，不一定能運行。

PS: 在要編譯 rom 的時候，如果參數加上 "WITH_DEXPREOPT=true"，會在 /system/app/ 下同時生成 .apk 和 .odex 文件（注意，這里後綴又用的 .odex，但實際上和系統在 /data/dalvik-cache/ 下的 .dex文件是一樣的）

ART

在 ART上，apk 包里的 dex文件在安裝的時候通過 dex2oat，也會生成一個後綴為 .dex 的文件，放在 /data/dalvik-cache中，如：

/data/dalvik-cache/arm/system@app@[email protected]@classes.dex
/data/dalvik-cache/arm64/system@vendor@app@[email protected]@classes.dex
這個文件後綴叫 .dex ，但是這個文件又不一樣了，這個既不是 dex 也不是 odex，用 dex2jar 的無法進行反編譯的。文件格式也完全不同，因為這其實就是一個實打實的 elf文件，這個文件已經可以直接在機器上運行了。

為何 pm.jar 是空的？

首先來了解一下 ROM 的編譯選項，看一下編譯的時候能做什麼事情， 大致了解就行了 。

編譯選項

WITH_DEXPREOPT

使能編譯時生成 OAT，避免第一次開機時編譯耗時，但會增大 system分區的空間消耗

DONT_DEXPREOPT_PREBUILTS

使能後，將不會對 Android.mk中包含了 include $(BUILD_PREBUILT)的 Apk進行 oat，例如 Gmail，它很可能會在後期通過商店自行升級，而升級後系統中的 oat文件則沒有意義了，但又無法刪除，會造成空間的浪費（oat比dex文件要大）

WITH_DEXPREOPT_BOOT_IMG_ONLY

僅僅針對 boot.img進行oat優化（boot.img中包含 boot.art和 boot.oat）

LOCAL_DEX_PREOPT ture|false|nostripping

可用於各個 Android.mk，對每個 package進行單獨配置，當設置為 true時，dex文件將會從 apk中剔除，如果不想剔除可使用 nostripping WPRODUCT _DEX PREOPT_*

WPRODUCT__DEX_PREOPT_*

PRODUCT_DEX_PREOPT_BOOT_FLAGS

這里的參數將會傳至 dex2oat，控制 boot.img的編譯優化行為。

PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

控制除 boot.img 外，其他（如 jar, apk）的 OAT編譯行為 例如：

PRODUCT_DEX_PREOPT_DEFAULT_FLAGS := --compiler- filter=interpret-only
$(call add-proct-dex-preopt-mole- config,services,--compiler-filter=space)
WITH_DEXPREOPT_PIC ture|false

使能 position-independent code，這樣在dex2oat編譯生成的 odex文件在運行時將不必再從 /system 下拷貝到 /data/dalvik-cache/ 目錄下， 可以節省 /data 空間

WITH_ART_SMALL_MODE true|false

設置為 true 時，將只編譯處於 boot classpath 里的類，其他的均不編譯，這樣既能加快第一次開機時間，因為大部分必要的類已經編譯過了； 同時也能節省不少空間，因為 APP 都未進行編譯。缺點是可能損失一性能，這可能要平時覺察不出，但在跑分軟體上會有所體現

編譯選項的經典配置

為了提高第一次開機速度，WITH_DEXPREOPT是必須使能的，這樣則在編譯階段會完成 dex2oat的操作，避免在開機時間去做這個轉碼，節省了開機時間（6min以上縮短2min內）。

但會引起一個缺點，那就是 apk中還是包含了 class.dex（dexopt生成的），同時在對應的apk文件夾中又生成了已經轉碼成oat的 class.odex（dex2oat生成的），相當於這部分重復，造成了大量的空間浪費。

為了把 apk包里的 class.dex去除，節省空間，可以打開 DEX PREOPT DEFAULT := ture。

然而，這樣開機速度是快了，而且節省了不少system空間，但開機後，我們會發現即使在 system中已經存在 class.odex的 apk，第一次開機後還是會在 /data下面生成 class.odex，如data/dalvik-cache/arm64/system@app@[email protected]@classes.dex，這是何解？原來 Google為了提高安全性，在每一台機器開機時都會在之前的機器碼加一個隨機的偏移量，這個偏移量是隨機的，每台機器都不相同，而 data分區下的這些文件就是從 system下的 class.odex加上偏移而來。

2. arm轉高級語言

ARM是一種處理器架構，它沒有直接對應高級編程語言的轉換方式。通常來說，我們需要通過編寫匯編語閉仿言代碼將ARM指令轉換成高級編程語言的代碼。

不過，可以使用ARM指令集架構的編譯器生成高級編沒巧程語言代碼，例如C語言。這些編譯器可以將C語言代碼編譯成ARM匯編語言代碼。然後，轎察纖通過稍加修改和調試這些生成的匯編代碼，可以將它轉換成高級編程語言的代碼。但是這種方法還是需要具備一定的

3. 通過arm指令的匯編語言,轉換為c/c++的學習資料

哈！你這匯編轉C可是不好直接轉的了！只有你按它的啟襲思路自己重編的了，因C語言是一種中級悄虛兄語言的，各設計（出版）家的不同或就是同家的只因版本的不同它本身就會譽神不同的，所有沒有定式好轉的。反過來C轉匯編那可是好轉的了，因匯編是死的了，生產廠家規定好的了，誰轉它都只有按它的要求轉的。

4. anzhuo應用程序怎麼反編譯

讓我們先來認識下APK文件. Android的應用程序包為擴展名為.apk文件, 無論你是從手機市場里下載, 還是電腦中下載. 都是這類APK文件. APK是AndroidPackage的縮寫，即Android安裝包(apk)。APK是類似Symbian Sis或Sisx的文件格式。通過將APK文件直接傳到Android模擬器或Android手機中執行即可安裝。apk文件和sis一樣，把android sdk編譯的工程打包成一個安裝程序文件，格式為apk。 APK文件其實是zip格式，但後綴名被修改為apk，通過UnZip解壓後，可以看到Dex文件，Dex是Dalvik VM executes的全稱，即Android Dalvik執行程序，並非java ME的位元組碼而是Dalvik位元組碼。Android在運行一個程序時首先需要UnZip，然後類似Symbian那樣直接，和Windows Mobile中的PE文件有區別.

android

一個APK文件解壓開通常有這樣的文件夾:

META-INF 目錄:

MANIFEST.MF: manifest文件

CERT.RSA: 應用程序證書

CERT.SF: SHA-1資源簽名列表. 例如:

Signature-Version: 1.0

Created-By: 1.0 (Android)

SHA1-Digest-Manifest: wxqnEAI0UA5nO5QJ8CGMwjkGGWE=

...

Name: res/layout/exchange_component_back_bottom.xml

SHA1-Digest: eACjMjESj7Zkf0cBFTZ0nqWrt7w=

...

Name: res/drawable-hdpi/icon.png

SHA1-Digest: DGEqylP8W0n0iV/ZzBx3MW0WGCA=

lib: 這個目錄包含某些特定編譯代碼, 這個文件夾分成下面這些

armeabi: 只基於所有ARM處理器的編譯代碼.

armeabi-v7a: 所有ARMv7處理器的編譯代碼

x86: 僅針對x86處理器的編譯代碼

mips: 為MIPS處理器的編譯代碼

res: 包含資源的目錄不編譯到資源文件,看下面:

assets: 包含應用程序的資產，可以通過AssetManager進行檢索.

AndroidManifest.xml: 包含應用程序的元數據文件，描述名稱、版本、訪問許可權、引用應用程序的庫文件。此文件在Android二進制格式, 可被工具轉化為可讀的純文本XML工具，如 AXMLPrinter2，apktool，或Androguard。設置，可以通過AssetManager進行檢索

classes.dex: Dalvik位元組碼

resources.arsc : 一個包含預編譯資源文件,如二進制的XML.

有兩種方法反編譯APK, 如果是為了漢化程序, 可以使用apktool:

安裝過程

1.下載apktool1.5.2.tar.bz2和apktool-install-windows-r05-brut1.tar.bz2

2.把兩個文件都解壓放在同一個目錄，共三個文件

aapt.exe

apktool.bat

apktool.jar用於解包，apktool.jar和aapt.exe聯合用於打包。

在命令行執行:

apktool d d:xxx.apk d:xxx

xxx 為你的輸出目錄, 然後你就可以看一些xml的資源文件, 以及Smali文件. 如下圖某APK文件反編譯輸出目錄:

由此可見,Android應用程序反編譯並不難, 加密與解密的斗爭一直會持續.

5. 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!

6. ARM 偽指令LDR.W的作用.

可能是立即數，因為arm裡面不能直接表示所有立即數，所以編譯器會把某些常量放到內存，在運行時載入進來

7. 能不能把arm的hex文件反編譯成源碼

反編譯出來是匯編語言，不是高級語言，要有點功底才能看得懂

8. arm64和xavier的不同

ARM64是ARM中64位體系結構，x64是x86系列中的64位體系。ARM屬於精簡指令集體系，匯編指令比較簡單。x86屬於復雜指令集體系，匯編指令較多。屬於兩種不同的體系。
從Win10操作系統入手可以做個對比，win10arm64跟win1064區別有下面三點：
一、應用不同
1、win10arm64隻能運行ARM64應用，無法運行x64應用
2、win1064既可以運版行運行x64應用，也可以運行ARM64應用
二、編譯不同
1、win10arm64允許開發者編譯和反編譯ARM64應用。
2、win1064不允許開發者編譯和反編譯x64應用，但可以編譯和反編譯ARM64應用。
三、電腦不同
1、win10arm64是針對使用高通ARM晶元的權電腦。
2、win1064是針對使用微軟普通晶元的電腦。
ARM64是專門給新出的高通筆記本准備的，也可以安裝在微軟的Lumia950XL手機上；win1064是一般的X64電腦安裝的，兩者互不通用。