Rixstep
	`About \| ACP \| Buy \| Industry Watch \| Learning Curve \| News \| Products \| Search \| Substack`

Home » Learning Curve

OS X Snake Oil

Stuff you don't need and don't want. Don't buy back what you already own.

Get It

Try It

Snake oil: comes from the 19th century practice of selling cure-all elixirs in traveling medicine shows. Snake oil salesmen would falsely claim that the potions would cure any ailments. Nowadays it refers to fake products.
- Urban Dictionary

All personal computing platforms get their share of snake oil. Windows certainly had a rich collection. Many were based on Unix code hastily ported; others exploited false impressions about how the platform worked. This is not to say that all purveyors were scheming charlatans, but at some level, even the most honest of them were at least fooling themselves (and you, the customer, as a consequence).

From file and disk shredders to memory optimisers to generic system cleaners, it was all the same.

The one type of snake oil that couldn't be effectively criticised was the antivirus software package. Windows has had, has today, and tomorrow and forever will always have an endemic weakness for technical attacks (as opposed to social engineering attacks - trojans - which can sneak into Fort Knox if needed). (Microsoft's criminal 'heroin economics' ecosystem.)

There are repeated attempts by AV vendors to port and then sell their wares on Apple's OS X. Once again, it can be a deluded belief on the part of the vendors that such tools are necessary, but ask any system engineer and you'll hear the truth. Ask Brian Krebs and you'll hear that he would never buy AV for his Mac.

And why not? Because OS X is a UNIX, and UNIX doesn't need it. But Windows is not UNIX and Windows cannot protect itself - 'real' operating systems don't leave files (and users) unprotected.

OS X Snake Oil

Then this turned up the other day at the always eager NoodleMac site.

Let's look at these claims.

The Mac doesn't need 'dozens' of cleaner apps. True.
Many of them are simply clones or copies of each other. Somewhat true, yes.
The only 'cleaning' apps one needs are Onyx and AppDelete. See the reply from 'carlton' above.

Onyx is an honest but unfortunately unnecessary app; AppDelete is definitely not necessary.

To be clear again: AppDelete need not have been a charlatan's scheme; the overall idea may have been considered valid, if the designer/creator was not proficient on the platform.

AppDelete followed the lead of AppZapper, which ushered a whole new category of snake oil to OS X. The idea seemed brilliant, and the tag line was spot-on - 'the uninstaller Apple forgot' - even if it wasn't really true.

Cocoa apps come as bundles, where the topmost level is a directory with the extension 'app'. This can be a clue - to a File Viewer, a Finder, or launch services - that running code is to be found within.

A Cocoa app can have half a dozen subdirectories or more, but the essentials are all located in the same place. What happens after that - on program launch - is that additional files get strewn about the user area. In places such as 'Application Support', 'Caches', and Preferences. And working with the base application name as well as using the bundle identifier, a thorough uninstall system can search for files that have those elements in their names or contents.

The idea is that uninstallers can be run at any time and do not need to be running from the moment a new application is installed - they can 'pick up the pieces' anyway.

It's a clever and elegantly simple idea, and AppZapper had good marketing, and the idea took off. Unfortunately, the idea is severely limited in efficacy. Worse still, it's way too easy for anyone (everyone) to go in and create the same app (without stealing anything). There's only a limited amount of logic involved.

The OmniFocus Project

Five years ago, Rixstep published 'The OmniFocus Project'.

The OmniFocus Project compared a great many uninstallers hogging the market back then. You had to make it to part 7 of the article to find out what was really going on.

And it wasn't mentioned directly, but the yardstick used for the review was Rixstep's own Tracker, the only OS X utility out there that's capable of measuring file system changes on that level.

How Uninstallers Work

OS X uninstallers work by searching a number of standard locations for files related to the app you want gone. The heuristics used generally include the bundle name and the bundle identifier.

How Tracker Works

Tracker is a tool to monitor file system changes over a given time interval. To better understand what this means, one should be acquainted with OS X and UNIX file system basics.

How Unix File Systems Work

Unix file systems have three time stamps per file.

ctime - often called 'changed'. For the time when the file's inode was last changed. The inode is a data chunk with all the file's metadata - such as the time stamps themselves. This time stamp cannot be modified programmatically in user mode.
mtime - 'modified'. When the file was last modified.
atime - 'accessed'. When the file was last accessed (opened for reading).

