android黑科技系列——爆破一款應用的簽名驗證問題

1、前言

在以前的文章中說過Android中的安全和破解是相輔相成的，爲了防止被破解，不少應用作了一些防禦策略，可是防禦策略也是分等級，通常簡單的策略就是混淆代碼和簽名校驗，而對於簽名校驗不少應用都是會作的，通常如今就兩種方式：

第一種：簽名校驗不經過直接退出程序，也就是你會發現回編譯二次打包運行失敗的現象

第二種：簽名校驗不經過不觸發程序指定邏輯，致使沒有錯誤信息，也進不了應用的現象

關於Android中應用防禦策略的文章能夠看這裏：Android中應用的攻防之戰 今天咱們就來看一下簽名校驗的應用案例，在回編譯二次簽名以後運行進不去遊戲的問題，其實在以前已經分析過了一個簽名驗證的問題，那裏的問題是回編譯二次打包運行失敗的問題。不瞭解的同窗能夠去這裏看一下：Android中使用靜態方式破解apk應用；這種運行失敗的應用比較好解決，由於這種簽名校驗的通常都在應用的入口處，因此直接在入口處加一些日誌，經過打印日誌就能夠看到，入口通常是Application的onCreate方法和attachBaseContext方法，而經過這個案例以後咱們也學習到一個快速定位簽名校驗的方法的技巧：全局搜索signatures字符串，由於咱們知道若是要作簽名驗證，必須調用系統的一個api方法：getPackageManager().getPackageInfo(getPackageName(), 64).signatures，因此在用Jadx工具反編譯apk以後，全局搜signatures字符串能夠立馬定位到簽名校驗的方法。

2、案例分析

上面分析完了以前一個解決簽名校驗的案例，下面就用這個小遊戲做爲簡單分析，這個遊戲在市場均可如下載到：

本文研究的是V3.3版本的。咱們下載遊戲以後，能夠利用apktool進行反編譯，而後回編譯重簽名，安裝運行：

遊戲能夠運行成功，可是卡在這裏，進不了遊戲了，這時候咱們就猜測他可能有簽名驗證邏輯，可能放在本地，也有可能放在服務端，咱們利用上面說到的那個技巧：在Jadx中全局搜」signatures」字符串內容：

這時候會發現有不少地方都在使用，其實能夠推斷出，這個遊戲爲了防止二次打包在不少地方都加了簽名驗證的邏輯，這樣對於破解也是增長必定的難度，由於這裏簽名校驗的地方太多了，因此無法一個一個修改，因此咋們用另一種方式高效率的解決問題：在運行遊戲的時候發現遊戲卡在進度條了，因此猜測和網絡請求有關，因此咋們就經過Fiddler抓包來分析他的請求信息:

遊戲打開就這些請求，可是做爲一個遊戲不可能就這點請求的，這個也是卡住的緣由，咱們能夠這麼作，用一個正常的遊戲在抓包看看狀況：

這個是沒有二次打包簽名的請求信息，和上面二次打包簽名以後的請求相比較，多了不少請求，能夠發現有一個get_user_info這個接口比較特殊，因此咱們能夠去Jadx全局搜這個請求接口：

這裏看到定義了url的地方，而後在全局Find Usage的地方：

點進去看方法調用：

繼續查看這個方法的調用地方：

這裏有四個地方調用這個方法，可是能夠依次排除，最終定位到是com.wepie.snake.module.home.b.d.e()方法，那麼下面來看一下如何進行排除的，能夠從下往上排除，看最下面一個方法：

而後進入l.a方法中查看邏輯：

這裏實際上是個請求，請求接口是d.r的值：

看到是這個接口信息，可是咱們在用Fiddler抓包的時候並無看到這個請求：

因此這個地方能夠過濾了，其餘三個地方的分析結果相似。因此經過這種方式定位到了方法調用的地方：

咱們在查找這個e方法調用的地方：

在這裏被調用了，經過調用結果發現，有第一個判斷：

這裏有一個字符串比較相等的邏輯，頗有多是比較簽名信息的，能夠查看h.a這個方法：

這裏貌似有一個字符串的構造算法，咱們爲了看到最終的字符串內容，能夠新建一個簡單的Java項目，而後把這個方法打印一下看看結果：

看到這個最終生成的字符串內容是：678a930b9829b54a44f92a840916f7d1，而後再看一下equals的o.a的方法：

這個方法是獲取應用簽名信息的，而後用MD5計算結果。因此到這裏咱們就知道校驗簽名邏輯是，獲取應用的簽名信息，而後MD5一下，和」678a930b9829b54a44f92a840916f7d1「字符串進行比較。那麼咱們二次簽名以後，這個判斷確定就是false了，因此後續的邏輯就不走了，沒有後面的請求，發現卡在開始界面了。

那麼問題找到了，改起來就比較簡單了，直接反編譯遊戲，而後找到這個 com.wepie.snake.helper.f.o.a()方法對應的smali代碼：

把這個方法直接返回」678a930b9829b54a44f92a840916f7d1「字符串便可。有的同窗說這個怎麼改？是手動編寫samli代碼嗎？確定不是的，咋們能夠先寫一個簡單的返回這個字符串的方法，而後反編譯獲得這段smali代碼就能夠了，可千萬別本身手動的去編寫，除非你有這個耐心和毅力，反正我沒有。替換完成以後，咋們就回編譯，二次簽名運行安裝遊戲，惋惜的是仍是卡住了，因此還得回去看代碼：

咋們修改了一次簽名校驗方法，進入了第一層簽名判斷，繼續往下看代碼：

這裏又有一個判斷，點進去查看邏輯：

果真，這裏又有了一次簽名校驗方法，因此還得手動的修改，修改方法和上面相似，把這個p方法改一下便可：

修改爲功以後，再次回編譯重簽名安裝運行，惋惜的是仍是卡住了，進不了遊戲，這時候咱們在次抓包看看：

此次比以前多了一個config_v3_android請求，可是仍是沒有get_user_info的請求！因此還得去看代碼邏輯，不過從請求結果來看，咱們以前的兩次簽名校驗修改已經有效果了，繼續看下面的代碼：

這裏能夠看到，有一個設置進度條的邏輯，並且有一個tag=999的日誌，貌似是取配置信息的進度條，那麼咱們能夠查看這個日誌信息：

看到了這個日誌信息以後，發現有開始取config到獲取成功config了，可是後面就沒有日誌了，因此這裏猜測應該是在本地解析這個配置信息的時候還有判斷，咋們全局搜一個字符串信息」getConfigAndroid「：

第一條信息就是咱們想要的，點擊進入：

果真這裏還有一個判斷，進入查看：

又是一次簽名校驗的邏輯，好吧，還得再一次改這個com.wepie.snake.helper.b.a.i()方法了：

修改爲功以後，再次回編譯二次簽名安裝運行便可，此次終於運行成功，進入遊戲界面了。

3、簽名校驗破解方案

好了，到這裏咱們來總結一下關於如何解決應用二次簽名校驗的問題：

第一步：先在Jadx中打開應用以後，全局搜字符串內容：」signatures」，這個就能夠定位到獲取應用簽名信息的地方了，而後能夠依次跟蹤校驗的地方了。

第二步：在第一步搜索結果比較多的狀況下，咱們能夠經過應用運行效果採用這兩種方式：

• 第一種方式：若是應用運行失敗，那麼多是在應用入口處做了簽名校驗邏輯，若是校驗失敗就退出程序。通常入口處是在Application的onCreate方法和attachBaseContext方法。
• 第二種方式：若是應用能夠運行，可是卡在某一個地方，咱們能夠採用抓包技術來分析應用運行到哪一步卡住了，由於如今的應用都會有請求的，若是是卡住了，那麼請求就會和原始包的請求不一樣，能夠根據不一樣的請求結果來跟蹤代碼邏輯，就好比本文的案例。

上面就是本人總結的簽名校驗的大體解決步驟和方法，可是確定還有其餘場景，好比有的應用會把簽名放到native層，可是這些校驗邏輯都是能夠作處理的，也有的應用把簽名信息放到服務端進行校驗，這個也是能夠處理的。放在native層的話，最終也是經過java層作鏈接訪問的，只要到了java層，那麼就能夠找到校驗方法的地方，放在服務端校驗，仍是能夠經過抓包查看請求來解決的。

4、簽名校驗破解後續

從上面看其實在給應用作防禦的時候，簽名校驗這種方式不是百分百的安全，只能防止一些破解小白。其實本文的案例中能夠發現，這個應用其實想經過多個地方的簽名校驗來作到全局校驗，本文中能夠看到咱們作了三次的簽名校驗方法代碼修改才成功的，並且後續版本也不排除他們還會繼續增長，以及在其餘地方邏輯處也作了簽名校驗判斷。

從本文中也能夠看到若是一個應用在不少地方都作了簽名校驗，那麼咱們手動修改會顯得很麻煩，其實這裏有這個思路：獲取應用的簽名方法是固定的：getPackageManager().getPackageInfo(getPackageName(), 64).signatures，咱們能夠直接修改應用的Application信息，經過反射機制，把校驗對象的字符串內容設置到signatures中，說白了就是用反射來修改應用的簽名信息，這樣在應用中全部獲取簽名的地方都是咱們設置的指定簽名值，也就是比對的那個常量字符串內容，全部的簽名校驗方法都是返回true了。這個思路本文再也不嘗試了，感興趣的同窗能夠嘗試。就是一個反射調用便可。有的同窗可能在想怎麼不用Xposed進行hook應用的簽名獲取方法那樣不就更簡單了。這裏必定要注意呀，咱們爲何要解決簽名校驗，就是由於咱們想二次簽名打包，而Xposed進行hook的時候是不須要二次打包的，主要hook點找到，不用進行二次打包安裝就能夠實現破解了。這兩種方式思路是不一樣的，要注意哈！

5、給應用安全防禦的意見

經過本文案例，其實對於如今應用防禦有這些建議：首先關於應用簽名校驗這塊邏輯，能夠作的更安全點，就是在native層用反射調用系統獲取簽名的方法，而後直接在native層進行比較，若是發現簽名不正確，就退出程序，所有放在native層作，這樣安全係數會高點！

可是這種也不是最安全的，安全點也就是考慮加固方案了，如今加固平臺不少，選擇企業版加固，對於破解難度那是確定會加大的。可是加固有一個弊端，就是崩潰率的問題，由於瞭解加固原理的同窗都知道，如今加固平臺都會涉及到so邏輯，而Android由於機型和系統版本複雜，致使兼容性很差，會有必定的加固崩潰率的，而對於一些用戶量比較多的應用和遊戲，他們沒法忍受這種崩潰率，那麼就放棄加固了。可是加固仍是一個相對安全的策略！

嚴重聲明：本文的目的只有一個，經過一個案例來分析如今應用的簽名校驗邏輯，如何破解這種校驗方式，若是有人利用本文內容進行任何商業目的和非法牟利，帶來的任何法律責任將由操做者本人承擔，和本文做者沒有任何關係，因此仍是由衷的但願你們秉着技術學習的目的閱讀此文，很是感謝！

6、總結

本文經過一個案例分析了應用簽名信息校驗的防禦策略破解，最後也總結了如今這種簽名校驗防禦策略的弊端和改進的地方，如何作到安全係數比較高的防禦。可是也不是最安全的，由於沒有絕對的安全！安全和逆向是相互進步！共同促進社會進步和技術革新！