androidsign

⑴ android api 签名是什么意思

首先我们得知道什么是摘要，摘要是指采用单向Hash函数对数据进行计算生成的固定长度的Hash值，摘要算法有Md5，Sha1等，Md5生成的Hash值是128位的数字，即16个字节，用十六进制表示是32个字符，Sha1生成的Hash值是160位的数字，即20个字节，用十六进制表示是40个字符。我们是不能通过摘要推算出用于计算摘要的数据，如果修改了数据，那么它的摘要一定会变化(其实这句话并不正确，只是很难正好找到不同的数据，而他们的摘要值正好相等)。摘要经常用于验证数据的完整性，很多下载网站都会列出下载文件的md5值或者sha1值。
摘要和签名没有任何关系，网上常常将摘要和签名混为一谈，这是错误的。签名和数字签名是同一个概念，是指信息的发送者用自己的私钥对消息摘要加密产生一个字符串，加密算法确保别人无法伪造生成这段字符串，这段数字串也是对信息的发送者发送信息真实性的一个有效证明。其他发送者用他们的私钥对同一个消息摘要加密会得到不同的签名，接收者只有使用发送者签名时使用的私钥对应的公钥解密签名数据才能得到消息摘要，否则得到的不是正确的消息摘要。
数字签名是非对称密钥加密技术+数字摘要技术的结合。
数字签名技术是将信息摘要用发送者的私钥加密，和原文以及公钥一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的信息摘要，然后接收者用相同的Hash函数对收到的原文产生一个信息摘要，与解密的信息摘要做比对。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改；不同则说明信息被修改过，因此数字签名能保证信息的完整性。并且由于只有发送者才有加密摘要的私钥，所以我们可以确定信息一定是发送者发送的。
另外还需要理解一个概念：数字证书。数字证书是一个经证书授权中心数字签名的包含公钥及其拥有者信息的文件。数字证书的格式普遍采用的是X.509V3国际标准，一个标准的X.509数字证书包含以下一些内容：证书的版本信息:
1)证书的序列号，每个证书都有一个唯一的证书序列号；
2)证书所使用的签名算法；
3)证书的发行机构名称，命名规则一般采用X.500格式；
4)证书的有效期，通用的证书一般采用UTC时间格式，它的计时范围为1950-2049；
5)证书所有人的名称，命名规则一般采用X.500格式；
6)证书所有人的公开密钥；
7)证书发行者对证书的签名。
CERT.RSA包含了数字签名以及开发者的数字证书。CERT.RSA里的数字签名是指对CERT.SF的摘要采用私钥加密后的数据，Android系统安装apk时会对CERT.SF计算摘要，然后使用CERT.RSA里的公钥对CERT.RSA里的数字签名解密得到一个摘要，比较这两个摘要便可知道该apk是否有正确的签名，也就说如果其他人修改了apk并没有重新签名是会被检查出来的。
需注意Android平台的证书是自签名的，也就说不需要权威机构签发，数字证书的发行机构和所有人是相同的，都是开发者自己，开发者生成公私钥对后不需要提交到权威机构进行校验。

⑵ android 系统签名

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

android的标准签名key有：

     testkey

     media

    latform

    hared

    以上的四种，可以在源码的/build/target/proct/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/proct/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/proct/security/releasekey)

  BUILD_VERSION_TAGS += release-key

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

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

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

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

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

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

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

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

make -j4 PRODUCT-proct_mol-user dist

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

我的proct_mol 是full_gotechcn,后面加“-user”代表的是最终用户版本，关于这个命名以及proct_mol等可参考http://blog.csdn.net/jscese/article/details/23931159

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

./build/tools/releasetools/sign_target_files_apks -d /build/target/proct/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/proct/security目录中的4个key（media, platform, shared, testkey）来对apk进行签名。其中，*.pk8是二进制形式（DER）的私钥，*.x509.pem是对应的X509公钥证书（BASE64编码）。build/target/proct/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=Cheng/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/proct/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/proct/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的miniSdkVersion<24(N)，那么你的签名方式必须内含V1签名：

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

这里只关心证书部分：

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

仅供参考，欢迎指正

⑷ 如何获取android 签名信息

android中有时候需要获取应用的签名信息，签名信息一般有：公钥，算法名，MD5值，序列号。要想获取这些信息首先该APK应用要有系统权限。

1. 在配置文件里添加系统权限：android:sharedUserId="android.uid.system"

2. 获取签名信息的字符信息：

String signature_key = "";

try{

PackageInfo packageInfo = context.getPackageManager().getPackageInfo(pkgName,
PackageManager.GET_SIGNATURES);

Signature[] signatures =
packageInfo.signatures;

SignatureKey.parseSignature(signatures[0].toByteArray());

} catch (NameNotFoundException e) {

e.printStackTrace();

} catch (NullPointerException e) {

e.printStackTrace();

}

（1）.其中packageInfo 得到的是指定包名的签名信息的字符串。另提及多说一句：在程序中我们一般使用

List list =
mPackageManager.getInstalledPackages(0);来得到所有的安装包的信息，这其中包括应用名，包名，大小....

（2）.
其中[]signatures里是存放的签名的字符串数组。我们一般取用第一个signatures[0]来做为该应用的签名信息。这里有一个疑惑就是为什么得到的是一个字符串的数组列表，而不是一个字符串，也有的开发者采用:

StringBuilder builder = new StringBuilder();

for(Signature sign: signatures
){
builder.append(sign.toCharsString());
builder.append("/n");
}来得到所有的签名信息。在这里我验证过，signatures
的长度为1，所以指定apk的签名信息就为signatures[0]。

至于第二种方法有待发现。

3 .获取签名的MD5值

public static final String getMD5String(byte[] paramArrayOfByte)
{
char[] asciiTable = { 48, 49, 50, 51, 52, 53, 54, 55, 56, 57,
97, 98, 99, 100, 101, 102 }; // ascii表对应的数字和字符的编码
try
{
MessageDigest md5MessageDigest =
MessageDigest.getInstance("MD5");
md5MessageDigest.update(paramArrayOfByte);//
byte[]
tempByte = md5MessageDigest.digest();
int i =
tempByte.length;
char[] tempChar = new char[i *
2];
int j = 0;
int k =
0;
while (true) { //
将二进制数组转换成字符串
if (j >= i)
{
return new
String(tempChar);
}
int m
= tempByte[j];
int n = k +
1;
tempChar[k] = asciiTable[(0xF & m >>>
4)];
k = n +
1;
tempChar[n] = asciiTable[(m &
0xF)];
j++;
}
}
catch (Exception e)
{
e.printStackTrace();
}
return
null;
}

（1）. 其中参数就是上一步得到的签名的byte数组。

4. 获取公钥，签名算法，签名序列号

public static void parseSignature(byte[] signature)
{
try
{
CertificateFactory
certFactory =
CertificateFactory.getInstance("X.509");

X509Certificate cert = (X509Certificate) certFactory.generateCertificate(new
ByteArrayInputStream(signature));

String pubKey =
cert.getPublicKey().toString(); //公钥

String signNumber =
cert.getSerialNumber().toString();

System.out.println("signName:" +
cert.getSigAlgName());//算法名

System.out.println("pubKey:" +
pubKey);

System.out.println("signNumber:" +
signNumber);//证书序列编号

System.out.println("subjectDN:"+cert.getSubjectDN().toString());

} catch (CertificateException e)
{

e.printStackTrace();
}
}

5. 电脑查看APK签名信息

查看三方应用或是系统应用签名
用winrar打开待查看的apk，将其中META-INF文件夹解压出来，得到其中的CERT.RSA文件
1.keytool
-printcert -file META-INF/CERT.RSA
命令是：keytool -printcert -file
<签名文件RSA的路径>
2.jarsigner -verify -verbose -certs Superuser.apk
此条未验证成功

⑸ 如何对Android的APP进行签名

1、在Android Studio中打开工程，点击“Build”菜单下的“Generate Signed APK”。