深入淺出iOS編譯

黃文臣發表於2018-12-26
iOS編譯

前言

兩年前曾經寫過一篇關於編譯的文章《iOS編譯過程的原理和應用》，這篇文章介紹了iOS編譯相關基礎知識和簡單應用，但也很有多問題都沒有解釋清楚：

  • Clang和LLVM究竟是什麼
  • 原始檔到機器碼的細節
  • Linker做了哪些工作
  • 編譯順序如何確定
  • 標頭檔案是什麼？XCode是如何找到標頭檔案的？
  • Clang Module
  • 簽名是什麼？為什麼要簽名

為了搞清楚這些問題，我們來挖掘下XCode編譯iOS應用的細節。

編譯器

把一種程式語言(原始語言)轉換為另一種程式語言(目標語言)的程式叫做編譯器。

大多數編譯器由兩部分組成：前端和後端。

  • 前端負責詞法分析，語法分析，生成中間程式碼；
  • 後端以中間程式碼作為輸入，進行行架構無關的程式碼優化，接著針對不同架構生成不同的機器碼。

前後端依賴統一格式的中間程式碼(IR)，使得前後端可以獨立的變化。新增一門語言只需要修改前端，而新增一個CPU架構只需要修改後端即可。

Objective C/C/C++使用的編譯器前端是clang，swift是swift，後端都是LLVM。

編譯器架構

LLVM

LLVM命名源自Low Level Virtual Machine，是一個強大的編譯器開發工具套件，聽起來像是虛擬機器，但實際上LLVM和傳統意義的虛擬機器關係不大，只不過專案最初的名字是LLVM罷了。

LLVM的核心庫提供了現代化的source-target-independent優化器和支援諸多流行CPU架構的程式碼生成器，這些核心程式碼是圍繞著LLVM IR(中間程式碼)建立的。

基於LLVM，又衍生出了一些強大的子專案，其中iOS開發者耳熟能詳的是：Clang和LLDB。

clang

clang是C語言家族的編譯器前端，誕生之初是為了替代GCC，提供更快的編譯速度。一張圖瞭解clang編譯的大致流程：

clang編譯流程

接下來，從程式碼層面看一下具體的轉化過程，新建一個main.c:

#include <
stdio.h>
// 一點註釋#define DEBUG 1int main() {#ifdef DEBUG  printf("hello debug\n");
#else  printf("hello world\n");
#endif  return 0;

  }複製程式碼

預處理(preprocessor)

