With my previous post I took a look at the
SystemPolicy.framework and how it kept track of 32-bit applications that had been run. In the process of looking into that I ended up looking into the internals of
syspolicyd. Way back in macOS 10.10.5
syspolicyd was part of the security_systemkeychain source code that Apple releases with each version of macOS. Unfortunately since that time
syspolicyd was moved out of the security_systemkeychain package and closed sourced. This post details the internals of
syspolicyd as it is today in macOS 10.14.x and covers both what services it provides and what clients connect and use its functionality.
At the 2018 WWDC State of the Union event, Apple vice president of software Sebastien Marineau revealed Mojave will be “the last release to support 32-bit at all”. Since macOS 10.13.4, Apple has provided the ability to set your machine to 64-bit only mode for testing. For most users this is not a very convenient way to test. As of 10.14 the System Information application has a new “Legacy Software” section that shows you all of the 32-bit applications that have been run on the machine. This new “Legacy Software” information provides great insight for Mac Admins into what 32-bit applications their users are running so that they can work with vendors to get software updated prior to the release of macOS 10.15. From an admin perspective, it would be nice to be able to get this information in an automated way. This post covers how I went about digging into this new feature and exposing it in a way that could be queried from osquery.
Recently while reverse engineering three kernel extensions from a macOS security product, I noticed that there was a lot of duplicated code between all of the KEXTs. Common things like logging or initialization of data structures were clearly the same in each one. With an IOKit KEXT you can create parent classes in one KEXT and inherit from it in another one. In this case, these three extensions were not IOKit drivers. Although Apple doesn’t document it very well you can share code across multiple KEXTs. This post covers some examples from Apple of shared KEXTs as well as how you would do it in your own KEXT.
One technique malware uses on Windows to disguise itself is called process replacement or process hollowing. This allows malware to start a well known piece of software like
svchost.exe in a suspended state, write malicious code into the processes memory and then start the process running. Anyone looking through running processes will simply see a normal
svchost.exe process running. This has the additional benefit of allowing the malicious code to run with the same privileges as the process it is replacing. You can find a lot of examples of how to create a suspended process on Windows but there doesn’t seem to be as many good examples for other platforms. This post will look at Windows, Linux and macOS and how you can create a suspended process on all three operating systems.