签名android,签名个性

Android APP的签名

Android APP的签名

创新互联建站主营哈尔滨网站建设的网络公司,主营网站建设方案,成都App制作,哈尔滨h5小程序制作搭建,哈尔滨网站营销推广欢迎哈尔滨等地区企业咨询

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才可以覆盖安装

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的方法。

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签名签名原理简析

仅供参考,欢迎指正

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 工具所在的目录,使用操作命令转换证书格式;

获取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 ,在终端中输入

即可得到签名信息


分享名称:签名android,签名个性
当前路径:http://scyanting.com/article/dsdjpsh.html