一、前言
在之前介紹了很多破解相關的文章，在這個過程中我們難免會遇到一些反調試策略，當時只是簡單的介紹瞭如何去解決反調試，其實在去年我已經介紹了一篇關於Android中的安全逆向防護之戰的文章：Android安全逆向防護解析；那麼這篇文章就來詳細總結一下，現階段比較流行的幾種反調試解決方案。
二、反調試方案分析
代碼非常簡單，在so中加上這行代碼即可：ptrace(PTRACE_TRACEME, 0, 0, 0);其中PTRACE_TRACEME代表：本進程被其父進程所跟蹤。其父進程應該希望跟蹤子進程，一般一個進程只能被附加一次，我們在破解調試的時候都會附加需要調試應用的進程，如果我們先佔坑，父進程附加自己，那麼後面在附加調試就會失敗。加上這段代碼我們運行之後看一下效果：
我們在進行破解動態調試的時候都知道附加進程的status文件中的TracerPid字段就是被調試的進程pid，這裏我們運行程序之後，查看進程對應的status文件，發現TracerPid值就是進程的父進程pid值。那麼後面如果有進程在想附加調試就是會失敗的。這種方式啓動一定的調試作用，但是不是絕對安全的。關於解決這種反調試方案後面再說。
其實簽名校驗，準備來說不算是反調試方案，但是也是一種安全防護策略，就在這裏提一下了，而簽名校驗一般現在有很多用途，用意在於防止二次打包，一般方案有兩種：
-
第一：直接在本地做防護，如果發現簽名不一致直接退出應用。
-
第二：將簽名信息攜帶請求參數中參與加密，服務端進行簽名校驗，失敗就返回錯誤數據即可。
而這兩種方式也都不是最安全的防護，因爲只要有簽名校驗的邏輯，在本地都可以進行過濾掉。而在之前的好幾篇文章中都介紹瞭如何過濾這種簽名校驗的方法，不瞭解的同學可以去查看：Android中一鍵破解簽名校驗工具ndroid中一鍵破解簽名校驗工具；而對於服務器簽名校驗以及將簽名校驗放到so中的文章後面會單獨在介紹一篇。
這種方式是純屬藉助Android中的api進行檢驗，有兩種方法：
直接調用Android中的flag屬性：ApplicationInfo.FLAG_DEBUGGABLE，判斷是否屬於debug模式：
這個其實就是爲了防止現在破解者爲了調試應用將應用反編譯在AndroidManifest.xml中添加：android:debuggable屬性值，將其設置true。然後就可以進行調試。
添加這個屬性之後，我們可以用 dumpsys package [packagename] 命令查看debug狀態：
所以我們可以檢查應用的AppliationInfo的flag字段是否爲debuggable即可。不過這種方式也不是萬能的，後面會介紹如何解決這種反調試問題。
這個也是藉助系統的一個api來進行判斷：android.os.Debug.isDebuggerConnected()；這個就是判斷當前應用有沒有被調試，我們加上這段代碼之後，其中有一個步驟進行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中應用在進行反調試反破解的幾種方案，對於每種方案進行了詳細原理分析，代碼也給出了下載地址，可以自行運行看效果，而對於這幾種反調試方案並非是絕對安全的，後面會再詳細介紹如何解決這些反調試功能，但是爲了應用安全，這幾種方案也不可以不用，有總比沒有好！
《Android應用安全防護和逆向分析》
點擊立即購買：京東 天貓
更多內容：點擊這裏
關注微信公衆號，最新技術乾貨實時推送
