有什么方法可以检测APK应用程序是否签名异常呢

0x01 APK应用程序是否签名异常的检测方法

要在Android上安装APK必须要进行数字签名，数字签名用于验证应用程序更新的所有者身份，验证的目的是为了防止APK应用程序被篡改或修改APK来包含恶意代码

对 APK 进行签名时，会附加一个公钥证书，这个证书是将 APK 应用程序与开发者和开发者的私钥进行关联

注：在调试模式下构建应用时，Android SDK 会使用专门为调试目的创建的调试密钥对我们要打包的APK应用程序进行签名，需要注意使用调试密钥签名的应用并不会在大多数APK应用商店中被接受和允许上架

应用程序的最终发布版本(上线生产版本)必须使用有效的发布版本的密钥进行签名。在 Android Studio 中，APK可手动或通过创建分配给发布构建类型的签名配置来对应用进行APK的签名

Android 9（API 级别 28）之前的 Android 上，所有的应用程序更新都需要使用相同的证书进行签名，所以开发者可以考虑使用 25 年或更长的有效期

注：需要注意，如果在 Google Play 上发布的应用必须使用有效期在 2033 年 10 月 22 日之后结束的密钥进行签名

三种 APK 签名方案：

v1 方案：JAR 签名

v2 方案：APK 签名方案 v2

v3 方案：APK 签名方案 v3

与 v1 方案相比，Android 7.0（API 级别 24）及更高版本支持的 v2 签名，且提供了更高的安全性和性能。Android 9（API 级别 28）及以上版本支持的 V3 签名，使应用程序能够更改其签名密钥，作为APK 更新的一部分，此功能通过允许同时使用新/旧密钥，保证了兼容性和应用程序的持续可用性。需要注意对于每个签名方案，发布APK版本也应该始终通过之前内部评估好的方案进行签名

在做静态分析（当然动态分析时跟这个一样，将APK导出来用jarsigner或apksigner工具来验证APK的签名是否异常）APK时，我们要确认几个重要的信息，比如APK的发布版本是 Android 7.0（API 级别 24）及更高版本的 v1 和 v2 方案以及 Android 9（API 级别 28）及更高版本的所有三个方案进行签名，且 APK 应用程序中的签名证书是属于开发者的

我们可以使用 Android SDK 构建工具的修订版 24.0.3 及更高版本中提供的 apksigner 工具为 APK 签名，并确保 APK 的签名能够在 APK 支持的所有版本的 Android 平台上成功通过验证，此处我们是主要是利用apksigner 工具来验证APK的签名是否是属于正确的开发者的，apksigner 工具它的位置在[SDK-Path] /build-tools/[版本]。

我们可以使用apksigner工具来验证 APK的 签名，apksigner 默认安装位置位于：C:UsersxxxAppDataLocalAndroidSdkuild-tools33.0.0lib下，随后执行如下命令：

$ java -jar C:UsersxxxAppDataLocalAndroidSdkuild-tools33.0.0libapksigner.jar verify --verbose vuls.apk
Verifies
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): false
Verified using v3.1 scheme (APK Signature Scheme v3.1): false
Verified using v4 scheme (APK Signature Scheme v4): false
Verified for SourceStamp: false
Number of signers: 1

当然，我们也可以使用 jarsigner 工具来检查APK的签名证书的内容，但需要注意在调试证书时，Common Name (CN)属性要设置为 "Android Debug"

使用调试证书签名的 APK 的输出，这里我们使用JAVA自带的jarsigner工具来做签名，如何签名的命令如下：

$ jarsigner -verify -verbose -certs vuls.apk

sm      14112 Fri Nov 30 00:00:00 CST 1979 AndroidManifest.xml      >>> 签名者
      X.509, C=US, O=Android, CN=Android Debug      [证书的有效期为18-6-6 下午12:41至48-5-29 下午12:41]
      [无效的证书链: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]sm          6 Fri Nov 30 00:00:00 CST 1979 META-INF/android.arch.core_runtime.version      >>> 签名者
      X.509, C=US, O=Android, CN=Android Debug      [证书的有效期为18-6-6 下午12:41至48-5-29 下午12:41]
      [无效的证书链: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]sm          6 Fri Nov 30 00:00:00 CST 1979 META-INF/android.arch.lifecycle_livedata-core.version

（... ...此处省略一堆内容）     >>> 签名者
      X.509, C=US, O=Android, CN=Android Debug      [证书的有效期为18-6-6 下午12:41至48-5-29 下午12:41]
      [无效的证书链: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]


  s = 已验证签名 
  m = 在清单中列出条目
  k = 在密钥库中至少找到了一个证书
  i = 在身份作用域内至少找到了一个证书- 由 "C=US, O=Android, CN=Android Debug" 签名
    摘要算法: SHA1 (弱)
    签名算法: SHA1withRSA (弱), 1024 位密钥 (弱)jar 已验证。

警告: 此 jar 包含其证书链无效的条目。原因: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
此 jar 包含其签名者证书为自签名证书的条目。
SHA1 摘要算法被视为存在安全风险。此算法将在未来的更新中被禁用。
SHA1withRSA 签名算法被视为存在安全风险。此算法将在未来的更新中被禁用。
RSA 签名密钥的密钥大小 1024 被视为存在安全风险。此密钥大小将在未来的更新中被禁用。
此 jar 包含的签名没有时间戳。如果没有时间戳, 则在其中任一签名者证书到期 (最早为 2048-05-29) 之后, 用户可能无法验证此 jar。

签名者证书将于 2048-05-29 到期。

上面可以看到出现了许多"CertPath not validated"错误，这个错误在 Java SDK 7 及以上版本才有，如果想忽略这个错误，我们可以使用 Android SDK 构建工具的修订版 24.0.3 及更高版本中提供的 apksigner 工具为 APK 签名来代替JAVA JDK自带的 jarsigner 工具来验证APK的证书链，如下：

检查 APK 的签名是否可在 APK 支持的所有 Android 平台上被确认为有效：

$ apksigner verify vuls.apk

检查 APK 的签名是否可在 Android 4.0.3（API 级别 15）及更高版本上被确认为有效：

$ apksigner verify --min-sdk-version 15 vuls.apk

另外签名配置可以通过Android Studio或build.gradle中的 signingConfig 块进行管理。要同时激活 v1和 v2 以及 v3 方案，必须设置以下值：

v1SigningEnabled true
v2SigningEnabled true
v3SigningEnabled true

在官方的 Android 开发者文档中，提供了几种配置应用发布的最佳实践

Android Studio Signature Version V1/ V2：

V1 (jar Signature)

V1: Jar Signature 来自 JDK，可对签名后的文件，作适当修改，并重新压缩

V1 签名不保护 APK 的某些部分，例如 ZIP 元数据。APK 验证程序需要处理大量不可信（尚未经过验证）的数据结构，然后会舍弃不受签名保护的数据。这会导致相当大的受攻击面。此外，APK 验证程序必须解压所有已压缩的条目，而这需要花费更多时间和内存。为了解决这些问题，Android 7.0 中引入了 APK 签名方案 v2

V2 (Full APK Signature)

V2: Android 7.0 (Nougat) 引入的一项新的签名方案，不能对签名后的 APK作任何修改，包括重新解压。因为它是针对字节进行的签名，所以任何改动都会影响最终结果

V3

V3：在 Android 9 中，v2 方案已更新为 v3 方案（也称为v2+），以便在签名分块中包含其他信息，但在其他方面保持相同的工作方式，该方案会对 APK 的内容进行哈希处理和签名，然后将生成的“APK 签名分块”插入到 APK 中

APK 签名方案详情，请移步Android 官网的介绍

只勾选v1签名所有机型都能用，如果只勾选V2签名7.0以下机型会在直接安装完后显示未安装，7.0及以上机型使用V2的方式验证成功安装，同时勾选V1和V2对所有机型成功安装，或者在Gradle 文件中修改，如下：

signingConfigs {  
    debug {  
        v1SigningEnabled true  
        v2SigningEnabled true
        v3SigningEnabled true    }  
    release {  
        v1SigningEnabled true  
        v2SigningEnabled true  
        v3SigningEnabled true    }  } 

来说说为什么我们要推荐使用v1和v2共同使用呢？因为在2020年的时候Google公布的“Janus”漏洞，可使攻击者将Dex附加到原有的apk之上，绕过签名认证，在执行时优先执行附加的dex文件，这个漏洞直接影响Android 5.0~8.0上所有基于signature scheme V1签名的APK。这里说哈，对应APK应用程序来说签名确是唯一的，是用来证明是谁开发的是否是盗版或恶意APK，那么假如正版应用被恶意修改，其签名也会随之被破坏，需要重新签名才能安装到Android上，而且市面上各种APK应用商店和手机应用助手类的工具，往往通过包名和签名来判断一个APK应用程序是否是盗版或恶意APK应用程序

注：在官方的 Android 开发者文档中，官方提供了几种配置应用发布的方式，

审核编辑：刘清