寫在前面
應用重簽名（本文涉及）無風險，但某信有檢測BundId機制，建議不要大號登入
一、程式碼簽名
程式碼簽名是對可執行檔案或指令碼進行數字簽名，用來確認軟體在簽名後未被修改或損壞的措施。和數字簽名原理一樣，只不過簽名的資料是程式碼而已
1.簡單的程式碼簽名
2.開發者上傳App到App Store時，蘋果後臺用私鑰對App資料進行簽名（即先進行Hash得到hash值，再用私鑰加密hash值得到“RSAHash”）；
3.iOS系統下載這個App後，用內建的公鑰驗證這個簽名，若簽名正確，那麼這個App肯定是由蘋果後臺認證的，並且沒有被修改過，也就達到了蘋果的需求:保證安裝的每一個APP都是經過蘋果官方允許的。（公鑰解密“RSAHash”得到hash1，再對應用包進行相同hash演算法得到hash2,驗證兩次hash值是否相同）
但是還有很多需求是不能通過App Store下載這一途徑滿足的
2.蘋果的市場需求
1.安裝包不需要上傳到App Store，可以直接安裝到手機上
- 開發App時直接真機除錯安裝
- 企業內部分發的渠道企業證書籤名的APP也是需要順利安裝的
2.蘋果為了保證系統的安全性,又必須對安裝的APP有絕對的控制權
- 經過蘋果允許才可以安裝
- 不能被濫用導致非開發APP也能被安裝
為了實現這些需求，iOS簽名的複雜度也就開始增加了，蘋果這裡給出的方案是雙層簽名
3.雙層簽名
這裡簡單梳理了一下iOS的雙層簽名流程，當然這不是最終的流程，蘋果爸爸在這個基礎流程上還要加點東西。這個流程中有兩個基礎角色：Mac電腦、iPhone手機，因為iOS的APP開發環境在Mac系統下，所以這個依賴關係成為了蘋果雙層簽名的基礎
1.蘋果自己有固定的一對公私鑰，跟之前App Store原理一樣，私鑰儲存在蘋果後臺，公鑰放在每個iOS系統中。這裡稱為公鑰A、私鑰A；在Mac系統中建立CSR檔案時生成非對稱加密演算法的一對公鑰/私鑰，這裡稱為公鑰M、私鑰M；A=Apple M = Mac
2.開發者通過CSR檔案向開發者中心申請證書
3.蘋果伺服器生成證書，也就是我們平時所說的開發者證書，其原理就是用私鑰A對公鑰M非對稱加密。請求到證書之後，鑰匙串訪問就會將證書與本地私鑰M（ 就是我們所熟知的p12） 進行相關聯
4.當我們Command+B生成一個應用時，Xcode就會用本地的私鑰M對這個應用進行簽名，同時將證書放到app裡面打包成ipa包
5.iPhone手機安裝ipa包
6.iOS系統裡的公鑰A對證書進行驗證
7.驗證通過拿到證書中的公鑰M
8.公鑰M驗證app的簽名。這裡就間接驗證了這個APP的安裝行為是否經過蘋果官方允許（這裡只驗證安裝行為，不驗證APP是否被改動，因為開發階段 APP 內容總是不斷變化的，蘋果不需要管）
3.第一次簽名：私鑰A->公鑰M=>證書
4.第二次簽名：私鑰M->app=>app
7.第一次驗證：公鑰A->證書=>公鑰M
8.第二次驗證：公鑰M->私鑰M=>結果
當CSR檔案建立的時候，會自動生成一對私鑰和公鑰，私鑰儲存在Mac上，私鑰儲存預設儲存在登入鑰匙串中，可以在鑰匙串的分類鑰匙下檢視，請求到的證書會包含公鑰部分
圖中還有一大坨東西是什麼？接下來就來介紹它
4.描述檔案
蘋果為了解決應用濫用的問題，所以蘋果又加了兩個限制
- 第一限制在蘋果後臺註冊過的裝置才可以安裝
- 第二限制簽名只能針對某一個具體的App，並且蘋果還想控制App裡面的iCloud/PUSH/後臺執行/偵錯程式附加這些許可權，所以蘋果把這些許可權開關統一稱為Entitlements（授權檔案）
因此才有了Provisioning Profile（描述檔案）
描述檔案一般包括證書、AppID、裝置。當我們在真機執行或者打包一個專案的時候，證書用來證明我們程式的安全性和合法性
描述檔案是在AppleDevelop網站建立的（在Xcode中填上AppleID它會代辦建立），Xcode執行時會打包進入App內。所以我們使用CSR申請證書時,我們還要申請一個東西！！就是描述檔案！
在開發時，編譯完一個App後，用本地的私鑰M對這個App進行簽名，同時把從蘋果伺服器得到的 Provisioning Profile檔案打包進APP裡，檔名為embedded.mobileprovision，把 APP 安裝到手機上，最後系統進行驗證
前往描述檔案目錄
$ /Users/**使用者名稱**/Library/MobileDevice/Provisioning Profiles
複製程式碼檢視描述檔案
$ security cms -Di xxx.mobileprovision
複製程式碼二、重簽名
1.重簽名前期準備
1.PP助手下載微信（越獄版本）
3.終端進入如圖目錄檢視應用簽名資訊
$ codesign -vv -d WeChat.app
複製程式碼//注意這裡要選擇iPhone Developer證書
$ security find-identity -v -p codesigning
複製程式碼5.檢視MachO檔案是否加密（步驟3顯示包內容後進入當前目錄）
//讀取MachO資訊
$ otool -l WeChat
//讀取MachO資訊並
$ otool -l WeChat > ~/Desktop/123.txt
//讀取MachO中"cry"開頭的資訊
$ otool -l WeChat | grep cry
複製程式碼2.重簽名步驟
1.刪除外掛和帶有外掛的.app包（比如Watch，PlugIns）
因為普通賬號不能對外掛進行簽名，所以需要刪除
在包內容路徑中找到Watch和PlugIns資料夾直接刪除
2.重籤framework
// 進入FrameWork目錄
$ cd Frameworks
// 列舉當前FrameWork
$ ls
// 覆蓋簽名
// codesign -fs "（證書名稱）" （FrameWork名稱）
$ codesign -fs "iPhone Developer: 840385400@qq.com (NZJQGFWAYE)" mars.framework
$ codesign -fs "iPhone Developer: 840385400@qq.com (NZJQGFWAYE)" marsbridgenetwork.framework
$ codesign -fs "iPhone Developer: 840385400@qq.com (NZJQGFWAYE)" matrixreport.framework
$ codesign -fs "iPhone Developer: 840385400@qq.com (NZJQGFWAYE)" OpenSSL.framework
$ codesign -fs "iPhone Developer: 840385400@qq.com (NZJQGFWAYE)" ProtobufLite.framework
$ codesign -fs "iPhone Developer: 840385400@qq.com (NZJQGFWAYE)" andromeda.framework
複製程式碼3.給MachO上可執行許可權
在包內容路徑下執行$ Chmod +x WeChat
4.新增描述檔案
新建工程，真機執行即可得到描述檔案
將ipa包中的描述檔案放到微信的包內容中去
5.修改應用包的bundid
修改微信包內容中的info.plist->BundleId，改為與描述檔案的BundleId一致
6.授權檔案重籤app包
檢視原先的描述檔案embedded.mobileprovision並複製相應內容
$ security cms -Di embedded.mobileprovision
利用Xcode新建一個plist檔案
以程式碼形式開啟plist檔案（open As->Source code）並貼上相應內容
複製一份與目標.app放於同一目錄下
最後一步命令列簽名app包
$ codesign -fs "iPhone Developer: 840385400@qq.com (NZJQGFWAYE)" --no-strict --entitlements=ent.plist WeChat.app
複製程式碼7.安裝.app包
Xcode介面下shift+cmd+2調出手機裝置
app執行後利用Xcode附加程式
點選“登入”按鈕就可以列印對應資訊了
接下來再介紹個騷操作——利用Xcode來使以上繁瑣的步驟略微減少
3.xcode重簽名
必須是與MachO檔案同名工程（工程名相同，BundId無所謂），否則程式不是微信程式
1.執行app，裝描述檔案
新建WeChat工程，同上Command+Run，將描述檔案生成一下
2.替換掉app包
複製一個新的越獄包，覆蓋掉到原來的ipa包
3.刪除外掛
同本文2-1
4.重籤framework
同本文2-2
5.run
由於是Xcode直接執行，可以通過Debug View檢視介面
寫在結尾
本來想寫的簡潔點，但為了讓看這篇文章的人有所收穫，我還是一步步操作儘可能講解的詳細點。我覺得寫部落格的目的一半是為了積累，另一半是送人玫瑰，手留餘香，希望對重簽名原理這塊沒怎麼接觸過的同學能有個初步認識乃至能夠上手操作
下一篇將介紹更騷的重簽名操作