Olivia A. Gallucci

This post is inspired by a conversation I had with a detection engineer about macOS versioning—how it affects my life, and the challenges of keeping various versions of macOS secure.

I’ve wanted to create a comprehensive macOS resource for a while, but I still don’t feel like I’ve captured the whole picture. Regardless, this post is a starting point. 

This knowledge is hard to absorb; it’s opaque. I love it, but it’s hidden by design. Changes from two, five, even ten years ago still impact current macOS versions—but only some of them, and only sometimes. And the documentation? Vanished. Hidden. You end up spelunking through the Wayback Machine just to find a broken link to a maybe-official page.

Soon, you’ve gone from comfortably searching on DuckDuckGo on your sleek college Mac to relying on Google Chrome’s auto-translate while digging through the comment sections of Chinese tech blogs from 2008—all on a collection of four half-broken test MacBooks you’ve acquired in the name of research.

(Along the way, you also somehow end up with six AirPods, two iPads, two Apple Watches, two HomePods, an Apple TV, and two upstream ARM laptops—all in the name of understanding a world that was never meant to be easy to access—a world that was deliberately hidden from you.)

Here’s how I can help you get started—at least for now, until I have more time to put together a comprehensive resource, or subsets of resources tailored to various use cases. 

All of the resources mentioned are compiled into a list at the end of this post for quick reference.

Let’s get into the gist of things

To begin, I recommend this macOS Internals gist by Kevin Conner. It provides a story of macOS internals—chronologically covering subsystems like launchd, FSEvents, Gatekeeper, App Sandboxing, code signing, and FileVault—offering historical and architectural context necessary for building accurate behavioral baselines. This information accounts for legacy quirks and how these quirks have led to new macOS security controls.

Why does the macOS version matter? 

During my conversation with the detection engineer, I asked them which OS versions and models were running. The gist above explains why. Specifically, it shows how even foundational macOS components—like launchd, FSEvents, and sandboxing—have changed significantly across versions, meaning detection rules relying on static paths (e.g., /System/Library/LaunchDaemons/), behaviors (like file event propagation), or entitlement structures can break or become noisy as Apple deprecates APIs (e.g., kexts vs System Extensions) or shifts security models (e.g., Gatekeeper enforcement tightening). Without this historical context, rules might misfire—flagging legit Swift-based apps using App Extensions or missing persistence mechanisms that now register via systemextensionsctl rather than launchd plists.

The lingo 

Next, I recommend Apple Internals by Michael Roitzsch, which offers—an albeit light—visibility into macOS security architecture, service-level launchd mappings, hardware-backed protections (e.g., SEP, Boot Policy, SKP), and user-mode behaviors, all of which can help craft precise and “durable” detection rules. It has helped me correlate macOS services and components—think com.apple.MobileFileIntegrity (Apple Mobile File Integrity (AMFI)), com.apple.endpointsecurity. endpointsecurityd (Endpoint Security), and com.apple.apsd (Apple Push Notification Service (APNS))—with launch behavior, entitlements, and other security constraints, theoretically allowing for alert tuning that aligns with how macOS evolves. 

Without this level of granularity, rules risk generating false positives (e.g., mistaking sandboxd behavior during a normal app launch) or false negatives (e.g., missing persistence via systemextensionsctl instead of launchd). This is especially true given macOS is moving away from kernel extensions (kexts) and Apple System Logger (ASL), toward System Extensions, App Extensions, Unified Logging, and Signed System Volumes (SSV).

More specifically: 

• System Extensions and App Extensions replace kernel-level code with safer, user-space alternatives (entitlements-based APIs); 
• Unified Logging consolidates system and application logs into a structured, centralized, and privacy-conscious format, replacing ASL and syslog; 
• and SSVs enforce system’s integrity by making the OS volume cryptographically sealed and read-only through a hash tree, making it immutable at runtime. 

How much time do you have? 

