有什么方法可以检测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 开发者文档中，官方提供了几种配置应用发布的方式，
审核编辑：刘清
-
Android系统
+关注
关注
0文章
56浏览量
13492 -
API接口
+关注
关注
1文章
84浏览量
10437 -
apk
+关注
关注
0文章
23浏览量
4928
原文标题：APK应用程序是否签名异常的检测方法
文章出处：【微信号：哆啦安全，微信公众号：哆啦安全】欢迎添加关注！文章转载请注明出处。
发布评论请先 登录
相关推荐
RK3588主板/开发板Android12系统APK签名文件生成的方法，干货满满
android手机上emulate应用程序的方法
如何检测HDMI接口是否正常工作
AWTK-WEB 快速入门(1) - C 语言应用程序
CYC8PROTO-063-BLE是否可以通过智能手机上的标准设置应用程序建立连接？
esp32c3安全启动文档里的签名，使用与计算的签名和使用idf.py签名有什么不同？
电路检测器检查电池是否有电怎么判断
将应用程序从NoOS SDK移植到RTOS SDK遇到异常怎么解决?
多个esp32开发板如何组成ble mesh网络，是否可以自动组网呢？
CapCut Pro APK的特点功能及优势
工业异常检测超越特定阈值限制的解决方案
工商网监
评论