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 >