This post will walk you through the basics of macOS internals, and by extension, iOS in many ways. Apple has a reputation for being a closed ecosystem, but that’s not the whole story. My hope for you (mainly, security analysts, detection engineers, and anyone interested) is to make Apple security accessible to you.
Apple open-sources a huge amount of code, including security components. And if you’re an aspiring researcher in these areas, knowing how to access and use that code is helpful, especially for reverse engineering.
Reverse engineering is the process of analyzing a compiled binary to uncover its structure, and functionality. It involves undoing compile-time transformations through disassembly, decompilation, and debugging. In my next few posts, I’ll cover reversing principles, and how I apply them in my research. But for now, we will cover macOS internals in a general sense, and Apple’s open source software.
What are “macOS internals”?
macOS internals are mechanisms that underpin the OS. This includes the XNU kernel, process and memory management, system calls, device drivers, libraries, and other frameworks that manage how software and hardware interact.
User interface example.
The opposite of internals is often described as user-facing components, including the user interface (UI), apps, system preferences, and visual elements that users directly see and interact with.
macOS internals matter because they define how the system functions at its core, enabling debugging, performance modifications, and lower-level security research.
The Apple open source myth
Many people mistakenly believe iOS and macOS are completely closed-source and/or “binary only” due to Apple’s reputation around secrecy. In reality, they share code and include open-source components… in both the kernel land (privileged core with direct hardware access), and in the userland (unprivileged application space for running programs).
Binary-only systems
For reference, binary-only systems are where the end user only receives compiled machine code (aka binaries) without access to the original source code used to create them.
This means that:
- I can’t inspect how the system works internally (e.g., how it handles memory, performs system calls, or enforces security).
- I can’t modify or rebuild the system from source.
- I am dependent entirely on the vendor (e.g., Apple, Microsoft) to fix bugs, patch vulnerabilities, or add features.
This is not necessarily the case for Apple products.
While macOS and iOS are commercial, they are not fully binary-only.
The reality is more nuanced:
- macOS and iOS include OSS components, particularly around the kernel, standard libraries (e.g.,
libc), system utilities, and even parts of the userland. - These components are often shared between the two systems, meaning that improvements or vulnerabilities in one can exist in the other.
- Apple publishes this open-source code online, where I can download, inspect, and even try to compile parts of the system.
That said, Apple doesn’t open everything. Certain frameworks (e.g., CoreFoundation), proprietary services, and newer or security-related components are often not released. This means:
- I don’t have full source access to the OS.
- I can’t rebuild iOS or macOS from scratch using only the available code.
- But I can learn a lot from what’s released, particularly in the kernel and system components.
In short, Apple includes proprietary components and third-party code that remain closed-source, but this only makes up part of the system. Much of macOS and iOS is built upon widely-used Unix-based open source software (OSS), sometimes modified with Apple-specific changes.
Apple OS 101
Before we get into the details, there are some concepts I think everyone should understand first.
First, Objective-C and Swift!
Objective-C and Swift are the primary languages used to build macOS and iOS applications. Objective-C is the older, legacy language still found in many system frameworks and older apps, while Swift is the modern, safer, and preferred language for new development across both platforms.
Understanding Objective-C and Swift is helpful for reversing because system binaries, apps, and APIs are often built in these languages. Thus, knowing their syntax, memory models, and runtime behaviors can reveal how code interacts with device frameworks and the underlying OS internals.
Next, is XCode.
Xcode is Apple’s official integrated development environment (IDE) for creating software. It provides the tools, compilers, and runtime support needed to write, build, debug, and run Objective-C and Swift applications. Xcode exposes frameworks, debugging tools, and system headers (OS-provided files that declare system APIs, types, and macros) that help analyze how software is structured and functions.
Now, let’s get into some internals!
Darwin: the common foundation
Darwin is an open-source Unix-like OS developed by Apple in 2000, forming the base of macOS and iOS. It combines the XNU kernel (a hybrid of Mach and BSD), device drivers, and basic system utilities (e.g., file systems and networking), serving as the foundation upon which Apple builds its proprietary UIs and services.
The kernel is the component of an OS that manages hardware resources and facilitates communication between software and hardware. Here, the XNU (X is Not Unix) is a hybrid kernel combining Mach for system tasks, BSD for Unix-like APIs and userland services, and IOKit for driver management.
When most people discuss Mach, they are referring to a microkernel developed at Carnegie Mellon University that provides system services like task management, memory handling, and interprocess communication.
On a similar note, when most people discuss BSD (Berkeley Software Distribution), they are usually talking about the Unix derivative that contributes components like the networking stack, file system interfaces to Darwin, and process model: the kernel’s architecture and rules for representing, creating, scheduling, and managing process lifecycles.
Shared codebase: macOS ≈ iOS
Given that these things form the foundation of macOS and iOS, these OS-es share a significant portion of their underlying architecture and code, particularly through their common foundation, Darwin.
Differences in userland, entitlements, and sandboxing
Despite this shared codebase, the OS-es diverge in their userland implementations, with iOS enforcing stricter sandboxing (isolates apps to limit their access to system resources), and stricter app entitlements (permissions defining what system features an app can use) to enhance security and control.
These differences influence how processes interact with the system and each other.
| Component (Daemon/Subsystem) | Function |
| XNU Kernel (Darwin core) | Hybrid Mach/BSD kernel; core of OS (process, memory, I/O management). |
launchd | Launch daemon (init) that starts other processes and services at boot. |
mDNSResponder | Network resolver and Bonjour service (DNS and service discovery). |
cfprefsd | Preferences daemon managing app and system settings (reads/writes .plist configs). |
Power Management (powerd) | Power management daemon controlling sleep, battery, and thermal policies. |
However, because much of the lower-level functionality is shared, an understanding of macOS internals can be really beneficial for reversing iOS. Researchers often exploit this overlap by analyzing macOS components, which may contain similar or even identical logic to their iOS counterparts. A good example of this would be daemons: background processes that run autonomously to provide system or application services,
In some cases, vulnerabilities discovered in macOS daemons have led to the discovery of related or identical bugs on iOS, making macOS a great place for finding cross-platform issues. For example, the preferences subsystem, a daemon called cfprefsd (Core Foundation Preferences Service) manages app and system settings on both platforms. On iOS, it runs as a dedicated XPC service (and has been a target for sandbox escape exploits), and on macOS, it plays an analogous role in handling .plist preference.
That said, let’s bust a myth. Why does Apple have OSS?
We all know Apple is secretive, but its products rely on OSS. A chunk of Apple’s code is under the Apple Public Source License (APSL), which allows reading and modification but restricts redistribution, making it useful for research but problematic for publishing modified versions… if that was something you were hoping to do.
🌸👋🏻 Join 10,000+ followers! Let’s take this to your inbox. You’ll receive occasional emails about whatever’s on my mind—offensive security, open source, boats, reversing, software freedom, you get the idea.
How OSS policies impact security
I firmly believe “security through community” outranks “security through obscurity.” I have given many presentations on this, and my mission is to show how providing people with clear, accurate information leads to better decisions in security and in life.
“Security through community” leverages the “many eyes” principle: when source code and design are open, a global community can test, and harden the system far more effectively than a small in-house team ever could. By contrast, “security through obscurity” hides vulnerabilities until they’re exploited, offering a false sense of safety and often delaying detection and patching.
In general, Apple struggles with this concept, although its product security has historically been good because they deprecate or invent new proprietary technology every few years.
It’s not if you’ll get hacked, it’s when, right?
Thus, it is only a matter of time before something cracks, and Apple’s product security (aka our personal device security) will falter. Luckily, there are some areas where Apple publishes their source code, so we can help with security in those areas!
The XNU kernel is open. So are Darwin, launchd, parts of the system libraries, and even some sandboxing tools. All of these components are important for understanding how macOS and iOS work.
What are launchd, system libraries, and sandboxing tools?
For reference, launchd is the unified service management daemon on macOS and iOS responsible for starting, stopping, and managing system processes and user services during boot and throughout runtime.
On Linux, launchd is most similar to systemd, which is the dominant init system and service manager that handles starting and managing services, sockets, and system resources during boot and runtime.
System libraries provide functionality for apps and the OS, such as libSystem, CoreFoundation, Foundation, libdispatch (Grand Central Dispatch), and libc, with Foundation being an Objective-C layer used across nearly all apps.
Lastly, Apple’s sandboxing tools enforce security boundaries between apps and system resources, with components like:
sandboxd,- Seatbelt, and
sandbox_init(), and- sandbox profiles written in Sandbox Profile Language (SBPL).
Here, iOS sandbox profiles and macOS ones are often similar. Studying one helps me understand the other.
What do I take away from all of this?
macOS and iOS share a significant amount of code.
Am I beating a dead horse?
That said, if you have already been pursuing macOS internals research, you probably recognize that it is not always that simple.
Why isn’t anything I try to do working?
Almost every time I embark on a research project, I discover that I’ve approached the problem the wrong way. Specifically, I have repeatedly tried to use Apple’s resources that have been moved or taken down.
I am asking:
Why doesn’t this 3rd-party tutorial that links to Apple’s documentation work? Why do all the links return 404 errors?
More often than not, I find myself in these situations because I don’t fully understand the history of the projects I’m working with, or how to effectively navigate their histories or codebases.
In these cases, a big component of this surrounds…
Navigating Apple’s open source drops.
As with many OSS projects, understanding their history is often needed for debugging or contributing. Documentation, Git tags, and other metadata are helpful in this process.
However, I’ve found that Apple’s OSS projects can be especially challenging in this regard; the historical context is sometimes incomplete, missing, or even redacted over time.
Nonetheless, I can usually find some information by reading the project’s structure, and by having a basic understanding of how projects are generally structured. (Tip #1)
Projects, tags, and versions
Apple publishes the source code of many macOS and iOS components (kernel, libraries, daemons, etc.) as compressed archive files (historically .tar.gz bundles).
These source tarballs have traditionally been available on Apple’s OSS website under each OS release. For example, Apple’s OSS portal offered downloads like xnu-8792.41.9.tar.gz for the XNU kernel, or libdispatch-1325.120.2.tar.gz for Grand Central Dispatch (libdispatch).
In recent years, Apple transitioned away from self-hosted archives to using GitHub: the Open Source site now links each component to a GitHub repository/tag (with a “Download” option for a ZIP/tarball).
In March 2024, Apple shut down many direct download links, causing posts linking to those URLs to 404!! Now, Apple’s GitHub organization (apple-oss-distributions) is the primary source for these archives. In other words, Apple still provides the source in bundled form in addition to browsing the code online. But now, they are available via GitHub auto-generated archives.
Apple’s OSS website
At present (20 May 2025), here’s what I see when I visit Apple’s OSS site.
XNU tags.
Each OS release comes with a bundle of projects: kernel, libraries, and daemons. When I click it, I am usually taken to a GitHub repository. Each open-source component is tagged by name and version (e.g., xnu-8792.41.9), corresponding to the source bundle that I download.
But there’s a catch!
The releases are often incomplete or outdated. I’ll get downloads, sure, but often without clear build instructions. And there are all sorts of troubles that come after that.
One of these troubles is the timeliness of open source releases.
Timeliness
Apple’s OSS releases are almost always delayed. The company publishes the source code weeks or months after the binary OS release. Even Apple’s Developer Technical Support noted that Darwin sources appear “some time after the release of the corresponding OS,” with the lag varying from a few weeks to several months.
Completeness
In many cases, the releases are incomplete or outdated. Apple does not guarantee that every bit of code from a given OS build is released.
In fact, chunks of code are deliberately redacted or omitted from the OSS packages to prevent the release of IP.
Additionally, Apple might skip releasing minor update sources if they’re “nearly identical” to a previous release.
In ONE case, there was no separate Darwin source bundle for macOS 12.5.1, even though macOS 12.5 had one; developers had to use the 12.5 source for investigating iOS 15.6.1, which corresponded to 12.5.1.
But who gets to define “nearly identical”? I’d bet my left kidney it’s the lawyers. There’s no timeline clause for responding to source code requests. Even the GPL doesn’t specify how quickly a source must be provided after a request is made. So, if the backlog is big enough, what’s to stop a company from dragging it out for years?
Timing and schedule
Apple noted that the delay can range from very quick to several months, and “it’s hard to predict how long that delay will be.” Some of the projects haven’t been updated on GitHub in years, despite known vulnerabilities. Stepping off my soapbox for a moment, that’s not to say there’s no validity to the “nearly identical” excuse for skipping releases.
Public communication
There is no regular cadence or exact timetable announced to the public. The Apple OSS website will simply label certain components as “coming soon” until the code is posted, without providing a specific ETA. Again, “coming soon” can mean a wait of many months (or longer), with no further communication from Apple about the timeline.
From what I can see, Apple releases the code when it’s ready on their end, as a courtesy. Historically, Apple eventually releases the kernel (XNU) source for every major macOS and iOS version, but not on the day of the OS launch. There have been instances where the wait was short though.
In one case, Apple took around six months to release required open-source code for an iOS update (iOS 4.1’s WebKit), only doing so after prominent developers complained about Apple’s delayed compliance.
WebKit is an open-source browser engine developed by Apple that renders HTML, CSS and JavaScript for Safari and numerous other applications.
Component listings
Additionally, Apple’s gits and websites sometimes don’t list components under a given platform even if they’re used there. The iOS OSS listings have omitted components like the XNU kernel and others, assuming developers would find them under macOS or Darwin listings.
All of this means the OSS drops can be incomplete (missing some drivers or tools), and out-of-sync with the latest OS patch.
🌸👋🏻 Join 10,000+ followers! Let’s take this to your inbox. You’ll receive occasional emails about whatever’s on my mind—offensive security, open source, boats, reversing, software freedom, you get the idea.
Build instructions
Also, they rarely include detailed build instructions. I mean, who would care about that?
Building Apple’s OS components from source can require extra steps or proprietary tools (e.g., obtaining a Kernel Debug Kit to build XNU for Apple Silicon).
Anyone looking for this info must rely on community documentation for build procedures, and of course, the official packages often lack straightforward build instructions (if any at all).
Versioning and component mapping to official releases
At times, I’ve also struggled with understanding and tracking versioning from OSS releases to official ones, and with mapping macOS/iOS component releases to their corresponding OS versions.
To map them to real OS versions, I check the “Release field” on GitHub. For instance, XNU 8792.41.9 maps to macOS 13.4.
Chess.app release field tags.
Each OSS component release from Apple includes a project version number that will map to a specific macOS/iOS version. Apple uses Darwin versioning for these components. For instance, the XNU kernel version is tagged with an internal build string that correlates with macOS releases.
Cross-referencing
To determine which macOS release a given OSS package corresponds to, I typically cross-reference Apple’s release listings or documentation. For example, Apple’s open source page for macOS Ventura 13.0 shows the kernel XNU version 8792.41.9.
It also appears in the Ventura 13.0 source release list on Wikipedia, which is the main source I use for this. This is good.
Wikipedia version history map.
Over the lifespan of macOS 13 Ventura, XNU was updated several times (e.g., to xnu-8796.121.2 by macOS 13.4). Apple’s open source tags mirror those changes.
Similarly, other frameworks and libraries are versioned and can be mapped. For instance, Libdispatch version 1325.120.2 was released as the OSS libdispatch for macOS 12.5, which was also used by iOS 15.6.1.
On that note, an engineer at Apple suggested using the macOS version as a bridge to find component versions. In other words, identify the corresponding macOS/Darwin release, and then, find the component’s package in that release.
Also, huge shout out to Quinn “The Eskimo!” You have helped everyone in the Apple community so much.
Community-maintained lists (and Apple’s documentation) enumerate these mappings. For example, the Wikipedia entry (the one I use) for macOS Ventura shows each minor Ventura release alongside its XNU kernel version. Apple’s developer forums often confirm which build number ties to which source package.
That is where we come to my second tip! (Tip #2)
Understand how to read and use git version control and GitHub
Why is this helpful? Well, let’s look at how I can…
Use the ‘release’ field in metadata for mapping
Apple’s OSS website and GitHub repositories can explicitly label which OS release a given source code package belongs to. This “Release” field (or designation) is the most reliable mapping tool if it is accurate and/or available.
Apple’s OSS releases grouped.
On Apple’s OSS website, the code releases are grouped by OS version, and each OS release should have a list of components and their source versions. Within each project’s metadata, Apple typically notes the target OS. For example, an open source project entry might read “Release: macOS 13.4” in its metadata, linking the internal version to that OS.
Apple’s distribution manifest repositories (like apple-oss-distributions/distribution-macOS) also act as official maps, locking each component to an OS build. In practice, the best way to map a component like XNU or Libdispatch to a macOS version is to use Apple’s OSS release page or metadata for the “Release” entry. Apple’s engineers advise to “look up the version of macOS” on the open source site and find the component there.
That Release field, effectively the OS version label, is authoritative. In summary, if I see a tag like xnu-8796.121.2 and the Apple OSS site (or GitHub release notes) marks it as Release 13.4, I can usually be confident that it corresponds to macOS 13.4. I have not actually seen this much though, which is why I rely on community maintained lists.
Now, back to the problems with Apple’s OSS releases.
Batch releases and skipped versions
Another weird thing is that Apple’s OSS releases sometimes appear to skip versions or arrive in batches. This is different from just stalling an OSS release, which is what I discussed earlier. It is not guaranteed that each incremental OS update will immediately get a corresponding source release.
In some cases, Apple lumped multiple versions together or released code for a later point release before the initial release’s code. For example, when macOS Mojave (10.14) was open-sourced, Apple initially posted the source for 10.14.1, while the 10.14.0 source was still marked “coming soon” on the site.
This meant the code for the minor update came out first, effectively skipping the initial version (the assumption being that 10.14.1’s source contains the bulk of 10.14.0 plus fixes). It’s not unusual for Apple to update the open source page only after a .1 or .2 update is out, rather than for every single build.
As an outsider looking in, it seems reasonable that Apple might release a large batch of open-source packages spanning multiple OS versions if it has fallen behind on its OSS publications.
For instance, in late 2017, Apple uploaded all current iOS and macOS kernel source code, including ARM/Apple mobile device kernels, in one go. Previously, the iOS-specific kernel code hadn’t been available. This was the first time ARM64 iOS kernel sources were posted publicly. It’s almost like Apple did a big catch-up dump of source code.
The switch
Apple (gradually) switched from 32-bit to 64-bit ARM starting on 20 September 2013. The A7 chip in iPhone 5s was the first consumer device with Apple’s 64-bit ARMv8 (AArch64) architecture. At the assembly level, this meant moving from the old ARMv7 instruction set (with 16 general-purpose 32-bit registers and variable-length opcodes) to AArch64’s fixed 32-bit-wide instructions, a much larger register file (31×64-bit registers), a conditional-execution model, and new SIMD/FPU enhancements. That translated into roughly double the CPU and GPU performance of its predecessor, for more than 4 GB of RAM, wider data paths for faster memory, and excellent power efficiency due to ARM’s RISC-style simplicity and Apple’s custom microarchitecture.
Omittance
Lastly, it’s worth noting that Apple has omitted or delayed components entirely. Over the years, some macOS components that used to be open source have been dropped or released sporadically.
An example is CoreFoundation: Apple removed it from the open-source releases around OS X 10.5, then briefly released it again (with a delay) for 10.5.2 after marking it “coming soon.”
In a later OS X release (10.11 El Capitan), CoreFoundation was once again listed as “coming soon,” and then never released. Likewise, CFNetwork was open-sourced up until OS X 10.4 but was never released after 10.5 Leopard. The launchd service was also pulled from the open-source distributions after OS X 10.10.
These examples show how Apple has skipped releasing certain libraries or frameworks.
Furthermore, the company provides no public explanation when this happens, but what’s new (hint: nothin’)?
So what do all these things lead to?
Compilation and build challenges!
What is compilation?: Compilation Phases Explained: Analysis and Synthesis – Olivia A. Gallucci
The source code Apple publishes (e.g., Darwin, XNU, and other components) can be studied and even compiled at times, but “building” it is non-trivial.
Building is the end-to-end process that takes your source code through steps like compiling, linking, and packaging to produce a final executable or deployable artifact. Compiling specifically refers to translating source code into object or intermediate machine code.
Apple’s OSS distributions require specific tools, dependencies, and random janked fixes to compile. Apple is providing a turnkey build system for end-users to rebuild macOS or iOS; in fact, I can’t compile it and run my own version of macOS from the released code alone. I’ve also spoken about my experience with this in multiple presentations.
Those attempting to compile these components encounter a number of challenges.
Incomplete or missing code.
The released code sometimes omits certain pieces, which usually affects the build. Apple sometimes strips out device-specific or proprietary parts. For example, the XNU kernel source code has all the ARM-specific assembly code removed.
This absence means the code as provided cannot build an iOS kernel with full functionality. Historically, Apple withheld the bits relevant to iPhone/iPad devices’ kernel. Even on macOS, newer kernel features may be absent in the OSS drop.
A Kernel Engineering Manager wrote that with macOS Big Sur, it’s not possible to build an ARM64 kernel from the open-source XNU at all. One option for this is to use the Intel x86_64 target, since key ARM64 kernel pieces are not released.
Furthermore, some subsystems in XNU are closed-source. The networking stack (Skywalk) and power management subsystem (XCPM) were left out of the open code for macOS.
If I were to compile and boot an open-source Big Sur kernel, it would run. But, features like network connectivity and sleep/wake would not work due to those missing components.
In short, the released code is sufficient for reference and experimentation, but it’s not the entire shipping OS. Drivers or firmware-related code may be absent, which prevents a fully functional build.
Dependencies and the build environment
Compiling Apple’s open-source OS components usually requires pulling in additional projects and matching Apple’s build environment. The source releases are provided as individual pieces (XNU kernel, various libraries, etc.), not as one unified build system for a whole OS. Thus, I have to obtain the correct versions of various libraries and headers that the kernel or other components depend on. Apple’s documentation notes that “building XNU requires some patience, and some open source dependencies which are not pre-installed.”
It’s my responsibility to download the ones needed to satisfy build dependencies; for example, header files or support libraries from Apple’s open source website. Enthusiast tools like xnudeps makefile have automated this process by fetching all the prerequisite packages for a given macOS version.
Using the correct Xcode version and Software Development Kit (SDK) is also important.
Like all companies, Apple builds their OS/software with specific toolchain versions, and the OSS may not compile with the latest Xcode by default. Apple suggests using the same Xcode version that corresponds to the OS release you’re targeting: “you might need a different version of Xcode installed when building for previous OS versions.”
“Compilation often works best with the same Xcode version used at the time the code was written” – Stefan Esser in macOS and iOS Security Internals Advent Calendar – Day 1.
For example, building an older Darwin kernel might require installing an older Xcode because newer compilers introduce incompatibilities. Ensuring the environment (compiler, SDK, etc.) matches what Apple used is often necessary to get a “successful” (still janked) build.
Build process quirks
Even with the correct code and tools, it’s common to encounter build challenges.
Apple’s OSS projects sometimes come with Xcode project files or Makefiles that seem to expect internal paths or configurations. There can be glitches that need workarounds. For instance, when building the macOS Mojave kernel (XNU) from source, a developer noted that he had to explicitly disable Xcode’s modern build system to avoid build errors, by passing -UseModernBuildSystem=NO to xcodebuild.
This suggests the project wasn’t immediately compatible with Xcode’s default new build system at that time. Similarly, custom build scripts or configurations (like Apple’s internal darwinbuild system) aren’t provided, so I need to improvise. Thus, if you’re someone trying to get into this space, you will most likely have to sit with improvisations too.
The documentation for building is sparse.
Occasionally, engineers will publish guides on personal blogs or notes in README files, but this practice is not centralized or common. The learning curve is steep: I have to manually configure environment variables, select the proper SDK roots, and sometimes even apply patches to get things compiling.
It’s the process that could easily start like this, but does not.
Finally, even after successfully compiling components like the XNU kernel, running them on actual hardware STILL has additional hurdles. macOS has security features (e.g., code signing, SIP, sealed system volume, etc.) that prevent booting an unofficial kernel without lowering security settings.
Since this post introduces my work, I want to be transparent about the hurdles, mixed successes, and the significant effort and time that go into it.
It has taken days to weeks for me to even get up to this point.
And “this point,” really just means learning enough for me to document, track, and understand some of these hurdles and why they occur.
Oh, also, I have not been successful with an OS build.
Additionally, the work I put into this process also can’t always be replicated for similar environments because the differences are often too drastic.
This is a trade-off. Apple integrates open-source components into a large proprietary system, releasing code to meet license requirements and “encouraging research,” while still maintaining complete control over the final build process.
However, I have usually accomplished something. In this next stage, I focus on resolving incomplete and inconsistent sources (e.g., headers, missing files). But, that gets more hands-on, so I will cover the rest of my process in the next post!
Conclusion
In the next post, I will show how I attempt to bridge the gap between whatever source is available and what the binaries are actually doing. Bridging is challenging in nature, and this post is already long, which is why I separated it out.
In short, this post covered an introduction to macOS and iOS internals, Apple’s open source situation, and the challenges with its OSS releases (e.g., compilation and build difficulties). We learned that macOS and iOS share code, making macOS research valuable for iOS reversing.
Lastly, I discussed how Apple’s OSS releases are great for research but intentionally incomplete. As a result, building from source is educational but unreliable, with many components missing or redacted.
Thanks, sources, and where to learn more about macOS internals
Standing on the shoulders
- Building XNU 4903.221.2 – Scott Knight
- Building XNU for macOS 11.2 (Intel + Apple Silicon) – Kernel Shaman
- Observations of Apple Open Source – Andrew Hyatt
- GUIDE – How to Enable CPU Power Management on macOS [Intel/AMD] – EliteMacx86 Forum
- Нет-Work: Darwin Networking – Jonathan Levin
- Building-XNU-17.4-Kernel-Guide: A short guide on building xnu-4570.41.2 – Foxlet
- Makefile.xnudeps – Jeremya (unlinked because certificate failed)
- macOS and iOS Security Internals Advent Calendar – Day 1 – xpl0n1c
- Reading IOS Sandbox Profiles – 8kSec
- CVE-2019-7286: iOS use-after-free in cfprefsd | 0-days In-the-Wild – Google Project Zero
- Compilation Phases Explained: Analysis and Synthesis – Olivia A. Gallucci
Media publications
- Apple no longer self-hosts their open source code and moved it all to GitHub – Hacker News
- Apple releases open source modules of Big Sur – Hacker News
- Apple open-sourced the kernel of iOS and macOS for ARM processors – TechCrunch
- Review: The iPhone 5S really is the best iPhone yet – Computer World
Terms that might be helpful
Wikis
- Kernel – The Apple Wiki
- BIND – Wikipedia
- Iconv – Wikipedia
- Apple A7 – Wikipedia
- AArch64 – Wikipedia
- Mach (kernel) – Wikipedia
- macOS Ventura – Wikipedia
- Grand Central Dispatch – Wikipedia
- Security through obscurity – Wikipedia
- Berkeley Software Distribution – Wikipedia
Official Apple sources
- Apple Open Source – Apple
- License: APSL – Apple
- Apple OSS Distributions – GitHub
- WebKit – Apple
- IOKit – Apple Developer Documentation
- Where can I get xnu sources for Ventura? – Apple Developer Forums
- Bug in Client of libdispatch – Apple Developer Forums
You must be logged in to post a comment.