Monthly Archives: November 2015
If you’re not familiar with this junior partner in our troubleshooting suite of apps, App Fixer does a very specific job: it returns any app you select to its default preferences and settings with the click of a button.
It’s raison d’être is largely for those apps that get themselves stuck in some unresponsive state (looking at you anything-Adobe). It also does a neat trick rescuing Safari from Adware on the side. ;).
If you’ve been using App Fixer already and you’re currently running El Capitan, we’re afraid you won’t see an update notice (the blame for that lies with Amazon AWS, but that’s another story). Just go to the App Fixer home page and download directly. We’ll be introducing an in-app updater (Sparkle) in the next release to make future updates more convenient.
With the release of Elite Keylogger Version 1.7.327, we’ve noticed some unexpected changes to how the developers are installing and hiding their work.
Let’s take a quick look at what happens when you install the free demo of this keylogger. First, you’ll notice that the app isn’t codesigned and requires you to override any GateKeeper settings.
Secondly, it’ll ask you for your admin password to escalate its privileges so it can write to wherever it wants in the system. So far nothing new. But here’s where the new release gets interesting.
What it does next is automagically insert itself into System Preferences/Security & Privacy/Privacy/Accessibility without throwing the required authorisation dialogue:
Forcing apps to be in this list if they want to leverage System Events to control a computer was a change brought in with OS X Lion 10.7, and it isn’t supposed to be circumventable.
The idea was that to get in this list, apps were forced to throw an authorisation dialog to get the user’s permission, even if the user had already given the app admin privileges elsewhere.
Unofficially, we’ve heard that Apple had once promised to crackdown on developers who tried to circumvent this security feature and to close any gaps that were exposed. As it is, we’ve not only been aware of a way around this security feature since late 2013, but it seems it’s not just the less reputable that are at it. Dropbox has been inserting itself into the Accessibility list since at least 10.10.5, without asking for permissions (in our screenshot, we never authorised either of these apps to be in this list, nor did we ever unlock the padlock to let them in).
The way that Elite Keylogger does this is through a sql database insertion, you can see the code they use here:
Another interesting development is that Elite’s developers, widestep, are now leveraging a hidden binary called
FScript64 that is placed and hidden with the
chflags -hidden flag set here:
We first saw this binary used in Refog’s Hoverwatch keylogger, but this is the first time we’ve seen the same code shared with other keyloggers. We can only speculate as to why developers from apparently-competing products are sharing code.
A couple of other things to note with Elite: If you drag the app to the Trash, the secret FScript64.osax will be left behind. If you use the uninstaller, the hidden binary will be removed, but another hidden data file will be placed here:
Our troubleshooting app DetectX already knows about both of these files, so if you want to check whether you’ve got rid of both of these or have other keylogger files present, download a free copy from sqwarq.com.
Finally, note that even if you use Elite Keylogger’s uninstaller, the app will remain in the list of Accessibility apps and it will remain in your list of login items. You’ll need to manually remove them both, and the hidden .ek file AND the osax if you didn’t use the uninstaller or didn’t use DetectX to help you remove the crud.
As always, be careful about what you download, use apps like DetectX or FastTasks 2 that can log changes that downloaded apps make to your system, and beware of all apps that require your admin password in order to be installed. There are legitimate reasons for that in some cases, but not many.
The standard method for doing this, either in Terminal or in code (via NSTask) has always been
defaults write com.apple.finder AppleShowAllFiles -bool true; killall Finder.
In every version of OS X from 10.6 thru to 10.10 this works as expected. In 10.11 I see a reproducible though not always consistent bug when using any GUI-wrapped app to toggle this Finder setting. The bug basically ends up with Finder showing the opposite of both what the app shows and what ‘defaults read’ shows (see image above; the value should be ‘1’ when invisible files are visible).
We believe a related bug is that Finder sometimes fails to show the new version of an app in the Finder preview after the app has been updated.
In both cases, there’s a couple of ways to deal with it (albeit temporary until Apple applies a proper cure):
i. log out then log in
ii. issue a ‘killall Finder’ on the command line
iii. purge the RAM then toggle the setting again in whatever app you’re using to toggle invisible files.
We are decidedly not impressed with MacBooster. Ok, we’ll put aside the general complaint that apps like this do very little if anything to improve performance (in fact, in our tests, we find almost always quite the opposite). We have a bigger beef with MacBooster.
Indeed, we rate it even more pesky than it’s obvious inspiration: MacKeeper… 😳
Aside from the fact that MacBooster’s uninstaller leaves a number of executables and other binary files hidden on the user’s system, there’s also the rather cheeky use of ‘com.apple.UninstallerAD” as a bundle identifier in their uninstaller app.
I really don’t think the folks at Cupertino are going to appreciate that, but more importantly the use of a misleading bundle identifier reveals a lot about the developers’ intentions.
Meanwhile, whether you use our apps or not, steer clear of MacBooster.
If you’d rather dig it out yourself than use DetectX, here’s the list of paths we have so far:
~/Library/Application Support/MacBooster 3.0
Version 2.06 is now available.
We’ve added more adware definitions and included MacBooster in the list of commercial apps that DetectX will find and remove.