Endpoint code signature failure

I'm trying to build and run the Endpoint sample code from Apple's "Monitoring System Events with Endpoint Security", but the extension keeps crashing apparently because the code signature is invalid.

Any help would be appreciated.

Details:

Because our endpoint entitlement isn't approved yet, I've disabled SIP.

I am running on the latest macOS 13.0 beta (22A5295i).

The extension is installed, and I grant it full disk access.

systemextensionsctl shows it is installed, but launchctl shows its status is -9

Console shows a crash because Code Signature Invalid

Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid)) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: CODESIGNING 1 Taskgated Invalid Signature

I've set the Team ID to my organization. The signing certificate is my Apple Development certificate.

Any other recommendations?

Accepted Reply

Disabling SIP should allow you to test an ES sysex without getting approval to use the ES entitlement. However, the last time I tried to do this I ran into a bug and, AFAIK, that’s not yet been fixed. See this thread for the details and the workaround.

Note that this only affects folks building a sysex. If you’re building your ES client as a daemon, you generally don’t run into this issue.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

  • Thanks!

    sudo nvram boot-args="amfi_get_out_of_my_way=0x1"

    did the trick.

  • A note of warning: I booted back into Monterey (I have both Monterey and Ventura beta in different volumes on the same Mac), and amfi_get_out_of_my_way setting of 0x1 is set there too. That is, setting amfi_get_out_of_my_way in Ventura affects Monterey (same Mac, different volumes). Before leaving Ventura and booting back into Monterey, I now set amfi_get_out_of_my_way to 0x0. Hopefully that keeps Monterey protected when I am working in that OS.

Add a Comment

Replies

Disabling SIP should allow you to test an ES sysex without getting approval to use the ES entitlement. However, the last time I tried to do this I ran into a bug and, AFAIK, that’s not yet been fixed. See this thread for the details and the workaround.

Note that this only affects folks building a sysex. If you’re building your ES client as a daemon, you generally don’t run into this issue.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

  • Thanks!

    sudo nvram boot-args="amfi_get_out_of_my_way=0x1"

    did the trick.

  • A note of warning: I booted back into Monterey (I have both Monterey and Ventura beta in different volumes on the same Mac), and amfi_get_out_of_my_way setting of 0x1 is set there too. That is, setting amfi_get_out_of_my_way in Ventura affects Monterey (same Mac, different volumes). Before leaving Ventura and booting back into Monterey, I now set amfi_get_out_of_my_way to 0x0. Hopefully that keeps Monterey protected when I am working in that OS.

Add a Comment