Not dismissing it. TCT is useful for forensic, for example a server compromise. Yes I used it before but took a better deeper look at mactime this time. I thought it could get the created timestamp for files.
I think an accurate way to get the install date is by getting the creation timestamp of the / partition. It is possible that some journaling file systems has a record of the creation time in the journal log. That is if the file system retains old information like that because as far as I know most of them only record recent updates. Ed <blog.eonsec.com> On Dec 25, 2007 2:07 AM, Drexx Laggui [personal] <[EMAIL PROTECTED]> wrote: > 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 > _________________________________________________ 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
