安全、逆向

Question

安全、逆向

ShannonChenCHN opened this issue 7 years ago · comments

ShannonChen commented 7 years ago

沙盒
加固
网络安全
- HTTPS
- DNS 拦截
- 接口加密
Code Signing
逆向工程
class dump
IDA Pro
Hopper
iOS Class Guard
加密算法
代码签名（Code Signing）
Advanced Apple Debugging & Reverse Engineering 学习笔记
爬虫与反爬虫

ShannonChen · Answer 1 · Tue May 23 2017 14:36:04 GMT+0800 (China Standard Time)

延伸阅读：

《Advanced Apple Debugging & Reverse Engineering》（推荐阅读）
《iOS 应用逆向工程：分析与实战》（作者：沙梓社 / 吴航 / 刘瑾）
《iOS 应用逆向与安全》（作者：刘培庆）
《iOS Hacker's Handbook》
《Hacking and Securing iOS Applications》
iOS应用逆向工程资料- everettjf
iOS 如何进行逆向工程？
iOS App 的逆向工程: Hacking on Lyft - Realm Academy
Reverse-Engineering the iPhone X Home Indicator Color
《iOS 应用逆向与安全》读后感
TikTok(抖音国际版)逆向，全球的小姐姐们，我来啦！
iWeChat - 通过逆向还原和探索微信
iOS逆向系列文章 - 一缕清风扬万里：关于重签名和代码注入的部分推荐阅读一下，逆向微信那一篇中注入 framework 部分不太好理解，可以跟非越狱下 iOS代码注入&HOOK微信登录结合起来看。
iOS逆向系列文章 - handclaper：关于砸壳部分的文章写的很赞
非越狱环境下的iOS逆向工程：IPAPatch + Reveal：研究第三方 app 的一个例子
无须越狱、自动集成、只需要一个砸壳的应用---MonkeyDev：MonkeyDev 作者刘培庆自己对 MonkeyDev 的介绍
开源项目
- yulingtianxia/FishChat
- Naituw/IPAPatch
- nst/RuntimeBrowser
- kevll/WeChatRedEnvelopesHelper：iOS版微信抢红包插件,支持后台抢红包
- Urinx/iOSAppHook：专注于非越狱环境下iOS应用逆向研究，从dylib注入，应用重签名到App Hook

ShannonChen · Answer 2 · Fri Jul 21 2017 22:34:23 GMT+0800 (China Standard Time)

如何查看 App Store 中下载的 APP 中的图片资源？

下载 cartool 源码；
打开 project，Command+B 编译一下；
找到工程目录 products 下的 cartool 文件，右击，show in finder；

打开终端，输入：

$ cd <cartool文件所在目录>

$ ./cartool  /xxx/Assets.car /xxx/outputDirectory

参考资料：

iOS学习之解压Assets.car

ShannonChen · Answer 3 · Tue Oct 10 2017 17:27:24 GMT+0800 (China Standard Time)

class dump

下载 class-dump
获取 /usr/bin 目录的访问权限：重启电脑按住 cmd+R，打开终端，输入 csrutil disable。
拷贝 class-dump 可执行文件到 /usr/bin 目录下
给 class-dump 操作权限：执行 sudo chmod 777 /usr/bin/class-dump 命令
获取头文件信息：先获取 ipa 包中的可执行文件，然后执行终端命令 class-dump -H 要破解的可执行文件路径 -o 破解后的头文件存放路径

参考资料：

ShannonChen · Answer 4 · Tue Oct 10 2017 18:02:26 GMT+0800 (China Standard Time)

代码混淆

基本原理：通过宏定义将函数名、方法名、类名、属性名等代码内容替换成无法被识别的加密字符串
要点：
- 如何配置宏定义，一个一个手写吗？
  - 把要替换的内容写到一个文件里面，然后通过脚本读取该文件内容，再生成相应的宏定义文件，并在 pch 文件中导入该文件
- 什么时候替换？怎么替换？
  - build phrase
注意点：
- 不要把系统的方法名和类名给替换掉了，最好给自定义的方法名加前缀
- XIB中拖线的控件名

示例脚本：

#!/usr/bin/env bash

TABLENAME=symbols
SYMBOL_DB_FILE="symbols"
STRING_SYMBOL_FILE="func.list"
HEAD_FILE="$PROJECT_DIR/$PROJECT_NAME/codeObfuscation.h"
export LC_CTYPE=C

#维护数据库方便日后作排重
createTable()
{
echo "create table $TABLENAME(src text, des text);" | sqlite3 $SYMBOL_DB_FILE
}

insertValue()
{
echo "insert into $TABLENAME values('$1' ,'$2');" | sqlite3 $SYMBOL_DB_FILE
}

query()
{
echo "select * from $TABLENAME where src='$1';" | sqlite3 $SYMBOL_DB_FILE
}

ramdomString()
{
openssl rand -base64 64 | tr -cd 'a-zA-Z' |head -c 16
}

rm -f $SYMBOL_DB_FILE
rm -f $HEAD_FILE
createTable

touch $HEAD_FILE
echo '#ifndef Demo_codeObfuscation_h
#define Demo_codeObfuscation_h' >> $HEAD_FILE
echo "//confuse string at `date`" >> $HEAD_FILE
cat "$STRING_SYMBOL_FILE" | while read -ra line; do
if [[ ! -z "$line" ]]; then
ramdom=`ramdomString`
echo $line $ramdom
insertValue $line $ramdom
echo "#define $line $ramdom" >> $HEAD_FILE
echo "#define _$line _$ramdom" >> $HEAD_FILE
fi
done
echo "#endif" >> $HEAD_FILE


sqlite3 $SYMBOL_DB_FILE .dump

参考资料

iOS安全攻防（二十三）：Objective-C代码混淆 - 念茜
iOS 对源代码进行混淆
iOS代码加密的几种方式
iOS代码混淆----自动：自动查找自定义的方法名来进行替换，而无需手动配置 func.list 文件
iOS应用安全之代码混淆实现篇：对文件名、类名、协议名、属性名、函数名进行混淆，但不是用宏定义的方式，而是直接替换
对 iOS app 进行安全加固
kaich/codeobscure：方便强大的OC工程代码自动混淆工具

ShannonChen · Answer 5 · Thu Oct 19 2017 21:38:00 GMT+0800 (China Standard Time)

接口加密

对称加密
1. 生成密钥（这个 key 只有发送方和接收方知道）
2. 加密：调用时，发送方，组合各个参数用密钥 key按照一定的规则(各种排序，MD5，ip等)生成一个access_key，一起提交到API接口
3. 校验：接收方拿到post过来的参数以及这个access_key。也和发送一样，用密钥key 对各个参数进行一样的规则(各种排序，MD5，ip等)也生成一个access_key2
4. 对比access_key 和access_key2 。一样。则允许操作，不一样，报错返回或者加入黑名单
非对称加密：私钥负责签名，公钥负责验证

参考

ShannonChen · Answer 6 · Fri Mar 02 2018 11:57:36 GMT+0800 (China Standard Time)

《代码签名探析》学习笔记

只有在越狱之后，iOS 才能运行没有签名的代码。
越狱使应用可以绕过代码签名和沙盒安全机制的全部限制，这会是一个非常危险的行为。

一、证书和密匙

作为一个 iOS 开发者，在你开发使用的机器上应该已经有一个证书，一个公钥，以及一个私钥。这些是代码签名机制的核心。

有两种方式可以查看你的系统中能用来对代码进行签名的证书：

打开 KeyChain （钥匙串访问）-> “我的证书”
命令行工具 security：security find-identity -v -p codesigning

$ csapp security find-identity -v -p codesigning
  1) A853191D0F53EBEEAADD9EE99932CA596F5A1F9F "Mac Developer: 273879688@qq.com (C6KU79QV5A)"
  2) 8120BD6A4536DCF46DBBF7D88EFF9EAB241F1870 "iPhone Developer: 273879688@qq.com (C6KU79QV5A)"
     2 valid identities found

一个证书是一个公钥加上许多附加信息，这些附加信息都是被某个认证机构（Certificate Authority 简称 CA）进行签名认证过的，认证这个证书中的信息是准确无误的。

命令行工具 CodeSign

