Android应用程序签名过程和解析过程分析

在正式解释Android应用程序签名过程之前，作为铺垫，还得先讲讲最基本的一些概念。

非对称加密算法

非对称加密算法需要两个密钥：公开密钥（简称公钥）和私有密钥（简称私钥）。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密；如果用私钥对数据进行加密，那么只有用对应的公钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。

非对称加密算法是数字签名和数字证书的基础，大家非常熟悉的RSA就是非对称加密算法的一种实现。

消息摘要算法

消息摘要算法（Message Digest Algorithm）是一种能产生特殊输出格式的算法，其原理是根据一定的运算规则对原始数据进行某种形式的信息提取，被提取出的信息就被称作原始数据的消息摘要。著名的摘要算法有RSA公司的MD5算法和SHA-1算法及其大量的变体。

消息摘要的主要特点有：

 

1）无论输入的消息有多长，计算出来的消息摘要的长度总是固定的。例如应用MD5算法摘要的消息有128个比特位，用SHA-1算法摘要的消息最终有160比特位的输出。

2）一般来说（不考虑碰撞的情况下），只要输入的原始数据不同，对其进行摘要以后产生的消息摘要也必不相同，即使原始数据稍有改变，输出的消息摘要便完全不同。但是，相同的输入必会产生相同的输出。

3）具有不可逆性，即只能进行正向的信息摘要，而无法从摘要中恢复出任何的原始消息。

数字签名和数字证书

其实数字签名的概念很简单。大家知道，要确保可靠通信，必须要解决两个问题：首先，要确定消息的来源确实是其申明的那个人；其次，要保证信息在传递的过程中不被第三方篡改，即使被篡改了，也可以发觉出来。

所谓数字签名，就是为了解决这两个问题而产生的，它是对前面提到的非对称加密技术与数字摘要技术的一个具体的应用。

对于消息的发送者来说，先要生成一对公私钥对，将公钥给消息的接收者。

如果消息的发送者有一天想给消息接收者发消息，在发送的信息中，除了要包含原始的消息外，还要加上另外一段消息。这段消息通过如下两步生成：

1）对要发送的原始消息提取消息摘要；

2）对提取的信息摘要用自己的私钥加密。

通过这两步得出的消息，就是所谓的原始信息的数字签名。

而对于信息的接收者来说，他所收到的信息，将包含两个部分，一是原始的消息内容，二是附加的那段数字签名。他将通过以下三步来验证消息的真伪：

1）对原始消息部分提取消息摘要，注意这里使用的消息摘要算法要和发送方使用的一致；

2）对附加上的那段数字签名，使用预先得到的公钥解密；

3）比较前两步所得到的两段消息是否一致。如果一致，则表明消息确实是期望的发送者发的，且内容没有被篡改过；相反，如果不一致，则表明传送的过程中一定出了问题，消息不可信。

通过这种所谓的数字签名技术，确实可以有效解决可靠通信的问题。如果原始消息在传送的过程中被篡改了，那么在消息接收者那里，对被篡改的消息提取的摘要肯定和原始的不一样。并且，由于篡改者没有消息发送方的私钥，即使他可以重新算出被篡改消息的摘要，也不能伪造出数字签名。

所以，综上所述，数字签名其实就是只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。

不知道大家有没有注意，前面讲的这种数字签名方法，有一个前提，就是消息的接收者必须要事先得到正确的公钥。如果一开始公钥就被别人篡改了，那坏人就会被你当成好人，而真正的消息发送者给你发的消息会被你视作无效的。而且，很多时候根本就不具备事先沟通公钥的信息通道。那么如何保证公钥的安全可信呢？这就要靠数字证书来解决了。

所谓数字证书，一般包含以下一些内容：

• 证书的发布机构（Issuer）
• 证书的有效期（Validity）
• 消息发送方的公钥
• 证书所有者（Subject）
• 数字签名所使用的算法
• 数字签名

可以看出，数字证书其实也用到了数字签名技术。只不过要签名的内容是消息发送方的公钥，以及一些其它信息。但与普通数字签名不同的是，数字证书中签名者不是随随便便一个普通的机构，而是要有一定公信力的机构。这就好像你的大学毕业证书上签名的一般都是德高望重的校长一样。一般来说，这些有公信力机构的根证书已经在设备出厂前预先安装到了你的设备上了。所以，数字证书可以保证数字证书里的公钥确实是这个证书的所有者的，或者证书可以用来确认对方的身份。数字证书主要是用来解决公钥的安全发放问题。

综上所述，总结一下，数字签名和签名验证的大体流程如下图所示：

Android应用程序签名流程

大家知道，Android采用的是开放的生态系统，任何人都可以开发和发布应用程序给别人使用。不像iOS，在没有被破解的情况下只能通过App Store安装应用，Android在打开了“Unknow Sources”选项后，可以安装任何来源的应用程序，可以是第三方市场，可以是自己开发的应用，也可以从论坛下载。

那么问题来了，对于有一些不怀好意的人，完全可以拿到一个原生的应用，然后加入一些恶意的代码，再发布出去，诱使别人去安装，达到不可告人的目的。

有没有什么办法可以防止应用程序在传送的过程中被第三方恶意篡改呢？Google因此引入了应用程序签名机制。

它是如何工作的呢？我们先来看看签名前后，一个apk文件到底发生了哪些变化。

首先，在没签名之前，apk文件内的目录结构是这样的：

而签名之后，会变成这样：

可以看到，多出来了一个META-INF目录。可以肯定的是，签名的机关就在这个目录中，里面有三个文件：

其实，在Android的源代码里包含了一个工具，可以对apk文件进行签名，具体的代码位置在build oolssignapk目录下，通过分析其中的SignApk.java文件，可以大致了解签名的过程。其流程大致有如下几步：

1）打开待签名的apk文件（由于apk其实是一个用zip压缩的文件，其实就是用zip解压整个apk文件），逐一遍历里面的所有条目，如果是目录就跳过，如果是一个文件，就用SHA1（或者SHA256）消息摘要算法提取出该文件的摘要然后进行BASE64编码后，作为“SHA1-Digest”属性的值写入到MANIFEST.MF文件中的一个块中。该块有一个“Name”属性，其值就是该文件在apk包中的路径。

2）计算这个MANIFEST.MF文件的整体SHA1值，再经过BASE64编码后，记录在CERT.SF主属性块（在文件头上）的“SHA1-Digest-Manifest”属性值值下。

然后，再逐条计算MANIFEST.MF文件中每一个块的SHA1，并经过BASE64编码后，记录在CERT.SF中的同名块中，属性的名字是“SHA1-Digest”。

3）把之前生成的 CERT.SF文件， 用私钥计算出签名, 然后将签名以及包含公钥信息的数字证书一同写入  CERT.RSA  中保存。CERT.RSA是一个满足PKCS7格式的文件，可以通过openssl工具来查看签名证书的信息。在Ubuntu或者在Windows上使用Cygwin，敲入以下命令：

openssl pkcs7 -inform DER -in CERT.RSA -noout -print_certs –text

可以得到如下输出：

下面我们来看看，如果apk文件被篡改后会发生什么。

首先，如果你改变了apk包中的任何文件，那么在apk安装校验时，改变后的文件摘要信息与MANIFEST.MF的检验信息不同，于是验证失败，程序就不能成功安装。

其次，如果你对更改的过的文件相应的算出新的摘要值，然后更改MANIFEST.MF文件里面对应的属性值，那么必定与CERT.SF文件中算出的摘要值不一样，照样验证失败。

最后，如果你还不死心，继续计算MANIFEST.MF的摘要值，相应的更改CERT.SF里面的值，那么数字签名值必定与CERT.RSA文件中记录的不一样，还是失败。

那么能不能继续伪造数字签名呢？不可能，因为没有数字证书对应的私钥。

