Big Sur on the M1 processor seems to prevent modified binaries from running. For instance, a simple C hello world: #import <stdio.h> int main(void) { &#9;printf("Hello World!\n"); } If I compile this with Clang and run it, everything works as expected. However, if I go into a hex editor and change the 'H' => 'h' (or something else trivial), the kernel immediately sends a SIGKILL, i.e. ➜&#9;~ ✗ ./a.out [1]&#9;&#9;943 killed&#9;&#9; ./a.out This is expected, since modifying the binary's hex would invalidate the signature, but when I try to resign the executable, I get the following non-descipt error: ➜&#9;~ ✗ codesign -s zbaylin a.out a.out: the codesign_allocate helper tool cannot be found or used From other posts I've seen online, this is often the result of codesign_allocate not being in one's path, but I know codesign_allocate is in my PATH, and I am able to sign unmodified executables, but any binary that has been modified refuses to sign. Is this behavior documented anywhere, and would I be able to sign these executables? I should mention that all of this works on my 2019 MacBook Pro (x86, obviously), so I think it has something to do with the M1 in particular.