[solved] Bundling SOUL_PatchLoader

Trying to bundle SOUL_PatchLoader.dylib inside my app bundle’s Frameworks folder and as per Apple’s requirements the binary needs to be signed. Singing works using my credentials but when trying to launch and use the application I get the following.

Crashed Thread:        51  SOUL Compiler

Exception Type:        EXC_BAD_ACCESS (Code Signature Invalid)
Exception Codes:       0x0000000000000032, 0x0000000117afb000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace CODESIGNING, Code 0x2

kernel messages:

VM Regions Near 0x117afb000:
CG image               0000000117af4000-0000000117afa000 [   24K] rw-/rwx SM=PRV  
--> VM_ALLOCATE            0000000117afb000-0000000117afe000 [   12K] r-x/rwx SM=COW  
WebKit Malloc          0000000117b00000-0000000117c00000 [ 1024K] rw-/rwx SM=PRV  


Thread 51 Crashed:: SOUL Compiler
0   ???                           	0x0000000117afb000 0 + 4692357120
1   SOUL_PatchLoader.dylib        	0x0000000111941a62 soul::patch::PatchPlayerImpl::compile(soul::CompileMessageList&, soul::LinkOptions const&, soul::patch::CompilerCache*, soul::patch::SourceFilePreprocessor*, soul::patch::ExternalDataProvider*, soul::patch::ConsoleMessageHandler*) + 9058
2   SOUL_PatchLoader.dylib        	0x000000011193c448 soul::patch::PatchInstanceImpl::compileNewPlayer(soul::patch::PatchPlayerConfiguration const&, soul::patch::CompilerCache*, soul::patch::SourceFilePreprocessor*, soul::patch::ExternalDataProvider*, soul::patch::ConsoleMessageHandler*) + 1016
3   com.deleteandzero.sattern     	0x000000010c2283c7 soul::patch::SOULPatchAudioProcessor::run() + 247
4   com.deleteandzero.sattern     	0x000000010c3fbf9c juce::threadEntryProc(void*) + 300
5   libsystem_pthread.dylib       	0x00007fff6d659109 _pthread_start + 148
6   libsystem_pthread.dylib       	0x00007fff6d654b8b thread_start + 15

Questions:

  1. Packaging SOUL_PatchLoader.dylib, I haven’t come across any docs on how to properly do this. Is this possible, allowed?
  2. Will there be a signed version of the binary at some point?

I’m interested in the smoothest installation process for the user, and bundling is preferred, but maybe I’m just going about this the wrong way.

I still have a couple places I can poke to make sure I’m not doing anything wrong, any suggestions much appreciated.

Thanks

Maybe SOUL_PatchLoader just needs to be built with hardened runtime? Or maybe I can just codesign --options=runtime flag on my end.

Investigating…

@dave96 you had to add a signing step to bundle it with Waveform, right?

IIRC you just need to run your normal signing process on the DLL along with your other binaries.

Still no dice… signing SOUL_PatchLoader.dylib separately or using codesign with --deep option on the app bundle.

Going to try com.apple.security.cs.disable-library-validation in the AM here.

This is how we sign it:
codesign --entitlements "$ENTITLEMENTS_FILE" --force -s "$SIGN_ID" -v "$APP_FILE/Contents/Resources/SOUL_PatchLoader.dylib" --deep --strict --options=runtime

where $ENTITLEMENTS_FILE has this contents:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>com.apple.security.cs.disable-library-validation</key>
	<true/>
	<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
	<true/>
	<key>com.apple.security.device.audio-input</key>
	<true/>
	<key>com.apple.security.automation.apple-events</key>
	<true/>
    <key>com.apple.security.get-task-allow</key>    
    <true/>
</dict>
</plist>
3 Likes

Yes, --entitlements was the missing bit.

Thanks @dave96 @jules