googleprojectzero
lldb "error: failed to send packet"
Once connected with lldb, commands like pr i and c work as expected, freezing and un-freezing the device respectively. However when trying to use commands like x, di, or b, I get error: failed to send packet.
Here are some sample outputs:
(lldb) x/12wx 0xffffffe001d5b528
error: failed to send packet: 'xffffffe001d5b400,200'
(lldb) di -s 0xfffffff01110e238
error: failed to send packet: 'xfffffff01110e200,200'
error: Failed to disassemble memory at 0xfffffff01110e238.
(lldb) b 0xfffffff01110e230
warning: failed to set breakpoint site at 0xfffffff01110e230 for breakpoint 1.1: error sending the breakpoint request
Breakpoint 1: address = 0xfffffff01110e230
Please let me know what other information you need (this is running on an iPhone 8 iOS 13.5, with the offsets supplied by NewDwarf in issue #6)
Interesting, this is certainly not expected! Can you retry with latest HEAD and send (1) a complete log of LLDB output from startup until you've tried a few failed commands and (2) a complete log of ktrw_usb_proxy output? (The latter in particular might be large, so it might be best to link to a paste.) If possible, a log of pongoOS output would be useful, but it's less important right now.
LLDB output: https://pastebin.com/ExWw1Qq3 ktrw_usb_proxy output: https://pastebin.com/ztCXzzq7
@Muirey03 Could you try to switch to the thread from the kernel address space first? Such thread is from the 0xffffff... address space. Use the lldb command 'thread select <thread #>'. In your lldb output it is 'thread select 3' After that try the commands which failed.
This might be some sort of encoding issue/bad checksum generation in the GDB stub: when LLDB asks for a dump of address ffffffe03a592c00, the GDB stub sends back data that LLDB thinks is invalid, causing LLDB to reply with a NAK -. (This first happens on line 409 of your paste, the first time LLDB issues the x packet.)
How often are you seeing this issue? Is it every time you boot with KTRW, or only occasionally? Does it always happen right at the start of your LLDB session, or does it take some time to occur? Are there any patches applied to KTRW?
One thing to try, that might confirm this hypothesis: Can you edit the file ktrw_gdb_stub/source/gdb_stub/gdb_packets.c to comment out the lines case 'x': return gdb_pkt__x(pkt); and case 'X': return gdb_pkt__X(pkt);? This should force LLDB to use a different encoding scheme, which may shed some light on the issue.
This used to happen every time I booted with KTRW, and always from the very start of the LLDB session. I hadn't been able to get a single x command to succeed.
Curiously, after commenting out those lines, it appears to be working. Here is the new LLDB output: https://pastebin.com/umM1mBqw and the new ktrw_usb_proxy output: https://pastebin.com/gA3qKX2L
Interesting. So it looks like for whatever reason the binary packets ("x") don't work on your system, even though the ASCII packets ("m") do. Usually I'd expect this to be a bug in KTRW's packet encoding, but it's weird that it happens every time for you and never for me.
What is your setup? Are you using a non-standard USB cable? Have you used prior versions of KTRW, and if so, did they also have this issue? Have you tried swapping cables/devices, if available?
I'll also try to find a way to get more detailed information from LLDB on why it rejected the packet.
I am using a standard Apple USB-to-lightning cable. I haven't used prior versions of KTRW, sorry. I realise it is quite likely to be caused by the fact that I am using a very old version of macOS (and therefore a very old lldb version: lldb-360.1.70). I am content with having those lines commented out, as now commands such as x, br and di all seem to be working as expected, if you wanted to close this issue. I am also happy to try and provide more information to you if you wanted to try to resolve this.
Ok, I'm glad it's working sufficiently for you now. Would you mind sharing the macOS and Xcode versions you're using? I'd like to add compatibility anyway, since commenting out parts of the code is less than ideal.