怎么提取apk的密钥再给别的apk签名啊

APP签名带来的好处：1应用程序升级。如果你想要升级应用的版本，那么你必须用同一个证书进行签名，这是由于只有以同一个证书签名，系统才会允许安装升级此应用程序。

如果用户使用了不同的证书进行签名，那么系统就会要求您的应用程序换名称，也就相当于安装一个新的应用程序。

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

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

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

String signature_key = "";

try{

PackageInfo packageInfo = contextgetPackageManager()getPackageInfo(pkgName,

PackageManagerGET_SIGNATURES);

Signature[] signatures =

packageInfosignatures;

SignatureKeyparseSignature(signatures[0]toByteArray());

} catch (NameNotFoundException e) {

eprintStackTrace();

} catch (NullPointerException e) {

eprintStackTrace();

}

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

List list =

mPackageManagergetInstalledPackages(0);来得到所有的安装包的信息，这其中包括应用名，包名，大小

（2）

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

StringBuilder builder = new StringBuilder();

for(Signature sign: signatures

){

builderappend(signtoCharsString());

builderappend("/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 =

MessageDigestgetInstance("MD5");

md5MessageDigestupdate(paramArrayOfByte);//

byte[]

tempByte = md5MessageDigestdigest();

int i =

tempBytelength;

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)

{

eprintStackTrace();

}

return

null;

}

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

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

public static void parseSignature(byte[] signature)

{

try

{

CertificateFactory

certFactory =

CertificateFactorygetInstance("X509");

X509Certificate cert = (X509Certificate) certFactorygenerateCertificate(new

ByteArrayInputStream(signature));

String pubKey =

certgetPublicKey()toString(); //公钥

String signNumber =

certgetSerialNumber()toString();

Systemoutprintln("signName:" +

certgetSigAlgName());//算法名

Systemoutprintln("pubKey:" +

pubKey);

Systemoutprintln("signNumber:" +

signNumber);//证书序列编号

Systemoutprintln("subjectDN:"+certgetSubjectDN()toString());

} catch (CertificateException e)

{

eprintStackTrace();

}

}

5 电脑查看APK签名信息

查看三方应用或是系统应用签名

用winrar打开待查看的apk，将其中META-INF文件夹解压出来，得到其中的CERTRSA文件

1keytool

-printcert -file META-INF/CERTRSA

命令是：keytool -printcert -file

<签名文件RSA的路径>

2jarsigner -verify -verbose -certs Superuserapk

此条未验证成功

通过前一篇 Apk签名机制之——JAR签名机制详解 的分析我们知道，JAR签名需要对apk内所有文件进行hash校验，当资源较多时签名验证速度较慢。为了加快验证速度并加强完整性保证，Andorid在70引入一种全文件签名方案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 70中引入的，为了使APK可在Android 70以下版本中安装，应先用JAR签名对APK进行签名，再用V2方案进行签名。要注意顺序一定是先JAR签名再V2签名，因为JAR签名需要修改zip 数据区 和 中央目录 的内容，先使用V2签名再JAR签名会破坏V2签名的完整性。

实际上我们在编译APK时并不需要关心这个过程，在Android Plugin for Gradle 22中，gradle默认会同时使用JAR签名和V2方案对APK进行签名，如果想要关闭JAR签名或V2签名，可以在buildgradle中进行配置：

在 Android 70 中，会优先以 v2方案验证 APK，在Android 70以下版本中，系统会忽略 v2 签名，仅验证 v1 签名。Android 70+的校验过程如下：

因为在经过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的密钥再给别的apk签名啊全部的内容，包括:怎么提取apk的密钥再给别的apk签名啊、如何获取android 签名信息、APK签名机制之——V2签名机制详解等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！