Re: Veritas

subscribe <[email protected]> Tue, 15 Nov 2005 23:10:47 -0500
Newsgroups gmane.comp.security.forensics.tct
Message-ID <1132114247.3610.37.camel@crazytrain>
Ivan,

Please review VERITAS FILE SYSTEM 4.0 ADMINISTRATOR'S GUIDE.  There's
good information therein, including disk layout, allocation, recovery,
etc.  Your mileage may vary, but I found it contains quite a bit of good
info.

http://www.sun.com/products-n-solutions/hardware/docs/Software/Storage_Software/VERITAS_File_System/


In addition, from VERITAS, you might like;

FILE SYSTEM WHITE PAPER (a bit dated);
http://www.veritas.com/us/products/filesystem/whitepapers.html


And finally, there is some VxFS information in UNIX FILESYSTEMS -
EVOLUTION, DESIGN, and IMPLEMENTATION (ISBN  0471164836)


regards,

farmerdude

http://www.farmerdude.com


On Sat, 2005-11-12 at 17:31, Knut Eckstein wrote:
> Ivan,
> 
> Ivan Buetler wrote:
> > 
> > I have to analyze a disk previously installed within a Solaris 9 box. It looks 
> > like the disk contains Veritas depending partitions.
> 
> Veritas is not supported by any forensic tool I know, most probably because
> their disk layout is not publicly documented (hence no open-source tools) and
> licensing this proprietary information is either expensive or not available
> at all (hence no commercial tools).
> 
> Linux can mount Veritas partitions read-only (beware, the Veritas file system
> has evolved over five different disk layouts, so yours may or may not be
> supported,
> I personally have never tested the Linux driver, any comments are most welcome,
> my initial guess would be that UnixWare vxfs partitions may be mountable ...)
> In any case, such a mount would not get you MAC timestamps of deleted files...
> 
> > I would like to do a MACTIME analysis using tct or sleuthkit. Any ideas how to 
> > proceed, because the veritas cluster partition stops further investigation. 
> 
> Given the situation described above, not much can be done, unless you happened
> to stumble across a .h file on your system describing the layout of your vxfs
> inode. If you had that information, you could run a perl script against a dd
> image of your partition to carve for timestamps (taking advantage of the fact
> that you know the rough range of values to expect in the timestamps, e.g.
> epoch values between something like 1/1/2000 and today). You would still have
> to link those timestamps to a inode number, a lot there depends on whether
> your file system explicitly records inode numbers inside the data structure
> or whether the number is implicitly derived from the physical location of
> the inode on disk. Recent file systems tend to do the former, so you may
> be lucky there. You could also try and carve for inode timestamp values
> without haveing access to the relevant include file, but then you would have
> to make some very bold assumptions about the way the timestamps are encoded
> in your Veritas file system. Just looking at ffs.h in tct or sleuthkit
> tells you there is more than one way to do this (*BSD vs Solaris style).
> 
> In terms of recovering files, file systems usually make every effort to
> keep file contiguous, so a hex editor can get you a long way in terms
> of recovery, if you roughly know what's inside the files you deleted...
> 
> Regards,
> 
> Knut
>