Understanding Apple Mobile File Integrity and Code Signing
Written on
Chapter 1: Introduction to Apple Mobile File Integrity
This piece builds on previous articles, such as "Snake&Apple II — Code Signing" and "Snake&Apple IV—Dylibs," where we explored Code Signing and the concept of Dynamic Libraries, respectively. In "Snake&Apple V—Dyld," we discussed Dyld Environment Variables, particularly the significance of DYLD_INSERT_LIBRARIES in the context of macOS security, as it facilitates the injection of custom code into a process's memory via Dylib.
This article aims to expand on these topics by examining the Apple Mobile File Integrity (AMFI) kernel extension, which is crucial for validating code signatures and defending against unauthorized code injections. We will detail the initiation of the Kernel Extension from its early loading phase to its registration as a Mandatory Access Control (MAC) policy.
Furthermore, we will demonstrate how certain AMFI policies are invoked by system components, particularly in relation to preventing the use of DYLD_INSERT_LIBRARIES. Lastly, we will illustrate how AMFI communicates with the amfid daemon through Mach messages via the MIG subsystem to validate code signatures.
Please be aware that some topics have been intentionally left out for discussion in future articles. Feel free to leave comments if you have any questions or require clarification on any aspects covered here. I promise to respond and will incorporate your feedback into subsequent articles.
Chapter 2: Overview of Apple Mobile File Integrity
The AMFI subsystem consists of a user-mode daemon known as amfid and the kernel extension, AppleMobileFileIntegrity.kext. Its primary function is to uphold code integrity through the Mandatory Access Control Framework. Key tasks include:
- Validation of Code Signatures
- In-kernel entitlement support
- Protection of Mach task ports
- Restrictions on debugging
- Mismatched platform checks (e.g., running iOS apps on macOS)
- Protection against memory mapping vulnerabilities
- Validation of libraries against unsigned code
- Enforcement of launch constraints
- Restrictions on Dyld Environment Variables
The potential for AMFI's enforcement capabilities is vast, and we can expect its functionality to evolve further in the future. This article will investigate some of the tasks mentioned above by reversing components of Apple Mobile File Integrity, aiming to demonstrate entry points into the security mechanisms rather than delving deeply into their functionalities.
Video Title: A Giant Solo Snake On The Official Servers...
In this video, we explore a unique gameplay experience with a giant snake, showcasing the challenges and strategies involved in navigating the official servers. The gameplay highlights various techniques and tactics.
Chapter 3: Kernel Extension Analysis
The AppleMobileFileIntegrity.kext is a kernel extension with the identifier com.apple.driver.AppleMobileFileIntegrity. Although its binary is typically located in /System/Library/Extensions, recent optimizations in macOS Sonoma have made it necessary to extract it from the Kernelcache for analysis.
Kext Binary Extraction:
To extract the AMFI kernel extension, we can utilize the following commands:
# Decompressing Kernelcache
ipsw kernel dec $(ls /System/Volumes/Preboot//boot//System/Library/Caches/com.apple.kernelcaches/kernelcache) -o kernelcache
# Extracting com.apple.driver.AppleMobileFileIntegrity
ipsw kernel extract $(ls kernelcache/System/Volumes/Preboot//boot//System/Library/Caches/com.apple.kernelcaches/kernelcache.decompressed) com.apple.driver.AppleMobileFileIntegrity --output amfi_kext
It is advisable to dump the __PRELINK_INFO section, which contains vital information about kernel extensions, including data typically found in Info.plist.
# Using CrimsonUroboros
CrimsonUroboros -p kernelcache.decompressed --dump_prelink_info
# Using dd
dd if=kernelcache.decompressed of=prelink_info bs=1 skip=$((0x04908000)) count=$((0x04c5bff0 - 0x04908000))
The Kernelcache only needs to be decompressed once to allow for the extraction of various kernel extensions.
Subsection 3.1: Dependent Kernel Extensions
According to the BSD manual pages for kextstat, the "Linked Against" column provides information on APIs exported from other kernel extensions. This data can be leveraged to identify all kernel extensions referencing the AppleMobileFileIntegrity.kext.
kextstat | grep "<.* 19 .*>" | cut -c53- | cut -d "(" -f 1
Among these, the sandbox extension is particularly noteworthy, as it works alongside AMFI as a policy module of the Mandatory Access Control Framework.
Subsection 3.2: Mach-O File Analysis
The AMFI kext binary is classified as a KEXT_BUNDLE, specifically built for the arm64e architecture. The decompressed AMFI kext binary lacks a Code Signature since it resides within the kernel cache, which is secured by System Integrity Protection (SIP) on the Preboot volume.
Furthermore, validation of the AMFI kext is conducted during loading via mac_kext_check_load to ensure that it is not being loaded from userland.
The header flags include TWOLEVEL, NOUNDEFS, and DYLDLINK, indicating that it does not import symbols from dynamic libraries; however, it does depend on other kernel extensions for symbol imports.
# List all registered kexts
ioreg -l
Subsection 3.3: AMFI Startup Sequence
The initialization of AMFI occurs during the MACF setup phase. This process begins by invoking mac_policy_init and kernel_startup_initialize_upto.
# Call to load security extensions
bootstrapLoadSecurityExtensions
As AMFI is marked as a security extension in the Info.plist file, it will be loaded during this step.
Video Title: Giving Snakes Their Legs Back
This video demonstrates a creative gameplay twist, illustrating how snakes can be given legs, changing the dynamics of interaction within the game environment.
Chapter 4: Conclusion and Future Directions
In summary, this article has explored the role of Apple Mobile File Integrity in maintaining code integrity and enforcing security policies on macOS. While we have touched on several aspects, including the kernel extension, its startup sequence, and the communication with the amfid daemon, there is still much to uncover regarding its internal mechanisms.
In future articles, we will delve deeper into code injection techniques and examine additional security measures, such as the Sandbox kext, Gatekeeper, and TCC. If you found this article enlightening, please share it and leave any feedback or questions in the comments section. Stay tuned for more insights!
References
The following articles provide further reading on Code Signing validation and AMFI-related vulnerabilities:
- The Nightmare of Apple's OTA Update by Mickey Jin
- MacOS Codesigning Translocation Vulnerability by impost0r
- CVE-2022–42855 by Ivan Fratric
- Code Signing — Hashed Out by Jonathan Levin
- Debug any iOS Apps on M1 Mac by Mickey Jin
- DYLD_PRINT_TO_FILE LPE by Stefan Esser