摘要：為了防止這種現(xiàn)象，我們可以對(duì)字節(jié)碼進(jìn)行混淆。動(dòng)態(tài)鏈接庫(kù)是目標(biāo)文件的集合，目標(biāo)文件在動(dòng)態(tài)鏈接庫(kù)中的組織方式是按照特殊方式形成的。

一、已知防護(hù)策略
1.不可或缺的混淆

Java 是一種跨平臺(tái)、解釋型語(yǔ)言，Java 源代碼編譯成的class文件中有大量包含語(yǔ)義的變量名、方法名的信息，很容易被反編譯為Java 源代碼。為了防止這種現(xiàn)象，我們可以對(duì)Java字節(jié)碼進(jìn)行混淆?；煜粌H能將代碼中的類名、字段、方法名變?yōu)闊o(wú)意義的名稱，保護(hù)代碼，也由于移除無(wú)用的類、方法，并使用簡(jiǎn)短名稱對(duì)類、字段、方法進(jìn)行重命名縮小了程序的大小。

ProGuard由shrink、optimize、obfuscate和preverify四個(gè)步驟組成，每個(gè)步驟都是可選的，需要哪些步驟都可以在腳本中配置。 參見ProGuard官方介紹。

壓縮(Shrink):偵測(cè)并移除代碼中無(wú)用的類、字段、方法、和特性(Attribute)。
優(yōu)化(Optimize):分析和優(yōu)化字節(jié)碼。
混淆(Obfuscate): 使用a、b、c、d這樣簡(jiǎn)短而無(wú)意義的名稱，對(duì)類、字段和方法進(jìn)行重命名。

上面三個(gè)步驟使代碼size更小，更高效，也更難被逆向工程。

預(yù)檢(Preveirfy): 在java平臺(tái)上對(duì)處理后的代碼進(jìn)行預(yù)檢。

一般來(lái)說(shuō)優(yōu)化和預(yù)檢選項(xiàng)在Android中是關(guān)閉的，腳本如下：
-dontoptimize 表示不進(jìn)行優(yōu)化，建議使用此選項(xiàng)，因?yàn)楦鶕?jù)proguard-android-optimize.txt中的描述，優(yōu)化可能會(huì)造成一些潛在風(fēng)險(xiǎn)，不能保證在所有版本的Dalvik上都正常運(yùn)行。
-dontpreverify 表示不進(jìn)行預(yù)校驗(yàn)。這個(gè)預(yù)校驗(yàn)是作用在Java平臺(tái)上的，Android平臺(tái)上不需要這項(xiàng)功能，去掉之后還可以加快混淆速度。 (在安裝apk過(guò)程中系統(tǒng)會(huì)對(duì)dex校驗(yàn)及優(yōu)化成odex) 作為防護(hù)來(lái)說(shuō)對(duì)于混淆的需求就是Obfuscate，增加閱讀代碼的難度。

2.簽名校驗(yàn)
校驗(yàn)各個(gè)文件的信息，比如微信的dex文件校驗(yàn)，阿里聚安全的簽名文件校驗(yàn)等高強(qiáng)度操作。

第一：直接在本地做防護(hù)，如果發(fā)現(xiàn)簽名不一致直接退出應(yīng)用
第二：將簽名信息攜帶請(qǐng)求參數(shù)中參與加密，服務(wù)端進(jìn)行簽名校驗(yàn)，失敗就返回錯(cuò)誤數(shù)據(jù)即可

Android的簽名機(jī)制可以有效防止應(yīng)用二次簽名后不能覆蓋安裝，具體原理這里不分析了，但也導(dǎo)致安裝了二次簽名的apk,無(wú)法覆蓋安裝正常簽名的apk，所以在很容易被二次簽名的防護(hù)基礎(chǔ)上進(jìn)行簽名校驗(yàn)是有必要的，當(dāng)然如果很難被反編譯攻破就可以酌情考慮了。

3、反調(diào)試異常檢測(cè) 1）so跟蹤調(diào)試是基于進(jìn)程的注入技術(shù)，然后使用Linux中的ptrace機(jī)制，進(jìn)行調(diào)試目標(biāo)進(jìn)程的ptrace提供了一種使父進(jìn)程得以監(jiān)視和控制子進(jìn)程的方式，它還能夠改變子進(jìn)程中的寄存器和內(nèi)核映像，因而可以實(shí)現(xiàn)斷點(diǎn)調(diào)試和系統(tǒng)調(diào)用的跟蹤

ptrace機(jī)制有一個(gè)特點(diǎn)，就是如果一個(gè)進(jìn)程被調(diào)試了，在他進(jìn)程的status文件中有一個(gè)字段TracerPid會(huì)記錄調(diào)試者的進(jìn)程id值，可以選擇兩種方式：
1.輪訓(xùn)查看文件：/proc/[myPid]/status，讀取TracerPid字段的值，發(fā)現(xiàn)大于0，就立馬退出程序
2.一般一個(gè)進(jìn)程只能被附加一次，我們?cè)趐ojie調(diào)試的時(shí)候都會(huì)附加需要調(diào)試應(yīng)用的進(jìn)程，如果我們先占坑，父進(jìn)程附加自己，那么后面在附加調(diào)試就會(huì)失敗

調(diào)試狀態(tài)檢查
1.檢查應(yīng)用是否屬于debug模式 直接調(diào)用Android中的flag屬性：ApplicationInfo.FLAG_DEBUGGABLE，判斷是否屬于debug模式，為了防止現(xiàn)在有人為了調(diào)試應(yīng)用將應(yīng)用反編譯在AndroidManifest.xml中添加：android:debuggable屬性值，將其設(shè)置true。然后就可以進(jìn)行調(diào)試。
2.檢查應(yīng)用是否處于調(diào)試狀態(tài) 借助系統(tǒng)的一個(gè)api來(lái)進(jìn)行判斷：android.os.Debug.isDebuggerConnected()；這個(gè)就是判斷當(dāng)前應(yīng)用有沒(méi)有被調(diào)試

3.循環(huán)檢查端口 查看設(shè)備的tcp端口使用情況 cat /proc/net/tcp 比如Frida框架，他的端口號(hào)是27042和27043，以及進(jìn)程名是frida-server

4、加固方案 加固的基本步驟如下：
從App原始apk文件里獲取到原始dex文件對(duì)原始dex文件進(jìn)行加密，并將加密后的dex文件和相關(guān)的存放到assert目錄用脫殼dex文件替換原始apk文件里的dex文件；脫殼dex文件的作用主要有兩個(gè)，一個(gè)是解密加密后的dex文件；二是基于dexclassloader動(dòng)態(tài)加載解密后的dex文件因?yàn)樵糰pk文件已經(jīng)被修改，所以需要?jiǎng)h除原始apk的簽名信息，即刪除META-INF目錄下的.RSA、.SF 和MANIFEST.MF文件生成加固后的apk文件對(duì)加固后的apk文件進(jìn)行簽名，apk加固完成。
dex加固主要是防止被靜態(tài)反編譯，進(jìn)而獲取源碼并修改

除了以上業(yè)務(wù)相關(guān)性弱的防護(hù)方案，還有防被抓包，防被hook等和業(yè)務(wù)密切相關(guān)的防護(hù)方案，如傳輸數(shù)據(jù)加密，防作弊等策略。

以上每個(gè)防護(hù)策略都有對(duì)應(yīng)的應(yīng)對(duì)之道，當(dāng)然攻克了不代表不能防，防護(hù)只是增加攻克的難度和時(shí)間，攻防沒(méi)有永遠(yuǎn)的勝利方，有人攻就有人防，防護(hù)策略也在不斷的升級(jí)更新?lián)Q代。

要深入理解Android安全防護(hù)，就必須了解Android應(yīng)用的結(jié)構(gòu)。

二、APK(Android PacKage)結(jié)構(gòu)

assets目錄： 用于存放需要打包到APK中的靜態(tài)文件，和res的不同點(diǎn)在于，assets目錄支持任意深度的子目錄，用戶可以根據(jù)自己的需求任意部署文件夾架構(gòu)
lib目錄： 程序依賴的native庫(kù)（so庫(kù)）
META-INF目錄： 存放應(yīng)用程序簽名和證書的目錄，包含的文件有CERT.RSA，CERT.DSA，CERT.SF和MANIFEST.MF，其中CERT.RSA是開發(fā)者利用私鑰對(duì)APK進(jìn)行簽名的簽名文件，CERT.SF，MANIFEST.MF記錄了文件中文件的SHA-1哈希值

res目錄： 存放應(yīng)用程序的資源，存在這個(gè)文件夾下的所有文件都會(huì)映射到Android工程的.R文件中，生成對(duì)應(yīng)的ID，res文件夾下可以包含多個(gè)文件夾，其中anim存放動(dòng)畫文件；drawable目錄存放圖像資源；layout目錄存放布局文件；values目錄存放一些特征值，colors.xml存放color顏色值，dimens.xml定義尺寸值，string.xml定義字符串的值，styles.xml定義樣式對(duì)象；xml文件夾存放任意xml文件，在運(yùn)行時(shí)可以通過(guò)Resources.getXML()讀??；raw是可以直接復(fù)制到設(shè)備中的任意文件，他們無(wú)需編譯。
resources.arsc： 資源配置文件，用來(lái)記錄資源文件和資源ID之間的映射關(guān)系，用來(lái)根據(jù)資源ID尋找資源
AndroidManifest.xml： 應(yīng)用程序的配置文件,程序打包時(shí)，會(huì)把AndroidManifest.xml進(jìn)行簡(jiǎn)單的編譯，便于Android系統(tǒng)識(shí)別，編譯之后的格式是AXML格式。
classes.dex： dex可執(zhí)行文件,傳統(tǒng)的Java程序，首先先把Java文件編譯成class文件，字節(jié)碼都保存在了class文件中，Java虛擬機(jī)可以通過(guò)解釋執(zhí)行這些class文件。而Dalvik虛擬機(jī)是在Java虛擬機(jī)進(jìn)行了優(yōu)化，執(zhí)行的是Dalvik字節(jié)碼，而這些Dalvik字節(jié)碼是由Java字節(jié)碼轉(zhuǎn)換而來(lái)，一般情況下，Android應(yīng)用在打包時(shí)通過(guò)AndroidSDK中的dx工具將Java字節(jié)碼轉(zhuǎn)換為Dalvik字節(jié)碼。dx工具可以對(duì)多個(gè)class文件進(jìn)行合并，重組，優(yōu)化，可以達(dá)到減小體積，縮短運(yùn)行時(shí)間的目的。

對(duì)于逆向首入門檻就是dex，了解dex的數(shù)據(jù)結(jié)構(gòu)對(duì)防護(hù)和逆向都是極其重要的，dex文件結(jié)構(gòu)分析文章非常多，這里不多贅述，不了解的先去了解下。

對(duì)于Android防護(hù)目前流行的最后方案就是加固，某些應(yīng)用市場(chǎng)已經(jīng)把加固和上架進(jìn)行了綁定，說(shuō)明加固的逆向難度公認(rèn)度是很高的。

上面介紹了加固的基本步驟，市面上的加固方案都大同小異，最核心的部分就是對(duì)apk/dex進(jìn)行加密-解析-動(dòng)態(tài)加載，對(duì)dex加密各有各的方式和算法，了解dex結(jié)構(gòu)和動(dòng)態(tài)加載之后就可以對(duì)不同加固方案進(jìn)行具體分析了，不過(guò)分析大廠的apk之后發(fā)現(xiàn)都沒(méi)有對(duì)dex進(jìn)行加固就令人深思，也許在客戶端的防護(hù)只是門檻，服務(wù)端的防護(hù)及防作弊才是終極防護(hù)策略，而加固會(huì)增加崩潰的概率，作為大流量的app來(lái)說(shuō)萬(wàn)分之一的概率也是很高的，而對(duì)dex加固的安全性并不是最高的，所以放棄對(duì)dex加固也是有跡可循的。

作為Android應(yīng)用開發(fā)者來(lái)說(shuō)，navite層的代碼具有更高的挑戰(zhàn)性，大部分Android開發(fā)者并不熟悉c/c++開發(fā)，所以so的加固應(yīng)運(yùn)而生。

動(dòng)態(tài)鏈接庫(kù)so： 動(dòng)態(tài)鏈接庫(kù)是程序運(yùn)行時(shí)加載的庫(kù)，當(dāng)動(dòng)態(tài)鏈接庫(kù)正確安裝后，所有的程序都可以使用動(dòng)態(tài)庫(kù)來(lái)運(yùn)行程序。動(dòng)態(tài)鏈接庫(kù)是目標(biāo)文件的集合，目標(biāo)文件在動(dòng)態(tài)鏈接庫(kù)中的組織方式是按照特殊方式形成的。庫(kù)中函數(shù)和變量的地址是相對(duì)地址，不是絕對(duì)地址，其真實(shí)地址在調(diào)用動(dòng)態(tài)庫(kù)的程序加載時(shí)形成。 so文件是基于ELF(Executable and Linking Format)文件格式。而so是共享目標(biāo)文件，所以要想對(duì)so文件進(jìn)行加密就必須了解

ELF文件格式： 可執(zhí)行鏈接格式(Executable and Linking Format)最初是由 UNIX 系統(tǒng)實(shí)驗(yàn)室(UNIX System Laboratories，USL)開發(fā)并發(fā)布的，作為應(yīng)用程序二進(jìn)制接口(Application Binary Interface，ABI)的一部分。工具接口標(biāo)準(zhǔn)(Tool Interface Standards，TIS)委員會(huì)將還在發(fā)展的 ELF 標(biāo)準(zhǔn)選作為一種可移植的目標(biāo)文件格式，可以在 32 位 Intel 體系結(jié)構(gòu)上的很多操作系統(tǒng)中使用。

目標(biāo)文件有三種類型: 可重定位文件(Relocatable File) .o)包含適合于與其他目標(biāo)文件鏈接來(lái)創(chuàng)建可執(zhí)行文件或者共享目標(biāo)文件的代碼和數(shù)據(jù)。 可執(zhí)行文件(Executable File) .exe) 包含適合于執(zhí)行的一個(gè)程序，此文件規(guī)定了exec() 如何創(chuàng)建一個(gè)程序的進(jìn)程映像。 共享目標(biāo)文件(Shared Object File) .so) 包含可在兩種上下文中鏈接的代碼和數(shù)據(jù)。首先鏈接編輯器可以將它和其它可重定位

文件和共享目標(biāo)文件一起處理， 生成另外一個(gè)目標(biāo)文件。其次動(dòng)態(tài)鏈接器(Dynamic Linker)可能將它與某 個(gè)可執(zhí)行文件以及其它共享目標(biāo)一起組合，創(chuàng)建進(jìn)程映像。

目標(biāo)文件全部是程序的二進(jìn)制表示，目的是直接在某種處理器上直接執(zhí)行。

通過(guò)對(duì)so中的section和函數(shù)進(jìn)行加密來(lái)加固對(duì)逆向的難度會(huì)提高很多，雖然對(duì)于了解so的人來(lái)說(shuō)并不是難事，比如動(dòng)態(tài)調(diào)試一下，或者dump出內(nèi)存中運(yùn)行的dex，所以沒(méi)有絕對(duì)的安全，只有相對(duì)的攻防。