1.apk的签名异常,安装时说已安装了存在签名冲突的数据包

2.apk提取的签名可回写吗

3.APKsign这个签名软件是干嘛用的,什么叫签名

4.安卓开发 导出apk文件 一定要设置签名吗

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

6.APK签名机制原理详解

apk签名的作用_apk文件签名是什么意思

使用手机的platform平台签名后,能够获取到系统权限。

1、在AndroidManifest.xml设置android:sharedUserId="android.uid.system"。

2、编译通过后,导出未签名的apk。

3、使用\out\host\Linux-x86\framework\signapk.jar \build\target\product\security\platform.pk8 +platform.x509.pem

4.执行“Ja -jar signapk.jar platform.x509.pem platform.pk8 test.apk testSigned.apk”做平台签名得到testSigned.apk。

test.apk必须放在上面同一个目录之下。

apk的签名异常,安装时说已安装了存在签名冲突的数据包

必须用安卓专门的签名才行,目前常用的是使用SDK开发临时签名。

网上找个APK签名的工具,将apktool重新打包后的APK进行签名就可以安装了。

另外反编译的QQ可能开启,表现为闪退,QQ程序里有些代码,程序有异常会中止自己进程

apk提取的签名可回写吗

这个很正常,那是因为你没有改过apk,你要是改过apk就会知道,改过的apk都是需要签名才可以安装上去的,而改了签名的话,和原软件的签名不同,但是程序名相同,就会提示你冲突。签名就是程序最后的校核,而程序名不是你所看到的表面中文字。

比如QQ,他的程序名不是QQ,而是com.tencent.mobileqq,凡是程序名都是以com开头的,只不过一般你看不到,你所说的应该是程序卸载不干净才会导致别的签名的程序安装不上,去系统-应用里找你apk的程序名,即变灰色且com开头的重新卸载即可。

若还是不行,自行恢复出厂设置。如果还是安装不上,提示apk签名异常的话,八成是装不上了,就算重新签名估计也装不上。

apk的格式定义:

在Android平台中,dalvik vm的执行文件被打包为apk格式,最终运行时加载器会解压,然后获取编译后的androidmanifest.xml文件中的permission分支相关的安全访问。

但仍然存在很多安全限制,如果你将apk文件传到/system/文件夹下,会发现执行是不受限制的。安装的文件可能不是这个文件夹,而在androidrom中,系统的apk文件默认会放入这个文件夹,它们拥有着root权限。

APKsign这个签名软件是干嘛用的,什么叫签名

不可。从APK中提取出的签名信息是只读的,不可回写。APK文件中的签名信息是用于验证应用程序来源和完整性的关键部分,一旦签名被添加到APK中,就无法修改。签名信息包括应用程序的公钥和数字签名,使用私钥生成。

安卓开发 导出apk文件 一定要设置签名吗

签名软件一般用于程序编译打包之后,手机在运行程序之前会先去验证程序的签名(可以看作类似于我们电脑上常说的md5)是否合法,只有通过了验证的文件才会被运行,所以签名软件的作用的让文件通过手机的验证为合法,不同的手机、系统是对应不同的签名的,这个新生成的apk文件就是带有签名文件的程序,和原来的其实是一样的,不同的是他是合法的程序。

概括来说就是一把锁配一把钥匙!(*^__^*) 嘻嘻……

Android V1及V2签名原理简析

不需要签名的

生成apk最懒惰的方法是:

只要你运行过android项目,到工作目录的bin文件夹下就能找到与项目同名的apk文件,这种apk默认是已经使用debug用户签名的。

如果想要自己给apk签名:

签名的意义

为了保证每个应用程序开发商合法ID,防止部分开放商可能通过使用相同的Package Name来混淆替换已经安装的程序,我们需要对我们发布的APK文件进行唯一签名,保证我们每次发布的版本的一致性(如自动更新不会因为版本不一致而无法安装)。

2.签名的步骤

a.创建key

b.使用步骤a中产生的key对apk签名

3.具体操作

方法一: 命令行下对apk签名(原理)

创建key,需要用到keytool.exe (位于jdk1.6.0_24\jre\bin目录下),使用产生的key对apk签名用到的是jarsigner.exe (位于jdk1.6.0_24\bin目录下),把上两个软件所在的目录添加到环境变量path后,打开cmd输入

D:\>keytool -genkey -alias demo.keystore -keyalg RSA -validity 40000 -keystore demo.keystore/*说明:-genkey 产生密钥 ? -alias demo.keystore 别名 demo.keystore ? -keyalg RSA 使用RSA算法对签名加密 ? -validity 40000 有效期限4000天 ? -keystore demo.keystore */D:\>jarsigner -verbose -keystore demo.keystore -signedjar demo_signed.apk demo.apk demo.keystore/*说明:-verbose 输出签名的详细信息 ? -keystore?demo.keystore 密钥库位置 ? -signedjar demor_signed.apk demo.apk demo.keystore 正式签名,三个参数中依次为签名后产生的文件demo_signed,要签名的文件demo.apk和密钥库demo.keystore.*/

注意事项:android工程的bin目录下的demo.apk默认是已经使用debug用户签名的,所以不能使用上述步骤对此文件再次签名。正确步骤应该是:在工程点击右键->Anroid Tools-Export Unsigned Application Package导出的apk用上述步骤签名。

方法二:使用Eclipse导出带签名的apk

Eclipse直接能导出带签名的最终apk,非常方便,推荐使用,步骤如下:

第一步:导出。

第二步:创建密钥库keystore,输入密钥库导出位置和密码,记住密码,下次Use existing keystore会用到。

第三步:填写密钥库信息,填写一些apk文件的密码,使用期限和组织单位的信息。

第四步:生成带签名的apk文件,到此就结束了。

第五步:如果下次发布版本的时候,使用前面生成的keystore再签名。

第六步:Next,Next,结束!

方法三:使用IntelliJ IDEA导出带签名的apk?

方法步骤基本和Eclipse相同,大概操作路径是:菜单Tools->Andrdoid->Export signed apk。

4.签名之后,用zipalign(压缩对齐)优化你的APK文件。

未签名的apk不能使用,也不能优化。签名之后的apk谷歌推荐使用zipalign.exe(位于android-sdk-windows\tools目录下)工具对其优化:

D:\>zipalign -v 4 demo_signed.apk final.apk

如上,zipalign能够使apk文件中未压缩的数据在4个字节边界上对齐(4个字节是一个性能很好的值),这样android系统就可以使用mmap()(请自行查阅这个函数的用途)函数读取文件,可以在读取上获得较高的性能,

PS:1.在4个字节边界上对齐的意思就是,一般来说,是指编译器吧4个字节作为一个单位来进行读取的结果,这样的话,CPU能够对变量进行高效、快速的访问(较之前不对齐)。

2.对齐的根源:android系统中的Dlik虚拟机使用自己专有的格式DEX,DEX的结构是紧凑的,为了让运行时的性能更好,可以进一步用"对齐"进一步优化,但是大小一般会有所增加。

5.签名对你的App的影响。

你不可能只做一个APP,你可能有一个宏伟的战略工程,想要在生活,服务,游戏,系统各个领域都想插足的话,你不可能只做一个APP,谷歌建议你把你所有的APP都使用同一个签名证书。

使用你自己的同一个签名证书,就没有人能够覆盖你的应用程序,即使包名相同,所以影响有:

1) App升级。 使用相同签名的升级软件可以正常覆盖老版本的软件,否则系统比较发现新版本的签名证书和老版本的签名证书不一致,不会允许新版本安装成功的。

2) App模块化。android系统允许具有相同的App运行在同一个进程中,如果运行在同一个进程中,则他们相当于同一个App,但是你可以单独对他们升级更新,这是一种App级别的模块化思路。

3) 允许代码和数据共享。android中提供了一个基于签名的Permission标签。通过允许的设置,我们可以实现对不同App之间的访问和共享,如下:

AndroidManifest.xml:<permission android:protectionLevel="normal" />

其中protectionLevel标签有4种值:normal(缺省值),dangerous, signature,signatureOrSystem。简单来说,normal是低风险的,所有的App不能访问和共享此App。dangerous是高风险的,所有的App都能访问和共享此App。signature是指具有相同签名的App可以访问和共享此App。signatureOrSystem是指系统image中App和具有相同签名的App可以访问和共享此App,谷歌建议不要使用这个选项,因为签名就足够了,一般这个许可会被用在在一个image中需要共享一些特定的功能的情况下。

APK签名机制原理详解

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.个人觉得有点像冗余,更像对文件完整性的二次保证,同绕过MANIFEST.MF一样,.校验也很容易被绕过。

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

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

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

