求帮忙：一个游戏APK更改安装包签名，想更改一下applicationId，求大神帮忙。

来源：蜘蛛抓取(WebSpider) 时间：2018-09-26 06:32 标签： 更改安装包签名

  • 正式应用和测试用应用需要同时安装在同一台手机上
  • 正式和测试拥有不同的签名、名称、图标。。。等等
  • 其他 例如 极光 配置不同账号，测试和正式的分开（吐槽也止呕极光才需要配置不同applicationId来区分，就这么而）

    • 那么他们之间到底有什么区别呢？

      • 包名： 文件所在的具体目录，
      • applicationId : 我们可以简单的认为是进程的名字， 那么我们就知道，测试和正式其实配置
        不同的applicationId, 那就相当于是不同的app所以可以同时安装在 同一款手机上

  • 清单文件如何更？ gradle 如何更改？

  • 清单文件里面的app lable 我们需要占位符 占位 然后再 gradle 里面配置 测试和正式的 不同的名字

  • 从名字就可以看出是清单文件的占位配置，好了有了这些东西那么我们就可以开始进行配置了

极光在清单文件里面有很多地方需要配置 JPUSH_PKGNAME 是记得更改 每个地方都用占位来替代 APP_NAME:"良医帮" // 还记得吗在上面图片中的占位 在这里进行配置 就有了不同的名字，其他需求同辞

如何查看我们是否更改成功

  1. 运行到手机上，查看进程
  2. 点击build目录下的app包 然后打开清单文件 查看里面刚才的占位符 是否都更改过来了

版权声明：部分文字及图片来自于网络，如侵犯到您的权益，请及时通知 /long/article/details/

最近项目有需求： 只有使用特定签名签的apk才可以安装，其他任何apk都不能安装（root版，使用adb push进去的除外），以供以后参考。

我们已经知道的是：Android对每一个Apk文件都会进行签名，在Apk文件安装时，系统会对其签名信息进行比对，判断程序的完整性，从而决定该Apk文件是否可以安装，在一定程度上达到安全的目的。

给定一个Apk文件，解压，可以看到一个META-INFO文件夹，在该文件夹下有三个文件：分别为'


  1. 将ROM文件（*.zip）或程序（*.apk）放到本文件夹，双击执行Auto_Sign.bat，选择要签名的文件类型。签名后的文件放置在Signed文件夹内。  


发布过Android应用的朋友们应该都知道，Android APK的发布是需要签名的。签名机制在Android应用和框架中有着十分重要的作用。

例如，Android系统禁止更新安装签名不一致的APK；如果应用需要使用system权限，必须保证APK签名与Framework签名一致，等等。在一文中，我们了解到，要破解一个APK，必然需要重新对APK进行签名。而这个签名，一般情况无法再与APK原先的签名保持一致。（除非APK原作者的私钥泄漏，那已经是另一个层次的软件安全问题了。）

简单地说，签名机制标明了APK的发行机构。因此，站在软件安全的角度，我们就可以通过比对APK的签名情况，判断此APK是否由“官方”发行，而不是被破解篡改过重新签名打包的“盗版软件”。

    为了说明APK签名比对对软件安全的有效性，我们有必要了解一下Android APK的签名机制。为了更易于大家理解，我们从Auto-Sign工具的一条批处理命令说起。

在一文中，我们了解到，要签名一个没有签名过的APK，可以使用一个叫作Auto-sign的工具。Auto-sign工具实际运行的是一个叫做Sign.bat的批处理命令。用文本编辑器打开这个批处理文件，我们可以发现，实现签名功能的命令主要是这一行命令：

    对于此处所使用的私钥和公钥的生成方式，这里就不做进一步介绍了。这方面的资料大家可以找到很多。我们这里要讲的是signapk.jar到底做了什么。

对比一个没有签名的APK和一个签名好的APK，我们会发现，签名好的APK包中多了一个叫做META-INF的文件夹。里面有三个文件，分别名为MANIFEST.MF、CERT.SF和CERT.RSA。signapk.jar就是生成了这几个文件（其他文件没有任何改变。因此我们可以很容易去掉原有签名信息）。

程序遍历update.apk包中的所有文件(entry)，对非文件夹非签名文件的文件，逐个生成SHA1的数字签名信息，再用Base64进行编码。具体代码见这个方法：

    这里简单介绍下SHA1数字签名。简单地说，它就是一种安全哈希算法，类似于MD5算法。它把任意长度的输入，通过散列算法变成固定长度的输出（这里我们称作“摘要信息”）。你不能仅通过这个摘要信息复原原来的信息。另外，它保证不同信息的摘要信息彼此不同。因此，如果你改变了apk包中的文件，那么在apk安装校验时，改变后的文件摘要信息与MANIFEST.MF的检验信息不同，于是程序就不能成功安装。

对前一步生成的Manifest，使用SHA1-RSA算法，用私钥进行签名。关键代码如下：

    RSA是一种非对称加密算法。用私钥通过RSA算法对摘要信息进行加密。在安装时只能使用公钥才能解密它。解密之后，将它与未加密的摘要信息进行对比，如果相符，则表明内容没有被异常修改。

生成MANIFEST.MF没有使用密钥信息，生成CERT.SF文件使用了私钥文件。那么我们可以很容易猜测到，CERT.RSA文件的生成肯定和公钥相关。

CERT.RSA文件中保存了公钥、所采用的加密算法等信息。核心代码如下：

1、 Android签名机制其实是对APK包完整性和发布机构唯一性的一种校验机制。

2、 Android签名机制不能阻止APK包被修改，但修改后的再签名无法与原先的签名保持一致。（拥有私钥的情况除外）。

3、 APK包加密的公钥就打包在APK包内，且不同的私钥对应不同的公钥。换句话言之，不同的私钥签名的APK公钥也必不相同。所以我们可以根据公钥的对比，来判断私钥是否一致。

APK签名比对的实现方式

    好了，通过Android签名机制的分析，我们从理论上证明了通过APK公钥的比对能判断一个APK的发布机构。并且这个发布机构是很难伪装的，我们暂时可以认为是不可伪装的。

    有了理论基础后，我们就可以开始实践了。那么如何获取到APK文件的公钥信息呢？因为Android系统安装程序肯定会获取APK信息进行比对，所以我们可以通过Android源码获得一些思路和帮助。

    OK，获取到APK签名证书之后，就剩下比对了。这个简单，功能函数如下所示:

APK签名比对的应用场景

    经过以上的论述，想必大家已经明白签名比对的原理和我的实现方式了。那么什么时候什么情况适合使用签名对比来保障Android APK的软件安全呢？

1、 程序自检测。在程序运行时，自我进行签名比对。比对样本可以存放在APK包内，也可存放于云端。缺点是程序被破解时，自检测功能同样可能遭到破坏，使其失效。

2、 可信赖的第三方检测。由可信赖的第三方程序负责APK的软件安全问题。对比样本由第三方收集，放在云端。这种方式适用于杀毒安全软件或者APP Market之类的软件下载市场。缺点是需要联网检测，在无网络情况下无法实现功能。（不可能把大量的签名数据放在移动设备本地）。

3、 系统限定安装。这就涉及到改Android系统了。限定仅能安装某些证书的APK。软件发布商需要向系统发布上申请证书。如果发现问题，能追踪到是哪个软件发布商的责任。适用于系统提供商或者终端产品生产商。缺点是过于封闭，不利于系统的开放性。

以上三种场景，虽然各有缺点，但缺点并不是不能克服的。例如，我们可以考虑程序自检测的功能用native method的方法实现等等。软件安全是一个复杂的课题，往往需要多种技术联合使用，才能更好的保障软件不被恶意破坏。

我要回帖

更多关于 更改安装包签名 的文章

 

随机推荐