1. 程式人生 > >一號店簽名爆破&應用啟動速度優化方案X2C&修改系統類載入器&另類啟動元件方式

一號店簽名爆破&應用啟動速度優化方案X2C&修改系統類載入器&另類啟動元件方式

一、前言

今天的套路和之前不同,因為最近看到了一些零散的知識,我不想一些簡單的知識單獨寫一篇文章,因為我想要的是每篇文章都能讓你們看很長時間,這樣我一週發一篇才算合理,所以本文就把四個零碎的不太熟知的知識點介紹一下吧:

第一、如何將一號店應用簽名爆破

第二、應用啟動速度優化方案X2C工具

第三、如何修改Android中的類載入器

第四、如何快速啟動Android中的四大元件

二、如何爆破「一號店」應用簽名

首先來看一號店的簽名爆破功能,為什麼會無意中想起來爆破一號店呢?因為之前無意中在小密圈裡面有人問過一個問題就是一號店的防Xposed的hook功能很厲害悄無聲息的讓你的日誌無法列印,所以對於這種樣本就非常感興趣就嘗試去弄,不過還沒弄好但是無意中發現他的簽名爆破倒是可以先爆破一下,說起簽名爆破大家首先想到的就是我的kstools工具,其實我也是這麼想的,不過用了還是不好使,所以就去分析程式碼,因為二次打包之後啟動就閃退,這個問題我之前介紹過,這個一般閃退的話校驗程式碼肯定是在Application中,看這裡主要看三部分:靜態程式碼塊,attachBaseContext方法,onCreate方法

;我們用Jadx開啟應用:

attachBaseContext這個方法沒啥問題,可以忽略了,接著看onCreate方法:

onCreate方法中有很多邏輯,不過通過分析可疑點都不是校驗的地方,大家可以自行點選跟蹤檢視程式碼,最後是靜態程式碼塊了:

最後看到靜態程式碼塊中載入了一個so檔案,通過檔名也發現這個地方可疑,而通過上面的排除法,可以非常肯定就是這個模組的校驗問題了,同時也告訴大家Xposed的防護也是在這裡的,不過這個程式碼我們不去看,告訴大家一個簡單的方法就是嘗試先把這個so載入程式碼註釋了,為什麼可以這麼做呢?因為如果這個so只是單純的校驗安全功能的,而不會影響應用的後續執行邏輯,註釋掉肯定是沒啥問題的,因為這個也是嘗試所以就註釋掉,在打包看看效果:

看到了不閃退了,但是有這個提示不過這個不要怕了,這時候再去用kstools一下就好了:

訪問的時候都會攜帶簽名信息的,所以看到整個爆破過程非常簡單,這裡一定要注意先用kstools操作然後在註釋那個載入so的程式碼,因為kstools需要獲取原始簽名信息的。

總結:以後遇到簽名信息先用kstools操作一下,如果不行就去看看程式的入口Application類的三個地方,發現可以程式碼;不過現在很多都把校驗放到so中操作了,所以如果so中的邏輯不影響後續程式執行的邏輯可以直接註釋載入邏輯,這樣就可以過掉校驗邏輯了,比如這裡的so中就是校驗操作,但是又不會影響後續的邏輯所以可以直接註釋!

三、應用啟動速度優化佈局方案

上面的簽名爆破邏輯介紹完了,接下來看第二件事就是應用的啟動速度優化問題,這個跨度有點大不過沒關係我們能學到東西就好,我們在做應用的時候是非常看重應用的啟動速度的問題,這裡只是介紹一個點就是如何對介面的載入優化,我們知道現在很多應用的首頁都有很多元素而且xml佈局非常複雜,這樣啟動之後系統會載入xml檔案,然後解析xml檔案最後是通過Class.forName載入控制元件類,這個過程是很耗時間的,而且元素很多就更加耗時了。有的同學可能會說那很簡單就是對於首頁直接進行程式碼佈局,這樣就好多了,的確優化的最終方案就是程式碼編寫佈局的,但是不是我們手動的去編寫因為這樣手動編寫程式猿受不了後面維護的人也受不了。這也是Android中不建議程式碼佈局的原因。那不手動編寫該怎麼編寫呢?這個就是掌閱公司出了一個X2C框架,這個框架其實原理非常簡單,在應用編譯期會藉助註解處理器把系統解析xml等後續的工作提前做了,這樣就會自動生成xml中的所有View控制元件,在應用啟動的時候就會先去找程式碼中已經定義好的控制元件;這樣就會在編譯期專案中多了一些中間類檔案,這個和專案中的R檔案非常類似,所以為了應用包大小以及相容問題,不會對專案中的所有介面都用這種方式去處理,而是對於一些需要優化啟動速度的頁面進行處理即可:https://github.com/iReaderAndroid/X2C

