Android防禦掃盲篇

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

Java 是一種跨平臺、解釋型語言，Java 源代碼編譯成的class文件中有大量包含語義的變量名、方法名的信息，很容易被反編譯爲Java 源代碼。爲了防止這種現象，咱們能夠對Java字節碼進行混淆。混淆不只能將代碼中的類名、字段、方法名變爲無心義的名稱，保護代碼，也因爲移除無用的類、方法，並使用簡短名稱對類、字段、方法進行重命名縮小了程序的大小。

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

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

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

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

通常來講優化和預檢選項在Android中是關閉的，腳本以下： -dontoptimize 表示不進行優化，建議使用此選項，由於根據proguard-android-optimize.txt中的描述，優化可能會形成一些潛在風險，不能保證在全部版本的Dalvik上都正常運行。 -dontpreverify 表示不進行預校驗。這個預校驗是做用在Java平臺上的，Android平臺上不須要這項功能，去掉以後還能夠加快混淆速度。 (在安裝apk過程當中系統會對dex校驗及優化成odex) 做爲防禦來講對於混淆的需求就是Obfuscate，增長閱讀代碼的難度。

2.簽名校驗

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

第一：直接在本地作防禦，若是發現簽名不一致直接退出應用 第二：將簽名信息攜帶請求參數中參與加密，服務端進行簽名校驗，失敗就返回錯誤數據便可

Android的簽名機制能夠有效防止應用二次簽名後不能覆蓋安裝，具體原理這裏不分析了，但也致使安裝了二次簽名的apk,沒法覆蓋安裝正常簽名的apk，因此在很容易被二次簽名的防禦基礎上進行簽名校驗是有必要的，固然若是很難被反編譯攻破就能夠酌情考慮了。

三、反調試異常檢測 1）so跟蹤調試是基於進程的注入技術，而後使用Linux中的ptrace機制，進行調試目標進程的ptrace提供了一種使父進程得以監視和控制子進程的方式，它還可以改變子進程中的寄存器和內核映像，於是能夠實現斷點調試和系統調用的跟蹤

ptrace機制有一個特色，就是若是一個進程被調試了，在他進程的status文件中有一個字段TracerPid會記錄調試者的進程id值，能夠選擇兩種方式： 1.輪訓查看文件：/proc/[myPid]/status，讀取TracerPid字段的值，發現大於0，就立馬退出程序 2.通常一個進程只能被附加一次，咱們在pojie調試的時候都會附加須要調試應用的進程，若是咱們先佔坑，父進程附加本身，那麼後面在附加調試就會失敗

2. 調試狀態檢查 1.檢查應用是否屬於debug模式 直接調用Android中的flag屬性：ApplicationInfo.FLAG_DEBUGGABLE，判斷是否屬於debug模式，爲了防止如今有人爲了調試應用將應用反編譯在AndroidManifest.xml中添加：android:debuggable屬性值，將其設置true。而後就能夠進行調試。

2.檢查應用是否處於調試狀態 藉助系統的一個api來進行判斷：android.os.Debug.isDebuggerConnected()；這個就是判斷當前應用有沒有被調試

3.循環檢查端口 查看設備的tcp端口使用狀況 cat /proc/net/tcp 好比Frida框架，他的端口號是27042和27043，以及進程名是frida-server

四、加固方案 加固的基本步驟以下：

1. 從App原始apk文件裏獲取到原始dex文件
2. 對原始dex文件進行加密，並將加密後的dex文件和相關的存放到assert目錄裏
3. 用脫殼dex文件替換原始apk文件裏的dex文件；脫殼dex文件的做用主要有兩個，一個是解密加密後的dex文件；二是基於dexclassloader動態加載解密後的dex文件
4. 由於原始apk文件已經被修改，因此須要刪除原始apk的簽名信息，即刪除META-INF目錄下的.RSA、.SF 和MANIFEST.MF文件
5. 生成加固後的apk文件
6. 對加固後的apk文件進行簽名，apk加固完成。

dex加固主要是防止被靜態反編譯，進而獲取源碼並修改

除了以上業務相關性弱的防禦方案，還有防被抓包，防被hook等和業務密切相關的防禦方案，如傳輸數據加密，防做弊等策略。

以上每一個防禦策略都有對應的應對之道，固然攻克了不表明不能防，防禦只是增長攻克的難度和時間，攻防沒有永遠的勝利方，有人攻就有人防，防禦策略也在不斷的升級更新換代。

要深刻理解Android安全防禦，就必須瞭解Android應用的結構。

2、APK(Android PacKage)結構

assets目錄： 用於存放須要打包到APK中的靜態文件，和res的不一樣點在於，assets目錄支持任意深度的子目錄，用戶能夠根據本身的需求任意部署文件夾架構

lib目錄： 程序依賴的native庫（so庫）