Patrick Wardle is the GOAT of the macOS security space; if you haven’t read my initiative—Miles for Mac Security: Supporting FOSS and Aspiring Hackers—you might have missed the memo. Alas, The Art of Mac Malware Volumes I and II by Patrick are a must. 

Volume I: Analysis — Defenders must understand how malware works to counter threats targeting Apple products. This volume explores infection methods, persistence mechanisms, and reverse-engineering techniques to analyze malicious code.

Volume II: Detection — Detecting malware is as vital as analyzing it. This volume explores programmatic approaches to detecting malicious code via behavioral heuristics, equipping you to develop tools and techniques to neutralize macOS threats.

– Patrick Wardle 

Since this post was inspired by a conversation with a detection engineer, I recommend starting with Volume II, as it directly addresses the problem we discussed. Admittedly, I have only read Volume I (so far!)—but knowing Patrick and consuming hours of his presentations online and IRL, I am confident Volume II is just as solid.

ARM

Additionally, I believe an understanding of ARM is important here. I’ll cover ARM more extensively in a future post, but for now, some ARM-specific context will help in fully appreciating macOS internals.

I love Blue Fox: Arm Assembly Internals and Reverse Engineering by Maria Markstedter. While I haven’t read it cover to cover, the sections I have explored are excellent. There’s also the Writing ARM Assembly series by Azeria Labs (Maria Markstedter’s company)—a structured introduction to instruction sets, memory operations, control flow, and stack mechanics, focusing on 32-bit ARMv6.

I also recommend ARM’s official documentation—particularly the Learn the Architecture series (e.g., the memory management guide) and the Architecture Reference Manuals. These are resources I rely on daily. 

Older documentation, like the ARM Architecture Reference Manual (2nd ed) by David Seal, helps me when I need historical or developer context.

Math

Lastly, queuing theory has helped me more than I expected. I have a feeling that as I go deeper into systems internals, math will become even more relevant, depending on the research I pursue. 

But when I think back to my work on manipulating the execution flow of TOCTOU attacks and my current research into process scheduling, math has proven useful. Take Little’s Law:

where is the arrival rate (jobs per second), and is the average time a job spends in the system. 

Apologies for the poor LaTeX rendering. It is a WIP.

This formula helps estimate how long a process spends in a queue or system. That directly relates to predicting the TOCTOU window, the period during which I can swap or modify a resource. In other words, it helps calculate how much time I have to race a legitimate operation. From a defender’s perspective, anomalously long or short queues might flag tampering. Similarly, the M/M/1 Queuing Model, models average response time in systems with a single resource (e.g., a file descriptor or lock)—the exact bottleneck TOCTOU attacks exploit. It gives a sense of how tight the race is and whether delays might be signs of interference. 

where represents the arrival rate of jobs (requests per second), and is the service rate (how many jobs the system can handle per second).

Another useful concept is the effective access time (EAT), which models delays from memory paging. These delays can unintentionally widen the TOCTOU window or reveal timing patterns for memory-based manipulations, like shared memory or mmap abuse. Spikes in page faults or memory latency could point to tampering. 

where is the ​​probability of a page fault occurring. 

Finally, the Utilization Law is useful for spotting overloaded or underutilized systems—scenarios where timing is easier to manipulate or where anomalies are more noticeable.

where is the throughput (jobs completed per second), and is the service time (average time to complete one job). 

These kinds of equations help model, optimize, and secure system behaviors—like process scheduling, memory access, resource contention, and power management—all of which directly affect system performance and the feasibility or detection of attacks like TOCTOU. 

Chasing novelty

So, you’ve picked up enough knowledge to get the gist of things, but now you’re hungry for resources that push the boundaries of your expertise. What you’re looking for is probably blogs!

I haven’t read every single post or resource these individuals have published, but I’ve read enough to confidently say: you will learn something from them, just like I have. I’ve either consumed mass amounts of these people’s work, worked with them, seen them speak, am friends with them, or otherwise consider them part of my professional circle.

First, The Eclectic Light Company by Dr. Howard Oakley. I’m borderline obsessed with this blog. Dr. Oakley covers everything—from detailed subsystem breakdowns to nuanced OS behavior that often flies under the radar. A huge chunk of my current research is inspired by things I’ve read on his site. 

To start, I’d recommend macOS Unified log: 2 content and extraction, where Dr. Oakley provides an overview of the unified logging system, its structured log format, field-level granularity, and predicate-based filtering. The unified log surfaces system activity—such as daemon behavior, XPC interactions, and subsystem diagnostics—through fields (e.g., subsystem, category, processImagePath, and eventMessage). 

Second, Stuart Ashenbrenner’s notes. This one’s newer to me but has been really valuable. It’s a collection of his learnings and experiences surrounding macOS internals and malware. The way he covers things like TCC, XProtect, and malware family mapping is useful for building a mental model of how things break or get abused. Last week, Stuart’s notes were also featured in fellow security blogger Zack Allen’s Detection Engineering Weekly newsletter! 

Also, Patrick Wardle’s posts are great, but those are probably a given. 

Some other names I check on regularly

• Csaba Fitzl 
• Gergely Kalman
• Alden Schmidt
• Jiska Classen
• Wojciech Regula
• Moonlock (not an individual, but solid posts)

I’ve seen each of these people speak (often multiple times), collaborated with some, and count a few as friends. I actively follow their work not just because of what I have learned, but because their output represents the level of quality I aspire to.

Each of these people deserves their own section, but for brevity, I’ll stop here for now. There are plenty more I want to mention, but might be better if I did a less-macOS specific post. For example, Ian Beer would be included if I were focusing more on iOS internals.

Lastly, while he doesn’t focus on macOS, Gynvael Coldwind is an excellent person to follow if you’re looking to sharpen your overall internals knowledge. He has a knack for making complex concepts digestible. 

What am I up to? 

Michael Tsai’s blog (11 Apr 2025) discusses nuanced failure modes in the softwareupdate process on Silicon Macs related to LocalPolicy and user ownership metadata. He highlights how Startup Security Utility, external boot authentication, and bputil interact, which might be helpful for detecting update tampering, misconfigured ownership, and/or unauthorized boot persistence. 

