how to find the paths of all loaded kexts

Thanks to a tip from Erik Gomez, I’ve only just noticed that the kextfind utility restricts its default search to just the System and local Library Extensions folders (note to self: RTF man page!). While you can name specific folders in a custom search, kextfind doesn’t have a recursive option to trawl the whole system or even all children of a parent directory. You might bash your way around that, but it’ll be slow and take forever.

Instead Erik offers a python script that hooks into Objective-C to find both loaded and unloaded kexts. As my job mostly involves disarming currently running badware, I’m generally more concerned with what’s actually running on a user’s system at the time I’m troubleshooting it, i.e., kexts that are currently loaded, and I figured I could probably do a quicker-and-dirtier job of that on the command line without needing to actually write an executable script or doing a slow trawl with the find tool.

The problem is that while we can get kexts in /Library/Extensions and /System/Library/Extensions easily enough from kextfind, what about all those 3rd party extensions lurking in unknown places? The answer lies in part with the kextstat utility, but unfortunately that will only tell us what the loaded kexts are, not where they are located.

The rest of the answer is to take the bundle identifiers provided by kextstat and then coerce kextutil into supplying the paths. We’ll then do a merry dance with a few other utilities (that don’t begin with the word ‘kext…’) and a temp file to parse out the noise and spit out the paths that we wanted all along. Finally, we’ll clear up after ourselves by deleting the temp file we created.

Here’s the whole command, then I’ll walk through how it works:

---

t="Desktop/kx.txt"; kextArray=`kextstat -l | grep -v com.apple | awk '{print $6"@"$3}'`; for i in $kextArray; do kextutil -a "$i" >> ~/"$t" 2>&1; done; v=$(<~/"$t"); echo "$v" | cut -d" " -f1 | grep -iv warning | awk '/^\s*$/ {next;} {print $1}'; rm ~/"$t"

---

At this point I’ll apologise to the learned: a better shell scripter than I would surely do this with far more panache, and my lazy habit of defaulting to solving new problems through familiar tools is undoubtedly clumsy; for our purposes here, however, if it works it’ll serve (feel free to add your own better solutions in the comments!).

So we start with a variable that we’ll substitute in later for our temp file path. We next get a list of running kexts’ bundle identifiers from kextstat. This tells us what’s loaded, and we grep out any of the Apple ones. The awk command after that rearranges the output from kextstat to a format that kextutil will like, and the whole lot is saved in an array.

We next iterate over the array and write out the result to a text file, appending as we go. We’re redirecting both standard out and standard error to our file.

Now, kextutil isn’t really meant for looking up paths per se, but we can leverage its –address flag to get those out of a more verbose kext debugging message.

We now read the file back in, and pretty much everything after that is my mangled attempt at parsing out the extraneous (for our purpose) messaging that kextutil provided.

The result? On my machine this code produces what you see in the screenshot at the top of this post. Since these kexts are all in the default locations, I could have got them simply from kextfind, but what I know now that kextfind wouldn’t have told me is that there aren’t any other 3rd party kexts in any other places loaded on this particular machine, and if there were, this little script would have told us where to find them. For troubleshooting purposes, that info is well worth having!

Enjoy 🙂

Advertisement