OSX User level application Preferences (plist) are not loaded after binary modification

Question

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.

Answer 1

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

https://stackoverflow.com/a/40705362/422797

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.