One important thing the article glosses over: even if you sign your binary with task_for_pid, that does NOT mean you can attach to arbitrary processes on modern macOS, especially on Apple Silicon machines.
There are two separate layers people often confuse:
1) Having the task_for_pid entitlement
2) Being allowed to obtain a task port for a target process
AMFI and the kernel enforce the second one.
Even if your binary has the entitlement, the kernel will still refuse task_for_pid() for many targets (Apple platform binaries, hardened runtime processes, protected tasks, etc). In those cases the call simply fails.
Older blog posts and guides often mention disabling AMFI with a boot argument like:
amfi_get_out_of_my_way=1
(also seen as amfi=0x80)
Historically that worked because AMFI behavior could be weakened via NVRAM boot arguments. The flag effectively disabled entitlement validation and allowed processes to obtain otherwise restricted capabilities. :contentReference[oaicite:0]{index=0}
That advice is now largely outdated on Apple Silicon.
On modern M-series Macs the boot chain is tied into Secure Boot and the Secure Enclave. The kernel image, boot policy, and security configuration are verified during boot, and the system enforces what boot arguments are allowed to affect security policy.
In practice this means:
• You cannot freely change security-sensitive boot args from a normal system.
• Boot policy is enforced by the secure boot chain.
• Root does not get to override it.
Changing these policies requires booting into Recovery and modifying the machine’s security mode (Reduced Security). Even then, many AMFI protections remain active.
So the old “just set amfi_get_out_of_my_way and reboot” trick that worked on older Intel systems does not translate cleanly to Apple Silicon machines.
As a result, signing a tool with task_for_pid does not magically give you the ability to attach to arbitrary system processes on modern macOS. Without weakening the system’s boot security policy or patching the kernel, AMFI-protected processes remain non-attachable by design.
For JIT you self-manage run protections for code segments. That isn’t free editing of arbitrary executables out of the gate, but you could develop code running in a self-harness supporting arbitrary runtime changes during development.
There would be indirection somewhere, but that could be high up the code tree, so zero impact on downstream performance sensitive code.
There are two separate layers people often confuse:
1) Having the task_for_pid entitlement 2) Being allowed to obtain a task port for a target process
AMFI and the kernel enforce the second one.
Even if your binary has the entitlement, the kernel will still refuse task_for_pid() for many targets (Apple platform binaries, hardened runtime processes, protected tasks, etc). In those cases the call simply fails.
Older blog posts and guides often mention disabling AMFI with a boot argument like:
Historically that worked because AMFI behavior could be weakened via NVRAM boot arguments. The flag effectively disabled entitlement validation and allowed processes to obtain otherwise restricted capabilities. :contentReference[oaicite:0]{index=0}That advice is now largely outdated on Apple Silicon.
On modern M-series Macs the boot chain is tied into Secure Boot and the Secure Enclave. The kernel image, boot policy, and security configuration are verified during boot, and the system enforces what boot arguments are allowed to affect security policy.
In practice this means:
• You cannot freely change security-sensitive boot args from a normal system. • Boot policy is enforced by the secure boot chain. • Root does not get to override it.
Changing these policies requires booting into Recovery and modifying the machine’s security mode (Reduced Security). Even then, many AMFI protections remain active.
So the old “just set amfi_get_out_of_my_way and reboot” trick that worked on older Intel systems does not translate cleanly to Apple Silicon machines.
As a result, signing a tool with task_for_pid does not magically give you the ability to attach to arbitrary system processes on modern macOS. Without weakening the system’s boot security policy or patching the kernel, AMFI-protected processes remain non-attachable by design.