25Dec2007 (UTC +8) On 12/24/07, Eduardo Tongson <[EMAIL PROTECTED]> wrote: > Took a peek. TCT mactime can not be used to determine the install > date. mactime uses lstat(2) which in turn relies on inode timestamps. > Inode timestamps only has one field each for modified, accessed, > changed so it can only record the last update.
I suggest that you try mactime first before dismissing it immediately. It might help if you try not to look at specific and individual files, but to look at filesytem activity in its entirety. Mactime is *one* of the tools that can let you visualize (in your mind only) what happened on a filesystem, by listing all the file times in chronological order. And of course, mactime output shouldn't be the only source of information you should look at. You need to check out whatever available logs there are as well. You need to co-relate it with other data to get a definitive idea of what went on. And the timestamps from both the logs and mactime output should be cross-checked with the hardware BIOS date and time output. Individual file properties may mislead a system administrator, but shouldn't if the whole filesystem and contents were examined. Note: I don't suggest using mactime on a live fs. You'd have to dd the fs, mount the HDD image file with ro,loop,nodev,noexec,nosuid,,noatime options on a workstation, before running ils and fls, then actually running mactime. This is so that you minimize "dirtying" the filesystem being examined. Mactime output can be a big file, like a 40GB HDD can easily yield a ~95MB text file --and you'll be producing more than one. > I think the MAC letters are confusing. C can be mistaken for inode > creation timestamp. Like this Security book that mistakenly attributes > it. > <http://books.google.com/books?id=xVuoTgSL1QoC&pg=PA620&dq=inode+timestamp&sig=Vg6TpwzxPVlqfVOX7pVUxL4Li-U> > Know your tools. For Windows NTFS users, ctime is "creation time". MAC times (modify / access / change; mtime / atime / ctime) for us in the Unix world, it's different. From stat(2): ctime is changed by writing or by setting inode information (i.e., owner, group, link count, mode, etc.). One perspective to take is to look at MAC times as reference to the file properties itself, not to the file content properties. To quote http://www.linux.com/feature/41179?theme=print "The atime attribute refers to the last time the file or directory was accessed. The mtime attribute, in contrast, changes when a file's contents are modified. The ctime attribute keeps track of when the contents or the meta-information about the file has changed: the owner, the group, the file permissions, and so on. The ctime attribute may also be used as an approximation of when a file was deleted." > On 12/24/07, Drexx Laggui [personal] <[EMAIL PROTECTED]> wrote: > > > > On 12/10/07, Federico Sevilla III <[EMAIL PROTECTED]> wrote: > > > On Mon, 2007-12-10 at 20:01 +0800, Drexx Laggui [personal] wrote: > > > > > > > > On 12/10/07, jan gestre <[EMAIL PROTECTED]> wrote: > > > > > I'm just after the install date. > > > > > > > > 'cat /proc/version' will give you the same output as "uname -a". The > > > > installation date is shown there. > > > > > > Caveat: /proc/version and `uname -a` provide you with the build date of > > > the kernel you are running. On systems where the kernel was upgraded > > > after the installation was done, this will not be an accurate measure of > > > the server's install date. > > > > > > Perhaps a more appropriate approach will be to try to find the change > > > date of the oldest system file (user files may have been extracted from > > > a tarball, inheriting the original timestamp... which while also > > > possible on system files is probably not as common). Again this isn't > > > fool proof, but it may be a bit more accurate when the kernel has been > > > modified. > > > > > > Federico Sevilla III > > > F S 3 Consulting Inc. > > > http://www.fs3.ph > > > > Thanks for the tip! "uname -a" or "cat /proc/version" is what is > > suggested on many first-responder guides on computer forensics. IIRC, > > it started with a CERT.org publication some years ago. Anyway, as > > noted by many already, there is not one "smoking gun" evidence that > > can give the answer right away, as a Linux system is a complex beast > > nowadays. The system analyst or admin must use a combination of tools, > > deduce the answer from all the data present, and arrive at a best > > possible conclusion. > > > > Another good tool to use is "mactime". Check out an article on how > > it's used here: > > http://www.linux.com/feature/41179 Drexx Laggui -- CISA, CISSP, CFE Associate, CCSI, CSA http://www.laggui.com ( Singapore / Manila / California ) Computer forensics; Penetration testing; QMS & ISMS developers; K-Transfer PGP fingerprint = 6E62 A089 E3EA 1B93 BFB4 8363 FFEC 3976 FF31 8A4E _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List [email protected] (#PLUG @ irc.free.net.ph) Read the Guidelines: http://linux.org.ph/lists Searchable Archives: http://archives.free.net.ph
