Brandon Azad

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...

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...

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...

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...

Unfortunately this is currently expected behavior: pongo_kextload disables the checkra1n kernel patches. If you'd like to try booting with checkra1n kernel patches enabled, then you'll need to make the following...

Excellent, I'll plan to incorporate more well-defined support for using KTRW with checkra1n kernel patches. Please do let me know if you encounter any issues in the meantime.

Hey @sferrini, that's definitely my #1 TODO on this project. I'm planning on adding the Mach-O parser from memctl to dynamically locate these symbols, and possibly make memctl-kext-core just stash...

Unfortunately I'm not planning on adding 32-bit support myself because it would be a significant effort and I'd prefer to focus elsewhere (e.g. keeping memctl up-to-date with new iOS releases)....

My guess is that this a bug related to the new (as of iOS 12) merged kernelcache format, which is causing libmemctl to unexpectedly fail to find the kext Mach-O...

Once #3 is merged, can you rebase these changes on master?