一、 概述
經(jīng)過實際項目大量測試驗證，F(xiàn)astHook表現(xiàn)出了遠超YAHFA的優(yōu)異穩(wěn)定性。用戶反饋未出現(xiàn)Hook引發(fā)的穩(wěn)定性問題、壓力測試也未發(fā)生Hook引發(fā)的穩(wěn)定問題。之所以FastHook擁有優(yōu)異的穩(wěn)定性，除了框架實現(xiàn)原理的優(yōu)越性之外，還得益于FastHook出色的細節(jié)處理。
本文將通過FastHook實現(xiàn)原理優(yōu)越性與一些出色的細節(jié)處理來解釋為何FastHook擁有優(yōu)異的穩(wěn)定性，最后對比YAHFA框架。
二、先天優(yōu)勢
如果你還未了解FastHook，請移步FastHook——一種高效穩(wěn)定、簡潔易用的Android Hook框架。
FastHook相較YAHFA原理上最大的優(yōu)勢、也是最大的亮點便是：不需要備份原方法！不需要備份原方法！不需要備份原方法！
科學上有一個著名的“奧卡姆剃刀定律”，什么意思呢？如果一個現(xiàn)象有兩個或者多個不同的理論解釋，那么選最簡單的那個。做Hook框架，也可以用剃刀定律來做指導：實現(xiàn)相同的功能，選對系統(tǒng)狀態(tài)改動最小的。
“備份原方法”是一種隱患頗多的方式，引發(fā)了諸如方法解析出錯、Moving GC空指針等問題。盡管其他框架通過一些手段來提高穩(wěn)定性，比如保證方法不被再次解析、檢查Moving GC是否移動了原方法相關(guān)對象等，但是這些都不是理論安全的，就像地上有個坑，你不去補上，而是讓人不要去踩。
反觀FastHook，Hook時對系統(tǒng)原有狀態(tài)的改變是最小的。
- Inline模式改變的僅是幾個字節(jié)的指令，因平臺而異，不篡改任何方法。
- EntryPoint模式替換了方法EntryPoint，但是原方法將強制為解釋執(zhí)行，也可等價的看為未做修改。
簡而言之，F(xiàn)astHook就是用Hook方法hook原方法，原方法hook Forward方法來實現(xiàn)最小改動hook。完美地從實現(xiàn)層面解決了YAHFA不能解決的問題，而且無需做一些其他操作，其他框架都需要一些其他的操作來提高穩(wěn)定性，而FastHook不需要做任何其他處理，更簡潔、更優(yōu)雅。
三、比YAHFA更出色的細節(jié)處理
3.1 JIT狀態(tài)檢查
如果你看過YAHFA代碼，你會發(fā)現(xiàn)沒有一個框架做了JIT狀態(tài)檢查。JIT狀態(tài)檢查的目的是為了保證hook的安全性，但這也不是理論安全的，也無法做到理論安全。這是為什么呢？
3.1.1 Inline模式
如果原方法未編譯則需要進行手動JIT編譯。那么問題來了，什么時候編譯才是安全的呢。下面列舉出所有可能出現(xiàn)的情景:
- 原方法未進行JIT編譯，此時手動JIT編譯時安全的
- 原方法未進行JIT編譯，即將進入編譯等待隊列或已進入編譯等待隊列，此時手動JIT編譯是不安全的
- 原方法正在JIT編譯，此時手動JIT編譯是不安全的
- 原方法編譯完成，此時手動編譯是安全的
上述4中情景，其中2、3是不安全的。如果要保證手動JIT編譯的安全性，必須做到以下兩點：
- 禁止JIT編譯，防止從1變化到2
- 能夠判斷2、3，當處于2、3狀態(tài)時，等待其變化到4
現(xiàn)在來看看FastHook到底是怎么處理的
int CheckJitState(JNIEnv *env, jclass clazz, jobject target_method) {
void *art_method = (void *)(*env)->FromReflectedMethod(env, target_method);
//添加kAccCompileDontBother，禁止JIT、AOT編譯
AddArtMethodAccessFlag(art_method, kAccCompileDontBother);
uint32_t hotness_count = GetArtMethodHotnessCount(art_method);
if(hotness_count >= kHotMethodThreshold) {
//hotness_count >= hot_threshold，肯定就不是1了，看看是2、3、4中的哪一個
long entry_point = (long)GetArtMethodEntryPoint(art_method);
if((void *)entry_point == art_quick_to_interpreter_bridge_) {
void *profiling = GetArtMethodProfilingInfo(art_method);
void *save_entry_point = GetProfilingSaveEntryPoint(profiling);
if(save_entry_point) {
//JIT垃圾回收會改變方法EntryPoint，雖然方法已經(jīng)編譯了，但是EntryPoint也可能是art_quick_to_interpreter_bridge
return kCompile;
}else {
//JIT狀態(tài)保存在profiling中，通過其來判斷是否是正在編譯，如果不是可能是正在等待或者已經(jīng)編譯失敗。
bool being_compiled = GetProfilingCompileState(profiling);
if(being_compiled) {
return kCompiling;
}else {
return kCompilingOrFailed;
}
}
}
return kCompile;
}else {
//hotness_count < hot_threshold，可能是1，也可能是2，即將進入編譯等待隊列，統(tǒng)一加一個增量，如果此時大于hot_threshold，就認為是2，反之是1
uint32_t assumed_hotness_count = hotness_count + kHotMethodMaxCount;
if(assumed_hotness_count > kHotMethodThreshold) {
return kCompiling;
}
}
return kNone;
}
class ProfilingInfo {
private:
ProfilingInfo(ArtMethod* method, const std::vector<uint32_t>& entries);
// Number of instructions we are profiling in the ArtMethod.
const uint32_t number_of_inline_caches_;
// Method this profiling info is for.
// Not 'const' as JVMTI introduces obsolete methods that we implement by creating new ArtMethods.
// See JitCodeCache::MoveObsoleteMethod.
ArtMethod* method_;
// Whether the ArtMethod is currently being compiled. This flag
// is implicitly guarded by the JIT code cache lock.
// TODO: Make the JIT code cache lock global.
bool is_method_being_compiled_;
bool is_osr_method_being_compiled_;
// When the compiler inlines the method associated to this ProfilingInfo,
// it updates this counter so that the GC does not try to clear the inline caches.
uint16_t current_inline_uses_;
// Entry point of the corresponding ArtMethod, while the JIT code cache
// is poking for the liveness of compiled code.
const void* saved_entry_point_;
// Dynamically allocated array of size `number_of_inline_caches_`.
InlineCache cache_[0];
};
- AddArtMethodAccessFlag(art_method, kAccCompileDontBother)，設置kAccCompileDontBother禁止JIT、AOT。防止1變化到2。
- 如果hotness_count > hot_threshold，這時肯定就不是1了，還需要判斷是2、3、4中哪一個。
- 通過判斷entry point是否為解釋執(zhí)行入口來判斷是否是4，因為entry point不是解釋執(zhí)行入口肯定不會是2和3。
- 這里有個關(guān)鍵點一定要注意，即使JIT編譯后entry point也有可能為解釋執(zhí)行入口，因為JIT垃圾回收會將entry point設置為解釋執(zhí)行入口，將實際入口保存在save_entry_point。如果save_entry_point不為空，那證明已經(jīng)編譯過了。
- 怎么判斷2、3呢？每個方法都有一個profiling info，保存一些運行過程信息和JIT編譯信息，其中就有是否在JIT編譯的信息。如果為true，則為3，如果為false，則為2（這里也可能是編譯失敗了的，為了簡便都做2看待）
- 如果hotness_count < hot_threshold，能說明一定是1嗎？答案是不能，也有可能是2。這是為什么呢？有一種罕見的情況，當我們檢查狀態(tài)時，hotness_count還未執(zhí)行到更新的代碼，而當其更新之后大于hot_threshold，那么實際就是2。因此假設hotness_count會更新，給一個增量（理論上給不了準確的數(shù)值，因為其增量受權(quán)重影響，也可能是批量處理的增量，因此這不是理論安全的），這里給一個比較大的值（50），如果此時大于hot_threshold，就認為是2（這個也不是完全準確的，因為可能hotness_count根本不會更新）。
3.1.2 小結(jié)
- hook之前先做JIT狀態(tài)檢查，如果安全就立即hook，反之放入一個異步隊列延遲hook
- 上述分析可知，該檢查也不是絕對安全的，但是已經(jīng)將出現(xiàn)問題的場景縮小到一個可以忽略不計的范圍。
- EntrypPoint替換模式的檢查與Inline模式一致，不做重復分析。
3.2 判斷方法是否需要編譯
如果只是簡單用entry point與解釋入口比較來判斷，通過3.1的分析可知這是不完備的。
JIT垃圾回收會改變entry point為解釋入口，必須做進一步判斷是否為JIT編譯方法。FastHook的做法很簡單，判斷hotness_count是否小于hot_threshold，如果其小于hot_threshold，那肯定還未被JIT編譯，因此可以判定其需要進行手動JIT編譯。
并且，這一步是在JIT檢查成功基礎上進行的，可以不用擔心JIT狀態(tài)的影響。
bool IsCompiled(JNIEnv *env, jclass clazz, jobject method) {
bool ret = false;
void *art_method = (void *)(*env)->FromReflectedMethod(env, method);
void *method_entry = (void *)ReadPointer((unsigned char *)art_method + kArtMethodQuickCodeOffset);
int hotness_count = GetArtMethodHotnessCount(art_method);
if(method_entry != art_quick_to_interpreter_bridge_)
ret = true;
if(!ret && hotness_count >= kHotMethodThreshold)
ret = true;
return ret;
}
3.3 線程狀態(tài)恢復
當一個java方法進入JNI時，線程狀態(tài)由runnable狀態(tài)變?yōu)閚ative狀態(tài)，返回java前恢復為runable狀態(tài)。而JIT編譯方法會將參數(shù)thread的狀態(tài)轉(zhuǎn)變?yōu)閞unnable狀態(tài)。
最開始在手動JIT編譯方法時不做其他處理。但是后來項目上有反饋，有概率出現(xiàn)crash，出現(xiàn)的位置正好是編譯完成后返回java的地方，異常原因是線程狀態(tài)錯誤。
FastHook之前的解決方案是：新建native線程用于JIT編譯，避免當前線程編譯。這時出現(xiàn)了新的問題，如何獲取native線程的thread對象？
通過研究android代碼發(fā)現(xiàn)，art獲取線程thread對象是通過TLS來獲取的，thread存儲在TLS固定位置。但實際上，這種方案雖然解決了crash的問題，但也導致了新的問題：線程錯誤地等待。
究其緣由，都是線程狀態(tài)異常引起的，因此根治的方法便是恢復線程狀態(tài)。通過研究Thread代碼發(fā)現(xiàn)，線程狀態(tài)是一個union結(jié)構(gòu)體StateAndFlags，保存在thread對象里，因此可以通過偏移的方式來訪問。
static inline void *CurrentThread() {
return __get_tls()[kTLSSlotArtThreadSelf];
}
#if defined(__aarch64__)
# define __get_tls() ({ void** __val; __asm__("mrs %0, tpidr_el0" : "=r"(__val)); __val; })
#elif defined(__arm__)
# define __get_tls() ({ void** __val; __asm__("mrc p15, 0, %0, c13, c0, 3" : "=r"(__val)); __val; })
#endif
class Thread {
union PACKED(4) StateAndFlags {
struct PACKED(4) {
volatile uint16_t flags;
volatile uint16_t state;
} as_struct;
AtomicInteger as_atomic_int;
volatile int32_t as_int;
};
struct PACKED(4) tls_32bit_sized_values {
typedef uint32_t bool32_t;
union StateAndFlags state_and_flags;
int suspend_count GUARDED_BY(Locks::thread_suspend_count_lock_);
int debug_suspend_count GUARDED_BY(Locks::thread_suspend_count_lock_);
uint32_t thin_lock_thread_id;
uint32_t tid;
const bool32_t daemon;
bool32_t throwing_OutOfMemoryError;
uint32_t no_thread_suspension;
uint32_t thread_exit_check_count;
bool32_t handling_signal_;
bool32_t is_transitioning_to_runnable;
bool32_t ready_for_debug_invoke;
bool32_t debug_method_entry_;
bool32_t is_gc_marking;
Atomic<bool32_t> interrupted;
bool32_t weak_ref_access_enabled;
uint32_t disable_thread_flip_count;
int user_code_suspend_count GUARDED_BY(Locks::thread_suspend_count_lock_);
} tls32_;
bool CompileMethod(JNIEnv *env, jclass clazz, jobject method) {
bool ret = false;
void *art_method = (void *)(*env)->FromReflectedMethod(env, method);
void *thread = CurrentThread();
int old_flag_and_state = ReadInt32(thread);
ret = jit_compile_method_(jit_compiler_handle_, art_method, thread, false);
memcpy(thread,&old_flag_and_state,4);
return ret;
}
3.4 指令檢查
Inline模式下需要注入代碼，那么就必須確保被覆蓋的指令不包含pc相關(guān)的指令。
這是為什么呢？pc寄存器存儲的是當前執(zhí)行的指令，如果以pc寄存器來做尋址就跟當前地址息息相關(guān)了，如果我們覆蓋的指令包含pc相關(guān)的指令，那么尋址將出錯。
需要注意的是，Thumb2有16位和32位兩種指令，因此對于Thumb2指令集還需額外判斷指令類型。
static inline bool IsThumb32(uint16_t inst, bool little_end) {
if(little_end) {
return ((inst & 0xe000) == 0xe000 && (inst & 0x1800) != 0x0000);
}
return ((inst & 0x00e0) == 0x00e0 && (inst & 0x0018) != 0x0000);
}
static inline bool HasThumb16PcRelatedInst(uint16_t inst) {
uint16_t mask_b1 = 0xf000;
uint16_t op_b1 = 0xd000;
uint16_t mask_b2_adr_ldr = 0xf800;
uint16_t op_b2 = 0xe000;
uint16_t op_adr = 0xa000;
uint16_t op_ldr = 0x4800;
uint16_t mask_bx = 0xfff8;
uint16_t op_bx = 0x4778;
uint16_t mask_add_mov = 0xff78;
uint16_t op_add = 0x4478;
uint16_t op_mov = 0x4678;
uint16_t mask_cb = 0xf500;
uint16_t op_cb = 0xb100;
if((inst & mask_b1) == op_b1)
return true;
if((inst * mask_b2_adr_ldr) == op_b2 || (inst * mask_b2_adr_ldr) == op_adr || (inst * mask_b2_adr_ldr) == op_ldr)
return true;
if((inst & mask_bx) == op_bx)
return true;
if((inst & mask_add_mov) == op_add || (inst & mask_add_mov) == op_mov)
return true;
if((inst & mask_cb) == op_cb)
return true;
return false;
}
static inline bool HasThumb32PcRelatedInst(uint32_t inst) {
uint32_t mask_b = 0xf800d000;
uint32_t op_blx = 0xf000c000;
uint32_t op_bl = 0xf000d000;
uint32_t op_b1 = 0xf0008000;
uint32_t op_b2 = 0xf0009000;
uint32_t mask_adr = 0xfbff8000;
uint32_t op_adr1 = 0xf2af0000;
uint32_t op_adr2 = 0xf20f0000;
uint32_t mask_ldr = 0xff7f0000;
uint32_t op_ldr = 0xf85f0000;
uint32_t mask_tb = 0xffff00f0;
uint32_t op_tbb = 0xe8df0000;
uint32_t op_tbh = 0xe8df0010;
if((inst & mask_b) == op_blx || (inst & mask_b) == op_bl || (inst & mask_b) == op_b1 || (inst & mask_b) == op_b2)
return true;
if((inst & mask_adr) == op_adr1 || (inst & mask_adr) == op_adr2)
return true;
if((inst & mask_ldr) == op_ldr)
return true;
if((inst & mask_tb) == op_tbb || (inst & mask_tb) == op_tbh)
return true;
return false;
}
static inline bool HasArm64PcRelatedInst(uint32_t inst) {
uint32_t mask_b = 0xfc000000;
uint32_t op_b = 0x14000000;
uint32_t op_bl = 0x94000000;
uint32_t mask_bc = 0xff000010;
uint32_t op_bc = 0x54000000;
uint32_t mask_cb = 0x7f000000;
uint32_t op_cbz = 0x34000000;
uint32_t op_cbnz = 0x35000000;
uint32_t mask_tb = 0x7f000000;
uint32_t op_tbz = 0x36000000;
uint32_t op_tbnz = 0x37000000;
uint32_t mask_ldr = 0xbf000000;
uint32_t op_ldr = 0x18000000;
uint32_t mask_adr = 0x9f000000;
uint32_t op_adr = 0x10000000;
uint32_t op_adrp = 0x90000000;
if((inst & mask_b) == op_b || (inst & mask_b) == op_bl)
return true;
if((inst & mask_bc) == op_bc)
return true;
if((inst & mask_cb) == op_cbz || (inst & mask_cb) == op_cbnz)
return true;
if((inst & mask_tb) == op_tbz || (inst & mask_tb) == op_tbnz)
return true;
if((inst & mask_ldr) == op_ldr)
return true;
if((inst & mask_adr) == op_adr || (inst & mask_adr) == op_adrp)
return true;
return false;
}
主要是幾類指令：
- 分支跳轉(zhuǎn)指令
- 比較分支指令
- 條件分支指令
- load指令
而Thumb2需要特別注意，因為其有16位和32位兩種模式，而跳轉(zhuǎn)指令長度是8字節(jié)，如果固定復制8字節(jié)，有可能會把指令截斷，例如4-2-4，最后4字節(jié)指令將會被截斷，因此需要做判斷，以確定需要復制8字節(jié)還是10字節(jié)
int original_prologue_len = 0;
while(original_prologue_len < jump_trampoline_len) {
if(IsThumb32(ReadInt16((unsigned char *)target_code + original_prologue_len),IsLittleEnd())) {
original_prologue_len += 4;
}else {
original_prologue_len += 2;
}
}
3.5 指令注入
Inline模式下，需要向目標方法代碼段注入一段跳轉(zhuǎn)指令，而代碼段是不可寫。一般解決方案是使用mprotect修改訪問權(quán)限。
而從實際項目測試來看，mprotect可能是無效的。mprotect執(zhí)行成功了，但是還是出現(xiàn)了SEGV_ACCERR。
FastHook的解決方案是先捕獲出錯信號，再使用mprotect修改訪問權(quán)限。如果修改無效，則一直會修改直到生效為止。指令注入后恢復默認信號處理。捕獲信號處理之后，再無crash的反饋。
void SignalHandle(int signal, siginfo_t *info, void *reserved) {
ucontext_t* context = (ucontext_t*)reserved;
void *addr = (void *)context->uc_mcontext.fault_address;
if(sigaction_info_->addr == addr) {
void *target_code = sigaction_info_->addr;
int len = sigaction_info_->len;
long page_size = sysconf(_SC_PAGESIZE);
unsigned alignment = (unsigned)((unsigned long long)target_code % page_size);
int ret = mprotect((void *) (target_code - alignment), (size_t) (alignment + len),
PROT_READ | PROT_WRITE | PROT_EXEC);
}
}
sigaction_info_->addr = target_code;
sigaction_info_->len = original_prologue_len;
if(current_handler_ == NULL) {
default_handler_ = (struct sigaction *)malloc(sizeof(struct sigaction));
current_handler_ = (struct sigaction *)malloc(sizeof(struct sigaction));
memset(default_handler_, 0, sizeof(sigaction));
memset(current_handler_, 0, sizeof(sigaction));
current_handler_->sa_sigaction = SignalHandle;
current_handler_->sa_flags = SA_SIGINFO;
sigaction(SIGSEGV, current_handler_, default_handler_);
}else {
sigaction(SIGSEGV, current_handler_, NULL);
}
memcpy(target_code, jump_trampoline, jump_trampoline_len);
sigaction_info_->addr = NULL;
sigaction_info_->len = 0;
sigaction(SIGSEGV, default_handler_, NULL);
3.6 注入安全
在獲得寫權(quán)限之后，注入的時候必須保證沒有其他線程同時讀需要注入的區(qū)域，不然將導致未知錯誤。
可以利用art暫停所用線程和恢復所有線程的接口來實現(xiàn)。FastHook并沒有采用這種方式，stop the world這種方式太重了，對性能有損耗。
FastHook是怎么做的呢？很簡單，強制需要注入的方法解釋執(zhí)行，注入完成后恢復。即保證了注入安全，也沒有任何性能損失。
memcpy((unsigned char *) art_target_method + kArtMethodQuickCodeOffset,&art_quick_to_interpreter_bridge_,pointer_size_);
memcpy(target_code, jump_trampoline, jump_trampoline_len);
memcpy((unsigned char *) art_target_method + kArtMethodQuickCodeOffset,&target_entry,pointer_size_);
3.7 EntryPoint替換安全
EntryPoint替換模式要求原方法以解釋模式執(zhí)行，而JIT垃圾回收會更改方法entry point為解釋執(zhí)行入口，當方法即將進入解釋執(zhí)行時會重新設置為原來的入口，這會導致什么問題呢？
java方法有兩種執(zhí)行模式，一種執(zhí)行dex字節(jié)碼，一種執(zhí)行機器碼，art因此需要知道機器碼與dex字節(jié)碼的映射關(guān)系，例如執(zhí)行一條機器碼，它對應哪一條dex字節(jié)碼。而這些映射需要方法entry point作為基址來計算，此時entry point已經(jīng)被替換，會得出錯誤的結(jié)果。
因此，如果監(jiān)測到上述情況，需要修改save_entry_point為解釋執(zhí)行入口，防止執(zhí)行JIT編譯的機器碼。
if(art_forward_method) {
memcpy((unsigned char *) target_trampoline + hook_trampoline_target_index, &art_target_method, pointer_size_);
memcpy((unsigned char *) target_trampoline + target_trampoline_target_entry_index, &target_entry, pointer_size_);
if(kTLSSlotArtThreadSelf) {
uint32_t hotness_count = GetArtMethodHotnessCount(art_target_method);
if(hotness_count >= kHotMethodThreshold) {
void *profiling = GetArtMethodProfilingInfo(art_target_method);
void *save_entry_point = GetProfilingSaveEntryPoint(profiling);
if(save_entry_point) {
SetProfilingSaveEntryPoint(profiling,art_quick_to_interpreter_bridge_);
}
}
}
}
四、與其他框架比較
4.1 YAHFA
| 框架 | 備份原方法 | 性能 | JIT狀態(tài)檢查 | EntryPoint檢查（JIT） | 線程狀態(tài)恢復 | 指令檢查 | mprotect失效處理 | 注入安全 | 防止內(nèi)聯(lián) | 防止backup/forword內(nèi)聯(lián) |
|---|---|---|---|---|---|---|---|---|---|---|
| YAHFA | 是 | 高 | 否 | - | - | - | - | - | 否 | 否 |
| FastHook | 否 | 高 | 是 | 是 | 是 | 是 | 是 | 是（高效） | JIT內(nèi)聯(lián) | 是 |
4.4 小結(jié)
從上述對比可以看出，F(xiàn)astHook與YAHFA的本質(zhì)區(qū)別是不備份原方法，在細節(jié)上的處理也比其他框架要嚴謹、高效，YAHFA在細節(jié)處理上都有所欠缺。
五、結(jié)語
由于項目原因，主要維護arm平臺，其他平臺暫時不支持，后續(xù)再計劃加入，目前主要關(guān)注arm平臺的穩(wěn)定性。如果有興趣，對穩(wěn)定性有要求的朋友，歡迎使用，本項目長期維護。
FastHook系列
FastHook——一種高效穩(wěn)定、簡潔易用的Android Hook框架
FastHook——巧妙利用動態(tài)代理實現(xiàn)非侵入式AOP
如何使用FastHook免root hook微信
FastHook——實現(xiàn).dynsym段和.symtab段符號查詢
