Android加固和簽名的那些坑(防掉坑技巧)

上個月公司一個專案突然要找第三方進行安全漏洞的檢測,於是打包了一個apk檔案,發到第三方結構進行了安全檢測,這專案我入職前就已經快完成的階段,我後面基本是維護和小更新.比較坑的是之前的哥們連混淆都沒有,更不要說加固了,最後掃出了30多個漏洞,看到檢測報告都懵逼了.

自己對混淆和加固之前也只是知道皮毛沒有深究,這次修復漏洞踩了不少坑,都是邊上網搜資料邊踩坑,總算搞定了,寫出來防止後人踩坑,這裡主要講加固簽名的坑,混淆這裡不說了(自己對混淆還不熟)

---

混淆簽名匯出

• Q: 進行混淆,怎麼混淆?

  A: 我也是不太熟簡單說一下自己的做法,先google一下常用的第三方框架的混淆程式碼找到自己需用的,剩下不常用的就上專案引用的框架對應的github專案地址找對應的混淆程式碼.

• Q: 匯出的時候怎麼選v1和v2?區別在哪?

  A: 我自己是把v1和v2都勾上,區別是v1是7.0之前就存在的簽名方式,v1相比v2安全係數要低,建議打包的時候v1和v2都勾上,只勾其中一個有可能會出現相容問題,具體自己上網查

加固

• Q: 怎麼加固?

  A: 網上很多加固方式 (360,愛加密,梆梆..)都是傻瓜式的操作,可以找自己合適的.

• Q:加固有哪些坑?

  A: apk進行加固之後簽名資訊都會丟失,加固完成之後要對apk重新進行簽名,沒有簽名的apk是不能在手機上跑的

  A: 我開始用的是某數字公司的加固,加固完重新簽名就發給第三方機構檢測了,報告說我沒有進行v2簽名,一直很懵逼,明明勾了v2的簽名為什麼一直說我沒進行v2簽名,最後發現原來有些公司的提供的簽名工具不支援v2簽名,你用了他的簽名工具他會說你簽名成功,但實際上他只進行了v1的簽名,真的很蛋疼,也不說明一下.

自己進行簽名檢查和加固後重新對apk進行簽名

檢查是否簽名成功:

方法1:利用android sdk自帶的工具

• 用命令列進入本地的Android sdk目錄(我用的是mac) 地址如下 cd /Users/使用者名稱/sdk/build-tools/27.0.3/lib

  • 27.0.3是你的自己的sdk版本,不一定和我一樣

• 檢查是否簽名成功 java -jar apksigner.jar verify -v my.apk (my.apk為本地安裝包的路徑)

  • 如果出現:mac 下終端訪問檔案出現“Permission Denied”解決方案的話:

  • 一個檔案有3種許可權，讀、寫、可執行，你這個檔案沒有可執行許可權，需要加上可執行許可權。

  • 終端下先cd到該檔案的目錄下,執行命令 chmod a+x ./apksigner.jar(檔名)

  • 重新執行步驟2檢查是否有簽名,會出現下面類似的結果:

    • Verifies
    • Verified using v1 scheme (JAR signing): true //已進行v1簽名
    • Verified using v2 scheme (APK Signature Scheme v2): false //沒有進行v2簽名

很容易理解,ture是已簽名,false是未簽名,都為true的話說明v1,v2都成功簽名了.

方法2:

• 下載GetApkInfo.jar

• 用命令列進入GetApkInfo.jar檔案目錄 cd /Users/xxxx/GetApkInfo.jar

• 執行 java -jar GetApkInfo.jar my.apk檢查是否有v2簽名

  • 如果出現:mac 下終端訪問檔案出現“Permission Denied”解決方案的話:

  • 一個檔案有3種許可權，讀、寫、可執行，你這個檔案沒有可執行許可權，需要加上可執行許可權。

  • 先cd到該檔案的目錄下,執行命令 chmod a+x ./apksigner.jar(檔名)

  • 再次執行 java -jar GetApkInfo.jar my.apk

       執行結果: 成功
       應用資訊: 
       包名: com.xxx.xx.xx
       版本名: 2.0.1
       版本號: 2
       簽名檔案MD5: e093xxxb53xxxxxf5bxxxe17xxx7d
       V1簽名驗證通過: true
       使用V2簽名: true
       V2簽名驗證通過: true
    

• 如果你要確保自己沒用錯簽名檔案(雖然一般不會這麼智障)這種方法比較適合你,能看到已簽名的md5值

• keytool -v -list -keystore /Users/xxxx/MyAPP/test.jks(路徑是你的進行簽名的祕鑰路徑)

    有效期開始日期: Mon May 08 09:35:21 CST 2017, 截止日期: Fri May 02 09:35:21 CST 2042
    證照指紋:
         MD5: E0:93:xx:xx:xx:22:xx:xx:xx:5F:xx:xx:xx:xx:15:7D
         SHA1: xx:xx:xx:xx:xx:xx:C0:A4:xx:33:6Exx02:80:xx:DA:xx:xx:5F:xx:C3
         SHA256: 39:xx:3A:xx:xx:BA:xx:A8:6C:xx:D0:C6:xx:BC:xx:76:25:xx:xx:A3:86:xx:xx:A0:xx:E8:xx:xx:4F:xx:xx:9C
         簽名演算法名稱: SHA256withRSA
         版本: 3 
  

然後把兩個md5的值進行比對,如果一致說明你的簽名沒用錯祕鑰 - -||

4.手動進行簽名操作:

• 進入本地的sdk目錄 cd /Users/xxxx/sdk/build-tools/27.0.3/lib
• 執行簽名操作:

java -jar apksigner.jar sign --ks /Users/xxxx/Desktop/key.jks --ks-key-alias test --ks-pass pass:123456 --key-pass pass:123456 --out /Users/xxxx/Desktop/簽名後的安裝包.apk /Users/xxxx/Desktop/需要進行簽名的安裝包.apk

上面的命令會執行同時執行v1,v2簽名

注意仔細看上的命令列:進了黑色加粗的文字需要替換成實際的資訊

• 第一個加粗的是祕鑰的路徑
• 第二個是祕鑰的別名
• 第三個是祕鑰的密碼
• 第四個是祕鑰的密碼
• 第五個是進行了簽名的安裝包儲存的路徑
• 第六個是需要進行簽名的安裝包路徑

---

說個小插曲,我們的專案找的是一個規模很大的公司進行檢測,開始用了網上的免費的加固工具加固拿去檢測,別人拿去測試之後全部都脫殼了,說這種免費的加固安全沒有保障,要用他們的加固服務可以解決,要收費..呵呵,因為專案比較特殊只能答應了,打包簽名了apk,發到他們那邊進行了加固後他們把apk發回來讓我重新簽名,簽名後apk用不了,閃退....老闆說別人大公司應該不會出現這種小問題,是我的問題.恩,自己也懷疑是我的錯. 當天折騰到凌晨才下班,經歷了上面的一頓折騰後發現v1,v2都簽名了,並且md5值也沒問題. 這時就有底氣的去質問那家公司,最後發現是他們的加固出問題.

一般來說進行了上面的方法重新簽名並且檢查md5值沒錯,應該不會出問題了這時候可以去質疑一下加固方的問題.

github參考連結1

github參考連結2

先寫這些記錄一下,後面有需要再更新,有什麼問題可以在下面留言討論.