META-INF目錄： 存放應用程序簽名和證書的目錄，包含的文件有CERT.RSA，CERT.DSA，CERT.SF和MANIFEST.MF，其中CERT.RSA是開發者利用私鑰對APK進行簽名的簽名文件，CERT.SF，MANIFEST.MF記錄了文件中文件的SHA-1哈希值

res目錄： 存放應用程序的資源，存在這個文件夾下的全部文件都會映射到Android工程的.R文件中，生成對應的ID，res文件夾下能夠包含多個文件夾，其中anim存放動畫文件；drawable目錄存放圖像資源；layout目錄存放佈局文件；values目錄存放一些特徵值，colors.xml存放color顏色值，dimens.xml定義尺寸值，string.xml定義字符串的值，styles.xml定義樣式對象；xml文件夾存聽任意xml文件，在運行時能夠經過Resources.getXML()讀取；raw是能夠直接複製到設備中的任意文件，他們無需編譯。

resources.arsc： 資源配置文件，用來記錄資源文件和資源ID之間的映射關係，用來根據資源ID尋找資源

AndroidManifest.xml： 應用程序的配置文件,程序打包時，會把AndroidManifest.xml進行簡單的編譯，便於Android系統識別，編譯以後的格式是AXML格式。

classes.dex： dex可執行文件,傳統的Java程序，首先先把Java文件編譯成class文件，字節碼都保存在了class文件中，Java虛擬機能夠經過解釋執行這些class文件。而Dalvik虛擬機是在Java虛擬機進行了優化，執行的是Dalvik字節碼，而這些Dalvik字節碼是由Java字節碼轉換而來，通常狀況下，Android應用在打包時經過AndroidSDK中的dx工具將Java字節碼轉換爲Dalvik字節碼。dx工具能夠對多個class文件進行合併，重組，優化，能夠達到減少體積，縮短運行時間的目的。

對於逆向首入門檻就是dex，瞭解dex的數據結構對防禦和逆向都是極其重要的，dex文件結構分析文章很是多，這裏很少贅述，不瞭解的先去了解下。

對於Android防禦目前流行的最後方案就是加固，某些應用市場已經把加固和上架進行了綁定，說明加固的逆向難度公認度是很高的。

上面介紹了加固的基本步驟，市面上的加固方案都大同小異，最核心的部分就是對apk/dex進行加密-解析-動態加載，對dex加密各有各的方式和算法，瞭解dex結構和動態加載以後就能夠對不一樣加固方案進行具體分析了，不過度析大廠的apk以後發現都沒有對dex進行加固就使人深思，也許在客戶端的防禦只是門檻，服務端的防禦及防做弊纔是終極防禦策略，而加固會增長崩潰的機率，做爲大流量的app來講萬分之一的機率也是很高的，而對dex加固的安全性並非最高的，因此放棄對dex加固也是有跡可循的。

做爲Android應用開發者來講，navite層的代碼具備更高的挑戰性，大部分Android開發者並不熟悉c/c++開發，因此so的加固應運而生。

動態連接庫so： 動態連接庫是程序運行時加載的庫，當動態連接庫正確安裝後，全部的程序均可以使用動態庫來運行程序。動態連接庫是目標文件的集合，目標文件在動態連接庫中的組織方式是按照特殊方式造成的。庫中函數和變量的地址是相對地址，不是絕對地址，其真實地址在調用動態庫的程序加載時造成。 so文件是基於ELF(Executable and Linking Format)文件格式。而so是共享目標文件，因此要想對so文件進行加密就必須瞭解

ELF文件格式： 可執行連接格式(Executable and Linking Format)最初是由 UNIX 系統實驗室(UNIX System Laboratories，USL)開發併發布的，做爲應用程序二進制接口(Application Binary Interface，ABI)的一部分。工具接口標準(Tool Interface Standards，TIS)委員會將還在發展的 ELF 標準選做爲一種可移植的目標文件格式，能夠在 32 位 Intel 體系結構上的不少操做系統中使用。

目標文件有三種類型: 可重定位文件(Relocatable File) .o)包含適合於與其餘目標文件連接來建立可執行文件或者共享目標文件的代碼和數據。 可執行文件(Executable File) .exe) 包含適合於執行的一個程序，此文件規定了exec() 如何建立一個程序的進程映像。 共享目標文件(Shared Object File) .so) 包含可在兩種上下文中連接的代碼和數據。首先連接編輯器能夠將它和其它可重定位

文件和共享目標文件一塊兒處理， 生成另一個目標文件。其次動態連接器(Dynamic Linker)可能將它與某 個可執行文件以及其它共享目標一塊兒組合，建立進程映像。

目標文件所有是程序的二進制表示，目的是直接在某種處理器上直接執行。

經過對so中的section和函數進行加密來加固對逆向的難度會提升不少，雖然對於瞭解so的人來講並非難事，好比動態調試一下，或者dump出內存中運行的dex，因此沒有絕對的安全，只有相對的攻防。