A common question that comes up when people start Swift development is what’s the difference between a
struct and a
class? The standard answer is structs are value types and classes are reference types. The Swift Programming Language book has a whole section reviewing this concept in more detail. From a reverse engineering perspective I always find it interesting to dive under the hood and see how the compiler actually handles the different concepts from high level languages. This post presents a very simple example of a struct and class in Swift and how the compiler deals with them.
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.