Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
- Subject: Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
- From: "John D." <email@hidden>
- Date: Mon, 15 Dec 2008 04:58:36 +0100
Hi Rick,
> 1 - You can create your Kext against the entire kernel instead of
> supported KPI bundles, by putting the following in the Info.plist
> for the Kext.
> <key>OSBundleLibraries</key>
> <dict>
> <key>com.apple.kernel</key>
> <string>9.5.0</string>
> </dict>
> Then, you can link to any global symbol in "/mach_kernel".
> (For example, chgproccnt() is one of these.) You will probably
> need the open kernel sources to use as documentation and you
> can find out what is global via "nm -g /mach_kernel" and looking
> for the symbols.
This is what I'm using right now:
<key>com.apple.kernel.bsd</key>
<key>com.apple.kernel.iokit</key>
<key>com.apple.kernel.libkern</key>
<key>com.apple.kernel.mach</key>
<key>com.apple.kpi.libkern</key>
<key>com.apple.kpi.bsd</key>
I will check with linking to the whole kernel. I wanted to keep my
KEXT compatible across future versions so I wrote some function hash
search code to find APIs I require when I can't find them around.
> 2 - If that doesn't get what you want, because the routine you need is
> non-global, you can crib it (making sure the resultant source
> file has the APSL on it and it handled in accordance with the APSL).
> This works if the routine doesn't use "private" globals or you can
> get a set of routines cribbed, so that you get to that state.
> (Obviously risky and you may need to re-crib them each time a new
> xnu-1228 source tree is released.)
> * Holy Bogosity Batman!. To hijack the nfssvc syscall,
> * I need to fiddle with the sysent table, but it's defined
> * __private_extern__, so I use nsysent to get a pointer to it.
> * The trick is that nsysent is right next to the table, either
> * just before or just after it. (Not right after it, though:-)
> * First, try just before and then just after.
> */
> if (mysysentptr == NULL) {
> mysysentptr = (struct sysent *)&nsysent;
> mysysentptr -= nsysent;
> if (mysysentptr[SYS_nfssvc].sy_call != (sy_call_t *)nfssvc) {
> tptr = &nsysent;
> do {
> tptr++;
> mysysentptr = (struct sysent *)tptr;
> } while (mysysentptr[SYS_nfssvc].sy_call !=
> (sy_call_t *)nfssvc && tptr < &kdebug_chudhook);
> }
I would implement the loop in a different manner. You can check Landon
F's code in his website. You should limit the search to a reasonable
boundary. If for some reason the sy_call comparison fails, you might
be receiving a wrong location in the best case, or reading past end of
memory in the worse (given that no false positive matches of the
pointer exist across kernel memory).
Useful code nonetheless. I use something similar but I don't patch
sysent, it's for parsing some code elsewhere.
> Not recommended and only to be used if you understand the implications,
> but they work for me. (I've actually been lucky and my Kext hasn't needed
> to be changed for 9.0.0->9.5.0, but I expect to get bit soon:-)
Nice, my main concern is portability across updates of the same major
version (10.5.x). I've added some safety checks to avoid loading
certain features but I would rather want my KEXT to work across all
minor revisions.
John.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden