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: Sun, 14 Dec 2008 18:08:43 +0100
What would be the process to request a KPI to be made available? We
are talking about exporting a handful functions here. Let's say I want
to emulate / write my own unix_syscall dispatcher for introducing some
process status tracking code or collecting stats or information about
registers or anything I need to do explicitly within the context of
the unix_syscall function, but implementing my own code along with it.
Most of the API used in unix_syscall isn't available in any KPI. That
leaves us with either patching its code on runtime (a hack, which
apparently isn't possible because that region isn't writable; I'm not
sure why kernel TEXT wouldn't be writable except for security reasons
I guess) or forgetting about implementing anything around it.
A KPI that provides us with means of resolving a kernel symbol from a
kext would be extremely handy. I could understand that we want certain
symbols to be restricted, but this would let us solve many issues.
Whether it's from the running kernel or from a file on the root disk
is not really important.
John.
On Sun, Dec 14, 2008 at 5:50 PM, Terry Lambert <email@hidden> wrote:
> You are trying to do something for which there is no KPI.
>
> You can ask for KPI (which you might not get) or you can build your own
> kernel. Basically you are asking us to not change what we consider
> implementation details. We want them to be fungible so we can implement more
> efficient algorithms at a later date. Doing so will break your code.
>
> -- Terry
>
>
> On Dec 14, 2008, at 8:13 AM, "John D." <email@hidden> wrote:
>
>> That's just messed up. This is a KEXT, I can't force people to rebuild
>> the kernel or patch it right away.
>> I guess I will have to search memory with a function hash of sorts,
>> but seems like a hack. I don't know why Apple decided to stop
>> exporting some really useful API (namely some kauth and proc
>> functions), plus restricting access to proc structure definitions by
>> providing a crippled public one.
>>
>> My KEXT project is related with collecting statistics of processes so
>> the non exported API is a bummer.
>>
>> John.
>>
>> On Sat, Dec 13, 2008 at 5:35 AM, Michael Smith <email@hidden> wrote:
>>>
>>> On Dec 12, 2008, at 8:15 PM, John D. wrote:
>>>
>>>> I'm working on a college project and I would like to access some
>>>> non-exported API. For example chgproccnt and kld_file_lookupsymbol. I
>>>> want to be able to obtain a symbol address from a kernel extension,
>>>> say, of the mach_kernel file. This could come handy but apparently
>>>> none of the useful API is available to extensions. Has anyone done
>>>> anything similar or can provide a suggestion to access
>>>> kld_file_lookupsymbol() without using static addresses (to avoid
>>>> version-specific builds, since Apple can change it anytime).
>>>
>>> You will need to build your own kernel.
>>>
>>> = Mike
>>>
>>>
>> _______________________________________________
>> 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