Re: Need to gain access to unexported symbols
Re: Need to gain access to unexported symbols
- Subject: Re: Need to gain access to unexported symbols
- From: Evan Lojewski <email@hidden>
- Date: Tue, 13 Jul 2010 18:08:18 -0600
It's possible to manually export the symbols from the installed kernel
without recompiling it. If you look in the XNU source, specifically
the config directory's Make file, you can determine how to use the
program to create a kext that exports those symbols for you. You then
need to modify your main kext's Info.plist to include the symbol kext
as a dependency. If you can find the symbol using nm /mach_kernel,
then you can link to it using this method. I've done this multiple
times without issues, but only if you don't plan on upgrading kernels.
You will have issues with this method if Apple ever decides to remove
a symbols from the kernel, and as such you really should be using
public symbols (use this as a last resort).
Essencialy, to create the kext you can to do the following:
#!/bin/bash
NAME=MissingSymbols
nm -gj /mach_kernel > allsymbols
echo "_in_pcblookup_local" > ${NAME}.exports
echo "_in_pcblookup_local_and_cleanup" >> ${NAME}.exports
# include any more symbols needed.
kextsymboltool -arch i386 -import allsymbols -export ${NAME}.exports
-output ${NAME}_32
# if you are making a universal kext for SL
kextsymboltool -arch x86_64 -import allsymbols -export ${NAME}.exports
-output ${NAME}_64
lipo -create ${NAME}_32 ${NAME}_64 -output ${NAME}
You then need to create the kext package. Take a look at
/System/Library/Extensions/System.kext/PlugIns for examples. Also note
that kextsymboltool is included with the XNU build environment.
Hope that helps,
Evan Lojewski
On Tue, Jul 13, 2010 at 12:09 PM, Platon Fomichev
<email@hidden> wrote:
> Dear Shantonu
>
> Thanks for your answer. I am targeting exclusively Leopard i386 10.5.6. Sad
> to say I won't be able to have a custom kernel - this should be a stock
> kernel with a specifically tied kext to it.
> I was not aware of pf.c!! This is great - this will help us immensely! But
> as you see I immediately checked the code and it is full of unexported calls
> like 'zone_change'. This again returns us to the question what are other
> ways to get access to unexported symbols.
>
> P.S. I immediately got hold of latest SL and whooops 'map pf' and 'man
> pfctl' returns nothing. Also where can I find pfctl code in SL? Can you shed
> some light on PF in SL - how can I enable it, how can I check it, etc.
>
> Best regards,
> Platon Fomichev<email@hidden>
>
> On Jul 13, 2010, at 9:00 PM, Shantonu Sen wrote:
>
>> What version of Mac OS X are you targeting, and what architecture?
>>
>> If you build your own kernel, you can add whatever symbols you like to the
>> exports list.
>>
>> Just to be sure, you're aware of
>> <http://opensource.apple.com/source/xnu/xnu-1504.7.4/bsd/net/pf.c> right?
>>
>> Shantonu
>>
>> On Jul 13, 2010, at 9:09 AM, Platon Fomichev wrote:
>>
>>> Good day, everyone
>>>
>>> Our team is porting OpenBSD PF filter to OS X and the progress so far is
>>> good. However we're battling with lots of 'hidden' symbols we need access
>>> to. Yes we know this is kernel tied stuff, but the project is supposed to be
>>> kernel-tied as closely as possible, so this is OK. We need access to some
>>> functions like in_pcblookup* funcs and some primitive ones like
>>> _boottime_sec().
>>>
>>> The question is simple - we can't link against these functions like
>>> _boottime_sec() because they are not exported from Kernel and kextload
>>> complains. Can you suggest me the way to workaround this - I just always
>>> can't copy-paste parts of the kernel (like I do now!) to implement some
>>> funcs. Yes, I understand this is hack, but for now we need a prototype to
>>> show to the customer - if it will be successfull I hope they will try to
>>> push Apple to help us, but without workaround my hands are tight.
>>>
>>> Let's start with simple - very simple func _boottime_sec() - it's not
>>> exported - how can I still link with it?
>>>
>>> Thanks in advance.
>>>
>>> Platon Fomichev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> 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
>
_______________________________________________
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