签名过程本身是由命令行工具 codesign 来完成的。如果你在 Xcode 中编译一个应用，这个应用构建完成之后会自动调用 codesign 命令进行签名。

二、一个已签名应用的组成

可执行文件

一个已签名的可执行文件的签名包含在 Mach-O 二进制文件格式中。

在 macOS 和 iOS 上的任何可执行二进制文件都可以被设置签名：不论是动态库，命令行工具，还是 .app 后缀的程序包。

设置签名的过程实际上会改动可执行文件的文件内容，将签名数据写入二进制文件中。

如果你拥有一个证书和它的私钥，那么用 codesign 来设置签名非常简单：

$ codesign -s "iPhone Developer: 273879688@qq.com (C6KU79QV5A)" ~/Desktop/AwesomeProject.app
/Users/ShannonChen/Desktop/AwesomeProject.app: is already signed

为一个已经签过名的文件重新签名：

$ codesign -f -s "iPhone Developer: 273879688@qq.com (C6KU79QV5A)" ~/Desktop/AwesomeProject.app
/Users/ShannonChen/Desktop/AwesomeProject.app: replacing existing signature

查看文件签名状态的信息：

$ codesign -vv -d ~/Desktop/AwesomeProject.app

得到的结果：

Executable=/Users/ShannonChen/Desktop/AwesomeProject.app/AwesomeProject
Identifier=org.reactjs.native.example.AwesomeProject
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20400 size=55629 flags=0x0(none) hashes=1731+3 location=embedded
Signature size=4799
Authority=iPhone Developer: 273879688@qq.com (C6KU79QV5A)
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=2019年2月15日 下午4:19:35
Info.plist entries=29
TeamIdentifier=L32PN8QKLZ
Sealed Resources version=2 rules=13 files=12
Internal requirements count=1 size=208

检查一下封印是否完好，没有任何输出说明签名是完好的：

$ codesign --verify ~/Desktop/AwesomeProject.app

程序包和其他资源文件

为一个程序包设置签名时，这个包中的所有资源文件也都会被设置签名，包括图片、XIB/NIB 文件、存档文件(archives)，甚至是证书文件。

为了达到为所有文件设置签名的目的，签名的过程中会在程序包中新建一个叫做 _CodeSignatue/CodeResources 的文件，这个文件实际上是一个 xml 文件，其中定义了被签名的程序包中所有文件的签名。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>files</key>
  <dict>
  ...
  </dict>
  <key>files2</key>
  <dict>
    <key>Base.lproj/LaunchScreen.nib</key>
    <dict>
      <key>hash</key>
      <data>
      hTT3EydgxVsF1sYscxcv10yz+kw=
      </data>
      <key>hash2</key>
      <data>
      u2MAOaedOTTaTtvI7WSWhH5swfkntlTSa1izuXC50Jk=
      </data>
    </dict>
    ...
  </dict>
  <key>rules</key>
  <dict>
  ...
  </dict>
  <key>rules2</key>
  <dict>
  ...
  </dict>
</dict>

三、授权机制 (Entitlements) 和配置文件 (Provisioning)

代码签名保证了这个应用里所包含的内容没有被修改过，而沙盒则是限制了应用访问系统的资源。

授权机制

授权机制决定了哪些系统资源在什么情况下允许被一个应用使用。简单的说它就是一个沙盒的配置列表，上面列出了哪些行为被允许，哪些会被拒绝。

在 Xcode 的 Capabilities 选项卡下选择一些选项之后，Xcode 会自动生成一个 .entitlements 文件，然后在需要的时候往里面添加条目。当构建整个应用时，这个文件也会提交给 codesign 作为应用所需要拥有哪些授权的参考。这些授权信息必须都在开发者中心的 App ID 中启用，并且包含在配置文件中。

授权信息会被包含在应用的签名信息中，你可以尝试查看签名信息中具体包含了什么授权信息：

$ codesign -d --entitlements - AwesomeProject.app

描述文件（Provisioning Profile）

一个描述文件是一组信息的集合，这组信息决定了某一个应用是否能够在某一个特定的设备上运行。

一个证书可以对应多个不同的描述文件。

