通過在應用程序的安裝目錄中搜索一些關鍵字，我們實際上得到了兩個結果，它們含有混淆器名稱的信息：

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_DEBUGGEREVT_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 ( "/.installedunc0ver" )

環境

混淆器還會檢查觸發 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。