做网站的资料,做网站的广告,php做网站开源项目,静安网站建设关键词优化seo一、序在将 App 发布到市场之前#xff0c;很重要的一个步骤就是为 APK 进行签名#xff0c;大部分时候#xff0c;这个操作隐藏在了打包的流程中#xff0c;而不被我们注意到。签名的作用#xff0c;除了证明 App 的所有权之外#xff0c;还可以帮助 Android 市场和设备… 一、序在将 App 发布到市场之前很重要的一个步骤就是为 APK 进行签名大部分时候这个操作隐藏在了打包的流程中而不被我们注意到。签名的作用除了证明 App 的所有权之外还可以帮助 Android 市场和设备校验 APK 的正确性。Android 的签名是自证明的并不会对证书进行 CA 认证。也就是我们可以使用工具自行生成签名证书只要是一个格式正确的签名系统就会承认并且允许安装。生成签名的时可以指定一个有效时间这个时间默认为 25 年并且 Google Play 也有硬性规定上架的 App 签名有效期必须在 2033-10-22 日期之后。所以只要不是手欠修改了这个有效期在当下这个时刻是不会有问题毕竟到现在还没有一款 App 存在 25 年。有些问题不在眼前却是真实存在的。对于一款上架的 App最重要的就是用户而当签名失效之后我们只能被迫替换签名此时因为签名校验无法通过就会导致旧用户无法覆盖安装。这些历史用户唯一的选择就是卸载后重新安装。好在这不仅仅是你我的问题天塌下来有个子高的顶着所以别担心Google 已经着手在解决这个问题了。方案就是 Android 9.0 新增的对 APK V3 签名的支持。二、新的签名方案 V32.1 Android 的签名方案Android 的签名方案发展到现在不是一蹴而就的。Android 现在已经支持三种应用签名方案V1 方案基于 JAR 签名。V2 方案APK 签名方案 V2在 Android 7.0 引入。V3 方案APK 签名方案 V3在 Android 9.0 引入。V1 到 V2 是颠覆性的为了解决 JAR 签名方案的安全性问题而到了 V3 方案其实结构上并没有太大的调整可以理解为 V2 签名方案的升级版有一些资料也把它称之为 V2 方案。因为这种签名方案的升级本身就是向下兼容的所以只要使用得当这个过程对开发者是透明的。V1 到 V2 方案的升级对开发者影响最大的就是渠道签署的问题。在当下这个大环境下我们想让不同渠道、市场的安装包有所区别携带渠道的唯一标识这就是我们俗称的渠道包。好在各大厂都开源了自己的签渠道方案例如Walle(美团)、VasDolly(腾讯)都是非常优秀的方案想了解的可以先看看之前的文章《Android 签名和多渠道打包原理》。2.2 签名的历史先从 Android 签名的历史讲起。在上个世纪 80 年代Phil Katz 创建了 ZIP 格式可以将文件和一些元数组组合在一个文件中便于传输和存档该格式是为了解决压缩、校验和冗余头等问题而提出的解决方案。Sum 公司在上世纪 90 年代将 ZIP 作为 JAR 格式的基础而 JAR 本质上就是一个 ZIP 存档。在其中META-INF 目录下会包含一些元数据和签名数据等信息。Android 出现后也沿用了 Java 的 JAR 的发布方式将 APK 建立在 JAR 格式之上在此基础上对 Dalvik 字节码 classes.dex 和资源 resources.arsc 等文件添加更多标准化的结构。当时 Android 的 APK 完全依赖 JAR 的签名方案来确保应用程序的正确性这就是我们俗称的 V1 方案(JAR 方案)。在 V1 签名方案中并不会保护 APK 内的所有文件会存在一些例外部分即便被修改也不会导致签名失效例如ZIP 元数据。同时V1 方案对 APK 内部被保护的原始文件是单独进行计算数据摘要的所以在验证时需要先解压再验证导致安装时会花费更多的时间消耗更多的内存。例如 V1 方案中签渠道的方式就是利用了此特性将渠道信息写入 META-INF 文件中这不会破坏 V1 签名。多年后在 Android 7.0 中添加了一种新的签名方式就是我们俗称的 V2 方案。V2 签名提供了更强大的 APK 文件验证它不再检查包内单个文件而是检查整个 APK。它在 ZIP 文件中插入一个额外的签名块覆盖 ZIP 文件中的其余部分。在这个额外的签名块(Apk Signature Block V2)中会对当前 APK 的其他部分签名。从安全的角度 V2 会比 V1 更安全V2 签名是验证整个打包后的 APK 文件所以对其 APK 文件做“任何”改动都会破坏签名。注意这里的任何是带引号的V2 签名的签名块其实是一个 K-V 的结构可以向其中插入一些简单的数据而不破坏 V2 签名这就是 V2 方案下多渠道的方案思路。在引入 V2 方案的同时也保证了向后兼容旧的 JAR 签名方案仍然在旧的设备(Android 7.0 以下)中生效而在较新的设备上也会判断是否使用 V2 签名不是则依然会去校验 V1 签名。V2 方案解决了安全问题以及安装时验证的效率问题但是它并没有解决前面提到的换签名问题。2.3 Android 的 V3 方案Android 9.0 中引入了新的签名方式它的格式大体和 V2 类似在 V2 插入的签名块(Apk Signature Block V2)中又添加了一个新快(Attr块)。在这个新块中会记录我们之前的签名信息以及新的签名信息以密钥转轮的方案来做签名的替换和升级。这意味着只要旧签名证书在手我们就可以通过它在新的 APK 文件中更改签名。V3 签名新增的新块(attr)存储了所有的签名信息由更小的 Level 块以链表的形式存储。其中每个链表节点都包含用于为之前版本的应用签名的签名证书最旧的签名证书对应根节点系统会让每个节点中的证书为列表中下一个证书签名从而为每个新密钥提供证据来证明它应该像旧密钥一样可信。这个过程有点类似 CA 证书的证明过程已安装的 App 的旧签名确保覆盖安装的 APK 的新签名正确将信任传递下去。2.4 V3 签名的验证过程Android 的签名方案无论怎么升级都是要确保向下兼容。在引入 V3 方案后Android 9.0 及更高版本中可以根据 APK 签名方案V3 → V2 → V1 依次尝试验证 APK。而较旧的平台会忽略 V3 签名并尝试 V2 签名最后才去验证 V1 签名。整个验证的过程如下图需要注意的是对于覆盖安装的情况签名校验只支持升级而不支持降级。也就是说设备上安装了一个使用 V1 签名的 Apk可以使用 V2 签名的 Apk 进行覆盖安装反之则不允许。三、总结时刻Android 签名替换的问题Google 已经在考虑了9.0 新增的 V3 签名方案就是为了解决签名替换的。这些肯定都是提前准备。签名过期的问题不需要太担心我们只需要跟着 Google 的步伐就可以了。最后小结一下结论签名过期的问题在 Android 9.0 上新支持的 V3 签名已经有解决的方案了。另外V1 签名遵循 JAR 的签名方式单独验证 APK 压缩包中的文件。V2 签名是针对 APK 文件的验证将签名信息写入签名块中增强了安全性和验证效率。V3 签名在签名块中又增加了新块(attr)由更小的 level 块以链表的形式存储多个证书。在 V3 方案中最旧的证书为新块链表的根节点以此对新证书签名确保新证书正确有效。V3 方案还没有正式开放在最新版的 Build Tools 版本 28.0.3 中的 Apksigner尚不支持 V3 的 APK 签名方案。想尝鲜可以通过源代码自行编译。从现有的资料来看我比较关心的多渠道打包的支持方案在升级到 V3 之后旧的 V2 支持的多渠道方案应该依然有效(或者少量改动)。期待上线后的具体效果。你对 V3 签名有什么想法或者疑问欢迎在留言区讨论。如若本文对你有所帮助欢迎留言、转发、点“好看”。reference:https://www.guardsquare.com/en/blog/android-apk-signature-scheme-v3-context-and-new-opportunitieshttps://source.android.com/security/apksigninghttps://xuanxuanblingbling.github.io/ctf/android/2018/12/30/signature/「联机圆桌」?推荐我的知识星球一年 50 个优质问题上桌联机学习。公众号后台回复成长『成长』将会得到我准备的学习资料也能回复『加群』一起学习进步你还能回复『提问』向我发起提问。
