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.

[norio-nomura]

Notes for someone who creating new.

• Placing plugins under /Library/* have a possibility of freeing from injecting it to containers of sandboxed apps.
• Resume apps on login is happened before launching SIMBL Agent.
• If placing .osax and/or plugins under /System/* while SIP disabled, cann't we load it after SIP enabled on OS X 10.11?

[therealmarv]

related I think because it was also previously mentioned here: http://blog.binaryage.com/el-capitan-update/ Total Finder will stop supporting OS X 10.11+ Still hope we will find a way :)

[norio-nomura]

I noticed that @d235j's test is similar to original SIMBL. So I tested SafariStand 8.0.211 with original SIMBL-0.9.9 on OS X 10.10.4 beta 4, and confirmed it works.

[d235j]

In order to fix this we'd probably just need to fix up the plists, and make it so that EasySIMBL puts its ScriptingAddition in /Library and not ~/Library. If I have time I'll take a look.

[w0lfschild]

Yup @d235j and it would seem as if this security measure is present now in 10.8.5, 10.9.5 and 10.10 versions prior to 10.10.4.

I know for sure it's in the update for 10.9.5 and 10.10.4 because I've got a bunch of emails about it already.

So EasySIMBL is basically dead... RIP :-1:

[d235j]

@w0lfschild: what entry are you referring to in the list? I can't seem to see it, at least at first glance.

As I said, since it works from /Library, this would probably be the best way to go about it. I don't think using /System/Library is preferable — at least for now.

[w0lfschild]

@d235j Not sure what entry it is, I just know that bunch of people emailed me saying they installed the new security update 2015-005 1.0 and now cDock (aka EasySIMBL) is not working.

[norio-nomura]

So EasySIMBL is basically dead... RIP :-1:

I agree. I think we can start over from SIMBL-0.9.9 https://github.com/norio-nomura/EasySIMBL/issues/26#issuecomment-117028426

[norio-nomura]

I checked EasySIMBL-1.7.1 on OS X versions updated today.

• On OS X 10.10.4 (14E46), it does not work.
• On OS X 10.9.5 (13F1096), it does not work.
• On OS X 10.8.5 (12F2542), it works.

[d235j]

@norio-nomura: I think it may be better to leave it as-is, but move the ScriptingAddition to /Library (and add logic to request privilege elevation in order to do that when turning on EasySIMBL). In my tests it works from /Library.

[norio-nomura]

@d235j: Placing at /Library/ScriptingAdditions does not work on OS X 10.11 (15A204h) https://github.com/norio-nomura/EasySIMBL/issues/26#issuecomment-117028426 It may be not working on future beta. But if I might do something about SIMBL, I might start over from SIMBL-0.9.9. I will not change EasySIMBL.

[d235j]

@norio-nomura: did you change the EasySIMBL.osax Info.plist to have Context: Process instead of User? I needed to do that to make it work on 10.10.4. On 10.11, System Integrity Protection must be off for it to inject system apps; I haven't tested it yet but I will tomorrow when I have access to a machine running 10.11. (I also made ThreadSafe: False instead of True in the plist, for safety.)

[norio-nomura]

@d235j No, I didn't change Info.plist both of testing on 10.10.4 b4 and 10.11.

[d235j]

@norio-nomura can you try that together with /Library/ScriptingAdditions? (You also have to remove EasySIMBL.osax from ~/Library/ScriptingAdditions or it will attempt to use that copy and fail.) I could not get it to work at all until I made this change, even with manual injection with an AppleScript, but it seems to work when set up that way on 10.10.4 at least.

[norio-nomura]

@d235j I'm using original SIMBL-0.9.9 on my testing. Because EasySIMBL has some unnecessary functions for placing at /Library/ScriptingAdditions.

[d235j]

@norio-nomura: I also had to delete EasySIMBL.osax from ~/Library/ScriptingAdditions. I'll summarize what it took to make it work:

1. Modify the Info.plist as described above.
2. Install and turn on EasySIMBL as usual.
3. Quit the EasySIMBL app.
4. Copy EasySIMBL.osax to /Library/ScriptingAdditions.
5. Delete EasySIMBL from ~/Library/ScriptingAdditions.
6. Observe that it functions. If something puts it back in ~/Library/ScriptingAdditions, it will stop functioning.

the aforementioned AEDebugSends and AEDebugReceives environment variables are useful for testing.

[norio-nomura]

@d235j SIMBL Agent.app copies EasySIMBL.osax to ~/Library/ScriptingAdditions before sending apple events. If target app is sandboxed, it also copies .osax and plugins into their container. Placing at /Library/ScriptingAdditions make those functions are unnecessary.

[d235j]

@norio-nomura Yeah, understood. I don't know if it still works if the target is sandboxed, though. Having the app to be able to turn SIMBL plugins on and off is handy, by the way.

[sambuev]

Can you update EasySimbl to newer version where everything is works under 10.10.4? please

[inket]

@sambuev It's pointless. It's a lot of work for no benefit (besides the plugins management GUI) because SIMBL already works.

And it's even less useful because 10.11 breaks both EasySIMBL and SIMBL without huge workarounds.