There really isn't a way for you to detect that someone is or is not tampering with your kext. If you are using an IOKit driver, someone can always subclass your driver. This provides an easy way to modify the behavior of your kext without touching the binary itself. If they don't want to do that, they can always binpatch the binary to include whatever code they wanted and either also patch out the check, or just point your kext to look at an unmodified version of the binary. As already mentioned, you can use the vfs system calls to read in a driver however you are never guaranteed that the file you are reading from disk is the same one that was loaded into memory. Yes, if the file was in a kernel cache or mkext, the cache includes that path that mkext used for the kext inclusion, however as already stated, that doesn't mean that either someone is lying to you or that the kext has changed on disk back to the original after it was placed in the cache to spoof your check. You also need to make sure the vfs subsystem is initialized before you call into it, otherwise you may cause panics. One easy way is to use the post root hook that is in the kernel specifically for the BootCache.kext (note that this is a private api and would not be recommended by Apple). If you do want to do some integrity check, it may be better to do some sort of checksum on the actual loaded binary (say, use the address of a symbol or the __TEXT segment) instead of checking something that doesn't correspond to your binary. Also note that your binary will be modified in memory by the kernel, so that has to be taken into account as well. Evan Lojewski On Sun, Aug 26, 2012 at 12:23 PM, Arun <arun.ka@gmail.com> wrote:
What is auto correct? Also yes integrity check is to make sure that some has not tampered with the kext. I am placing the kext in the /System/Library/Extensions and it is a IOKit driver for BlockI/O devices. So how can i read files from within this kext when it is trying to initialize when the system boots?
Arun KA
On Sat, Aug 25, 2012 at 12:47 AM, Evan Lojewski <meklort@gmail.com> wrote:
Heh, autocorrect is useful... That should say prelinked kernel and not prelim led,
Evan
On Aug 24, 2012, at 1:16 PM, Evan Lojewski <meklort@gmail.com> wrote:
I think a good question to ask here is *why* you want to do an integrity check. Do you just want to make sure that the Kext hasn't been corrupted? Additionally, if the Kext is loading from a prelim led kernel or cache, the binary itself may get modified.
Evan Lojewski
On Aug 24, 2012, at 1:08 PM, Ken Hornstein <kenh@cmf.nrl.navy.mil> wrote:
You seem to be drawing conclusions based on writing a BSD filesystem kext (?) which is not the general case, and certainly has a different operating environment than 99% of kexts (which are IOKit kexts, match asynchronously with respect to the root filesystem and each other, and cannot in general call into the BSD side of the kernel early in boot without panicking)
Well, yeah, that's my experience, and I hope I've never presented myself as the be-all expert when it comes to MacOS kernel extensions because obviously I'm not.
My original point was that you can definitely access filesystems from kexts, but I was under the impression that kext loading was handled exclusively by kextd and friends and obviously everything will be up and running by that time. As you've pointed out, that's not a valid assumption; I learned something new today.
It occurs to me that if your kext is loaded before the root filesystem is mounted you could do somet goofy stuff like have a thread wait around until it is available, but that probably falls under "here be dragons".
--Ken _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/darwin-kernel/meklort%40gmail.com
This email sent to meklort@gmail.com
Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/arun.ka%40gmail.com
This email sent to arun.ka@gmail.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com