為什么有些APP沒有上架App Store？iOS 打包簽名內幕-魔扣目錄

文章轉自：開源中國

IOS簽名類型有Development、AD-Hoc、In-House與App Store，而打包過程中又涉及到各種證書、Provision Profile、entitlements、CertificateSigningRequest、p12、AppID......各種概念一大堆，本文將從打包簽名的原理說起，并梳理完全簽名的整體流程，最后講解重簽名的實現以及簽名機制中有哪些需要注意防護的要點。

為了保證App的分發平臺是可控的，以及保證所有安裝到iOS設備上的App都是經過蘋果官方允許的，蘋果建立了iOS簽名打包機制。要了解iOS簽名機制的實現，我們首先從簽名機制的原理說起。

1. 簽名原理

1.1 不對稱加密

網絡數據的傳輸可以使用對稱加密以及不對稱加密的方式進行安全防護，對稱加密是指數據發送者（A）和接收者（B）雙方進行加解密的密鑰是一致的，但這樣會增加密鑰自身分發的不安全性：比如要如何保證密鑰在傳遞過程中不被泄露。

而不對稱加密則由A、B持有一對公私鑰進行加解密，公私鑰鑰匙是成對出現的。對于一個私鑰，有且只有一個與其對應的公鑰，私鑰保密、公鑰公開，但是不能通過公鑰推導出私鑰，使用私鑰加密的文件可用公鑰解密，反過來公鑰加密的文件也只能用私鑰進行解密。加密過程如下：

發送方（A）首先生成一對公私鑰鑰匙對，私鑰自己保管，公鑰則任意分發出去（每臺iOS設備終端其實已經包含Apple的公鑰）。
發送數據時，發送方使用私鑰對原數據加密成密文傳輸（加密打包ipa）；
接收方（B）收到密文后，使用之前已經獲取到的公鑰進行解密得到數據內容（iOS設備驗證安裝ipa）。

1.2 數據簽名

這里主要解決了兩個問題，一個是加密數據大小的問題，另一個是如何驗證公鑰的有效性。

1.2.1 信息摘要

前面已經講到，iOS打包安裝的過程中會對ipa包進行加解密驗證。然而ipa安裝包大小動輒就有十幾M，大的有好幾G，那如果對這么大的數據量進行加解密，肯定效率是非常低的。而信息摘要則是解決了加密數據過大的問題，其原理是對信息內容通過一個很難被逆向推導的公式計算得到一段哈希數值，它具有以下特點：

計算得到的哈希值大小固定，不受原本信息內容大小的影響；
不可逆，根據哈希值無法推斷得到原本信息（實際上MD5以及SHA-1算法已經被證明可以被破解）；
唯一性，原本信息內容一致，那么哈希值也一致；原數據不同，也不會存在重復的哈希結果。

使用信息摘要技術在數據加密傳輸時，發送方先對文件內容使用哈希算法進行信息摘要計算，再對摘要內容進行加密，之后將文件內容以及摘要內容（已加密）發送出去。

接收方收到數據后，先解密得到摘要內容，再依據相同的哈希算法對文件內容進行信息摘要計算，最后匹配接收到的哈希值與計算得到的哈希值是否一致，如果一致那就說明傳輸過程是安全的。

這樣也就避免了對整體原數據加解密的計算過程，從而提高了驗證效率。

1.2.2 簽名證書

不對稱加密中的公鑰是公開的，誰都可以得到，這樣也就存在了不安全性。比如主動攻擊者C冒充數據發送者A，將自己偽裝后的公鑰分發給數據接收者B，從而達到監聽A、B之間通信的目的，又或者是對A、B之間的通信數據進行注入攻擊。

那為了保證獲取公鑰的安全性，這里引入CA認證（Certificate Authority）。CA是證明公鑰合法性的權威機構（Apple就屬于CA認證機構），它為每個使用公開密鑰的用戶發放一個數字證書，數字證書的作用是證明證書中列出的用戶合法擁有證書中列出的公開密鑰。用戶使用CA的公鑰對數字證書上的簽名進行驗證，如果驗證通過，也就認為證書內包含的公鑰是有效的。

CA認證確保了用戶公鑰使用過程中的安全性，iOS打包需要向蘋果開發者中心上傳.certSigningRequest文件，然后配置得到各種.cer證書，這些流程中便包括了開發者向Apple CA認證中心注冊公鑰的過程。

2. iOS簽名

2.1 概念要點

.certSigningRequest 文件。從mac的鑰匙串訪問中生成.certSigningRequest文件，這個過程會從Mac終端生成一對鑰匙對，私鑰存儲在Mac中，公鑰則包含在.certSigningRequest中。再將.certSigningRequest文件上傳到Apple后臺即蘋果開發者中心，則可以對應生成開發證書或者發布證書（.cer文件）。
.cer 文件：Apple后臺使用Apple私鑰對Mac公鑰進行簽名后生成的證書。
.p12 文件：Mac本地生成的鑰匙對私鑰。由于私鑰是本地私有的，但你可以使用.p12將私鑰導出給其他團隊成員使用。
Identifiers。Identifiers是iOS設備安裝應用時用來識別不同App的唯一標識，點擊創建App IDs，同時勾選app所包含的權限：APNs、HealthKit、iCloud等。
entitlements。App使用到的各種權限（APNs、HealthKit、iCloud等），也是需要Apple驗證通過后才能生效的，Apple將這些權限開關統一稱為Entitlements。當第一次在Xcode中勾選權限時，項目中會自動生成一個.entitlements后綴的文件，里面記錄了App所擁有的權限。
Profiles。.cer文件只是聲明了證書的類型，比如Apple Development、Apple Distribution、APNs推送等等，而至于使用什么證書打包、AppID是什么、打包的App包含了哪些功能、可以在哪些設備上安裝，則是通過Provisioning Profile 描述文件（.mobileprovision后綴）來說明的，蘋果后臺將所有這些信息組合后再使用Apple私鑰進行簽名，最后生成Provisioning Profile描述文件：

2.2 AppStore簽名

發布App至AppStore之前需要經過蘋果后臺審核，審核通過蘋果后臺會用Apple私鑰對App數據進行加密簽名生成ipa包；用戶從AppStore下載App后，使用設備內置的Apple公鑰解密驗證，驗證通過安裝成功。由于AppStore分發的過程中上傳審核、下載安裝的整個過程都處在蘋果的生態鏈內，所以只需要一次驗證就能保證安全性。

2.3 其他簽名

從AppStore下載安裝App只需要一次數字簽名就足以保證安全性，但除了這種途徑蘋果還有其他的安裝方式：

開發中連接設備到Xcode進行調試安裝
AD-Hoc內部測試安裝，需要先獲取設備UDID并注冊，并且有最多100臺設備的限制
In-House企業內部分發，安裝設備數量無限制，但安裝后需主動在設置中選擇信任證書

那這些安裝App的過程中蘋果又是怎樣保證流程安全性的呢？答案就是雙重簽名機制，蘋果使用前面講到的Mac本地鑰匙對以及Apple后臺鑰匙對進行多次數字簽名，從而保證整體流程的可控。

