一、前言
在之前介紹了很多破解相關的文章，在這個過程中我們難免會遇到一些反調試政策，當時隻是簡單的介紹了如何去解決反調試，其實在去年我已經介紹了一篇關于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安全逆向防護解析。現在一些加強平台為了更有效的防護，啟動的多程序之間的防護監聽，多程序一起參與反調試方案，這種方式對于破解難度就會增大，但是也不是絕對安全的。文章中對于每種方式最後都說到了，都不是萬能安全的，都有方法解決，而這内容放到下一篇來詳細介紹了。
反調試方案政策代碼下載下傳：
<a href="https://github.com/fourbrother/android_anti_debug">https://github.com/fourbrother/android_anti_debug</a>
四、總結
本文主要介紹了android中應用在進行反調試反破解的幾種方案，對于每種方案進行了詳細原理分析，代碼也給出了下載下傳位址，可以自行運作看效果，而對于這幾種反調試方案并非是絕對安全的，後面會再詳細介紹如何解決這些反調試功能，但是為了應用安全，這幾種方案也不可以不用，有總比沒有好!
作者：程式猿大雄
來源：51cto