3 ms·
Author here. Yes, the issues you pointed out are mostly already captured via // TODO and // FIXME comments. The library was written in about a day. I could prob
by rgovostes 9y ago
Author here. Yes, the issues you pointed out are mostly already captured via // TODO and // FIXME comments. The library was written in about a day. I could probably add the basic block length check (as it is, I just check for 0xC3), but I wasn't able to readily figure out how to disable interrupts during patching. If you have a suggestion, I'll implement it. The nice thing about a reusable library is that safety improvements can be made and shared with other clients.
(As an aside, can I suggest posting an issue to GitHub? I might not have seen this thread, and xnu_override users who want to know of its shortcomings should also be able to find your comments easily.)
I hope that someone who has the know-how to reverse engineer the kernel, devise a patch to add desired behavior, and write a kernel extension to implement that behavior, will understand that patching the kernel is inherently a dangerous thing to do—and will actually test that their change works.
I wrote this as an alternative to other patchers which provide a string search and replace on the system kexts. Reverting these patches, dealing with the code signing fallout, and updating them for a new release are significantly more challenging with this style of patching.
- dmitrygr 9y agoI don't GitHub, but here are some thoughts: you only need to disable ints when you mess with cr0 and cr3 and applying patches. There are apis in the kernel for that. Basic block detection isn't easy. You CAN find branches in the block, and even patch them to work when you copy them elsewhere (you'll need this since most x86 branches are relative). There is provably NO 100% certain way to make sure no branch anywhere else targets those 12 bytes though. You can use heuristics to almost-reliably guess though. If there is a "call", the instruction after it likely is a target of an indirect branch (ret). Also you'll have to disassemble the entire function (breadth first search till every traversal path hits a "ret") and see if any jumps to these 12 bytes exist. This will cover 99.99% of cases. The remaining 0.01% is VERY hard.