如果你要在自己的机器上找到描述文件，在这个目录下 ~/Library/MobileDevice/Provisioning Profiles，Xcode 将从开发者中心下载的全部描述文件都放在了这里。

描述文件是一个根据密码讯息语法 (Cryptographic Message Syntax) 加密的文件，在 Mac 上不能直接打开查看，不过我们可以用 security 工具查看描述文件中的信息：

$ security cms -D -i ~/Library/MobileDevice/Provisioning\ Profiles/c1f2bcb3-6e73-4db8-abc7-260eef7f904c.mobileprovision

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>AppIDName</key>
  <string>onlyu</string>
  <key>ApplicationIdentifierPrefix</key>
  <array>
  <string>38K2TJBGY2</string>
  </array>
  <key>CreationDate</key>
  <date>2016-11-24T04:34:48Z</date>
  <key>Platform</key>
  <array>
    <string>iOS</string>
  </array>
  <key>DeveloperCertificates</key>
  <array>
    <data>MIIFjDCCBHSgAwIBAgIIedRPpOc4HBIwDQYJKoZIhvcNAQEFBQAwgZYxCzAJBgNVBAYTAlVTMRMwEQYDVQQKDApBcHBsZSBJbmMuMSwwKgYDVQQLDCNBcHBsZSBXb3JsZHdpZGUgRGV2ZWxvcGVyIFJlbGF0aW9uczFEMEIGA1UEAww7QXBwbGUgV29ybGR3aWRlIERldmVsb3BlciBSZWxhdGlvbnMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTYxMTI0MDQyMTQ4WhcNMTkxMTI0MDQyMTQ4WjCBjTEaMBgGCgmSJomT8ixkAQEMCjM4SzJUSkJHWTIxMDAuBgNVBAMMJ2lQaG9uZSBEaXN0cmlidXRpb246IFlIT1VTRSBDb3Jwb3JhdGlvbjETMBEGA1UECwwKMzhLMlRKQkdZMjEbMBkGA1UECgwSWUhPVVNFIENvcnBvcmF0aW9uMQswCQYDVQQGEwJVUzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmEtQvnT7HgEPrNctaIZkE5UVpHby+BwkcdcYUJpOEa4hgYjEKGQEm6kCCjaITygndAMLl9aa+uj7YXRZoTkIZI1GihaqfWfw0lpMrAWnRc2R6BEEQTpnu0+iEvIoqyXG49WW6jSpFok2Lk3kCFOCvKRauvm7QyvIM13t++wcujtATn4pVUGJ7sIIFDM3QPTwLrwA89n6EQb/14KWdk0I0U72gKeNXGYj2TNiT+qOpD94GCTyPSRCgN8xUL8FZQZQ/8cw9ZAwrHhO8h7tSpjEQr1VhdYrIYu4cBwpekANzDjZ+jDwld+WIra8wiETfoFvGgktQIkqx7glNeilITUCUCAwEAAaOCAeMwggHfMD8GCCsGAQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL29jc3AuYXBwbGUuY29tL29jc3AwMi13d2RyMDEwHQYDVR0OBBYEFL7srqri6AwTjTOt0lKhQFNFKWYxMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiCcXCam2GGCL7Ou69kdZxVJUo7cwggEPBgNVHSAEggEGMIIBAjCB/wYJKoZIhvdjZAUBMIHxMIHDBggrBgEFBQcCAjCBtgyBs1JlbGlhbmNlIG9uIHRoaXMgY2VydGlmaWNhdGUgYnkgYW55IHBhcnR5IGFzc3VtZXMgYWNjZXB0YW5jZSBvZiB0aGUgdGhlbiBhcHBsaWNhYmxlIHN0YW5kYXJkIHRlcm1zIGFuZCBjb25kaXRpb25zIG9mIHVzZSwgY2VydGlmaWNhdGUgcG9saWN5IGFuZCBjZXJ0aWZpY2F0aW9uIHByYWN0aWNlIHN0YXRlbWVudHMuMCkGCCsGAQUFBwIBFh1odHRwOi8vd3d3LmFwcGxlLmNvbS9hcHBsZWNhLzAOBgNVHQ8BAf8EBAMCB4AwFgYDVR0lAQH/BAwwCgYIKwYBBQUHAwMwEwYKKoZIhvdjZAYBBAEB/wQCBQAwDQYJKoZIhvcNAQEFBQADggEBACCsQ85W+jGC9Cl7LuNq3aW00UVJJcjIWEF0cXborTL9nP6oDlKv4cmSSrEVwSYm94pDoslFpPErwwGySvILxJ7yo7D3YA3myN06w67iFSioZlh28xMcCTdB3UnMKr2A8hw0mwMRY91PzhU6zKGgCCQ3IhzTtxZAZMVXGyjHFQMcQMR6tOGSHzdBNfaJ/aKfZ2OKuQk4IJlF01JF42mmNHMC/G6bfZzWVFPzDZ4O7Mq6jKzb9tb6yLEnIZwugqLfGt9fKWX9fq380IdgrNEuQf4iBb07kgBoADQjYNDXkzOVV3/ml/TuD68xetE7UG5zfNtd490G9WMgI6Mk7ffWhs8=</data>
  </array>
  <key>Entitlements</key>
  <dict>
    <key>keychain-access-groups</key>
    <array>
      <string>38K2TJBGY2.*</string>
    </array>
    <key>get-task-allow</key>
    <false/>
    <key>application-identifier</key>
    <string>38K2TJBGY2.com.yhouse.onlyu</string>
    <key>com.apple.developer.team-identifier</key>
    <string>38K2TJBGY2</string>
    <key>aps-environment</key>
    <string>production</string>
  </dict>
  <key>ExpirationDate</key>
  <date>2017-11-24T04:34:48Z</date>
  <key>Name</key>
  <string>onlyu_inHouse_distribution</string>
  <key>ProvisionsAllDevices</key>
  <true/>
  <key>TeamIdentifier</key>
  <array>
    <string>38K2TJBGY2</string>
  </array>
  <key>TeamName</key>
  <string>YHOUSE Corporation</string>
  <key>TimeToLive</key>
  <integer>365</integer>
  <key>UUID</key>
  <string>c1f2bcb3-6e73-4db8-abc7-260eef7f904c</string>
  <key>Version</key>
  <integer>1</integer>
</dict>
</plist>%

DeveloperCertificates：这一项是一个列表，包含了可以为使用这个配置文件的应用签名的所有证书。如果你用了一个不在这个列表中的证书进行签名，无论这个证书是否有效，这个应用都无法运行
Entitlements：包含了你的应用的所有授权信息，键值就和之前在授权那一节看到的一模一样。
ProvisionedDevices：所有可以用于测试的设备列表

参考

ShannonChen · Answer 7 · Tue Feb 19 2019 14:12:14 GMT+0800 (China Standard Time)

iOS Code Signing Tutorials（Part 1 Getting Started）学习笔记

1. Code Signing

跟我们平时签合同一样，代码签名主要保证两点：

权威性，表示这是“我”写的
完整性，表示“我”写的内容没有被修改过或者被破坏过

2. iOS Code Signing

苹果通过很强的代码签名机制，保证我们的（未越狱的）iPhone 只能运行来自 App Store 下载的应用
平时日常开发过程中，Xcode 会在 build 的最后环节帮我们做代码签名，最近的版本中还引入了自动签名的特性

3. 为什么需要学习 iOS Code Signing 相关的知识

持续集成的自动化过程不能再依赖 Xcode 了，我们需要人为干涉 build 过程
当使用第三方构建工具（比如 Fastlane）时，出现了错误，只能傻等维护者更新，不知道怎么自己去解决
开发过程中花了大量时间去解决代码签名错误、certificates 问题和 provisioning profiles 问题
了解底层原理，能够解决一些更深层次的问题，带来技术上的成长，而不仅仅是做一名 iOS 工程师

4. 准备条件

macOS
Apple Developer Membership
Xcode 9+

5. 代码签名的好处和局限

好处：

保证合法开发者开发应用程序后，该程序代码具备其作者的身份标识
保证代码在签名后没有被修改或破坏掉，确保这份代码是原始状态的
用户可以下载来自他们信任的开发者的程序，而不用担心安全问题

