在 XNU 内核上查找某个函数的指针的最佳方法是什么?
What would be the best approach patch-finding the pointer of a certain function on the XNU Kernel?
我目前正在为 iOS 13.7 进行 iOS 越狱。
作为越狱的一部分,我需要对内存中的 XNU 内核进行一系列修补。
当然,内核受到 kASLR
、KPP
/ KTRR
和其他内存看门狗的保护,如果某些内容被修改,这些看门狗会触发内核恐慌。
幸运的是,KTRR
(内核文本只读区域)只能保护不应更改的静态数据(即 TEXT
部分和常量)。变量仍然可以改变。
我正在构建一个 PatchFinder,它应该根据指示符号在 XNU 内存中定位一个函数或变量,我想知道什么是最有效的方法。
我目前正在 PatchFinder made publicly available 之上进行调整,回到 iOS 8 时代 in7egal
看起来像这样:
uint32_t find_cs_enforcement_disable_amfi(uint32_t region, uint8_t* kdata, size_t ksize)
{
// Find a function referencing cs_enforcement_disable_amfi
const uint8_t search_function[] = {0x20, 0x68, 0x40, 0xF4, 0x40, 0x70, 0x20, 0x60, 0x00, 0x20, 0x90, 0xBD};
uint8_t* ptr = memmem(kdata, ksize, search_function, sizeof(search_function));
if(!ptr)
return 0;
// Only LDRB in there should try to dereference cs_enforcement_disable_amfi
uint16_t* ldrb = find_last_insn_matching(region, kdata, ksize, (uint16_t*) ptr, insn_is_ldrb_imm);
if(!ldrb)
return 0;
// Weird, not the right one.
if(insn_ldrb_imm_imm(ldrb) != 0 || insn_ldrb_imm_rt(ldrb) > 12)
return 0;
// See what address that LDRB is dereferencing
return find_pc_rel_value(region, kdata, ksize, ldrb, insn_ldrb_imm_rn(ldrb));
}
我想知道是否有更快或更可靠的方法来定位 cs_enforcement_disable_amfi
。
一旦被PatchFinder在XNU Kernel内存中找到,就这样使用:
uint32_t cs_enforcement_disable_amfi = find_cs_enforcement_disable_amfi(kernel_base, kdata, ksize);
printf("cs_enforcement_disable_amfi is at=0x%08x\n",cs_enforcement_disable_amfi);
if (cs_enforcement_disable_amfi){
char patch[] ="\x00\xbf\x00\xbf\x00\xbf\x00\xbf\x00\xbf";
kern_return_t kernret = vm_write(proccessTask, cs_enforcement_disable_amfi+kernel_base, patch, sizeof(patch)-1);
if (kernret == KERN_SUCCESS){
printf("Successfully patched cs_enforcement_disable_amfi\n");
}
}
因此 PatchFinder 必须能够可靠地 return 指向 cs_enforcement_disable_amfi
的指针,否则我将盲目地写入无效(或有效但不同)的地址,这几乎肯定会触发内存损坏。
大多数时候,当前代码确实 return 一个指向 cs_enforcement_disable_amfi
的有效指针,但大约有 10-15% 的时间随机使内核恐慌,这意味着它的地址 returns 10-15% 的时间是无效的。不确定如何让它更可靠。
您要查找的变量已不存在。
你的第一个片段中的字节组成了 Thumb 指令,它在 32 位内核缓存的 AMFI 中找到这个函数:
0x8074ad04 90b5 push {r4, r7, lr}
0x8074ad06 01af add r7, sp, 4
0x8074ad08 0d48 ldr r0, [0x8074ad40]
0x8074ad0a 7844 add r0, pc
0x8074ad0c 0078 ldrb r0, [r0]
0x8074ad0e 0128 cmp r0, 1
0x8074ad10 03d1 bne 0x8074ad1a
0x8074ad12 0020 movs r0, 0
0x8074ad14 00f04efa bl 0x8074b1b4
0x8074ad18 30b9 cbnz r0, 0x8074ad28
0x8074ad1a 7c69 ldr r4, [r7, 0x14]
0x8074ad1c 002c cmp r4, 0
0x8074ad1e 05d0 beq 0x8074ad2c
0x8074ad20 2068 ldr r0, [r4]
0x8074ad22 40f44070 orr r0, r0, 0x300
0x8074ad26 2060 str r0, [r4]
0x8074ad28 0020 movs r0, 0
0x8074ad2a 90bd pop {r4, r7, pc}
考虑到魔术常数 0x300
和 AMFI 的 __TEXT_EXEC
段非常小的事实,我们可以很容易地在其他内核中找到它,包括 64 位内核。
这是 8.4 上 iPhone 5s 的样子:
0xffffff800268d2e4 f44fbea9 stp x20, x19, [sp, -0x20]!
0xffffff800268d2e8 fd7b01a9 stp x29, x30, [sp, 0x10]
0xffffff800268d2ec fd430091 add x29, sp, 0x10
0xffffff800268d2f0 f30307aa mov x19, x7
0xffffff800268d2f4 e8fc1110 adr x8, section.com.apple.driver.AppleMobileFileIntegrity.10.__DATA.__bss
0xffffff800268d2f8 1f2003d5 nop
0xffffff800268d2fc 08054039 ldrb w8, [x8, 1]
0xffffff800268d300 a8000037 tbnz w8, 0, 0xffffff800268d314
0xffffff800268d304 130100b4 cbz x19, 0xffffff800268d324
0xffffff800268d308 680240b9 ldr w8, [x19]
0xffffff800268d30c 08051832 orr w8, w8, 0x300
0xffffff800268d310 680200b9 str w8, [x19]
0xffffff800268d314 00008052 mov w0, 0
0xffffff800268d318 fd7b41a9 ldp x29, x30, [sp, 0x10]
0xffffff800268d31c f44fc2a8 ldp x20, x19, [sp], 0x20
0xffffff800268d320 c0035fd6 ret
但是到 iOS11 时,变量消失了:
0xfffffff006245d84 f44fbea9 stp x20, x19, [sp, -0x20]!
0xfffffff006245d88 fd7b01a9 stp x29, x30, [sp, 0x10]
0xfffffff006245d8c fd430091 add x29, sp, 0x10
0xfffffff006245d90 f30307aa mov x19, x7
0xfffffff006245d94 130100b4 cbz x19, 0xfffffff006245db4
0xfffffff006245d98 680240b9 ldr w8, [x19]
0xfffffff006245d9c 08051832 orr w8, w8, 0x300
0xfffffff006245da0 680200b9 str w8, [x19]
0xfffffff006245da4 00008052 mov w0, 0
0xfffffff006245da8 fd7b41a9 ldp x29, x30, [sp, 0x10]
0xfffffff006245dac f44fc2a8 ldp x20, x19, [sp], 0x20
0xfffffff006245db0 c0035fd6 ret
查看iOS 12.0b1,我们可以了解该函数的签名:
_vnode_check_exec(ucred*, vnode*, vnode*, label*, label*, label*, componentname*, unsigned int*, void*, unsigned long)
是的,找到这个函数真的很容易:
- 找到 AMFI 的
__TEXT_EXEC
细分市场。
- 在其中找到一个
orr wN, wN, 0x300
。
但除非您破坏内核完整性,否则这对您没有帮助。
我目前正在为 iOS 13.7 进行 iOS 越狱。
作为越狱的一部分,我需要对内存中的 XNU 内核进行一系列修补。
当然,内核受到 kASLR
、KPP
/ KTRR
和其他内存看门狗的保护,如果某些内容被修改,这些看门狗会触发内核恐慌。
幸运的是,KTRR
(内核文本只读区域)只能保护不应更改的静态数据(即 TEXT
部分和常量)。变量仍然可以改变。
我正在构建一个 PatchFinder,它应该根据指示符号在 XNU 内存中定位一个函数或变量,我想知道什么是最有效的方法。
我目前正在 PatchFinder made publicly available 之上进行调整,回到 iOS 8 时代 in7egal
看起来像这样:
uint32_t find_cs_enforcement_disable_amfi(uint32_t region, uint8_t* kdata, size_t ksize)
{
// Find a function referencing cs_enforcement_disable_amfi
const uint8_t search_function[] = {0x20, 0x68, 0x40, 0xF4, 0x40, 0x70, 0x20, 0x60, 0x00, 0x20, 0x90, 0xBD};
uint8_t* ptr = memmem(kdata, ksize, search_function, sizeof(search_function));
if(!ptr)
return 0;
// Only LDRB in there should try to dereference cs_enforcement_disable_amfi
uint16_t* ldrb = find_last_insn_matching(region, kdata, ksize, (uint16_t*) ptr, insn_is_ldrb_imm);
if(!ldrb)
return 0;
// Weird, not the right one.
if(insn_ldrb_imm_imm(ldrb) != 0 || insn_ldrb_imm_rt(ldrb) > 12)
return 0;
// See what address that LDRB is dereferencing
return find_pc_rel_value(region, kdata, ksize, ldrb, insn_ldrb_imm_rn(ldrb));
}
我想知道是否有更快或更可靠的方法来定位 cs_enforcement_disable_amfi
。
一旦被PatchFinder在XNU Kernel内存中找到,就这样使用:
uint32_t cs_enforcement_disable_amfi = find_cs_enforcement_disable_amfi(kernel_base, kdata, ksize);
printf("cs_enforcement_disable_amfi is at=0x%08x\n",cs_enforcement_disable_amfi);
if (cs_enforcement_disable_amfi){
char patch[] ="\x00\xbf\x00\xbf\x00\xbf\x00\xbf\x00\xbf";
kern_return_t kernret = vm_write(proccessTask, cs_enforcement_disable_amfi+kernel_base, patch, sizeof(patch)-1);
if (kernret == KERN_SUCCESS){
printf("Successfully patched cs_enforcement_disable_amfi\n");
}
}
因此 PatchFinder 必须能够可靠地 return 指向 cs_enforcement_disable_amfi
的指针,否则我将盲目地写入无效(或有效但不同)的地址,这几乎肯定会触发内存损坏。
大多数时候,当前代码确实 return 一个指向 cs_enforcement_disable_amfi
的有效指针,但大约有 10-15% 的时间随机使内核恐慌,这意味着它的地址 returns 10-15% 的时间是无效的。不确定如何让它更可靠。
您要查找的变量已不存在。
你的第一个片段中的字节组成了 Thumb 指令,它在 32 位内核缓存的 AMFI 中找到这个函数:
0x8074ad04 90b5 push {r4, r7, lr}
0x8074ad06 01af add r7, sp, 4
0x8074ad08 0d48 ldr r0, [0x8074ad40]
0x8074ad0a 7844 add r0, pc
0x8074ad0c 0078 ldrb r0, [r0]
0x8074ad0e 0128 cmp r0, 1
0x8074ad10 03d1 bne 0x8074ad1a
0x8074ad12 0020 movs r0, 0
0x8074ad14 00f04efa bl 0x8074b1b4
0x8074ad18 30b9 cbnz r0, 0x8074ad28
0x8074ad1a 7c69 ldr r4, [r7, 0x14]
0x8074ad1c 002c cmp r4, 0
0x8074ad1e 05d0 beq 0x8074ad2c
0x8074ad20 2068 ldr r0, [r4]
0x8074ad22 40f44070 orr r0, r0, 0x300
0x8074ad26 2060 str r0, [r4]
0x8074ad28 0020 movs r0, 0
0x8074ad2a 90bd pop {r4, r7, pc}
考虑到魔术常数 0x300
和 AMFI 的 __TEXT_EXEC
段非常小的事实,我们可以很容易地在其他内核中找到它,包括 64 位内核。
这是 8.4 上 iPhone 5s 的样子:
0xffffff800268d2e4 f44fbea9 stp x20, x19, [sp, -0x20]!
0xffffff800268d2e8 fd7b01a9 stp x29, x30, [sp, 0x10]
0xffffff800268d2ec fd430091 add x29, sp, 0x10
0xffffff800268d2f0 f30307aa mov x19, x7
0xffffff800268d2f4 e8fc1110 adr x8, section.com.apple.driver.AppleMobileFileIntegrity.10.__DATA.__bss
0xffffff800268d2f8 1f2003d5 nop
0xffffff800268d2fc 08054039 ldrb w8, [x8, 1]
0xffffff800268d300 a8000037 tbnz w8, 0, 0xffffff800268d314
0xffffff800268d304 130100b4 cbz x19, 0xffffff800268d324
0xffffff800268d308 680240b9 ldr w8, [x19]
0xffffff800268d30c 08051832 orr w8, w8, 0x300
0xffffff800268d310 680200b9 str w8, [x19]
0xffffff800268d314 00008052 mov w0, 0
0xffffff800268d318 fd7b41a9 ldp x29, x30, [sp, 0x10]
0xffffff800268d31c f44fc2a8 ldp x20, x19, [sp], 0x20
0xffffff800268d320 c0035fd6 ret
但是到 iOS11 时,变量消失了:
0xfffffff006245d84 f44fbea9 stp x20, x19, [sp, -0x20]!
0xfffffff006245d88 fd7b01a9 stp x29, x30, [sp, 0x10]
0xfffffff006245d8c fd430091 add x29, sp, 0x10
0xfffffff006245d90 f30307aa mov x19, x7
0xfffffff006245d94 130100b4 cbz x19, 0xfffffff006245db4
0xfffffff006245d98 680240b9 ldr w8, [x19]
0xfffffff006245d9c 08051832 orr w8, w8, 0x300
0xfffffff006245da0 680200b9 str w8, [x19]
0xfffffff006245da4 00008052 mov w0, 0
0xfffffff006245da8 fd7b41a9 ldp x29, x30, [sp, 0x10]
0xfffffff006245dac f44fc2a8 ldp x20, x19, [sp], 0x20
0xfffffff006245db0 c0035fd6 ret
查看iOS 12.0b1,我们可以了解该函数的签名:
_vnode_check_exec(ucred*, vnode*, vnode*, label*, label*, label*, componentname*, unsigned int*, void*, unsigned long)
是的,找到这个函数真的很容易:
- 找到 AMFI 的
__TEXT_EXEC
细分市场。 - 在其中找到一个
orr wN, wN, 0x300
。
但除非您破坏内核完整性,否则这对您没有帮助。