Re: [sleuthkit-users] NetBSD support?

[Brian C. <ca...@sl...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jun 8, 2004, at 7:43 PM, Scott Ellis wrote:

> In an attempt to recover some data accidentally deleted by one of my  
> users,
> I've been trying to get either Sleuthkit or TCT working on a UFS1
> filesystem, to no avail.

Just because a tool does not do what you want it to does not mean that  
it doesn't work. File deletion procedures are OS specific and not file  
system specific.  UFS1 defines only the data structures and does not  
define when or how they will be updated or wiped.

Many of the UFS file systems wipe the block pointers, but do not wipe  
the inode pointer in the directory entry when a file is deleted.   
Solaris wipes both pointers as does Linux in the past couple of years  
with EXT3FS and EXT2FS.  I documented this back in 2001 for a SANSFIRE  
paper and I think it is documented elsewhere in the TSK docs.

http://www.cerias.purdue.edu/homes/carrier/forensics/docs/ 
autopsy_sansfire2001.pdf


> Unfortunately, the tools from SleuthKit and TCT don't seem to operate  
> as
> expected, and my gut tells me it's due to a divergence of NetBSD's  
> on-disk
> format from that of the other BSD's.

> Note that st_block is zero, when it should contain the disk block that  
> is
> referenced by that inode.  Indeed, trying to just cat the contents of  
> that
> inode returns nothing as well:

I will admit that I haven't looked at a NetBSD image in a while, but I  
wouldn't expect it to have the block pointers (based on how FreeBSD and  
OpenBSD operate).  Do you have a reference for what lead you to believe  
that the block pointers should exist?

brian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAxrvqOK1gLsdFTIsRArQ3AJ0XCLNLTNZ2UqcBNdJE5Pps9iZiQQCeLnwy
eW3JboCwHbPTD+oAtub5VEM=
=7maZ
-----END PGP SIGNATURE-----