之前已經寫了一個爆破簽名校驗的工具kstools，很多同學也在使用，但是也反饋了不少問題，之前一篇文章也介紹了，關於爆破之后第三方登錄問題修復，這篇我們在綜合說明一下一些后遺症問題，關於kstools工具說明以及工具的原理，可以看這篇文章說明：Android中自動爆破簽名工具kstools說明。
二、樣本分析
下面開始進入正題吧，關於有些同學反饋，使用該kstools爆破某app之后，出現無限制重啟問題，關於這個問題，我沒見過，很好奇就是嘗試了這個樣本案例：
看到了，的確是這樣的，無限制重啟。我們使用Jadx打開使用kstools處理過的樣本看看hook是否成功：
這里可以看到，我們hook是成功的，所以應該不是hook的問題導致的，所以這里就需要借助開發經驗了：記住如果在破解過程中發現應用重啟或者閃退的時候，要第一時間想起來是否程序內部做了異常捕獲，然后自己做了一些操作導致這樣的結果。
本文案例就是這個原因導致的，所以我們得先把應用自己捕獲全局異常功能給關閉，這樣會出現系統崩潰異常信息，這樣定位問題就簡單了，對於Android中全局捕獲異常有一個特征就是這行代碼：
Thread.setDefaultU www.xyseo.net ncaughtExceptionHandler(this);
所以我們在Jadx中全局所有字符串即可：
這里看到了，他的確有這些代碼，然后我們直接在反編譯之后的smali代碼中找到這些地方，注釋這行代碼即可，然后在回編譯安裝運行，果然崩潰了，看崩潰日志信息：
是這個app內部用到了ormlite框架來操作數據庫的，具體信息就是Class類型不能轉化成String類型，我們通過這個堆棧信息跟蹤最后找到了出錯的地方：
這是個注解，看到這里doClass是Class類型，但是默認值卻是String類型，所以報錯了，但是這個為什么會這樣呢？我們用原始樣本看看：
這個才是正確的，所以我們猜想這個可能和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函數中：
這里就是先獲取全局的context變量，然后再去進行簽名校驗功能，這里有一個AppRuntime日志tag，我們可以打印我們爆破成功的日志：
看到這信息，說明已經騙過簽名校驗功能了，而這樣做是不是非常的方便了，沒必要再去分析代碼找到簽名校驗的地方了，所以這個工具還是很有用的，准確的說是這個爆破思想非常有用。
最后還想在說明兩點：
第一、有的同學說，這個工具對於加殼的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方法中添加即可。
kstools下載地址：https://www.jhyl1.cn/
HookPMS代碼下載地址：https://之前已經寫了一個爆破簽名校驗的工具kstools，很多同學也在使用，但是也反饋了不少問題，之前一篇文章也介紹了，關於爆破之后第三方登錄問題修復，這篇我們在綜合說明一下一些后遺症問題，關於kstools工具說明以及工具的原理，可以看這篇文章說明：Android中自動爆破簽名工具kstools說明。
二、樣本分析
下面開始進入正題吧，關於有些同學反饋，使用該kstools爆破某app之后，出現無限制重啟問題，關於這個問題，我沒見過，很好奇就是嘗試了這個樣本案例：
看到了，的確是這樣的，無限制重啟。我們使用Jadx打開使用kstools處理過的樣本看看hook是否成功：
這里可以看到，我們hook是成功的，所以應該不是hook的問題導致的，所以這里就需要借助開發經驗了：記住如果在破解過程中發現應用重啟或者閃退的時候，要第一時間想起來是否程序內部做了異常捕獲，然后自己做了一些操作導致這樣的結果。
本文案例就是這個原因導致的，所以我們得先把應用自己捕獲全局異常功能給關閉，這樣會出現系統崩潰異常信息，這樣定位問題就簡單了，對於Android中全局捕獲異常有一個特征就是這行代碼：
Thread.setDefaultUncaughtExceptionHandler(this);
所以我們在Jadx中全局所有字符串即可：
這里看到了，他的確有這些代碼，然后我們直接在反編譯之后的smali代碼中找到這些地方，注釋這行代碼即可，然后在回編譯安裝運行，果然崩潰了，看崩潰日志信息：
是這個app內部用到了ormlite框架來操作數據庫的，具體信息就是Class類型不能轉化成String類型，我們通過這個堆棧信息跟蹤最后找到了出錯的地方：
這是個注解，看到這里doClass是Class類型，但是默認值卻是String類型，所以報錯了，但是這個為什么會這樣呢？我們用原始樣本看看：
這個才是正確的，所以我們猜想這個可能和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函數中：
這里就是先獲取全局的context變量，然后再去進行簽名校驗功能，這里有一個AppRuntime日志tag，我們可以打印我們爆破成功的日志：
看到這信息，說明已經騙過簽名校驗功能了，而這樣做是不是非常的方便了，沒必要再去分析代碼找到簽名校驗的地方了，所以這個工具還是很有用的，准確的說是這個爆破思想非常有用。
最后還想在說明兩點：
第一、有的同學說，這個工具對於加殼的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方法中添加即可。
kstools下載地址：http://www.ysylcsvip.cn/
HookPMS代碼下載地址：http://www.lieqibiji.com/
五、總結
關於簽名爆破就講這么多了，而這個工具也希望大家多多使用提意見，特別是在處理失敗的時候記得將失敗樣本發給我，本文也提到了一個破解的經驗就是出現閃退或者重啟問題記得想起全局捕獲異常功能代碼。把這部分代碼注釋就可以看到錯誤信息，然后在詳細跟蹤解決問題即可，看完文章，記得多多點贊分享哈！
五、總結
關於簽名爆破就講這么多了，而這個工具也希望大家多多使用提意見，特別是在處理失敗的時候記得將失敗樣本發給我，本文也提到了一個破解的經驗就是出現閃退或者重啟問題記得想起全局捕獲異常功能代碼。把這部分代碼注釋就可以看到錯誤信息，然后在詳細跟蹤解決問題即可，看完文章，記得多多點贊分享哈！