Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Device resets (panics?) right after issuing 'gdb-remote 39399' #2

Open
tjkr0wn opened this issue May 21, 2021 · 5 comments
Open

Device resets (panics?) right after issuing 'gdb-remote 39399' #2

tjkr0wn opened this issue May 21, 2021 · 5 comments

Comments

@tjkr0wn
Copy link

tjkr0wn commented May 21, 2021

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 run sudo 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 with gdb-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

@jeppojeps
Copy link

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

@jeppojeps
Copy link

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

@peternguyen93
Copy link

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

@ghost
Copy link

ghost commented Mar 21, 2022

@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

@ghost
Copy link

ghost commented Mar 21, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants