Re: Forensics tools for HammerFS

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:> =A0 =A0undo -i <filename> will locate any retained history for a file or
:> =A0 =A0prior incarnation of a file, if it exists.
:>
:
:If the file exists or if the history exists?
:It seems if I delete a file its history also vanishes.

    Is the HAMMER filesystem mounted normally or is it mounted 'nohistory'?

:dfly-bkpsrv# undo -i 1.txt
:1.txt: ITERATE ENTIRE HISTORY
:        0x000000011cab1960 14-Aug-2009 14:29:52
:        0x000000011cab19a0 14-Aug-2009 14:30:01
:        0x000000011cab19c0 14-Aug-2009 14:30:10
:        0x000000011cab19e0 14-Aug-2009 14:30:17
:dfly-bkpsrv# rm 1.txt
:dfly-bkpsrv# undo -i 1.txt
:1.txt: ITERATE ENTIRE HISTORY: Unknown error: 0

    This works for me.  The undo can still find the file.  One thing
    I will note here is that in your test you are creating and destroying
    the file within a 25-second span.  HAMMER's history mechanic only
    works for data that actually gets flushed to the media and that may
    have been too short a time for a flush to occur naturally.  You can
    force a flush with 'sync'.

    Here is the test I did:

	test29# echo "a" > 2.txt
	test29# sync
	test29# echo "a" >> 2.txt
	test29# sync
	test29# echo "a" >> 2.txt
	test29# sync
	test29# undo -i 2.txt
	2.txt: ITERATE ENTIRE HISTORY
		0x00000001158f57a0 14-Aug-2009 15:59:36
		0x00000001158f57e0 14-Aug-2009 15:59:38
		0x00000001158f5820 14-Aug-2009 15:59:42
	test29# rm 2.txt
	test29# undo -i 2.txt
	2.txt: ITERATE ENTIRE HISTORY
		0x00000001158f57a0 14-Aug-2009 15:59:36
		0x00000001158f57e0 14-Aug-2009 15:59:38
		0x00000001158f5820 14-Aug-2009 15:59:42
	test29# sync
	test29# undo -i 2.txt
	2.txt: ITERATE ENTIRE HISTORY
		0x00000001158f57a0 14-Aug-2009 15:59:36
		0x00000001158f57e0 14-Aug-2009 15:59:38
		0x00000001158f5820 14-Aug-2009 15:59:42

	test29# sync; sleep 5; sync  <-- be sure undo isn't working
					 on cached in-kernel data.
	test29# undo -a -d 2.txt
	2.txt: ITERATE ENTIRE HISTORY
	diff -N -r -u 2.txt@@0x00000001158f57a0 2.txt@@0x00000001158f57e0 (to 14-Aug-2009 15:59:38)
	--- 2.txt@@0x00000001158f57a0   2009-08-14 15:59:33 +0000
	+++ 2.txt@@0x00000001158f57e0   2009-08-14 15:59:33 +0000
	@@ -1 +1,2 @@
	 a
	+a
	diff -N -r -u 2.txt@@0x00000001158f57e0 2.txt@@0x00000001158f5820 (to 14-Aug-2009 15:59:42)
	--- 2.txt@@0x00000001158f57e0   2009-08-14 15:59:33 +0000
	+++ 2.txt@@0x00000001158f5820   2009-08-14 15:59:33 +0000
	@@ -1,2 +1,3 @@
	 a
	 a
	+a
	diff -N -r -u 2.txt@@0x00000001158f5820 2.txt@@0x00000001158f5860 (to 14-Aug-2009 15:59:51)
	--- 2.txt@@0x00000001158f5820   2009-08-14 15:59:33 +0000
	+++ 2.txt@@0x00000001158f5860   1970-01-01 00:00:00 +0000
	@@ -1,3 +0,0 @@
	-a
	-a
	-a
	test29# 

:File System is mounted normally
:
:Backup1 on /Backup1 (hammer, local)
:But when the file is deleted the history also vanishes.

    This should only happen if the file is chflagged nohistory or the
    filesystem is mounted nohistory.  But again there might be
    cockpit trouble here as only meta data flushed to the media is
    recorded in the history.  Stuff held in kernel memory (up until
    the filesystem flush every 60 seconds or so) does not.

:> =A0 =A0Trying to find old file data on-media is possible but without any
:> =A0 =A0meta-data to point at it the best you can do is to try to pick it =
:out
:> =A0 =A0of the disk image.
:>
:
:How do I pick it out of the disk image?
:...
:Thanks
:
:Siju

    Hmm.  Well, something like: 'hammer -f <device> show' will
    dump the B-Tree and you can pick out records belonging to the
    file's inode number (obj field in the dump), and you should
    be able to pick out the inode number from deleted directory
    entries.

    The show command does not dump the actual data buffers though
    it does read them to check the CRC.  It would be fairliy easy
    to augment the command to also dump the data given a verbose
    option (-v).

    On a large filesystem the show command could take hours to
    run... it is literally picking every single byte of information
    out from the entire filesystem.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>