Clownpertino: a simple macOS debugger detection trick by fG! (4 Apr 2025) presents an anti-debugging technique using LLDB-injected breakpoints at dyld_image_notifier, an internal dyld function used for shared library load notifications. By resolving the address of this notifier via TASK_DYLD_INFO and inspecting its contents for architecture-specific breakpoint instructions (e.g., INT3 on x86_64 or BRK #0 on ARM64), the presence of a debugger can be programmatically inferred. It highlights a subtle evasion that may affect dynamic analysis workflows and weaken the efficacy of heuristic and behavioral detections. 

What will I be up to next?

The Objective by the Sea (OBTS) Conference in Spain (and Hawaii – the conference location rotates each year)! Do I have tickets yet? No. Will I find a way to get there? Absolutely.

OBTS—along with Objective for the We (OFTW)—feels like a giant gathering of the Apple security community. I love these conferences and recommend attending if you’re interested in anything Apple security related.

Random resources

I do not use these resources daily, but they are fun to poke around. I think experimenting with resources like these inspires people to actually pursue and learn more about macOS internals. 

OS X/iOS Entitlement Database

OS X/iOS Entitlement Database by Jonathan Levin is a corpus of entitlements extracted from system binaries across iOS 9.0.2 to 18 and macOS 11.4 to 10.18 (“13”). It provides references of task-level and sandbox entitlements, including undocumented and private ones, which govern process capabilities, sandbox exemptions, IPC permissions, and hardware access. 

It can help validate expected privilege boundaries, identifying unauthorized entitlement usage (e.g., com.apple.private.security.no-container, com.apple.system-task-ports), and detecting tampered or side-loaded binaries with escalated capabilities. Theoretically, it could help with precise rule tuning for behavioral detection, especially when malware or jailbreaks injects elevated entitlements to subvert system integrity or bypass policy enforcements like Apple Mobile File Integrity (AMFI), Seatbelt, or XPC service access control. 

The Apple Wiki

The Apple Wiki (more mobile) is an archive of internals info, jailbreaks, firmware-level vulnerabilities, and other Apple bypasses. It gives granularity to iOS/macOS architecture—including attack paths within iBoot, SEPROM, bootchain stages, and AMFI—as well as the mechanics of kernel task port (tfp0) acquisition, pointer authentication code (PAC) mitigation bypasses, and code signing enforcement subversion.

The wiki documents a wide range of persistence tech (e.g., checkra1n, Fugu15, palera1n), memory corruption primitives (e.g., dmaFail, oobPCI, tlbFail), and post-exploitation methods using Cydia Substrate, Theos, and custom entitlement injection. This depth could help with behavioral baselining, artifact correlation, and anomaly detection design in cases where rootkit-like userland or kernel-level modifications escape EDR telemetry and MDM-based controls.

IPSW Downloads

IPSW Downloads is a centralized, programmatically updated index of official Apple firmware images (IPSWs) across major platforms, directly linking to Apple servers. It allows me to acquire specific OS versions for anything I want: static analysis, diffing kernelcache binaries, inspecting system daemons, or isolating changes in sandbox profiles, entitlements, and even identifying regression windows! 

Conclusion

There are many more resources out there than the ones I’ve listed—but this should serve as a good starting point.

If you’ve made it this far, thank you for reading my blog. Hopefully this helps my SEO, haha.

Jokes aside, if there is anything specific you’d like to see a macOS internals guide on—offensive security, hardware, firmware, or something else entirely—please let me know. I’d love to tailor future posts to what is useful. 

If you enjoyed this post on macOS internals, consider reading How OS affects binary exploitation. You might also enjoy IDS Security Using Decision Trees and Neural Networks​​. 

Links

• macOS internals
  • Kevin Conner’s macOS Internals Gist – Great starting point for understanding subsystems historically
  • Apple Sandbox Guide (2011) by fG! – Still useful
  • Apple Internals by Michael Roitzsch – Service-levels, SEP, Boot Policy, etc.
  • The Art of Mac Malware Volumes I & II by Patrick Wardle – Book
• ARM
  • Blue Fox: ARM Assembly Internals by Maria Markstedter – Book
  • Writing ARM Assembly by Azeria Labs – Beginner-friendly series
  • Learn the Architecture Series by ARM – Official resource
  • Memory Management Guide by ARM – Specific example of the Learn the Architecture Series
  • Architecture Reference Manual by ARM – Official resource
  • Historical ARM Reference Manual by David Seal – Book
• Math
  • How to manipulate the execution flow of TOCTOU attacks by Olivia Gallucci – in reference to the importance of Little’s Law, M/M/1, EAT, and the Utilization Law
• Blogs and research notes
  • The Eclectic Light Company, and Unified Logging Breakdown by Dr. Howard Oakley – macOS internals in depth 
  • Notes by Stuart Ashenbrenner – his notes on macOS & Malware
  • Detection Engineering Newsletter by Zack Allen – issue featuring Ashenbrenner
  • Objective-See Blog by Patrick Wardle – macOS internals in depth 
  • Michael Tsai’s Blog – Security nuance and update behaviors
  • macOS anti-debugging tricks by fG!
  • Other’s I keep up with: Csaba Fitzl, Gergely Kalman, Alden Schmidt, Jiska Classen, Wojciech Regula, Moonlock, and Gynvael Coldwind
• Other macOS resources
  • Objective by the Sea (OBTS) Conference 
  • Objective For The We (OBTW) Conference 
  • OS X/iOS Entitlements Database and OS X Book site by Jonathan Levin 
  • The Apple Wiki – Exploits, jailbreak internals, SEP, tfp0, AMFI
  • IPSW Downloads – For firmware, kernelcaches, etc.
  • Miles for Mac Security by Olivia Gallucci – FOSS/macOS scholarship initiative