Android应用的安全的攻防之战
一、前言
在前兩篇破解的文章中，我們介紹了如何使用動態調試來破解apk，一個是通過調試smali源碼，一個是通過調試so代碼來進行代碼的跟蹤破解，那么今天我們就這兩篇文章的破解方法，來看看Android中開發應用的過程中如何對我們的應用做一層安全保護，當然現在市場中大部分的應用已經做了一些防護策略，但是沒有絕對的安全，破解只是時間上的問題。所以攻破和防護是相生相克，永不停息的戰爭，沒有絕對的安全，也沒有萬能的破解之道。
下面我們就來看看如何做到我們的應用更安全，我們主要從這五個方面來看看怎么操作：
1、混淆策略
2、應用的簽名
3、修改Native函數名
4、反調試異常檢測
5、應用的加固策略
當然還有其他防護方法，我們今天就介紹這五種，后續還有的話，繼續補充
二、技術原理
第一種方式：混淆策略
混淆策略是每個應用必須增加的一種防護策略，同時他不僅是為了防護，也是為了減小應用安裝包的大小，所以他是每個應用發版之前必須要添加的一項功能，現在混淆策略一般有兩種：
1、對代碼的混淆
我們在反編譯apk之后，看到的代碼類名，方法名，已經代碼格式看起來不像正常的Android項目代碼，那么這時候就會增加閱讀難度，增加破解難度，像這樣的代碼混淆：
我們一般現在的破解查看Java層代碼就是兩種方式：
一種是直接先解壓classes.dex文件出來，使用dex2jar工具轉化成jar文件，然后再用jd-gui工具進行查看類結構
一種是使用apktool工具直接反編譯apk，得到smali源碼，閱讀smali源碼
不過這種代碼混淆有時候在一定程度上能夠增加混淆策略，但是有時候也不是很安全，因為我們知道我們在破解的過程中一般是找程序的入口，那么這些入口一般都是Application或者是MainActivity之類的，但是這些Android中的組件類是不能進行混淆的，所以我們還是有入口可尋，能夠找到入口代碼，然后進行跟蹤。
?
2、對工程資源的混淆
我們上面說到了對代碼的混淆能夠增加一定的代碼閱讀難度，有時候我們為了防止資源的保護也是可以做混淆的，這個資源混淆原理這里就不多解釋了，微信團隊已經將這個功能開源，不了解的同學可以轉戰github查看：
https://github.com/shwenzhang/AndResGuard
當然資源混淆還有一個很大的好處就是減小apk包的大小，當然這個不是本文討論的知識點，這里我們討論的是混淆資源增加破解查找資源的難度，先來看一下混淆資源之后的結果：
這里我們可以看到，一個混淆資源的應用，反編譯之后查看他的string.xml內容，發現他的name全是簡單的混淆字母，那么這個對于我們之前的那種可以通過name的值，來查找對應的字符串內容來獲取消息，這個將是很蛋疼的一件事，因為你這時候如果全局搜索一個name值的話，比如這里的name='a'，那么得搜出多少個這樣的name，查找也是很好時間的，其實在沒有混淆之前，一般string中的name都是比較唯一的一種值，查找的話不會有那么多查找結果，而且查找時間也是很短的。
破解之道：
但是對于這種混淆資源也是絕對的防護安全，因為我們知道一般在反編譯之后的Java代碼中，看到的獲取資源值的時候，并不是資源的name值了，而是資源對應的int類型的值，比如這樣：
這里獲取一個字符串的值，那么，這些int類型的值，我們可以在反編譯之后的res/values/pulblic.xml中找到：
比如這里的2131230929變成16進制就是：0x0x7f0800d1，我們在public.xml中查找，找到了name='ey‘的一項，然后再去string.xml中進行name查找：
好吧，還是找到了這個字符串的值，反編譯之后的public.xml中記錄了所有資源的id和整型值對應值，混淆之后的代碼中看到的都是資源id的整型值，那么這么一看混淆并沒有什么用途。只能偏偏小白了。
?
從上面的兩處混淆策略看到，混淆對于破解并沒有什么太大的阻礙，也是只是一個障眼法，不過混淆的另外一個功能就是減少apk包的大小，這個也是每個應用添加混淆的最主要原因。
?
第二種方式：應用的簽名
我們知道Android中的每個應用都是有一個唯一的簽名，如果一個應用沒有被簽名是不允許安裝到設備中的，一般我們在運行debug程序的時候也是有默認的簽名文件的，只是IDE幫我們做了簽名工作，一般在應用發版的時候會用唯一的簽名文件進行簽名，那么我們在以往的破解中可以看到，我們有時候需要在反編譯應用之后，然后從新簽名在打包運行，這個又給了很多二次打包團隊謀取利益的一種手段，就是反編譯市場中的包，然后添加一些廣告代碼，最后使用自家的簽名在此從新打包發布到市場中，因為簽名在反編譯之后是獲取不到的，所以只能用自己的簽名文件去簽名，但是在已經安裝了應用設備再去安裝一個簽名不一致的應用也是安裝失敗的，這樣也有一個問題就是有些用戶安裝了這些二次打包的應用之后，無法再安裝正規的應用了，只有卸載重裝。那么這時候我們可以利用應用的簽名是唯一的特性做一層防護。
我們為了防止應用被二次打包，或者是需要破解我們的apk的操作，在入口處添加簽名驗證，如果發現應用的簽名不正確就立即退出程序，我們可以在應用啟動的時候獲取應用的簽名值，然后和正規的簽名值作比對，如果不符合就直接退成程序即可，這里我們做一個簡單的案例測試一下：
這里定義一個簡單的工具類用于比較應用的簽名，這里只是簡單處理，正常情況下這里應該比對簽名的MD5值，這里為了簡單就忽略了，然后我們在程序的入口處做一次比對，如果不正確就退出程序：
那么我們得到上面的apk之后，下面來反編譯，然后從新簽名安裝(關于這里如何反編譯和簽名，不做解釋了，使用apktool和signapk工具即可，簽名文件是自己的)，然后運行：
發現程序根本運行不起來，一點擊就閃退，這里就做到了防止應用被二次簽名打包的安全問題策略了。
?
破解之道：
但是這個也不是最安全的，因為我們知道，既然有簽名比對方法的地方，那么我只需要反編譯apk之后，修改smali語法，把這個方法調用的地方注釋即可：
只需要使用#把這行代碼注釋，然后回編譯從新打包安裝即可。所以這種方式也是只能欺騙一下小白，不過這里需要注意的是，如何找到這個檢測簽名的方法的地方還是最關鍵的，比如有的程序在native層做的，但是不管在哪里，只要是在代碼中，我們就可以找出來的。
?
第三種方式：修改Naitve函數名
這個方法其實不太常用，因為他的安全措施不是很強大的，但是也是可以起到一定的障眼法策略，在說這個知識點的時候，我們先來了解一下so加載的流程：
在Android中，當程序在java層運行System.loadLibrary("jnitest");這行代碼后，程序會去載入libjnitest.so文件，與此同時，產生一個"Load"事件，這個事件觸發后，程序默認會在載入的.so文件的函數列表中查找JNI_OnLoad函數并執行，與"Load"事件相對，當載入的.so文件被卸載時，“Unload”事件被觸發，此時，程序默認會去在載入的.so文件的函數列表中查找JNI_OnUnload函數并執行，然后卸載.so文件。需要注意的是，JNI_OnLoad與JNI_OnUnload這兩個函數在.so組件中并不是強制要求的，用戶也可以不去實現，java代碼一樣可以調用到C組件中的函數，之所以在C組件中去實現這兩個函數（特別是JNI_OnLoad函數），往往是做一個初始化工作或“善后”工作。可以這樣認為，將JNI_ONLoad看成是.so組件的初始化函數，當其第一次被裝載時被執行（window下的dll文件也可類似的機制，在_DLL_Main()函數中，通過一個swith case語句來識別當前是載入還是卸載）。將JNI_OnUnload函數看成是析構函數，當其被卸載時被調用。由此看來，就不難明白為什么很多jni C組件中會實現JNI_OnLoad這個函數了。 一般情況下，在C組件中的JNI_OnLoad函數用來實現給VM注冊接口，以方便VM可以快速的找到Java代碼需要調用的C函數。（此外，JNI_OnLoad函數還有另外一個功能，那就是告訴VM此C組件使用那一個JNI版本，如果未實現JNI_OnLoad函數，則默認是JNI 1.1版本）。
應用層的Java類別通過VM而調用到native函數。一般是通過VM去尋找*.so里的native函數。如果需要連續呼叫很多次，每次都需要尋找一遍，會多花許多時間。此時，C組件開發者可以將本地函數向VM進行注冊,以便能加快后續調用native函數的效率.可以這么想象一下，假設VM內部一個native函數鏈表，初始時是空的，在未顯式注冊之前此native函數鏈表是空的，每次java調用native函數之前會首先在此鏈表中查找需要查找需要調用的native函數，如果找到就直接使用，如果未找到，得再通過載入的.so文件中的函數列表中去查找，且每次java調用native函數都是進行這樣的流程，因此，效率就自然會下降，為了克服這樣現象，我們可以通過在.so文件載入初始化時，即JNI_OnLoad函數中，先行將native函數注冊到VM的native函數鏈表中去，這樣一來，后續每次java調用native函數時都會在VM中的native函數鏈表中找到對應的函數，從而加快速度
?
通過上面的分析之后，我們知道原來我們知道so文件加載和卸載的時機，同時我們可以顯示的手動注冊我們自己的native方法，那么我們知道一般我們在定義native方法的時候，對應的native層的函數名是：Java_類名_方法名 ?這種樣式：
所以就有兩個問題：
第一個問題就是我們在IDA工具查看so文件的時候，去找到對應的native方法非常容易，以為我們知道了Java層的native方法名和類型，那么直接可以定位到這個native函數：
第二問題就是惡意破解人可以得到這個so文件之后，查看這個native方法的參數和返回類型也就是方法簽名，然后自己在Java層寫一個demo程序，然后構造一個和so文件中對應的native方法，然后就可以執行這個native方法，如果我們有一個校驗密碼或者是獲取密碼的方法是個native的，那么這時候就會很容易的被惡意人執行方法后獲取結果。
說的簡單點就比如上面的這個isEquals例子：
現在有一個人，想執行這個我的應用的isEquals方法，那么他只需要解壓我的apk，得到so文件，查看so文件中的函數，或者是查看上層的Java代碼，得到這個方法的返回值和簽名，然后他就可以編寫一個簡單的程序，構造一個類：
cn.wjdainkong.encryptdemo.MainActivity
然后在他內部定義一個native方法：
public native boolean isEquals(String str);
然后在使用System.loadLibrary加載我的so文件，然后在適當的地方執行isEquals方法，這樣就等于調用了我的so文件中的isEquals方法了。
?
所以從上面的兩個為可以看到，如果我們native層的函數遵從這樣的格式，無疑是給破解者簡單的一種方式，所以我們可以這么做，就是顯示的注冊我們的JNI方法，只需要在我們native層的代碼中調用這三個函數即可：
第一個函數：(*env)->RegisterNatives(env,clazz, methods, methodsLenght)
這個函數就是手動的注冊一個native方法，這個函數是屬于JNIEnv*的，參數也比較簡單
1》clazz就是，需要注冊native方法的那個類，是jclass類型，這個我們可以使用JNIEnv的FindClass方法，傳遞類的名稱即可獲取這個對象，類似于這樣：
2》methods是一個結構體，定義如下：
typedef struct {
const char* name;
const char* signature;
void* fnPtr;
} JNINativeMethod;
第一個變量name是Java中函數的名字。
第二個變量signature，用字符串是描述了函數的參數和返回值
第三個變量fnPtr是函數指針，指向C函數。
類似于這樣的結構：
?
第二個函數：jint JNI_OnLoad(JavaVM* vm, void* reserved)
這個函數就是上面說到的，so被加載的時候被調用到，同時我們可以看到這里還可以獲取JVM參數的，一般在這個函數中主要就是執行上面的注冊函數功能，同時這里還需要獲取一個JNIEnv*變量：
這里通過JVM來獲取JNIEnv變量，然后調用注冊函數：
實現手動的注冊函數
?
第三個函數：void JNI_OnUnload(JavaVM* vm, void* reserved)
這個函數和JNI_OnLoad是相對應的，是在so被卸載的時候調用
?
通過上面的三個函數我們就可以手動的顯示注冊我們的native函數方法了，那么我們同時就可以修改native層的函數名，不要按照之前的那種格式了，增加破解者尋找關鍵的native層函數的難度：
這里我們把isEquals函數名變成了jiangwei：
然后在修改注冊方法的結構體：
編譯運行，在使用IDA查看：
這時候破解者不能按照常規的套路，找到了native層的函數了，那么上面的兩個問題就可以避免了。增加安全性
?
破解之道：
但是問題來了，現在的破解者，一般打開SO文件的時候，如果找不到對應的native方法之后，就會去找JNI_OnLoad函數，然后在通過分析arm匯編代碼，找到register函數，分析注冊方法結構體，找到對應的native方法，那么這種方式還是不靠譜，也是只能糊弄一下小白破解者。不過我們通過這個例子也可以得知，在JNI_OnLoad中可以做很多事的，比如上面說到的簽名機制校驗，我們也可以在JNI_OnLoad中做一次，增加安全性：
看看equal_sign函數功能：
在這個方法中，其實用我們用JNIEnv變量調用了Java層的方法，來獲取應用的簽名，然后進行比對的
所以我們用這種簽名校驗方式來做安全性保證也是一個思路至少native層的代碼分析比smali代碼分析難度大點，而且這種簽名校驗機制必須用靜態方式去破解apk，也就是通過分析代碼來破解，因為程序沒有運行起來無法通過動態方式破解的。那么應對與靜態方式破解的話，我們只能增加代碼的閱讀難度了。
?
第四種方式：反調試異常檢測
這種方式其實是為了應對現在很多破解者使用IDA進行動態方式調試so文件，從而獲取重要的信息，如果還不知道如何使用IDA進行動態調試so文件的同學可以查看這篇文章：Android中使用IDA進行動態調試so文件?，看完這篇文章之后，我們可以知道IDA進行so動態調試是基于進程的注入技術，然后使用Linux中的ptrace機制，進行調試目標進程的，那么ptrace機制有一個特點，就是如果一個進程被調試了，在他進程的status文件中有一個字段TracerPid會記錄調試者的進程id值，比如：
查看文件：/proc/[myPid]/status
在第六行，有一個TracerPid字段，就是記錄了調試者的進程id
那么我們就可以這么做來達到反調試的功效了，就是我們可以輪訓的遍歷自己進程的status文件，然后讀取TracerPid字段值，如果發現他大于0，那么就代表著自己的應用在被人調試，所以就立馬退出程序。原理知道了，代碼實現也很簡單，這里用pthread創建一個線程，然后進行輪訓操作：
使用pthread_create創建一個線程，線程啟動之后執行thread_function函數
看看thread_funcation函數：
開始輪訓，讀取TracerPid字段的值，發現大于0，就立馬退出程序，我們運行結果看看：
看到了，當我們使用IDA工具進行調試的時候，程序立馬退出，同時IDA的調試頁面也退出了。
所以這里我們看到這種輪訓機制來實現反調試策略，可以應對與一般的破解小白了。
?
破解之道：
但是還是有問題，因為現在破解者們，他們已經免疫了，知道會有這種檢測，所以就會用IDA工具給JNI_OnLoad函數下斷點，然后進行調試，找到檢測輪訓代碼，使用nop指令，替換檢測指令，就相當于把檢測代碼給注釋了，功能的夭折，所以這種反調試方法還是不好使，知道的人多了，也沒什么意義了，但是有總比沒有的好。
?
第五種方式：應用的加固策略
關于這種方式，那就是現在很多應用都用的一種方式了，也是安全性最高的一種防護了，他加固主要有三方面：
1、對dex文件進行加密
這樣我們用dex2jar工具，或者apktools等工具反編譯失敗，關于這個dex加密這里，也不做太多的介紹了，之前有一篇文章已經介紹了dex加固的原理了：Android中apk加固原理解析? ?
破解之道：
但是可惜的是，這種方式也淪陷了，因為我們知道，不管你dex怎么加密，最后都是需要用DVM加載dex文件到內存中的，我們知道Android中所有關于DVM的函數都是在libdvm.so文件中的，而且這個文件是存在設備的/system/lib目錄中的，加載dex有一個重要的函數：
int dvmDexFileOpenPartial(const void* addr, int len, DvmDex** ppDvmDex)
第一個參數就是dex內存起始地址
第二個參數就是dex大小。所以在這個函數下斷點可以直接dump出明文dex
所以我們使用IDA調試程序，找到模塊libdvm.so的內存地址，找到其中的函數dvmdexfileopenpartialPKviPP6DvmDex，在這個函數下斷點即可dump處dex文件了。
關于這個案例，后續還會寫一篇文章來介紹如何破解現在加固dex的應用。
2、對so文件進行加密
現在很多應用把中號的功能都放到了native層中，那么如果我們隊so文件進行加密的話，那么IDA工具就無法打開so文件，從而做到安全保護，關于Android中so加密可以參考這篇文章：Android中對so加固原理解析??
破解之道：
但是可惜的是，這種方式也被淪陷了，看完這篇文章之后，我們知道加固so的有一個特點就是你必須在so在被調用的時候需要進行解密，不然會影響正常的native層調用，那么這個時機很重要，一般都是在so文件的入口處，也就是用：
?__attribute__((constructor)) 這個屬性來標注一個解密函數，這樣就能保證解密函數執行的時機比任何一個函數時機都早，或者可以理解為是一個類的構造函數的執行時機即可，但是一般有這種屬性的函數都在so的.inin_array段中的：
那么現在的問題就變成了，如果我知道了.init_array端的位置，然后在查看這個段中的arm指令代碼，就可以得到解密函數了，然后在解讀這個解密函數的邏輯即可。那么最后就要看這個加密函數的難度程度怎么樣了。
關于這個案例，后續還會寫一篇文章來介紹如何破解現在加固so的應用。
3、加固資源文件和AndroidManifest.xml文件
這個加固一般是應對與現在最流行的反編譯工具apktool了，他是開源的，比如下面的這個應用：
所以看到了，這種加固就是利用apktool工具的漏洞來進行加固的，不過這個apktool工具也是實時在更新的，也是為了解決現在的apk這種資源文件的加固導致反編譯失敗的問題。
破解之道：
所以對于這種反編譯失敗的問題，我們應該自己編譯apktool的源碼，找到指定的保存位置，然后修改異常即可，不過這個可不是一個簡單的工作，是需要耐心和經驗的。
?
項目下載：http://download.csdn.net/detail/jiangwei0910410003/9534543
?
三、安全工作流程
1、為了應對與低級破解小白，同時也是為了減小apk包的大小，我們會對代碼和資源的一個混淆，增加破解難度
2、為了應對與初級破解小白，我們將手動的注冊我們的native方法，讓破解者找不到對應的native方法，同時解決一些重要的native方法的被調用問題，增加破解難度
3、為了應對與中級破解小白，我們會利用應用的簽名，來防止應用的二次簽名打包，同時防止動態調試問題，增加破解難度
4、為了應對與高級破解小白，我們會增加應用的反調試功能，來防止應用被動態調試和進程注入問題，增加破解難度
5、為了應對與資深破解小白，我們會采用應用的加固策略，對dex，so，資源文件進行加固，增加反編譯工作了和調試難度
?
四、總結
通過這篇文章我們看到，介紹了幾種安全防護應用的方法，但是我們在每個方法后面也都介紹了破解者如何應對與這種方法，所以說這里說的這些安全防護都是可以被破解的，只是時間問題，隨著時間的推移，我們看到沒有絕對的安全，也沒有統一的破解之道，只有一個安全策略出來了，破解之道也就相對應出來的，這樣相生相克，彼此進步。但是個人感覺破解還是要大于防護的，因為破解是逆向思維，這種要求會更高點，特別是對于那種變態的加密算法的破解和逆向，尤其蛋疼。最后也希望通過這篇文章能夠讓你們了解到Android中的破解不是那么容易的，安全也不是那么容易的。兩者都在進步，我們也要進步！
轉載于:https://www.cnblogs.com/chenxibobo/p/6075064.html
總結
以上是生活随笔為你收集整理的Android应用的安全的攻防之战的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： AutoLISP 绘制表情图案
- 下一篇： 精通android（Pro Androi