APK簽名替換檢測

APK二次打包的危害

APK二次打包是Android應用安全風險中的一部分， 通常是經過反編譯工具嚮應用中插入廣告代碼與相關配置，再在第三方應用市場、論壇發佈。打包黨對移動App帶來的危害有如下幾種：

1. 插入本身廣告或者刪除原來廣告；
2. 惡意代碼, 惡意扣費、木馬等；
3. 修改原來支付邏輯；

上述惡意行爲嚴重危害移動產品和用戶利益，同時也影響企業口碑。

APK的簽名機制

Google設計APK的簽名機制就是防止兩個問題：

• 不讓別人修改APK包，防止反編譯後二次打包；
  怎麼作到不讓別人二次打包呢？Android系統在安裝APK時，會先去確認是否有簽名、簽名是否能對上；
• Android系統在安裝APK包時，不容許安裝同一個包名可是簽名不同的APK；

下面開始分析APK打簽名的流程：

須要瞭解的背景知識

自行去百度，瞭解概念便可；

• 數據摘要（數據指紋）、MD5\SHA-1對稱加密算法
• 非對稱加密算法
• 數字簽名、數字證書
• 手動簽名APK包

1.查看META-INF文件

將.apk包修改後綴成.zip，解壓以後打開該文件夾，找到META-INF目錄。

簽名就是圍繞這三個文件開始的。

2.先看第一個文件MANIFEST.MF

這個文件裏面包括了APK文件中全部文件的數據摘要值。至關於對每一個單獨（除了這三個）的文件都作了數據指紋。

3.在看第二個文件CERT.SF

和MANIFEST.MF文件差很少，惟一的差異在於，多了一行SHA1-Digest-Manifest: KDerPmANkkB5mxceo/t5oXRGApg=，這行就是MANIFEST.MF的數據摘要。

4.最後看第三個文件CERT.SF

把以前的CERT.SF文件用私鑰計算出一個加密值，這個加密值稱爲簽名，因此這個文件包含了簽名和公鑰；

若是是在Windows系統下，推薦使用cmder.exe軟件使用以下命令。

D:\ProgramFiles\cmder>openssl pkcs7 -inform DER -in "C:\app-debug - 副本\META-INF\CERT.RSA" -noout -print_certs -text
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=Android Debug, O=Android, C=US
        Validity
            Not Before: Dec 27 09:26:22 2018 GMT
            Not After : Dec 19 09:26:22 2048 GMT
        Subject: CN=Android Debug, O=Android, C=US
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:89:e0:b4:29:a9:62:b1:44:48:b8:35:f2:8a:06:
                    91:c7:36:44:1a:d2:b3:97:fd:58:b5:84:35:fc:83:
                    09:50:f5:85:83:d9:bc:12:a8:da:da:cf:f0:10:d0:
                    4d:9f:a5:9d:7f:de:b6:4e:1e:94:36:c4:f4:44:45:
                    4e:44:f5:97:9f:f3:62:3f:5f:9d:ce:a6:18:73:22:
                    62:28:79:f7:46:f8:d6:f7:ca:46:e3:3f:dd:a8:ac:
                    b7:aa:cb:77:7c:47:16:89:d1:d5:f8:47:e5:21:28:
                    87:f8:a6:dd:ee:ed:01:da:b5:06:49:04:19:49:46:
                    d8:0a:a6:bb:b4:b5:c9:56:79
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha1WithRSAEncryption
         79:3c:29:c5:3c:e7:d8:28:e1:5c:2a:1d:ce:31:cb:e6:a5:09:
         d0:10:d8:e5:74:e9:b5:80:4a:63:76:f4:67:ee:8c:f1:eb:04:
         8f:23:f4:f6:c2:f7:a5:99:af:c5:be:8f:70:6d:dc:3e:b3:db:
         ca:b2:64:e1:0c:ca:ce:fe:16:1f:3b:00:83:b5:f8:be:8a:b4:
         7e:a9:94:fe:77:1f:67:ff:4f:54:87:66:f4:97:be:ce:38:54:
         51:b4:ce:a8:23:60:92:e3:bf:5d:21:11:50:c9:c2:40:b4:69:
         89:fe:4f:66:84:17:42:91:af:af:bd:e9:47:24:f8:db:74:70:
         d0:87

證書內容概況：

用來管理私鑰倉庫的命令：

D:\ProgramFiles\cmder>keytool -printcert -file "C:\app-debug - 副本\META-INF\CERT.RSA"
全部者: C=US, O=Android, CN=Android Debug
發佈者: C=US, O=Android, CN=Android Debug
序列號: 1
有效期爲 Thu Dec 27 17:26:22 CST 2018 至 Sat Dec 19 17:26:22 CST 2048
證書指紋:
         MD5:  41:41:89:25:4C:9B:91:6D:16:91:20:6C:1D:D7:61:2F
         SHA1: 73:FC:5A:9F:5D:7A:CC:93:14:8D:F1:13:37:E6:11:C2:86:A4:3D:34
         SHA256: 32:33:24:4F:1C:4E:6E:78:3F:F2:C4:59:CD:19:9F:43:BC:AC:1A:23:CB:78:72:9A:0E:61:C9:B3:5D:4C:B9:C1
簽名算法名稱: SHA1withRSA
主體公共密鑰算法: 1024 位 RSA 密鑰
版本: 1

總結

APK生成後簽名不能更改，由於沒有私鑰。但能替換籤名，由於Android系統在安裝APK的時候只校驗簽名的正確性。

一個apk文件，經過使用AndroidKiller二次編譯，我對比了原APK和編譯後的APK的./META-INF/CERT.RSA文件，發現確實是被替換了。

簽名的過程能夠想象成發件人和收件人的處理流程，也是一個雙向的動做，能夠大體理解成下圖流程：

能夠把上圖的客戶1替換成打包APK的過程，把服務器替換成Android手機安裝APK的過程，當系統拿着CERT.RSA裏面的公鑰和apk原文解密出的Hash值和CERT.SF文件裏面的Hash值不一致時，就不會去安裝。

檢測是否能替換籤名

二次打包成功的前提是能替換籤名，而且APK沒作簽名校驗。而簽名驗證的方式有三種：

• APK包沒有作簽名校驗
  直接替換籤名便可，下面將介紹替換籤名的步驟；

• APK包作了簽名校驗
  • java代碼校驗
    難點在於找到校驗的JAVA代碼，註釋掉便可；
  • .so文件校驗
    難點在於找到校驗的C代碼，註釋掉便可；
  • 加殼
    難點在於得先脫殼；

替換籤名步驟

工具：
AndroidKiller_v1.3.1 （下載地址：https://www.52pojie.cn/thread-319641-1-1.html）

步驟：
使用AndroidKiller_v1.3.1工具，裏面有個編譯功能，就能作到二次打包，原理就是替換籤名值。

我通常修改版本號來證實能二次打包：
反編譯後在AndroidManifest.xml 裏直接修改版本號，若是在AndroidManifest.xml文件中沒法看到 versionCode和versionName字段，則在apktool.yml文件中打開找到，對應修改versionName字段的數字大小便可。

修復方式

1. SO層校驗簽名
2. 網絡校驗簽名
3. APK加固