There was a 'glitch' in versions of OS X up to but not including 10.4 - for more on this, see below.

How Apple's File System Works

Apple's file system is not fully Unix-compatible. Quite a lot of work was put in to making it as compatible as possible. There are still several loose ends. An 'HFS' file system admits of not three but five time stamps.

create - when the file was created. This stamp is immutable.
contentMod - when the file was last modified. Corresponds to the Unix mtime.
attributeMod - when the file's 'attributes' were last modified. Corresponds to the Unix ctime.
access - when the file was last accessed. Corresponds to the Unix atime.
backup - when the file was last backed up. There is no corresponding Unix time stamp.

Prior to OS X 10.4, it was possible - using the old 'Carbon' APIs - to programmatically modify the 'attributeMod' time stamp in user mode. This represented a security vulnerability.

Back Down Windows Memory Lane

To understand why an open 'attributeMod' field can be so crucial, it's helpful to know what had been happening on Windows. Trojans flooded the platform, and one of the best tricks involved replacing system DLLs (shared libraries) with bogus ones. To make the infection as successful as possible, the trojan code would:

Read the file system data, including file size and time stamps, on the target DLL.
Read the Microsoft 'version info' on the target DLL.
Add the same 'version info' to the payload.
Pad the payload until it had the exact same size as the target.
Overwrite the target with the payload. (This typically does not require privilege escalation - after all, it's only Windows, and any obstructions can easily be circumvented or defeated.)
Reset the target's time stamps to what they were before the overwrite.

The ability to change time stamps is crucial to hiding an intrusion on the system. Prior to 10.4 Tiger, this was possible even on OS X. It might require particularly malicious code, but it could easily be done, as the 'changed' field could be reset in user mode. Thankfully, Apple saw this vulnerability and fixed it. And as of 10.4, it is no longer possible to 'fool' the file system on OS X.

How Tracker Works, Revisited

Tracker works much as the Unix command line find. (And find is a good utility to be acquainted with, for all Mac owners.)

One of the most important flags for find in this context is '-newer <file>'.

True if the current file has a more recent last modification time than file.

What the man page is saying is that find will catch all files that have a more recent last modification time stamp.

The easiest way to utilise this is to use your application download as the '<file>' to compare to; anything created after then will be flagged and listed.

What one does in such case is:

Download the new app you want to test.
Run it and go through all possible options.
Exit the app.
find <your user area (~)> -newer <path to app>

And that's a pretty good inspection - far better than AppDelete. And why, in case you already forgot? Check again.

Once again, the summary of how five uninstallers fared:

Location	AppCleaner	AppDelete	AppZapper	CleanApp	uApp	Tracker
~/Documents/OmniFocus Backups	NO	NO	NO	NO	NO	√
~/Library/Application Support/OmniFocus	√	√	√	√	√	√
~/Library/Caches/com.apple.nsservicescache.plist	NO	NO	NO	NO	NO	√
~/Library/Caches/com.omnigroup.OmniFocus	NO	√	√	√	NO	√
~/Library/Caches/Metadata/com.omnigroup.OmniFocus	NO	√	NO	NO	NO	√
~/Library/Caches/OmniSoftwareUpdateCheck	NO	NO	NO	NO	NO	√
~/Library/Preferences	2(3)	2(3)	2(3)	2(3)	2(3)	3(3)
~/Library/Preferences/pbs.plist	NO	NO	NO	NO	NO	√

OmniFocus deposited files in eight locations. Of those eight locations, the uninstallers found files in only three.

~/Library/Caches/Metadata/com.omnigroup.OmniFocus - only one app found it.
~/Library/Caches/com.omnigroup.OmniFocus - three of the five found something.
~/Library/Application Support/OmniFocus - they all found this (it's standard location).

But look at this twice: ~/Documents/OmniFocus Backups was not found by any of them. Perhaps scarier still is how none of them bothered to look into pbs.plist and com.apple.nsservicescache.plist for modifications to the Services menu.

Four of the eight locations were not found by any of the uninstallers; a fifth was found by only one. How good are uninstallers?

Not very. And why not? Again: because uninstallers can only guess where files can be found - they have no way of tracking what's actually happened.

Any app you try to run - without privilege escalation - can drop files in any location it pleases. The uninstallers can't know because they didn't track the file system activity.

Uninstalling an app by using file system activity involves more work, but it's 100% accurate, as opposed to the uninstallers. And Tracker tries to make it easier. Tracker is a mini file manager and comes equipped with a collection of standard file management functions. Tracker can also save a 'playback' file so you can come back to things at a later point in time.

Tracker works with a start time stamp (as find) but also an ending time stamp (find can't do this) so your output is limited to system activity for the test run of your application. (Naturally you should limit other activities when you're tracking an app, and perform an initial scan as soon as the app exits.)

Tracker has an additional function as well: Tracker can show you exactly how your new app will run/open and who will run/open it. This is very important what with all the scheming script kiddie tricks out there. The 'Oompa-Loompa' attack relied on your not checking (or being able to check) that 'latestpics.tgz' was not a zip file of Britney Spears' baby or the latest leaked screenshots of the new OS X in beta.

A minimal version of Tracker comes for free in the Xfile Test Drive package. You can still find out what's happened to your file system; you just can't manage what's going on without a purchase. But this will at least show you what's really happened to your file system - which is a lot more than the uninstaller will. And then too there's find which is already on your file system and will be good enough in a pinch. Both methods produce far more adequate results than you get with your snake oil.

This is OS X, and it's Unix - it's not Windows. A common practice for reviewers testing Windows software is to do all testing on a separate computer and then wipe and reinstall at the end of every work day. You're on OS X. You don't have to do that. As long as you know how to clean up afterwards. (And uninstallers aren't good enough.)

System Cleaners, Revisited

Cleaning a system of detritus is a matter of knowing which locations, not purchasing simplistic code. The locations are the kind of things any good friend (or even bad friend) would pass on for free. And then you just create a shell script (and preferably run it through CLIX) and your system is very very clean.

The crannies you want to clean include the following.

Application Support
/var/log (your ASL files)
/var/audit (your audit files)
~/Library/Caches (they're only caches)
~/Library/Containers (depends how clean you want things)
~/Library/Preferences (lockfiles if they still exist - thank goodness Apple scrapped that weird idea)

You might also want to escalate and clear out your playlists at /var/db/BootCaches/PreheatedUser - otherwise you'll get a crazy stampede of empty document windows on reboot.

You might also want to protect your own files from intrusion by resetting ownership to 501:20 (for standard first system user, if that's you) and masking their mode with 'chflags \022 ~' once everything else is in order.

That should get you going well. Use CLIX to run a command like that, and protect the script file itself by setting it to root:admin, using the user flags 'immutable' and 'no unlink', and with the following preamble at the start, courtesy Dali of Graphic Tribe.

if [[ `stat -f %u%g $0` != "080" ]] ; then
echo "Script ownership is `stat -f %u:%g $0` but should be 0:80."
exit
fi
if [[ `stat -f %p $0` != "100550" ]] ; then
echo "Script mode is `stat -f %p $0` but should be 100550."
exit
fi

Cleaning .DS_Store is a no-brainer too, and does not require special software. You can incorporate it into your script.

find -x ~ -name "\.DS_Store" -print0 | xargs -0 rm -fr {}

(The xargs above means the danged thing runs real fast.)

Finally, you might want to check out /var/folders and see what you can access without privilege escalation; consider putting this into your script as well.

Bottom Line!

The bottom line? It's as 'carlton' said.

I would venture to say the Mac doesn't really need any of those utilities.

And why? Because it's either:

The system doesn't need things like that at all; or
The system already comes bundled with the utilities you need (except you weren't told - someone tried to sell your own software back to you instead).

Postscript: CLIX Caveats

OS X is getting increasingly (overly, hysterically) paranoid about 'SUID' apps. 'SUID' doesn't represent any real danger if used properly - it's been a part of Unix from the start, which is a lot longer time than most Apple engineers have used Unix, and is used all over the place by OS X itself. But Apple's launch services can spook here. If you run into any issues, purge your launch services and if necessary run CLIX the first time at the command line. Once it runs that first time, things should be OK. Don't put too much trust in Gatekeeper!