I am working on a project that requires to modify an existing OSX application's dylib binary (few bytes to correct an obsolete URL). I do not have access to the application source code nor the code signing certificates. After patching the application everything works perfectly except it does not load its application plist file from ~/Library/Preferences.

Even without patching/modifying the application if I do:

codesign -s "Local Codesign" -f ./lib<name>.dylib

and execute the application it does not read its properties from

~/Library/Preferences/<application id>.plist

including previously opened files or connected servers. If I copy back the original (developer signed) dylib then everything works fine: properties are read back again.

One strange thing: even with my local signed binary which is unable to read the plist file if I change something the changes are written back. So if this is an OSX security related stuff seems it's only affects reads.

Now my questions and assumptions:

  • Am I right when I am assuming that this is some kind of OSX security mechanism that ensures application plist data cannot be accessed from a non-same-developer signed binary? If yes, why can it write and protects reads only?
  • Does any of you find similar issue when modified an OSX binary?
  • How can I debug this behaviour?
  • And yes: any solutions?

Any comments and feedbacks are welcome.

  • how did you determine that the application does not load the plist from that location and that it did before?
    – Igor Skochinsky
    Commented Apr 29, 2018 at 16:02
  • If I change the signature of any of the libraries then the UI does not show "Recent files" and "Recent connections". If I change back the libraries to the original signed ones everything works well. Also, in case I change the libraries I see security exceptions in OSX Console: code requirement check failed (-67063), client is not Apple-signed. Commented Apr 30, 2018 at 7:08

1 Answer 1


I could find some hints by googling the error message, e.g.:


Looks like it's not related to the plist but possibly to some security APIs (e.g. keychain access or SecCodeCheckValidity) used by the program. Apparently the OS caches signing info based on the file's vnode, and if you replace it in-place that invalidates the signature. The linked answer suggests some workarounds.

  • This was one of the issue. After I changed the process flow to 1) move the file 2) sign it in /Application folder with a proper apple signed signature it was able to read the plist. Thanks! Commented May 18, 2018 at 19:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.