概念性的東西:代碼簽名是對可執行文件或腳本進行數字簽名.用 來確認軟件在簽名後未被修改或損壞的措施。和 數字簽名原理同樣,只不過簽名的數據是代碼而已。算法
在iOS出來以前,之前的主流操做系統(Mac/Windows)軟件隨便從哪裏下載都能運行,系統安全存在隱患,盜版軟件,病 毒入侵,靜默安裝等等.那麼蘋果但願解決這樣的問題,要保證每個安裝到 iOS 上的 APP 都是通過蘋果官方容許的,怎樣 保證呢?就是經過代碼簽名。shell
若是要實現驗證.其實最簡單的方式就是經過蘋果官方生成非對稱加密的一對公私鑰.在iOS的系統中內置一個公鑰,私鑰 由蘋果後臺保存,咱們傳APP到AppStore時,蘋果後臺用私鑰對APP數據進行簽名,iOS系統下載這個APP後,用公鑰驗證這個簽名, 若簽名正確,這個APP確定是由蘋果後臺認證的,而且沒有被修改過,也就達到了蘋果的需求:保證安裝的每個APP都是通過蘋 果官方容許的.安全
若是咱們iOS設備安裝APP只從App Store這一個入口這件事就簡單解決了,沒有任何複雜的東西,一個數字簽名搞定. 可是實際上iOS安裝APP還有其餘渠道.好比對於咱們開發者iOSER而言,咱們是須要在開發APP時直接真機調試的.並且蘋 果還開放了企業內部分發的渠道,企業證書籤名的APP也是須要順利安裝的. 蘋果須要開放這些方式安裝APP,這些需求就沒法經過簡單的代碼簽名來辦到了。
bash
• 通過蘋果容許才能夠安裝服務器
• 不能被濫用致使非開發APP也能被安裝微信
因此爲了實現這些需求,iOS簽名的複雜度也就開始增長,蘋果給出的方案,就是雙層簽名。app
iOS的雙層代碼簽名流程簡單梳理,這也不是最終的iOS簽名原理.iOS的最終簽名在這個基礎上還要稍微加 點東西.ide
首先這裏有兩個角色.一個是iOS系統 還有一個就是咱們的Mac系統.由於iOS的APP開發環境在Mac系統下.因此這 個依賴關係成爲了蘋果雙層簽名的基礎.工具
一、在Mac系統中生成一對非對稱加密算法的公鑰和私鑰,這裏簡稱公鑰M和私鑰M。網站
二、蘋果本身也有一對固定的公鑰A和私鑰A,公鑰A在每一個手機iOS系統中,而私鑰A在蘋果後臺。
三、在項目打包過程當中,咱們第一件事,就是生成CSR文件,生成文件的時候,電腦會讓咱們填入相關開發者信息,這些就是所謂的信息摘要。把CSR文件(包含公鑰M以及開發者信息)發送給蘋果後臺,蘋果後臺用私鑰A去簽名公鑰M,獲得了一份數據包含了公鑰M以及其簽名,這份數據稱爲證書,以及會給咱們一份描述文件(經過填寫設備ID、AppID、證書等信息獲得的(Provisioning profile)。
四、在開發時,編譯完一個APP後,用本地的私鑰M(其本質就是P12文件)對這個APP進行簽名,同時把第三部獲得的描述文件及證書一塊兒打包進APP裏,安裝到手機上。
五、在安裝時,iOS系統取得證書,經過系統內置的公鑰A,去驗證證書的數字簽名是否正確。
六、驗證證書後確保了公鑰M是蘋果認證過的,再用公鑰 M 去驗證 APP 的簽名,這裏就間接驗證了這個 APP 安裝 行爲是否通過蘋果官方容許。(這裏只驗證安裝行爲,不驗證APP 是否被改動,由於開發階段 APP 內容老是 不斷變化的,蘋果不須要管。)
若是你仍是不太明白,就仔細看一下下面的流程圖。
有了上面的過程,已經能夠保證開發者的認證,和程序的安全性了。
描述文件(Provisioning profile)通常包括三樣東 西:證書、App ID、設備。當咱們在真機運行或 者打包一個項目的時候,證書用來證實咱們程序 的安全性和合法性。
蘋果爲了解決應用濫用的問題,因此蘋果又加了兩個限制. 第一限制在蘋果後臺註冊過的設備才能夠安裝. 第二限制簽名只能針對某一個具體的APP. 而且蘋果還想控制App裏面的iCloud/PUSH/後臺運行/調試器附加這些權限,因此蘋果把這些權限開關統一稱爲 Entitlements(受權文件).並將這個文件放在了一個叫作Provisioning Profile(描述文件)文件中. 描述文件是在AppleDevelop網站建立的(在Xcode中填上AppleID它會代辦建立),Xcode運行時會打包進入APP內. 因此咱們使用CSR申請證書時,咱們還要申請一個東西!! 就是描述文件! 在開發時,編譯完一個 APP 後,用本地的私鑰M對這個APP進行簽名,同時把從蘋果服務器獲得的 Provisioning Profile 文件 打包進APP裏,文件名爲embedded.mobileprovision,把 APP 安裝到手機上.最後系統進行驗證。
Xcode提供了簽名工具,codesign,咱們經過幾個命令就能夠完成重簽名。平常咱們開發中,簽名的過程都是Xcode代替咱們手工完成。
$security find-identity -v -p codesigning //列出鑰匙串裏可簽名的證書
複製代碼
$Codesign –fs 「證書串」 //文件名 強制替換籤名
複製代碼
$Chmod +x 可執行文件 //給文件添加權限
複製代碼
$security cms -D -i ../embedded.mobileprovision //查看描述文件
複製代碼
$codesign -fs 「證書串」 --no-strict --entitlements=權限文件.plist APP包
複製代碼
$Zip –ry 輸出文件 輸入文件 將輸入文件壓縮爲輸出文件
複製代碼
說在前面的一些注意事項,由於剛開始接觸逆向,因此如今pp助手下載越獄的ipa包。越獄的ipa包是非加密包,能夠經過幾項操做查詢到該ipa包是否加密
如下咱們用微信舉例:
一、下載越獄版WeChat ipa包,解壓後,獲得WeChat.app,右鍵顯示包內容,打開iterm2,cd到該目錄下。
二、
$ otool -l WeChat | grep cry //otool查詢WeChat文件信息,而後管道輸出以cry開頭的信息.複製代碼
cryptid 0 // 1表明加密算法, 0表明未加密複製代碼
ps:若是cryptid 1 ,證實app是通過appStore加密處理過的。此加密是對稱加密,由於數據量過大,以前咱們說過非對稱加密適合小型數據加密。那麼何時解密呢?是手機安裝的時候對app解密,仍是在運行的時候解密呢?答案是運行的時候解密,因此在appStore上下載的app,咱們每次運行的時候,都會進行解密。
三、在該文件夾下刪除插件和帶有插件的.app包(Watch\Plugins若是有就刪除)
四、在顯示包內容文件夾對Frameworks文件夾下的庫進行重簽名
$ codesign -fs "iPhone Developer:XXX(123A456B)" abc.framework //強制替換籤名,這裏強調一下,若是存在多個.framework都要依次強制替換籤名。複製代碼
五、包內容下,有個叫WeChat的可執行文件,該文件圖標爲白色則是無執行權限,黑色則是有可執行權限。
$ chomd +x 可執行文件 //給文件添加權限複製代碼
六、本地新建工程,(必定要是同名工程,避免在包內容文件夾下的可執行文件衝突,同時也是爲了方便),這裏新建工程是爲了獲得描述文件,描述文件不可生成,只能去請求,把新建項目在真機跑一遍,保證真機已信任該描述文件。
七、打開該新建工程,打開包內容,複製描述文件,而後粘貼到微信的包內容下
七、替換BundleID,在微信(WeChat.app)的包內容文件夾下找到info.plist文件,替換成新建工程的BundleID。
八、打開新建工程的描述文件、查看描述文件信息
$ cd /複製代碼
$ security cms -Di +描述文件複製代碼
<key>Entitlements</key>
<dict>
<key>xxxxx</key>
<array>xxxxx</array>
<true/>xxxx
<string>xxxx</string>
</dict>複製代碼
複製<dict>下全部內容,而後新建abx.plist文件,粘貼其內容,保證格式正確。
九、經過受權文件(Entilements)重籤.app包,注意,上面生成的abx.plist的很重要,描述文件包含其權限文件。
$codesign -fs "iPhone Developer:XXX(123A456B)" --no-strict --entitlements=abx.plist WeChat.app
複製代碼
十、回到Xcode新建項目中,command + shift + R,點擊+,安裝WeChat.app。這時候會提示,是否要替換掉你剛纔新建的項目(由於爲了讓手機信任描述文件,因此咱們以前用真機跑過一次新建項目)。選擇替換replace。
十一、至此安裝成功。回到Xcode中,點擊debug,選擇attach to process,找到WeChat。點擊。直到Xcode進程欄中顯示, Running WeChat on XXiPhone。成功附加,就能夠lldb調試了。
說在最後面的話。以上知識點僅是從新簽名的原理,往後還會更新利用Xcode快速重簽名以及shell腳本重簽名。
若是我哪裏寫的不對,還但願你能校訂出來,咱們共同進步,若是你喜歡此文章,就動一動小手點個贊吧。