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

來源:互聯網
上載者:User

標籤:介面   情況   技巧   校正   產生   返回   反射   解決問題   pac   

一、前言

在之前的文章中說過Android中的安全和破解是相輔相成的,為了防止被破解,很多應用做了一些防護策略,但是防護策略也是分等級,一般簡單的策略就是混淆代碼和簽名校正,而對於簽名校正很多應用都是會做的,一般現在就兩種方式:

第一種:簽名校正不通過直接退出程式,也就是你會發現回編譯二次打包運行失敗的現象

第二種:簽名校正不通過不觸發程式指定邏輯,導致沒有錯誤資訊,也進不了應用的現象

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

二、案例分析

上面分析完了之前一個解決簽名校正的案例,下面就用這個小遊戲作為簡單分析,這個遊戲在市場都可以下載到:


本文研究的是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()方法了:


修改成功之後,再次回編譯二次簽名安裝運行即可,這次終於運行成功,進入遊戲介面了。

三、簽名校正破解方案

好了,到這裡我們來總結一下關於如何解決應用二次簽名校正的問題:

第一步:先在Jadx中開啟應用之後,全域搜字串內容:”signatures”,這個就可以定位到擷取應用簽名資訊的地方了,然後可以依次跟蹤校正的地方了。

第二步:在第一步搜尋結果比較多的情況下,我們可以通過應用運行效果採用這兩種方式:

  • 第一種方式:如果應用運行失敗,那麼可能是在應用入口處作了簽名校正邏輯,如果校正失敗就退出程式。一般入口處是在Application的onCreate方法和attachBaseContext方法。
  • 第二種方式:如果應用可以運行,但是卡在某一個地方,我們可以採用抓包技術來分析應用運行到哪一步卡住了,因為現在的應用都會有請求的,如果是卡住了,那麼請求就會和原始包的請求不同,可以根據不同的請求結果來跟蹤代碼邏輯,就比如本文的案例。

上面就是本人總結的簽名校正的大致解決步驟和方法,但是肯定還有其他情境,比如有的應用會把簽名放到native層,但是這些校正邏輯都是可以做處理的,也有的應用把簽名資訊放到服務端進行校正,這個也是可以處理的。放在native層的話,最終也是通過java層做串連訪問的,只要到了java層,那麼就可以找到校正方法的地方,放在服務端校正,還是可以通過抓包查看請求來解決的。

四、簽名校正破解後續

從上面看其實在給應用做防護的時候,簽名校正這種方式不是百分百的安全,只能防止一些破解小白。其實本文的案例中可以發現,這個應用其實想通過多個地方的簽名校正來做到全域校正,本文中可以看到我們做了三次的簽名校正方法代碼修改才成功的,而且後續版本也不排除他們還會繼續增加,以及在其他地方邏輯處也做了簽名校正判斷。

從本文中也可以看到如果一個應用在很多地方都做了簽名校正,那麼我們手動修改會顯得很麻煩,其實這裡有這個思路:擷取應用的簽名方法是固定的:getPackageManager().getPackageInfo(getPackageName(), 64).signatures,我們可以直接修改應用的Application資訊,通過反射機制,把校正對象的字串內容設定到signatures中,說白了就是用反射來修改應用的簽名資訊,這樣在應用中所有擷取簽名的地方都是我們設定的指定簽名值,也就是比對的那個常量字串內容,所有的簽名校正方法都是返回true了。這個思路本文不再嘗試了,感興趣的同學可以嘗試。就是一個反射調用即可。有的同學可能在想怎麼不用Xposed進行hook應用的簽名擷取方法那樣不就更簡單了。這裡一定要注意呀,我們為什麼要解決簽名校正,就是因為我們想二次簽名打包,而Xposed進行hook的時候是不需要二次打包的,主要hook點找到,不用進行二次打包安裝就可以實現破解了。這兩種方式思路是不同的,要注意哈!

五、給應用安全防護的意見

通過本文案例,其實對於現在應用防護有這些建議:首先關於應用簽名校正這塊邏輯,可以做的更安全點,就是在native層用反射調用系統擷取簽名的方法,然後直接在native層進行比較,如果發現簽名不正確,就退出程式,全部放在native層做,這樣安全係數會高點!

但是這種也不是最安全的,安全點也就是考慮加固方案了,現在加固平台很多,選擇企業版加固,對於破解難度那是肯定會加大的。但是加固有一個弊端,就是崩潰率的問題,因為瞭解加固原理的同學都知道,現在加固平台都會涉及到so邏輯,而Android因為機型和系統版本複雜,導致相容性不好,會有一定的加固崩潰率的,而對於一些使用者量比較多的應用和遊戲,他們無法忍受這種崩潰率,那麼就放棄加固了。但是加固還是一個相對安全的策略!

嚴重聲明:本文的目的只有一個,通過一個案例來分析現在應用的簽名校正邏輯,如何破解這種校正方式,如果有人利用本文內容進行任何商業目的和非法牟利,帶來的任何法律責任將由操作者本人承擔,和本文作者沒有任何關係,所以還是由衷的希望大家秉著技術學習的目的閱讀此文,非常感謝!

六、總結

本文通過一個案例分析了應用簽名資訊校正的防護策略破解,最後也總結了現在這種簽名校正防護策略的弊端和改進的地方,如何做到安全係數比較高的防護。但是也不是最安全的,因為沒有絕對的安全!安全和逆向是相互進步!共同促進社會進步和技術革新!

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

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.