深入淺出iOS編譯

黃文臣發表於2018-12-26

前言

兩年前曾經寫過一篇關於編譯的文章《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開發者耳熟能詳的是:ClangLLDB

clang

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

clang編譯流程

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

#include <stdio.h>
// 一點註釋
#define DEBUG 1
int 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 uwtable
define 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 _printf
0000000000000000 (__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 main
main: 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_header
0000000100000f60 (__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.h
Demo-Bridging-Header.h -> /Users/huangwenchen/Desktop/Demo/Demo/Demo-Bridging-Header.h
Dummy.h -> /Users/huangwenchen/Desktop/Demo/Framework/Dummy.h
Framework.h -> Framework/Framework.h
TestView.h -> /Users/huangwenchen/Desktop/Demo/Demo/View/TestView.h
ViewController.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 & clang

swift編譯器會從objective c標頭檔案裡查詢符號,標頭檔案的來源分為兩大類:

  • Bridging-Header.h中暴露給swfit的標頭檔案
  • framework中公開的標頭檔案,根據編寫的語言不同,可能從modulemap或者umbrella header查詢

XCode提供了巨集定義NS_SWIFT_NAME來讓開發者定義Objective C => Swift的符號對映,可以通過Related Items -> Generate Interface來檢視轉換後的結果:

Objective C => Swift

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@PAGE
add     x0, x0, l_.str@PAGEOFF
bl      _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.plist
open 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指正。

相關文章