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

Date:   Thu, 11 Apr 2019 11:37:55 +0200
From:   Andrea Lo Pumo <alopumo@...ia.biz>
To:     linux-ext4@...r.kernel.org
Subject: Run mkfs.ext4 on an already existing ext4 filesystem. Seeking
 professional help or programming hints for the recovery.

Sorry for writing on this development mailing list, we are seeking an
expert in ext4, we are also willing to offer a professional contract
to solve this issue.

On /dev/sda1(*) there was an ext4 file system with a lot of large
files. Now, by mistake, mkfs.ext4 has been run on /dev/sda1. The
result is that now /dev/sda1 is "empty": mounting it shows no files.

Note *: actually, it is /dev/mapper/secure_storage, an encrypted
volume opened with LUKS: cryptsetup luksOpen /dev/sda1 secure_storage

Note 2: Ubuntu 18.04

This is my current understanding:

- Originally, /dev/sda1 was created with "mkfs.ext4 /dev/sda1"
- Now, the second "mkfs.ext4 /dev/sda1" has overwritten the
superblock, and all backups of the superblock (because it has created
the backups of the NEW superblock at the exact same locations of the
previous superblock backups).
- 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?

We are willing to discuss a professional contract tailored to solve
this issue. So if you have the right knowledge, or you know someone,
please let us know.

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.

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.

Thank you.

Best regards.