First, grab Maximillian Dornseif’s forensics slides (you’ll find them…).
Second: Think about a way to prevent Finder.app
to automount the image, otherwise it will modify the image by adding two files: .Trash and ._.Trash.
How about…
How about…
… patching this: http://blog.annulator.de/articles/2005/06/09/hastalads_store-nie-wieder-ds_store-dateien
This comment was originally posted on 20051006T11:51:23
Very nice software, but I guess it won’t work:
I was wrong in the orignal posting that Finder.app creates
the trashcan directories, it’s the diskarbitrationd itself,
see function void _DAMountCreateTrashFolder( DADiskRef disk, CFURLRef mountpoint ) in DAMount.c.
This comment was originally posted on 20051006T17:04:44
You can get the patch here.
This comment was originally posted on 20051006T18:33:20
I read TONS of useless documentation, about
all kind of ancient MacOS X versions and tools
like autodiskmount (This command is deprecated and exists only for backwards compatibility.)
and just before giving up, I found this tool:
/usr/sbin/diskarbitrationdthat is startedfrom a startscript in
/priv/etc/mach_init.d/diskarbitrationd.plist. I still have to find out who restarts the program after killing it, for testing purposes, I renamed the program and started it with the -d flag. Here is the output:diskarbitration [2897] -> diskarbitration [2897]
probed disk, id = /dev/disk2s1, with msdos, ongoing.
probed disk, id = /dev/disk2s1, with msdos, success.
mounted disk, id = /dev/disk2s1, ongoing.
mounted disk, id = /dev/disk2s1, success.
.
Patching the diskarbitrationd seems easy, but the
mechanism itself doesn’t. I’m thinking about preventing
mounting of FAT filesystems, or even some execution prevention by a lock file.
This comment was originally posted on 20051005T23:38:28