android签名,android签名算法

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

Android系统签名

有时候，我们开发的apk需要用到系统权限，需要在AndroidManifest.xml中添加共享系统进程属性：

这时候apk的签名就需要是系统签名(platform、shared或media)才能正常使用。

常用系统签名方式

这种方式比较麻烦，你需要有编译过的源码环境，并按如下步骤：

1、拷贝App源码到Android源码的packages/apps/目录下，且App源码是普通(Eclipse)格式的

2、配置Android.mk，在其中添加

3、使用mm编译App，生成的apk即系统签名

这种方式比在源码环境下签名简单，App可以在Eclipse或Android Studio下编译，然后给apk重新签名即可。

但这种方式在频繁调试的时候比较痛苦，即使写成脚本，也需要重复一样的操作。

相关问答

Q1: Android查看应用签名方法

查看应用签名的MD5、SHA1、SHA256值及签名算法。

查看keystore文件签名信息，前提要有keystore文件和密钥，才能够获取keystore文件的签名信息。

方法一：（适用于 AS）

1)打开 AS工具窗口栏右边的 Gradle - Project - app - Tasks - android - signingReport,双击运行 signingReport;

在没有keystore文件和密钥的情况下,要想查看我们所需应用的签名信息,就需要借助 keytool 工具来完成。

首先解压要查看的apk包,通过数据证书管理工具 keytool 查看apk的签名信息。具体步骤如下：

1）将apk修改后缀为 .rar 文件后进行解压；

2）进入解压后的 META-INF 目录，找到该目录下的 xxx.RSA 文件；

3）通过命令 cmd 打开DOS窗口，输入命令： keytool -printcert -file [RSA文件路径]

在查看应用签名信息过程中，可能会遇到以下几个问题：

定位 keytool.exe 工具所在的目录，使用相关操作命令查看签名信息；

JKS(Java KeyStore) ：是 Java 的 keytools 证书工具支持的证书私钥格式。jks 包含了公钥和私钥，可以通过 keytool 工具来将公钥和私钥导出。因为包含了私钥，所以 jks 文件通常通过一个密码来加以保护。一般用于 Java 或者 Tomcat 服务器。

PKCS #12 ：定义了一种存档文件格式，用于实现存储许多加密对象在一个单独的文件中。通常用它来打包一个私钥及有关的 X.509 证书，或者打包信任链的全部项目。

定位 keytool.exe 工具所在的目录，使用操作命令转换证书格式；

Q2: Android V1及V2签名原理简析

Android为了保证系统及应用的安全性，在安装APK的时候需要校验包的完整性，同时，对于覆盖安装的场景还要校验新旧是否匹配，这两者都是通过Android签名机制来进行保证的，本文就简单看下Android的签名与校验原理，分一下几个部分分析下：

签名是摘要与非对称密钥加密相相结合的产物，摘要就像内容的一个指纹信息，一旦内容被篡改，摘要就会改变，签名是摘要的加密结果，摘要改变，签名也会失效。Android APK签名也是这个道理，如果APK签名跟内容对应不起来，Android系统就认为APK内容被篡改了，从而拒绝安装，以保证系统的安全性。目前Android有三种签名V1、V2（N）、V3（P），本文只看前两种V1跟V2，对于V3的轮密先不考虑。先看下只有V1签名后APK的样式：

再看下只有V2签名的APK包样式：

同时具有V1 V2签名：

可以看到，如果只有V2签名，那么APK包内容几乎是没有改动的，META_INF中不会有新增文件，按Google官方文档：在使用v2签名方案进行签名时，会在APK文件中插入一个APK签名分块，该分块位于zip中央目录部分之前并紧邻该部分。在APK签名分块内，签名和签名者身份信息会存储在APK签名方案v2分块中，保证整个APK文件不可修改，如下图：

而V1签名是通过META-INF中的三个文件保证签名及信息的完整性：

V1签名是如何保证信息的完整性呢？V1签名主要包含三部分内容，如果狭义上说签名跟公钥的话，仅仅在.rsa文件中，V1签名的三个文件其实是一套机制，不能单单拿一个来说事，

如果对APK中的资源文件进行了替换，那么该资源的摘要必定发生改变，如果没有修改MANIFEST.MF中的信息，那么在安装时候V1校验就会失败，无法安装，不过如果篡改文件的同时，也修改其MANIFEST.MF中的摘要值，那么MANIFEST.MF校验就可以绕过。

CERT.SF个人觉得有点像冗余，更像对文件完整性的二次保证，同绕过MANIFEST.MF一样，.SF校验也很容易被绕过。

CERT.RSA与CERT.SF是相互对应的，两者名字前缀必须一致，不知道算不算一个无聊的标准。看下CERT.RSA文件内容：

CERT.RSA文件里面存储了证书公钥、过期日期、发行人、加密算法等信息，根据公钥及加密算法，Android系统就能计算出CERT.SF的摘要信息，其严格的格式如下：

从CERT.RSA中，我们能获的证书的指纹信息，在微信分享、第三方SDK申请的时候经常用到，其实就是公钥+开发者信息的一个签名：

除了CERT.RSA文件，其余两个签名文件其实跟keystore没什么关系，主要是文件自身的摘要及二次摘要，用不同的keystore进行签名，生成的MANIFEST.MF与CERT.SF都是一样的，不同的只有CERT.RSA签名文件。也就是说前两者主要保证各个文件的完整性，CERT.RSA从整体上保证APK的来源及完整性，不过META_INF中的文件不在校验范围中，这也是V1的一个缺点。V2签名又是如何保证信息的完整性呢？

前面说过V1签名中文件的完整性很容易被绕过，可以理解单个文件完整性校验的意义并不是很大，安装的时候反而耗时，不如采用更加简单的便捷的校验方式。V2签名就不针对单个文件校验了，而是针对APK进行校验，将APK分成1M的块，对每个块计算值摘要，之后针对所有摘要进行摘要，再利用摘要进行签名。

也就是说，V2摘要签名分两级，第一级是对APK文件的1、3 、4 部分进行摘要，第二级是对第一级的摘要集合进行摘要，然后利用秘钥进行签名。安装的时候，块摘要可以并行处理，这样可以提高校验速度。

APK是先摘要，再签名，先看下摘要的定义：Message Digest：摘要是对消息数据执行一个单向Hash，从而生成一个固定长度的Hash值，这个值就是消息摘要，至于常听到的MD5、SHA1都是摘要算法的一种。理论上说，摘要一定会有碰撞，但只要保证有限长度内碰撞率很低就可以，这样就能利用摘要来保证消息的完整性，只要消息被篡改，摘要一定会发生改变。但是，如果消息跟摘要同时被修改，那就无从得知了。

而数字签名是什么呢（公钥数字签名），利用非对称加密技术，通过私钥对摘要进行加密，产生一个字符串，这个字符串+公钥证书就可以看做消息的数字签名，如RSA就是常用的非对称加密算法。在没有私钥的前提下，非对称加密算法能确保别人无法伪造签名，因此数字签名也是对发送者信息真实性的一个有效证明。不过由于Android的keystore证书是自签名的，没有第三方权威机构认证，用户可以自行生成keystore，Android签名方案无法保证APK不被二次签名。

知道了摘要跟签名的概念后，再来看看Android的签名文件怎么来的？如何影响原来APK包？通过sdk中的apksign来对一个APK进行签名的命令如下：

其主要实现在 android/platform/tools/apksig 文件夹中，主体是ApkSigner.java的sign函数，函数比较长，分几步分析

先来看这一步，ApkUtils.findZipSections，这个函数主要是解析APK文件，获得ZIP格式的一些简单信息，并返回一个ZipSections，

ZipSections包含了ZIP文件格式的一些信息，比如中央目录信息、中央目录结尾信息等，对比到zip文件格式如下：

获取到 ZipSections之后，就可以进一步解析APK这个ZIP包，继续走后面的签名流程，

可以看到先进行了一个V2签名的检验，这里是用来签名，为什么先检验了一次？第一次签名的时候会直接走这个异常逻辑分支，重复签名的时候才能获到取之前的V2签名，怀疑这里获取V2签名的目的应该是为了排除V2签名，并获取V2签名以外的数据块，因为签名本身不能被算入到签名中，之后会解析中央目录区，构建一个DefaultApkSignerEngine用于签名

先解析中央目录区，获取AndroidManifest文件，获取minSdkVersion(影响签名算法)，并构建DefaultApkSignerEngine，默认情况下V1 V2签名都是打开的。

第五步与第六步的主要工作是：apk的预处理，包括目录的一些排序之类的工作，应该是为了更高效处理签名，预处理结束后，就开始签名流程，首先做的是V1签名（默认存在，除非主动关闭）：

步骤7、8、9都可以看做是V1签名的处理逻辑，主要在V1SchemeSigner中处理，其中包括创建META-INFO文件夹下的一些签名文件，更新中央目录、更新中央目录结尾等，流程不复杂，不在赘述，简单流程就是：

这里特殊提一下重复签名的问题：对一个已经V1签名的APK再次V1签名不会有任何问题，原理就是：再次签名的时候，会排除之前的签名文件。

可以看到目录、META-INF文件夹下的文件、sf、rsa等结尾的文件都不会被V1签名进行处理，所以这里不用担心多次签名的问题。接下来就是处理V2签名。

V2SchemeSigner处理V2签名，逻辑比较清晰，直接对V1签名过的APK进行分块摘要，再集合签名，V2签名不会改变之前V1签名后的任何信息，签名后，在中央目录前添加V2签名块，并更新中央目录结尾信息，因为V2签名后，中央目录的偏移会再次改变：

签名校验的过程可以看做签名的逆向，只不过覆盖安装可能还要校验公钥及证书信息一致，否则覆盖安装会失败。签名校验的入口在PackageManagerService的install里，安装官方文档，7.0以上的手机优先检测V2签名，如果V2签名不存在，再校验V1签名，对于7.0以下的手机，不存在V2签名校验机制，只会校验V1，所以，如果你的App的miniSdkVersion24(N)，那么你的签名方式必须内含V1签名：

校验流程就是签名的逆向，了解签名流程即可，本文不求甚解，有兴趣自己去分析，只是额外提下覆盖安装，覆盖安装除了检验APK自己的完整性以外，还要校验证书是否一致只有证书一致（同一个keystore签名），才有可能覆盖升级。覆盖安装同全新安装相比较多了几个校验

这里只关心证书部分：

Android V1及V2签名签名原理简析

仅供参考，欢迎指正

Q3: 获取Android应用签名的几种方式

打开 Android Studio，然后选择右边的 Gradle 标签，选择一个项目，然后选择 signingReport 这个 Task，双击运行

然后选择右下角的 Gradle Console，就可以看到签名信息了

使用解压工具解压 APK 文件，在 META-INF 文件夹拿到 CERT.RSA 文件。假设 CERT.RSA 文件的路径是 C:\Users\Administrator\Desktop\CERT.RSA 。在 CMD 中输入

就可以得到签名信息了

jks 作为签名文件，也可以通过命令行来查看的其中的签名信息，假设签名文件的名称是 test_release.jks ，在终端中输入

即可得到签名信息

Q4: Android APP的签名

Android APP的签名

Android项目以它的包名作为唯一的标识，如果在同一部手机上安装两个包名相同的APP，后者就会覆盖前面安装的应用。为了避免Android APP被随意覆盖，Android要求对APP进行签名。下面介绍对APP进行签名的步骤

1、选择builder菜单下的Generate Signed APK

2、弹出签名向导对话框

3、在该对话框中选择数字证书，如果没有数字证书，可以点击Create new按钮，创建数字证书如下图所示：

4、输入证书的存储路径及文件名称，密码，有效年份，发布人员的姓名，单位，所在城市，省份，国家等信息，后点击OK按钮，如下图所示，系统会自动带入密码

5、点击Next选择签名后的安装包存放路径，构建类型，点击finish完成安装包的构建

注意：

v2是Android 7.0中引入了签名版本，v1是jar Signature来自JDK，只勾选v1签名并不会影响什么，但是在7.0上不会使用更安全的验证方式，只勾选V2签名7.0以下会直接安装完显示未安装，7.0以上则使用了V2的方式验证，为了保证兼容性，可以同时勾选V1和V2。

在Debug调试版本中，默认会调用调试用的签名证书debug.keystore，该证书默认存放在C:\Users你的用户名.android下。

包名和签名都相同的APP才可以覆盖安装

Q5: android 系统签名

也有提到怎么单独给一个apk签名，这里补充一下android的签名权限控制机制。

android的标准签名key有：

testkey

media

latform

hared

以上的四种，可以在源码的/build/target/product/security里面看到对应的密钥，其中shared.pk8代表私钥，shared.x509.pem公钥，一定是成对出现的。

其中testkey是作为android编译的时候默认的签名key，如果系统中的apk的android.mk中没有设置LOCAL_CERTIFICATE的值，就默认使用testkey。

而如果设置成：

LOCAL_CERTIFICATE := platform

就代表使用platform来签名，这样的话这个apk就拥有了和system相同的签名，因为系统级别的签名也是使用的platform来签名，此时使用android:sharedUserId="android.uid.system"才有用！

在/build/target/product/security目录下有个README，里面有说怎么制作这些key以及使用问题（android4.2）：

从上面可以看出来在源码下的/development/tools目录下有个make_key的脚本，通过传入两个参数就可以生成一对签名用的key。

其中第一个为key的名字，一般都默认成android本身有的，因为很多地方都默认使用了这些名字，我们自定义的话只需要对第二个参数动手脚，定义如下：

C --- Country Name (2 letter code) ST --- State or Province Name (full name) L --- Locality Name (eg, city) O --- Organization Name (eg, company) OU --- Organizational Unit Name (eg, section) CN --- Common Name (eg, your name or your server’s hostname) emailAddress --- Contact email addre

另外在使用上面的make_key脚本生成key的过程中会提示输入password，我的处理是不输入，直接enter，不要密码！后面解释，用自定义的key替换/security下面的。

可以看到android源码里面的key使用的第二个参数就是上面README里面的，是公开的，所以要release版本的系统的话，肯定要有自己的签名key才能起到一个安全控制作用。

在上面提到如果apk中的编译选项LOCAL_CERTIFICATE没有设置的话，就会使用默认的testkey作为签名key，我们可以修改成自己想要的key，按照上面的步骤制作一个releasekey，修改android配置在/build/core/config.mk中定义变量：

在主makefile文件里面：

ifeq ($(DEFAULT_SYSTEM_DEV_CERTIFICATE),build/target/product/security/releasekey)

BUILD_VERSION_TAGS += release-key

这样的话默认的所有签名将会使用releasekey。

修改完之后就要编译了，如果上面的这些key在制作的时候输入了password就会出现如下错误：

我在网上找到了合理的解释：

其实会出现这个错误的最根本的原因是多线程的问题。在编译的时候为了加速一般都会执行make -jxxx，这样本来需要手动输入密码的时候，由于其它线程的运行，就会导致影响当前的输入终端，所以就会导致密码无法输入的情况！

再编译完成之后也可以在build.prop中查看到变量：

这样处理了之后编译出来的都是签名过的了，系统才算是release版本

我发现我这样处理之后，整个系统的算是全部按照我的要求签名了。

网上看到还有另外的签名release办法，但是应该是针对另外的版本的，借用学习一下：

make -j4 PRODUCT-product_modul-user dist

这个怎么跟平时的编译不一样,后面多了两个参数PRODUCT-product_modul-user 和 dist. 编译完成之后回在源码/out/dist/目录内生成个product_modul-target_files开头的zip文件.这就是我们需要进行签名的文件系统.

我的product_modul 是full_gotechcn,后面加“-user”代表的是最终用户版本，关于这个命名以及product_modul等可参考

编译出需要签名的zip压缩包之后，就是利用/security下面的准备的key进行签名了：

./build/tools/releasetools/sign_target_files_apks -d /build/target/product/security out/dist/full_gotechcn-target_files.zip out/dist/signed_target_files.zi

签名目标文件输出成signed_target_files.zi

如果出现某些apk出错，可以通过在full_gotechcn-target_files.zip前面加参数"-e =" 来过滤这些apk.

然后再通过image的脚本生成imag的zip文件，这种方式不适用与我目前的工程源码，没有做过多验证！

Android签名机制可划分为两部分：（1）ROM签名机制；（2）第三方APK签名机制。

Android APK实际上是一个jar包，而jar包又是一个zip包。APK包的签名实际上使用的是jar包的签名机制：在zip中添加一个META的子目录，其中存放签名信息；而签名方法是为zip包中的每个文件计算其HASH值，得到签名文件(*.sf)，然后对签名文件(.sf)进行签名并把签名保存在签名块文件(*.dsa)中。

在编译Android源码生成ROM的过程中，会使用build/target/product/security目录中的4个key（media, platform, shared, testkey）来对apk进行签名。其中，*.pk8是二进制形式（DER）的私钥，*.x509.pem是对应的X509公钥证书（BASE64编码）。build/target/product/security目录中的这几个默认key是没有密码保护的，只能用于debug版本的ROM。

要生成Release版本的ROM，可先生成TargetFiles，再使用带密码的key对TargetFiles重新签名，最后由重签名的TargetFiles来生成最终的ROM。

可以使用Android源码树中自带的工具“development/tools/make_key”来生成带密码的RSA公私钥对（实际上是通过openssl来生成的）: $ development/tools/make_key media ‘/C=CN/ST=Sichuan/L=Chengdu/O=MyOrg/OU=MyDepartment/CN=MyName’ 上面的命令将生成一个二进制形式（DER）的私钥文件“media.pk8”和一个对应的X509公钥证书文件“media.x509.pem”。其中，/C表示“Country Code”，/ST表示“State or Province”，/L表示“City or Locality”，/O表示“Organization”，/OU表示“Organizational Unit”，/CN表示“Name”。前面的命令生成的RSA公钥的e值为3，可以修改development/tools/make_key脚本来使用F4 (0×10001)作为e值（openssl genrsa的-3参数改为-f4）。

也可以使用JDK中的keytool来生成公私钥对，第三方APK签名一般都是通过keytool来生成公私钥对的。

可以使用openssl x509命令来查看公钥证书的详细信息： $ openssl x509 -in media.x509.pem -text -noout or, $ openssl x509 -in media.x509.pem -inform PEM -text -noout

还可以使用JDK中的keytool来查看公钥证书内容，但其输出内容没有openssl x509全面： $ keytool -printcert -v -file media.x509.pem

有了key之后，可以使用工具“build/tools/releasetools/sign_target_files”来对TargetFiles重新签名： $ build/tools/releasetools/sign_target_files_apks -d new_keys_dir -o target_files.zip target_files_resigned.zip 其中，new_keys_dir目录中需要有四个key（media, platform, shared, releasekey）。注意：这里的releasekey将代替默认的testkey（请参考build/tools/releasetools/sign_target_files脚本实现），也就是说，如果某个apk的Android.mk文件中的LOCAL_CERTIFICATE为testkey，那么在生成TargetFiles时是使用的build/target/product/security/testkey来签名的，这里重新签名时将使用new_keys_dir/releasekey来签名。

uild/tools/releasetools/sign_target_files_apks是通过host/linux-x86/framework/signapk.jar来完成签名的。也可以直接使用host/linux-x86/framework/signapk.jar来对某个apk进行签名： $ java -jar signapk [-w] publickey.x509[.pem] privatekey.pk8 input.jar output.jar 其中，”-w”表示还对整个apk包(zip包）进行签名，并把签名放在zip包的comment中。

对于第三方应用开发者而言，对APK签名相对要简单得多。第三方应用开发一般采用JDK中的keytool和jarsigner来完成签名密钥的管理和APK的签名。

使用keytool来生成存储有公私钥对的keystore： $ keytool -genkey -v -keystore my-release-key.keystore -alias mykey -keyalg RSA -keysize 2048 -validity 10000

查看生成的密钥信息： $ keytool -list -keystore my-release-key.keystore -alias mykey -v or, $ keytool -list -keystore my-release-key.keystore -alias mykey -rfc （注：获取Base64格式的公钥证书，RFC 1421）

导出公钥证书： $ keytool -export -keystore mystore -alias mykey -file my.der （注：二进制格式公钥证书，DER） $ keytool -export -keystore mystore -alias mykey -file my.pem -rfc （注：Base64格式公钥证书，PEM）

对APK进行签名： $ jarsigner -verbose -keystore my-release-key.keystore my_application.apk mykey

验证签名： $ jarsigner -verify -verbose -certs my_application.apk

在进行Android二次开发时，有时需要把build/target/product/security下面的公私钥对转换为keystore的形式，可以参考这篇文章：把Android源码中的密码对转换为keystore的方法。