Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Slxt51ZTQI9RRx4grFxUTcV5ixg6y6Uf0en3B9zPtT0=; b=Z20rwr2Va+QRgcmWJiBeSpJeFy9K9SZ6kFEdH3kUwJklQCBQ7xJgqi7gC47ClUHdmZ Bii7U7q4I2uFD+pncS14yjWvIsochdaxiRHIJmFPQ+rH5vNuQh0Q3q+cI96PebWnSjQs faPtGdjtNyJP7Zw7fhV3NeeZMJunvu5o0L8MY= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=dZszeYFppKhJ9Go8XzoJH8swfcvxsGCvO1QL/0dXnKa0Ecm7SjG2OxLzKMW2TCffG7 Nb/xVmPlBFUrRi0xNZejTR3uu1/fi/QeLzZXPLnVktLx/eBiap1JAPnAm4YwsvhyaEs+ PAUtFtKjxiqAOR53Ov2ZH4yMvaGJ0BGD6c2yg= Hi Rick,
1 - You can create your Kext against the entire kernel instead of supported KPI bundles, by putting the following in the Info.plist for the Kext. <key>OSBundleLibraries</key> <dict> <key>com.apple.kernel</key> <string>9.5.0</string> </dict> Then, you can link to any global symbol in "/mach_kernel". (For example, chgproccnt() is one of these.) You will probably need the open kernel sources to use as documentation and you can find out what is global via "nm -g /mach_kernel" and looking for the symbols.
This is what I'm using right now: <key>com.apple.kernel.bsd</key> <key>com.apple.kernel.iokit</key> <key>com.apple.kernel.libkern</key> <key>com.apple.kernel.mach</key> <key>com.apple.kpi.libkern</key> <key>com.apple.kpi.bsd</key> I will check with linking to the whole kernel. I wanted to keep my KEXT compatible across future versions so I wrote some function hash search code to find APIs I require when I can't find them around.
2 - If that doesn't get what you want, because the routine you need is non-global, you can crib it (making sure the resultant source file has the APSL on it and it handled in accordance with the APSL). This works if the routine doesn't use "private" globals or you can get a set of routines cribbed, so that you get to that state. (Obviously risky and you may need to re-crib them each time a new xnu-1228 source tree is released.) * Holy Bogosity Batman!. To hijack the nfssvc syscall, * I need to fiddle with the sysent table, but it's defined * __private_extern__, so I use nsysent to get a pointer to it. * The trick is that nsysent is right next to the table, either * just before or just after it. (Not right after it, though:-) * First, try just before and then just after. */ if (mysysentptr == NULL) { mysysentptr = (struct sysent *)&nsysent; mysysentptr -= nsysent; if (mysysentptr[SYS_nfssvc].sy_call != (sy_call_t *)nfssvc) { tptr = &nsysent; do { tptr++; mysysentptr = (struct sysent *)tptr; } while (mysysentptr[SYS_nfssvc].sy_call != (sy_call_t *)nfssvc && tptr < &kdebug_chudhook); }
I would implement the loop in a different manner. You can check Landon F's code in his website. You should limit the search to a reasonable boundary. If for some reason the sy_call comparison fails, you might be receiving a wrong location in the best case, or reading past end of memory in the worse (given that no false positive matches of the pointer exist across kernel memory). Useful code nonetheless. I use something similar but I don't patch sysent, it's for parsing some code elsewhere.
Not recommended and only to be used if you understand the implications, but they work for me. (I've actually been lucky and my Kext hasn't needed to be changed for 9.0.0->9.5.0, but I expect to get bit soon:-)
Nice, my main concern is portability across updates of the same major version (10.5.x). I've added some safety checks to avoid loading certain features but I would rather want my KEXT to work across all minor revisions. John. _______________________________________________ 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: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com
participants (1)
-
John D.