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

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

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

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

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

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

預(yù)檢(Preveirfy): 在java平臺上對處理后的代碼進行預(yù)檢。

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

2.簽名校驗
校驗各個文件的信息，比如微信的dex文件校驗，阿里聚安全的簽名文件校驗等高強度操作。

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

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

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

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

調(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。然后就可以進行調(diào)試。
2.檢查應(yīng)用是否處于調(diào)試狀態(tài) 借助系統(tǒng)的一個api來進行判斷：android.os.Debug.isDebuggerConnected()；這個就是判斷當(dāng)前應(yīng)用有沒有被調(diào)試

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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