一、前言

在之前介紹了很多破解相關(guān)的文章，在這個過程中我們難免會遇到一些反調(diào)試策略，當(dāng)時只是簡單的介紹了如何去解決反調(diào)試，其實在去年我已經(jīng)介紹了一篇關(guān)于Android中的安全逆向防護之戰(zhàn)的文章：Android安全逆向防護解析;那么這篇文章就來詳細總結(jié)一下，現(xiàn)階段比較流行的幾種反調(diào)試解決方案。

二、反調(diào)試方案分析

***種：先占坑，自己附加

代碼非常簡單，在so中加上這行代碼即可：ptrace(PTRACE_TRACEME, 0, 0, 0);其中PTRACE_TRACEME代表：本進程被其父進程所跟蹤。其父進程應(yīng)該希望跟蹤子進程，一般一個進程只能被附加一次，我們在破解調(diào)試的時候都會附加需要調(diào)試應(yīng)用的進程，如果我們先占坑，父進程附加自己，那么后面在附加調(diào)試就會失敗。加上這段代碼我們運行之后看一下效果：

我們在進行破解動態(tài)調(diào)試的時候都知道附加進程的status文件中的TracerPid字段就是被調(diào)試的進程pid，這里我們運行程序之后，查看進程對應(yīng)的status文件，發(fā)現(xiàn)TracerPid值就是進程的父進程pid值。那么后面如果有進程在想附加調(diào)試就是會失敗的。這種方式啟動一定的調(diào)試作用，但是不是絕對安全的。關(guān)于解決這種反調(diào)試方案后面再說。

第二種：簽名校驗

其實簽名校驗，準備來說不算是反調(diào)試方案，但是也是一種安全防護策略，就在這里提一下了，而簽名校驗一般現(xiàn)在有很多用途，用意在于防止二次打包，一般方案有兩種：

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

而這兩種方式也都不是最安全的防護，因為只要有簽名校驗的邏輯，在本地都可以進行過濾掉。而在之前的好幾篇文章中都介紹了如何過濾這種簽名校驗的方法，不了解的同學(xué)可以去查看：Android中破解某應(yīng)用的簽名校驗;而對于服務(wù)器簽名校驗以及將簽名校驗放到so中的文章后面會單獨在介紹一篇。

第三種：調(diào)試狀態(tài)檢查

這種方式是純屬借助Android中的api進行檢驗，有兩種方法：

***：檢查應(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)試。

添加這個屬性之后，我們可以用 dumpsys package [packagename] 命令查看debug狀態(tài)：

所以我們可以檢查應(yīng)用的AppliationInfo的flag字段是否為debuggable即可。不過這種方式也不是***的，后面會介紹如何解決這種反調(diào)試問題。

第二：檢查應(yīng)用是否處于調(diào)試狀態(tài)

這個也是借助系統(tǒng)的一個api來進行判斷：android.os.Debug.isDebuggerConnected();這個就是判斷當(dāng)前應(yīng)用有沒有被調(diào)試，我們加上這段代碼之后，按照之前的那篇文章：脫掉360加固保護殼，其中有一個步驟進行jdb連接操作：

jdb -connect com.sun.jdi.SocketAttach:hostname=127.0.0.1,port=8700，當(dāng)連接成功之后，這個方法就會返回true，那么我們可以利用這個api來進行判斷當(dāng)前應(yīng)用是否處于調(diào)試狀態(tài)來進行反調(diào)試操作。但是這種方式不是***的，后面會介紹如何解決這種反調(diào)試問題。

第四種：循環(huán)檢查端口

我們在之前破解逆向的時候，需要借助一個強大利器，那就是IDA，在使用IDA的時候，我們知道需要在設(shè)備中啟動android_server作為通信，那么這個啟動就會默認占用端口23946：

我們可以查看設(shè)備的tcp端口使用情況 cat /proc/net/tcp：

其中5D8A轉(zhuǎn)化成十進制就是23946，而看到uid是0，因為我們運行android_server是root身份的，uid肯定是0了。所以我們可以利用端口檢查方式來進行反調(diào)試策略，當(dāng)然這種方式不是***的，后面會詳細介紹如何解決這樣的反調(diào)試方法。

第五種：循環(huán)檢查TracerPid值

在***種方式中，我們簡單的介紹了如果應(yīng)用被調(diào)試了，那么他的TracerPid值就是調(diào)試進程的pid值，而在使用IDA進行調(diào)試的時候，需要在設(shè)備端啟動android_server進行通信，那么被調(diào)試的進程就會被附加，這就是android_server進程的pid值了：

查看一下android_server的pid值：

所以我們可以在自己的應(yīng)用中的native層加上一個循環(huán)檢查自己status中的TracerPid字段值，如果非0或者是非自己進程pid(如果采用了***種方案的話，這里也是需要做一次過濾的);那么就認為被附加調(diào)試了。當(dāng)然這里還有一種方案，就是可以檢查進程列表中有沒有android_server進程，不過這種方式都不是***的，后面會詳細介紹如何解決這種反調(diào)試方案。

三、反調(diào)試方案總結(jié)

下面簡單幾句話總結(jié)這幾種方案：

• ***、自己附加進程，先占坑，ptrace(PTRACE_TRACEME, 0, 0, 0)!
• 第二、簽名校驗不可或缺的一個選擇，本地校驗和服務(wù)端校驗雙管齊下!
• 第三、借助系統(tǒng)api判斷應(yīng)用調(diào)試狀態(tài)和調(diào)試屬性，最基礎(chǔ)的防護!
• 第四、輪訓(xùn)檢查android_server調(diào)試端口信息和進程信息，防護IDA的一種有效方式!
• 第五、輪訓(xùn)檢查自身status中的TracerPid字段值，防止被其他進程附加調(diào)試的一種有效方式!

上面就簡單的介紹了現(xiàn)在流行的幾種應(yīng)用反調(diào)試策略方案，這幾種方案可以全部使用，也可以采用幾種使用，但是要記住一點：如果要做到更安全點，記得把反調(diào)試方案放到native層中，時機最早，一般在JNI_OnUnload函數(shù)里面，為了更安全點，native中的函數(shù)可以自己手動注冊，函數(shù)名自己混淆一下也是可以的。具體可參見這篇文章：Android安全逆向防護解析?，F(xiàn)在一些加固平臺為了更有效的防護，啟動的多進程之間的防護監(jiān)聽，多進程一起參與反調(diào)試方案，這種方式對于破解難度就會增大，但是也不是絕對安全的。文章中對于每種方式***都說到了，都不是***安全的，都有方法解決，而這內(nèi)容放到下一篇來詳細介紹了。

反調(diào)試方案策略代碼下載：

https://github.com/fourbrother/android_anti_debug

四、總結(jié)

本文主要介紹了Android中應(yīng)用在進行反調(diào)試反破解的幾種方案，對于每種方案進行了詳細原理分析，代碼也給出了下載地址，可以自行運行看效果，而對于這幾種反調(diào)試方案并非是絕對安全的，后面會再詳細介紹如何解決這些反調(diào)試功能，但是為了應(yīng)用安全，這幾種方案也不可以不用，有總比沒有好!