App is notarized successfully, but crashes with 'Code Signature Invalid' when loading compiled C binary.

Question

Created Oct ’23

Replies 1

Boosts 0

Participants 2

I'm attempting to notarize and distribute a game built with Love2D. Love2D is an engine which runs games written in Lua and bundled into .love files, which are identical to .zip files. Packaging a game for Mac distribution involves cloning the Love2D Xcode project, providing your built game.love file (the zipped game content), and then signing and notarizing as with any other Mac app (see more on the Love2D wiki: https://love2d.org/wiki/Game_Distribution#Creating_a_macOS_Application).

I'm encountering an issue because my game contains compiled C binaries which the game loads at runtime. These binaries are compiled for MacOS x86 and arm64, and work perfectly in development. I am able to successfully build and sign the game with my Developer ID Application certificate and provisioning profile, but notarization of the game fails because the compiled C binaries are not signed; below is an excerpt from the audit log:

{
  "severity": "error",
  "code": null,
  "path": "Bang_Average_Football.zip/love.app/Contents/Resources/game.love/deps/gifcatlib_arm64.so",
  "message": "The binary is not signed with a valid Developer ID certificate.",
  "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087721",
  "architecture": "arm64"
},

I can sign these binaries using codesign and the same certificate as the Mac app like so (with the correct name):

codesign --sign "Developer ID Application: Firstname Lastname" --verbose=4  gifcatlib_arm64.so

After signing the binaries, the app successfully builds, and is notarized successfully without reporting any code signing issues. Hooray! The issue is that the app doesn't actually run and crashes as soon as it attempts to use any of the now-signed binaries complaining that they haven't been signed correctly. Here's a link to the full crash log; the specific error is below:

Exception Type:        EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid))
Exception Codes:       UNKNOWN_0x32 at 0x000000010a9c8000
Exception Codes:       0x0000000000000032, 0x000000010a9c8000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace CODESIGNING, Code 2

The same error occurs even with Hardened Runtime disabled and 'Disable Library Validation' enabled.

Is there a likely cause of this crash? Why does notarization succeed but the app essentially instacrashes? Have I signed the binaries incorrectly? Is what I'm attempting not actually possible? (can signed and unsigned binaries not really be hotswapped like this?)

Please let me know if there's any more information I should provide.

Thanks,

Ruairi

Boost

Answer 1

DTS Engineer OP

Apple

Oct ’23

Why does notarization succeed but the app essentially instacrashes?

Notarisation’s goal is to block malicious software; it make no guarantees that your app will work, or even pass Gatekeeper.

Your crash report isn’t symbolicated, so it’s hard to be 100% sure what’s going on. However, the crashing thread shows this:

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   dyld     … 0x102574000 + 221640
…
13  dyld     … 0x102574000 + 153092
14  Lua      … 0x102864000 + 437652
15  Lua      … 0x102864000 + 440452
16  Lua      … 0x102864000 + 440452
17  love     … 0x102550000 + 13032
18  dyld     … 0x102574000 + 20724

So, your app started (frame 17) and started bring up the Lua language runtime (frames 16 through 14), which has invoked the dynamic linker somehow (frame 13). I suspect it’s doing this by calling dlopen. The interesting thing is that it then goes on to crash within the dynamic linker itself (frame 0). I believe that dyld is trying to access the load commands of the library being loaded and those have a broken code signature that triggers this failure:

Exception Type:        EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid))

Problems like this are tricky to resolve. One common cause is mentioned in the Code Signing Crashes After Launch section of Resolving Trusted Execution Problems. The best way to rule that out is to:

Run the app to reproduce the problem.
Restart your Mac.
Run the app again, without rebuilding it.

If that resolves this crash, you know that you need to investigate further down this path. If not, this path is a dead end and we can discuss other areas to explore.

Also, this crash is on macOS 12. If you have access to a macOS 14 machine, you should try the shiny new syspolicy_check tool. See the note at the top of Resolving Trusted Execution Problems for some basics.

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

0