文章轉(zhuǎn)自：開源中國
IOS簽名類型有Development、AD-Hoc、In-House與App Store，而打包過程中又涉及到各種證書、Provision Profile、entitlements、CertificateSigningRequest、p12、AppID......各種概念一大堆，本文將從打包簽名的原理說起，并梳理完全簽名的整體流程，最后講解重簽名的實現(xiàn)以及簽名機制中有哪些需要注意防護(hù)的要點。
為了保證App的分發(fā)平臺是可控的，以及保證所有安裝到iOS設(shè)備上的App都是經(jīng)過蘋果官方允許的，蘋果建立了iOS簽名打包機制。要了解iOS簽名機制的實現(xiàn)，我們首先從簽名機制的原理說起。
1. 簽名原理
1.1 不對稱加密
網(wǎng)絡(luò)數(shù)據(jù)的傳輸可以使用對稱加密以及不對稱加密的方式進(jìn)行安全防護(hù)，對稱加密是指數(shù)據(jù)發(fā)送者（A）和接收者（B）雙方進(jìn)行加解密的密鑰是一致的，但這樣會增加密鑰自身分發(fā)的不安全性：比如要如何保證密鑰在傳遞過程中不被泄露。
而不對稱加密則由A、B持有一對公私鑰進(jìn)行加解密，公私鑰鑰匙是成對出現(xiàn)的。對于一個私鑰，有且只有一個與其對應(yīng)的公鑰，私鑰保密、公鑰公開，但是不能通過公鑰推導(dǎo)出私鑰，使用私鑰加密的文件可用公鑰解密，反過來公鑰加密的文件也只能用私鑰進(jìn)行解密。加密過程如下：
- 發(fā)送方（A）首先生成一對公私鑰鑰匙對，私鑰自己保管，公鑰則任意分發(fā)出去（每臺iOS設(shè)備終端其實已經(jīng)包含Apple的公鑰）。
- 發(fā)送數(shù)據(jù)時，發(fā)送方使用私鑰對原數(shù)據(jù)加密成密文傳輸（加密打包ipa）；
- 接收方（B）收到密文后，使用之前已經(jīng)獲取到的公鑰進(jìn)行解密得到數(shù)據(jù)內(nèi)容（iOS設(shè)備驗證安裝ipa）。
1.2 數(shù)據(jù)簽名
這里主要解決了兩個問題，一個是加密數(shù)據(jù)大小的問題，另一個是如何驗證公鑰的有效性。
1.2.1 信息摘要
前面已經(jīng)講到，iOS打包安裝的過程中會對ipa包進(jìn)行加解密驗證。然而ipa安裝包大小動輒就有十幾M，大的有好幾G，那如果對這么大的數(shù)據(jù)量進(jìn)行加解密，肯定效率是非常低的。而信息摘要則是解決了加密數(shù)據(jù)過大的問題，其原理是對信息內(nèi)容通過一個很難被逆向推導(dǎo)的公式計算得到一段哈希數(shù)值，它具有以下特點：
- 計算得到的哈希值大小固定，不受原本信息內(nèi)容大小的影響；
- 不可逆，根據(jù)哈希值無法推斷得到原本信息（實際上MD5以及SHA-1算法已經(jīng)被證明可以被破解）；
- 唯一性，原本信息內(nèi)容一致，那么哈希值也一致；原數(shù)據(jù)不同，也不會存在重復(fù)的哈希結(jié)果。
使用信息摘要技術(shù)在數(shù)據(jù)加密傳輸時，發(fā)送方先對文件內(nèi)容使用哈希算法進(jìn)行信息摘要計算，再對摘要內(nèi)容進(jìn)行加密，之后將文件內(nèi)容以及摘要內(nèi)容（已加密）發(fā)送出去。
接收方收到數(shù)據(jù)后，先解密得到摘要內(nèi)容，再依據(jù)相同的哈希算法對文件內(nèi)容進(jìn)行信息摘要計算，最后匹配接收到的哈希值與計算得到的哈希值是否一致，如果一致那就說明傳輸過程是安全的。
這樣也就避免了對整體原數(shù)據(jù)加解密的計算過程，從而提高了驗證效率。
1.2.2 簽名證書
不對稱加密中的公鑰是公開的，誰都可以得到，這樣也就存在了不安全性。比如主動攻擊者C冒充數(shù)據(jù)發(fā)送者A，將自己偽裝后的公鑰分發(fā)給數(shù)據(jù)接收者B，從而達(dá)到監(jiān)聽A、B之間通信的目的，又或者是對A、B之間的通信數(shù)據(jù)進(jìn)行注入攻擊。
那為了保證獲取公鑰的安全性，這里引入CA認(rèn)證（Certificate Authority）。CA是證明公鑰合法性的權(quán)威機構(gòu)（Apple就屬于CA認(rèn)證機構(gòu)），它為每個使用公開密鑰的用戶發(fā)放一個數(shù)字證書，數(shù)字證書的作用是證明證書中列出的用戶合法擁有證書中列出的公開密鑰。用戶使用CA的公鑰對數(shù)字證書上的簽名進(jìn)行驗證，如果驗證通過，也就認(rèn)為證書內(nèi)包含的公鑰是有效的。
CA認(rèn)證確保了用戶公鑰使用過程中的安全性，iOS打包需要向蘋果開發(fā)者中心上傳.certSigningRequest文件，然后配置得到各種.cer證書，這些流程中便包括了開發(fā)者向Apple CA認(rèn)證中心注冊公鑰的過程。
2. iOS簽名
2.1 概念要點
- .certSigningRequest 文件。從mac的鑰匙串訪問中生成.certSigningRequest文件，這個過程會從Mac終端生成一對鑰匙對，私鑰存儲在Mac中，公鑰則包含在.certSigningRequest中。再將.certSigningRequest文件上傳到Apple后臺即蘋果開發(fā)者中心，則可以對應(yīng)生成開發(fā)證書或者發(fā)布證書（.cer文件）。
- .cer 文件：Apple后臺使用Apple私鑰對Mac公鑰進(jìn)行簽名后生成的證書。
- .p12 文件：Mac本地生成的鑰匙對私鑰。由于私鑰是本地私有的，但你可以使用.p12將私鑰導(dǎo)出給其他團隊成員使用。
- Identifiers。Identifiers是iOS設(shè)備安裝應(yīng)用時用來識別不同App的唯一標(biāo)識，點擊創(chuàng)建App IDs，同時勾選app所包含的權(quán)限：APNs、HealthKit、iCloud等。
- entitlements。App使用到的各種權(quán)限（APNs、HealthKit、iCloud等），也是需要Apple驗證通過后才能生效的，Apple將這些權(quán)限開關(guān)統(tǒng)一稱為Entitlements。當(dāng)?shù)谝淮卧赬code中勾選權(quán)限時，項目中會自動生成一個.entitlements后綴的文件，里面記錄了App所擁有的權(quán)限。
- Profiles。.cer文件只是聲明了證書的類型，比如Apple Development、Apple Distribution、APNs推送等等，而至于使用什么證書打包、AppID是什么、打包的App包含了哪些功能、可以在哪些設(shè)備上安裝，則是通過Provisioning Profile 描述文件（.mobileprovision后綴）來說明的，蘋果后臺將所有這些信息組合后再使用Apple私鑰進(jìn)行簽名，最后生成Provisioning Profile描述文件：
2.2 AppStore簽名
發(fā)布App至AppStore之前需要經(jīng)過蘋果后臺審核，審核通過蘋果后臺會用Apple私鑰對App數(shù)據(jù)進(jìn)行加密簽名生成ipa包；用戶從AppStore下載App后，使用設(shè)備內(nèi)置的Apple公鑰解密驗證，驗證通過安裝成功。由于AppStore分發(fā)的過程中上傳審核、下載安裝的整個過程都處在蘋果的生態(tài)鏈內(nèi)，所以只需要一次驗證就能保證安全性。
2.3 其他簽名
從AppStore下載安裝App只需要一次數(shù)字簽名就足以保證安全性，但除了這種途徑蘋果還有其他的安裝方式：
- 開發(fā)中連接設(shè)備到Xcode進(jìn)行調(diào)試安裝
- AD-Hoc內(nèi)部測試安裝，需要先獲取設(shè)備UDID并注冊，并且有最多100臺設(shè)備的限制
- In-House企業(yè)內(nèi)部分發(fā)，安裝設(shè)備數(shù)量無限制，但安裝后需主動在設(shè)置中選擇信任證書
那這些安裝App的過程中蘋果又是怎樣保證流程安全性的呢？答案就是雙重簽名機制，蘋果使用前面講到的Mac本地鑰匙對以及Apple后臺鑰匙對進(jìn)行多次數(shù)字簽名，從而保證整體流程的可控。
- Mac 鑰匙串訪問 在本地生成一對公私鑰鑰匙對，下面默認(rèn)為公鑰L、私鑰L（L：Local）。
- Apple已有一對公私鑰鑰匙對，私鑰A在Apple后臺，公鑰A內(nèi)置到每一臺iOS設(shè)備終端（A：Apple）。
- 上傳公鑰L至Apple后臺，使用私鑰L對公鑰L進(jìn)行數(shù)字簽名生成簽名證書.cer，同時使用私鑰L對額外信息（使用什么證書打包、AppID、打包的App包含了哪些功能、可以在哪些設(shè)備上安裝）進(jìn)行簽名生成描述文件Provisioning Profile，之后將.cer和Provisioning Profile下載安裝到Mac機器上。
- 編譯打包app，選擇簽名證書.cer，打包指令會自動找到該證書對應(yīng)的私鑰L（能匹配是因為鑰匙對是成對出現(xiàn)的，前提是本地必須已經(jīng)存在L私鑰，也就是p12的安裝），然后使用私鑰L對app進(jìn)行簽名。這些簽名數(shù)據(jù)包含兩部分：Mach-O可執(zhí)行文件會把簽名直接寫入這個文件中，其他資源文件則會保存在_CodeSignature目錄下。你可以將打包生成的.ipa文件另存為.zip，解壓后對Payload文件夾中的.app文件右鍵、顯示包內(nèi)容，就可以看到簽名數(shù)據(jù)。另外簽名過程中對于App內(nèi)包含的動態(tài)庫以及插件（Plugins、Watch、Frameworks文件夾），每一個都會單獨進(jìn)行一次簽名，并生成各自的Mach-O可執(zhí)行文件和_CodeSignature。簽名數(shù)據(jù)指代碼內(nèi)容、App包含的所有資源文件，只要其中有任何改動，都必須重新簽名才有效。
- 打包的過程中會將描述文件Provisioning Profile命名為embedded.mobileprovision放入到打包app中。
- 安裝/啟動，iOS設(shè)備使用內(nèi)置的公鑰A驗證embedded.mobileprovision是否有效（設(shè)備是否在允許安裝列表內(nèi)），同時再次驗證里面包含的.cer證書簽名是否有效（證書過期與否）并取出公鑰L。
- embedded.mobileprovision驗證通過，就使用公鑰L解密驗證app簽名信息：AppID是否對應(yīng)、權(quán)限開關(guān)是否跟app里的entitlements一致等等。
- 所有驗證通過，安裝/啟動完成。
以上流程便是開發(fā)調(diào)試、AD-Hoc、In-House等方式打包安裝App的過程，區(qū)別只在于第⑤步中設(shè)備IDs的匹配規(guī)則不一致。開發(fā)調(diào)試只安裝當(dāng)前聯(lián)調(diào)的設(shè)備；AD-Hoc允許安裝到已在開發(fā)者賬號下注冊過的設(shè)備，且每年最多允許100臺；In-House無設(shè)備數(shù)量限制，常用于企業(yè)內(nèi)部App的分發(fā)。
3. ipa包重簽名
ipa包重簽名主要針對的是非App Store的安裝包，App Store分發(fā)最終是上傳ipa文件到蘋果后臺審核，通過后使用Apple私鑰加密，然后才能發(fā)布安裝，不存在重簽入侵的可能。而開發(fā)調(diào)試、AD-Hoc、In-House等分發(fā)途徑生成的ipa包不存在蘋果后臺驗證的步驟，這也就意味著你可以對任意的.app、 .ipa文件進(jìn)行重簽名。
回顧前面講到的簽名流程，真正對ipa包進(jìn)行簽名的關(guān)鍵步驟（④⑤）是在Mac本地進(jìn)行的，簽名過程中需要滿足三個條件：App即軟件代碼編譯生成的產(chǎn)物、p12證書以及Provisioning Profile配置文件。其中App的內(nèi)容是動態(tài)變動的，Apple不會去驗證它，實際上也無需驗證，因為在開發(fā)調(diào)試過程中，所開發(fā)的App肯定是不停的迭代變化的，如果需要上線App Store那Apple只需在審核階段對App內(nèi)容進(jìn)行把關(guān)驗證即可，而其他分發(fā)渠道它則管不了。p12以及Provisioning Profile則是下載后主動安裝的，大部分情況下都是由管理員創(chuàng)建下載好之后，導(dǎo)出分發(fā)給團隊成員。
3.1 簽名指令
iOS簽名調(diào)用的是codesign指令，你也可以直接使用相關(guān)指令進(jìn)行簽名，下面是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的編譯日志，也可以看到簽名的詳細(xì)信息
# 簽名指令
codesign -f -s "iphone Distribution: XXX（證書名稱）" --entitlements entitlements.plist（Profile配置文件） XXX.app（簽名app）
3.2 重簽名
- 首先獲取需要重簽名的ipa包，注意該ipa包必須是未加密的。如果是從App Store下載的ipa，需要砸殼解密后才能進(jìn)行重簽名，你也可以從越獄平臺下載。將獲取的.ipa重命名為.zip，然后右鍵解壓，將會生成一個 Payload 文件夾，里面包含.app文件。
- 將簽名證書對應(yīng)的Provisioning Profile文件重命名為 embedded.mobileprovision，并拷貝放到Payload文件夾中。同時右鍵.app文件，顯示包內(nèi)容，將前面的embedded.mobileprovision文件再拷貝一份放到.app文件夾中，替換掉原有的embedded.mobileprovision。
- entitlements.plist是由簽名證書對應(yīng)的Profile配置導(dǎo)出的簽名文件，它與前面截圖Xcode簽名日志中的XXX.xcent文件的作用相同。終端cd到Payload文件夾路徑，執(zhí)行指令# cd xxx/Payload，然后執(zhí)行下面指令 security cms -D -i embedded.mobileprovision將會打印出Profile配置的內(nèi)容，找到<key>Entitlements</key>，然后把<key>Entitlements</key>下面<dict>...</dict>的內(nèi)容拷貝到新建的entitlements.plist文件中（可以通過Xcode生成plist文件，選Property List類型），最后將entitlements.plist文件放到Payload文件夾中。# 拷貝內(nèi)容為：<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
- 準(zhǔn)備工作完成，開始重簽名。先右鍵.app顯示包內(nèi)容，查看動態(tài)庫和插件（Plugins、Watch、Frameworks文件夾），如果是個人證書需要移除Plugins、Watch文件夾，因為個人證書沒法簽名Extention。如果存在Frameworks，則執(zhí)行簽名指令，有多個的話則每一個Frameworks都要重簽一次。
- codesign -fs "簽名證書名稱" "Frameworks/xxx.framework（動態(tài)庫路徑）"
- 最后對app進(jìn)行重簽名
- codesign -f -s "iPhone Distribution: XXX（證書名稱）" --entitlements entitlements.plist（Profile配置文件） XXX.app（簽名app）
- 最后將Payload文件夾下的資源移除，只保留.app文件，右鍵壓縮，然后更改后綴為.ipa，這樣重簽后的ipa便已生成了，你可以通過iTunes、iTools或其他途徑安裝到iOS設(shè)備上。
3.3 注入代碼重簽
- ipa代碼注入一般通過動態(tài)庫來實現(xiàn)。新建動態(tài)庫在Xcode中選擇新建 TARTETS — Framework & Library — Framework，然后在framework中添加自定義代碼，一般都是使用Runtime來注入附加功能。最后選擇framework要支持的架構(gòu)，編譯后便得到了最終動態(tài)庫。
- 對需要重簽名的.app右鍵顯示包內(nèi)容，然后將動態(tài)庫拷貝到Framework文件夾（沒有則新建）中。然而此時動態(tài)庫與app還沒建立關(guān)聯(lián)關(guān)系，動態(tài)庫需要注入MachO中才能生效。注入使用yololib工具，下載yololib并編譯，將生產(chǎn)的命令復(fù)制到/usr/local/bin或$PATH中的其他路徑，便可以在終端使用yololib指令## 通過yololib工具實現(xiàn)注入動態(tài)庫 yololib "MachO文件路徑" "需要注入的動態(tài)庫路徑"注入成功后再對所有Framework簽名，最后對app重簽名，然后生成ipa文件。這里整理了一份用于重簽名的腳本 CJCodeSign，想了解更多關(guān)于簽名指令的內(nèi)容可點擊查看詳情。
3.4 關(guān)于重簽名的思考
iOS重簽名實現(xiàn)，可以發(fā)現(xiàn)用于簽名的私鑰資源（包括.cer證書和Provisioning Profile配置）和實際簽名的app包是沒有強關(guān)聯(lián)關(guān)系的，這也就帶來了兩方面的問題。
- .cer證書和Provisioning Profile配置被用于其他App的分發(fā)簽名，特別如果是In-House企業(yè)類型的證書，那是可以進(jìn)行無限制分發(fā)的，而一旦蘋果檢測到這種違規(guī)簽名的行為，輕則撤銷證書，重則注銷企業(yè)開發(fā)者賬號！這也就是為什么一定要嚴(yán)格把控 p12、Provisioning Profile 文件外發(fā)的原因。
- 自有App被注入代碼后重簽名，比如應(yīng)用多開、添加插件、惡意抓包等等，對于這一類的防護(hù)除了對Bundle ID進(jìn)行檢查，以及對App動態(tài)庫增加白名單檢索外好像也沒有更好的辦法。當(dāng)然這已經(jīng)涉及到逆向防護(hù)的方向了，本人對此還未深入了解，有興趣的同學(xué)可以一起參與探討。
全文完！
最后再附上重簽名腳本地址： CJCodeSign
作者簡介：
lele8446，iOS開發(fā)深耕者，愛好分享、深?探討有溫度的內(nèi)容，GitHub地址。
