Re: Finding symbols in loaded kexts
Re: Finding symbols in loaded kexts
- Subject: Re: Finding symbols in loaded kexts
- From: Dean Reece <email@hidden>
- Date: Sun, 5 Aug 2007 19:22:56 -0700
On Aug 5, 2007, at 6:21 PM, Ryan Govostes wrote:
Is it possible for one kext to locate a symbol in another kext?
I've tried APETools, dlcompat, kld, and a couple other tricks
without success, but I'll admit (and it should be obvious) that I
only have a vague notion of what I'm doing.
Obviously this is not for anything production and I accept
responsibility for the horrible condition I'll likely leave my
kernel in if I screw up!
I did notice that kextstat is able to get a list of loaded kexts
and their addresses, but I could not replicate its functionality
from within the kernel. Surely there is a way to do so, but I'm not
familiar with the functions used.
[below, I refer to the kext that contains the symbol you are after as
the "target" kext, and the one that is doing the lookup as the
"probe" kext.
When you say "find a symbol", I assume you trying get the kernel-
virtual address of the storage/entry point for a symbol defined in
the target kext by running code only in your probe kext. Is the
symbol you are after global? (Use the nm command to examine the
binary of your target kext. if the symbol of interest has a type
specifier that is capital, then it is global.) Does the target kext
allow other kexts to link against it? (does it have the
"OSBundleCompatibleVersion" property.)
If the answer to both of these it yes, then the solution is quite
simple: Just have your probe kext declare a dependency on the target
kext. You can then declare an extern reference to the symbol in
question, and when the probe kext loads, it'll have its reference
patched to the same address as the global symbol in the target kext.
This is typically used to share data and make direct function calls
between kexts, but you can also take the address of such symbols if
that is what you want.
If the target kext does not allow linking, then you can fake it by
adding the "OSBundleCompatibleVersion" property with a value that is
less-than-or-equal the CFBundleVersion value. Obviously, this is
just a hack, and you shouldn't go and modify somebody else's kext in
production code (you indicated this was just for your own
experimentation).
If the symbol you want is not global (lower-case type specifier in
the nm output), or has been stripped out of the target kext entirely,
then there isn't really anything you can do.
Hope this helps,
- Dean
_______________________________________________
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