Android中破解應用簽名校驗的後續問題處理方案(閃退和重啟現象以及無效問題)...

weixin_34185560發表於2017-07-03

一、前言
之前已經寫了一個爆破簽名校驗的工具kstools,很多同學也在使用,但是也反饋了不少問題,之前一篇文章也介紹了,關於爆破之後第三方登入問題修復,這篇我們在綜合說明一下一些後遺症問題,關於kstools工具說明以及工具的原理,可以看這篇文章說明:Android中自動爆破簽名工具kstools說明

二、樣本分析
下面開始進入正題吧,關於有些同學反饋,使用該kstools爆破某app之後,出現無限制重啟問題,關於這個問題,我沒見過,很好奇就是嘗試了這個樣本案例:

2241150-f9b27753e70bce10

看到了,的確是這樣的,無限制重啟。我們使用Jadx開啟使用kstools處理過的樣本看看hook是否成功:
2241150-10a8fdf987620cb1

這裡可以看到,我們hook是成功的,所以應該不是hook的問題導致的,所以這裡就需要藉助開發經驗了:記住如果在破解過程中發現應用重啟或者閃退的時候,要第一時間想起來是否程式內部做了異常捕獲,然後自己做了一些操作導致這樣的結果。

本文案例就是這個原因導致的,所以我們得先把應用自己捕獲全域性異常功能給關閉,這樣會出現系統崩潰異常資訊,這樣定位問題就簡單了,對於Android中全域性捕獲異常有一個特徵就是這行程式碼:
Thread.setDefaultUncaughtExceptionHandler(this);
所以我們在Jadx中全域性所有字串即可:

2241150-461736e94aba58de

這裡看到了,他的確有這些程式碼,然後我們直接在反編譯之後的smali程式碼中找到這些地方,註釋這行程式碼即可,然後在回編譯安裝執行,果然崩潰了,看崩潰日誌資訊:
2241150-2e558142076b9cb9

是這個app內部用到了ormlite框架來操作資料庫的,具體資訊就是Class型別不能轉化成String型別,我們通過這個堆疊資訊跟蹤最後找到了出錯的地方:
2241150-82d2922a5f981276

這是個註解,看到這裡doClass是Class型別,但是預設值卻是String型別,所以報錯了,但是這個為什麼會這樣呢?我們用原始樣本看看:
2241150-666b625e13c4c5c1

這個才是正確的,所以我們猜想這個可能和kstools工具操作有關,因為kstools工具的操作步驟是:
解壓apk=>獲取dex=>轉化成jar(插入hook程式碼)=>轉化成dex=>塞入apk=>簽名apk
而這個過程中,特別是在dex轉化成jar,然後在轉化成dex,應該是這個過程導致這個問題。所以這裡為了解決這個問題,我們還得按照這個工具的原始手動操作一下,不瞭解的同學可以看這篇文章:Android中爆破簽名校驗新姿勢,這樣操作時候,會發現這個註解不會有問題了,而且簽名也爆破成功了,執行正常了。

三、問題說明總結
到這裡,本文內容就介紹完了,其實就是想說明一個問題也是破解過程中的一個經驗值:在應用二次簽名跑的時候發現閃退或者重啟,也沒有什麼錯誤資訊的時候,要想到可能是應用本身做了捕獲全域性異常的功能導致,所以只需要把這塊功能註釋即可看到詳細的錯誤資訊,然後在定位解決問題即可。
當然通過這個樣本我們也發現了kstools這個工具的弊端,這個也有同學說了就是操作過於複雜,其實沒必要將dex轉化成jar然後在轉成dex的,耗時而且最大的問題在於可能在轉化過程中出錯,操作多的同學會發現有時候在dex轉化成jar或者是jar轉化成dex會出現一些錯誤資訊。導致後面無法進行了。這個是工具的最大弊端。所以繼續優化這個工具,已經更新到github上了,直接將dex轉化成smali,然後進行操作即可,這樣的好處是原始的在android基礎上進行操作了,不會帶來一些爆破後遺症了,比如本文案例用這種方式肯定就不會有問題了。

四、疑問解答
在很多同學使用這個工具或者用這種思想去爆破,提出這個問題就是如果將簽名驗證放到程式最開始入口,然後放到native層,這樣就會爆破失敗了,這裡我再說明一下,就是這個爆破的思想是hook程式的pms服務,然後攔截獲取簽名資訊的方法,而加入hook的程式碼已經是最開始的入口了,一般是attachBaseContext方法了,那麼及時你在native層最開始入口,比如是JNI_ONLoad函式中也是無效的。有的同學又說了?那可以把載入so放到程式的入口Application的靜態程式碼塊中,這樣時機是最早的了,其實想一想這樣的確是最早,但是能在這裡校驗簽名嗎?要知道校驗簽名可能得用應用的context變數獲取資訊,你在靜態程式碼塊中是無法拿到這個變數的,及時你在native層也是一樣,所以在靜態程式碼塊中提前load原生程式碼是不行的。比如這個樣本案例,校驗就在JNI_OnLoad函式中:


2241150-a6c2aa2320559c4e

這裡就是先獲取全域性的context變數,然後再去進行簽名校驗功能,這裡有一個AppRuntime日誌tag,我們可以列印我們爆破成功的日誌:


2241150-ae73ba427f9bc64c

看到這資訊,說明已經騙過簽名校驗功能了,而這樣做是不是非常的方便了,沒必要再去分析程式碼找到簽名校驗的地方了,所以這個工具還是很有用的,準確的說是這個爆破思想非常有用。

最後還想在說明兩點:
第一、有的同學說,這個工具對於加殼的app沒用,就意義不大了,首先說明並非所有的應用都會加固,特別是大型應用,因為加固有分享,他們未必採用加固,其次是,現在有很多應用不僅加固了,還做了簽名校驗,所以如果你脫殼成功還可以藉助這個工具進行操作了。
第二、通過最近同學給我反饋的使用意見和問題,這裡就總結一下使用流程:
1、首先你的樣本案例如果是加固的,那麼請你先脫殼,脫殼之後在使用kstools工具,具體用法有說明。
2、如果對於一些非加固的應用在使用的過程中可能會出現爆破失敗,比如kstools工具使用報錯,簽名校驗爆破失效,程式閃退重啟等問題,那麼可能和kstools工具有關,所以這時候可能要手動的去新增hook程式碼了,這個我在前面的文章中也提到了操作流程了。最後如果還是不行,那麼可以把樣本發給我,我幫忙檢視。

關於手動新增hook程式碼步驟這裡在說一下大致流程:
首先去github/fourbrother/HookPmsSignature下載最新的hook程式碼,自己編譯得到一個apk之後,反編譯得到對應的smali程式碼,然後將其拷貝到需要破解的apk反編譯原始碼目錄下,然後在爆破app入口類新增hook程式碼呼叫,可以參見HookPmsSignature中的MyApplication/MyActivity類中的呼叫方式。注意hookPMS方法中的簽名和包名需要改成你想要破解app的對應資訊,關於應用入口可以在XML清單檔案中檢視,如果有Application類,直接在程式碼類中的方法attachBaseContext或者onCreate方法新增,如果沒有就找到入口的Activity類,在其onCreate方法中新增即可。


2241150-3423b181a17d1fd6

kstools下載地址:https://github.com/fourbrother/kstools
HookPMS程式碼下載地址:https://github.com/fourbrother/HookPmsSignature

五、總結
關於簽名爆破就講這麼多了,而這個工具也希望大家多多使用提意見,特別是在處理失敗的時候記得將失敗樣本發給我,本文也提到了一個破解的經驗就是出現閃退或者重啟問題記得想起全域性捕獲異常功能程式碼。把這部分程式碼註釋就可以看到錯誤資訊,然後在詳細跟蹤解決問題即可,看完文章,記得多多點贊分享哈!

更多內容:點選這裡

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

2241150-787965362b25c348

編碼美麗技術圈
微信掃一掃進入我的"技術圈"世界
2241150-232a8ed33198872c

掃一掃加小編微信新增時請註明:“編碼美麗”非常感謝!
2241150-61e76c201ac5cab3

相關文章