Android逆向之旅---逆向「某借款理財App新版」防抓包策略

​一、前言

之前已經介紹了某借款應用他的抓包策略防護,因爲在小密圈裏有人告知這個應用有一個抓包策略,抓不到數據包了,所以就分析的確他的最新版已經做了一些防護比如簽名校驗,Xposed防護等導致JustTrustMe插件以及之前介紹的升級版插件都用不了了,不過再怎麼變他都是用的okhttp網絡框架,設置ssl信息也就是那幾個接口,但是因爲現在Xposed插件沒法用了,所以我們只能手動的去分析代碼了。今天這篇文章就直接分析代碼修改代碼來直接搞定抓包策略。

 

二、逆向分析

首先因爲我們這一次要改代碼所有,我們先用apktool工具反編譯,然後在回編譯簽名安裝運行看效果:

安裝運行之後提示這樣的錯誤信息,這個明顯是簽名校驗問題,我們可以直接用Jadx打開代碼查看:

這裏展示對話框,然後繼續追蹤代碼查看:

這裏看到是獲取簽名信息然後進行比對的:

然後看到的確用的是系統Api獲取簽名信息,其實到這裏我們可以直接修改這個方法返回值是true即可,但是這裏就不做修改了,因爲爲了驗證我的kstools工具的威力,直接用這個工具一鍵搞定,當然肯定是可以的,不然我也不會在這裏說了,所以大家可以直接用kstools工具即可搞定這個簽名校驗。

 

弄完簽名校驗之後直接簽名打包安裝就好了,這裏可以看到他沒有對二次打包做太多的校驗邏輯,這個也算是安全的遺漏點,因爲有了二次打包成功,我們就可以隨意的修改代碼了,首先我們然後抓包看看信息:

還是提示錯誤網絡不安全,全局搜索錯誤信息到這裏了,其實我們可以利用Xposed進行hook操作打印這個異常信息的,但是可惜他做了防護Xposed操作,所以搞不了但是沒關係,這裏在告訴大家一個小技巧:一般okhttp框架時候的時候如果有網絡請求錯誤一般都會打印日誌,就是會調用e.printStackTrace()打印信息:

我們通過日誌發現的確有錯誤信息報道,然後把錯誤異常信息去網上搜索也是說的證書錯誤問題,但是這裏有個問題就是我們沒法查看在那個地方錯誤,以至於我們怎麼去修改代碼呢?這裏又有一個小技巧了:在使用這個框架設置ssl的時候都知道就是三個Api的使用方法:

  • sslSocketFactory(SSLSocketFactory factory)

  • hostnameVerifier(HostnameVerifier verifiter)

  • getSocketFactory()

所以其實很簡單,我們只要全局搜索這兩個方法即可,但是這裏可能不能這麼做,因爲我們之前分析另外一個應用的時候發現現在很多應用爲了防止JustTrustMe插件,他直接把okhttp的一些方法全部混淆了,所以我們直接搜索這兩個方法名可能不全,所以我們可以搜索兩個參數類型,這兩個是java系統庫中的,所以不可能被混淆的,但是我們其實還有一種更加高效的方式,直接搜索這兩個類的構造地方,因爲既然要用那就要初始化:

這樣就全局搜索到了初始化的地方,可以排除一下比如okhttp內部的一些方法,還有通過包名可以判斷肯定沒有關係的方法,最後就剩下這兩個比較可疑了方法了:

看到這個類中設置ssl的方法,其實我們只要把這些方法全部設置一遍:

我們找到第一個方法的類中,直接用#註釋了設置ssl的兩個方法,然後再看第二個地方:

然後看到這個類有個好玩的地方,他本身做了一個兜底策略就是信任全部證書,但是有個if條件判斷,這個就簡單了,我們直接把判斷條件改一下即可,把之前的a != null 改成a == null即可,怎麼改其實很簡單:

改了這個之後我們直接回編譯然後安裝即可:

抓包看到接口已經可以了:

但是當我們點擊進入二級頁面發現提示打不開錯誤信息,我們查看當前頁面信息:

 

然後查看這個類定義:

繼續查看代碼:

我們看到了這個是WebView中的ssl校驗邏輯,這個會判斷如果正確的證書校驗成功調用proceed方法,否則就調用cancel方法,這個校驗方法還是在HttpsUtils裏面:

這個可以直接改成返回值true即可,當然可以直接改,但是這裏介紹一個AndroidStudio的一個好用的插件java2smali:

直接在Plugins->java2Smali,然後直接安裝即可,安裝之後我們可以編寫好java代碼:

然後點擊菜單中的Build->Compile to smali:

這樣編譯成smali代碼了:

我們只關心.prologue後面的代碼,其實看代碼也很簡單,直接返回true:

這樣就把原來的方法直接返回true了,修改好之後我們在用jadx打開看看:

這樣就改成功了,這時候在安裝就可以打開所有頁面了,而且可以正常使用了,到這裏其實我們已經通過直接改代碼邏輯搞定了這個應用的防護抓包策略,但是問題依然還有就是這個應用是如何進行Xposed防護,其實他是用了第三方的安全框架,這個可能需要後續深入分析了。

 

三、知識點概要總結

第一、對於一些應用做了Xposed防護我們可以嘗試修改代碼,修改代碼之後一般都會有簽名防護的,可以用kstools工具一鍵先搞定簽名防護操作。

第二、對於後續所有的抓包失敗的應用,因爲有了Xposed防護,所以原有的JustTrustMe插件沒法使用了,所以需要分析代碼,這時候查看入口很簡單,直接全局搜索

  • sslSocketFactory(SSLSocketFactory factory)

  • hostnameVerifier(HostnameVerifier verifiter)

  • getSocketFactory()

等方法和類型信息。因爲不管怎麼變最終都是需要調用這三個方法,先需要初始化類然後在設置到okhttp中,所以一些應用沒法在這些操作中做防護,就直接防xposed操作了。

第三、有時候我們手動改smali代碼可能比較難,可以藉助AndroidStudio中的插件編寫好對應的Java代碼然後變成smali代碼即可

 

嚴重說明

本文的目的只有一個就是學習逆向分析技巧,如果有人利用本文技術進行非法操作帶來的後果都是操作者自己承擔,和本文以及本文作者沒有任何關係,本文涉及到的代碼項目可以去編碼美麗小密圈自取,長按下方二維碼加入小密圈一起學習探討技術 

 

四、總結

對於本文內容其實還是比較簡單的,但是又引出另外一個問題就是這個應用他竟然用了第三方的安全SDK做了一些防護,導致一些核心數據無法獲取到,這個是後續需要弄得問題,當然這個可能直接對抗的是這個第三方的安全SDK功能了,不過有個好奇的地方,既然都用了這個SDK做了Xposed防護,卻沒有對代碼二次打包做個好的防護,很是奇怪!

 

《Android應用安全防護和逆向分析》

點擊立即購買:京東  天貓  

更多內容:點擊這裏

關注微信公衆號,最新技術乾貨實時推送

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章