Author：楊空明 Date：2018-8-17
一婶熬、前言
Android開發(fā)者常常面臨的一個問題就是防破解赵颅、 防二次打包〗让現(xiàn)如今安全問題越來越重要,越來越多的Android開發(fā)者也開始尋求安全的保護方案募寨。請看一下下面的幾張圖片：
1.1
1.2
1.3
二、什么是加殼恰画？
移動平臺攻防技術(shù)的發(fā)展基本是沿著PC端發(fā)展軌跡在進行,從windows平臺的加殼脫殼反調(diào)試到Andriod的平臺apk加固,反調(diào)試代碼混淆等拴还。
加殼是在二進制的程序中植入一段代碼片林，在運行的時候優(yōu)先取得程序的控制權(quán)，做一些額外的工作孝偎。大多數(shù)病毒就是基于此原理衣盾。PC EXE文件加殼的過程如下：
三势决、加殼作用和分類
作用：
加殼的程序可以有效阻止對程序的反匯編分析，以達到它不可告人的目的虽抄。這種技術(shù)也常用來保護軟件版權(quán)迈窟，防止被軟件破解车酣。
分類：
從App的加固技術(shù)來看:主流分為dex加密和so加密,目前來看保護dex文件更為重要,應(yīng)為dex反編譯后的java代碼可讀性更強湖员。
四娘摔、Android Dex文件加殼原理
4.1.APK文件結(jié)構(gòu)
每個文件及文件夾的作用如下表所示嫡丙。
| 文件或目錄 | 說明 |
|---|---|
| assets文件夾 | 存放資源文件的目錄 |
| lib文件夾 | 存放ndk編譯出來的so文件 |
| META-INF文件夾 | 1.該目錄下存放的是簽名信息曙博，用來保證apk包的完整性和系統(tǒng)的安全性 2.CERT.RS 保存著該應(yīng)用程序的證書和授權(quán)信息 3.CERT.SF 保存著SHA-1信息資源列表 4.MANIFEST.MF 清單信息 |
| res文件夾 | 存放資源文件的目錄 |
| AndroidManifest.xml | 一個清單文件，它描述了應(yīng)用的名字惠窄、版本杆融、權(quán)限脾歇、注冊的服務(wù)等信息藕各。 |
| classes.dex | java源碼編譯經(jīng)過編譯后生成的dalvik字節(jié)碼文件，主要在Dalvik虛擬機上運行的主要代碼部分 |
| resources.arsc | 編譯后的二進制資源文件乌逐。 |
4.2DEX文件格式
4.2.1什么是DEX文件黔帕？
他是Android系統(tǒng)的可執(zhí)行文件，包含應(yīng)用程序的全部操作指令以及運行時數(shù)據(jù)
由于dalvik是一種針對嵌入式設(shè)備而特殊設(shè)計的java虛擬機逻杖，所以dex文件與標準的class文件在結(jié)構(gòu)設(shè)計上有著本質(zhì)的區(qū)別
當java程序編譯成class后闻伶，還需要使用dx工具將所有的class文件整合到一個dex文件蓝翰，目的是其中各個類能夠共享數(shù)據(jù)畜份，在一定程度上降低了冗余，同時也是文件結(jié)構(gòu)更加經(jīng)湊钙态，實驗表明册倒，dex文件是傳統(tǒng)jar文件大小的50%左右
4.2.2dex文件結(jié)構(gòu)
Dex文件整體結(jié)構(gòu)如下：
Dex文件整體結(jié)構(gòu)說明：
| 數(shù)據(jù)名稱 | 解釋 |
|---|---|
| dex_header | dex文件頭部記錄整個dex文件的相關(guān)屬性 |
| string_table | 字符串數(shù)據(jù)索引册着，記錄了每個字符串在數(shù)據(jù)區(qū)的偏移量 |
| type_table | 類似數(shù)據(jù)索引甲捏，記錄了每個類型的字符串索引 |
| proto_table | 原型數(shù)據(jù)索引司顿，記錄了方法聲明的字符串化漆，返回類型字符串座云，參數(shù)列表 |
| field_table | 字段數(shù)據(jù)索引朦拖，記錄了所屬類璧帝，類型以及方法名 |
| method_table | 類方法索引锣夹，記錄方法所屬類名晕城，方法聲明以及方法名等信息 |
| class_def | 類定義數(shù)據(jù)索引，記錄指定類各類信息滤蝠，包括接口物咳，超類蹄皱，類數(shù)據(jù)偏移量 |
| data_section | 數(shù)據(jù)區(qū)览闰，保存了各個類的真是數(shù)據(jù) |
下面是DEX文件目錄：
這里面，有3個成員我們需要特別關(guān)注巷折，這在后面加固里會用到压鉴，它們分別是checksum、signature和fileSize锻拘。
checksum字段
checksum是校驗碼字段，占4bytes署拟，主要用來檢查從該字段（不包含checksum字段婉宰，也就是從12bytes開始算起）開始到文件末尾，這段數(shù)據(jù)是否完整推穷，也就是完整性校驗心包。它使用alder32算法校驗。
signature字段
signature是SHA-1簽名字段馒铃，占20bytes蟹腾，作用跟checksum一樣痕惋，也是做完整性校驗。之所以有兩個完整性校驗字段岭佳，是由于先使用checksum字段校驗可以先快速檢查出錯的dex文件，然后才使用第二個計算量更大的校驗碼進行計算檢查萧锉。
fileSize字段
占4bytes珊随，保存classes.dex文件總長度。
這3個字段當我們修改dex文件的時候柿隙，這3個字段的值是需要更新的叶洞，否則在加載到Dalvik虛擬機的時候會報錯。
為什么說我們只需要關(guān)注這三個字段呢禀崖？
因為我們需要將一個文件(加密之后的源Apk)寫入到Dex中衩辟，那么我們肯定需要修改文件校驗碼(checksum).因為他是檢查文件是否有錯誤。那么signature也是一樣波附，也是唯一識別文件的算法艺晴。還有就是需要修改dex文件的大小。
不過這里還需要一個操作掸屡，就是標注一下我們加密的Apk的大小封寞，因為我們在脫殼的時候，需要知道Apk的大小仅财，才能正確的得到Apk狈究。那么這個值放到哪呢？這個值直接放到文件的末尾就可以了盏求。
所以總結(jié)一下我們需要做：修改Dex的三個文件頭抖锥，將源Apk的大小追加到殼dex的末尾就可以了。
我們修改之后得到新的Dex文件樣式如下：
[圖片上傳失敗...(image-831de6-1534489556791)]
4.3APK打包流程
上圖中涉及到的工具及其作用如下：
| 名稱 | 功能介紹 |
|---|---|
| aapt | 打包資源文件碎罚，包括res和assets文件夾下的資源磅废、AndroidManifest.xml文件、Android基礎(chǔ)類庫 |
| aidl | 將.aidl接口文件轉(zhuǎn)換成.java文件 |
| javaComiler | 編譯java文件荆烈，生成.class字節(jié)碼文件 |
| dex | 將所有的第三方libraries和.class文件轉(zhuǎn)換成Dalvik虛擬機支持的.dex文件 |
| apkbuilder | 打包生成apk文件还蹲，但未簽名 |
| jarsigner | 對未簽名的apk文件進行簽名 |
| zipalign | 對簽名后的apk文件進行對其處理 |
4.4加固原理
Dex文件整體加固原理如下：
在該過程中涉及到三個對象，分別如下：
l 源程序
源程序也就是我們的要加固的對象耙考，這里面主要修改的是原apk文件中的classes.dex文件和AndroidManifest.xml文件谜喊。
l 殼程序
殼程序主要用于解密經(jīng)過加密了的dex文件，并加載解密后的原dex文件倦始，并正常啟動原程序斗遏。
l 加密程序
加密程序主要是對原dex文件進行加密，加密算法可以是簡單的異或操作鞋邑、反轉(zhuǎn)诵次、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文件的大小數(shù)值
在殼程序里面壳坪，有個重要的類：ProxyApplication類舶得，該類繼承Application類，也是應(yīng)用程序最先運行的類爽蝴。所以沐批，我們就是在這個類里面，在原程序運行之前蝎亚，進行一些解密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虛擬機會加載我們經(jīng)過修改的新的classes.dex文件酿秸，并最先運行ProxyApplication類灭翔。在這個類里面，有2個關(guān)鍵的方法：attachBaseContext和onCreate方法辣苏。ProxyApplication顯示運行attachBaseContext再運行onCreate方法肝箱。
在attachBaseContext方法里哄褒，主要做兩個工作：
讀取classes.dex文件末尾記錄加密dex文件大小的數(shù)值，則加密dex文件在新classes.dex文件中的位置為：len(新classes.dex文件) – len(加密dex文件大小)煌张。然后將加密的dex文件讀取出來呐赡，加密并保存到資源目錄下
然后使用自定義的DexClassLoader加載解密后的原dex文件
在onCreate方法中，主要做兩個工作：
通過反射修改ActivityThread類骏融，并將Application指向原dex文件中的Application
創(chuàng)建原Application對象链嘀，并調(diào)用原Application的onCreate方法啟動原程序
五、加殼代碼實現(xiàn)
5.1绎谦、加殼程序項目：
5.2管闷、核心代碼
六粥脚、常見加固平臺
梆梆加固窃肠，愛加密，360加固刷允，騰訊加固
市面上常見的加固工具加固之后,他會把你的dex,so 加密存在apk中,然后運行過程會先運行殼的代碼,殼的代碼再把原來的這個dex冤留、so 解出來加載,不同的廠商有自己的方案,略有差距,但目前多數(shù)都是這個思路.
七、App加固的利弊
正面:
1.保護自己核心代碼算法,提高破解/盜版/二次打包的難度
2.緩解代碼注入/動態(tài)調(diào)試/內(nèi)存注入攻擊
負面：
1.影響兼容性
2.影響程序運行效率.
3.部分流氓树灶、病毒也會使用加殼技術(shù)來保護自己
4.部分應(yīng)用市場會拒絕加殼后的應(yīng)用上架
八纤怒、App安全未來展望
一款app的流水線,從開發(fā)到內(nèi)測到平臺到消費者再到破解者再到平臺再到消費者，所以每一個環(huán)節(jié)都不可輕視Ｌ焱ā２淳健！
九像寒、App安全總結(jié)
| 風(fēng)險名稱 | 風(fēng)險 | 解決方案 |
|---|---|---|
| 1.App防止反編譯 | 被反編譯的暴露客戶端邏輯烘豹，加密算法，密鑰诺祸，等等 | 加固 |
| 2.java層代碼源代碼反編譯風(fēng)險 | 被反編譯的暴露客戶端邏輯携悯，加密算法，密鑰筷笨，等等 | 加固 憔鬼，混淆 |
| 3.so文件破解風(fēng)險 | 導(dǎo)致核心代碼泄漏。 | so文件加固 |
| 4.篡改和二次打包風(fēng)險 | 修改文件資源等胃夏，二次打包的添加病毒割笙，廣告，或者竊取支付密碼夫凸，攔截短信等 | 資源文件混淆和校驗簽名的hash值 |
| 5.資源文件泄露風(fēng)險 | 獲取圖片喧笔，js文件等文件，通過植入病毒悼瘾，釣魚頁面獲取用戶敏感信息 | 資源混淆囊榜，加固等等 |
| 6.應(yīng)用簽名未交驗風(fēng)險 | 反編譯或者二次打包审胸，添加病毒代碼，惡意代碼卸勺，上傳盜版App | 對App進行簽名證書校驗 |
| 7.代碼為混淆風(fēng)險 | 業(yè)務(wù)邏輯暴露砂沛，加密算法，賬號信息等等曙求。 | 混淆（中文混淆） |
| 8.webview明文存儲密碼風(fēng)險 | 用戶使用webview默認存儲密碼到databases/webview.db root的手機可以產(chǎn)看webview數(shù)據(jù)庫碍庵，獲取用戶敏感信息 | 關(guān)閉wenview存儲密碼功能 |
| 9.明文數(shù)字證書風(fēng)險 | APK使用的數(shù)字證書用來校驗服務(wù)器的合法性，保證數(shù)據(jù)的保密性和完成性 明文存儲的證書被篡改造成數(shù)據(jù)被獲取等 | 客戶端校驗服務(wù)器域名和數(shù)字證書等 |
| 10.調(diào)試日志函數(shù)調(diào)用風(fēng)險 | 日志信息里面含有用戶敏感信息等 | 關(guān)閉調(diào)試日志函數(shù)悟狱，刪除打印的日志信息 |
| 11.AES/DES加密方法不安全使用風(fēng)險 | 在使用AES/DES加密使用了ECB或者OFB工作模式静浴，加密數(shù)據(jù)被選擇明文攻擊破解等 | 使用CBC和CFB工作模式等 |
| 12.RSA加密算法不安全風(fēng)險 | 密數(shù)據(jù)被選擇明文攻擊破解和中間人攻擊等導(dǎo)致用戶敏感信息泄露 | 密碼不要太短，使用正確的工作模式 |
| 13.密鑰硬編碼風(fēng)險 | 用戶使用加密算法的密鑰設(shè)置成一個固定值導(dǎo)致密鑰泄漏 | 動態(tài)生成加密密鑰或者將密鑰進程分段存儲等 |
| 14.動態(tài)調(diào)試攻擊風(fēng)險 | 攻擊者使用GDB挤渐，IDA調(diào)試追蹤目標程序苹享，獲取用戶敏感信息等 | 在so文件里面實現(xiàn)對調(diào)試進程的監(jiān)聽 |
| 15.應(yīng)用數(shù)據(jù)任意備份風(fēng)險 | AndroidMainfest中allowBackup=true 攻擊者可以使用adb命令對APP應(yīng)用數(shù)據(jù)進行備份造成用戶數(shù)據(jù)泄露 | allowBackup=false |
| 16.全局可讀寫內(nèi)部文件風(fēng)險。 | 實現(xiàn)不同軟件之間數(shù)據(jù)共享浴麻，設(shè)置內(nèi)部文件全局可讀寫造成其他應(yīng)用也可以讀取或者修改文件等 | （1）.使用MODE_PRIVATE模式創(chuàng)建內(nèi)部存儲文件（2）.加密存儲敏感數(shù)據(jù)3.避免在文件中存儲明文和敏感信息 |
| 17.SharedPrefs全局可讀寫內(nèi)部文件風(fēng)險得问。 | 被其他應(yīng)用讀取或者修改文件等 | 使用正確的權(quán)限 |
| 18.Internal Storage數(shù)據(jù)全局可讀寫風(fēng)險 | 當設(shè)置MODE_WORLD_READBLE或者設(shè)置android:sharedUserId導(dǎo)致敏感信息被其他應(yīng)用程序讀取等 | 設(shè)置正確的模式等 |
| 19.getDir數(shù)據(jù)全局可讀寫風(fēng)險 | 當設(shè)置MODE_WORLD_READBLE或者設(shè)置android:sharedUserId導(dǎo)致敏感信息被其他應(yīng)用程序讀取等 | 設(shè)置正確的模式等 |
| 20.java層動態(tài)調(diào)試風(fēng)險 | AndroidManifest中調(diào)試的標記可以使用jdb進行調(diào)試，竊取用戶敏感信息软免。 | android：debuggable=“false” |
| 21.內(nèi)網(wǎng)測試信息殘留風(fēng)險 | 通過測試的Url宫纬，測試賬號等對正式服務(wù)器進行攻擊等 | 講測試內(nèi)網(wǎng)的日志清除，或者測試服務(wù)器和生產(chǎn)服務(wù)器不要使用同一個 |
| 22.隨機數(shù)不安全使用風(fēng)險 | 在使用SecureRandom類來生成隨機數(shù)膏萧，其實并不是隨機漓骚，導(dǎo)致使用的隨機數(shù)和加密算法被破解。 | （1）不使用setSeed方法（2）使用/dev/urandom或者/dev/random來初始化偽隨機數(shù)生成器 |
| 23.Http傳輸數(shù)據(jù)風(fēng)險 | 未加密的數(shù)據(jù)被第三方獲取榛泛，造成數(shù)據(jù)泄露 | 使用Hpps |
| 24.Htpps未校驗服務(wù)器證書風(fēng)險蝌蹂，Https未校驗主機名風(fēng)險，Https允許任意主機名風(fēng)險 | 客戶端沒有對服務(wù)器進行身份完整性校驗挟鸠，造成中間人攻擊 | （1）.在X509TrustManager中的checkServerTrusted方法對服務(wù)器進行校驗（2）.判斷證書是否過期（3）.使用HostnameVerifier類檢查證書中的主機名與使用證書的主機名是否一致 |
| 25.webview繞過證書校驗風(fēng)險 | webview使用https協(xié)議加密的url沒有校驗服務(wù)器導(dǎo)致中間人攻擊 | 校驗服務(wù)器證書時候正確 |
| 26.界面劫持風(fēng)險 | 用戶輸入密碼的時候被一個假冒的頁面遮擋獲取用戶信息等 | （1）.使用第三方專業(yè)防界面劫持SDK（2）.校驗當前是否是自己的頁面 |
| 27.輸入監(jiān)聽風(fēng)險 | 用戶輸入的信息被監(jiān)聽或者按鍵位置被監(jiān)聽造成用戶信息泄露等 | 自定義鍵盤 |
| 28.截屏攻擊風(fēng)險 | 對APP運行中的界面進行截圖或者錄制來獲取用戶信息 | 添加屬性getWindow().setFlags(FLAG_SECURE)不讓用戶截圖和錄屏 |
| 29.動態(tài)注冊Receiver風(fēng)險 | 當動態(tài)注冊Receiver默認生命周期是可以導(dǎo)出的可以被任意應(yīng)用訪問 | 使用帶權(quán)限檢驗的registerReceiver API進行動態(tài)廣播的注冊 |
| 30.Content Provider數(shù)據(jù)泄露風(fēng)險 | 權(quán)限設(shè)置不當導(dǎo)致用戶信息 | 正確的使用權(quán)限 |
| 31.Service 叉信，Activity，Broadcast,content provider組件導(dǎo)出風(fēng)險 | Activity被第三方應(yīng)用訪問導(dǎo)致被任意應(yīng)用惡意調(diào)用 | 自定義權(quán)限 |
| 32.PendingIntent錯誤使用Intent風(fēng)險 | 使用PendingIntent的時候艘希，如果使用了一個空Intent硼身，會導(dǎo)致惡意用戶劫持修改Intent的內(nèi)容 | 禁止使用一個空Intent去構(gòu)造PendingIntent |
| 33.Intent組件隱式調(diào)用風(fēng)險 | 使用隱式Intent沒有對接收端進行限制導(dǎo)致敏感信息被劫持 | 1.對接收端進行限制 2.建議使用顯示調(diào)用方式發(fā)送Intent |
| 34.Intent Scheme URL攻擊風(fēng)險 | webview惡意調(diào)用App | 對Intent做安全限制 |
| 35.Fragment注入攻擊風(fēng)險 | 出的PreferenceActivity的子類中，沒有加入isValidFragment方法覆享，進行fragment名的合法性校驗佳遂，攻擊者可能會繞過限制，訪問未授權(quán)的界面 | （1）.如果應(yīng)用的Activity組件不必要導(dǎo)出撒顿，或者組件配置了intent filter標簽丑罪，建議顯示設(shè)置組件的“android:exported”屬性為false（2）.重寫isValidFragment方法，驗證fragment來源的正確性 |
| 36.webview遠程代碼執(zhí)行風(fēng)險 | 風(fēng)險：WebView.addJavascriptInterface方法注冊可供JavaScript調(diào)用的Java對象，通過反射調(diào)用其他java類等 | 建議不使用addJavascriptInterface接口吩屹，對于Android API Level為17或者以上的Android系統(tǒng)跪另，Google規(guī)定允許被調(diào)用的函數(shù)，必須在Java的遠程方法上面聲明一個@JavascriptInterface注解 |
| 37.zip文件解壓目錄遍歷風(fēng)險 | Java代碼在解壓ZIP文件時煤搜，會使用到ZipEntry類的getName()方法免绿，如果ZIP文件中包含“../”的字符串，該方法返回值里面原樣返回擦盾，如果沒有過濾掉getName()返回值中的“../”字符串嘲驾，繼續(xù)解壓縮操作，就會在其他目錄中創(chuàng)建解壓的文件 | （1）. 對重要的ZIP壓縮包文件進行數(shù)字簽名校驗迹卢，校驗通過才進行解壓辽故。 （2）. 檢查Zip壓縮包中使用ZipEntry.getName()獲取的文件名中是否包含”../”或者”..”，檢查”../”的時候不必進行URI Decode（以防通過URI編碼”..%2F”來進行繞過）腐碱，測試發(fā)現(xiàn)ZipEntry.getName()對于Zip包中有“..%2F”的文件路徑不會進行處理誊垢。 |
| 38.Root設(shè)備運行風(fēng)險 | 已經(jīng)root的手機通過獲取應(yīng)用的敏感信息等 | 檢測是否是root的手機禁止應(yīng)用啟動 |
| 39.模擬器運行風(fēng)險 | 刷單，模擬虛擬位置等 | 禁止在虛擬器上運行 |
| 40.從sdcard加載Dex和so風(fēng)險 | 未對Dex和So文件進行安全喻杈，完整性及校驗彤枢，導(dǎo)致被替換狰晚，造成用戶敏感信息泄露 | （1）.放在APP的私有目錄 （2）.對文件進行完成性校驗筒饰。 |