所以，如果要重新打包后的应用程序能再Android设备上安装，必须对其进行重签名。

总结

1）Android应用程序签名只是用来解决发布的应用不被别人篡改的，其并不会对应用程序本身进行加密，这点不同于Windows Phone和iOS。

2）Android并不要求所有应用程序的签名证书都由可信任CA的根证书签名，通过这点保证了其生态系统的开放性，所有人都可以用自己生成的证书对应用程序签名。

3）如果想修改一个已经发布的应用程序，哪怕是修改一张图片，都必须对其进行重新签名。但是，签原始应用的私钥一般是拿不到的（肯定在原始应用程序开发者的手上，且不可能公布出去），所以只能用另外一组公私钥对，生成一个新的证书，对重打包的应用进行签名。所以重打包的apk中所带证书的公钥肯定和原始应用不一样。同时，在手机上如果想安装一个应用程序，应用程序安装器会先检查相同包名的应用是否已经被安装过，如果已经安装过，会继续判断已经安装的应用和将要安装的应用，其所携带的数字证书中的公钥是否一致。如果相同，则继续安装；而如果不同，则会提示用户先卸载前面已安装的应用。通过这种方式来提示用户，前后两个应用是不同开发者签名的，可能有一个是李鬼。

　

Android应用程序签名验证过程分析

 

 

版权声明：本文为博主原创文章，未经博主允许不得转载。

在前面的《Android应用程序签名过程分析》中，我大致分析了Android应用程序签名的过程，接下来我将结合源代码，分析一下Android应用程序在安装过程中对签名进行验证的过程。

我们还是用前面的例子分析，假设签名后，apk文件中多了一个META-INF目录，里面有三个文件，分别是MANIFEST.MF、CERT.SF和CERT.RSA：

通过前面的分析，我们可以知道，MANIFEST.MF中记录的是apk中所有文件的摘要值；CERT.SF中记录的是对MANIFEST.MF的摘要值，包括整个文件的摘要，还有文件中每一项的摘要；而CERT.RSA中记录的是对CERT.SF文件的签名，以及签名的公钥。

大家知道，Android平台上所有应用程序安装都是由PackageManangerService（代码位于frameworksaseservicescorejavacomandroidserverpmPackageManagerService.java）来管理的，Android的安装流程非常复杂，与签名验证相关的步骤位于installPackageLI函数中：

private void installPackageLI(InstallArgs args, PackageInstalledInfo res) {
    ……
    PackageParser pp = new PackageParser();
    ……
    try {
        pp.collectCertificates(pkg, parseFlags);
        pp.collectManifestDigest(pkg);
    } catch (PackageParserException e) {
        res.setError("Failed collect during installPackageLI", e);
        return;
    }
    ……

PackageParser（代码位于frameworksasecorejavaandroidcontentpmPackageParser.java，编译后存在于framework.jar文件中）是一个apk包的解析器，接下来我们来看其collectCertificates函数的实现：

public void collectCertificates(Package pkg, int flags) throws PackageParserException {
    pkg.mCertificates = null;
    pkg.mSignatures = null;
    pkg.mSigningKeys = null;

    collectCertificates(pkg, new File(pkg.baseCodePath), flags);
    ……

接着调用了collectCertficates的一个重载版本：

private static void collectCertificates(Package pkg, File apkFile, int flags)
            throws PackageParserException {
    final String apkPath = apkFile.getAbsolutePath();

    StrictJarFile jarFile = null;
    try {
        jarFile = new StrictJarFile(apkPath);
        ……

函数的开头，首先创建了一个StrictJarFile（代码位于libcorelunisrcmainjavajavautiljarStrictJarFile.java，编译后存在于core.jar文件中）对象，先来看看其构造函数中的内容：

public StrictJarFile(String fileName) throws IOException {
    ……
    try {
        HashMap<String, byte[]> metaEntries = getMetaEntries();
        this.manifest = new Manifest(metaEntries.get(JarFile.MANIFEST_NAME), true);
        this.verifier = new JarVerifier(fileName, manifest, metaEntries);

        isSigned = verifier.readCertificates() && verifier.isSignedJar();
        ……

这里构造了几个重要的对象。首先，获得了META-INF目录下所有文件名及其字节流。然后是构造了一个manifest对象，主要是用来处理对META-INF目录下MANIFEST.MF文件的操作。接着，构造了一个JarVeirifer（代码位于libcorelunisrcmainjavajavautiljarJarVerifier.java文件中，编译后存在于core.jar文件中）对象，这个对象主要实现了对Jar文件的验证工作，非常关键，后面的分析中会逐步提到。在构造函数的最后，调用了JarVeirifer.readCertificates函数：

synchronized boolean readCertificates() {
    if (metaEntries.isEmpty()) {
        return false;
    }

    Iterator<String> it = metaEntries.keySet().iterator();
    while (it.hasNext()) {
        String key = it.next();
        if (key.endsWith(".DSA") || key.endsWith(".RSA") || key.endsWith(".EC")) {
            verifyCertificate(key);
            it.remove();
        }
    }
    return true;
}

代码遍历所有META-INF目录下的文件，找到以.DSA、.RSA或者.EC结尾的文件，以这些名字结尾的文件都是所谓的签名证书文件。在本例中对应的是META-INF目录下的CERT.RSA签名文件。然后调用JarVeirifer.verifyCertificate函数：

private void verifyCertificate(String certFile) {
    String signatureFile = certFile.substring(0, certFile.lastIndexOf('.')) + ".SF";
    byte[] sfBytes = metaEntries.get(signatureFile);
    if (sfBytes == null) {
        return;
    }
    ……
    byte[] sBlockBytes = metaEntries.get(certFile);
    try {
       Certificate[] signerCertChain = JarUtils.verifySignature(
                    new ByteArrayInputStream(sfBytes),
                    new ByteArrayInputStream(sBlockBytes));
        if (signerCertChain != null) {
            certificates.put(signatureFile, signerCertChain);
        }
    } catch (IOException e) {
        return;
    } catch (GeneralSecurityException e) {
        throw failedVerification(jarName, signatureFile);
    }
    ……

函数开头，首先找到与证书文件同名，但是以.SF结尾的签名文件，本例中即为META-INF目录下的CERT.SF文件。然后分别获得签名文件CERT.SF和证书文件CERT.RSA的字节流，调用JarUtils（代码位于libcorelunisrcmainjavaorgapacheharmonysecurityutilsJarUtils.java文件中，编译后存在于core.jar文件中）的verifySignature函数，验证CERT.RSA文件中包含的对CERT.SF文件的签名是否正确。如果验证失败，则会抛出GeneralSecurityException异常；而如果验证成功，则会返回签名的证书链。回到JarVeirifer.verifyCertificate函数，如果JarUtils.verifySignature验证失败抛出异常，被捕获后会接着向上抛出SecurityException异常；

private static SecurityException failedVerification(String jarName, String signatureFile) {
    throw new SecurityException(jarName + " failed verification of " + signatureFile);
}

而如果签名验证成功的话，会将证书链保存在certifcates属性变量中。而JarVerifier自己的isSignedJar函数，就是判断一下这个certificates属性变量是否为空。

boolean isSignedJar() {
    return certificates.size() > 0;
}

如果不为空就代表这个Jar是签过名的，如果为空则代表其没有签过名。我们接着看JarVeirifer.verifyCertificate函数：

……
Attributes attributes = new Attributes();
HashMap<String, Attributes> entries = new HashMap<String, Attributes>();
try {
    ManifestReader im = new ManifestReader(sfBytes, attributes);
    im.readEntries(entries, null);
} catch (IOException e) {
    return;
}

if (attributes.get(Attributes.Name.SIGNATURE_VERSION) == null) {
    return;
}

boolean createdBySigntool = false;
String createdBy = attributes.getValue("Created-By");
if (createdBy != null) {
    createdBySigntool = createdBy.indexOf("signtool") != -1;
}
……

函数接下来读取了所谓签名文件，也就是META-INF目录下CERT.SF文件中的内容。CERT.SF文件内容大致如下：

接着，判断了是否有“Signature-Version”属性，如果没有的话，直接返回。再下来判断apk是否是由签名工具签的名，判断条件就是在“Created-By”属性值内有没有“signtool”字符串。本例中，签名版本是“1.0”，并且不是用其它签名工具签的名。如果不是用其它工具签名的话，接下来还会验证主属性中是否有“SHA1-Digest-Manifest-Main-Attributes”属性的值，这个属性值记录的是对META-INF目录下MANIFEST.MF文件内，头属性块的hash值。

……
byte[] manifestBytes = metaEntries.get(JarFile.MANIFEST_NAME);
if (manifestBytes == null) {
    return;
}
……
if (mainAttributesEnd > 0 && !createdBySigntool) {
    String digestAttribute = "-Digest-Manifest-Main-Attributes";
    if (!verify(attributes, digestAttribute, manifestBytes, 0, mainAttributesEnd, false, true)) {
        throw failedVerification(jarName, signatureFile);
    }
}
……

接着调用了JarVerifier.verify对该摘要值进行验证：

private boolean verify(Attributes attributes, String entry, byte[] data,
            int start, int end, boolean ignoreSecondEndline, boolean ignorable) {
    for (int i = 0; i < DIGEST_ALGORITHMS.length; i++) {
        String algorithm = DIGEST_ALGORITHMS[i];
        String hash = attributes.getValue(algorithm + entry);
        if (hash == null) {
            continue;
        }

        MessageDigest md;
        try {
            md = MessageDigest.getInstance(algorithm);
        } catch (NoSuchAlgorithmException e) {
            continue;
        }
        if (ignoreSecondEndline && data[end - 1] == '
' && data[end - 2] == '
') {
            md.update(data, start, end - 1 - start);
        } else {
            md.update(data, start, end - start);
        }
        byte[] b = md.digest();
        byte[] hashBytes = hash.getBytes(StandardCharsets.ISO_8859_1);
        return MessageDigest.isEqual(b, Base64.decode(hashBytes));
    }
    return ignorable;
}

JarVerifier.verify函数很简单，由于不知道到底是用什么算法算出的散列值，所以其会遍历所有的可能算法。这些算法都预先定义在DIGEST_ALGORITHMS这个JarVerifier内的静态字符串数组变量中：

private static final String[] DIGEST_ALGORITHMS = new String[] {
    "SHA-512",
    "SHA-384",
    "SHA-256",
    "SHA1",
};

可以看出，一共支持四种算法，本例中用到的是SHA1摘要算法。变量attributes表示的是一个属性块，而变量entry是要在attributes属性块中查找的属性名的一部分，它会与摘要算法的名称拼接成正真的属性名。接着会将在属性块中，对应属性名的属性值取出来，与data数据块中start到end之间的数据，用同样算法算出的摘要值进行比较，如果一致就返回“true”，不一致则返回“false”。

而ignorable表示这个验证是否可忽略，也就是说如果要查找的属性不存在的情况下，如果可忽略，则仍然返回“true”。但如果属性值确实存在则这项对判断结果没有任何影响。本例中，根本没有这个属性，但是验证任然是通过的，因为在调用的时候，最后一个参数ignorable被设置成了“true”。

    ……
    String digestAttribute = createdBySigntool ? "-Digest" : "-Digest-Manifest";
    if (!verify(attributes, digestAttribute, manifestBytes, 0, manifestBytes.length, false, false)) {
        Iterator<Map.Entry<String, Attributes>> it = entries.entrySet().iterator();
        while (it.hasNext()) {
            Map.Entry<String, Attributes> entry = it.next();
            Manifest.Chunk chunk = manifest.getChunk(entry.getKey());
            if (chunk == null) {
                return;
            }
            if (!verify(entry.getValue(), "-Digest", manifestBytes,
                    chunk.start, chunk.end, createdBySigntool, false)) {
                throw invalidDigest(signatureFile, entry.getKey(), jarName);
            }
        }
    }
    metaEntries.put(signatureFile, null);
    signatures.put(signatureFile, entries);
}

JarVeirifer.verifyCertificate剩下的代码就很简单了，会比较MANIFEST.MF文件的整体摘要值和每一个属性块的摘要值，与CERT.SF文件中记录的是否一致。如果都验证通过的话，会将该签名文件的信息加到metaEntries和signatures属性变量中去。

所以，在StrictJarFile构造的过程中就已经完成了两步验证：一是通过在CERT.RSA文件中记录的签名信息，验证了CERT.SF没有被篡改过；二是通过CERT.SF文件中记录的摘要值，验证了MANIFEST.MF没有被修改过。

所以，到目前为止，还有一步没有被验证，即apk内文件的摘要值要与MANIFEST.MF文件中记录的一致。接下来，让我们继续回到PackageParser. collectCertificates函数中：

……
final ZipEntry manifestEntry = jarFile.findEntry(ANDROID_MANIFEST_FILENAME);
if (manifestEntry == null) {
    throw new PackageParserException(INSTALL_PARSE_FAILED_BAD_MANIFEST,
                "Package " + apkPath + " has no manifest");
}

final List<ZipEntry> toVerify = new ArrayList<>();
toVerify.add(manifestEntry);

if ((flags & PARSE_IS_SYSTEM) == 0) {
    final Iterator<ZipEntry> i = jarFile.iterator();
    while (i.hasNext()) {
        final ZipEntry entry = i.next();

        if (entry.isDirectory()) continue;
        if (entry.getName().startsWith("META-INF/")) continue;
        if (entry.getName().equals(ANDROID_MANIFEST_FILENAME)) continue;

        toVerify.add(entry);
    }
}
……

接下来的代码主要是用来确定，到底哪些文件需要进行验证。AndroidManifest.xml无论如何都要验证。如果不是系统，也就是普通的应用程序安装，必须要验证除去位于META-INF目录下所有文件之外的所有剩下的文件。

……
for (ZipEntry entry : toVerify) {
    final Certificate[][] entryCerts = loadCertificates(jarFile, entry);
    if (ArrayUtils.isEmpty(entryCerts)) {
        throw new PackageParserException(
                    INSTALL_PARSE_FAILED_NO_CERTIFICATES,
                    "Package " + apkPath + " has no certificates at entry " + entry.getName());
    }
    final Signature[] entrySignatures = convertToSignatures(entryCerts);
    ……

接着是逐项验证前面罗列出的apk中的各个文件。对每个文件，都接着调用了PackageParser.loadCertificates函数：

private static Certificate[][] loadCertificates(StrictJarFile jarFile, ZipEntry entry)
            throws PackageParserException {
    InputStream is = null;
    try {
        is = jarFile.getInputStream(entry);
        readFullyIgnoringContents(is);
        return jarFile.getCertificateChains(entry);
    } catch (IOException | RuntimeException e) {
        throw new PackageParserException(INSTALL_PARSE_FAILED_UNEXPECTED_EXCEPTION,
                    "Failed reading " + entry.getName() + " in " + jarFile, e);
    } finally {
        IoUtils.closeQuietly(is);
    }
}

貌似没有什么特别的，只是对apk内的文件创建了一个输入流，并且通过函数PackageParser.readFullyIgnoringContents全读了一遍，而且通过函数名可以看出，具体读出什么内容并不重要。我们先来看看StrictJarFile.getInputStream函数：

public InputStream getInputStream(ZipEntry ze) {
    final InputStream is = getZipInputStream(ze);

    if (isSigned) {
        JarVerifier.VerifierEntry entry = verifier.initEntry(ze.getName());
        if (entry == null) {
            return is;
        }

        return new JarFile.JarFileInputStream(is, ze.getSize(), entry);
    }

    return is;
}

重点要关注两个函数调用，一是JarVerifier.initEntry，二是JarFile.JarFileInputStream。好，我们先来看第一个：

VerifierEntry initEntry(String name) {
    if (manifest == null || signatures.isEmpty()) {
        return null;
    }

    Attributes attributes = manifest.getAttributes(name);
    if (attributes == null) {
        return null;
    }

    ArrayList<Certificate[]> certChains = new ArrayList<Certificate[]>();
    Iterator<Map.Entry<String, HashMap<String, Attributes>>> it = signatures.entrySet().iterator();
    while (it.hasNext()) {
        Map.Entry<String, HashMap<String, Attributes>> entry = it.next();
        HashMap<String, Attributes> hm = entry.getValue();
        if (hm.get(name) != null) {
            String signatureFile = entry.getKey();
            Certificate[] certChain = certificates.get(signatureFile);
            if (certChain != null) {
                certChains.add(certChain);
            }
        }
    }

    if (certChains.isEmpty()) {
        return null;
    }
    Certificate[][] certChainsArray = certChains.toArray(new Certificate[certChains.size()][]);

    for (int i = 0; i < DIGEST_ALGORITHMS.length; i++) {
        final String algorithm = DIGEST_ALGORITHMS[i];
        final String hash = attributes.getValue(algorithm + "-Digest");
        if (hash == null) {
            continue;
        }
        byte[] hashBytes = hash.getBytes(StandardCharsets.ISO_8859_1);

        try {
            return new VerifierEntry(name, MessageDigest.getInstance(algorithm), hashBytes,
                        certChainsArray, verifiedEntries);
        } catch (NoSuchAlgorithmException ignored) {
        }
    }
    return null;
}

该函数主要的用途就是构造一个JarVerifer.VerifierEntry对象：

要构造这个对象，必须事先准备好参数。第一个参数很简单，就是要验证的文件名，直接将name传进来就好了。第二个参数是计算摘要的对象，可以通过MessageDigest.getInstance获得，不过要先告知到底要用哪个摘要算法，同样也是通过查看MANIFEST.MF文件中对应名字的属性值来决定的。本例中的MANIFEST.MF文件格式大致如下：

所以可以知道所用的摘要算法是SHA1。第三个参数是对应文件的摘要值，这是通过读取MANIFEST.MF文件获得的。第四个参数是证书链，即对该apk文件签名的所有证书链信息。为什么是二维数组呢？这是因为Android允许用多个证书对apk进行签名，但是它们的证书文件名必须不同。最后一个参数是已经验证过的文件列表，VerifierEntry在完成了对指定文件的摘要验证之后会将该文件的信息加到其中。

生成好了entry之后，我们接下来看JarFile（代码位于）中的JarFileInputStream函数的实现：

static final class JarFileInputStream extends FilterInputStream {
    private final JarVerifier.VerifierEntry entry;

    private long count;
    private boolean done = false;

    JarFileInputStream(InputStream is, long size, JarVerifier.VerifierEntry e) {
        super(is);
        entry = e;

        count = size;
    }
    ……

其构造函数没有什么特别的，只是完成了赋值的操作。所以，调用StrictJarFile.getInputStream函数之后，实际返回的是一个JarFileInputStream对象。在获得了这个输入流对象后，紧接着，PackageParser.loadCertificates会调用PackageParser .readFullyIgnoringContents对这个输入流进行读取的操作：

public static long readFullyIgnoringContents(InputStream in) throws IOException {
    byte[] buffer = sBuffer.getAndSet(null);
    if (buffer == null) {
        buffer = new byte[4096];
    }

    int n = 0;
    int count = 0;
    while ((n = in.read(buffer, 0, buffer.length)) != -1) {
        count += n;
    }

    sBuffer.set(buffer);
    return count;
}

没什么特别的，只是调用了InputStream的read函数，直到读完为止，而且只是返回了读到了多少个字节，并没有返回读到的内容，所以读到什么内容它并不关心。由于实际传进来的是InputStream的子类，这里也就是JarFileInputStream，它对read函数进行了重载，看它是如何实现的：

public int read(byte[] buffer, int byteOffset, int byteCount) throws IOException {
    if (done) {
        return -1;
    }
    if (count > 0) {
        int r = super.read(buffer, byteOffset, byteCount);
        if (r != -1) {
            int size = r;
            if (count < size) {
                size = (int) count;
            }
            entry.write(buffer, byteOffset, size);
            count -= size;
        } else {
            count = 0;
        }
        if (count == 0) {
            done = true;
            entry.verify();
        }
        return r;
    } else {
        done = true;
        entry.verify();
        return -1;
    }
}

玄机原来在这里，这里的JarFileInputStream.read确实会调用其父类的read读取指定的apk内文件的内容，并且将其传给JarVerifier.VerifierEntry.write函数。当文件读完后，会接着调用JarVerifier.VerifierEntry.verify函数对其进行验证。JarVerifier.VerifierEntry.write函数非常简单：

public void write(byte[] buf, int off, int nbytes) {
    digest.update(buf, off, nbytes);
}

就是将读到的文件的内容传给digest，这个digest就是前面在构造JarVerifier.VerifierEntry传进来的，对应于在MANIFEST.MF文件中指定的摘要算法。万事具备，接下来想要验证就很简单了：

void verify() {
    byte[] d = digest.digest();
    if (!MessageDigest.isEqual(d, Base64.decode(hash))) {
        throw invalidDigest(JarFile.MANIFEST_NAME, name, name);
    }
    verifiedEntries.put(name, certChains);
}

通过digest就可以算出apk内指定文件的真实摘要值。而记录在MANIFEST.MF文件中对应该文件的摘要值，也在构造JarVerifier.VerifierEntry时传递给了hash变量。不过这个hash值是经过Base64编码的。所以在比较之前，必须通过Base64解码。如果不一致的话，会抛出SecurityException异常：

private static SecurityException invalidDigest(String signatureFile, String name,
        String jarName) {
    throw new SecurityException(signatureFile + " has invalid digest for " + name +
            " in " + jarName);
}

至此，最后一步验证，即apk内所有文件的摘要值要和在MANIFEST.MF文件中记录的一致，也已经完成了。这还没完，PackageParser.collectCertificates还要接着验证apk文件中的每个文件对应的签名要和第一个文件一致：

……
if (pkg.mCertificates == null) {
    pkg.mCertificates = entryCerts;
    pkg.mSignatures = entrySignatures;
    pkg.mSigningKeys = new ArraySet<PublicKey>();
    for (int i=0; i < entryCerts.length; i++) {
        pkg.mSigningKeys.add(entryCerts[i][0].getPublicKey());
    }
} else {
    if (!Signature.areExactMatch(pkg.mSignatures, entrySignatures)) {
        throw new PackageParserException(
            INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES,
            "Package " + apkPath + " has mismatched certificates at entry "
            + entry.getName());
    }
}
……

到这里，apk安装时的签名验证过程都已经分析完了，来总结一下：

1. 所有有关apk文件的签名验证工作都是在JarVerifier里面做的，一共分成三步；
2. JarVeirifer.verifyCertificate主要做了两步。首先，使用证书文件（在META-INF目录下，以.DSA、.RSA或者.EC结尾的文件）检验签名文件（在META-INF目录下，和证书文件同名，但扩展名为.SF的文件）是没有被修改过的。然后，使用签名文件，检验MANIFEST.MF文件中的内容也没有被篡改过；
3. JarVerifier.VerifierEntry.verify做了最后一步验证，即保证apk文件中包含的所有文件，对应的摘要值与MANIFEST.MF文件中记录的一致。