|
Mac GeekeryGet your geek on. |
|
blog advertising is good for you
recent popular content
User login
|
So I’m paranoid, but not THAT paranoid. Sometimes I feel like using “Secure Empty Trash”, but that uses ’/usr/bin/srm’ with the ’-m’ option (7 passes), which can take a while to complete. Most of the time, I only care about what might turn up with simple file recovery tools in case my drive gets stolen (as opposed to covering my tracks from say law enforcement or a foreign government) so really, a single pass should be plenty for my needs. I could always use ’srm’ directly, but the convenience the built-in tool offers in handling the Trashes on various volumes, and having a built-in menu item is nice. It turns out the ’srm’ option used by “Secure Empty Trash” in Tiger is specified in the file: /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Resources/Locum eg. in 10.4.10 (PPC): $ hexdump -C -s 81168 -n 64 /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Resources/Locum 00013d10 73 72 6d 00 2d 73 00 00 2f 75 73 72 2f 62 69 6e |srm.-s../usr/bin| 00013d20 2f 73 72 6d 00 00 00 00 2d 6d 00 00 63 6f 6d 2e |/srm....-m..com.| 00013d30 61 70 70 6c 65 2e 64 65 73 6b 74 6f 70 73 65 72 |apple.desktopser| 00013d40 76 69 63 65 73 00 00 00 4c 6f 63 75 6d 3a 20 74 |vices...Locum: t| I don’t know what the “srm.-s” in the top line is doing (maybe there’s a plist key somewhere to switch options the easy way), but using a hex editor to change the “-m” in the second line (at 00013d29) alters how “Secure Empty Trash” treats the files being deleted. The results were confirmed, at least as far as I could tell, watching while using “Secure Empty Trash” on a file on a small, previously zeroed volume. Apparently, in addition to the “-“, only one byte is allowed to specify the actual parameter. A simple substitution of the “-m” flag with something else works – eg. I opted for “0x2d 0x73” for “-s”, while others might prefer “0x2d 0x2d” for “--” (35 passes) – but trying to use more than one flag at a time (eg. “-sn” or “-mz”) did not work in my limited testing. The “-n” or “-z” flags can be used by themselves, however srm will then default to 35 passes (see the ’man’ page). The ’Locum’ file is a system file, owned by “root” and ’setuid’ no less, so the sensible may want to avoid messing with it and skip this hack. But then again, this is macgeekery so I hope it is in keeping with the spirit of this site. Back up the original file in any case, proceed at your own risk, and be aware that Apple system and security updates could replace the file at any time. Either way, this trick will probably be obsolete by the end of the month when Leopard comes out with its redesigned Finder.
About biovizier
|
Hex Fiend is an easier choice for ye olde binary search-and-replace.
I did this to my copy and it works, but the location in the file was different for me (around 0xD7E0). Just open Hex Fiend and search for “srm” to find the spot in your file. You’ll need to copy it somewhere, edit it, and copy it back with the right permissions if you use the GUI tool.
You’ll note that the first few bytes of the file in hex are:
This equates to the ASCII you saw:
*but* in fact the “.” are actually a place-holder for a non-printable ASCII character (in this case for the hex value 0x00 aka NUL).
It’s standard in C to use a NUL-terminated string so these 0x00 are probably used to indicate the end of the strings.
What this means is it *might* be possible to have additional options if you *insert* characters between the 0x73 value and the 0x00 value.
Or it might not.
Thanks for the suggestion. I gave it a try, but alas, after inserting an extra character, “Secure Empty Trash” no longer worked (never-ending progress bar, files untouched).
Just to update this topic, the “Locum” file in Leopard doesn’t contain the “srm” string any more, and ‘/usr/bin/srm’ apparently is no longer involved since “Secure Empty Trash” seems to work just fine when it has been removed.
However, the “Finder” executable now contains the string “_FXSecureEmptyTrashLevel” and it turns out this can be used as a property in the “com.apple.finder.plist” file. So potentially, no more hacking of executables required to change how “Secure Empty Trash” deletes files.
In terms of the values that “_FXSecureEmptyTrashLevel” accepts, there is probably some underlying logic but beyond the fact that they should be numerical (the actual data “type” doesn’t seem to matter), it’s a bit of a puzzle to me. From trial and error, a value such as “-1” (the minus sign is important) results in the 35 passes (following the Gutmann algorithm) to be used. The equivalent of ‘srm -s’ (a single overwrite with random data) results from a value of eg. “9” (or others ending in “9”). So far, I haven’t stumbled on an actual numerical value that gives the default 7 passes, although that is what is used in the absence of a “_FXSecureEmptyTrashLevel” property, or with what are perhaps invalid values such as non-numeric strings or booleans.
Somewhat disturbing is the fact that many values will cause “Secure Empty Trash” to delete the file insecurely without overwriting it at all, and without any notification to the user (as of 10.5.2 anyway). This is much worse than 10.4 or 10.3 where a file that was unsuccessfully “secure deleted” would at least be left in place so that the user would notice that it didn’t work. Now, people may be left with a false sense of security, not realizing that pieces of their data may still be on the hard drive ripe for the picking. It raises the question of whether secure destruction of data can be entrusted to the “Finder”…