iOS 包签名及重签名

签名相关的命令：

十余年的桑日网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。成都全网营销的优势是能够根据用户设备显示端的尺寸不同，自动调整桑日建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。创新互联公司从事“桑日网站设计”,“桑日网站推广”以来，每个客户项目都认真落实执行。

•$security find-identity -v -p codesigning -- 列出钥匙串里可签名的证书

•$security cms -D -i embedded.mobileprovision -- 查看描述文件

•$codesign–fs “证书串” 文件名 -- 强制替换签名

重签步骤:

1.删除插件和带有插件的.app包（比如Watch）

2.对Frameworks里面的库进行重签名

3.给可执行文件 +x（可执行）权限

4.替换描述文件

5.替换BundleID

6.通过授权文件（Entilements）重签.app包

实际操作：

获取破壳的ipa包

获取第三方ipa包

查看ipa包是否已经破壳 》 非上架的都没加壳，无需关注

解压ipa包，进入playload文件夹，找到MachO文件

在终端使用命令otool -l DingTalk | grep crypt，0是已脱壳，大于0是未脱壳（一

般为1）

终端查看本地有效证书

$security find-identity -v -p codesigning

删除无法签名的插件文件

删除Plugins文件夹和Watch文件夹

对.app文件夹内的Frameworks文件夹中的每一个framework强制重签名

命令：$ codesign -fs "iPhone Developer: xxx " xxx.framework

找到framework文件夹下所有.framework，分别使用上面的命令对其签名。

建议通过脚本命令执行：

将要签名的描述文件该成 embedded.mobileprovision 替换 来的 embedded.mobileprovision

创建entitlements.plist文件

查看描述文件内容，使用命令security cms -D -I embedded.mobileprovision，找到Entitlements节点，接着创建entitlements.plist文件，内容拷贝过去，最后把entitlements.plist文件拷贝到playload文件夹内（与xx.app同级）。

!]( )

修改xx.app包里面的info.plist中的bundleId为上面项目的bundleId

对xx.app开始签名

使用的命令： zip –ry 输出文件 输入文件 命令。也可以手动压缩。

将上述操作 通过shell命令 写个脚本文件。然后一键操作。

shell脚本语言命令

地址：

蒲公英平台重签名

本文章主要介绍iOS 版本发布的两个相关功能。

一 : iOS 开发出的版本发布安装 用两种方式 ：

软件环境

Mac: v10.12.6 (16G29)

ruby: v2.3.4

rvm: v1.29.3

sigh: v2.71.1

Xcode: v9.2

使用sigh脚本

使用之前先安装一下脚本环境

应用场景：

主要解决因重复打包导致测试同学回归测试的包和上传App Store的包不一致的问题。以及 合作方之间 证书不一致，需要重新签名问题。

App开发测试流程

对回归测试通过的ipa包进行重新签名，然后上传 App Store

输入的 Signing Identity 如果和 .mobileprovision文件 不一致，那么终端上仍会提示resign成功，但是，安装时会报错！

codesign -vv -d xxx.app

本文主要讲述sigh命令的安装和使用。

首先确保你安装了Xcode的命令行工具。

然后通过gem安装sigh，gem的安装请自行谷歌。

在终端执行

依次执行下列步骤：

关于更多sigh用法请访问 sigh使用

签名成功的应用就可以顺利在我们的设备中安装了并使用了，用这个方法可以进行非越狱平台安装在正版基础移植的越狱应用。

工具：

借鉴：

iOS APP签名机制详解

iOS 签名机制流程

保证安装到用户手机上的APP都是经过 Apple官方允许的。

Mac设备有自己的公钥和私钥，Apple后台充当CA机构，有自己的Apple私钥，每一个iOS设备都有对应的App公钥。

1.编译项目，利用Mac的私钥进行签名，生成一个ipa包。

2.利用钥匙串-证书助理-请求证书，生成Mac的公钥，也就是Certificatesigningrequest.certsigningrequest文件，在苹果官网，选择创建相应的证书，将Mac的公钥上传，苹果后台会用私钥进行签名，生成证书，也就是ios_XXXX.cer文件。

3.将证书和app id，设备信息，权限等，用苹果私钥再次签名，生成配置文件，也就是XXX.moblleprovision文件。

4.在安装到手机的过程中，手机上的苹果公钥对XXX.mobileprovision进行验证签名。

5.XXX.mobileprovision验证通过后会继续对证书进行验证签名，获取到Mac的公钥。

6.利用Mac的公钥，验证ipa安装包的签名。

7.以上流程走完，就可以确定安装到用户手机上的APP都是经过 Apple官方允许的。

1.签名都是对散列值进行加密。

2.App Store的流程更简单，苹果对项目用苹果私钥签名，手机用苹果公钥验证签名。

3.本文如有侵犯隐私或其他请联系我，我将在第一时间整改或删除。

iOS 应用签名证书的类型说明

iOS 应用的证书选择

对于一个未上线 App Store 的应用，一般来说，开发者如果需要将应用安装到某些用户的设备上，就需要将应用导出为这些设备可以直接安装的安装包（.ipa文件），安装包能否正确导出，是决定了应用能否被正确安装到设备上的关键因素。其中，最关键的一个因素是，导出安装包时，应用所使用的证书（即：签名方式）。

开发者可以选择如下两种方式的证书签名方式，来导出应用安装包：

其中，具体使用哪种方式，取决于开发者拥有苹果开发者账号的类型。例如，如果开发者拥有的是苹果个人开发者账号，则可以使用 Ad-hoc 方式；如果拥有的是苹果企业开发者账号，则可以使用 In-house 方式。关于苹果开发者账号支持的证书类型，请见下表：

到目前为止，苹果为 iOS 应用共提供了三种类型的证书签名方式，每一种都有独特的用途。这三种分别是：

蒲公英会根据打包证书的不同，分别显示为 内测版 、 企业版 、 App-Store版 。

关于这三种类型的证书，区别如下表所示：

iOS中的签名机制

说到签名机制，首先要了解一下 加密解密 ,签名文件就是 加密解密 的过程。

加密 是将明文信息改变为难以读取的密文内容，使之不可读的过程。

解密 是通过特殊的对象，将密文还原为正常可读的内容的过程。而在这个过程中，我们所使用的方法，就是加密解密算法。

加密分为 对称加密 与 非对称加密（公开密钥加密） 。

对称加密就是加密和解密使用的都是同一套密钥

常见的对称密码算法有：

如下图，在使用对称密码时，一定会遇到密钥配送问题， 假设，Alice将使用对称密码加密过的消息发给了Bob， 只有将密钥发送给Bob，Bob才能完成解密， 在发送密钥过程中，可能会被Eve窃取密钥，最后Eve也能完成解密。

加密和解密使用的不是同一个密钥，即为非对称加密算法，也称公开密钥加密；

公钥密码中，密钥分为加密密钥、解密密钥2种，它们并不是同一个密钥， 公钥密码也被称为非对称密码（Asymmetric Cryptography）

在公钥密码中：

加密密钥 ，一般是公开的，因此该密钥称为 公钥 （public key）

解密密钥 ，由消息接收者自己保管的，不能公开，因此也称为 私钥 （private key） 公钥和私钥是一 一对应的，是不能单独生成的，一对公钥和密钥统称为密钥对（key pair）

这样就能 解决秘钥配送的问题 了，如下图：

上图解析：

这其中如果有第三者窃听，只有第2步和第4步能够监听数据，由于Bob公钥是公开的谁都可以获取，那么第二步也不用担心被谁获取，第4步如果数据被第三者截获，那么他看到的也是加密后的数据，由于他没有Bob的私钥，那么他也无法知道消息的真实内容。而且他即使篡改密文消息也无任何意义。

虽然非对称加密解决了密钥配送问题，但是它的加解密速度较慢，下面我们总结一下对称和非对称加密的优缺点：

混合密码 系统，是将对称密码和公钥密码的优势相结合的方法:

为本次通信随机生成的临时密钥； 作为对称密码的密钥，用于加密消息，提高速度

首先，消息发送者要拥有消息接收者的公钥； 生成会话密钥，作为对称密码的密钥，加密消息； 用消息接收者的公钥，加密会话密钥； 将前2步生成的加密结果，一并发给消息接收者。

发送出去的内容包括

用会话密钥加密的消息（加密方法：对称密码）

用公钥加密的会话密钥（加密方法：公钥密码）

1 消息接收者用自己的私钥解密出会话密钥

2 再用第1步解密出来的会话密钥，解密消息

发送过程，加密过程

接收过程，解密过程

1.Bob利用自己的私钥解密会话密钥（使用的是公钥密码解密，也就是非对称密码解密）

2.Bob利用会话密钥解密发送过来的消息（使用的是对称密码解密）

上面的加密算法解决了数据传输的安全问题，那么 数据的完整性 是没法验证的，就是我这个数据有没有被改过，因为公钥大家都能获取，如果有中间人拦截了消息，并改动了内容。那么我们如何验证这个 消息有没有变动 呢?

单向散列函数 ，又称单向 Hash函数 、 杂凑函数 ，就是把任意长的输入消息串变化成 固定长的输出串 且由输出串难以得到输入串的一种函数。这个输出串称为该消息的散列值。一般用于产生消息摘要，密钥加密等

单向散列函数，可以根据根据消息内容计算出散列值 散列值的长度和消息的长度无关 ，无论消息是1bit、10M、100G，单向散列函数都会计算出 固定长度的散列值 。

单向散列函数 ，又被称为 消息摘要函数 （message digest function），哈希函数输出的散列值，也被称为消息摘要（message digest）、指纹（fingerprint）

MD4、MD5 产生128bit的散列值，MD就是Message Digest的缩写，目前已经不安全 Mac终端上默认可以使用md5命令

SHA-1 产生160bit的散列值，目前已经不安全

SHA-2 SHA-256、SHA-384、SHA-512，散列值长度分别是256bit、384bit、512bit

SHA-3 全新标准

不同的数据生成的散列值是不一样的，只要你对一个文件改动过，那么它的散列值就会发生变化，要想确定我们的数据有没有发生变化，只要对比两次散列值相不相同就可以了，我们常常做的登录功能，在保存用户密码的时候就采用单项散列函数生成的值来进行保存，防止第三方人员串改密码。

数据防篡改的技术我们知道了，在数据传输的过程中，我们对数据生成一个散列值，和发送的数据一并发给接收者，当接收者收到这个数据的时候，它拿接收到的数据重新生成散列值，然后跟接收到的散列值进行比较，就可以判断这个数据有没有被人改过。

到此我们通过混合密码技术解决的传输数据的保密性，通过单项散列函数确定数据的一致性，但是还是没有解决 中间人截获篡改 的问题，因为散列函数中间人也可以重新生成一次，接下来我们就要讲数字签名了，他可以对消息发送者的真实性进行认证。

数字签名 （又称公钥数字签名）是只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。

它是一种类似写在纸上的普通的物理签名，但是使用了公钥加密领域的技术来实现的，用于鉴别数字信息的方法。一套数字签名通常定义两种互补的运算，一个用于签名，另一个用于验证。数字签名是非对称密钥加密技术与数字摘要技术的应用。

说白了就是用用消息发送者的私钥进行签名就是数字签名

在数字签名中，任何人都可以使用公钥验证签名

在数字签名技术中，有以下2种行为:

生成签名 由消息的发送者完成，通过“签名密钥”生成

验证签名 由消息的接收者完成，通过“验证密钥”验证

数字签名由于是消息发送者的私钥进行签名，消息发送者的私钥只有他自己拥有，别人是没有的，从而我们通过私钥进行签名，别人通过消息发送者的公钥就能确定消息发送者的真实身份。

接下来我们看一下数字签名和公钥密码的对比:

