淺談Frida無痕Hook

0x0 前言

前段時間有大佬開源了一套名為wxshadow的無痕hook方案，它主要通過頁表的一些機制來實現，詳細實現推薦去看源碼，非常厲害的思路！！( 原文：「[原创]linux/android 利用shadow内存无痕hook方法」 )

wxshadow是一個提供了無痕patch接口的KPM模塊，而非一個可以開箱即用的hook框架，因此我就在想，能否把它集成到Frida中，給Frida裝上無痕Hook功能？本文簡單聊聊它的可行性。

0x1 一些內核知識

一些個人認為要先了解的內核知識，來自「《linux内核深度解析》余华兵」第三章。

1.1 統一的頁表框架

頁表用來把虛擬頁映射到物理頁，並且存放頁的保護位。

在Linux4.11版本之前，Linux內核把頁表分為四級：

頁全局目錄 ( Page Global Directory，PGD )
頁上層目錄 ( Page Upper Directory，PUD )
頁中間目錄 ( Page Middle Directory，PMD )
直接頁表 ( Page Table，PT ，表中的元素稱為Page Table Entry，簡稱PTE )

4.11版本把頁表擴展到五級，在PGD和PUD之間增加了頁四級目錄( Page 4th Directory，P4D )。

可以通過CONFIG_PGTABLE_LEVELS宏來配置頁表的級數，以我的P6為例，是3級頁表。

1 2	oriole:/ # zcat /proc/config.gz \| grep CONFIG_PGTABLE_LEVELS CONFIG_PGTABLE_LEVELS=3

每個進程有獨立的頁表，進程的mm_struct實例成員pgd指向全局目錄，前面四級頁表的表項存放下一級頁表的起始地址，直接頁表的表項存放頁幀號( Page Frame Number，PFN )。

頁幀號 + 頁內編移 = 物理地址

1.2 ARM64處理器頁表

ARM64把頁表稱為轉換表( translation table )，最多4級。

頁長度是4KB：使用4級轉換表，0級轉換表對應頁全局目錄，1級轉換表對應頁上層目錄，如此類推( 沒有P4D )。 48位虛擬地址被分解為如下所示：
頁長度是64KB：使用3級頁表，1級轉換表對應頁全局目錄，2級對應頁中間目錄，3級對應直接頁表。

ARM64把表項稱為描述符( descriptor )，長度為64位。描述符的第0位代表當前描述符是否有效，0表示無效，1表示有效。第1位指定描述符的類型，具體如下：

在0 ~ 2級轉換表中，0表示塊( block )描述符，存放一個內存塊( 即巨型頁 )的起始地址，1表示表( table )描述符，存放下一級轉換表的地址。
在第3級轉換表中，0表示保留，1表示頁描述符。

3級轉換表的頁描述符如下圖所示：

在塊描述符和頁描述符中，內存屬性被拆分成一個高屬性塊和一個低屬性塊，如下圖所示：

wxshadow利用了其中幾個關鍵屬性來實現：

第54位：在EL0中表示UXN( Unprivileged execute-Never )，即不允許EL0執行內核代碼；在其他異常級別，表示XN( execute-Never )，不允許執行。
第6 ~ 7位：AP[2:1]( Data Access Permissions，數據訪問權限 )。在階段1轉換中，AP[2]用來選擇只讀或讀寫，1表示只讀，0表示讀寫；AP[1]用來選擇是否允許EL0訪問，1表示允許，0表示不允許。在非異常級別1和0轉換機制的階段2轉換中，AP[2:1]為00表示不允許訪問，01表示只讀，10表示只寫，11表示讀寫。

1.3 巨型頁

當運行內存需求量較大的應用程序時，如果使用長度為4KB的頁，將會產生較多的TLB未命中和缺頁異常，大大影響應用程序的性能。而如果使用長度為2MB，什至更大的巨型頁，可以大幅改善此問題，這正是內核引入巨型頁( Huge Page )的直接原因。

ARM64支持巨型頁的方式有兩種：

通過塊描述符來支持
通過頁/塊描述符的連續位來支持

0x2 Frida集成wxshadow的可行性

wxshadow提供了PR_WXSHADOW_PATCH和PR_WXSHADOW_RELEASE，前者可以用於替代frida的patch行為，後者用於清理現場。

// wxshadow_bp.c
case PR_WXSHADOW_PATCH:
    pid = (pid_t)arg2;
    mm = resolve_pid_to_mm(pid);
    if (!mm) { args->ret = -3; args->skip_origin = 1; break; }
    ret = wxshadow_do_patch(mm, arg3, (void __user *)arg4, arg5);
    kfunc_mmput(mm);
    args->ret = ret;
    args->skip_origin = 1;
    break;

case PR_WXSHADOW_RELEASE:
    pid = (pid_t)arg2;
    mm = resolve_pid_to_mm(pid);
    if (!mm) { args->ret = -3; args->skip_origin = 1; break; }
    if (arg3 == 0) {
        ret = wxshadow_release_pages_for_mm(mm, "release_all");
    } else {
        ret = wxshadow_do_release(mm, arg3);
    }
    kfunc_mmput(mm);
    args->ret = ret;
    args->skip_origin = 1;
    break;

實際嘗試時，遇到了兩個問題。

問題一：會發生livelock的情況。

原因是Frida hook會把目標地址patch成如下形式，用到了arm64的ldr literal技術( 代碼 / 數據在相鄰位置 )。

1
2
3

ldr x16, [pc, #8]
br  x16
.dword on_enter_trampoline

若PR_WXSHADOW_PATCH時仍然是按這種形式來patch，會導致livelock ( APP卡死 )

因為wxshadow本質上維護了original(r--)( 讀 )和wxshadow(--x)( 執行 )兩種視圖，當wxshadow直接套用到上述patch中，就會發生以下情況：

; 當前視圖: wxshadow(--x)
exec: ldr x16, [pc, #8]
; 觸發read fault, 切換到original(r--)
read: on_enter_trampoline
; 讀完後, 回到ldr指令, 觸發exec fault, 切換到wxshadow(--x)
exec: ldr x16, [pc, #8]

; 死循環...

而wxshadow的作用範圍是一整頁，因此對同頁下的ldr literal也要做處理。

問題二：wxshadow無法對libart.so大部份函數進行hook。

這與libart.so在某次更新時改用巨型頁( Huge PMD )有關，而wxshadow是以PTE為單位進行管理，雖然其中有對巨型頁做處理，但測試下來發現是不夠的。

// https://android.googlesource.com/platform/art/+/07ff2833c7
Compile libart.so and libart-compiler.so with 2MB section alignment.

Adds the appropriate linker flags for libart and libart-compiler to have
2MB section alignment. This allows the executable segment of these
libraries to be backed by transparent hugepages on supporting systems.

解決思路是手動把2MB的PMD分割成512個4KB的PTE，實測可行。

基於wxshadow提供能力，能很好地隱藏Frida本身的一些特徵：

默認hook行為：以Frida16.5.9為例，默認會hook libc.so、libselinux.so和libandroid_runtime.so，用到Java相關API時，會hook libart.so。注：之後的某個版本開始還會默認hook linker
maps特徵：啟動一次frida-server後，maps特徵( rwxp段、N段的libc.so等 )會永久留下，即使關掉frida-server也無用，必須要重開機才行。原因是frida-server的那些默認hook行為是對zygote進程做的，而zygote進程是所有APP進程的父進程。

除此之外，Frida還有memfd、注入線程等特徵，可以在內核層做繞過。

總結：Frida集成wxshadow是完全可行的，遇到的各種問題基本都有解法。