linux-ext4 - Re: ext4 undeletion question

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 28 Apr 2009 12:53:46 -0600
From:	Andreas Dilger <adilger@....com>
To:	Greg Freemyer <greg.freemyer@...il.com>
Cc:	"Michael B. Trausch" <mbt@...t.trausch.us>,
	Theodore Tso <tytso@....edu>, linux-ext4@...r.kernel.org,
	mike-mobile@...usch.us
Subject: Re: ext4 undeletion question

On Apr 28, 2009  13:55 -0400, Greg Freemyer wrote:
> On Tue, Apr 28, 2009 at 1:26 PM, Michael B. Trausch <mbt@...t.trausch.us> wrote:
> > Eh.  Thanks for the mention... gave it a shot, but it seems to fail
> > nearly immediately:
> >
> > Tuesday, 2009-Apr-28 at 13:21:41 - mbt@...t - Linux v2.6.29.1
> > Ubuntu Jaunty:[0-9/10014-0]:undel> sudo ext3grep --restore-all /dev/zestvg/home-retain-undelete
> > Running ext3grep version 0.10.1
> > WARNING: I don't know what EXT3_FEATURE_COMPAT_EXT_ATTR is.
> > ext3grep: ext3grep.cc:119: void run_program(): Assertion `be2le(journal_super_block.s_header.h_magic) == 0xc03b3998U' failed.
> > zsh: abort      sudo ext3grep --restore-all /dev/zestvg/home-retain-undelete

One question is whether you formatted this filesystem as ext4 to start
with, or did you upgrade the filesystem from ext3 and the files existed
before the upgrade?  If the latter it is much more likely that you can
recover.  If the former you need to add EXT4_FEATURE_INCOMPAT_EXTENTS
to the list of supported feature flags in run_program().

If the files were created under ext4 then the ext3grep tool will likely
have to be further modified to understand the extent format, which
might not be too hard if you are willing to poke at the code a bit.
It seems like the ext3grep author is receptive to answering questions
about that tool and we can answer questions about the ext4 extent layout.

At a quick glance, what would be easiest to start is to modify the
print_inode_to() function to check for the EXT4_EXTENT_FL being set
in the inode.flags() field.  Add a new extent() method to the Inode
struct that casts i_blocks[0] to struct ext4_extent_header and then
the i_blocks[3], i_blocks[6], i_blocks[9], i_blocks[12] to struct
ext4_extent if eh_depth == 0, or ext4_extent_index if eh_depth > 0.

The good news is that ext4 usually allocates file blocks contiguously
so if you can find the inodes themselves in the journal you can likely
extract most of the data just by printing the in-inode extents to find
the block ranges and then dumping the file data with 'dd'.

> > I did create a snapshot of it using LVM (durr, I didn't think of that
> > before) so the FS is preserved as it was... I just don't know how to go
> > about digging through it to get the directory that I deleted out.
> > Hopefully I can figure that out before terribly long, as I am stuck
> > until I do...

> WinHex is a commercial product for doing undeletes that supports
> Ext2/3, ReiserFS, Reiser4, and UFS.  You need the Specialist version
> to handle ext3.  It might handle ext4.

It is highly unlikely that this tool will understand ext4 enhancements as-is.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html