Mac 鑰匙串訪問在本地生成一對公私鑰鑰匙對，下面默認為公鑰L、私鑰L（L：Local）。
Apple已有一對公私鑰鑰匙對，私鑰A在Apple后臺，公鑰A內置到每一臺iOS設備終端（A：Apple）。
上傳公鑰L至Apple后臺，使用私鑰L對公鑰L進行數字簽名生成簽名證書.cer，同時使用私鑰L對額外信息（使用什么證書打包、AppID、打包的App包含了哪些功能、可以在哪些設備上安裝）進行簽名生成描述文件Provisioning Profile，之后將.cer和Provisioning Profile下載安裝到Mac機器上。
編譯打包app，選擇簽名證書.cer，打包指令會自動找到該證書對應的私鑰L（能匹配是因為鑰匙對是成對出現的，前提是本地必須已經存在L私鑰，也就是p12的安裝），然后使用私鑰L對app進行簽名。這些簽名數據包含兩部分：Mach-O可執行文件會把簽名直接寫入這個文件中，其他資源文件則會保存在_CodeSignature目錄下。你可以將打包生成的.ipa文件另存為.zip，解壓后對Payload文件夾中的.app文件右鍵、顯示包內容，就可以看到簽名數據。另外簽名過程中對于App內包含的動態庫以及插件（Plugins、Watch、Frameworks文件夾），每一個都會單獨進行一次簽名，并生成各自的Mach-O可執行文件和_CodeSignature。簽名數據指代碼內容、App包含的所有資源文件，只要其中有任何改動，都必須重新簽名才有效。
打包的過程中會將描述文件Provisioning Profile命名為embedded.mobileprovision放入到打包app中。
安裝/啟動，iOS設備使用內置的公鑰A驗證embedded.mobileprovision是否有效（設備是否在允許安裝列表內），同時再次驗證里面包含的.cer證書簽名是否有效（證書過期與否）并取出公鑰L。
embedded.mobileprovision驗證通過，就使用公鑰L解密驗證app簽名信息：AppID是否對應、權限開關是否跟app里的entitlements一致等等。
所有驗證通過，安裝/啟動完成。

以上流程便是開發調試、AD-Hoc、In-House等方式打包安裝App的過程，區別只在于第⑤步中設備IDs的匹配規則不一致。開發調試只安裝當前聯調的設備；AD-Hoc允許安裝到已在開發者賬號下注冊過的設備，且每年最多允許100臺；In-House無設備數量限制，常用于企業內部App的分發。

3. ipa包重簽名

ipa包重簽名主要針對的是非App Store的安裝包，App Store分發最終是上傳ipa文件到蘋果后臺審核，通過后使用Apple私鑰加密，然后才能發布安裝，不存在重簽入侵的可能。而開發調試、AD-Hoc、In-House等分發途徑生成的ipa包不存在蘋果后臺驗證的步驟，這也就意味著你可以對任意的.app、 .ipa文件進行重簽名。

回顧前面講到的簽名流程，真正對ipa包進行簽名的關鍵步驟（④⑤）是在Mac本地進行的，簽名過程中需要滿足三個條件：App即軟件代碼編譯生成的產物、p12證書以及Provisioning Profile配置文件。其中App的內容是動態變動的，Apple不會去驗證它，實際上也無需驗證，因為在開發調試過程中，所開發的App肯定是不停的迭代變化的，如果需要上線App Store那Apple只需在審核階段對App內容進行把關驗證即可，而其他分發渠道它則管不了。p12以及Provisioning Profile則是下載后主動安裝的，大部分情況下都是由管理員創建下載好之后，導出分發給團隊成員。

3.1 簽名指令

iOS簽名調用的是codesign指令，你也可以直接使用相關指令進行簽名，下面是codesign的常用指令：

# MAC終端輸入： codesign --help
codesign --help
Usage: codesign -s identity [-fv*] [-o flags] [-r reqs] [-i ident] path ... # sign
codesign -v [-v*] [-R=<req string>|-R <req file path>] path|[+]pid ... # verify
codesign -d [options] path ... # display contents
codesign -h pid ... # display hosting paths

查看Xcode的編譯日志，也可以看到簽名的詳細信息

# 簽名指令
codesign -f -s "iphone Distribution: XXX（證書名稱）" --entitlements entitlements.plist（Profile配置文件） XXX.app（簽名app）

3.2 重簽名

