Skip to content

Instantly share code, notes, and snippets.

@macshome
Last active April 24, 2024 18:31
Show Gist options
  • Star 43 You must be signed in to star a gist
  • Fork 5 You must be signed in to fork a gist
  • Save macshome/15f995a4e849acd75caf14f2e50e7e98 to your computer and use it in GitHub Desktop.
Save macshome/15f995a4e849acd75caf14f2e50e7e98 to your computer and use it in GitHub Desktop.
How to defang system protections on macOS

How to Defang macOS System Protections

If you want to change things on the root drive of a Mac you will need to take some steps to disable the built in security of the system. Most of these steps are the same regardless if you are on Intel or Apple Silicon. If there is a difference it is noted.

Note that all of these things put a Mac into an unsupported and less secure state.

Make sure you either perform these steps in a VM or that you reset the protections after you are done poking around

Protections and Terms

(This list is not exahustive on the details of each. Check the links at the end for more info.)

  • SIP (System Integrety Protection)
    • Protects agains a wide range of things from changing system launchd jobs to denying debugger attaching.
  • Hardened Runtime
    • A runtime flag that enforces additional security measures on macOS apps. By default blocks things like JIT-code, unsigned executable memory, loading of unsigned libraries, microphone and camera access, contacts and photos.
  • SSV (Signed System Volume)
    • Prevents changes from being made to the contents of the boot volume. This is implimented by restricting boot to a known good APFS snapshot.
  • AMFI (Apple Mobile File Integrity)
    • On macOS this checks the code signatures of binaries before allowing code to execute. Also enforces entitlements.
  • Library Validation
    • Ensure that code loaded into other processes is signed by the expected owner.
  • Platform Binary
    • Code supplied by Apple as part of the system. On Apple Silicon this is arm64e ABI code to enable pointer authentication (PAC).

Disable SIP

Disabling SIP is the first step in most of these processes. This step will essentially give the root user the power to do things like debug arbitrary executables that don't contain additional hardening in code or to break things by deleting otherwise protected directories.

  1. Boot into Recovery OS and open the Terminal.
  2. Disable SIP with: csrutil disable
  3. Reboot.

Unlock the Boot Volume

To unlock the boot volume you need to disable SIP and SSV then make a new snapshot to boot from that contains your changes. Since the system boots from a snapshot now you can't just enable write access to the system volume. Once you make changes to the boot disk you will need to keep SSV disabled in order to boot. Updates will turn this back on if the installer will even run against the modified disk. Luckily you can revert to the previous boot snapshot without any real headache.

If you change the boot volume you will need to keep SSV disabled in order to boot.

How to make changes to the boot disk

  1. Boot into Recovery OS and open the Terminal.
  2. Disable SIP with: csrutil disable
  3. Disable SSV with: csrutil authenticated-root disable
  4. Reboot from the regular boot drive.
  5. Take a look at the volume list with mount and find the sealed volume. In my case it shows as:
~ % mount
/dev/disk3s1s1 on / (apfs, sealed, local, read-only, journaled)
  1. Make a directory to use as a mount point somewhere: mkdir /tmp/mount
  2. Mount the snapshot there with r/w access with: sudo mount -o nobrowse -t apfs /dev/disk3s1 /tmp/mount
  3. Make the changes you want to test to the volume at that mount point.
  4. Generate a new snapshot to boot from with: sudo bless --mount /tmp/mount --bootefi --create-snapshot
  5. Reboot and you will be running from your modified root volume.

How to revert changes to the boot disk

If you want to go back to the Apple sealed snapshot, it is easy to revert your changes.

  1. Revert the boot snapshot with: sudo bless --mount / --last-sealed-snapshot
  2. Reboot.

Running Modified Code

Disabling AMFI

If you want to run code that you've resigned, fiddled with, or just generally messed with you will need to get around AMFI. Otherwise it is going to deny your code the ability to run as it won't be signed by the expected identity for a platform binary or to have the enitlements that it needs to run.

We do this with a boot argument set in NVRAM.

  1. Make sure SIP is disabled with: sudo csrutil status. If it's not then follow the steps above to disable it.
  2. Set the required boot arg with: sudo nvram boot-args="amfi_get_out_of_my_way=1"
  3. Reboot.

Disabling system-wide library validation

We can disable library validation for the cases in which just disabling SIP and AMFI is not enough.

  1. Make sure SIP is disabled.
  2. Adjust this setting with /Library/Preferences/com.apple.security.libraryvalidation.plist DisableLibraryValidation -bool true
  3. Reboot.

Enabling non-Apple signed arm64e binaries

If you are experimenting with your own arm64e code, or patching Apple's, you need an additional boot-arg on Apple Silicon.

  1. Make sure SIP is disabled.
  2. Set the boot-arg to disable AMFI and enabled non-Apple arm64e code: sudo nvram boot-args="amfi_get_out_of_my_way=1 -arm64e_preview_abi"
  3. Reboot.

Possible help if things crash with AMFI out of the way

Even with AMFI told to leave you alone it is still running and checking things. This can cause issues with some apps, notably Electron stuff (eww). You may get better results with the following boot args:

nvram boot-args="ipc_control_port_options=0 amfi_get_out_of_my_way=1"

Put Everything Back Like Apple Made It

To put everything back into a factory state:

  1. Revert boot snapshot changes with: sudo bless --mount / --last-sealed-snapshot
  2. Clear boot-args with: sudo nvram -d boot-args
  3. Boot into Recovery OS and open the Terminal.
  4. Re-enable SIP with: csrutil enable
  5. Re-enable SSV with: csrutil authenticated-root enable
  6. Reboot.

References

@yucc4
Copy link

yucc4 commented Apr 2, 2023

Does this work for macOS Ventura 13.0? I'm trying to delete some files in the System folder.

@ylluminate
Copy link

There were problems in macOS 12.4 wherein arm64e_preview_abi and amfi_get_out_of_my_way could not be enabled together. Has this changed in 12.6.x?

Also, have you discovered a tccutil replacement convenience tool to facilitate enabling of camera, microphone, etc. usage since it will no longer work as before with amfi_get_out_of_my_way enabled?

@macshome
Copy link
Author

macshome commented Aug 2, 2023

Does this work for macOS Ventura 13.0? I'm trying to delete some files in the System folder.

All of my testing for this was done on Ventura.

@macshome
Copy link
Author

macshome commented Aug 2, 2023

There were problems in macOS 12.4 wherein arm64e_preview_abi and amfi_get_out_of_my_way could not be enabled together. Has this changed in 12.6.x?

Also, have you discovered a tccutil replacement convenience tool to facilitate enabling of camera, microphone, etc. usage since it will no longer work as before with amfi_get_out_of_my_way enabled?

Generally you want to have AMFI enabled as it helps prevent all sorts of things like TCC not working. The most prominent example of this I can think of is all the work done with the OpenCore Legacy patcher to allow unsupported OSes to run while keeping AMFI enabled.

@sm3sher
Copy link

sm3sher commented Nov 23, 2023

I can confirm that this is working on an M2 Max with Sonoma 14.1.1 (23B81)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment