APK签名机制之——V2签名机制详解
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了APK签名机制之——V2签名机制详解相关的知识,希望对你有一定的参考价值。
参考技术A通过前一篇 Apk签名机制之——JAR签名机制详解 的分析我们知道,JAR签名需要对apk内所有文件进行hash校验,当资源较多时签名验证速度较慢。为了加快验证速度并加强完整性保证,Andorid在7.0引入一种全文件签名方案V2。下面来看V2方案的具体设计原理。
在了解V2签名结构前,先来了解下 zip(apk)文件的结构 。
zip文件分为3部分:
通过中央目录起始偏移量和size即可定位到中央目录,再遍历中央目录条目,根据本地文件头的起始偏移量即可在数据区中找到相应的压缩数据。
在 Apk签名机制之——JAR签名机制详解 中我们已经知道,JAR签名是在apk文件中添加META-INF目录,即需要修改 数据区 、 中央目录 ,因为添加文件后会导致中央目录大小和偏移量发生变化,还需要修改 中央目录结尾记录 。V2方案为加强数据完整性保证,不在 数据区 和 中央目录 中插入数据,选择在 数据区 和 中央目录 之间 插入一个 APK签名分块 ,从而保证了原始zip(apk)数据的完整性。具体如下所示:
v2 签名块负责保护第 1、3、4 部分的完整性,以及第 2 部分包含的 APK 签名方案 v2分块 中的 signed data 分块的完整性。
APK签名分块包含了4部分:分块长度、ID-VALUE序列、分块长度、固定magic值。其中 APK 签名方案 v2分块 存放在ID为0x7109871a的键值对中。在进行签名校验时,先找到zip 中央目录结尾记录 ,从该记录中找到 中央目录起始偏移量 ,再通过magic值即可确定前方可能是 APK签名分块 ,再通过前后两个分块长度字段,即可确定 APK签名分块 的位置,最后通过ID(0x7109871a)定位 APK 签名方案 v2分块 位置。
APK 签名方案 v2分块 是一个签名序列,说明可以使用多个签名者对同一个APK进行签名。每个签名信息中均包含了三个部分的内容:
前面说了v2 签名块负责保护第 1、3、4 部分的完整性,以及第 2 部分包含的 APK 签名方案 v2分块 中的 signed data 分块的完整性。第1、3、4部分的完整性是通过内容摘要来保护的,这些摘要保存在 signed data 分块中,而 signed data 分块的完整性是通过签名来保证的。下面来看摘要的计算过程:
第 1、3 和 4 部分的摘要采用以下计算方式,类似于两级 Merkle 树 。
因为V2签名机制是在android 7.0中引入的,为了使APK可在Android 7.0以下版本中安装,应先用JAR签名对APK进行签名,再用V2方案进行签名。要注意顺序一定是先JAR签名再V2签名,因为JAR签名需要修改zip 数据区 和 中央目录 的内容,先使用V2签名再JAR签名会破坏V2签名的完整性。
实际上我们在编译APK时并不需要关心这个过程,在Android Plugin for Gradle 2.2中,gradle默认会同时使用JAR签名和V2方案对APK进行签名,如果想要关闭JAR签名或V2签名,可以在build.gradle中进行配置:
在 Android 7.0 中,会优先以 v2方案验证 APK,在Android 7.0以下版本中,系统会忽略 v2 签名,仅验证 v1 签名。Android 7.0+的校验过程如下:
因为在经过V2签名的APK中同时带有JAR签名,攻击者可能将APK的V2签名删除,使得Android系统只校验JAR签名。为防范此类攻击,V2方案规定:
攻击者还可能试图删除 APK 签名方案 v2 分块 中安全系数较高的签名,从而使系统验证安全系数较低的签名。为防范此类攻击:
通过 Apk签名机制之——JAR签名机制详解 和本篇文章的分析,我们知道了:
JAR签名的劣势
V2签名的优势
现在我们可以解答 Apk签名的基本概念和用法 前言中提出的问题了:
APK签名是为了保证APK的完整性和来源的真实性,分为JAR签名和V2签名两种方案。核心思想均是计算APK内容的hash,再使用签名算法对hash进行签名。校验时通过签名者公钥解密签名,再与校验者计算的APK内容hash进行比对,一致则校验通过。
签名证书的指纹,在申请第三方SDK时,需填入APK包名和证书指纹,SDK开发者后台会根据这两个值生成一个key。第三方SDK在初始化时,会从系统中获取当前APK的包名、签名证书指纹以及key,然后将此指纹上传到其服务器,然后校验包名、签名证书指纹是否与此key绑定,校验通过后才进行授权。
在V2方案出现之前,快速批量打包方案有3类:
在V2方案出现之后,因同时保证了 数据区 、 中央目录 和 中央目录结尾记录 的完整性,故方案2、3均不适用了。那是不是就没有快速批量打包的可能了呢?当然不是,可以从 APK签名分块 中着手。再回过头来看一下 APK签名分块 的结构:
APK签名分块 中有一个ID-VALUE序列, 签名信息( APK 签名方案 v2 分块 )只存储在ID 为 0x7109871a的ID-VALUE中,通过分析签名校验源码可以发现,其它ID-VALUE数据是未被解析的,也就是说除 APK 签名方案 v2 分块 外,其余ID-VALUE是不影响签名校验的。故可以定义一个新的ID-VALUE,将渠道信息写入 APK签名分块 中。因为V2方案只保证了第1、3、4部分和第 2 部分( APK签名分块 )包含的 APK 签名方案 v2分块 中的 signed data 分块的完整性。新写入的ID-VALUE不受保护,所以此方案可行。实际上美团新一代渠道包生成工具 Walle 就是以这个方案实现的。
好了,到这里APK签名机制的全部内部就分析完了,相信大家看完这三篇文章之后,对JAR签名和V2签名机制都有了大致的了解,有兴趣的同学可以阅读签名和校验的源码进一步分析。
以上是关于APK签名机制之——V2签名机制详解的主要内容,如果未能解决你的问题,请参考以下文章
字节码插桩Android 签名机制 ( 生成 Android 签名文件 | 分析签名文件 | 签名文件两个密码的作用 | 三种签名方式 )