Open tjkr0wn opened 3 years ago
Same issue on iPhoneX (GSM) 14.6 - seeing a panic error with "panicString" : "Attempting to forcibly halt cpu 1\ncpu 1 failed to halt with error -5: halt not supported for this configuration\nDebugger synchronization timed out; waited 10000000 nanoseconds\npanic(cpu 0 caller 0xfffffff00b5c96bc): \"WDT timeout: CPU 1 failed to respond\"@\/BuildRoot\/...
https://googleprojectzero.blogspot.com/2019/10/ktrw-journey-to-build-debuggable-iphone.html
My guess is that the KTRR disable does not properly work
After further investigation, the issue seems related also to FaceID/Passcode unlock, strangely if I enable the passcode the usbproxy never starts, on the contrary with FaceId (which is broken on my iPhone) the phone eventually crashes and never unlocks
I also encountered with this error, when I tested on my iPhone 8 with disabled passcode but the output is different a little bit. Here the panic log
Attempting to forcibly halt cpu 1\ncpu 1 failed to halt with error -5: halt not supported for this configuration\nAttempting to forcibly halt cpu 2\ncpu 2 failed to halt with error -5: halt not supported for this configuration\nAttempting to forcibly halt cpu 3\ncpu 3 failed to halt with error -5: halt not supported for this configuration\nAttempting to forcibly halt cpu 4\ncpu 4 failed to halt with error -5: halt not supported for this configuration\nAttempting to forcibly halt cpu 5\ncpu 5 failed to halt with error -5: halt not supported for this configuration\nDebugger synchronization timed out; waited 10000000 nanoseconds
I have debugged and tested many times and I figured out that the patch is correct but somehow gdb can't halt CPU which triggers the panic above
@tjkr0wn
I know this is a late response but I also had an iPhone 8 (running iOS 14.4.2) panicing at the same stage. For me the panic logs showed a kernel data abort was happening in the KTRW KEXT. This was because in gdb_pkt_qHostInfo, gdb.mach_header
points to the unslid address of the kernel header and therefore doesn't point to mapped memory. So when it tries to read the CPU type and sub type from the kernel header a kernel fault occurs, causing the panic.
My solution was just to add the following line at the end of command_ktrwpf in the KEXT loader Pongo module:
g_mhaddr = va_for_sa(g_mhaddr);
This updates the kernel header pointer with the current kernel slide. This global variable is used by the KTRW KEXT to set the value for gdb.mach_header
. Everything works fine for me after that
Same issue on iPhoneX (GSM) 14.6 - seeing a panic error with
"panicString" : "Attempting to forcibly halt cpu 1\ncpu 1 failed to halt with error -5: halt not supported for this configuration\nDebugger synchronization timed out; waited 10000000 nanoseconds\npanic(cpu 0 caller 0xfffffff00b5c96bc): \"WDT timeout: CPU 1 failed to respond\"@\/BuildRoot\/...
https://googleprojectzero.blogspot.com/2019/10/ktrw-journey-to-build-debuggable-iphone.html
My guess is that the KTRR disable does not properly work
It looks like the watchdog timer is not being disabled, which is likely due to the fact that you are using an iPhone X rather than the original development target which was an iPhone 8. I tried getting this working for an iPhone 6S and there were a number of problems, in part related to the fact that certain values are hardcoded for an iPhone 8 it seems. In your case I suspect your problem is to do with the fact that the watchdog timer registers have a different physical memory location to the hardcoded value found in watchdog.c. You'd need to find out what the physical memory location of them are for your device, which I believe will be in the device tree somewhere.
My device:
iPhone 8 on 14.5.1
I'm using the latest checkra1n and latest version of this repo. I have successfully entered pongoOS with the '-p' option and selected to skip the A11 BPR check. The device seems to find all correct offsets after running
pongo_kext_loader/pongo_kext_loader -l pongo_kextload/kextload.pongo-module -k ktrw_gdb_stub/ktrw_gdb_stub.ikext
, and it boots normally. After unlocking, I wait 30 seconds then runsudo ktrw_usb_proxy/ktrw_usb_proxy 39399
, and the KTRW device is found successfully. Immediately after I attempt to connect to the GDB stub running on the device withgdb-remote 39399
, the device goes into a black screen and shows the Apple logo, which presumably means it has panicked and gone through iBoot.Here is the output of the lldb remote packets log: < 1> send packet: + history[1] tid=0x0307 < 1> send packet: + < 19> send packet: $QStartNoAckMode#b0 < 1> read packet: + < 4> read packet: $#00 < 1> send packet: + < 45> send packet: $qSupported:xmlRegisters=i386,arm,mips,arc#74 < 1> read packet: + < 48> read packet: $PacketSize=700;hwbreak+;qXfer:features:read+#ec < 1> send packet: + < 26> send packet: $QThreadSuffixSupported#e4 < 1> read packet: + < 4> read packet: $#00 < 1> send packet: + < 27> send packet: $QListThreadsInStopReply#21 < 1> read packet: + < 6> read packet: $OK#9a < 1> send packet: + < 10> send packet: $vCont?#49 < 1> read packet: + < 15> read packet: $vCont;c;s;t#05 < 1> send packet: + < 27> send packet: $qVAttachOrWaitSupported#38 < 1> read packet: + < 4> read packet: $#00 < 1> send packet: + < 23> send packet: $QEnableErrorStrings#8c < 1> read packet: + < 6> read packet: $OK#9a < 1> send packet: + < 13> send packet: $qHostInfo#9b