上图Alice将要发送的消息用自己的私钥加密，发送给Bob,Bob用Alice的公钥解密消息，这里其实有一个不好的点，就是如果Alice如果发送的消息比较大，比如发1GB的视频文件，那这个签名过程就太慢了，本身非对称加密的速度就是比较慢的，

下面我们来看一个改进版的:

这里我们将要发送的消息先生成固定大小的散列值，然后再签名，这样签名文件就小的多了，然后我们将消息和签名一同发送该Bob,然后Bob再用公钥解密 对比等。

下面有关数字签名的一些点进行一下说明：

1 如果有人篡改了文件内容或者签名内容，会是什么结果？ 结果是：签名验证失败，证明内容会篡改

2 数字签名不能保证机密性？ 数字签名的作用不是为了保证机密性，仅仅是为了能够识别内容有没有被篡改

3 数字签名的作用

数字签名是能确定消息发送者，前提是你要确定你获取的公钥是确定是消息发送者的，如果你拿到的公钥是中间人伪造的，那么你就无法验证消息发送者的真实性了，就如下图：

[图片上传中...(image-b6d6e1-1614756605461-3)]

A问B要公钥，M从监听到了中间，B给A发的公钥被M拦截了并保存，M把他自己的公钥给了A，A以为这个公钥是B的，A用公钥加密发消息给B，M拦截然后用自己的私钥解密，修改消息内容后，然后用保存的公钥加密把消息发送给B，B解密消息。A,和B都以为是正常通信的，但消息确实不是那个消息了，那么如何确定公钥合法？也就是如何确定这个公钥就是B的呢？

接下来就是我们要讲的证书了，我们引入一个第三方权威机构来认正，说这个公钥就是B的。接下来我们来看一下。

CA是证书的签发机构，它是公钥基础设施（Public Key Infrastructure，PKI）的核心。CA是负责签发证书、认证证书、管理已颁发证书的机关。

CA 拥有一个证书（内含公钥和私钥）。网上的公众用户通过验证 CA 的签字从而信任 CA ，任何人都可以得到 CA 的证书（含公钥），用以验证它所签发的证书,密码学中的证书，全称叫公钥证书（Public-key Certificate，PKC），跟驾驶证类似 里面有姓名、邮箱等个人信息，以及此人的公钥； 并由认证机构（Certificate Authority，CA）施加数字签名。

图已经表示的很清楚了，消息发送者先向CA机构 注册自己的证书，那么任何拿到消息发送者的公钥都可以向CA进行验证公钥的真实性。

首先我们要知道iOS签名机制的作用是什么？

保证安装到用户手机上的APP都是经过Apple官方允许的

不管是真机调试，还是发布APP，开发者都需要经过一系列复杂的步骤：

大致如下图：

[图片上传中...(image-169a4f-1614756605461-0)]

总结：

1、.cerSigningRequest文件 ： Mac公钥

2、.cer文件：利用Apple私钥（CA）,对Mac公钥生成了数字签名

3、.mobileprovision : 利用Apple私钥，对【.cer证书 + devices + AppID + entitlements】进行数字签名

ios开发者应用 怎么签名

苹果签名目前可以分为企业签名、超级签名、tf签名。

企业签名是使用苹果企业证书，生成描述文件对应用进行签名，用户在安装时只需要在【设置】-【描述文件】信任企业证书就可以安装了，无需上架App Store。亥著五一活动，企业签名500起。

超级签名是使用个人开发者账号，通过注册苹果设备的udid，来实现真机测试，用户安装时非常简单，无需信任证书，直接安装即可，无需上架App Store。

tf上架，在签名商口中一般会称呼为tf签名，其实它全称是testflight，是一种苹果认可的分发模式，是苹果官方的内测应用分发渠道。它是目前最稳定的签名方式，一经上架基本不会掉签，用户可以一直使用。风险极小。

当前文章：ios开发签名,ios签名源码
网站URL：http://scyanting.com/article/hojdeo.html