Re: IOKit KEXT Questions
Re: IOKit KEXT Questions
- Subject: Re: IOKit KEXT Questions
- From: Matt Burnett <email@hidden>
- Date: Thu, 16 Aug 2007 00:33:37 -0500
Getting the right VM Map for a specific task/process isn't hard. As
far as 64 bit systems and mach_vm_protect, i can still use it, its
exported at 0x1831F5 on 10.4.10 Intel. What i am trying to do can NOT
be done from user space, my intent is to hook kernel functions and do
all sorts of things that cause kernel panics.
I didn't ask about any symbols that were not exported (sysent), i
asked about symbols that were exported (execve). It doesn't matter if
you dont export the symbol, i can still find it, for example nsysent
comes right after sysent, i can calculate sysent's address from
nsysent's address. Also the sysent structure could be found though
brute force methods as well.
I know what i am trying to do will produce code that may or may not
work on past or future versions of darwin/os x. Even if i did release
this code, it would be trivial to check the current version of OS X
and auto-disable the extension. I would also like to make it clear
that i have all ready created code that can hook system calls though
both sysent and though jmp instructions on OS X 10.4.10 Intel. Im NOT
asking you how to hook functions, please understand this.
Regarding the linking against the entire kernel, do non-IOKit KEXTs
link against the entire kernel by default and IOKit KEXTs do not, or
is this another reason why my IOKit KEXT can not resolve execve?
Regarding the whole kernel hook abuse issue. I think this could have
a much better solution than security though obscurity. There are
several articles in Phrack magazine on how to do this with previous
versions of OS X and other similar OSes. I too figured out how to do
this on current versions of OS X. There is also a primitive rootkit
(WeaponX) in the wild that can hook system calls. So the cats out of
the bag on os x kernel hooking. A better solution than saying it cant
be done would be to offer a API that can do this and presents a
warning to the user regarding the stability issues of doing so. When
i was trying to figure out how to hook function calls i looked all
over apple's dev lists and saw plenty of other people asking the same
question, im sure you know this is a demand from developers to do
this. Im sure if you spent some time on it you could think of a
better idea than mine and one much better than saying it cant/
shouldnt be done. Thanks.
-Matt Burnett
On Aug 15, 2007, at 10:24 PM, Terry Lambert wrote:
On Aug 15, 2007, at 5:40 PM, Matt Burnett wrote:
You didnt answer my question, and you jumped to conclusions. I all
ready have functioning code to arbitrarily hook kernel functions.
I didn't ask for help on how to do this, i just asked if there are
any IOKit classes that implement features similar to mprotect/
vm_protect,
I didn't answer because I'm not the best person to answer this
particular question, and you are actually unlikely to find them on
the "dev" list instead of the "kernel" list. Here is my best answer:
No, there are not.
"Unsupported" exports vm_protect, but to get the right map
identifier you would have to go through other unsupported exports
in order to find the right map for the task involved, and by the
time you are down in the IOKit, if you are on a work loop or
another thread, or the operation is an AIO operation being proxied
on behalf of a user space process, or a request from an NFS client,
etc., the task you get will not be the task that initiated the
action. If so, you will not be able to make the call without
information which is lost by the time the call to your code
happens. This will also fail from 64 bit code, which requires the
use of mach_vm_protect() instead of the 32 bit vm_protect() to
represent address space ranges that span or which are above the 4G
32 bit address space limit.
Your best bet is to deal with this from user space instead.
and why IOKit based KEXTs have issues resolving symbols in the
kernel.
Because we intentionally made it difficult to get at things we
think will probably change over time, to try and ensure forwards
binary compatibility for our KEXT developers and our users; when
everything Just Works, that's best for everyone. You can't resolve
many symbols because we __private_extern__'ed the sysent[] table
members because people were hooking them (predominantly for
antivirus software). These hooks don't work long term, and tend to
break between software updates because these functions are not KPI;
they are off limits for use in code you want to work after a
software update, or between major releases.
For example, we've changed the credential structure reference model
several times in software updates in order to deal with a number of
developer issues, so anything that attempts to deal with a cached
reference to a cred (for example, creating a process via fork
+execve) that used old code would suddenly be implemented
incorrectly, if the code we intended was replaced by a third party
with a copy from previously published versions of the code.
You can always link your KEXT against the entire kernel, which gets
you all the non-private symbols (private ones were stripped by the
linker when Mach, BSD, and IOKit were linke to create mach_kernel),
at the cost of your KEXT not working each time there is a software
update. This will more or less ensure that you at least had
opportunity to update to the most recent code base before you
changed the version dependency string.
- I can still use mprotect/vm_protect
Please do so (see above); if someone else jumps in with a better
answer, feel free to take their answer instead.
- For the symbols issue, i can at the very worst use some script
hackery to resolve the symbols in user space and transfer their
addresses to my KEXT.
Expect that this could break in software updates.
I know there are tables in the kernel where i could resolve the
symbols manually as well.
Incorrect; these tables are all in user space after the message
"Jettisoning kernel linker" is emitted to the console, very early
in the boot process. All KEXT linking not coming out of preloading
occurs in user space vs. the supported KPI symbol sets, and the
symbol tables aren't mapped into kernel memory along with the rest
of the KEXT or mach_kernel sections.
I would like to remind you that hurling insults at me such as
"unscrupulous" (definition: having or showing no moral
principles; not honest or fair) does nothing other than provoke me
to release a SDK to the public which would allow people to hook
kernel functions.
I was specifically referring to the act of overwriting kernel
function entries, and the potential for misuse/abuse, and the high
likelihood that the system would become unstable, if not
immediately, then most probably as soon as you installed an
update. FWIW, the already announced Leopard DTrace facility
depends on being able to do this type of thing on its own, and
would more or less stomp any code you put in its way.
If you can't accomplish what you need to accomplish within the
constraints of KPI, please contact DTS to request additional KPI.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden