EasySIMBL stopped working on 10.10.4 b4

[antons]

Just restarted to 10.10.4 b4 and noticed that EasySIMBL stopped working. All checkboxes are enabled, but the plugins are not injected into apps.

[norio-nomura]

It seems OS X 10.10.4 b4 (14E26a) has restricted API that EasySIMBL (and original SIML) depend on with some undocumented conditions.

2015/05/27 12:57:34.421 com.github.norio-nomura.SIMBL-Agent[41695]: AppleEvents: Send port for process has no send right, port=( port:32047/0x7d2f rcv:1,send:0,d:0 limit:5) (findOrCreate()/AEMachUtils.cp #526) com.apple.main-thread

[d235j]

This warning appeared on previous 10.10 versions. So I doubt this is why it fails.

[norio-nomura]

I have been taught that the log is appearing also on OS X 10.10.3. It seems silently failed injecting on OS X 10.10.4 (14E26a) EasySIMBL has ever stopped working while OS X 10.9 Preview as #4, but it works again until final release.

[d235j]

This is a weird one. TotalFinder's injector (source at https://github.com/binaryage/totalfinder-osax) still works, as does FinderPop's (finderpop.com), Default Folder X, Bartender.

This log message does seem related, but doesn't give enough information to be of use.

Apple also changed other major stuff in this 10.10.4 beta — discoveryd was removed and replaced with the older mDNSResponder.

[d235j]

If I make a standalone AppleScript application that sends the appropriate Apple Event to the desired application, the bundles get loaded. Therefore this is a bug in the EasySIMBL Agent.

[norio-nomura]

@d235j Thanks. I'll investigate.

[norio-nomura]

I tested injecting EasySIMBL.osax by using AppleScript as following:

tell application "Safari" to «event ESIMload»

got same errors on both OS X 10.10.3 and OS X 10.10.4 as following:

tell application "Safari"
    «event ESIMload»
        --> error number -1708
    «event ascrgdut»
        --> error number -1708
    «event ESIMload»
        --> error number -10004
end tell
tell current application
    «event ESIMload»
end tell

It works on OS X 10.10.3 (14D131), and not on OS X 10.10.4 (14E26a) :confused:

[d235j]

I also had to change Context: User to Context: Process in the OSAX Info.plist. It works if I send the event using Script Editor, after doing this. If I create an .app of the script, it does require a password. This is probably because this is cross-app scripting. Other injectors (such as FinderPop and the others I mentioned) use Context: Process in the OSAX. They do not require a password.

[norio-nomura]

@d235j Thank you for explanation, After editing Info.plist of EasySIMBL.osax 0.10.10 (bundled into EasySIMBL-1.7.1) and re-codesign it, I got works by AppleScript.

[ylluminate]

So glad to see this guys, thanks for your effort on this! This was a real headache for me today.

Are you releasing a packaged fix soon for this changed over to Context: Process @norio-nomura?

[orbitly]

Any word on when the fix will be released?

[norio-nomura]

Referring information about TotalFinder, I have tried fix. But I have not yet success EasySIMBL working on OS X 10.10.4 (14E26a). :disappointed:

[ylluminate]

Have we asked the BinaryAge guys for input / help? @darwin @sdsykes

[sdsykes]

Don't know why the problem has arisen. You might try using the AESendMessage API rather than SBApplication to send the events.

[darwin]

ScriptingAdditions are fragile.

AFAIK, OSAX bundles should reside in /Library/ScriptingAdditions (probably installed by root/admin) to be first-class citizens with full rights to be injected in all bundles in /Applications. Having them in ~/Library/ScriptingAdditions sometimes works, but I had issues that sometimes the system prevents apple events because of "no send right". I don't remember the details, but I would assume system-level OSAXes can be injected into anything. And user-level OSAXes can be injected only into user-level processes. The exact rules are unknown to me but it is possible Apple made some changes of this mechanism in 10.10.4 (14E26a).

Also one thing which burned me during development is that OSAX bundles are being actively scanned for on the whole filesystem using Spotlight or something like that. So if you have some broken OSAX lying somewhere then scripting additions could pick it up and try inject it instead of good OSAX in Library/ScriptingAdditions folders. So for example installer should not unpack OSAX somewhere into a temp folder and copy it later to the destination. This could confuse the system in rare cases.

In TotalFinder I had a lot of problems related to failed OSAX injections. I decided not to use hihg-level applescript, but send events using AESendMessage, it boils down to: https://gist.github.com/darwin/72be854b54c590d05958

Some dev notes: https://github.com/binaryage/totalfinder-osax/blob/280930f6e3dc96602d31b281a61104da773f2fed/TotalFinderInjector.m#L21-L65

[norio-nomura]

@sdsykes @darwin Thanks for informations, I will try using AESendMessage as first step.

[d235j]

@darwin @norio-nomura It seems that putting the OSAX in ~/Library/Scripting Additions is not the problem since using an AppleScript Editor created application to send the Apple Event still works. This is probably due to how SBApplication is being used.

[norio-nomura]

I have tested using AESendMessage without SBApplication. It works on OS X 10.10.3 and does not work on OS X 10.10.4 (14E26a). Is it needed to change bundle structures for placing OSAX in /Library/ScriptingAdditions? :unamused:

[antons]

@norio-nomura In my (limited) testing, that is the only location that worked.

[antons]

EasySIMBL doesn’t work on El Capitan too, as far as I can see.

[orbitly]

I can report the same, 10.11 (15A178w)

[w0lfschild]

Are you sure about that? It's definitely working for me. Granted not all bundles are working with the new apps (cDock, colorfulsidebar). I believe some apps have moved to swift because I can't class dump the dock executable anymore.

[orbitly]

Neither Flashlight nor Safari Stand work.

[w0lfschild]

That's doesn't mean that simbl isn't working though...

NotificationClear and RadonChrome are both 100% working on 10.11 via easySIMBL.

[antons]

@w0lfschild You’re right, some plugins work. However, I have an app and a plugin that have not changed since 10.10, and yet they fail to load.

09.06.15 16:06:43,511 Gitbox[14462]: Error loading /Users/Anton/Library/ScriptingAdditions/EasySIMBL.osax/Contents/MacOS/EasySIMBL:  dlopen(/Users/Anton/Library/ScriptingAdditions/EasySIMBL.osax/Contents/MacOS/EasySIMBL, 262): no suitable image found.  Did find:
    /Users/Anton/Library/ScriptingAdditions/EasySIMBL.osax/Contents/MacOS/EasySIMBL: open() failed with errno=24

[d235j]

From https://developer.apple.com/library/prerelease/mac/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_11.html#//apple_ref/doc/uid/TP40016227-SW1 :

System Integrity Protection A new security policy that applies to every running process, including privileged code and code that runs out of the sandbox. The policy extends additional protections to components on disk and at run-time, only allowing system binaries to be modified by the system installer and software updates. Code injection and runtime attachments are no longer permitted.

Supposedly this can be turned off from the Recovery partition.

[d235j]

@norio-nomura:

In my testing, it apparently tries to load when in /Library/ScriptingAdditions. However, I don't have a signing key so I can't test it further, as I get this error:

2015-06-13 20:31:41.930 Safari[30755:2250532] Error loading /Library/ScriptingAdditions/EasySIMBL.osax/Contents/MacOS/EasySIMBL:  dlopen(/Library/ScriptingAdditions/EasySIMBL.osax/Contents/MacOS/EasySIMBL, 262): no suitable image found.  Did find:
    /Library/ScriptingAdditions/EasySIMBL.osax/Contents/MacOS/EasySIMBL: code signature invalid for '/Library/ScriptingAdditions/EasySIMBL.osax/Contents/MacOS/EasySIMBL'
Safari: OpenScripting.framework - can't find entry point InjectEventHandler in scripting addition /Library/ScriptingAdditions/EasySIMBL.osax.

EDIT: I found that the old signing key I have still works, so I signed it, and — well, it does work from /Library/ScriptingAdditions!

EDIT 2: I did not have to make any changes to the injection method other than setting Context to Process. I also changed ThreadSafe to NO, because it is not a good idea to assume that the injected SIMBL plugin will be thread-safe!

To make testing easier, open Terminal and run these two commands:

export AEDebugSends=1
export AEDebugReceives=1

Then run Safari from Terminal, as follows:

/Applications/Safari.app/Contents/MacOS/Safari

And you should see all Apple Event activity.

[norio-nomura]

Thanks all for testing on OS X 10.10.4 b4.

I should write about my EasySIMBL usage here. The past two years, I have not used EasySIMBL on my Mac except on testing it. I have no reason to using SIMBL plugins as I needed on my forking EasySIMBL from original SIMBL. I don't have time for fixing this issue in the near future.

Thank you for your understanding.

[rpendleton]

Perhaps this is discussed somewhere else, but is there a reason SIMBL must be injected using ScriptingAdditions? I've always used the DYLD_INSERT_LIBRARIES environment variable. (Although, I guess if an app set this in it's plist, it could override the SIMBL one. And this won't fix 10.11 support with SIP enabled.)

[norio-nomura]

When I forked EasySIMBL, another implementation was exists that using another injecting method. On that time, injecting dynamically was needed for some system processes(e.g. Finder, Dock I don't know DYLD_INSERT_LIBRARIES can be used for such processes.