heard 2 days ago first mac virus

How did you get that idea from my post? I never suggested anything of the sort. 😕

A standard 'erase' doesn't erase anything from the disk. It just tells the index file to ignore what is written to that data space.

My point is that if MK has copied/written anything into that data space that is from your own personal data (and I'm not saying it does, I'm saying "if", but since MK appears to do a pretty thorough job at rampaging through a users personal data, it is not entirely unlikely), then that data is still physically recoverable from the disk at a later date.

There is a reason for secure erase on Mac OS X, and I am suggesting that it is wise to employ it in this case since you don't know what personal data MK has written to disk in its various resource folders.

I'm not really sure why you're arguing about it to be honest. The procedure for removing MK is, to my knowledge, the most comprehensive one you'll find anywhere on the net. Granted, you can disable MK from working with fewer steps, but being thorough with this kind of 'crapware' is what I'd call 'best practice'.

softwater wrote:

I'm not really sure why you're arguing about it to be honest.

I'm not arguing about anything, just pointing out that there is a potential downside to using the secure erase, especially after something like MacKeeper may have caused unknown problems with the system.

softwater wrote:

R C-R wrote:

Alias_alas wrote:

in fact I just followed phil Stokes's excellent "how to" dig out all the various files that mac keeper left behind after trialing it (for about 3 minutes a few months ago).

Stokes' method is a bit over the top.

I prefer to think of it as 'thorough' in order to return a machine to the state before MK. The BOM's are arguable, but I see no reason to leave anything at all on there.

Securely emptying the trash ensures the data space gets written over rather than MK being actually still on your system but unrecognized. I haven't looked in the MK package contents to see what if, any, personal user info is written/copied there. Secure trash is just a precaution to make sure that nothing related to MK remains readable on your disk.

The best way to deal with any issue, whether malware or user error is to possess a current backup of your system, that way you can't lose anything but time, and probably less time than trying to get the junk out.

I'm happy to be educated by those who know more than I (which is probably most on here), but I fail to see what downside you have pointed out.

I can't see ANY downside to using secure erase on MacKeeper. Please make clear my misunderstanding.

Thx.

softwater wrote:

I can't see ANY downside to using secure erase on MacKeeper. Please make clear my misunderstanding.

We are assuming that MacKeeper does all kinds of nasty stuff to the system, right? So it isn't unreasonable to assume that it might corrupt the file system, including messing up the directory structures that indicate what parts of it are free & what parts are in use storing files. (It's one of the kinds of problems Disk Utility's "Repair Disk" step is designed to try to fix.)

A secure erase overwrites free space, as determined by the directory structures. So if the file system is corrupted, it may very well overwrite files or parts of files, making them unrecoverable even with recovery utilities like Data Rescue. If the affected files have not yet been backed up, they are gone forever. If they include system files, at the very least the OS will have to be reinstalled.

Note that this is a potential problem for any secure erase of free space. It just seems more likely after MacKeeper has been used, in part because (perhaps ironically) among its utilities are both file recovery & secure erase (the "Shredder") functions.

So any time one is contemplating a secure erase on a drive containing files that should be saved, it is good practice to run Disk Utility's "Verify Disk" or "Repair Disk" step before doing that, as well as making sure those files are backed up.

Mr. Stokes doesn't suggest doing this. He suggests using the Finder's "Secure Empty Trash" step (which of course is a type of secure erase) & restarting the Mac before running Disk Utility, & that just to do a permissions repair, not a verify or repair of the disk. He doesn't suggest backing anything up -- in fact, part of his procedure involves removing items from TM backups and/or erasing clones & then re-cloning the 'cleaned' startup disk.

If I was going to do a "best practice" removal of MacKeeper, step one would be to run Disk Utility's "Repair Disk" step, ideally while booted from an installer DVD, to insure that the file system was OK before doing anything else. I would then reboot from the normal startup volume in Safe Mode (to prevent any MacKeeper components from running), move the files associated with MacKeeper to the trash, & before even emptying the trash, restart normally to make sure no essential system file has accidentally been trashed or anything else had happened to interfere with starting up the Mac. (If a problem occurs on restart, I would restart from my clone & try again.) Only then would I empty the trash, & I wouldn't bother with a secure erase unless there was a potential security issue (like if I was selling the Mac or had to leave it in an unsecured location for some reason).

I also would not erase some of the non-executable files Mr. Stokes suggests erasing that might be useful in analyzing what it had done, like MacKeeper log or receipt files, but I realize that's not something that would interest everyone.

Much of this makes good sense, but before I make further comment I should formally state that the procedure and blog we're talking about is mine. I say that only so as not to mislead or misrepresent my interest in pursuing questions (you may, perhaps, feel that you don't want to continue this in light of that info).. I know some on here already know the association between 'softwater' and Applehelpwriter, and the only reason I wasn't more explicit earlier is because I didn't want to seem to be hijacking this thread in order to drive traffic to my website (which is against the ToU in any case). I'm only interested in getting the procedure right.

Likewise, I would not be surprised or particularly upset if some of our more "vigilant about the ToU" members feel the need to report this discussion as off-topic (which it clearly now is) and have it stopped. In the meantime, however, I'd like to make a few comments, as long as they last:

1. Thanks for the tip about running DU first. That hadn't occurred to me, but makes good sense.

2. In response to a question on my site in the comments a few days ago, I suggested that it would be wise to run this procedure from safe mode first, but I hadn't taken the further step of incorporating that into the main post. My feeling was that it wasn't necessary, and I've had quite a few 'inexperienced' users have trouble with implementing safe mode, sometimes thinking they were in it when they weren't, and sometimes being in it and (despite the warnings to the contrary) thinking their computer was really hosed. For that reason, I've been reluctant to write the procedure starting from a safe boot if it isn't necessary. I may reconsider that in light of your comments, but I need to look into it a bit further.

3. I don't believe the removal of any TM files in the procedure is detrimental as (I think) you suggest since that removal is done through the 'star wars' interface and is specific to MK files. I can't see how that could possibly be harmful.

4. I categorically do not suggest blanket wiping any clones as you seem to imply above. My procedure always leaves a backup in place. Either you have a clone with archives, in which case you boot into that and uninstall MK from it first (leaving your internal disk untouched and acting as your backup till you've verified that the uninstall on the clone worked and rebooted safely), or you have an unarchived clone, in which case you unplug (and therefore preserve it) before uninstalling MK on your internal disk. Only once your internal HD is rebooted and seen to be OK do I suggest you then make a new clone, wiping out the old one. That's effectively what you're doing everytime you clone your system anyway (when you clone without archiving).

5. I understand the argument with BOMs and other non-exectuables, (which is why I said it was 'arguable' earlier), but I'm unconvinced that there is any reason to leave them. I know you could argue that there is no reason to remove them, and we could go round that for hours. My feeling is that I don't want people following my procedure and then later worrying 'Hey, I found something from MK on my disk he didn't tell me about'. Might as well clear the lot.

6. As I understand it, 'Secure Empty Trash' is, at least in Snow Leopard, a 7-pass overwrite, which is the maximum available in Lion's DU (SL allows a 35-pass overwrite in DU), so it isn't "a kind" of secure erase, it is a secure erase. I appreciate your comments on using Verify and Repair permissions first, which I hadn't thought of and which I'll need to look into further, but on the face of it that sounds very sensible.

Even so, I still disagree with you about whether secure erase should be performed or not. If I follow the suggestion to do verify and repair first, I can't see any adverse affects. I can, however, see problems with not securely erasing MK. I've outlined some above, and I think they still hold. I have one or two others suspicions, but I need to find out more about the technical side both by testing what MK actually does write to disk, and whether there are possibilites of a trojan or some other script being able to recover data from the disk remotely (I freely admit that this is way out of my depth of current understanding, but I am actively engaged in learning more).

Thanks for your comments. They're very helpful to me (and will be to others). I have had lots of positive responses to the procedure and none of any body having any problems from doing either the secrue erase of any other part of it. I happily admit, though, that "so far so good" is not a reliable indicator of what tomorrow may hold. 😉

Finally, apologies to both the OP and everyone else uninterested in this diversion. It will be of benefit to others, just probably not to those following the OP and thread title. 😐

Just out of curiosity, are you Phil Stokes or a contributor to the website?

Thanks for making it clear that you are the author of the article, & for considering my criticism of it.

It is only my opinion but I strongly believe that authors of articles of that nature are obligated to base them only on things they understand quite well, or at least to indicate clearly when that isn't true. They also should be comprehensive, explaining any possible undesirable side effects or anything else a user should know before trying what they suggest. It is much like the physician's ethic to "first, do no harm."

I fully understand & acknowledge that this is not always easy or even possible to do, but I believe it is something aspiring tech writers must strive for, much more so than for typical users just trying to help each other, because they are trying to speak from a position of authority.

Enough on that. Regarding your comments in the last post, I'm not sure it would be entirely clear to all readers of your article what you mean about keeping a backup always in place. I find your comments like "**If you are running a clone, remember to follow the instructions given above under “Getting ready”.**" somewhat confusing, but maybe that's just me.

I think it would be easy to avoid your worries about users discovering 'left over' files as well as instructive to briefly explain which are the critical files that must be removed, which are optional, & why that is. As it is, you give the impression that they are all equally capable of causing problems, which will convince some users that this is equally true of any similar types of files associated with other apps they want to quit using. That can & too frequently does lead to some users poking around looking for all sorts of things to remove without a clear understanding of what they should leave alone & breaking the system. Just something to think about.

AFAIK, 'Secure Empty Trash' is just a single pass secure erase. The 7 pass & 35 pass secure erases are both somewhat out-of-date & unnecessary. The DoD 5220.22-standard implemented by the 7 pass one is obsolete (see for example the notes in the "Standards" section of this Wikipedia article for more about that). The 35 pass Gutmann erase was never intended to run all 35 passes. For (much!) more on that refer to the seminal article by Peter Gutmann himself, especially the 'epilogue,' 'further epilogue,' & 'even further epilogue' sections.

Regarding the need for the secure erase, I've already explained the specific circumstances for which I think it is necessary or desirable. As for the possibility of some remote control method of recovering or accessing (normally) erased data, I won't say it is completely impossible, but it is extremely unlikely anyone would even try that for the simple reason that once an allocation block is marked free in the file system, there is no guarantee that it won't be overwritten with parts of newly saved or modified files in the course of normal use of the drive.

Thanks. I do take on board some of your comments, not others, but I think further discussion of the style of the article will test the patience of the mods beyond breaking. I'll bring my end of it to a close by noting that the article has a limited scope and has evolved in light of reader feedback. It'll continue to do so, and I'll certainly be bearing in mind some of the points you've made when I next revise it, so thanks again for your feedback.

Back to technical matters. My claim that 'Secure Empty Trash' is a 7-pass overwrite is based on information in White's "OS X Lion Support Essentials", which is Apple's own recommended text for those doing Apple certification.

If that's wrong, I'd like to know your source (and maybe then someone should inform Apple their training materials are inaccurate... 😉 ).

I have also read this in the past, but according to Wikipedia's page on the subject, Apple uses the Department of Defenses' recommended 7 pass erase method with Secure Empty Trash.