預處理會替進行標頭檔案引入，巨集替換，註釋處理，條件編譯(#ifdef)等操作。

#include "stdio.h"就是告訴前處理器將這一行替換成標頭檔案stdio.h中的內容，這個過程是遞迴的：因為stdio.h也有可能包含其標頭檔案。

用clang檢視預處理的結果：

xcrun clang -E main.c複製程式碼

預處理後的檔案有400多行，在檔案的末尾，可以找到main函式

int main() { 
 printf("hello debug\n");
  return 0;

  }複製程式碼

可以看到，在預處理的時候，註釋被刪除，條件編譯被處理。

詞法分析(lexical anaysis)

詞法分析器讀入原始檔的字元流，將他們組織稱有意義的詞素(lexeme)序列，對於每個詞素，此法分析器產生詞法單元（token）作為輸出。

$ xcrun clang -fmodules -fsyntax-only -Xclang -dump-tokens main.c複製程式碼

輸出：

annot_module_include '#include <
s'  Loc=<
main.c:1:1>
int 'int'  [StartOfLine] Loc=<
main.c:4:1>
identifier 'main'  [LeadingSpace] Loc=<
main.c:4:5>
....複製程式碼

Loc=<
main.c:1:1>
標示這個token位於原始檔main.c的第1行，從第1個字元開始。儲存token在原始檔中的位置是方便後續clang分析的時候能夠找到出錯的原始位置。

語法分析(semantic analysis)

詞法分析的Token流會被解析成一顆抽象語法樹(abstract syntax tree – AST)。

$ xcrun clang -fsyntax-only -Xclang -ast-dump main.c | open -f複製程式碼

main函式AST的結構如下：

 [0;
34m`- [0m [0;
1;
32mFunctionDecl [0m [0;
33m 0x7fcc188dc700 [0m <
 [0;
33mmain.c:4:1 [0m,  [0;
33mline:11:1 [0m>
  [0;
33mline:4:5 [0m [0;
1;
36m main [0m  [0;
32m'int ()' [0m [0;
34m  `- [0m [0;
1;
35mCompoundStmt [0m [0;
33m 0x7fcc188dc918 [0m <
 [0;
33mcol:12 [0m,  [0;
33mline:11:1 [0m>
 [0;
34m    |- [0m [0;
1;
35mCallExpr [0m [0;
33m 0x7fcc188dc880 [0m <
 [0;
33mline:6:3 [0m,  [0;
33mcol:25 [0m>
  [0;
32m'int' [0m [0;
36m [0m [0;
36m [0m [0;
34m    | |- [0m [0;
1;
35mImplicitCastExpr [0m [0;
33m 0x7fcc188dc868 [0m <
 [0;
33mcol:3 [0m>
  [0;
32m'int (*)(const char *, ...)' [0m [0;
36m [0m [0;
36m [0m <
 [0;
31mFunctionToPointerDecay [0m>
 [0;
34m    | | `- [0m [0;
1;
35mDeclRefExpr [0m [0;
33m 0x7fcc188dc7a0 [0m <
 [0;
33mcol:3 [0m>
  [0;
32m'int (const char *, ...)' [0m [0;
36m [0m [0;
36m [0m  [0;
1;
32mFunction [0m [0;
33m 0x7fcc188c5160 [0m [0;
1;
36m 'printf' [0m  [0;
32m'int (const char *, ...)' [0m [0;
34m    | `- [0m [0;
1;
35mImplicitCastExpr [0m [0;
33m 0x7fcc188dc8c8 [0m <
 [0;
33mcol:10 [0m>
  [0;
32m'const char *' [0m [0;
36m [0m [0;
36m [0m <
 [0;
31mBitCast [0m>
 [0;
34m    |   `- [0m [0;
1;
35mImplicitCastExpr [0m [0;
33m 0x7fcc188dc8b0 [0m <
 [0;
33mcol:10 [0m>
  [0;
32m'char *' [0m [0;
36m [0m [0;
36m [0m <
 [0;
31mArrayToPointerDecay [0m>
 [0;
34m    |     `- [0m [0;
1;
35mStringLiteral [0m [0;
33m 0x7fcc188dc808 [0m <
 [0;
33mcol:10 [0m>
  [0;
32m'char [13]' [0m [0;
36m lvalue [0m [0;
36m [0m [0;
1;
36m "hello debug\n" [0m [0;
34m    `- [0m [0;
1;
35mReturnStmt [0m [0;
33m 0x7fcc188dc900 [0m <
 [0;
33mline:10:3 [0m,  [0;
33mcol:10 [0m>
 [0;
34m      `- [0m [0;
1;
35mIntegerLiteral [0m [0;
33m 0x7fcc188dc8e0 [0m <
 [0;
33mcol:10 [0m>
  [0;
32m'int' [0m [0;
36m [0m [0;
36m [0m [0;
1;
36m 0 [0m複製程式碼

有了抽象語法樹，clang就可以對這個樹進行分析，找出程式碼中的錯誤。比如型別不匹配，亦或Objective C中向target傳送了一個未實現的訊息。

AST是開發者編寫clang外掛主要互動的資料結構，clang也提供很多API去讀取AST。更多細節：Introduction to the Clang AST。

CodeGen

CodeGen遍歷語法樹，生成LLVM IR程式碼。LLVM IR是前端的輸出，後端的輸入。

xcrun clang -S -emit-llvm main.c -o main.ll複製程式碼

main.ll檔案內容：

...@.str = private unnamed_addr constant [13 x i8] c"hello debug\0A\00", align 1;
 Function Attrs: noinline nounwind optnone ssp uwtabledefine i32 @main() #0 {  %1 = alloca i32, align 4  store i32 0, i32* %1, align 4  %2 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([13 x i8], [13 x i8]* @.str, i32 0, i32 0))  ret i32 0
  }...複製程式碼

Objective C程式碼在這一步會進行runtime的橋接：property合成，ARC處理等。

LLVM會對生成的IR進行優化，優化會呼叫相應的Pass進行處理。Pass由多個節點組成，都是Pass類的子類，每個節點負責做特定的優化，更多細節：Writing an LLVM Pass。

生成彙編程式碼

LLVM對IR進行優化後，會針對不同架構生成不同的目的碼，最後以彙編程式碼的格式輸出：

生成arm 64彙編：

$ xcrun clang -S main.c -o main.s複製程式碼

檢視生成的main.s檔案，篇幅有限，對彙編感興趣的同學可以看看我的這篇文章：iOS彙編快速入門。

_main:                                  ## @main        .cfi_startproc## %bb.0:        pushq   %rbp        .cfi_def_cfa_offset 16        .cfi_offset %rbp, -16        movq    %rsp, %rbp...複製程式碼

彙編器

彙編器以彙編程式碼作為輸入，將彙編程式碼轉換為機器程式碼，最後輸出目標檔案(object file)。

$ xcrun clang -fmodules -c main.c -o main.o複製程式碼

還記得我們程式碼中呼叫了一個函式printf麼？通過nm命令，檢視下main.o中的符號

$ xcrun nm -nm main.o                 (undefined) external _printf0000000000000000 (__TEXT,__text) external _main複製程式碼

_printf是一個是undefined external的。undefined表示在當前檔案暫時找不到符號_printf，而external表示這個符號是外部可以訪問的，對應表示檔案私有的符號是non-external。

Tips：什麼是符號(Symbols)? 符號就是指向一段程式碼或者資料的名稱。還有一種叫做WeakSymols，也就是並不一定會存在的符號，需要在執行時決定。比如iOS 12特有的API，在iOS11上就沒有。

連結

聯結器把編譯產生的.o檔案和（dylib,a,tbd）檔案，生成一個mach-o檔案。

$ xcrun clang main.o -o main複製程式碼

我們就得到了一個mach o格式的可執行檔案

$ file mainmain: Mach-O 64-bit executable x86_64$ ./main hello debug複製程式碼

在用nm命令，檢視可執行檔案的符號表：

$ nm -nm main                 (undefined) external _printf (from libSystem)                 (undefined) external dyld_stub_binder (from libSystem)0000000100000000 (__TEXT,__text) [referenced dynamically] external __mh_execute_header0000000100000f60 (__TEXT,__text) external _main複製程式碼

_printf仍然是undefined，但是後面多了一些資訊：from libSystem，表示這個符號來自於libSystem，會在執行時動態繫結。

XCode編譯

通過上文我們大概瞭解了Clang編譯一個C語言檔案的過程，但是XCode開發的專案不僅僅包含了程式碼檔案，還包括了圖片，plist等。XCode中編譯一次都要經過哪些過程呢？

新建一個單頁面的Demo工程：CocoaPods依賴AFNetworking和SDWebImage，同時依賴於一個內部Framework。按下Command+B，在XCode的Report Navigator模組中，可以找到編譯的詳細日誌：

XCode編譯

詳細的步驟如下：

  • 建立Product.app的資料夾
  • 把Entitlements.plist寫入到DerivedData裡，處理打包的時候需要的資訊（比如application-identifier）。
  • 建立一些輔助檔案，比如各種.hmap，這是headermap檔案，具體作用下文會講解。
  • 執行CocoaPods的編譯前指令碼：檢查Manifest.lock檔案。
  • 編譯.m檔案，生成.o檔案。
  • 連結動態庫，o檔案，生成一個mach o格式的可執行檔案。
  • 編譯assets，編譯storyboard，連結storyboard
  • 拷貝動態庫Logger.framework，並且對其簽名
  • 執行CocoaPods編譯後指令碼：拷貝CocoaPods Target生成的Framework
  • 對Demo.App簽名，並驗證（validate）
  • 生成Product.app

Tips: Entitlements.plist儲存了App需要使用的特殊許可權，比如iCloud，遠端通知，Siri等。

編譯順序

編譯的時候有很多的Task(任務)要去執行，XCode如何決定Task的執行順序呢？

答案是：依賴關係。

還是以剛剛的Demo專案為例，整個依賴關係如下：

任務依賴關係

可以從XCode的Report Navigator看到Target的編譯順序：

Target順序

XCode編譯的時候會盡可能的利用多核效能，多Target併發編譯。

那麼，XCode又從哪裡得到了這些依賴關係呢？

  • Target Dependencies – 顯式宣告的依賴關係
  • Linked Frameworks and Libraries – 隱式宣告的依賴關係
  • Build Phase – 定義了編譯一個Target的每一步

增量編譯

日常開發中，一次完整的編譯可能要幾分鐘，甚至幾十分鐘，而增量編譯只需要不到1分鐘，為什麼增量編譯會這麼快呢？

因為XCode會對每一個Task生成一個雜湊值，只有雜湊值改變的時候才會重新編譯。

比如，修改了ViewControler.m，只有圖中灰色的三個Task會重新執行（這裡不考慮build phase指令碼）。

增量編譯

標頭檔案

C語言家族中，標頭檔案(.h)檔案用來引入函式/類/巨集定義等宣告，讓開發者更靈活的組織程式碼，而不必把所有的程式碼寫到一個檔案裡。

標頭檔案對於編譯器來說就是一個promise。標頭檔案裡的宣告，編譯會認為有對應實現，在連結的時候再解決具體實現的位置。

標頭檔案報錯

當只有宣告，沒有實現的時候，連結器就會報錯。

Undefined symbols for architecture arm64:
“_umimplementMethod”, referenced from:
-[ClassA method] in ClassA.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Objective C的方法要到執行時才會報錯，因為Objective C是一門動態語言，編譯器無法確定對應的方法名(SEL)在執行時到底有沒有實現(IMP)。

日常開發中，兩種常見的標頭檔案引入方式：

#include "CustomClass.h" //自定義#include <
Foundation/Foundation.h>
 //系統或者內部framework複製程式碼

引入的時候並沒有指明檔案的具體路徑，編譯器是如何找到這些標頭檔案的呢？

回到XCode的Report Navigator，找到上一個編譯記錄，可以看到編譯ViewController.m的具體日誌：

詳細日誌

把這個日誌整體拷貝到命令列中，最後加上-v，表示我們希望得到更多的日誌資訊，執行這段程式碼，在日誌最後可以看到clang是如何找到標頭檔案的：

#include "..." search starts here: /Users/.../Build/Intermediates.noindex/Demo.build/Debug-iphoneos/Demo.build/Demo-generated-files.hmap (headermap) /Users/.../Build/Intermediates.noindex/Demo.build/Debug-iphoneos/Demo.build/Demo-project-headers.hmap (headermap) /Users/.../Build/Products/Debug-iphoneos/AFNetworking/AFNetworking.framework/Headers /Users/.../Build/Products/Debug-iphoneos/SDWebImage/SDWebImage.framework/Headers #include <
...>
 search starts here: /Users/.../Build/Intermediates.noindex/Demo.build/Debug-iphoneos/Demo.build/Demo-own-target-headers.hmap (headermap) /Users/.../Build/Intermediates.noindex/Demo.build/Debug-iphoneos/Demo.build/Demo-all-non-framework-target-headers.hmap (headermap) /Users/.../Build/Intermediates.noindex/Demo.build/Debug-iphoneos/Demo.build/DerivedSources /Users/.../Build/Products/Debug-iphoneos (framework directory) /Users/.../Build/Products/Debug-iphoneos/AFNetworking (framework directory) /Users/.../Build/Products/Debug-iphoneos/SDWebImage (framework directory) /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include $SDKROOT/usr/include $SDKROOT/System/Library/Frameworks (framework directory) End of search list.複製程式碼

這裡有個檔案型別叫做heademap，headermap是幫助編譯器找到標頭檔案的輔助檔案：儲存這標頭檔案到其物理路徑的對映關係。

可以通過一個輔助的小工具hmap檢視hmap中的內容：

192:Desktop Leo$ ./hmap print Demo-project-headers.hmap AppDelegate.h ->
 /Users/huangwenchen/Desktop/Demo/Demo/AppDelegate.hDemo-Bridging-Header.h ->
 /Users/huangwenchen/Desktop/Demo/Demo/Demo-Bridging-Header.hDummy.h ->
 /Users/huangwenchen/Desktop/Demo/Framework/Dummy.hFramework.h ->
 Framework/Framework.hTestView.h ->
 /Users/huangwenchen/Desktop/Demo/Demo/View/TestView.hViewController.h ->
 /Users/huangwenchen/Desktop/Demo/Demo/ViewController.h複製程式碼

Tips: 這就是為什麼備份/恢復Mac後，需要clean build folder，因為兩臺mac對應檔案的物理位置可能不一樣。

clang發現#import "TestView.h"的時候，先在headermap(Demo-generated-files.hmap,Demo-project-headers.hmap)裡查詢，如果headermap檔案找不到，接著在own target的framework裡找：

/Users/.../Build/Products/Debug-iphoneos/AFNetworking/AFNetworking.framework/Headers/TestView.h/Users/.../Build/Products/Debug-iphoneos/SDWebImage/SDWebImage.framework/Headers/TestView.h複製程式碼

系統的標頭檔案查詢的時候也是優先headermap，headermap查詢不到會查詢own target framework，最後查詢SDK目錄。

以#import <
Foundation/Foundation.h>
為例，在SDK目錄查詢時：

首先查詢framework是否存在

$SDKROOT/System/Library/Frameworks/Foundation.framework複製程式碼

如果framework存在，再在headers目錄裡查詢標頭檔案是否存在

$SDKROOT/System/Library/Frameworks/Foundation.framework/headers/Foundation.h複製程式碼

Clang Module

傳統的#include/#import都是文字語義：前處理器在處理的時候會把這一行替換成對應標頭檔案的文字，這種簡單粗暴替換是有很多問題的：

  1. 大量的預處理消耗。假如有N個標頭檔案，每個標頭檔案又#include了M個標頭檔案，那麼整個預處理的消耗是N*M。
  2. 檔案匯入後，巨集定義容易出現問題。因為是文字匯入，並且按照include依次替換，當一個標頭檔案定義了#define std hello_world，而第另一個標頭檔案剛好又是C++標準庫，那麼include順序不同，可能會導致所有的std都會被替換。
  3. 邊界不明顯。拿到一組.a和.h檔案，很難確定.h是屬於哪個.a的，需要以什麼樣的順序匯入才能正確編譯。

clang module不再使用文字模型，而是採用更高效的語義模型。clang module提供了一種新的匯入方式:@import，module會被作為一個獨立的模組編譯，並且產生獨立的快取，從而大幅度提高預處理效率，這樣時間消耗從M*N變成了M+N。

XCode建立的Target是Framework的時候，預設define module會設定為YES，從而支援module，當然像Foundation等系統的framwork同樣支援module。

#import <
Foundation/NSString.h>
的時候，編譯器會檢查NSString.h是否在一個module裡，如果是的話，這一行會被替換成@import Foundation。

Module

那麼，如何定義一個module呢？答案是：modulemap檔案，這個檔案描述了一組標頭檔案如何轉換為一個module，舉個例子：

framework module Foundation  [extern_c] [system] { 
umbrella header "Foundation.h" // 所有要暴露的標頭檔案  export * module * { 
  export *  
  }  explicit module NSDebug { 
//submodule   header "NSDebug.h"   export *  
  } 
  }複製程式碼

swift是可以直接import一個clang module的，比如你有一些C庫，需要在Swift中使用，就可以用modulemap的方式。

Swift編譯

現代化的語言幾乎都拋棄了標頭檔案，swift也不例外。問題來了，swift沒有標頭檔案又是怎麼找到宣告的呢？

編譯器幹了這些髒活累活。編譯一個Swift標頭檔案，需要解析module中所有的Swift檔案，找到對應的宣告。

swift編譯

當開發中難免要有Objective C和Swfit相互呼叫的場景，兩種語言在編譯的時候查詢符號的方式不同，如何一起工作的呢？

Swift引用Objective C：

Swift的編譯器內部使用了clang，所以swift可以直接使用clang module，從而支援直接import Objective C編寫的framework。

swiftc &<br /> clang” class=”lazyload” data-height=”540″ src=”https://user-gold-cdn.xitu.io/2018/12/26/167e865ac8321b67?imageView2/0/w/1280/h/960/ignore-error/1″ data-width=”828″><figcaption></figcaption></figure> </p> <p><strong>swift編譯器會從objective c標頭檔案裡查詢符號</strong>，標頭檔案的來源分為兩大類：</p> <ul> <li><code>Bridging-Header.h</code>中暴露給swfit的標頭檔案</li> <li>framework中公開的標頭檔案，根據編寫的語言不同，可能從modulemap或者umbrella header查詢</li> </ul> <p>XCode提供了巨集定義<code>NS_SWIFT_NAME</code>來讓開發者定義Objective C =><br /> Swift的符號對映，可以通過Related Items -><br /> Generate Interface來檢視轉換後的結果：</p> </p> <figure><img alt= Swift” class=”lazyload” data-height=”952″ src=”https://user-gold-cdn.xitu.io/2018/12/26/167e865ad4f73163?imageView2/0/w/1280/h/960/ignore-error/1″ data-width=”928″>

Objective引用swift

xcode會以module為單位，為swift自動生成標頭檔案，供Objective C引用，通常這個檔案命名為ProductName-Swift.h。

swift提供了關鍵詞@objc來把型別暴露給Objective C和Objective C Runtime。

@objc public class MyClass複製程式碼

深入理解Linker

連結器會把編譯器編譯生成的多個檔案，連結成一個可執行檔案。連結並不會產生新的程式碼，只是在現有程式碼的基礎上做移動和補丁。

連結器的輸入可能是以下幾種檔案：

  • object file(.o)，單個原始檔的編輯結果，包含了由符號表示的程式碼和資料。
  • 動態庫(.dylib)，mach o型別的可執行檔案，連結的時候只會繫結符號，動態庫會被拷貝到app裡，執行時載入
  • 靜態庫(.a)，由ar命令打包的一組.o檔案，連結的時候會把具體的程式碼拷貝到最後的mach-o
  • tbd，只包含符號的庫檔案

這裡我們提到了一個概念：符號(Symbols)，那麼符號是什麼呢？

符號是一段程式碼或者資料的名稱，一個符號內部也有可能引用另一個符號。

以一段程式碼為例，看看連結時究竟發生了什麼？

原始碼：

- (void)log{ 
printf("hello world\n");

  }複製程式碼

.o檔案：

#程式碼adrp    x0, l_.str@PAGEadd     x0, x0, l_.str@PAGEOFFbl      _printf#字串符號l_.str:                                 ;
 @.str        .asciz  "hello world\n"複製程式碼

在.o檔案中，字串”hello world\n”作為一個符號(l_.str)被引用，彙編程式碼讀取的時候按照l_.str所在的頁加上偏移量的方式讀取，然後呼叫printf符號。到這一步，CPU還不知道怎麼執行，因為還有兩個問題沒解決：

  1. l_.str在可執行檔案的哪個位置？
  2. printf函式來自哪裡？

再來看看連結之後的mach o檔案：

Linker

連結器如何解決這兩個問題呢？

  1. 連結後，不再是以頁+偏移量的方式讀取字串，而是直接讀虛擬記憶體中的地址，解決了l_.str的位置問題。
  2. 連結後，不再是呼叫符號_printf，而是在DATA段上建立了一個函式指標_printf$ptr，初始值為0x0(null)，程式碼直接呼叫這個函式指標。啟動的時候，dyld會把DATA段上的指標進行動態繫結，繫結到具體虛擬記憶體中的_printf地址。更多細節，可以參考我之前的這篇文章：深入理解iOS App的啟動過程。

Tips: Mach-O有一個區域叫做LINKEDIT，這個區域用來儲存啟動的時dyld需要動態修復的一些資料：比如剛剛提到的printf在記憶體中的地址。

理解簽名

基礎回顧

非對稱加密。在密碼學中，非對稱加密需要兩個金鑰：公鑰和私鑰。私鑰加密的只能用公鑰解密，公鑰加密的只能用私鑰解密。

數字簽名。數字簽名表示我對資料做了個標記，表示這是我的資料，沒有經過篡改。

資料傳送方Leo產生一對公私鑰，私鑰自己儲存，公鑰發給接收方Lina。Leo用摘要演算法，對傳送的資料生成一段摘要，摘要演算法保證了只要資料修改，那麼摘要一定改變。然後用私鑰對這個摘要進行加密，和資料一起傳送給Lina。

簽名

Lina收到資料後，用公鑰解密簽名，得到Leo發過來的摘要；然後自己按照同樣的摘要演算法計算摘要，如果計算的結果和Leo的一樣，說明資料沒有被篡改過。

驗證簽名

但是，現在還有個問題：Lina有一個公鑰，假如攻擊者把Lina的公鑰替換成自己的公鑰，那麼攻擊者就可以偽裝成Leo進行通訊，所以Lina需要確保這個公鑰來自於Leo，可以通過數字證書來解決這個問題。

數字證書由CA（Certificate Authority）頒發，以Leo的證書為例，裡面包含了以下資料：簽發者；Leo的公鑰；Leo使用的Hash演算法；證書的數字簽名；到期時間等。

有了數字證書後，Leo再傳送資料的時候，把自己從CA申請的證書一起傳送給Lina。Lina收到資料後，先用CA的公鑰驗證證書的數字簽名是否正確，如果正確說明證書沒有被篡改過，然後以信任鏈的方式判斷是否信任這個證書，如果信任證書，取出證書中的資料，可以判斷出證書是屬於Leo的，最後從證書中取出公鑰來做資料簽名驗證。

iOS App簽名

為什麼要對App進行簽名呢？簽名能夠讓iOS識別出是誰簽名了App，並且簽名後App沒有被篡改過，

除此之外，Apple要嚴格控制App的分發：

  1. App來自Apple信任的開發者
  2. 安裝的裝置是Apple允許的裝置

證書

通過上文的講解，我們知道數字證書裡包含著申請證書裝置的公鑰，所以在Apple開發者後臺建立證書的時候，需要上傳CSR檔案(Certificate Signing Request)，用keychain生成這個檔案的時候，就生成了一對公/私鑰：公鑰在CSR裡，私鑰在本地的Mac上。Apple本身也有一對公鑰和私鑰：私鑰儲存在Apple後臺，公鑰在每一臺iOS裝置上。

證書

Provisioning Profile

iOS App安裝到裝置的途徑(非越獄)有以下幾種：

  1. 開發包(插線，或者archive匯出develop包)
  2. Ad Hoc
  3. App Store
  4. 企業證書

開發包和Ad Hoc都會嚴格限制安裝裝置，為了把裝置uuid等資訊一起打包進App，開發者需要配置Provisioning Profile。

Provisioning Profile

可以通過以下命令來檢視Provisioning Profile中的內容：

security cms -D -i embedded.mobileprovision >
 result.plistopen result.plist複製程式碼

本質上就是一個編碼過後的plist

Provisioning Profile

iOS簽名

生成安裝包的最後一步，XCode會呼叫codesign對Product.app進行簽名。

建立一個額外的目錄_CodeSignature以plist的方式存放安裝包內每一個檔案簽名

<
key>
Base.lproj/LaunchScreen.storyboardc/01J-lp-oVM-view-Ze5-6b-2t3.nib<
/key>
<
data>
T2g5jlq7EVFHNzL/ip3fSoXKoOI=<
/data>
<
key>
Info.plist<
/key>
<
data>
5aVg/3m4y30m+GSB8LkZNNU3mug=<
/data>
<
key>
PkgInfo<
/key>
<
data>
n57qDP4tZfLD1rCS43W0B4LQjzE=<
/data>
<
key>
embedded.mobileprovision<
/key>
<
data>
tm/I1g+0u2Cx9qrPJeC0zgyuVUE=<
/data>
...複製程式碼

程式碼簽名會直接寫入到mach-o的可執行檔案裡，值得注意的是簽名是以頁(Page)為單位的，而不是整個檔案簽名：

程式碼簽名

驗證

在安裝App的時候，

  • 從embedded.mobileprovision取出證書，驗證證書是否來自Apple信任的開發者
  • 證書驗證通過後，從證書中取出Leo的公鑰
  • 讀取_CodeSignature中的簽名結果，用Leo的公鑰驗證每個檔案的簽名是否正確
  • 檔案embedded.mobileprovision驗證通過後，讀取裡面的裝置id列表，判斷當前裝置是否可安裝(App Store和企業證書不做這步驗證)
  • 驗證通過後，安裝App

啟動App的時候：

  • 驗證bundle id，entitlements和embedded.mobileprovision中的AppId，entitlements是否一致
  • 判斷device id包含在embedded.mobileprovision裡
    • App Store和企業證書不做驗證
  • 如果是企業證書，驗證使用者是否信任企業證書
  • App啟動後，當缺頁中斷(page fault)發生的時候，系統會把對應的mach-o頁讀入實體記憶體，然後驗證這個page的簽名是否正確。
  • 以上都驗證通過，App才能正常啟動

小結

如有內容錯誤，歡迎issue指正。

來源：https://juejin.im/post/5c22eaf1f265da611b5863b2#comment

相關文章