一、前言

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

二、反調試方案分析

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

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

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

第二種：簽名校驗

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

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

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

第三種：調試狀態檢查

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

***：檢查應用是否屬于debug模式

直接調用Android中的flag屬性：ApplicationInfo.FLAG_DEBUGGABLE，判斷是否屬于debug模式：   

這個其實就是為了防止現在破解者為了調試應用將應用反編譯在AndroidManifest.xml中添加：android:debuggable屬性值，將其設置true。然后就可以進行調試。

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

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

第二：檢查應用是否處于調試狀態

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

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

第四種：循環檢查端口

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

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

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

第五種：循環檢查TracerPid值

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

查看一下android_server的pid值：

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

三、反調試方案總結

下面簡單幾句話總結這幾種方案：

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

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

反調試方案策略代碼下載：

https://github.com/fourbrother/android_anti_debug

四、總結

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