linux-ext4 - Re: Run mkfs.ext4 on an already existing ext4 filesystem. Seeking professional help or programming hints for the recovery.

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] [day] [month] [year] [list]

Message-ID: <20190411212340.GB28307@mit.edu>
Date:   Thu, 11 Apr 2019 17:23:40 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Andrea Lo Pumo <alopumo@...ia.biz>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: Run mkfs.ext4 on an already existing ext4 filesystem. Seeking
 professional help or programming hints for the recovery.

On Thu, Apr 11, 2019 at 11:37:55AM +0200, Andrea Lo Pumo wrote:
> - The inode map has been overwritten too.
> - However, the data is still there in the disk, and also the related
> inode structures. (Just the inode map is missing right?). So, if one
> is able to locate these inode structures, the relative files could be
> recovered. We know the name of important directories and files to be
> recovered. Could this help?

Unfortunately, what gets overwritten is the inode table, which
contains the inode structures.  So all of the information which says,
"logical block N of inode M is located on physical block P" is gone.

So your only hope is going to be to use a program which looks at
individual data blocks, and assumes that (for the most part) files
tend to be allocated contiguously on the storage device.  Fortunately,
such a tool has already been written, and it is an open source tool
called PhotoRec[1].  I see however, you've already tried PhotoRec.

> I could also invest some programming efforts to solve this issue, by
> hacking some available tools, if this could help and is not too
> complex. In this regard, I have this question: given that I know the
> name of some important directories and files to be recovered,
> theoretically I could write a program that "greps" the name of the
> file in /dev/sda1 and, around that point, I should locate the inode
> structure, and with the inode recover the whole file? Any hint toward
> this direction? I don't have experience with ext programming, but I am
> willing to hack.

Yeah, unfortunately, no.  You'll be able to find the directory data
block, sure.  And that will contain the inode number.  But mke2fs
overwrites the entire inode table, so there's nothing that you can
find.

> Final question: are there tools to handle this situation? testdisk and
> ext4magic do not seem to give good results. Photorec is useless to
> recover large .tar.gz and .ogg files, and more importantly the name of
> the file, which we also need.

You've listed the primary tools that are available already.  It is
possible to configure mke2fs to create an undo file, and then when
something screws up they can use the e2undo file to unwind the
modifications made by mke2fs (or e2fsck, if the undo file generation
is enabled by e2fsck).

This feature is not enabled by default, mainly because (a) it slows
down the mke2fs and e2fsck operations, and that tends to make system
administrators cranky, and (b) you have to put the e2undo file
somewhere, and you need to have some kind of scheme to delete old
e2undo files.  So there is a lot of distribution integration changes
that has never been done.

Telling you this now isn't particularly helpful, since it's basically
suggesting that you close the barn door after the horse has escaped.
However, along with other changes you might want to make to your
procedures (such as doing regular backups) to avoid future mistakes of
this ilk, it might be something to consider.

Good luck, and sorry there's not much else help we can offer you,

					- Ted