| About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack | |
Home » Learning Curve
App Cleaners RevisitedThere's always one app.
There's always one app that's the rage at any given time on any platform. Things get blown out of proportion pretty fast. Everybody and their cousins try to whip something up fast and rush it out the door. Users suffer. Apple Didn't Forget ShitA big one on OS X has been the 'app cleaner'. And all too many vendors include the tag 'the app Apple forgot'. For once and for all and make no mistake about it: Apple didn't forget shit. Unix File SystemsUnix file systems have three very important timestamps in this context.
That last point is very instructive. Intelligent malware might try to disguise operations by wiping away the 'last modified' timestamp and replacing it with the previous one. That won't work. For although it's possible to programmatically set the 'last accessed' and 'last modified' timestamps, you can't do that with the 'last changed' stamp. That's the dominion of the drivers alone. Should anything happen to the timestamps, this field gets bumped, and there's nothing malware can do about it.
So a proper tracker, assigned the task of noting all changes to a file system for any given period of time or any given run of any given application, will be able to see:
Such a tracking system (as used by Tracker) is the only complete, only foolproof way to see what an application - or what anything - is up to on disk. But that's not the way the 'app cleaners' work. AppTrapAppTrap is one of a myriad 'app cleaners' for OS X available today. Some of these app cleaners have as many as 800,000 downloads at CNET. The comments show basically that none of the users have a clue what they're doing.
AppTrap installs itself as a pane in System Preferences. So it runs all the time in the background, sucking CPU clocks whenever it gets a notification that something (perhaps of importance, perhaps not) is happening to the file system. ATApplicationControllerThe guts of AppTrap is in the ATApplicationController module - more specifically the file ATApplicationController.m. This file is the only file we need look at. ----------------------------------------------- APPTRAP LICENSE "Do what you want to do, and go where you're going to Think for yourself, 'cause I won't be there with you" You are completely free to do anything with this source code, but if you try to make money on it you will be beaten up with a large stick. I take no responsibility for anything, and this license text must always be included. Markus Amalthea Magnuson <markus.magnuson@gmail.com> ----------------------------------------------- */ That's the prologue. It's free code. With certain caveats. @implementation ATApplicationController That indicates the code for ATApplicationController is about to begin. -(id)init {
if ((self = [super init])) {
// Setup the path to the trash folder
pathToTrash = nil;
CFURLRef trashURL;
FSRef trashFolderRef;
OSErr err;
This is an instance method. AppTrap should run only one instance, but this standard hook is used anyway. Here the app's trying to find the canonical path to the Trash. This presumably because that's where files will be put when they're deleted. // Setup paths for application folders
applicationsPaths = [[NSSet alloc] initWithArray:
NSSearchPathForDirectoriesInDomains(NSAllApplicationsDirectory, NSLocalDomainMask | NSUserDomainMask, YES)];
What AppTrap is trying to do here is find the places where applications are normally found. Rixstep's Lightman has an excellent facility for finding these paths. They're controlled by APIs and not baked into the system per se. These are paths the system itself uses for searches. // Setup paths for library items, where we'll search for files NSMutableArray *tempArray = [[NSMutableArray alloc] init]; NSArray *tempSearchArray = nil; NSEnumerator *e = nil; id currentObject = nil; // Preferences and StartupItems tempSearchArray = NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSUserDomainMask | NSLocalDomainMask, YES); AppTrap will try to find 'ancillary files' connected with application you want 'cleaned'. This is key - this is how the application goes about finding them. It doesn't check the file system to see what files have been generated etc - it only looks in standard locations. And if your trusty app decides to put things elsewhere, they won't be found. // Application Support
[tempArray addObjectsFromArray:NSSearchPathForDirectoriesInDomains(
NSApplicationSupportDirectory, NSUserDomainMask | NSLocalDomainMask, YES)];
'Application Support' is another place applications put files. Tshis places the files external to the application bundle which can get updated at any time, and given how Apple file systems work, support files in the bundle would be obliterated. // Cache
[tempArray addObjectsFromArray:NSSearchPathForDirectoriesInDomains(
NSCachesDirectory, NSUserDomainMask | NSLocalDomainMask, YES)];
Yes there's a cache directory in ~/Library too. All this is good to check. // Register for changes to the trash [self registerForWriteNotifications]; A key line. What AppTrap will do is wait for you to 'trash' an app you no longer want. The file system will notify AppTrap whenever you do this. The bad thing is this applies to everything that goes into the trash, not just apps you want gone. And remember: you never get told what happens behind the scenes. // Return all applications currently in the trash, as an array
// TODO: Can this method be incorporated in handleWriteNotification: to speed things up?
-(NSArray *)applicationsInTrash {
This is what the app's going to do when something turns up in the trash. This is actually not germane, but let's take a look anyway. NSMutableArray *applicationsInTrash = [NSMutableArray array]; He's going to check all the files in the trash, and from that make a list of all the applications there. while ((currentFilename = [e nextObject])) {
if ([currentFilename hasSuffix:@".app"])
[applicationsInTrash addObject:currentFilename];
Quite straightforward. While there are still further files to check, if the current file being checked has the extension 'app', put it in the list. But why the code doesn't use the more correct pathExtension method is yet another mystery. -(void)handleWriteNotification:(NSNotification *)notification {
What to do when the notification system says there's been a disk write operation. while ((currentFilename = [e nextObject])) {
// Is it on the whitelist?
if ([whitelist containsObject:currentFilename])
continue;
There's a 'white list' of apps you never touch. If the one you're checking is on that list, ignore it. // If it's in the applications folder, it was probably auto-updated by Sparkle Ah. We're actually checking in those 'applications' directories we found earlier. And one of the 'sparkly' add-ons might be doing some nasty work. So ignore. // XXX: Currently only works for applications in root (not apps in folders), we could of course recurse // with an NSDirectoryEnumerator but that would be _reeeally_ slow since this method is called very often Basically an admission that this method of cleaning apps sucks! while ((currentApplicationPath = [applicationPathsEnumerator nextObject]))
if ([manager fileExistsAtPath:[currentApplicationPath stringByAppendingPathComponent:currentFilename]])
// Add it to the whitelist
[whitelist addObject:currentFilename];
He now goes about updating his white list. Comments anyone? // Now, check again for safety
if ([whitelist containsObject:currentFilename])
continue;
Same thing as before. Unfortunately. NSLog(@"I just trapped the application %@!", currentFilename); Yay! Ahem. // Get the full path of the trapped application NSString *fullPath = [pathToTrash stringByAppendingPathComponent:currentFilename]; Now we caught one. Now we have to find what else could be on disk. Behold the logic of the 'app cleaner'. // Get the applications's bundle and its identifier NSBundle *appBundle = [NSBundle bundleWithPath:fullPath]; NSString *preferenceFileName = [[appBundle bundleIdentifier] stringByAppendingPathExtension:@"plist"]; NSString *preflockFileName = [preferenceFileName stringByAppendingPathExtension:@"lockfile"]; It's thorough at any rate. And it's been updated for 10.7 and above where those nasty 'lockfiles' start to appear. He's looking for the name of the app's preferences file and from that he's going to find the full path for the lockfile. NSString *lssflprefFileName = [[appBundle bundleIdentifier] stringByAppendingPathExtension:@"LSSharedFileList.plist"]; NSString *lssflpreflocklFileName = [lssflprefFileName stringByAppendingPathExtension:@"lockfile"]; Now he gets the other two pieces of junk Apple leave behind in ~/Library/Preferences these days. // Let's find some system files NSMutableSet *matches = [[NSMutableSet alloc] init]; NSEnumerator *libraryEnumerator = [libraryPaths objectEnumerator]; id currentLibraryPath = nil; Let's find some system files! Yes let's do that! Wahoo! while ((currentLibraryPath = [libraryEnumerator nextObject])) {
[matches addObjectsFromArray:[self matchesForFilename:preferenceFileName atPath:currentLibraryPath]];
[matches addObjectsFromArray:[self matchesForFilename:preflockFileName atPath:currentLibraryPath]];
[matches addObjectsFromArray:[self matchesForFilename:lssflprefFileName atPath:currentLibraryPath]];
[matches addObjectsFromArray:[self matchesForFilename:lssflpreflocklFileName atPath:currentLibraryPath]];
[matches addObjectsFromArray:[self matchesForFilename:appName atPath:currentLibraryPath]];
}
What's all that? Looking for the four files mentioned plus the app itself. // Part of code from http://www.borkware.com/quickies/single?id=130
// TODO: Seems like were leaking NSConcreteTask and NSConcretePipe here, needs to be investigated
-(NSArray *)matchesForFilename:(NSString *)filename atPath:(NSString *)path {
The code at the cited URL has the following warning. // Open up the window if we got any hits
if ([[listController arrangedObjects] count] > 0) {
[NSApp activateIgnoringOtherApps:YES];
[NSApp runModalForWindow:mainWindow];
}
Show something onscreen if you've been a good hunter. But don't let the user choose which files to trash. // Clear the whitelist if the trash is empty, i.e an "Empty trash"
// operation was just finished
if ([self numberOfVisibleItemsInTrash] == 0)
[whitelist removeAllObjects];
Clear away your white list until next time (then access it twice, both before and after you rebuild it). Bottom LineThat's about it. A final curious thing about AppTrap is that it uses three separate methods (code blocks) to react to the application launch, each requiring a separate system call. But whatever. The basic things we learned from the above are the following.
More to ReadApp Cleaner, AppDelete, AppZapper, CleanApp, and uApp were all tested previously. All failed miserably. This is a seven-page report: read it here. See Also |
| About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack |
| Copyright © Rixstep. All rights reserved. |