一、前言
最近有一個同學，發給我一個設備流量訪問檢測工具，但是奇怪的是，他從GP上下載下來之後安裝就沒有數據了，而在GP上直接安裝就可以。二次打包也會有問題。所以這裏就可以判斷這個app應該是有簽名校驗了，當然還有其他的校驗邏輯，我們打開這個app界面如下，沒有任何數據：
二、應用分析
下面就來簡單分析這個app，不多說直接使用Jadx工具打開：
我們在使用的過程中會發現需要授權VPN權限，所以就斷定這個app利用了系統的VPNService功能開發的，直接在xml中找到入口，然後進入查看配置代碼：
繼續跟蹤查看內部邏輯：
在Worker類中，看到有一些核心的Native方法，開發過VPNService都知道，攔截數據等操作一般都會放到native去做，主要原因是性能會高點。不多說直接使用IDA打開libwebd.so文件，直接搜索NativeInit函數，爲什麼搜索這個函數呢？因爲一看這個是初始化操作，而沒有數據的話那些校驗判斷只會在這裏，所以直接看這個函數實現：
繼續往下看，他到底做了哪些驗證，這裏主要包括了三處驗證，具體如下：
第一處驗證：驗證安裝渠道是否爲GP，這裏利用了系統的getInstallerPackageName方法來做判斷，這個方法在很早的Android版本就有了，但是這個方法有很大使用問題，後面會介紹。因爲GP安裝器包名是：com.android.vending,這裏直接判斷如果安裝器不是GP就不進行攔包操作了。
第二處驗證：應用簽名校驗，這個已經是最普遍的校驗方法了，這裏不多解釋了，直接使用kstools工具進行爆破即可破解簽名校驗。
第三處驗證：這個主要驗證xml中的android:debuggable="true"這個屬性值，我們之前如果想調試這個app的話，一般都會手動反編譯改這個屬性爲true的。但是我們現在不需要調試，也沒必要進行修改。這個驗證對於我們來說沒什麼影響。
看到上面的三處驗證，其實對於我們現在掌握的技術來說，都不難，特別是簽名校驗，完全可以使用kstools工具來搞定，一鍵化操作，不瞭解kstools工具的同學可以看這篇文章：Android中自動爆破簽名校驗工具kstools;這裏同學自己使用工具操作一下即可過了這個驗證。而第三處驗證可以說沒什麼影響，不用管它。主要來看第一處驗證。有的同學說破解也簡單，直接修改CBZ指令即可。但是這個就缺失了一些技巧，我們要的不是結果，而是學習的過程。接下來看看我是怎麼破解這個校驗的。又要多介紹一些知識點了。
三、破解方案
破解這個安裝渠道大致有兩個方案，一個是利用kstools工具源碼修改一下，攔截getInstallerPackageName方法，然後修改返回值即可，如下：
直接返回這個包名的的安裝器就是GP的，這樣在打包就可以給多人使用了。這個不多介紹了，感興趣的同學去下載源碼自己操作實踐一下即可：https://github.com/fourbrother/kstools
還有一種超級簡單的方式，直接使用命令 pm install -i[指定安裝器包名] apk文件，這個命令應該又很少人知道，但是這個簡單的一個命令就可以在這裏很方便的破解，可以指定一個app的安裝器。
我們安裝之後，可以在系統的 /data/system/packages.xml 中查看應用對應的安裝器名稱：
而這裏又說道一個知識，就是系統的這個packages.xml文件，他就是設備安裝成功的應用的一些詳細信息，包括使用到的權限，簽名信息，安裝渠道，各種標誌等。之前有人問怎麼獲取設備中的應用安裝渠道來源，其實可以從這個文件中獲取到。從這裏看到這個應用現在的確是從GP上安裝的了，也說明了上面的那個pm命令的確有效。
這時候我們再看看應用的攔截是否有效果了：
看到了，這裏開始攔截設備的數據包了，從這裏看這款app的確很有用，對於我們開發來說，也算是一個很好的工具了，破解之後可以珍藏使用了。對於第一種方式破解是最好的，因爲那樣可以給多個人使用，而對於第二種命令指定安裝器的安裝方式，一般小白用戶肯定不知道。對於第一種方式破解只需要修改kstools源碼即可。
本文的目的只有一個就是學習更多的逆向技巧和思路，如果有人利用本文技術去進行非法商業獲取利益帶來的法律責任都是操作者自己承擔，和本文以及作者沒關係，本文涉及到的代碼項目可以去編碼美麗小密圈自取，歡迎加入小密圈一起學習探討技術
四、總結
好了到這裏我們就破解成功了，可以愉快的使用這個app了，但是從上面來看瞭解到了新的防護策略就是判斷應用是否來自於指定應用市場。有的同學可能立馬想到了，爲了防止二次打包，可以在應用中判斷是否來自於主流的應用市場渠道，如果不是就不走正確的邏輯了，這個也算是一個防護策略了，不過可惜的是這個想法是不可行的，如果可行就有很多app早這麼幹了。原因是因爲這個系統方法：getInstallerPackageName，大家可以自己測試這個方法，會發現：如果一個app是系統應用，那麼這個返回值可能是設備自帶的應用市場。如果一個app是第三方應用，從GP上安裝，這個值一定是com.android.vending；而如果是其他渠道，比如國內的應用包，手機助手，豌豆莢等。就有可能是null值，而是用pm這樣的命令，或者系統自帶的安裝器安裝的第三方應用也有可能是null值，也就是說：這個系統api返回的應用安裝器名稱極不穩定，完全就是不靠譜的方法，至少在國內沒法使用的。所以幾乎可以忽略這個方法的。但是爲何這個app敢這麼幹呢?其實我也很好奇。不過有一點可以說明就是這個app開發商就認定了此app只在GP上發佈，其他渠道都不發佈，這樣只認定GP上下載的app纔算是合法的。比如一個國外用戶，用了華爲手機使用非GP渠道下載了這個app，那麼可惜這個人也是不能使用的。我也很好奇這個app的開發商爲何要這麼做？反正國內的app應該都不會這麼做的。因爲這個方法的返回值極不穩定。但是不能說這個方法不靠譜，我們在後面的逆向就要忽略這個防護，後面我們在破解app依然遵從不變法則：全局搜索signature字符串來判斷是否有簽名校驗，全局搜索getInstallerPackageName方法是否有安全渠道驗證。不管是在IDA還是Jadx中搜索，都是如此。
《Android應用安全防護和逆向分析》
點擊立即購買：京東 天貓
更多內容：點擊這裏
關注微信公衆號，最新技術乾貨實時推送
