本文字數：3141字

預計閱讀時間：25分鐘

一、背景

最近看到一篇有意思的技術文章：《抖音研發實踐：基于二進制檔案重排的解決方案 APP啟動速度提升超15%》，

原文結尾提到該方案無法覆寫100%的符號：

基于靜態掃描+運行時trace的方案仍然存在少量瓶頸：

initialize hook不到

部分block hook不到

C++通過暫存器的間接函式呼叫靜態掃描不出來

目前的重排方案能夠覆寫到80%～90%的符號，未來我們會嘗試編譯期插樁等方案來進行100%的符號覆寫，讓重排達到最優效果，

實際上，除上面的場景外，抖音研發團隊的方案還存在一些無法覆寫的場景：

無法覆寫代碼行級別的檢測
- 當某些復雜的函式存在 if/else/switch 等場景時，開發者可以將函式拆成多個子函式進行優化
OC/C 語言的函式呼叫同樣很難被靜態掃描
無法對第三方的靜態庫或者動態庫進行有效處理
無法檢測 __attribute__((constructor)) 修飾的函式

今天我們將嘗試通過 llvm 和 IR 配合實作解決上面提到的各類場景，

二、效果展示

本質上，上面提到的各類場景，都可以通過 對代碼進行 基本塊(BasicBlock-Level) 級別插樁 的方式解決，

為了方便讀者能夠繼續將本文全部閱讀下去，我們先看看一個給 微信SDK 插樁的實際效果，

基本塊(BasicBlock-Level) 的概念會在下一章節進行講解

1、微信SDK

微信SDK（OpenSDK1.8.7.1)^[1] 提供了3個公開的頭檔案，其中 WXApi.h 的暴露了一個類方法 [WXApi registerApp: universalLink:]：

/*! @brief 微信Api介面函式類
 *
 * 該類封裝了微信終端SDK的所有介面
 */
@interface WXApi : NSObject

/*! @brief WXApi的成員函式，向微信終端程式注冊第三方應用，
 *
 * 需要在每次啟動第三方應用程式時呼叫，
 * @attention 請保證在主執行緒中呼叫此函式
 * @param appid 微信開發者ID
 * @param universalLink 微信開發者Universal Link
 * @return 成功回傳YES，失敗回傳NO，
 */
+ (BOOL)registerApp:(NSString *)appid universalLink:(NSString *)universalLink;

@end

2、 main.m

新建一個工程，添加回呼函式并增加對微信SDK的介面呼叫：

@import Darwin;
int main(int argc, char * argv[]) {
  // 呼叫微信SDK
    [WXApi registerApp:@"App" universalLink:@"link"];
    return 0;
}

// 提供回呼函式
void __sanitizer_cov_trace_pc_guard(uint32_t *guard) {
    Dl_info info;
  // 獲取當前函式的回傳地址 
)
    void *PC = __builtin_return_address(0);
   // 根據回傳地址，獲取相關的資訊 
    dladdr(PC, &info);
   // 列印與 PC 最近的符號名稱
    printf("guard:%p 開始執行:%s \n", PC, info.dli_sname);
}

更多內容，可以閱讀參考資料的相關鏈接 dladdr^[2] __builtin_return_address^[3]

3、運行

通過在 __sanitizer_cov_trace_pc_guard 函式增加斷點，我們可以看到下面的呼叫堆疊：

整理后的流程圖如下所示：

我們可以很容易地從流程圖看出來：

微信SDK 呼叫了開發者提供的回呼函式 __sanitizer_cov_trace_pc_guard，

下面，我們開始進入正題，

三、插樁與代碼覆寫率

為了強調一下本文與抖音技術方案的區別，我們需要先了解一下插樁中常用的代碼覆寫率計量單位，

通常情況下，代碼覆寫率有 3 種計量單位：

函式（Fuction-Level）
基本塊（BasicBlock-Level）
邊界（Edge-Level）

1、函式（Fuction-Level）

函式（Fuction-Level） 比較容易理解，就是記錄哪些函式執行過，是一種粗糙但高效的統計方式，

從抖音的技術文章看，他們勉強算是做到了這個級別的代碼覆寫率檢測，

2、基本塊（BasicBlock-Level）

基本塊（BasicBlock） 通常是只包含順序執行的代碼塊，

以下面的代碼為例：

void foo(int *a) {
  if (a)
    *a = 0;
}

通過編譯器將代碼轉為匯編時，它會被拆成3個部分：

每個部分都是一個 基本塊（BasicBlock），

代碼行覆寫率可以通過 基本塊（BasicBlock-Level） 級別的代碼插樁實作，

3、邊界（Edge-Level）

邊界（Edge） 的概念比較難理解，我們仍然以上面的代碼為例進行說明，

上面的代碼包含3個 基本塊（BasicBlock） ： A、B、C，

即使代碼行覆寫測驗報告顯示 A、B、C 三塊都被執行過，我們仍然無法得到以下結論：

路徑A-->C 出現過，

此時，我們可以添加一個虛擬路徑 D：

如果測驗報告顯示 虛擬路徑 D 被執行過，則路徑A-->C 就一定出現過；反之，路徑A-->C 就一定沒有出現過，

路徑覆寫率可以通過 邊界（Edge） 級別的代碼插樁實作，

三、SanitizerCoverage

根據 llvm 的官方檔案 SanitizerCoverage^[4]，我們可以搭配 -fsanitize-coverage=trace-pc-guard 或者其它編譯引數控制編譯器插入不同級別的 樁，

下面，我們以 -fsanitize-coverage=trace-pc-guard 為例進行演示效果：

1、配置編譯開關

2、準備原始碼檔案

// 檔案 A
int f(void) __attribute__((constructor));

int f(void) {
    NSLog(@" int f() __attribute__((constructor)) 被呼叫");
    return 0;
}

// 檔案 ViewController.mm
#import <string>

static std::string cxx_static_str("cxx_static_str");

+ (void)load {
    NSLog(@"load 被執行");
}

// 檔案 main.m
@import Darwin;

void __sanitizer_cov_trace_pc_guard_init(uint32_t *start,
                                         uint32_t *stop) {
    static uint32_t N;  // Counter for the guards.
    if (start == stop || *start) return;  // Initialize only once.
    printf("INIT: %p %p\n", start, stop);
    for (uint32_t *x = start; x < stop; x++)
    *x = ++N;
}

void __sanitizer_cov_trace_pc_guard(uint32_t *guard) {
    Dl_info info;
    
    void *PC = __builtin_return_address(0);
    dladdr(PC, &info);
    printf("guard:%p 開始執行:%s \n", PC, info.dli_sname);
}

void foo(int *a) {
    if (a)
        *a = 0;
}


int main(int argc, char * argv[]) {
    dispatch_async(dispatch_get_main_queue(), ^{
        NSLog(@"main block");
    });
    int i=0;
    foo(&i);
    
    NSString * appDelegateClassName;
    @autoreleasepool {
        // Setup code that might create autoreleased objects goes here.
        appDelegateClassName = NSStringFromClass([AppDelegate class]);
    }
    return UIApplicationMain(argc, argv, nil, appDelegateClassName);
}

3、運行

運行日志如下所示，我們可以發現以下場景都能夠被正常覆寫：

load 方法
c++ 變數
__attribute__((constructor)) 修飾的函式
函式 foo 的兩個 基本塊（BasicBlock-Level)
block

四、編譯流程簡析

我們先通過一個簡單例子，看看原始碼是如何成為二進制檔案的，

1、準備原始碼檔案

命令列輸入：

cat <<EOF > main.m
int main() {
  return 0;
}
EOF

2、列印構建順序

命令列輸入：

xcrun clang main.m -save-temps -v -mllvm -debug-pass=Structure -fsanitize-coverage=trace-pc-guard

輸出如下所示（有刪減）：

clang -cc1 -E --fsanitize-coverage-type=3 -fsanitize-coverage-trace-pc-guard main.mi -x objective-c main.m

clang -cc1 -emit-llvm-bc -disable-llvm-passes -fsanitize-coverage-type=3 -fsanitize-coverage-trace-pc-guard -o main.bc -x objective-c-cpp-output main.mi

clang -cc1 -S -fsanitize-coverage-type=3 -fsanitize-coverage-trace-pc-guard -o main.s -x ir main.bc

clang -cc1as -o main.o main.s

ld -o a.out -L/usr/local/lib main.o

整理后，如下圖所示：

graph LR
 subgraph 示例
     流程:::流程
     檔案:::檔案
    classDef 流程 fill:#f96;
	end
 

  main.m-->preprocessor:::流程-->main.mi
  --> compiler:::流程--> main.bc
  
  
  main.bc_fake[main.bc] --> backend:::流程 --> main.s
  --> assembler:::流程 --> main.o
  --> linker:::流程 --> a.out

因為 main.bc 是二進制版本的 bitcode，可讀性比較差，

開發者可以通過 llvm-dis main.bc -o - 命令轉為更具有可讀性的版本：

; ModuleID = 'main.bc'
source_filename = "~/main.m"
target datalayout = "e-m:o-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.15.0"

; Function Attrs: noinline nounwind optnone ssp uwtable
define i32 @main() #0 {
  %1 = alloca i32, align 4
  store i32 0, i32* %1, align 4
  ret i32 0
}

attributes #0 = { noinline nounwind optnone ssp uwtable "correctly-rounded-divide-sqrt-fp-math"="false" "darwin-stkchk-strong-link" "disable-tail-calls"="false" "frame-pointer"="all" "less-precise-fpmad"="false" "min-legal-vector-width"="0" "no-infs-fp-math"="false" "no-jump-tables"="false" "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" "no-trapping-math"="false" "probe-stack"="___chkstk_darwin" "stack-protector-buffer-size"="8" "target-cpu"="penryn" "target-features"="+cx16,+cx8,+fxsr,+mmx,+sahf,+sse,+sse2,+sse3,+sse4.1,+ssse3,+x87" "unsafe-fp-math"="false" "use-soft-float"="false" }

!llvm.module.flags = !{!0, !1, !2, !3, !4, !5, !6, !7}
!llvm.ident = !{!8}

!0 = !{i32 2, !"SDK Version", [3 x i32] [i32 10, i32 15, i32 6]}
!1 = !{i32 1, !"Objective-C Version", i32 2}
!2 = !{i32 1, !"Objective-C Image Info Version", i32 0}
!3 = !{i32 1, !"Objective-C Image Info Section", !"__DATA,__objc_imageinfo,regular,no_dead_strip"}
!4 = !{i32 1, !"Objective-C Garbage Collection", i8 0}
!5 = !{i32 1, !"Objective-C Class Properties", i32 64}
!6 = !{i32 1, !"wchar_size", i32 4}
!7 = !{i32 7, !"PIC Level", i32 2}
!8 = !{!"Apple clang version 12.0.0 (clang-1200.0.32.21)"}

再與 main.s 檔案的內容對照一下：

	.p	__TEXT,__text,regular,pure_instructions
	.build_version macos, 10, 15	sdk_version 10, 15, 6
	.globl	_main                   ## -- Begin function main
	.p2align	4, 0x90
_main:                                  ## @main
	.cfi_startproc
## %bb.0:
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset %rbp, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register %rbp
	subq	$16, %rsp
	leaq	l___sancov_gen_(%rip), %rdi
	callq	___sanitizer_cov_trace_pc_guard
	## InlineAsm Start
	## InlineAsm End
	xorl	%eax, %eax
	movl	$0, -4(%rbp)
	addq	$16, %rsp
	popq	%rbp
	retq
	.cfi_endproc
                                        ## -- End function
	.p2align	4, 0x90         ## -- Begin function sancov.module_ctor_trace_pc_guard
_sancov.module_ctor_trace_pc_guard:     ## @sancov.module_ctor_trace_pc_guard
	.cfi_startproc
## %bb.0:
	pushq	%rax
	.cfi_def_cfa_offset 16
	leaq	p$start$__DATA$__sancov_guards(%rip), %rax
	leaq	p$end$__DATA$__sancov_guards(%rip), %rcx
	movq	%rax, %rdi
	movq	%rcx, %rsi
	callq	___sanitizer_cov_trace_pc_guard_init
	popq	%rax
	retq
	.cfi_endproc
                                        ## -- End function
	.p	__DATA,__sancov_guards
	.p2align	2               ## @__sancov_gen_
l___sancov_gen_:
	.space	4

	.p	__DATA,__mod_init_func,mod_init_funcs
	.p2align	3
	.quad	_sancov.module_ctor_trace_pc_guard
	.no_dead_strip	l___sancov_gen_
	.p	__DATA,__objc_imageinfo,regular,no_dead_strip
L_OBJC_IMAGE_INFO:
	.long	0
	.long	64

.subps_via_symbols

通過兩份檔案對比，我們可以發現經過 backend 流程后，___sanitizer_cov_trace_pc_guard 相關的呼叫才開始出現，

所以，我們可以得到第一個重要的結論：

在具有 bc 檔案 的情況下，就可以通過 backend 流程進行插樁處理，

再結合我們之前發過的公眾號文章：檢查第三方庫是否包含 bitcode 資訊，我們可以得到第二個結論：

通過匯出第三方庫的 bitcode，我們可以實作任意 cpu 架構下的插樁，

五、實戰

講解完基礎知識后，我們開始以 微信SDK（OpenSDK1.8.7.1）為例進行實際講解，

1、對微信SDK進行處理

檢測 微信SDK 的檔案型別

命令列輸入：

file ~/Downloads/OpenSDK1.8.7.1/libWeChatSDK.a

輸出如下：

~/Downloads/OpenSDK1.8.7.1/libWeChatSDK.a: Mach-O universal binary with 4 architectures: [i386:current ar archive] [arm_v7] [x86_64] [arm64]
~/Downloads/OpenSDK1.8.7.1/libWeChatSDK.a (for architecture i386): current ar archive
~/Downloads/OpenSDK1.8.7.1/libWeChatSDK.a (for architecture armv7): current ar archive
~/Downloads/OpenSDK1.8.7.1/libWeChatSDK.a (for architecture x86_64): current ar archive
~/Downloads/OpenSDK1.8.7.1/libWeChatSDK.a (for architecture arm64): current ar archive

因為 微信SDK包含多個架構，所以需要先用 lipo 命令匯出一份單架構檔案

lipo -thin armv7 ~/Downloads/OpenSDK1.8.7.1/libWeChatSDK.a -o ~/Downloads/OpenSDK1.8.7.1/libWeChatSDK_armv7.a

檢測單架構檔案的型別

命令列輸入：

file -b ~/Downloads/OpenSDK1.8.7.1/libWeChatSDK_armv7.a

輸出如下：

current ar archive

因為 libWeChatSDK_armv7.a 是 ar 檔案，通過 tar 命令解壓縮

tar -xf ~/Downloads/OpenSDK1.8.7.1/libWeChatSDK_armv7.a

產出12個 .o 檔案

tree
.
├── AppCommunicate.o
├── AppCommunicateData.o
├── WXApi+ExtraUrl.o
├── WXApi+HandleOpenUrl.o
├── WXApi.o
├── WXApiObject.o
├── WXLogUtil.o
├── WapAuthHandler.o
├── WeChatApiUtil.o
├── WeChatIdentityHandler.o
├── WechatAuthSDK.o
└── base64.o

0 directories, 12 files

依次判斷 .o 檔案的型別并進行處理命令列輸入：
```
file -b AppCommunicate.o
```
輸出：
```
Mach-O object arm_v7
```

通過 segedit 命令匯出 bitcode

segedit AppCommunicate.o -extract __LLVM __bitcode .AppCommunicate.bc

通過 clang 將 bitcode 轉為 .s 檔案

注意事項：

為了避免編譯器錯誤： fatal error: error in backend: Cannot select: intrinsic %llvm.objc.clang.arc.use，這里需要傳入 -O1 或者更高級別的優化開關，以啟用 -objc-arc-contract Pass
```
xcrun clang -O1 -target armv7-apple-ios7 -S AppCommunicate.bc -o AppCommunicate.s -fsanitize-coverage=trace-pc-guard -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.1.sdk
```

截取 AppCommunicate.s 部分內容如下：

Ltmp0:
	.loc	9 16 0 prologue_end     ; AppCommunicate/AppCommunicate.m:16:0
Lloh0:
	adrp	x0, l___sancov_gen_@PAGE
Ltmp1:
	;DEBUG_VALUE: +[AppCommunicate getDataPasteboardName]:self <- [DW_OP_LLVM_entry_value 1] $x0
Lloh1:
	add	x0, x0, l___sancov_gen_@PAGEOFF
	bl	___sanitizer_cov_trace_pc_guard
Ltmp2:
	;DEBUG_VALUE: +[AppCommunicate getDataPasteboardName]:_cmd <- [DW_OP_LLVM_entry_value 1] $x1

2、Demo

將處理后的檔案直接放到工程中：

3、運行

我們仍然用本文開頭的代碼進行演示，

如下所示，可以通過 console 區域看到微信SDK內部的執行流程

總結

首先，我們先回顧一下本文的重點知識：

代碼覆寫率 分為 函式（Fuction-Level)、基本塊（BasicBlock-Level）、邊界（Edge-Level） 三種級別，
llvm 編譯器 通過 SanitizerCoverage 支持以上三種級別的代碼覆寫率插樁，
通過匯出第三方庫的 bitcode，我們可以實作任意cpu架構下的插樁，

本文通過介紹 代碼覆寫率 、SanitizerCoverage 和 編譯流程 ，并以 微信SDK 為例，對如何實作第三方SDK插樁進行了詳細的講解，

參考資料

[1]

微信SDK（OpenSDK1.8.7.1): https://developers.weixin.qq.com/doc/oplatform/Downloads/iOS_Resource.html

[2]

dladdr: https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html

[3]

__builtin_return_address: https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html

[4]

SanitizerCoverage: https://releases.llvm.org/10.0.0/tools/clang/docs/SanitizerCoverage.html#instrumentation-points

上期獲獎名單公布

恭喜“蓋上被子的...”、“阿策~”、“beat you”！以上讀者請及時添加小編微信：sohu-tech20兌書~