This year, some of our researchers went to the Objective by the Sea (OBTS) conference which is focused on Apple related security.
As usual, you can find below a quick review of a workshop and of our favorite talks.

*OS - Security & Insecurity Workshop (Jonathan Levin)

This training, led by Jonathan Levin (author of several iOS and Android books), covered internals topics of MacOSX/iOS security components.

On the first day we got an introduction to the training program. Then we got details about the different ARMv8.x hardware protections (TBI, PAN, BTI and PAC). We also covered MTE which was freshly released on iOS. We received explanations about IPSW internals and the firmware it contains. We also got some explanation about how the kernel cache is organised.

On the second day, we dived into the kernelcache, and thus the kernel and its extensions. We got great explanations about MACF (which is the foundation for Sandbox and the AppleMobileFileIntegrity). We also covered the code signature format inside the Mach-o binaries in great details.

The third and last day was the most interesting for me. We covered the sandbox and talked about AMFI and its integration with TxM. We also received explanations on SPTM. The final chapter covered all the system tracing possibilities offered by MacOS (which are unfortunately restricted by iOS).

The training was pretty intense and there was a lot of information to digest, it would have been great to have an extra day, but we covered a lot of subjects which was great.

Make XNU GREAT Little Again (Jonathan Levin)

In his talk, Jonathan Levin discussed the refactoring of Darwin Kernel security components into hardware-backed protections and its impact on driving XNU towards a micro kernel architecture.

He started by explaining the evolution of security mitigation on iOS. He explained the role of KPP (Watchtower) and why it was only a “primitive” security mitigation. He then covered KTRR, a hardware-backed protection which was more secure. After he discussed about PPL, explaining how its combination with PAC is a game changer for kernel security.

Then he explained SPTM (Secure Page Table Monitor), and how Apple implemented its own concept of TrustZone to implement it (and TxM). He explained that Apple Silicon implements specific instructions such as GENTER and GEXIT, which are used to enter the Apple “trust zone”. The implementation of custom instructions like that are only possible because Apple is controlling their full stack (hardware and software). We also got a funny slide where ChatGPT tries to explain GENTER (and fails miserably). He also explained that SPTM is in charge of tagging pages, and verifying that page operation are allowed. He used a tool he created named disarm, to disassemble the SPTM firmware.

Then he moved on TxM, which is the Trusted eXecution Monitor. TxM implements a Code Signature Monitor that is used by XNU. He showed that TxM is used in a lot of operation (for example in developer mode or lockdown mode enable, trustcache operations etc…).

He also briefly explained the concept of exclaves which are similar to the trustlets in TrustZone.

Something from Nothing - Exploiting Memory Zeroing in XNU (Ian Beer)

In his talk, Ian Beer explained how he had exploited a vulnerability that Apple deemed impossible to exploit for privilege escalation. Firstly, he introduced basic concepts about the Mach virtual memory system and explained his methodology when it comes to vulnerability research.

He then explained the target function he had found : pmap_zero_page. This function fills a physical page with zeroes. He demonstrated that when calling vm_page_delete with a specific flag it is possible to zero out a page even without permission for that page, resulting into an arbitrary writing of zeroes. During his first report, Apple said that it was not possible to escalate privileges with that, but Ian Beer wanted to prove them wrong.

He explained that he tried to find a usable file to erase (such as certificates or configuration files), but he did not find something exploitable. He then demonstrated that 00 00 00 00 is actually add [rax], al in x86_64, which is a kind of a NOP instruction.

He decided to find a SUID binary that can be exploited just by setting a page to zeroes. He found the binary /usr/libexec/smd which implements a XPC service that can be exploited by this technique. By writing zeroes at a specific place in this binary, Ian Beer was able to subvert control flow and escalate privileges to root.

Finally, he showed that Apple corrected the description of the CVE to confirm that it is exploitable.

Using Type Metadata from Swift Binaries - Gregor Carmesin

This talk from Gregor Carmesin outlined some difficulties in reverse engineering Swift binaries and some proposed solutions.

Swift uses mangled symbol names which can make reversing harder. The tool swift-demangle that comes by default with the swift compiler can be used to demangle symbol names and retrieve type and method information. However, the tool won’t help with stripped binaries.

In order to retrieve information from any binary, whether stripped or not, Gregor delved into several binary sections.

Specifically, he listed and explained the following sections of interest:

• Several sections starting with __swift5 within the __TEXT segment.
• The __objc_classlist and __const sections in the __DATA_CONST segment.
• The __DATA__const section.

Gregor gave some examples of information that can be retrieved even in a stripped binary. For example, the types and names of elements in a class or a structure. He then details how swift resolves type metadata at runtime and the inner workings of swift method dispatch.

To conclude, he explains how he implemented his own demangler and parser of types and metadata. The solution is built with the angr framework and retrieves information that was not available with existing tools. A Ghidra plugin is currently on the roadmap.

What’s new in Lockdown Mode? Marie Fischer

In this talk, Marie Fischer went over the implementation of the lockdown mode and its recent changes.

To start, Marie gave us a summary of the lockdown mode, which reduces the attack surface on Apple devices.

She then went over some components and how it limits features that are a common attack vector used by some sophisticated threat actors.

Among the features limited by the lockdown mode are several that are related to Apple services, web browsing, network, and USB connectivity.

The goal of her research was to understand the implementation of Lockdown mode and its recent changes.

The methodology was to analyse:

• The LockdownMode framework
• Callers of the LockdownMode framework
• The dyld binary

She used static and dynamic analysis methods such as using disassemblers and lldb scripts. To understand the inner workings of some daemons, she used the tool ldumpj which I would also recommend, as it helps a lot to understand and parse the output of launchctl.

We can see several things from her findings. For example, we can see that a significant number of Apple processes are compatible with lockdown mode. Looking at some function calls in the LockdownMode framework, we can see that these processes will go through a different initialization if lockdown mode is enabled.

Crash One - A StarBucks Story (CVE-2025-24277) - Csaba Fitzl, Gergely Kalman

This talk from Gergely and Csaba is about their joined effort in exploiting a vulnerability that seemed non-exploitable at first.

The exploit targets the osanalyticshelperd daemon. This daemon runs as root and is responsible for writing crash reports. If the crashing process runs as the standard unprivileged user, it will write the crash report in the directory ~/Library/Logs/DiagnosticReports/ which is owned by that user. This is a common scenario where a less privileged user could use its privileges on directories or files to perform a local privilege escalation.

Their goal was to get an arbitrary write on the filesystem. The sandbox profile of the daemon normally only allowed a restricted list of directories for file write. However, the profile allowed for an arbitrary file write in the presence of a specific sandbox extension. Csaba was able to issue the sandbox extension token to osanalyticshelperd via xpc, essentially removing the directory limitation originally imposed by the sandbox.

At this point, even though the process could write anywhere on the filesystem they still did not control the destination of the file system write. This situation called for a rename-based race condition.

Gergely has done extensive research on filesystem internals and quirks on unix-like platforms. He explains that because the parameters src and dst of the rename() system call will be looked up separately, every rename is essentially prone to race conditions.

He decided to target the /etc/sudoers.d/ directory and to bruteforce the race condition as in this case, unsuccessful attempts do not have side effects. The race condition is a typical symlink race, they were successful in elevating their privileges to root.

To sum up, the exploit involved extending the original sandbox via xpc and racing rename() to write arbitrary content in /etc/sudoers.d.
Apple rewarded them and assigned the CVE CVE-2025-24277.