首先獲取需要重簽名的ipa包，注意該ipa包必須是未加密的。如果是從App Store下載的ipa，需要砸殼解密后才能進行重簽名，你也可以從越獄平臺下載。將獲取的.ipa重命名為.zip，然后右鍵解壓，將會生成一個 Payload 文件夾，里面包含.app文件。
將簽名證書對應的Provisioning Profile文件重命名為 embedded.mobileprovision，并拷貝放到Payload文件夾中。同時右鍵.app文件，顯示包內容，將前面的embedded.mobileprovision文件再拷貝一份放到.app文件夾中，替換掉原有的embedded.mobileprovision。
entitlements.plist是由簽名證書對應的Profile配置導出的簽名文件，它與前面截圖Xcode簽名日志中的XXX.xcent文件的作用相同。終端cd到Payload文件夾路徑，執行指令# cd xxx/Payload，然后執行下面指令 security cms -D -i embedded.mobileprovision將會打印出Profile配置的內容，找到<key>Entitlements</key>，然后把<key>Entitlements</key>下面<dict>...</dict>的內容拷貝到新建的entitlements.plist文件中（可以通過Xcode生成plist文件，選Property List類型），最后將entitlements.plist文件放到Payload文件夾中。# 拷貝內容為：<dict> ... </dict> <key>Entitlements</key> <dict> <key>application-identifier</key> <string>xxx</string> <key>keychain-access-groups</key> <array> <string>xxx</string> </array> <key>get-task-allow</key> <false/> <key>com.apple.developer.team-identifier</key> <string>xxx</string> </dict>
簽名證書名稱可以在安裝證書后從鑰匙串中心查看或者在終端使用以下指令查看：security find-identity -v -p codesigning
準備工作完成，開始重簽名。先右鍵.app顯示包內容，查看動態庫和插件（Plugins、Watch、Frameworks文件夾），如果是個人證書需要移除Plugins、Watch文件夾，因為個人證書沒法簽名Extention。如果存在Frameworks，則執行簽名指令，有多個的話則每一個Frameworks都要重簽一次。
codesign -fs "簽名證書名稱" "Frameworks/xxx.framework（動態庫路徑）"
最后對app進行重簽名
codesign -f -s "iPhone Distribution: XXX（證書名稱）" --entitlements entitlements.plist（Profile配置文件） XXX.app（簽名app）
最后將Payload文件夾下的資源移除，只保留.app文件，右鍵壓縮，然后更改后綴為.ipa，這樣重簽后的ipa便已生成了，你可以通過iTunes、iTools或其他途徑安裝到iOS設備上。

3.3 注入代碼重簽

ipa代碼注入一般通過動態庫來實現。新建動態庫在Xcode中選擇新建 TARTETS — Framework & Library — Framework，然后在framework中添加自定義代碼，一般都是使用Runtime來注入附加功能。最后選擇framework要支持的架構，編譯后便得到了最終動態庫。
對需要重簽名的.app右鍵顯示包內容，然后將動態庫拷貝到Framework文件夾（沒有則新建）中。然而此時動態庫與app還沒建立關聯關系，動態庫需要注入MachO中才能生效。注入使用yololib工具，下載yololib并編譯，將生產的命令復制到/usr/local/bin或$PATH中的其他路徑，便可以在終端使用yololib指令## 通過yololib工具實現注入動態庫 yololib "MachO文件路徑" "需要注入的動態庫路徑"注入成功后再對所有Framework簽名，最后對app重簽名，然后生成ipa文件。這里整理了一份用于重簽名的腳本 CJCodeSign，想了解更多關于簽名指令的內容可點擊查看詳情。

3.4 關于重簽名的思考

iOS重簽名實現，可以發現用于簽名的私鑰資源（包括.cer證書和Provisioning Profile配置）和實際簽名的app包是沒有強關聯關系的，這也就帶來了兩方面的問題。

.cer證書和Provisioning Profile配置被用于其他App的分發簽名，特別如果是In-House企業類型的證書，那是可以進行無限制分發的，而一旦蘋果檢測到這種違規簽名的行為，輕則撤銷證書，重則注銷企業開發者賬號！這也就是為什么一定要嚴格把控 p12、Provisioning Profile 文件外發的原因。
自有App被注入代碼后重簽名，比如應用多開、添加插件、惡意抓包等等，對于這一類的防護除了對Bundle ID進行檢查，以及對App動態庫增加白名單檢索外好像也沒有更好的辦法。當然這已經涉及到逆向防護的方向了，本人對此還未深入了解，有興趣的同學可以一起參與探討。

全文完！

最后再附上重簽名腳本地址： CJCodeSign