一、前言
Android開發者常常面臨的一個問題就是防破解、 防二次打包。現如今安全問題越來越重要,越來越多的Android開發者也開始尋求安全的保護方案。請看一下下面的幾張圖片：
1.1
1.2
1.3
二、什么是加殼？
移動平台攻防技術的發展基本是沿着PC端發展軌跡在進行,從windows平台的加殼脫殼反調試到Andriod的平台apk加固,反調試代碼混淆等。
加殼是在二進制的程序中植入一段代碼，在運行的時候優先取得程序的控制權，做一些額外的工作。大多數病毒就是基於此原理。PC EXE文件加殼的過程如下：
三、加殼作用和分類
作用：
加殼的程序可以有效阻止對程序的反匯編分析，以達到它不可告人的目的。這種技術也常用來保護軟件版權，防止被軟件破解。
分類：
從App的加固技術來看:主流分為dex加密和so加密,目前來看保護dex文件更為重要,應為dex反編譯后的java代碼可讀性更強。
四、Android Dex文件加殼原理
4.1.APK文件結構
每個文件及文件夾的作用如下表所示。
| 文件或目錄 | 說明 |
|---|---|
| assets文件夾 | 存放資源文件的目錄 |
| lib文件夾 | 存放ndk編譯出來的so文件 |
| META-INF文件夾 | 1.該目錄下存放的是簽名信息，用來保證apk包的完整性和系統的安全性 2.CERT.RS 保存着該應用程序的證書和授權信息 3.CERT.SF 保存着SHA-1信息資源列表 4.MANIFEST.MF 清單信息 |
| res文件夾 | 存放資源文件的目錄 |
| AndroidManifest.xml | 一個清單文件，它描述了應用的名字、版本、權限、注冊的服務等信息。 |
| classes.dex | java源碼編譯經過編譯后生成的dalvik字節碼文件，主要在Dalvik虛擬機上運行的主要代碼部分 |
| resources.arsc | 編譯后的二進制資源文件。 |
4.2DEX文件格式
4.2.1什么是DEX文件？
他是Android系統的可執行文件，包含應用程序的全部操作指令以及運行時數據
由於dalvik是一種針對嵌入式設備而特殊設計的java虛擬機，所以dex文件與標准的class文件在結構設計上有着本質的區別
當java程序編譯成class后，還需要使用dx工具將所有的class文件整合到一個dex文件，目的是其中各個類能夠共享數據，在一定程度上降低了冗余，同時也是文件結構更加經湊，實驗表明，dex文件是傳統jar文件大小的50%左右
4.2.2dex文件結構
Dex文件整體結構如下：
Dex文件整體結構說明：
| 數據名稱 | 解釋 |
|---|---|
| dex_header | dex文件頭部記錄整個dex文件的相關屬性 |
| string_table | 字符串數據索引，記錄了每個字符串在數據區的偏移量 |
| type_table | 類似數據索引，記錄了每個類型的字符串索引 |
| proto_table | 原型數據索引，記錄了方法聲明的字符串，返回類型字符串，參數列表 |
| field_table | 字段數據索引，記錄了所屬類，類型以及方法名 |
| method_table | 類方法索引，記錄方法所屬類名，方法聲明以及方法名等信息 |
| class_def | 類定義數據索引，記錄指定類各類信息，包括接口，超類，類數據偏移量 |
| data_section | 數據區，保存了各個類的真是數據 |
下面是DEX文件目錄：
這里面，有3個成員我們需要特別關注，這在后面加固里會用到，它們分別是checksum、signature和fileSize。
checksum字段
checksum是校驗碼字段，占4bytes，主要用來檢查從該字段（不包含checksum字段，也就是從12bytes開始算起）開始到文件末尾，這段數據是否完整，也就是完整性校驗。它使用alder32算法校驗。
signature字段
signature是SHA-1簽名字段，占20bytes，作用跟checksum一樣，也是做完整性校驗。之所以有兩個完整性校驗字段，是由於先使用checksum字段校驗可以先快速檢查出錯的dex文件，然后才使用第二個計算量更大的校驗碼進行計算檢查。
fileSize字段
占4bytes，保存classes.dex文件總長度。
這3個字段當我們修改dex文件的時候，這3個字段的值是需要更新的，否則在加載到Dalvik虛擬機的時候會報錯。
為什么說我們只需要關注這三個字段呢？
因為我們需要將一個文件(加密之后的源Apk)寫入到Dex中，那么我們肯定需要修改文件校驗碼(checksum).因為他是檢查文件是否有錯誤。那么signature也是一樣，也是唯一識別文件的算法。還有就是需要修改dex文件的大小。
不過這里還需要一個操作，就是標注一下我們加密的Apk的大小，因為我們在脫殼的時候，需要知道Apk的大小，才能正確的得到Apk。那么這個值放到哪呢？這個值直接放到文件的末尾就可以了。
所以總結一下我們需要做：修改Dex的三個文件頭，將源Apk的大小追加到殼dex的末尾就可以了。
我們修改之后得到新的Dex文件樣式如下：
[圖片上傳失敗...(image-831de6-1534489556791)]
4.3APK打包流程
上圖中涉及到的工具及其作用如下：
| 名稱 | 功能介紹 |
|---|---|
| aapt | 打包資源文件，包括res和assets文件夾下的資源、AndroidManifest.xml文件、Android基礎類庫 |
| aidl | 將.aidl接口文件轉換成.java文件 |
| javaComiler | 編譯java文件，生成.class字節碼文件 |
| dex | 將所有的第三方libraries和.class文件轉換成Dalvik虛擬機支持的.dex文件 |
| apkbuilder | 打包生成apk文件，但未簽名 |
| jarsigner | 對未簽名的apk文件進行簽名 |
| zipalign | 對簽名后的apk文件進行對其處理 |
4.4加固原理
Dex文件整體加固原理如下：
在該過程中涉及到三個對象，分別如下：
l 源程序
源程序也就是我們的要加固的對象，這里面主要修改的是原apk文件中的classes.dex文件和AndroidManifest.xml文件。
l 殼程序
殼程序主要用於解密經過加密了的dex文件，並加載解密后的原dex文件，並正常啟動原程序。
l 加密程序
加密程序主要是對原dex文件進行加密，加密算法可以是簡單的異或操作、反轉、rc4、des、rsa等加密算法。
該加固過程可以分為如下4個階段：
（1） 加密階段
（2）合成新的dex文件
（3）修改原apk文件並重打包簽名
（4）運行殼程序加載原dex文件
4.4.1 加密階段
加密階段主要是講把原apk文件中提取出來的classes.dex文件通過加密程序進行加密。加密的時候如果使用des對稱加密算法，則需要注意處理好密鑰的問題。同樣的，如果采用非對稱加密，也同樣存在公鑰保存的問題。
4.4.2 合成新的dex文件
這一階段主要是講上一步生成的加密的dex文件和我們的殼dex文件合並，將加密的dex文件追加在殼dex文件后面，並在文件末尾追加加密dex文件的大小數值
在殼程序里面，有個重要的類：ProxyApplication類，該類繼承Application類，也是應用程序最先運行的類。所以，我們就是在這個類里面，在原程序運行之前，進行一些解密dex文件和加載原dex文件的操作。
4.4.3 修改原apk文件並重打包簽名
在這一階段，我們首先將apk解壓，會看到如下圖的6個文件和目錄。其中，我們需要修改的只有2個文件，分別是classes.dex和AndroidManifest.xml文件，其他文件和文件加都不需要改動。
首先，我們把解壓后apk目錄下原來的classes.dex文件替換成我們在0x02上一步合成的新的classes.dex文件。然后，由於我們程序運行的時候，首先加載的其實是殼程序里的ProxyApplication類。所以，我們需要修改AndroidManifest.xml文件，指定application為ProxyApplication，這樣才能正常找到識別ProxyApplication類並運行殼程序。
4.4.4運行殼程序加載原dex文件
Dalvik虛擬機會加載我們經過修改的新的classes.dex文件，並最先運行ProxyApplication類。在這個類里面，有2個關鍵的方法：attachBaseContext和onCreate方法。ProxyApplication顯示運行attachBaseContext再運行onCreate方法。
在attachBaseContext方法里，主要做兩個工作：
-
讀取classes.dex文件末尾記錄加密dex文件大小的數值，則加密dex文件在新classes.dex文件中的位置為：len(新classes.dex文件) – len(加密dex文件大小)。然后將加密的dex文件讀取出來，加密並保存到資源目錄下
-
然后使用自定義的DexClassLoader加載解密后的原dex文件
在onCreate方法中，主要做兩個工作：
-
通過反射修改ActivityThread類，並將Application指向原dex文件中的Application
-
創建原Application對象，並調用原Application的onCreate方法啟動原程序
五、加殼代碼實現
5.1、加殼程序項目：
5.2、核心代碼
六、常見加固平台
梆梆加固，愛加密，360加固，騰訊加固
市面上常見的加固工具加固之后,他會把你的dex,so 加密存在apk中,然后運行過程會先運行殼的代碼,殼的代碼再把原來的這個dex、so 解出來加載,不同的廠商有自己的方案,略有差距,但目前多數都是這個思路.
七、App加固的利弊
正面:
1.保護自己核心代碼算法,提高破解/盜版/二次打包的難度
2.緩解代碼注入/動態調試/內存注入攻擊
負面：
1.影響兼容性
2.影響程序運行效率.
3.部分流氓、病毒也會使用加殼技術來保護自己
4.部分應用市場會拒絕加殼后的應用上架
八、App安全未來展望
一款app的流水線,從開發到內測到平台到消費者再到破解者再到平台再到消費者，所以每一個環節都不可輕視！！！
九、App安全總結
| 風險名稱 | 風險 | 解決方案 |
|---|---|---|
| 1.App防止反編譯 | 被反編譯的暴露客戶端邏輯，加密算法，密鑰，等等 | 加固 |
| 2.java層代碼源代碼反編譯風險 | 被反編譯的暴露客戶端邏輯，加密算法，密鑰，等等 | 加固 ，混淆 |
| 3.so文件破解風險 | 導致核心代碼泄漏。 | so文件加固 |
| 4.篡改和二次打包風險 | 修改文件資源等，二次打包的添加病毒，廣告，或者竊取支付密碼，攔截短信等 | 資源文件混淆和校驗簽名的hash值 |
| 5.資源文件泄露風險 | 獲取圖片，js文件等文件，通過植入病毒，釣魚頁面獲取用戶敏感信息 | 資源混淆，加固等等 |
| 6.應用簽名未交驗風險 | 反編譯或者二次打包，添加病毒代碼，惡意代碼，上傳盜版App | 對App進行簽名證書校驗 |
| 7.代碼為混淆風險 | 業務邏輯暴露，加密算法，賬號信息等等。 | 混淆（中文混淆） |
| 8.webview明文存儲密碼風險 | 用戶使用webview默認存儲密碼到databases/webview.db root的手機可以產看webview數據庫，獲取用戶敏感信息 | 關閉wenview存儲密碼功能 |
| 9.明文數字證書風險 | APK使用的數字證書用來校驗服務器的合法性，保證數據的保密性和完成性 明文存儲的證書被篡改造成數據被獲取等 | 客戶端校驗服務器域名和數字證書等 |
| 10.調試日志函數調用風險 | 日志信息里面含有用戶敏感信息等 | 關閉調試日志函數，刪除打印的日志信息 |
| 11.AES/DES加密方法不安全使用風險 | 在使用AES/DES加密使用了ECB或者OFB工作模式，加密數據被選擇明文攻擊破解等 | 使用CBC和CFB工作模式等 |
| 12.RSA加密算法不安全風險 | 密數據被選擇明文攻擊破解和中間人攻擊等導致用戶敏感信息泄露 | 密碼不要太短，使用正確的工作模式 |
| 13.密鑰硬編碼風險 | 用戶使用加密算法的密鑰設置成一個固定值導致密鑰泄漏 | 動態生成加密密鑰或者將密鑰進程分段存儲等 |
| 14.動態調試攻擊風險 | 攻擊者使用GDB，IDA調試追蹤目標程序，獲取用戶敏感信息等 | 在so文件里面實現對調試進程的監聽 |
| 15.應用數據任意備份風險 | AndroidMainfest中allowBackup=true 攻擊者可以使用adb命令對APP應用數據進行備份造成用戶數據泄露 | allowBackup=false |
| 16.全局可讀寫內部文件風險。 | 實現不同軟件之間數據共享，設置內部文件全局可讀寫造成其他應用也可以讀取或者修改文件等 | （1）.使用MODE_PRIVATE模式創建內部存儲文件（2）.加密存儲敏感數據3.避免在文件中存儲明文和敏感信息 |
| 17.SharedPrefs全局可讀寫內部文件風險。 | 被其他應用讀取或者修改文件等 | 使用正確的權限 |
| 18.Internal Storage數據全局可讀寫風險 | 當設置MODE_WORLD_READBLE或者設置android:sharedUserId導致敏感信息被其他應用程序讀取等 | 設置正確的模式等 |
| 19.getDir數據全局可讀寫風險 | 當設置MODE_WORLD_READBLE或者設置android:sharedUserId導致敏感信息被其他應用程序讀取等 | 設置正確的模式等 |
| 20.java層動態調試風險 | AndroidManifest中調試的標記可以使用jdb進行調試，竊取用戶敏感信息。 | android：debuggable=“false” |
| 21.內網測試信息殘留風險 | 通過測試的Url，測試賬號等對正式服務器進行攻擊等 | 講測試內網的日志清除，或者測試服務器和生產服務器不要使用同一個 |
| 22.隨機數不安全使用風險 | 在使用SecureRandom類來生成隨機數，其實並不是隨機，導致使用的隨機數和加密算法被破解。 | （1）不使用setSeed方法（2）使用/dev/urandom或者/dev/random來初始化偽隨機數生成器 |
| 23.Http傳輸數據風險 | 未加密的數據被第三方獲取，造成數據泄露 | 使用Hpps |
| 24.Htpps未校驗服務器證書風險，Https未校驗主機名風險，Https允許任意主機名風險 | 客戶端沒有對服務器進行身份完整性校驗，造成中間人攻擊 | （1）.在X509TrustManager中的checkServerTrusted方法對服務器進行校驗（2）.判斷證書是否過期（3）.使用HostnameVerifier類檢查證書中的主機名與使用證書的主機名是否一致 |
| 25.webview繞過證書校驗風險 | webview使用https協議加密的url沒有校驗服務器導致中間人攻擊 | 校驗服務器證書時候正確 |
| 26.界面劫持風險 | 用戶輸入密碼的時候被一個假冒的頁面遮擋獲取用戶信息等 | （1）.使用第三方專業防界面劫持SDK（2）.校驗當前是否是自己的頁面 |
| 27.輸入監聽風險 | 用戶輸入的信息被監聽或者按鍵位置被監聽造成用戶信息泄露等 | 自定義鍵盤 |
| 28.截屏攻擊風險 | 對APP運行中的界面進行截圖或者錄制來獲取用戶信息 | 添加屬性getWindow().setFlags(FLAG_SECURE)不讓用戶截圖和錄屏 |
| 29.動態注冊Receiver風險 | 當動態注冊Receiver默認生命周期是可以導出的可以被任意應用訪問 | 使用帶權限檢驗的registerReceiver API進行動態廣播的注冊 |
| 30.Content Provider數據泄露風險 | 權限設置不當導致用戶信息 | 正確的使用權限 |
| 31.Service ，Activity，Broadcast,content provider組件導出風險 | Activity被第三方應用訪問導致被任意應用惡意調用 | 自定義權限 |
| 32.PendingIntent錯誤使用Intent風險 | 使用PendingIntent的時候，如果使用了一個空Intent，會導致惡意用戶劫持修改Intent的內容 | 禁止使用一個空Intent去構造PendingIntent |
| 33.Intent組件隱式調用風險 | 使用隱式Intent沒有對接收端進行限制導致敏感信息被劫持 | 1.對接收端進行限制 2.建議使用顯示調用方式發送Intent |
| 34.Intent Scheme URL攻擊風險 | webview惡意調用App | 對Intent做安全限制 |
| 35.Fragment注入攻擊風險 | 出的PreferenceActivity的子類中，沒有加入isValidFragment方法，進行fragment名的合法性校驗，攻擊者可能會繞過限制，訪問未授權的界面 | （1）.如果應用的Activity組件不必要導出，或者組件配置了intent filter標簽，建議顯示設置組件的“android:exported”屬性為false（2）.重寫isValidFragment方法，驗證fragment來源的正確性 |
| 36.webview遠程代碼執行風險 | 風險：WebView.addJavascriptInterface方法注冊可供JavaScript調用的Java對象，通過反射調用其他java類等 | 建議不使用addJavascriptInterface接口，對於Android API Level為17或者以上的Android系統，Google規定允許被調用的函數，必須在Java的遠程方法上面聲明一個@JavascriptInterface注解 |
| 37.zip文件解壓目錄遍歷風險 | Java代碼在解壓ZIP文件時，會使用到ZipEntry類的getName()方法，如果ZIP文件中包含“../”的字符串，該方法返回值里面原樣返回，如果沒有過濾掉getName()返回值中的“../”字符串，繼續解壓縮操作，就會在其他目錄中創建解壓的文件 | （1）. 對重要的ZIP壓縮包文件進行數字簽名校驗，校驗通過才進行解壓。 （2）. 檢查Zip壓縮包中使用ZipEntry.getName()獲取的文件名中是否包含”../”或者”..”，檢查”../”的時候不必進行URI Decode（以防通過URI編碼”..%2F”來進行繞過），測試發現ZipEntry.getName()對於Zip包中有“..%2F”的文件路徑不會進行處理。 |
| 38.Root設備運行風險 | 已經root的手機通過獲取應用的敏感信息等 | 檢測是否是root的手機禁止應用啟動 |
| 39.模擬器運行風險 | 刷單，模擬虛擬位置等 | 禁止在虛擬器上運行 |
| 40.從sdcard加載Dex和so風險 | 未對Dex和So文件進行安全，完整性及校驗，導致被替換，造成用戶敏感信息泄露 | （1）.放在APP的私有目錄 （2）.對文件進行完成性校驗。 |
十、參考
作者：問心2018
鏈接：https://www.jianshu.com/p/4ff48b761ff6