分析APK文件
要分析APK文件，首先要了解APK打包過程
- 打包資源文件(aapt)
- 檢查Manifest合法性
- 將res和asserts目錄的資源打包加密，生成resources.arsc
- 生成加密后的Manifest
- 將加密后的Manifest和resources.arsc打包壓縮成resource.ap_
- 生成R.java
- 處理aidl文件，生成相應(yīng)java文件
- javac編譯工程源代碼，生成相應(yīng)class文件
- 轉(zhuǎn)換所有class文件，生成classes.dex文件
- 將依賴jar和class文件轉(zhuǎn)換為dex文件
- 打包生成apk
- 將dex、resource.ap_以及so文件打包成apk
- 對apk文件進(jìn)行簽名
- 可在build.gradle中指定簽名文件
- apk文件對齊
- 將apk包進(jìn)行對齊處理，使apk包中的所有資源文件距離文件起始偏移為4字節(jié)整數(shù)倍，這樣通過內(nèi)存映射訪問apk文件時速度會更快
打包過程就是一個編譯、加密和打包的過程，因此逆向工程就是反編譯、解密和解壓了。
解壓特別容易，將apk文件后綴改為rar，用解壓工具就能將apk文件解壓了。下圖是微信解壓的結(jié)果
不同的apk文件解壓后的內(nèi)容不盡相同，但分析的思路都是一樣的
- 一定包含加密后的Manifest文件
- 一定包含classes.dex文件。為了突破65536個方法數(shù)的限制，所以可能會有多個classes.dex。
- 如果項(xiàng)目中使用了so庫，一般會在lib文件夾下
- 資源文件的中加密xml，可能在r文件夾，res文件夾下
使用了加殼措施的apk，由于加殼方案不一樣，所以資源文件和dex文件的處理會有差異，這里不做深入討論。
dex2jar
如果只是要了解別人的實(shí)現(xiàn)方案，那么解壓后的classes.dex通過反編譯即可得到j(luò)ar包，再通過JD-GUI就可以看到大部分的源碼了。
這里不贅述怎么使用dex2jar和JD-GUI，下圖微信反編譯后的結(jié)果
- 由于微信方法數(shù)較多，所以進(jìn)行了分包，需要使用2.1以上版本的dex2jar，直接將apk文件作為輸入，就可以導(dǎo)出jar包了。
- Activity是沒有完全混淆，所以可讀性還比較高。其他代碼讀起來會比較困難。
apktools
如需解密資源文件就要用到apktool。我們會用到的apktools的功能有：
- 反編譯資源文件和classes.dex
- 將反編譯的資源文件重新打包為apk
使用命令apktool d xxx.apk
可以看到使用apktools反編譯的結(jié)果和直接解壓和類似，主要的不同在于：
- 包括Manifest和資源文件中的xml都已經(jīng)解密了
- class文件變成了smali文件夾，且里面的smali文件和反編譯的jar包的類基本對應(yīng)
了解Smali文件和語法
Smali是Dalvik的寄存器語言，語法比較簡單，只是比較繞。下面以一個簡單的Activity來了解Smali語法。
package com.netease.smali;
import android.app.Activity;
import android.os.Bundle;
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
}
}
.class public Lcom/netease/smali/MainActivity;
.super Landroid/app/Activity;
.source "MainActivity.java"
# direct methods
.method public constructor <init>()V
.locals 0
.prologue
.line 14
invoke-direct {p0}, Landroid/app/Activity;-><init>()V
return-void
.end method
# virtual methods
.method protected onCreate(Landroid/os/Bundle;)V
.locals 1
.parameter "savedInstanceState"
.prologue
.line 18
invoke-super {p0, p1}, Landroid/app/Activity;->onCreate(Landroid/os/Bundle;)V
.line 19
const/high16 v0, 0x7f03
invoke-virtual {p0, v0}, Lcom/fusijie/helloworld/MainActivity;->setContentView(I)V
.line 20
return-void
.end method
- 前三行指明了類名，父類名，和源文件名。
- 類名以“L”開頭相信熟悉Jni的童鞋都比較清楚。
- “#”是smali中的注釋。
- “.method”和“.end method”類似于Java中的大括號，包含了方法的實(shí)現(xiàn)代碼段。
- 方法的括號后面指明了返回類型，這同樣類似與Jni的調(diào)用。
- “.locals”指明了這個方法用到的寄存器數(shù)量，當(dāng)然寄存器可以重復(fù)利用，從“V0”起算。
- “.prologue”指定了代碼開始處。
- “.line”表明這是在java源碼中的第幾行，其實(shí)這個值無所謂是多少，可以任意修改，主要用于調(diào)試。
- “invoke-direct”這是對方法的調(diào)用，可以看到這里調(diào)用了是Android.app.Activity的init方法，這在java里是隱式調(diào)用的。
- “return-void”表明了返回類型，這和java不一樣，即使沒有返回值，也需要這樣寫。
- 接下來是onCreate方法，“.parameter”指明了參數(shù)名，但是一般沒有用，需要注意的是p0代表的是this，p1開始代表函數(shù)參數(shù)，靜態(tài)函數(shù)沒有this，所以從p0開始就代表參數(shù)。
- 在實(shí)現(xiàn)里先是調(diào)用了父類的方法，然后再調(diào)用setContentView，注意這里給了一個傳參。整形的傳參，這個值是先賦給寄存器v0，然后再調(diào)用的使用傳遞進(jìn)去的。smali中都是這么使用，所有的值必須通過寄存器來中轉(zhuǎn)。這點(diǎn)和匯編很像。
詳細(xì)的Smali語法可以參考進(jìn)入Android Dalvik虛擬機(jī)之Dalvik指令集
修改Smali并打包
了解Smali語法后就可以嘗試修改源碼了。
例如，我們需要在Activity中顯示一個Toast。通過Java，只需要在OnCreate中增加一行代碼
Toast.makeText(this, "Hello, Smali", Toast.LENGTH_LONG).show();
翻譯為Smali就是：
.line xx
const-string v0, "Hello, Smali"
const/4 v1, 0x1
invoke-static {p0, v0, v1}, Landroid/widget/Toast;->makeText(Landroid/content/Context;Ljava/lang/CharSequence;I)Landroid/widget/Toast;
move-result-object v0
invoke-virtual {v0}, Landroid/widget/Toast;->show()V
除了這些，還有兩個地方需要修改：
- “.locals 1”，因?yàn)楸緛碇挥玫搅藇0，現(xiàn)在多用了一個v1，所以改為“.locals 2”。
- “.line xx” xx隨意改為一個不重復(fù)的值即可。
最后通過apktool b即可將項(xiàng)目重新打包，再經(jīng)過簽名就能運(yùn)行了。
應(yīng)用加殼
有反編譯二次打包的黑科技，就有apk加殼的保護(hù)方式。大部分經(jīng)過加殼保護(hù)的apk，已經(jīng)無法通過上述方案進(jìn)行二次打包了。
應(yīng)用加殼的基本原理是
- 對原始APK進(jìn)行反編譯，并記錄其簽名信息
- 將dex文件加密并放入assets文件夾中
- 使用自定義的Application接管apk原本的Application
- Applicaiton啟動時首先進(jìn)行簽名驗(yàn)證
- 再解密dex并動態(tài)加載class文件
為了破解這類加殼應(yīng)用，又出現(xiàn)了ZjDroid--脫殼神器。
這類脫殼工具都是針對特定的加殼方案去做逆向工程，針對“愛加密”的加殼方案，也有文章專門進(jìn)行分析：Apk脫殼圣戰(zhàn)之---脫掉“愛加密”的殼
