It’s been a truism on macOS for some time that the most reviled piece of software on the platform is MacKeeper, but brother-in-arms Advanced Mac Cleaner must be running it a close second.
Advanced Mac Cleaner is produced by PCVark and has many incarnations. Aside from ‘AMC’, it’s also distributed as Mac Tonic, Mac Mechanic, Malware-Crusher, Mac Optimizer and now, the most recent form we’re seeing, Mac Auto Fixer.
Like all the other forms of AMC, this app gets bundled in with fake Flash installers and writes itself all over your Mac to multiple places inside your user and local domain Library folders. Here’s a 40-second video showing how Mac users get tricked into installing AMC and its fake virus scanner:
For those of you that want to remove Mac Auto Fixer and related manually, here’s a list of most of the paths you should look for:
/Applications/Mac Auto Fixer.app
/Library/Advanced Mac Cleaner
/Library/Application Support/Advanced Mac Cleaner
/Library/Application Support/Mac Mechanic
/Library/Application Support/Mac Tonic
/Volumes/MacAutoFixer/.hlpr/Mac Auto Fixer
~/Applications/Mac Auto Fixer.app
~/Library/Advanced Mac Cleaner
~/Library/Application Support/Advanced Mac Cleaner
~/Library/Application Support/Mac Auto Fixer
~/Library/Application Support/Mac Mechanic
~/Library/Application Support/Mac Tonic
~/Library/Logs/Advanced Mac Cleaner.log
~/Library/Logs/Mac Auto Fixer.log
~/Library/Mac Auto Fixer
You can also save yourself a whole lot of grief by using my shareware troubleshooting tool DetectX Swift, which will not only find all these pesky elements for you, it’ll remove them all for you, too. There’s no requirement to pay, we don’t mind ridding your Mac of this stuff for free!
Most recent update: Mon 3 Sep 2018
Want to remove MacKeeper? The easiest way is to use my free/shareware app DetectX Swift, but if you’re looking to do it yourself, here’s the complete list of all past and current known filepaths.
Bear in mind that DetectX Swift can find other MacKeeper paths that are not on the list due to its internal search heuristics; however, I’ll update this list as new paths come to light. If you happen to find any that are not on the list, please share in the comments!
Thx & Enjoy!
/Library/Security/SecurityAgentPlugins/MKAuthPlugin.bundle -- warning: deleting this file could harm your Mac! Contact me for help.
~/Library/Application Support/MacKeeper 3
~/Library/Application Support/MacKeeper Helper
Bundle Identifiers & Launch Labels
how to uninstall MacKeeper
For small enterprise developers like myself, commercial analytics aren’t really an option. And while there are open source alternatives like UKCrashReporter, I’ve been lucky enough to suffer relatively few crashes and typically just ask users to manually submit crash reports (stored in ~/Library/Logs/DiagnosticReports) as and when they occur.
Choosing a method of collecting crash reports is one thing, but scouring them for useful information is quite another, and the reams of data often included can seem a little overwhelming.
On a good day, your crash report may include a direct reference to the method or function that’s caused the issue, like this one from an early version of my troubleshooting app DetectX Swift:
On other days, though, you might get presented with nothing but a bunch of unhelpful memory addresses:
It’s at this point that you need to enlist the help of the built-in command-line tool atos. In the remainder of this post, we’re going to learn what it does and how to use it to find the line in our source code that caused the crash.
How does atos help?
The beauty of
atos is that it will give you a reference to the source file, function and even line number in your code where the crash occurred. Given that it can do this for a crash that occurred on another user’s machine that you can’t reproduce locally and don’t have access to, this seems like nothing short of magic.
Here’s an example of what
atos might provide from a crash log like the one above:
ViewController.checkReg(isCli:) (in DetectX Swift) (ViewController.swift:4042)
The output from
atos tells me the name of the Swift source file, the name of the function and — here’s the truly wonderous part — even the line number: 4042.
This is all part of the magic of symbollication, which is such an esoteric word I’m not even going to try to spell it again :-). Instead, let’s just get down to the practical nitty-gritty of how to get this kind of data out of our users’ crash reports.
How to use atos
The method is fairly simple and goes like this:
1. Create a folder called “CrashWork”.
2. Go to Xcode’s ‘Organizer’, and right-click on the archive of the version of the app that crashed.
Choose “Show in Finder”. That takes you to the
.xcarchive file in Finder, from which right-click again and choose “Show Package Contents” to open the package:
3. Click on the
.dSYM file and make a copy of it. Switch back to your CrashWork folder and paste the copy in there. Grab a copy of the same version of your app that crashed (you can also get that from the Products folder in the .xcarchive package, if you don’t have one handy elsewhere) and place it in the same folder:
Important: Be sure you’re working with the same version of your app as the user;
atos needs that to match up the addresses in the crash report, and any other version will produce incorrect results or an error.
4. It’s now time to head on over to the Terminal.
cd into your CrashWork directory:
5. The format of the command is generally going to be like this (see man atos for options):
atos -o <path to executable> -arch x86_64 -l <load address> <address>
<path to executable> is the path all the way to the Mach-O binary in your app bundle in the CrashWork folder, so the path in my example looks like this:
atos -o DetectX\ Swift.app/Contents/MacOS/DetectX\ Swift -arch x86_64 -l <load address> <address>
You need to be careful to get the
<load address> and the
<address> the right way around. They are the reverse order of what you see in the crash log:
Now my complete example looks like this:
atos -o DetectX\ Swift.app/Contents/MacOS/DetectX\ Swift -arch x86_64 -l 0x10a10e000 0x000000010a16a601
6. Hitting ‘return’ produces the magic:
Earlier this year, Digita Security’s Patrick Wardle took apart a cross-platform backdoor trojan he nicknamed ”ColdRoot’. Wardle was retro-hunting possible malware by searching for apps on VirusTotal that access Apple’s TCC privacy database.
For those unfamiliar, TCC.db is the database that backs the System Preferences > Security & Privacy | Accessibility preferences pane and which controls, among other things, whether applications are allowed access to the Mac’s Accessibility features. Of interest from a security angle is that one of the permissions an app with access to Accessibility can gain is the ability to simulate user clicks, such as clicking “OK” and similar buttons in authorisation dialogs.
One particular comment in Wardle’s article caught my eye:
there is no legitimate or benign reason why non-Apple code should ever reference [the TCC.db] file!
While in general that is probably true, there is at least one good reason I can think of why a legitimate app might reference that file: reading the TCC.db used to be the easiest way to programmatically retrieve the list of apps that are allowed Accessibility privileges, and one reason why a piece of software might well want to do that is if it’s a piece of security software like DetectX Swift.
If your aim is to inform unsuspecting users of any changes or oddities in the list (such as adware, malware or just sneaky apps that want to backdoor you for their own ends), then reading TCC.db directly is the best way to get that information.
Just call me ‘root’
Since Apple put TCC.db under SIP protection subsequent to my reports on Dropbox’s user-unfriendly behaviour, apps are no longer able to write to the database via SQL injection. An app with elevated privileges can, however, still read the database. A sufficiently privileged app (or user) can output the current list with:
sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db 'select * from access'
On my machine, this indicates that there are twelve applications in the System Preferences’ Privacy pane, all of which are enabled save for two, namely LaunchBar and Safari:
We can see from the output that LaunchBar and Safari both have the ‘allowed’ integer set to ‘0’ (the middle of the three values in “0|0|1”) , whereas all the other apps have it set to ‘1’ (“0|1|1”).
It’s not clear to me why reading the database should require privileges. Certainly, Apple have provided APIs by which developers can test to see if their own apps are included in the database or not. The AXIsProcessTrusted() global function, for example, will return whether a calling process is a trusted accessibility client (see AXUIElement.h for related functions):
However, there remains a case (as I will demonstrate shortly) where developers may well need to know whether apps other than their own are, or are not, in the list. Moreover, there doesn’t seem to be any obvious vulnerability in allowing read access to that data, just so long as the write protection remains, as it does, in place.
The use case for being able to read the TCC.db database is clearly demonstrated by apps like DetectX Swift: security apps that conform to the principle of least privilege, always a good maxim to follow whenever practical. Asking users to grant elevated privileges just to check which apps are in Accessibility is akin to opening the bank vault in order to do an employee head count. Surely, it would be more secure to be able to determine who, if anyone, is in the vault without having to actually take the risk of unlocking the door.
Did they put a CCTV in there?
Without direct access to TCC.db, we might wonder whether there are any other less obvious ways by which we can determine which apps are able to access Accessibility features. There are three possibilities for keeping an eye on bad actors trying to exploit Accessibility without acquiring elevated privileges ourselves, each of which has some drawbacks.
1. Authorisation dialogs
The first is that we can read the property list that records all invocations of the Accessibility authorisation dialog, without admin rights:
defaults read ~/Library/Preferences/com.apple.universalaccessAuthWarning.plist
That gives us a list of all the apps that macOS has ever thrown the ‘some.app would like permission to control your computer’ dialog alert for, along with an indication of the user’s response (1= they opened sys prefs, 0= they hit Deny).
This list could prove useful for identifying adware installers that try to trick users into allowing them into Accessibility (looking at you, PDFPronto and friends), but it’s main drawback is that the list is historical and doesn’t indicate the current denizens of Accessibility. It doesn’t tell us whether the apps in the list are currently approved or not, only that each app listed once presented the user with the option of opening System Preferences and what the user chose to do about it at that time.
2. Distributed Notifications
The second option is that developers can register their apps to receive notifications when any other application gets added or removed from the list with code similar to this:
DistributedNotificationCenter.default().addObserver(self, selector: #selector(self.accessibilityChanged), name: NSNotification.Name.init("com.apple.accessibility.api"), object: nil)
This ability was in fact added to DetectX Swift in version 1.04.
However, Apple hasn’t made this API particularly useful. Although we don’t need elevated privileges to call it, the NSNotification returned doesn’t contain a userInfo dictionary – the part in Apple’s notification class that provides specific information about a notification event. All that the notification provides is news that some change occurred, but whether that was an addition or a deletion, and which app it refers to, is not revealed:
Even so, notification of the change is at least something we can present to the user. Alas, this is only useful if the app that’s receiving the notification is actually running at the time the change occurs. For an on-demand search tool like DetectX Swift, which is only active when the user launches it, the notification is quite likely to be missed.
It would be nice, at least, if Apple would provide a more useful notification or an API for developers wishing to keep their users safe and informed. The lack of a userInfo dictionary in the notification was apparently reported as a bug to Apple several years back, but I suppose it could always use a dupe.
3. AppleScript – everyone’s favourite ‘Swiss Army Knife’
There is, as it turns out, a third way to reliably get exactly all the info we need about who has access to Accessibility. We can use AppleScript to return a complete list of apps in Accessibility that are enabled. Note that the output of this unprivileged script, shown here in the results pane of Script Debugger, returns a more readable version of the same list of apps we obtained from the privileged sqlite3 query of TCC.db, minus Safari and LaunchBar, which as we previously noted were not enabled:
Fantastic! There’s just one problem. While this AppleScript does not require blanket elevated privileges to run – in short, it doesn’t require an administrator password – it does need to be run by an app that is itself already in the list of Accessibility apps. If you have a script runner like Apple’s Script Editor, or third-party tools like Script Debugger or FastScripts, already approved in Accessibility, then you can run it without authorisation. It’s also worth noting that the script relies on launching and quitting System Preferences, which it attempts to do as quietly as possible.
As for DetectX Swift, I may consider adding something like this to a future version as an option for users who are happy to add DetectX to the list of apps in Accessibility.
Have your own tips about accessing TCC.db? Let us know in the Comments!
Featured pic: Can’t STOP Me by smilejustbcuz
If you’re a regular user of DetectX Swift (DTXS), you’ll be familiar with the Folder Observer function. Although DetectX has always been and will remain an on-demand search tool in principle (i.e., it doesn’t do anything unless you launch it), the Folder Observer adds the capability to alert you and optionally launch DTXS if any items are added or removed from your Launch folders.
This is a useful feature which removes the need, for example, to set Folder Actions or other scripting solutions on the folders which are most likely to be written to in the event of an adware or malware attack. However, as some users (and even myself!) have noticed, the Folder Observer can, at times, be a little irritating.
For example, here at sqwarq I have Little Snitch installed, which puts daemons and agents in both of the local domain Launch folders. The annoyance occurs whenever Little Snitch requires an update. When that happens, the daemon and agents will get written to, and DTXS will dutifully throw me an alert:
Great, except that I don’t really want alerts for software I already trust. I only really want to know about stuff that I don’t know is already in those folders. Of course, I can uncheck the preference for the Folder Observer entirely to stop all alerts, but that then deprives me of the security of being warned of things that I do want to be informed about.
Fortunately, there’s a simple solution that will allow you to tame DTXS and customise the alerts to your personal needs.
1. Go to DetectX Swift > Preferences and click the ‘Observer’ tab.
2. Click the ‘Ignore Keywords’ checkbox (you need to be a registered or licensed user).
3. Click the ‘Edit’ button, and add the launch label of each item you want to ignore in a comma-separated list.
4. Click the ‘OK’ button to finish.
You can get the launch label either by reading it from each of the property lists that you want to ignore, or directly from DetectX Swift’s Profiler. The linked video shows one way you can do that.
While troubleshooting a user’s mac the other day, I happened to come across a curious line in one of the logs:
After a bit of digging, it occurred to me that this and the other flags being sent in the process command were possibly Preferences or Settings in the Chrome.app. Looking at
chrome://settings/privacy revealed, of course, Google’s phishing and malware protection setting, ‘Protect you and your device from dangerous sites’.
Here it is set to ‘On’, which is the default setting:
A quick test proved that setting it to ‘Off’ produced the `—disable-client-side-phishing-detection’ flag in the browser’s process output. Setting it back to ’On’ and relaunching the browser produced no output, confirming my theory.
A quick message to my user also confirmed that he wasn’t aware that phishing protection had been disabled, and to the best of his memory, had not been disabled by himself.
A simple preference setting
That got me to wondering whether that setting could be turned off programmatically by another, possibly malicious, process. To my surprise, it turns out that it’s trivial to do so.
All Chromium browsers have a Preferences file located in their Application Support folder. Usually this is within another folder called ‘Default’, but not always. Chrome and Vivaldi, for example, have it there, but Opera (and Opera Developer) store the Preferences file at the root level of their respective support folders.
The file contains the setting for whether the Phishing protection should be enabled or not. To determine how the preference was encoded in the file, I made a copy of the current Preferences file, toggled the setting, then made another copy. BBEdit’s ‘Find Differences’ function quickly told me the name of the key (if you don’t have BBEdit, you can also use Xcode’s FileMerge to run diffs, though it isn’t as pretty or as full-featured):
Again, there are differences among browsers. As shown above, Opera uses the key “fraud_protection_enabled” which takes a boolean. Chrome and Vivaldi, on the other hand, use a “safebrowsing” key which takes an array of key-value pairs, with the first item of the array being the key “enabled:”, and taking a bool for its value, like this:
With this information, it’s a pretty simple thing for another process running under your username to write to the Preferences file and turn off the built-in protections.
What about Safari?
Safari isn’t vulnerable to quite the same tactic as it doesn’t store its preferences in the same way. However, it’s even easier to defeat Safari’s ‘Warn when visiting a fraudulent website’ setting:
Apple hardened some of Safari’s preferences (like setting the Home page) some time ago to stop adware from making unauthorised changes, but this one is still unprotected in the current public release of macOS High Sierra. A one-liner in Terminal removes the preference:
defaults write com.apple.Safari WarnAboutFraudulentWebsites 0
What can you do?
The ease with which these protections can be surreptitiously turned off in all major browsers is a worry. And let’s face it, who would notice if this setting was quietly turned off? In both Chrome and Safari, the change takes effect immediately and does not even require a restart of the browser.
Fortunately, my shareware app DetectX Swift will warn you if browsing protection is off when you run a search and prompt you to turn it back on. To ensure that all insecure pages have been removed after turning the setting back on, DetectX Swift will continue to show the warning until you restart the browser and execute another search.
The protection covers all the browsers mentioned above. If you’re running some other browser and would like to know if it’s similarly vulnerable, drop a line in the Comments or contact Sqwarq Support and request support for your browser to be added.
Stay safe, folks! 😀
Featured pic: Nature by PichieArt
Xcode 10 beta has got some nice new touches (as well as the return of some old favourites, hello again the code folding ribbon!), but one that might disorientate you at first is the absence of the Snippets, Objects and Media libraries that typically live in the bottom right corner of IB in the Utilities sidebar.
I’ve always found this position and size to be somewhat awkward, so I’m overjoyed to find that Apple have now given the libraries their own floating panel. You can access the libraries either with the keyboard shortcut Command-Shift-L, or by clicking the button that’s now in the top-right of the toolbar, just to the left of the editor buttons.
The new button is context-sensitive, so you’ll notice you can’t access code snippets when in Interface Builder, and you can’t access the Objects library when you’re in the text editor. Makes sense to me!
If you need to teardown your current login session and get your mac up and running in a hurry, here’s a neat little trick that should take you from login to logout and back again in as little as 10 seconds. And I’m not talking about SSD-only Macbook*’s either. That’s the time I achieved on a clunky late-2014 iMac with a sluggish old mechanical 1TB Fusion drive.
Forget the Apple menu and the ‘Restart…’ menu option and don’t worry about how many login items or startup scripts you’ve got either, this method will slice through them all.
We’re going to leverage a little-known command in the
launchctl command line tool that will teardown and rebuild your login sessions in an instant. To see for yourself, execute this in Terminal:
sudo launchctl reboot userspace
I was astonished at just how fast the reboot is. What’s even nicer is you don’t lose any unsaved data either. This command restores all current window sessions (similar to checking the ‘Reopen windows when logging back in…’ option in the normal Restart dialog) but without the delay of the standard restart procedure.
See the man launchctl page for more options on using its
featured picture: Steampunk boots by Imp0s5ible
I often need to check version numbers of apps I’m using from the ‘About’ menu. However, unlike ‘Preferences’, ‘Hide’ and ‘Quit’, the About menu doesn’t have a default hotkey.
Normally, it’s no problem to add a menu hotkey through System Preferences > Keyboard > Shortcuts, but you can’t do that for the ‘About’ menu. That’s because the Shortcuts requires an exact menu name, and the ‘About’ menu is actually postfixed with the name of each app, so there’s no way to specify the menu universally.
The script is quite simple, but does require System Events, and that means you need to make sure that System Events itself or the app that’s going to run the script has Assistive Access allowed in System Preferences’ Privacy pane.
The raw text for the script is available from my pastebin here.
Popular macOS package manager Homebrew is a great way to easily install and manage 3rd party software. As their own tag line goes, “Homebrew installs the stuff you need that Apple didn’t.”
However, installing it recently on a new setup brought something odd to my attention. An oddness, it turns out, that is a gaping security flaw.
do yourself a favor and install to /usr/local. Some things may not build when installed elsewhere. One of the reasons Homebrew just works relative to the competition is because we recommend installing to /usr/local. Pick another prefix at your peril!
Peril indeed, for those that follow that advice. Homebrew’s installer is kind enough to tell you what is happening, but it seems neither the installer nor the developers have any idea just what this means:
As soon as I saw that, the words ‘sudo piggyback!’ sprang to mind. But wait, the brew docs say installing into
/usr/local is safe, look at the screenshot at the top of this post from their FAQ, which says
3. It’s safe
Apple has left this directory for us. Which means there is no /usr/local directory by default, so there is no need to worry about messing up existing tools.
Ah, wrong kind of safe. Here, we’re not concerned with ‘messing up’ existing tools, but spoofing system tools that live further down the path search hierarchy behind the user’s back. Also, what the brew docs fail to mention is that although Apple may have “left this directory for us”, they didn’t intend for you to change its ownership and make it writable by just anything in userland. Other 3rd party software plays correctly with
usr/local and doesn’t change its ownership permissions.
Why does brew do this? According to the docs, they want to avoid using
sudo because of the security flaws it contains (it’s true,
sudo does have security issues); unfortunately, the proposed solution is far worse and creates a far bigger security hole.
The brew docs seem to be unaware of the danger, however, only noting that:
If you need to run Homebrew in a multi-user environment, consider creating a separate user account especially for use of Homebrew.
But that just isn’t going to cut it. We’re not worried about other users, but processes running as our user that can now attempt to elevate their own privileges by stealing the admin user’s password.
How’s that possible?
To understand the crucial error being foisted upon Homebrew users here you need to understand a little about the program search path on macOS and other unix variant operating systems.
This is basically a list of directories that the shell environment uses to find programs. It’s a convenience so that no matter what directory you’re in in the shell, you can execute commands without having to specify the full path to them. This is why you can type, say,
uptime in any directory and the program will run instead of having to type
The program search path hierarchy is saved in a variable called
PATH. You can see its value by typing
echo $PATH at the command prompt:
A more reader friendly version is output by doing
The order is ‘first come first served’; in other words, when you type a command on the command line, the shell will look for it first in the first path in the list. If it doesn’t find it there, it will move to the next path in the list and so on. However, and here’s the crucial bit, it will stop at the first hit, and execute that command.
As you can see from the above,
/usr/local/bin occurs before the other directories, which means it gets searched first. So, if you had an executable in there called
uptime that didn’t do what the normal uptime does, but say, advanced your clock by 1hr, then when you (or anyone else on the system) typed
uptime in the command line, instead of getting the output of how long the system has been booted, you’d get your clock going forward an hour. The system doesn’t know which
uptime you (or any other user) intended if you don’t specify the full path; it just executes the first
uptime it finds in the program search path.
If you’re still thinking “so….???”, let me add two more little spicy notes into this melting pot:
i. Since Homebrew changes the permissions on
/usr/local/bin to the user (see the preceding screenshot), the user (or any process running as the user) is able to write files to it and give those files executable permissions.
sudo is a program that lives in
/usr/bin, the path that is after (Danger! Danger!)
/usr/local/bin. Now if you (or someone else, or some other program) were to place a program called
/usr/local/bin, then every time you typed
sudo it would be that program that would be executed, not the real one.
Hopefully the picture is becoming clearer now, and I apologise if I’ve laboured the point for those of you that saw it right away, but this is worth being clear about. This hypothetical
sudo program could easily capture your password before passing on your commands to the real
sudo and you’d be none the wiser (until, of course, the malicious actor behind it chose to use your password for their own amusement or benefit!).
Oh, did I say ‘hypothetical’? Well, here’s a short video of me actually doing it in my VM (yes, folks, I know you don’t need
sudo to execute
uptime, it’s just an example; the command could be anything, such as
sudo mkdir -p /Library/...):
Sure enough, I was able to use a simple script to steal the user’s password. In this case, an admin password, but it could and would have been the password of whoever is set as the owner of
/usr/local/bin as a result of Homebrew’s recommended installation. Even for non-admin users this is a worry as the login password of course allows full access to the user’s Login Keychain.
Eh, run that by me again / tl;dr.
Installing Homebrew as recommended means that from then on, any process or application you launch can write anything it wants into the first directory that gets searched for command line binaries, change its mode to
execute and give it the same name as a system binary. It will then run instead of the system binary whenever you type the program with the same name in the command line (unless you type the full path to it). The potential for exploitation is vast. Few people if any ever type the full path to workaday binaries like
sudo and many others. And as shown in my example, any of these could be hijacked to perform different operations thanks to the way Homebrew is installed. This can be done and cleaned up in such a way that you’d never know it had happened.
What can you do about it?
My advice is if you’re running Homebrew from
/usr/local/bin you should
i. Uninstall Homebrew; follow the instruction here under ‘How do I uninstall Homebrew?’ This will remove all your installed packages.
ii. Reset the permissions of
/usr/local/binback to ‘wheel’.
sudo chown root:wheel /usr/local/bin
iii. Reinstall Homebrew and choose a location within your home folder.
iv. You should probably change your login password just to be on the safe side.
Above all, stay safe folks! 🙂