總結:這個框架對於介面複雜的啟動邏輯有效果,不是把整個專案都用這種方式處理,那麼無形中增加了很多中間類,同時相容性也不一定好。我們的目的就是為了啟動速度優化而已。核心技術就是利用註解處理器在編譯期間提前生成控制元件類。

四、如何修改類的載入器

上面說完了第二件事啟動速度優化問題,接著介紹第三件事就是如何修改類載入器,這個問題也是在小密圈裡面有人提問如何修改系統的類載入器,因為系統中有一些方法呼叫會判斷是否是系統類載入器載入的類,如果不是呼叫失敗的也是系統為了安全考慮,所以這裡我們就來看看如何修改;其實這種操作肯定是在Native層做了,我們通過檢視程式碼art/runtime/mirror/class.h:

這裡有一個方法可以設定類載入器,不過接受的是ObjPtr型別,繼續檢視這個型別,找到一個函式可以把jclass轉化成這個型別:

這裡有一個ToClass函式可以轉換操作,到這裡我們就找到了兩個關鍵函式就可以操作了,我們把需要改變類載入器的類傳遞到Native層的jclass進行轉換即可,不過按照國際慣例呼叫系統函式,肯定需要去看system/lib/libart.so中找到呼叫函式的匯出地址,然後用dlopen和dlsym函式呼叫即可:

接下來程式碼就簡單了:

然後上層呼叫即可:

最後列印執行看一下效果:

類載入器的確變成了系統載入器了,這樣我們就成功的修改了一個類的載入器為系統的了,那麼就解決了小密圈裡面的那位同學的問題了,當然這個技術和知識點大家也要記住,因為後面肯定有這需求。

總結:以後記住可以修改類的載入器了,不是用Java方法,而是通過Native層去操作。把自己的類變成系統類來欺騙系統,這樣就可以做一些壞事了。

五、如何快速啟動元件

好了介紹完了第三件事修改類載入器,接下來在介紹一個黑科技就是如何快速的啟動系統元件也就是activity等,這個有的同學好奇了?這個能怎麼快呀而且為什麼要快呀?這個你記住未來的某一天你肯定有這個需求,所以你就記住這個技術就好了,接下來介紹怎麼快,這個當然又要說activity的啟動流程了,前面的流程不多說了,直接說重點:

在系統類:frameworks\base\core\java\android\app\ActivityManagerNative.java 程式碼中看到最終的啟動activity需要獲取很多訊息,那麼如果想要加速啟動,有一些資訊是否可以不用獲取呢?進而節約時間,然後我們我們就嘗試一個一個引數新增:

只要傳遞這幾個引數就可以啟動了,然後我們在用反射獲取ActivityManagerNative中的Binder物件用於啟動邏輯:

最後直接啟動即可:

然後這樣就可以比正常快了啟動,通過多次測試發現比正常的啟動速度快了10ms,有的同學會說就10ms也沒什麼用呀?其實不然有時候我們做一些事情需要和系統搶時間,手機硬體很好10ms可以做很多事情了,不要小看這10ms哦。

總結:記住這個技術用非正常方式啟動元件是為了更快的和系統搶時間,特定需求以後一定會用到。只要比系統的一些邏輯執行快我們可以做一些壞事。

本文的目的只有一個就是學習更多的逆向技巧和思路,如果有人利用本文技術去進行非法商業獲取利益帶來的法律責任都是操作者自己承擔,和本文以及作者沒關係,本文涉及到的程式碼專案可以去編碼美麗小密圈自取,歡迎加入小密圈一起學習探討技術

六、總結

本文介紹的知識是沒有相互關係的,但是都是比較冷的黑科技技術,大家可能看了之後發現並不會用到,但是請記住有這些技術可以做一些事,以後遇到一些問題可以想到這一篇文章即可,感謝小密圈的同學們提的問題,定時會在小密圈裡收集問題有空就研究一下自己學習和大家分享,小密圈是一批大神和熱愛學習的人聚集地。

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

點選立即購買:京東  天貓  

更多內容:點選這裡

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