Open sferrini opened 6 years ago
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 a reference to a remapped kernel task port and delegate the actual core implementation to memctl-tfp0-core.
Unfortunately this project is not my top priority right now. If you can use a workaround (e.g. edit the build-phase bash script in Xcode), I'll try to implement a proper fix sometime later this month.
Nice, thanks!
I currently have (and use) two workarounds:
Anyway, thanks again for this project!
Hey @bazad, first of all, congrats for the great tool! It's awesome! I only have one suggestion, and wanted to talk with you about it:
I usually do macOS research with VMs: because I don't want to panic my host when I try stuff that could go wrong (like accidentally accessing unmapped memory, etc.) and also because I can't load kexts when SIP is enabled.
Those VMs have different macOS versions (10.12.6 and 10.13.2 for example). Instead my host, it's always at the latest version.
The current design of the
KernelTask.kext
, is that it hardcodes the symbols's offsets with the ones of the OS's kernel (/System/Library/Kernels/kernel
) used to compile the kext.In this way, it's hard to cross compile the kext from the host to the VMs.
Now, @Siguza wrote a similar kext (hsp4) to access the
kernel_task
from user-space: his kext uses dynamic symbol resolution so that the symbols are resolved at runtime and not hardcoded. Also remaps thekernel_task
(instead of copying it) so that you can access the real one.I think that would be nice to integrate the dynamic symbol resolution in this kext, or better, to use hsp4 as the kext (git submodule?), and modify the core accordingly (or maybe, after adding x86_64 support, memctl-tfp0-core could replace the memctl-kext-core).
Let me know what you think!
Thanks