局限：

代码签名保证了用户使用的代码是加入了苹果开发者计划的开发者编写的，但是并不能保证代码本身是不易受攻击的
代码签名不能保证程序在运行时动态加载的 app 插件是安全的
签过名的代码没有数字版权管理和盗版保护

参考

iOS Code Signing: 1. Getting Started

ShannonChen · Answer 8 · Tue Feb 19 2019 17:40:10 GMT+0800 (China Standard Time)

iOS Code Signing Tutorials（Part 2 Certificate Signing Requests）学习笔记

创建 iOS 开发/发布证书的第一步就是 Certificate Signing Requests。

1. 什么是 CSR

CSR 请求指的是申请者为了申请一个数字身份证书（digital identity certificate）而向权威认证机构发送一条信息。

创建 CSR 请求的过程是 PKI（Public Key Infrastructure）中的一个标准，在这个过程中，申请者要在本地的机器上生成一对公钥和私钥。申请者会将公钥、邮箱地址、国家等信息附加到 CSR 中，私钥会由申请者自己保留起来。

创建一个 CSR 请求通常需要以下这些信息：

CN (Common Name)
Organisation
Organisation Unit
Country
email address

2. 向苹果发送 CSR 请求

向苹果发送 CSR 请求时，苹果会验证请求信息，如果验证通过，就会分发证书。

CSR 请求的发起必须是在 macOS 机器上，发送 CSR 请求有两种方式：

GUI，也就是 KeyChain Access（钥匙串访问）
命令行，借助 OpenSSL

在我们创建 CSR 文件时，发生了这几件事：

自动生成了一对公钥和私钥
公钥被附加到 CSR 文件上了
私钥被自动保存到本地的 KeyChain 中了，可以在 KeyChain 的“密钥”中查看

参考

ShannonChen · Answer 9 · Wed Feb 20 2019 14:34:42 GMT+0800 (China Standard Time)

iOS Code Signing Tutorials（Part 3 Certificates）学习笔记

1. 创建证书

根据官方文档，苹果总共有 10 种不同类型的证书。

创建证书的步骤：

创建 CSR 文件（也就是我们在上一节中所做的事）
Apple Developer Center -> Certificates, Identifiers & Profiles -> Certificates section
上传刚才创建的 CSR 文件
Apple 会帮你生成一个 .cer 证书，可以下载下来

双击下载下来的 .cer 证书，系统就会自动将它添加到 KeyChain 中。Keychain 会自动把它和之前创建 CSR 时自动生成的私钥归为一组，无论是在「我的证书」中查看证书还是在「密钥」中查看私钥，都能看到与之匹配的另一半。

2. 证书中有哪些信息

Subject Name
Issuer name
Public Key Info
Fingerprints

3. PKCS#12（p12）

当我们想要在另一台机器上上进行代码签名时，据需要将公钥证书和对应的私钥导出成一个 .p12 文件。

.p12 文件是根据 PKCS#12 标准生成的，PKCS#12 是一种公钥密码学标准（Public Key Cryptography Standard，PKCS）。这个标准用来将私钥和公钥证书保存成一个文件，并用密码保护起来。

.p12 文件中包含我们的公钥证书和对应的私钥，我们可以用下面的命令查看 .p12 文件中的信息：

$ openssl pkcs12 -info -in mycert.p12

参考

ShannonChen · Answer 10 · Wed Feb 20 2019 17:26:34 GMT+0800 (China Standard Time)

iOS Code Signing Tutorials（Part 4 Provisioning Profiles）学习笔记

1. 几个概念

Team ID：苹果会自动为每一个开发团队/个人分配一个唯一的 team id
Bundle Identifier：每个 app 都会有一个唯一的 Bundle ID，这个 bundle id 需要开发者自己定义
App ID：App ID 一般由两部分组成，Team ID 和 Bundle Identifier。另外，App ID 有两种类型，explicit App ID 和 wildcard App IDs
Device ID：每一台 iOS 设备都有一个唯一设备 id，这个 Device id 有个专门的名字叫做 UDID。
Entitlements：由于 iOS 的沙盒机制的限制，所有的 app 都被限制访问系统层面的资源和数据，比如 Apple Pay、HealthKit、iCloud 等等。对此，苹果提供了 entitlements 的机制来让开发者选择开启哪些权限，在 Xcode 的
Capabilities tab 中可以看到可供开启的权限选项，默认都是关闭的。

Provisioning Profile 实际上是证书、app ID、device ID 和 entitlements 的组合。

2. 创建 Provisioning Profiles

注：从 Xcode 8 开始，苹果推出了 automatic code signing 机制，可以自动创建和管理 Provisioning Profiles。

手动创建 Provisioning Profile 的步骤：

Select Type（iOS or tvOS）
Configure
- Select App ID
- Select Certificates
- Select devices
Generate
Download

双击下载好的 Provisioning Profile 后，系统会自动将其添加到 ~/Library/MobileDevice/Provisioning\ Profiles 目录下。

3. Provisioning Profiles 中有什么内容

见 iOS 代码签名概览

4. Xcode and Provisioning Profile

在 Xcode 的 General tab 中可以选择是否开启 Automatically manage sigining，在未开启 Automatically manage sigining 的模式下，可以在 Build Settings tab 中手动指定 Provisioning Profile。

参考

ShannonChen · Answer 11 · Thu Feb 21 2019 16:06:26 GMT+0800 (China Standard Time)

iOS Code Signing Tutorials（Part 5 Signing iOS App）学习笔记

1. Code Signing

Xcode 的自动签名只适合在本地机器上使用，如果需要在 CI 服务器上签名就需要自己去执行脚本调用相关工具进行手动签名了。

苹果提供了一个叫做 codesign 的命令行工具来进行手动签名，Xcode 的自动签名机制其实本质上也是在调用这个命令行工具。

2. Code Signing Stages

对 iOS App 签名时，会经历这三个步骤：

Seal
Digital Signature
Code Requirement

2.1 Seal

类比信封的密封处理
seal 是代码签名软件根据源代码生成的校验和和 hash 值
对应用程序包中的代码、资源进行 hash 处理，验证方会用同样的算法去验证，以检测程序代码、资源是否被修改过。

2.2 Digital Signature

代码签名软件用签名者的身份信息生成数字签名来对 seal 进行编码，以保证密封的完整性。

2.3 Code Requirement

Code Requirement 是验证代码签名时的规则。

3. Automatic Code Signing VS. Manual Code Signing

4. Re-Signing iOS Apps

准备条件：

证书
Provisioning profile

重签名步骤：

解压 .ipa
删除 _CodeSignature 目录
替换 provisioning profile
使用 codesign 基于旧的 entitlements 文件重新生成一个 entitlements 文件
使用新的证书和 entitlements 文件重新签名代码
压缩重新签名后的 ipa

参考

ShannonChen · Answer 12 · Thu Feb 21 2019 18:07:03 GMT+0800 (China Standard Time)

iOS 代码签名的原理总结

1. 为什么要代码签名

2. 什么是代码签名

非对称加密
哈希算法
数字签名

（图片来源：http://xelz.info/blog/2019/01/11/ios-code-signature/）

3. 安装 iOS App 的几种方式

从 App Store 下载
In-House 企业内部分发
本地调试时直接在真机上运行

4. 几个概念

CSR
证书和证书链
公钥和私钥
p12
Provisioning Profile
Entitlements

5. 代码签名的流程（以在真机上直接运行 app 为例）

（图片来源：http://blog.cnbang.net/tech/3386/）

6. 几个问题

上面提到的打包证书、Provisioning Profile 以及其他那几个概念分别起到什么作用
Entitlements 到底是用来干嘛的？用来控制访问权限？怎么控制？

参考

代码签名探析 - obj.io
iOS App 签名的原理 - bang【推荐阅读】
深度长文：细说iOS代码签名【推荐阅读】
iOS Code Signing（part 1）、（part 2）、（part 3）、（part 4）、（part 5）

ShannonChen · Answer 13 · Fri Feb 22 2019 09:59:53 GMT+0800 (China Standard Time)

HTTPS、TLS 和 SSL

TLS/SSL 握手过程（单向认证）

完整的 HTTPS 连接的建立过程