android验证签名

Ⅰ Android APP的签名

Android APP的签名

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应用的发布形式apk中包含的签名加密方法除了RSA还有DSA，所以不能只从apk中提取常见的META-INF/CERT.RSA，第一步应该是检查apk中具体的签名文件是什么。
FILE="yourapp.apk"
cert_XSA=`jar tf $FILE | grep SA`
此时得到的cert_XSA可能是META-INF/*.RSA或者META-INF/*.DSA。

接下来从apk中提取具体的签名文件。
jar xf $FILE $cert_XSA
此时会在当前目录得到cert_XSA文件。

然后对于得到的签名文件，提取其中签名的MD5值
keytool -printcert -file $cert_XSA | grep MD5 > "$FILE.certMD5"
这时候yourapp.certMD5这个文件中就保存了yourapp.apkk中的签名MD5值。

最后比较两个app的签名可以用diff
FILE1="yourapp1.apk"
FILE2="yourapp2.apk"
# ...
# ... 经过上述步骤得到$FILE1.certMD5和$FILE2.certMD5
# ...
certMD5_diff=`diff $FILE1.certMD5 $FILE2.certMD5`
if [ "$certMD5_diff" = "" ]; then
echo "$FILE1.certMD5 == $FILE2.certMD5"
fi
若输出yourapp1.apk.certMD5 == yourapp2.apk.certMD5那么这两个应用的签名就一致。

Ⅲ 安卓 自动签名 以及如何验证一个apk包是用你的签名文件签名的

## 使用自动签名的方法

1. 创建或者修改 ~/.gradle/gradle.properties

2. 在gradle.properties 文件中增加链宽乎下面的内容.(具体内巧棚容需要根据实际来更改)

STORE_PASSWORD=xysys

KEY_ALIAS=xxsasd

KEY_PASSWORD=988asdf

3. 这样每次build的时候，总是用keystore来签名，不会用生成的debug来签名了

## 使用命令行来构建APK

进入项目最高层目录,找到 gradlew. 执行下面的命令来构建所有类型的APK，自动使用官方签名

## 验证签名是官方签名

1. 使用keytool 获取apk包的指纹

例如：

2. 查看keystore的棚悉指纹

apk的签名指纹跟keystore中的指纹一致表明该包是用keystore来签名的。

注意：若java版本是7之前的，需要先把apk解压，

来看包的指纹。

Ⅳ Android签名机制之签名文件和数字证书的作用

Android签名机制目的是确保app的可靠通信，其一，要确定消息的来源确实是其申明

的那个人；其二，要保证信息在传递的过程中不被第三方篡改，即使被篡改了，也可以

发觉出来。

所谓数字签名，就是为了解决这两个问题而产生的，它是对非对称加密技术与数字摘要

技术的一个具体的应用。

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

如果消息的发送者有一天想给消息接收者发消息，在发送的信息中，除了要包含原始的

消息外，还要加上另外一段消息。这段消息通过如下两步生成：

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

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

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

而对于信息的接收者来说，他所收到的信息，将包含两个部分，一是原始的消息内容，

二是附加的那段数字签名。他将通过以下三步来验证消息的真伪：

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

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

3）比较前两步所得到的两段消息是否一致。如果一致，则表明消息确实是期望的发送者

发的，且内容没有被篡改过；相反，如果不一致，则表明传送的过程中一定出了问题，

消息不可信。

通过这种所谓的数字签名技术，确实可以有效解决可靠通信的问题。如果原始消息在传

送的过程中被篡改了，那么在消息接收者那里，对被篡改的消息提取的摘要肯定和原始

的不一样。并且，由于篡改者没有消息发送方的私钥，即使他可以重新算出被篡改消息

的摘要，也不能伪造出数字签名。

那么数字签名呢？

综上所述，数字签名其实就是只有信息的发送者才能产生的别人无法伪造的一段数字

串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。

不知道大家有没有注意，前面讲的这种数字签名方法，有一个前提，就是消息的接收者

必须要事先得到正确的公钥。如果一开始公钥就被别人篡改了，那坏人就会被你当成好

人，而真正的消息发送者给你发的消息会被你视作无效的。而且，很多时候根本就不具

备事先沟通公钥的信息通道。那么如何保证公钥的安全可信呢？这就要靠数字证书来解

决了。

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

证书的发布机构（Issuer）

证书的有效期（Validity）

消息发送方的公钥

证书所有者（Subject）

数字签名所使用的算法

数字签名

可以看出，数字证书其实也用到了数字签名技术。只不过要签名的内容是消息发送方的

公钥，以及一些其它信息。但与普通数字签名不同的是，数字证书中签名者不是随随便

便一个普通的机构，而是要有一定公信力的机构。这就好像你的大学毕业证书上签名的

一般都是德高望重的校长一样。一般来说，这些有公信力机构的根证书已经在设备出厂

前预先安装到了你的设备上了。所以，数字证书可以保证数字证书里的公钥确实是这个

证书的所有者的，或者证书可以用来确认对方的身份。数字证书主要是用来解决公钥的

安全发放问题。

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

引用链接： https://www.cnblogs.com/dacainiao/p/5842987.html

Ⅳ 如何对android的apk签名进行验证

方法/步骤

1
菜单菜单键，键入cmd命令进入命令模式。如图：

2
命令模式中，进入JDK的安装目录的Bin子目录下。（我的JDK安装在E盘，所以先进入E盘，然后再进入JDK安装目录）

3
通过keytool.exe 工具来创建keystore库.
输入以下命令：
keytool -genkeypair -alias - mydemo.keystore -keyalg RSA -validity 100
-keystore mydemo.keystore
命令说明如下：
-genkeypair ：指定生成数字证实
-alias ：指定生成数字证书的别名
-keyalg：指定生成数字证书的算法 这里如RSA算法
-validity：指定生成数字证书的有效期
-keystore ：指定生成数字证书的存储路径。 （这里默认在keytool.exe 目录下）
回车 出现如图交互式界面 输入数字证书费密码 作者 公司等详细信息
如图 ：

4
完成后，keystore库创建完成，你可以在指定的保存目录下找到 如图：

5
使用jarsigner命令对未签名的APK安装包进行签名。使用JDK安装目录下bin子目录下的jarsigner.exe工具来进行签名。
然后把未签名的apk也拷贝到此目录。如图：

6
使用如下命令进行签名：
jarsigner -verbose -keystore mydemo.keystore -signedjar
-Note.apk Notes.apk mydemo.keystore
以上命令的说明：
-verbose：指定生成详细输出
-keystore：指定数字证书存储路径
-signedjar：该选项的三个参数为 签名后的apk包 未签名的apk包 数字证书别名
注意有效期哦。

7
签名后的apk 如图：

8
sdk目录下tool目录下使用zipalign.exe工具优化APK安装包。
将已经签名的apk包放在zipalign.exe同目录下 如图：

9
使用如下命令：
zipalign -f -v 4 -Note.apk -Notes.apk
命令说明：
-f ：指定强制覆盖已有文件
-v 指定生成详细输出
4：指定档案整理基于的字节数 一般是4 也有基于32位的。
-Note.apk :优化前APK
-Notes.apk 优化后的APK

10
运行命令后，在该目录下生成一个-Notes.apk,这个就是优化过的APK安装包
，该安装包可以对外发布。
如图：
如果能对你有帮助，希望你能收藏和支持。

http://jingyan..com/article/3c48dd3491d91fe10be358f4.html

Ⅵ 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/v3 签名机制

这篇文章的内容会涉及以下前置 / 相关知识，贴心的我都帮你准备好了，请享用~

数字签名（Digital Signature）也叫作数字指纹（Digital Fingerprint），它是消息摘要算法和非对称加密算法的结合体，能够验证数据的完整性，并且认证数据的来源 。

数据签名算法的模型分为两个主要阶段：

需要注意的是，Android 目前不对应用证书进行 CA 认证，应用可以由第三方（OEM、运营商、其他应用市场）签名，也可以自行签名。

应用 APK 其实是一种特殊的 Zip 压缩包，无法避免恶意破解者解压 / 反编译修改内容，针对这个问题有何解决方案呢？他山之石，可以攻玉 ——数字签名算法。应用签名正是数字签名算法的应用场景之一，与其他应用场景类似，目的无非是：

Android 平台上运行的每个应用都必须有开发者的签名。在安装应用时，软件包管理器会验证 APK 是否已经过适当签名，安装程序会拒绝没有获得签名就尝试安装的应用。

软件包管理器在安装应用前会验证应用摘要，如果破解者修改了 apk 里的内容，那么摘要就不再匹配，验证失败（验证流程见下文方案）。

截止至 Android 11，Android 支持以下三种应用签名方案：

为了提高兼容性，必须按照 v1、v2、v3 的先后顺序采用签名方案，低版本平台会忽略高版本的签名方案在 APK 中添加的额外数据。

v1 签名方案是基于 Jar 的签名。

首先，我们先来分析其签名产物。 v1 签名后会增加 META-INF 文件夹 ，其中会有如下三个文件。考虑到使用不同的证书和签名方式，得到的文件名可能不同，因此你只要留意文件的后缀即可：

v1 签名流程如下：

MANIFEST.MF（Message Digest File，摘要文件）

*.SF（Signature File，签名文件）

验证流程可以分为验证签名和验证完整性两个步骤：

验证签名步骤：

如果上述签名验证结果正确，才会验证完整性：

以上任何步骤验证失败，则整个 APK 验证失败。

为了解决这些问题，Android 7.0 中引入了 APK 签名方案 v2。

v2 签名方案是一种 全文件签名方案 ，该方案能够发现对 APK 的受保护部分进行的所有更改，相对于 v1 签名方案验证速度更快，完整性覆盖范围更广。

在分析 v2 签名方案之前，我们先简单了解一下 Zip 文件格式：

首先，我们先来分析其签名产物。v2 签名后会在 “条目内容区”和“中央目录区”之间插入“APK 签名分块（APK Signing Block）” 。

从左到右边，我们定义为区块 1~4。

相对与 v1 签名方案，v2 签名方案不再以文件为单位计算摘要了，而是以 1 MB 为单位将文件拆分为多个连续的块（chunk），每个分区的最后一个块可能会小于 1 MB。

v2 签名流程如下：

验证流程可以分为验证签名和验证完整性两个步骤：

签名方案 v3 支持密钥轮换，应用能够在 APK 更新过程中更改其签名密钥。

【累了，后面先不写了...】

这一节，我们介绍基于 Android 应用签名机制的衍生应用场景。

在 v1 方案中， MANIFEST.MF 和 *.SF 这两个文件会记录大量的文件名和文件摘要。如果 apk 中文件数很多，而且文件名很长，那么这两个文件会变得很大。使用 AndResGuard 工具，可以将文件名转换为短路径文件名，从而减少这两个文件的大小。

在实际生产中，往往需要生成多个渠道的 APK 包，传统的方法是使用 APKTool 逆向工具、Flavor + BuildType 等方案，这一类多渠道打包方案的缺点是耗时严重。随着 Android 应用签名方案的演进，演变出了不同的多渠道打包方案：

在 v1 方案中，我们提到了完整性校验不覆盖到 META-INF 文件夹的问题。有些多渠道打包方案就是利用了这个问题，在 META-INF 文件夹下添加空文件， 用空文件的名称来作为渠道的唯一标识 ，就可以节省打包的时间，提高打渠道包的速度。

除了添加空文件的方法，还可以向 APK 添加 Zip Comment 来生成多渠道包（APK 本身就是特殊的 Zip 包）。

在 v2 签名方案中，几乎整个 APK 都纳入保护范围，如果向 APK 添加空文件或 Zip Comment 的话，在安装时会报以下错误：

新背景下的多渠道打包方案，则是利用了 APK 签名分块（区块 2）不受保护 & 字段可扩展的特点 ，向区块中添加多渠道信息（ID-Value），例如 美团多渠道打包方案 Walle 。