task_for_pid-allow permission

[googleprojectzero]

task_for_pid-allow permission

[bazad]

I’m actively working on adding support for checkra1n and iOS 13.2.2.

[bazad]

It looks like the issue is actually in the ktrw_kext_loader's KTRR bypass, not the kext. I think the problem is due to changes in iOS 13's io_map() implementation causing the mappings allocated by the kext loader to overlap with other data. I'm working on a fresh implementation that avoids the need for io_map() entirely.

[bazad]

I've just pushed a change that should bring partial support to iPhone10,1 17B102 (iOS 13.2.2). ktrw_kext_loader runs fine as a command-line tool, but there appear to be stability problems when the ktrw_gdb_stub kext is running on iOS 13 which causes the phone to eventually panic. I'm looking into this and I'll update this thread with further info.

[mrmacete]

@bazad ah good to know! i started to port this to 13.2 as well, got to the point that the kext is loaded, but it panics as soon as it gets started for "Kernel instruction fetch abort". It looks like kext's text segment is still non-executable regardless of vm_protect.

[bazad]

After examining a few different approaches, I feel that the best solution under the current checkra1n feature set is to provide ktrw_kext_loader as a command-line utility (which can be easily signed with task_for_pid-allow) instead of an app.

[NewDwarf]

@bazad Thanks. Originally, I also thought about making the kext loader as a command line tool.
To add new platform, iPhone 10.4 in my case, should we add new <hardware-version>_<build-version>.txt in the ktrw_kext_loader/kernel_symbols folder and do changes in the platform initialization platform?
Or using it on iOS 13.2.x requires more changes?

[cdpython]

Hi, @NewDwarf

I'm trying to making the kext loader CLI tools. My environ is iPhone 10,4(13.2.2) similar to you.

Could you get the KASLR slide successfully?

I use Checkr1an and I can do tfp0 but failed to get task_info.

The code snip is below.

kern_return_t ret;
uint64_t kbase, kslide;
mach_msg_type_number_t cnt = TASK_DYLD_INFO_COUNT;
task_dyld_info_data_t dyld_info;

ret = init_tfp0();
...
INFO("got mach port = 0x%x", tfp0);
ret = task_info(tfp0, TASK_DYLD_INFO, (task_info_t)&dyld_info, &cnt);
if(ret != KERN_SUCCESS) {
    ERROR("could not get slide...");
    return -1;
}
kslide = dyld_info.all_image_info_size;
kbase = kslide + 0xFFFFFFF007004000;
INFO("kbase: 0x%llx" , kbase);
INFO("kslide: 0x%llx" , kslide);
...

and result is below

iPhone:/usr/ktrw root# ldid -e ktrw
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>com.apple.springboard.debugapplications</key>
        <true/>
        <key>get-task-allow</key>
        <true/>
        <key>proc_info-allow</key>
        <true/>
        <key>task_for_pid-allow</key>
        <true/>
        <key>run-unsigned-code</key>
        <true/>
        <key>platform-application</key>
        <true/>
    </dict>
</plist>
iPhone:/usr/ktrw root# ./ktrw
[+] got mach port = 0x903
[-] could not get slide...

Is there another way to get kslide with tfp0?

Thanks.

[NewDwarf]

@cdpython The same problem and, I guess, it is described here
@bazad suggested to use init_with_unsafe_heap_scan() in his last commit.

[NewDwarf]

@bazad Could you also add support of the iPhone 10,4 platform, please?
The same build (17B102) is used for both 10,1 and 10,4 platforms.
I did internal changes to verify that it works:

./ktrw_kext_loader ktrw_gdb_stub.ikext
[+] Platform: iPhone10,4 17B102
[+] task_for_pid(0) = 0xa07
[!] Could not find the kernel base address
[!] Trying to find the kernel base address using an unsafe heap scan!
[+] KASLR slide is 0x1217c000
[+] Kext ktrw_gdb_stub.ikext loaded at address 0xffffffe0dd14c000
<kernel panic>

[bazad]

@NewDwarf Will do. Just to confirm, did you use the same offsets/addresses as iphone10,1 17B102, or did you have to change any of them? I don’t have an iphone10,4 to verify for myself.

[NewDwarf]

@bazad Thanks. Yes, I used exactly the same offsets/addresses as iphone10,1 17B102.
Here is the patch