除了CERT.RSA文件,其余两个签名文件其实跟keystore没什么关系,主要是文件自身的摘要及二次摘要,用不同的keystore进行签名,生成的MANIFEST.MF与CERT.都是一样的,不同的只有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.ja的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的miniSdkVersion<24(N),那么你的签名方式必须内含V1签名:

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

这里只关心证书部分:

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

仅供参考,欢迎指正

众所周知,Android系统在安装Apk的过程中,会对Apk进行签名校验,校验通过后才能安装成功。那你知道签名校验的机制是什么?具体校验的是什么内容吗?申请第三方SDK(如微信支付)时填入的SAH1值是什么?目前众多的快速批量打包方案又是如何绕过签名检验的?

我将通过一系列的文章来解开这些疑惑:

这篇文章先来介绍Apk签名相关的基本知识。

要知道签名是什么,先来看为什么需要签名 。大家都知道,在消息通信时,必须至少解决两个问题:一是确保消息来源的真实性,二是确保消息不会被第三方篡改。在安装Apk时,同样需要确保Apk来源的真实性,以及Apk没有被第三方篡改。如何解决这两个问题呢?方法就是开发者对Apk进行签名:在Apk中写入一个“指纹”。指纹写入以后,Apk中有任何修改,都会导致这个指纹无效,Android系统在安装Apk进行签名校验时就会不通过,从而保证了安全性。

要了解如何实现签名,需要了解两个基本概念:数字摘要和数字证书。

简单来说,就是对一个任意长度的数据,通过一个Hash算法计算后,都可以得到一个固定长度的二进制数据,这个数据就称为“摘要”。摘要具有下面的几个特征:

前面已经说到,可以通过签名来确保数据来源的可靠性和数据的不可篡改性。签名就是在摘要的基础上再进行一次加密,对摘要加密后的数据就可以当作数字签名,在安装Apk需要对签名进行验证,验证通过才能继续安装。

这里有两个过程:签名过程 和 校验过程。

先来说 签名过程:

再来看 校验过程:

这里有一个前提:接收方必须要知道发送方的公钥和所使用的算法。如果数字签名和公钥一起被篡改,接收方无法得知,还是会校验通过。如何保证公钥的可靠性呢?答案是数字证书,数字证书是身份认证机构(Certificate Authority)颁发的,包含了以下信息:

接收方收到消息后,先向CA验证证书的合法性(根据证书的签名、绑定的域名等信息。CA机构是权威的,可以保证这个过程的可靠性。)再进行签名校验。

需要注意的是,Apk的证书通常的自签名的,也就是由开发者自己制作,没有向CA机构申请。Android在安装Apk时并没有校验证书本身的合法性,只是从证书中提取公钥和加密算法,这也正是对第三方Apk重新签名后,还能够继续在没有安装这个Apk的系统中继续安装的原因。

我们在对Apk签名时并没有直接指定私钥、公钥和数字证书,而是使用keystore文件,这些信息都包含在了keystore文件中。根据编码不同,keystore文件分为很多种,Android使用的是Ja标准keystore格式JKS(Ja Key Storage),所以通过Android Studio导出的keystore文件是以.jks结尾的。

keystore使用的证书标准是X.509,X.509标准也有多种编码格式,常用的有两种:pem(Privacy Enhanced Mail)和der(Distinguished Encoding Rules)。jks使用的是der格式,Android也支持直接使用pem格式的证书进行签名,我们下面会介绍。

两种证书编码格式的区别:

X.509证书格式:

Android提供了两种对Apk的签名方式,一种是基于JAR的签名方式,另一种是基于Apk的签名方式,它们的主要区别在于使用的签名文件不一样:jarsigner使用keystore文件进行签名;apksigner除了支持使用keystore文件进行签名外,还支持直接指定pem证书文件和私钥进行签名。

不知道大家有没有注意一个问题,我们通过keytool或者AS生成一个keystore的时候( 签署您的应用 ),除了要输入keystore的密码外,还要输入一个alias和key的密码。在签名时,除了要指定keystore文件和密码外,也要指定alias和key的密码,这是为什么呢?

原因是keystore是一个密钥库,也就是说它可以存储多对密钥和证书,keystore的密码是用于保护keystore本身的,一对密钥和证书是通过alias来区分的。从这里可以看出jarsigner是支持使用多个证书对Apk进行签名的。apksigner也同样支持,关于apksigner的使用介绍可以参考官方文档 apksigner 。

ok,签名的基本概念和校验过程就介绍到这里,关于JAR签名和V2签名机制的详细介绍,参考下面两篇文章: