通過在應用程序的安裝目錄中搜索一些關鍵字,我們實際上得到了兩個結果,它們含有混淆器名稱的信息:
NuDetectSDK 二進制文件也使用相同的混淆器,但它似乎沒有參與上圖所示的早期越獄檢測。另一方面,SingPass 是應用程序的主要二進制文件,我們可以觀察到與威脅檢測相關的字符串:
混淆器的名稱已被編輯,但不會影響代碼的内容。
不幸的是,二進制文件沒有洩漏其他字符串,這些字符串可以幫助識别應用程序檢測越獄設備的位置和方式,但幸運的是,應用程序沒有崩潰。
如果我們假設混淆器在運行時解密字符串,則可以嘗試在顯示錯誤消息時轉儲 __data 部分的内容。在執行時,用于檢測越獄設備的字符串可能已被解碼并清楚地存在于内存中。
1. 我們運行應用程序并等待越獄消息;
2. 我們使用 Frida 附加到 SingPass,并注入一個庫:
2.1 在内存中解析 SingPass 二進制文件;
2.2 轉儲 __data 部分的内容;
2.3 将轉儲寫入 iPhone 的 /tmp 目錄;
一旦數據區被轉儲,__data 部分會發生以下變化:
轉儲前後的 __data 部分
此外,我們可以觀察到以下字符串,它們似乎與混淆器的 RASP 功能有關:
與 RASP 功能相關的字符串
所有的 EVT_* 字符串都由一個且隻有一個我命名爲 on_rasp_detection 的函數引用。這個函數是應用程序開發者在觸發 RASP 事件時用來執行操作的威脅檢測回調函數。
爲了更好地理解這些字符串背後的檢查邏輯,讓我們從用于檢測挂鈎函數的 EVT_CODE_PROLOGUE 開始。
EVT_CODE_PROLOGUE:挂鈎檢測
當通過彙編代碼接近 on_rasp_detection 的交叉引用時,我們可以多次發現這種模式:
爲了檢測給定函數是否被鈎住,混淆器加載函數的第一個字節,并将該字節與值 0xFF 進行比較。乍一看,0xFF 似乎是任意的,但事實并非如此。實際上,常規函數以一個序言開始,該序言在堆棧上分配空間,以保存由調用約定定義的寄存器和函數所需的堆棧變量。在 AArch64 中,這個分配可以通過兩種方式執行:
這些指令是不相等的,如果偏移量存在,它們可能會導緻相同的結果。在第二種情況下,指令 sub SP、SP、#CST 用以下字節編碼:
正如我們所看到的,該指令的編碼從 0xFF 開始。如果不是這樣,那麽該函數要麽以不同的堆棧分配序言開始,要麽可能以一個挂鈎的蹦床開始。由于應用程序的代碼是通過混淆器的編譯器編譯的,因此編譯器能夠區分這兩種情況,并爲正确的函數的序言插入正确的檢查。
如果函數指令的第一個字節沒有通過檢查,則跳轉到紅色基本塊。這個基本塊的目的是觸發一個用戶定義的回調,它将根據應用程序的設計和開發人員的選擇來處理檢測:
打印錯誤
應用程序崩潰
破壞内部數據
……
從上圖中,我們可以觀察到檢測回調是從位于 #hook_detect_cbk_ptr 的靜态變量加載的。調用此檢測回調時,混淆器會向回調提供以下信息:
1. 檢測碼:EVT_CODE_PROLOGUE 爲 0x400;
2. 可能導緻應用程序崩潰的受攻擊指針;
現在讓我們仔細看看檢測回調的整體設計。
檢測回調
如上一節所述,當混淆器檢測到篡改時,它會通過調用存儲在地址的靜态變量中的檢測回調來做出反應:0x10109D760
通過靜态分析 hook_detect_cbk,實現似乎破壞了回調參數中提供的指針。另一方面,在運行應用程序時,我們觀察到越獄檢測消息,而不是應用程序崩潰。
如果我們查看在該地址讀取或寫入的交叉引用,我們會得到以下指令列表:
所以實際上隻有一條指令,init_and_check_rasp+01BC,用另一個函數覆蓋默認的檢測回調:
與默認回調相比:hook_detect_cbk(被覆蓋的函數)相比,hook_detect_cbk_user_def 不會損壞一個會導緻應用程序崩潰的指針。相反,它調用 on_rasp_detection 函數,該函數引用上圖中列出的所有字符串 EVT_CODE_TRACING、EVT_CODE_SYSTEM_LIB 等。
通過整體查看 init_and_check_rasp 函數,我們可以注意到 X23 寄存器也用于初始化其他靜态變量:
X23 寫入指令
這些内存寫入意味着回調 hook_detect_cbk_user_def 用于初始化其他靜态變量。特别是,這些其他靜态變量很可能用于其他 RASP 檢查。通過查看這些靜态變量 #EVT_CODE_TRACING_cbk_ptr、#EVT_ENV_JAILBREAK_cbk_ptr 等的交叉引用,我們可以找到執行其他 RASP 檢查的位置以及觸發它們的條件。
EVT_CODE_SYSTEM_LIB
EVT_ENV_DEBUGGER
EVT_ENV_JAILBREAK
多虧了 #EVT_* 交叉引用,我們可以靜态地通過使用這些 #EVT_* 變量的所有基本塊,并突出顯示可能觸發 RASP 回調的底層檢查。在詳細檢查之前,需要注意以下幾點:
1. 雖然應用程序使用了一個商業混淆器,除了 RASP 之外,還提供了本地代碼混淆,但代碼是輕度混淆的,這使得靜态彙編代碼分析非常容易。
2. 應用程序爲所有 RASP 事件設置相同的回調。因此,它簡化了 RASP 繞過和應用程序的動态分析。
反調試
SingPass 使用的混淆器版本實現了兩種調試檢查。首先,它檢查父進程 id ( ppid ) 是否與 /sbin/launchd 相同,後者應該爲 1。
getppid 通過函數或系統調用調用。
如果不是這種情況,它會觸發 EVT_ENV_DEBUGGER 事件。第二個檢查基于用于訪問 extern_proc.p_flag 值的 sysctl。如果此标志包含 P_TRACED 值,則 RASP 例程會觸發 EVT_ENV_DEBUGGER 事件。
在 SingPass 二進制中,我們可以在以下地址範圍内找到這兩個檢查的實例:
越獄檢測
對于大多數越獄檢測,混淆器會通過檢查設備上是否存在(或不存在)某些文件來嘗試檢測設備是否已越獄。
借助以下幫助程序,可以使用系統調用或常規函數檢查文件或目錄:
如上所述,我提到 __data 部分的轉儲顯示與越獄檢測相關的字符串,但轉儲并未顯示混淆器使用的所有字符串。
通過仔細研究字符串編碼機制,可以發現有些字符串是在臨時變量中即時解碼的。我将在本文的第二部分解釋字符串編碼機制,這樣,我們可以通過在 fopen、utimes 等函數上設置鈎子,并在這些調用之後立即轉儲 __data 部分來揭示字符串。然後,我們可以遍曆不同的轉儲,查看是否出現了新的字符串。
最後,該方法無法對所有字符串進行解碼,但可以實現良好的覆蓋。用于檢測越獄的文件列表在附件中給出。
還有一個檢測 unc0ver 越獄的特殊檢查,包括嘗試卸載 /.installed_unc0ver:
0x100E4D814: _unmount ( "/.installed_unc0ver" )
環境
混淆器還會檢查觸發 EVT_ENV_JAILBREAK 事件的環境變量。其中一些檢查似乎與代碼提升檢測有關,但仍會觸發 EVT_ENV_JAILBREAK 事件。
startswith ( )
從逆向工程的角度來看,startswith ( ) 實際上是作爲一個 "or-ed" 的 xor 序列來實現的,以得到一個布爾值。這可能是編譯器優化的結果。你可以在位于地址 0x100015684 的基本塊中觀察這個模式。
高級檢測
除了常規檢查之外,混淆器還執行高級檢查,比如驗證 SIP ( 系統完整性保護 ) 的當前狀态,更準确地說,是 KEXTS 代碼簽名狀态。
根據我在 iOS 越獄方面的經驗,我認爲沒有越獄會禁用 CSR_ALLOW_UNTRUSTED_KEXTS 标志。相反,我猜它是用來檢測應用程序是否在允許這種停用的 Apple M1 上運行。
Assembly range: 0x100004640 – 0x1000046B8
混淆器還使用 Sandbox API 來驗證是否存在某些路徑:
通過這個 API 檢查的路徑是 OSX 相關的目錄,所以我猜它也被用來驗證當前代碼沒有在 Apple Silicon 上被解除。例如,下面是使用 Sandbox API 檢查的目錄列表:
Assembly range: 0x100ED7684 ( function )
此外,它使用沙盒屬性 file-read-metadata 作爲 stat ( ) 函數的替代方案。
Assembly range: 0x1000ECA5C – 0x1000ECE54
該應用程序通過私有系統調用使用沙盒 API 來确定是否存在一些越獄工件。這是非常明智的做法,但我想這并不符合蘋果的安全政策。
代碼符号表
此檢查的目的是驗證已解析導入的地址是否指向正确的庫。換句話說,此檢查驗證導入表沒有被可用于挂鈎導入函數的指針篡改。
Initialization: part of sub_100E544E8
Assembly range: 0x100016FC4 – 0x100017024
在 RASP 檢查初始化 ( sub_100E544E8 ) 期間,混淆器會手動解析導入的函數。此手動解析是通過叠代 SingPass 二進制文件中的符号、檢查導入符号的庫、訪問(在内存中)此庫的 __LINKEDIT 段、解析導出 trie 等來執行的。此手動解析填充一個包含已解析符号的絕對地址的表。
此外,初始化例程設置遵循以下布局的元數據結構:
symbols_index 是一種轉換表,它将混淆器已知的索引轉換爲 __got 或 __la_symbol_ptr 部分中的索引。索引的來源(即 __got 或 __la_symbol_ptr)由包含類枚舉整數的 origins 表确定:
symbols_index 和 origins 這兩個表的長度都是由靜态變量 nb_symbols 定義的,它被設置爲 0x399。元數據結構後面跟着兩個指針:resolved_la_syms 和 resolved_got_syms,它們指向混淆器手動填充的導入地址表。
每個部分都有一個專用表:__got 和 __la_symbol_ptr。
然後,macho_la_syms 指向 __la_symbol_ptr 部分的開頭,而 macho_got_syms 指向 __got 部分。
最後,stub_helper_start / stub_helper_end 保存了 __stub_helper 部分的内存範圍。稍後我将介紹這些值的用途。
這個元數據結構的所有值都是在函數 sub_100E544E8 中進行初始化時設置的。
在 SingPass 二進制文件的不同位置,混淆器使用此元數據信息來驗證已解析導入的完整性。它首先訪問 symbols_index 和具有固定值的起源:
由于 symbols_index 表包含 uint32_t 值,#0xCA8 匹配 #0x32A ( 起源表的索引 ) 當除以 sizeof ( uint32_t ) : 0xCA8 = 0x32A * sizeof ( uint32_t ) 。
換句話說,我們有以下操作:
然後,給定 sym_idx 值并根據符号的來源,該函數訪問已解析的 __got 表或已解析的 __la_symbol_ptr 表。此訪問是通過位于 sub_100ED6CC0 的輔助函數完成的。可以用下面的僞代碼來概括:
比較 section_ptr 和 manual_resolved 的索引 sym_idx 處的條目,如果它們不匹配,則觸發事件 #EVT_CODE_SYMBOL_TABLE。
實際上,比較涵蓋了不同的情況。首先,混淆器處理 sym_idx 處的符号尚未解析的情況。在這種情況下,section_ptr [ sym_idx ] 指向位于 __stub_helper 部分中的符号解析存根。這就是元數據結構包含本節的内存範圍的原因:
另外,如果兩個指針不匹配,函數會使用 dladdr 來驗證它們的位置:
例如,如果導入的函數與 Frida 挂鈎,則兩個指針可能不匹配。
在 origin [ sym_idx ] 被設置爲 SYM_ORIGINS::NONE 的情況下,函數跳過檢查。因此,我們可以通過用 0 填充原始表來禁用這個 RASP 檢查。符号的數量接近元數據結構,元數據結構的地址是由 ___atomic_load 和 ___atomic_store 函數洩露的。
代碼跟蹤檢查
代碼跟蹤檢查旨在驗證當前沒有被跟蹤。通過查看 #EVT_CODE_TRACING_cbk_ptr 的交叉引用,我們可以識别出兩種驗證。
GumExecCtx
EVT_CODE_TRACING 似乎能夠檢測 Frida 的跟蹤檢查是否正在運行。這是我第一次觀察到這種檢查,非常聰明。對于那些想用原始彙編代碼進行分析的人,我将使用 SingPass 二進制文件中的這個地址範圍:0x10019B6FC – 0x10019B82C。
這是執行 Frida Stalker 檢查的函數圖:
與 Frida Stalker 檢測相關的代碼
是的,此代碼能夠檢測到 Stalker。讓我們從第一個基本塊開始。 _pthread_mach_thread_np ( _pthread_self ( ) ) 旨在獲取調用此檢查的函數的線程 ID。
然後更巧妙的是,MRS ( TPIDRRO_EL0 ) & #-8 用于手動訪問線程本地存儲區。在 ARM64 上,蘋果使用 TPIDRRO_EL0 的最低有效字節來存儲 CPU 的數量,而 MSB 包含 TLS 基地址。
然後,第二個基本塊(循環的入口)使用鍵 tlv_idx 訪問線程本地變量,在循環中取值範圍爲 0x100 到 0x200:
以下調用 _vm_region_64 ( ... ) 的基本塊用于驗證 tlv_addr 變量是否包含具有正确大小(即大于 0x30)的有效地址。在這些情況下,它會通過這些奇怪的内存訪問跳轉到以下基本塊:
觸發 EVT_CODE_TRACING 的條件
爲了弄清楚這些内存訪問的含義,我們有必要知道這個函數與 EVT_CODE_TRACING 事件相關聯。哪些知名的公共工具可以與代碼跟蹤相關聯?沒有太大的風險,我們可以假設存在 Frida Stalker。
如果我們查看 Stalker 的實現,我們會注意到在 gumstalker-arm64.c 中的這種初始化:
所以跟蹤者創建了一個線程局部變量,用于存儲 GumExecCtx 結構的指針,該結構具有以下布局:
如果我們添加這個布局的偏移量并且如果我們實際上内聯 GumArm64Writer 結構,我們可以得到這個表示:
由于編譯器強制對齊,destroy_pending_since 位于偏移量 0x08 而不是 0x04 處。
這樣一來,我們可以觀察到:
* ( tlv_table + 0x18 ) 有效匹配 GumThreadId thread_id 屬性;
* ( tlv_table + 0x24 ) 匹配 GumOS target_os;
* ( tlv_table + 0x28 ) 匹配 GumPtrauthSupport ptrauth_support;
GumOS 和 GumPtrauthSupport 是在 gumdefs.h 和 gummemory.h 中定義的枚舉,其值如下:
GumOS 包含 6 個條目,從 GUM_OS_WINDOWS = 0 到 GUM_OS_QNX = 5,這類似于 GUM_PTRAUTH_INVALID = 0,而最後一個條目與 GUM_PTRAUTH_SUPPORTED = 2 相關聯。
因此,前面的奇怪條件被用來對 GumExecCtx 結構進行指紋識别:
防止這種 Stalker 檢測的一種方法是使用 _GumExecCtx 結構中的交換字段重新編譯 Frida。