diff --git a/ktrw_kext_loader/kernel/kernel_parameters.c b/ktrw_kext_loader/kernel/kernel_parameters.c
index 84af7db..a696ec5 100644
--- a/ktrw_kext_loader/kernel/kernel_parameters.c
+++ b/ktrw_kext_loader/kernel/kernel_parameters.c
@@ -61,6 +61,7 @@ static struct platform_initialization offsets[] = {
 	{ "iPhone10,6", "16E227", offsets__iphone10_1__16C101 },
 	{ "iPhone10,1", "16G77",  offsets__iphone10_1__16C101 },
 	{ "iPhone10,1", "17B102", offsets__iphone10_1__17B102 },
+	{ "iPhone10,4", "17B102", offsets__iphone10_1__17B102 },
 };
 
 // ---- Address initialization --------------------------------------------------------------------
@@ -90,6 +91,7 @@ static struct platform_initialization addresses[] = {
 	{ "iPhone10,6", "16E227", addresses__iphone10_6__16E227 },
 	{ "iPhone10,1", "16G77",  addresses__iphone10_1__16G77  },
 	{ "iPhone10,1", "17B102", addresses__iphone10_1__17B102 },
+	{ "iPhone10,4", "17B102", addresses__iphone10_1__17B102 },
 };
 
 // ---- Public API --------------------------------------------------------------------------------
diff --git a/ktrw_kext_loader/kernel_call/kernel_call_parameters.c b/ktrw_kext_loader/kernel_call/kernel_call_parameters.c
index cccad66..bd174c5 100644
--- a/ktrw_kext_loader/kernel_call/kernel_call_parameters.c
+++ b/ktrw_kext_loader/kernel_call/kernel_call_parameters.c
@@ -61,6 +61,7 @@ static struct platform_initialization offsets[] = {
 	{ "iPhone10,6", "16E227", offsets__iphone10_1__16C101 },
 	{ "iPhone10,1", "16G77",  offsets__iphone10_1__16C101 },
 	{ "iPhone10,1", "17B102", offsets__iphone10_1__17B102 },
+	{ "iPhone10,4", "17B102", offsets__iphone10_1__17B102 },
 };
 
 // ---- Address initialization --------------------------------------------------------------------
@@ -99,6 +100,7 @@ static struct platform_initialization addresses[] = {
 	{ "iPhone10,6", "16E227", addresses__iphone10_6__16E227 },
 	{ "iPhone10,1", "16G77",  addresses__iphone10_1__16G77  },
 	{ "iPhone10,1", "17B102", addresses__iphone10_1__17B102 },
+	{ "iPhone10,4", "17B102", addresses__iphone10_1__17B102 },
 };
 
 // ---- Public API --------------------------------------------------------------------------------
diff --git a/ktrw_kext_loader/ktrr/ktrr_bypass_parameters.c b/ktrw_kext_loader/ktrr/ktrr_bypass_parameters.c
index be70700..6ae3b07 100644
--- a/ktrw_kext_loader/ktrr/ktrr_bypass_parameters.c
+++ b/ktrw_kext_loader/ktrr/ktrr_bypass_parameters.c
@@ -52,6 +52,7 @@ static struct platform_initialization offsets[] = {
 	{ "iPhone10,6", "16E227", offsets__iphone10_1__16C101 },
 	{ "iPhone10,1", "16G77",  offsets__iphone10_1__16C101 },
 	{ "iPhone10,1", "17B102", offsets__iphone10_1__17B102 },
+	{ "iPhone10,4", "17B102", offsets__iphone10_1__17B102 },
 };
 
 // ---- KTRR parameter initialization -------------------------------------------------------------
@@ -131,6 +132,7 @@ static struct platform_initialization parameters[] = {
 	{ "iPhone10,6", "16E227", parameters__iphone10_6__16E227 },
 	{ "iPhone10,1", "16G77",  parameters__iphone10_1__16G77  },
 	{ "iPhone10,1", "17B102", parameters__iphone10_1__17B102 },
+	{ "iPhone10,4", "17B102", parameters__iphone10_1__17B102 },
 };
 
 // ---- Public API --------------------------------------------------------------------------------

and the new file kernel_symbols/iPhone10,4_17B102.txt:

__disable_preemption	0xFFFFFFF007CD06E4
__enable_preemption	0xFFFFFFF007CD0710
__mh_execute_header	0xFFFFFFF007004000
_const_boot_args	0xFFFFFFF007906870
_IOSleep		0xFFFFFFF0080F568C
_kernel_map		0xFFFFFFF007905658
_kernel_memory_allocate	0xFFFFFFF007C50AF4
_kernel_thread_start	0xFFFFFFF007BFAC54
_ml_nofault_copy	0xFFFFFFF007CD6CF8
_panic			0xFFFFFFF0090329E4
_paniclog_append_noflush	0xFFFFFFF007BD5698
_thread_deallocate	0xFFFFFFF007BF93A0
_vsnprintf		0xFFFFFFF007FE60E4```

[bazad]

After much investigation it appears that there are stability issues that occur when changing TTBR1_EL1 to remap the kernel. I haven't been able to pin down exactly what's causing these issues. However, given that checkra1n is likely to support loading kexts in the future anyway, remapping the kernel will become obsolete.

Unfortunately, this means that KTRW is stuck on 12.4 until checkra1n is updated with a kext loading framework.

[NewDwarf]

@bazad
I guess on executing ktrr_bypass.c:309

...
307    else if (insn == 0xd5182020) { // MSR TTBR1_EL1, X0
308        DEBUG_TRACE(1, "Hijacking TTBR1_EL1 %llx -> %llx", read_X(0), ttbr1_el1);
309        write_X(0, ttbr1_el1);
...

[bazad]

Yes, that's one part of it; io_map() was also problematic.

[NewDwarf]

@bazad
The full log of loading the kext.

./ktrw_kext_loader ktrw_gdb_stub.ikext
[+] Platform: iPhone10,4 17B102
[+] task_for_pid(0) = 0x1407
[!] Could not find the kernel base address
[!] Trying to find the kernel base address using an unsafe heap scan!
[D] Found kernel pointer 0xfffffff026e47030
[+] KASLR slide is 0x1f538000
[D] Allocated kernel buffer at 0xffffffe035464000
[D] Set CPU 0 to halt on next reset
[D] Halted CPU 0 in debug state
[D] Skipping KTRR initialization
[D] Hijacking TTBR1_EL1 809608000 -> 8269b4000
[D] Hijacking TTBR1_EL1 806e68000 -> 8269b4000
[D] Restarting CPU 0
[D] Set CPU 1 to halt on next reset
[D] Halted CPU 1 in debug state
[D] Skipping KTRR initialization
[D] Hijacking TTBR1_EL1 809608000 -> 8269b4000
[D] Hijacking TTBR1_EL1 806e68000 -> 8269b4000
[D] Restarting CPU 1
[D] Set CPU 2 to halt on next reset
[D] Halted CPU 2 in debug state
[D] Skipping KTRR initialization
[D] Hijacking TTBR1_EL1 809608000 -> 8269b4000
[D] Hijacking TTBR1_EL1 806e68000 -> 8269b4000
[D] Restarting CPU 2
[D] Set CPU 3 to halt on next reset
[D] Halted CPU 3 in debug state
[D] Skipping KTRR initialization
[D] Hijacking TTBR1_EL1 809608000 -> 8269b4000
[D] Hijacking TTBR1_EL1 806e68000 -> 8269b4000
[D] Restarting CPU 3
[D] Set CPU 4 to halt on next reset
[D] Halted CPU 4 in debug state
[D] Skipping KTRR initialization
[D] Hijacking TTBR1_EL1 809608000 -> 8269b4000
[D] Hijacking TTBR1_EL1 806e68000 -> 8269b4000
[D] Restarting CPU 4
[D] Set CPU 5 to halt on next reset
[D] Halted CPU 5 in debug state
[D] Skipping KTRR initialization
[D] Hijacking TTBR1_EL1 809608000 -> 8269b4000
[D] Hijacking TTBR1_EL1 806e68000 -> 8269b4000
[D] Restarting CPU 5
[D] Loading kext ktrw_gdb_stub.ikext
[D] Resolved _IOSleep = 0xfffffff02762d68c
[D] Resolved __disable_preemption = 0xfffffff0272086e4
[D] Resolved __mh_execute_header = 0xfffffff02653c000
[D] Resolved _const_boot_args = 0xfffffff026e3e870
[D] Resolved _kernel_map = 0xfffffff026e3d658
[D] Resolved _kernel_memory_allocate = 0xfffffff027188af4
[D] Resolved _kernel_thread_start = 0xfffffff027132c54
[D] Resolved _ml_nofault_copy = 0xfffffff02720ecf8
[D] Resolved _thread_deallocate = 0xfffffff0271313a0
[D] Resolved _vsnprintf = 0xfffffff02751e0e4
[D] kext = ffffffe0ca230000
[D] Protecting segment 0-4000 as 1
[D] Protecting segment 4000-10000 as 5
[D] Protecting segment 10000-2c000 as 3
[D] Protecting segment 2c000-30000 as 3
[D] Protecting segment 30000-34000 as 1
[D] Starting kext ktrw_gdb_stub.ikext
[D] _kext_start returned 0x0
[+] Kext ktrw_gdb_stub.ikext loaded at address 0xffffffe0ca230000

I didn't get the kernel panic but lldb is not able to connect to the gdb-server.

lldb kernelcache.release.iphone10_decomp
(lldb) target create "kernelcache.release.iphone10_decomp"
Current executable set to 'kernelcache.release.iphone10_decomp' (arm64).
(lldb) settings set plugin.dynamic-loader.darwin-kernel.load-kexts false
(lldb) gdb-remote 39399
error: failed to get reply to handshake packet

./ktrw_usb_proxy 39399
Found KTRW device c03
Opened KTRW device


 <- +
 <- $QStartNoAckMode#b0
EOF socket

[bazad]

@NewDwarf Yeah, that does not look inconsistent with what I've seen. The corruption sometimes manifests as a hang.

It does look like disabling KTRR for both the MMU and AMCC through kernel __TEXT_EXEC patches via checkra1n would solve the issue fully. In addition to fixing the stability issues, this would remove the need for a KTRR bypass in ktrw_kext_loader itself and make kext loading much faster. I'm thus going to postpone any iOS 13 workarounds until this feature becomes available in checkra1n.

[bazad]

@NewDwarf I just realized that the behavior you saw might have actually been due to a bug in the USB stack that broke connectivity on macOS 10.15. That bug was fixed recently, but the instability on iOS 13 remains and is still pending on updates to checkra1n.

[NewDwarf]

@bazad Thanks for the update. That's is good news!
...but recently I updated iPhone 8 to iOS 13.3.
I afraid all kernel symbol offsets as well as struct offsets in the kernel_call_parameters.c are changed and it is necessary to fix them.
Do you have updated symbol offsets for iOS 13.3?

[NewDwarf]

@bazad
I fixed offsets for iOS 13.3 (17C54). iphone10_1 and iphone10_4 have same offsets.
Could you add them to the code base to support iOS 13.3, please?

addresses__iphone10_1__17C54() {
    STATIC_ADDRESS(allproc) = 0xFFFFFFF0091EEC30;
}

static void
parameters__iphone10_1__17C54() {
    gPhysBase                   = kernel_read64(SLIDE(0xFFFFFFF00790AB68));
    gVirtBase                   = kernel_read64(SLIDE(0xFFFFFFF00790AB70));
    rorgn_begin                 = kernel_read64(SLIDE(0xFFFFFFF00790AE58));
    rorgn_end                   = kernel_read64(SLIDE(0xFFFFFFF00790AE60));
    cpu_ttep                    = kernel_read64(SLIDE(0xFFFFFFF00790A7C0));
    kernel_pmap                 = kernel_read64(SLIDE(0xFFFFFFF00790A7A0));
    ADDRESS(pmap_find_phys)     = SLIDE(0xFFFFFFF007CCBDAC);
    ADDRESS(ml_phys_read_data)  = SLIDE(0xFFFFFFF007CD83EC);
    ADDRESS(ml_phys_write_data) = SLIDE(0xFFFFFFF007CD8690);
    ADDRESS(ml_io_map)          = SLIDE(0xFFFFFFF007CDDD44);
    ADDRESS(ldr_w0_x0__ret)     = SLIDE(0xFFFFFFF007BDAF34);
    ADDRESS(str_w1_x0__ret)     = SLIDE(0xFFFFFFF007BDAFB8);
    ADDRESS(CpuDataEntries)     = SLIDE(0xFFFFFFF0091D2C98);
}

static void
addresses__iphone10_1__17C54() {
    ADDRESS(IOUserClient__vtable)                = SLIDE(0xFFFFFFF007920CD8);
    ADDRESS(IORegistryEntry__getRegistryEntryID) = SLIDE(0xFFFFFFF00810696C);
}

iPhone10,4_17C54.txt
__disable_preemption        0xFFFFFFF007CD8BC4
__enable_preemption         0xFFFFFFF007CD8BF0
__mh_execute_header         0xFFFFFFF007004000
_const_boot_args            0xFFFFFFF00790A870
_IOSleep                    0xFFFFFFF0080FC218
_kernel_map                 0xFFFFFFF007909658
_kernel_memory_allocate     0xFFFFFFF007C58B6C
_kernel_thread_start        0xFFFFFFF007C02C8C
_ml_nofault_copy            0xFFFFFFF007CDF1D8
_panic                      0xFFFFFFF00903A9E4
_paniclog_append_noflush    0xFFFFFFF007BDD6D0
_thread_deallocate          0xFFFFFFF007C013D8
_vsnprintf                  0xFFFFFFF007FECB98

Additionally I verified that offsets in the ipc_entry, ipc_space, proc, task structs were not changed.
static void

offsets__iphone10_1__17B102() {
    kernel_slide_step                       = 0x4000;
    SIZE(ipc_entry)                         = 0x18;
    OFFSET(ipc_entry, ie_object)            = 0;
    OFFSET(ipc_space, is_table_size)        = 0x14;
    OFFSET(ipc_space, is_table)             = 0x20;
    OFFSET(proc, p_list_next)               = 0;
    OFFSET(proc, task)                      = 0x10;
    OFFSET(proc, p_pid)                     = 0x68;
    OFFSET(task, itk_space)                 = 0x320;
    OFFSET(task, bsd_info)                  = 0x380;
    STATIC_ADDRESS(kernel_base)             = 0xFFFFFFF007004000;
}

can be used as

offsets__iphone10_1__17C54() {
    kernel_slide_step                       = 0x4000;
    SIZE(ipc_entry)                         = 0x18;
    OFFSET(ipc_entry, ie_object)            = 0;
    OFFSET(ipc_space, is_table_size)        = 0x14;
    OFFSET(ipc_space, is_table)             = 0x20;
    OFFSET(proc, p_list_next)               = 0;
    OFFSET(proc, task)                      = 0x10;
    OFFSET(proc, p_pid)                     = 0x68;
    OFFSET(task, itk_space)                 = 0x320;
    OFFSET(task, bsd_info)                  = 0x380;
    STATIC_ADDRESS(kernel_base)             = 0xFFFFFFF007004000;
}

But I didn't verify

offsets__iphone10_1__17B102() {
    OFFSET(ipc_port, ip_kobject)                             = 104;
    OFFSET(proc, p_ucred)                                    = 0x100;
    OFFSET(task, bsd_info)                                   = 0x380;
    SIZE(IOExternalTrap)                                     = 24;
    OFFSET(IOExternalTrap, object)                           = 0;
    OFFSET(IOExternalTrap, function)                         = 8;
    OFFSET(IOExternalTrap, offset)                           = 16;
    OFFSET(IORegistryEntry, reserved)                        = 16;
    OFFSET(IORegistryEntry__ExpansionData, fRegistryEntryID) = 8;
    VTABLE_INDEX(IOUserClient, getExternalTrapForIndex)      = 0x5c0 / 8;
    VTABLE_INDEX(IOUserClient, getTargetAndTrapForIndex)     = 0x5c8 / 8;
}

static void
offsets__iphone10_1__17B102() {
    SIZE(cpu_data_entry)                   = 16;
    OFFSET(cpu_data_entry, cpu_data_vaddr) = 8;
    OFFSET(cpu_data, cpu_regmap_paddr)     = 63 * 8;
    OFFSET(cpu_data, ed_mmio)              = 59 * 8;
    OFFSET(cpu_data, utt_mmio)             = 62 * 8;
}

[NewDwarf]

@bazad
Above offsets and addresses work fine on iOS 13.3. I got the kernel debugger functionality. It works pretty stable. At least, I didn't face with kernel panics.
Thanks for the great project!

...closing this issue.