-
Notifications
You must be signed in to change notification settings - Fork 76
Issues with EasySIMBL and OS X 10.11 El Capitan #26
Comments
I have not yet tested on OS X 10.11, but I think it will be checked by attaching debugger to Gitbox.
and did resume the process. Maybe it will be possible for |
Tested SafariStrand on EasySIMBL with OS X 10.11 Build 15A178w. No dice. |
Runtime protections Injecting code into a process is equivalent to modifying the binary on disk
|
@catlan I’m not sure how rutime protection is related to my question, considering that the issue is only with one app, which loads plugins, but once, and only fails to do it again unless the system is restarted. Other plugins are injected into other apps without any issues. |
Can confirm it continues to not work on beta 2 (15A204h) |
@orbitly: 10.11 developer preview 2 has begun enforcing code injection restrictions. You will need to boot into recovery mode and disable System Integrity Protection for EasySIMBL to work. |
@d235j can you confirm that System Integrity Protection protects all apps from code injection or does it just protect system apps? |
Disabling SIP didn't fix things for me. (TotalFinder on the other hand did start working after disabling it) |
Maybe #25 will prevent EasySIMBL working if SIP is disabled on OS X 10.11. |
Yup even with SIP off on 10.11 (15A204h) I'm not having success with anything loading. |
@norio-nomura It looks like that's probably the problem. I just installed a VM of OS X 10.11. To ensure that SIP was enabled, I tried to create a file in
I was able to inject code into Console, Terminal, TextEdit, ls, and a few others. However, I was not able to inject code into Finder, Safari, or Notes. |
FYI about SIP http://blog.binaryage.com/el-capitan-update/ |
I confirmed that the original SIMBL-0.9.9 placed at Steps of installing SIMBL-0.9.9:
sudo installer -verbose -pkg Downloads/SIMBL-0.9.9/SIMBL-0.9.9.pkg -target /
sudo rm -rf /System/Library/ScriptingAdditions/SIMBL.osax
sudo mv /Library/ScriptingAdditions/SIMBL.osax /System/Library/ScriptingAdditions/
sudo cp -p /System/Library/ScriptingAdditions/SIMBL.osax/Contents/Resources/SIMBL\ Agent.app/Contents/Resources/net.culater.SIMBL.Agent.plist /System/Library/LaunchAgents/
sudo sed -e "s/Library/System\/Library/" -i "" /System/Library/LaunchAgents/net.culater.SIMBL.Agent.plist
After above steps, I confirmed that SafariStand 9.0.215 is injected into Safari 9.0 (11601.1.56) with above setup. Notes:
Added following on 2015/07/02:
Edited on 2015/07/05:
Edited on 2015/09/05:
Edited on 2015/10/02:
|
I wrote a note about injection mechanism of EasySIMBL extended from SIMBL-0.9.9 |
@norio-nomura thanks for the instructions. I was able to compile and run stand with the setup above! |
norio-nomura, how does that demonstrate "SIMBL-0.9.9 working on SIP enabled OS X 10.11" if your very first step is "disabling SIP" and rebooting? |
Because the last step is turning it back on... You only need to turn off SIP to install SIMBL. |
Ah, gotcha, thanks. I really hope we'll be able to keep using SafariStand in OS X 10.11. |
I updated the comment. |
For whatever it's worth, Apple has already stated that changing SIP via boot-args will not be supported in the release version of El Capitan. |
@d235j That's fine, as long as it can still be toggled from the recovery partition. |
@norio-nomura Have you ever encountered an issue where a plugin is injected when the app is launched from Xcode, but not when when launched from Finder? Using original SIMBL with your instructions. |
@antons Enabling debug logging may help you. defaults write net.culater.SIMBL SIMBLLogLevel -int 0 |
@norio-nomura Thank you very much for continuing to check issues, even though you don’t use SIMBL yourself. I’ll leave this for anyone who may encounter the same issue. Unfortunately the logs weren’t helpful. From Finder.
From Xcode.
|
Sufl, SafariStand has nothing to do with the Finder Sidebar colors. That is handled by another SIMBL plug-in. And there are a few out there that have enabled this in the past. Which one are you using? And, are you sure it's even compatible with OS X 10.11? Probably not. XtraFinder is. Try that. |
@Sufl +1 for XtraFinder - have not tried Finder Sidebar colors but they're a supported option. Apologies to everyone else for getting so off-topic here. |
Thank you everyone for your help. I thought #26 (comment) was what you had to do to get the colorful Finder sidebar back in El Capitan as this post gave the solution to that for Yosemite. Yes I successfully got the colored Finder sidebar back using XtraFinder but it only works with SIP disabled and I thought it might be best to have it enabled. I have spent days searching for other ways to get the color back in Finder and trying various things but no joy which was why I was asking for help here as it helped me before. I had thought installing SIMBL, as described above, was the answer but it seems not. If there is any possibility that Finder's color can be returned then I would be most keen to hear it. Thanks again. |
@Sufl The return of the color icons is unlikely. That was a deliberate change by the Finder and OS X designers. I (and many people) actually like the change but can understand that some people don't. Having said that, color icons on the Finder's sidebar, for the foreseeable future, will have to rely on hacks and workarounds, and SIP will always prevent them. As such, it is up to you to choose which you want more: color icons or SIP. :) Cheers! |
You can use XtraFinder with SIP on. https://www.reddit.com/r/OSXTweaks/comments/3o3h6k/question_is_there_actual_demand_for_more_native/cvuxvtq |
Dear w0lfschild, you did it for me and I think you are a miracle worker and wonderful. Your answer did the trick for me and, unbelievably, I have got my colorful Finder sidebar back - even after closing down, unlike the Yosemite fix I got earlier on here. So I am absolutely delighted because I had latterly given up. That trick was magic and I thank you so much for your help. You have made me VERY happy :-) |
Just tried XtraFinder Unfortunately, doesn't work after you turn SIP back on.
So XtraFinder works if you are okay with keeping SIP disabled. @Sufl - I am guessing you kept SIP off for XtraFinder to keep working? |
PS @w0lfschild — I use cDock2. good stuff. thanks for that. |
Yes that was the problem for me too, mdaddy, till I tried w0lfschild solution, above, which allowed me to have colorful Finder sidebar icons with SIP ENABLED via XtraFinder! I still can't believe it. I keep clicking on Finder to see if it is still true. And it is. I had tried cDock2 too but there was no option in it for Finder colorful sidebar icons in El Capitan which was what I had wanted. But now I have that with the solution just mentioned - with SIP enabled. So now I've got the best of both worlds. |
boom. that was it. I have XtrafFinder running, with SIP on. thanks @Sufl and @w0lfschild |
Let me preface this by saying that I know nothing about any of this stuff, but I am generally good at following directions. Anyway, I recently upgraded to OS X 10.11.3 and am trying to get Afloat to work again in Safari for the fairly pedestrian purpose of keeping a Twitch.tv chat window visible in overlay while playing computer games in fullscreen. First, I deleted all previous SIMBL and Afloat files and followed @norio-nomura's instructions posted June 30, 2015, to reinstall SIMBL-0.9.9. Next, I reinstalled Afloat from here and later followed @w0lfschild's directions posted Oct. 24, 2015, replacing "XtraFinder.osax" with "SIMBL.osax" where applicable. I also followed @w0lfschild's directions from here, replacing "NotificationCenter" with "Safari" and "Snow Leopard" with "El Capitan." End result: Afloat works in Safari only if I boot up with SIP disabled. (Which, I gather, is not preferable to having SIP _en_abled.) Any ideas? (Preferably simple and clearly-explained ones?) |
Using @norio-nomura's instructions from June 30th, I was able to get Afloat up and running in El Capitan. I disabled SIP, installed SIMBL and Afloat, then re-enabled SIP, and everything initially appeared to work fine. However, Afloat's options now randomly (as far as I can tell) disappear from the What could be the cause of this behavior? |
I'm having issues with this, no matter what I do I can't get a plugin injected without using Applescript to send the inject SIMBL event. Any ideas? Also, I need to check the use SIMBL box in EaseSIMBL. This seems different from the other posts I've read. I get this error in the console:
|
It seems like one way around this without disabling SIP would be to write a SIMBL kernel extension that specifically enables SIMBL's functionality. |
@alexchandel Sorry but that doesn't exactly work. System Integrity Protection blocks unsigned kext. You'd still have to partly disable System Integrity Protection. |
AFAIK, A certificate for signing kext can't be get usual way. We need to submit request to apple by e-mail. I don't yet try that. |
I wouldn't bother. Spyresoft tried this with DockMod and their signing was revoked (after being approved) and their kext was added to a kext blacklist that was silently pushed out to all Macs. Now Sypresoft and DockMod are abandonware as their site has gone down and all traces of them vanished. http://enterprisemac.bruienne.com/2016/03/04/kext-friends-forever/ |
@w0lfschild Thanks for information. I didn't know about the incident of DockMod. |
@w0lfschild right, a certificate would be required. But there are several open source kext projects with certificates (tun/tap and osxfuse come to mind). As for DockMod, it seems these tweets:
It seems Apple feared the existence of a kext that could inject arbitrary signed code into processes, or at least feared such a kext would be used for malware. Hypothetically, I think a 3rd party kext for code injection that Apple would approve (and not later revoke) would be one that: limited what injected code could do to a finite list of tasks/features (e.g., adding new menu items to the menu bar, writing to /Library/Caches); was able to prevent injected code from doing anything other than what the kext permitted; could grant or deny a bundle's request to inject code on a per-feature basis, essentially running only parts of a bundle; only loaded injected code from SIP protected files; could move bundles into SIP-protection upon request; and required the user to explicitly tell it (i.e. choose in a SIP-protected, uninjectable GUI) to add a particular file, to explicitly mark (i.e. check in a SIP-protected, uninjectable GUI) which processes it could inject into, and explicitly mark (i.e. check in a SIP-protected, uninjectable GUI) which of the file's requested injection features are to be enabled for each chosen process. This would cover most of the corner cases, and would be consistent with Apple's recent security philosophy of "no implicit permissions." I'm not saying it's easy/possible to limit what injected code could do, but XPC services might be the way to go for that. |
Hey guys, Im trying SIMBL for the first time and all I'm seeing in console is this error Any ideas? I've turned debug logging on but nothing.. |
@alexandre-g consider using mySIMBL. All other SIMBL variants including the original SIMBL do not work properly or at all on the latest releases of macOS. |
@w0lfschild I actually did end up finding mySIMBL last night, and was even going to leave a comment here, but didn't get to it. Great work by the way! Worked perfectly the first time. |
It appears that 10.11b1 is not affected by the issue described in #25.
However, one of my plugins which previously injected into the target app just fine, now has issues.
Plugin is injected into the app only if I do the following.
If I initially turn on SIMBL before launching Gitbox, or quit Gitbox after the first injection and launch it again, the following message is logged into console (and the plugin is not injected).
Any thoughts on what might be causing this?
The text was updated successfully, but these errors were encountered: