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:   Thu, 12 Oct 2017 15:02:03 -0700
From:   Kilian Cavalotti <kilian.cavalotti.work@...il.com>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: Recover from a "deleted inode referenced" situation

On Wed, Oct 11, 2017 at 7:36 AM, Kilian Cavalotti
<kilian.cavalotti.work@...il.com> wrote:
> On Tue, Oct 10, 2017 at 1:36 PM, Andreas Dilger <adilger@...ger.ca> wrote:
>> If the problem is only one of the partition being misaligned compared
>> to the logical volume, you can run the "findsuper" utility which is
>> part of e2fsprogs *sources* (it isn't built and packaged by default).
>> It will scan your block device and print out the ext2/3/4 superblocks
>> that it finds, along with the *byte* offset of each one found.  You
>> can use this to determine where the start of the filesystem should be.
>
> I will give this a try, thanks. Although I don't really had any issue
> to mount the filesystem r/o, which seems to indicate that there is no
> misalignment issue, right?

So... I tried findsuper, and it started listing things (including, for
some, non-printable characters in the "label" field, but I guess it's
just false-positives).

It's still running right now, but it already listed superblocks which
are obviously not related to the actual filesystem, but to raw disk
images (created via dd) that I had on that filesystem. For instance:

-- 8< ---------------------------------------------------------
# /usr/local/sbin/findsuper /dev/mapper/overlay
starting at 0, with 512 byte increments
byte_offset  byte_start     byte_end  fs_blocks blksz  grp
mkfs/mount_time           sb_uuid label
      1024           0  17983724322816   95590400  4096    0  Thu Nov
26 23:22:42 2015 12c2c019 1.42.6-5644
149595921408 18323935265112545280  13818231386087778304  2356078660
1024 28990  Sun Sep  7 13:34:55 2098 dc41997c 8�b���a`/����03��x^��|


��Fq��<<��_�sߠ蒿���Cx�X��Z��8���MxR��(R���/
                              �@�-+�>�F�������ۂ����@�
���$�׸}��|���)����
��K����y��l��0�ހc.3`B�~g݄`A�~��{�12��!^p���������k�Dn
0������oD��޳���I��;&ڢ�B�����/�Y� �_Ba�o���?$}�b'�B���%A�!�#�$@u�8~
293534171136 293534170112  18277258492928   95590400  4096    0  Thu
Nov 26 23:22:42 2015 12c2c019 1.42.6-5644
716505512960 716505511936  716628391936     120000  1024    0  Thu Aug
20 23:31:41 2009 d33ff464
716539067392 716530677760  716653557760     120000  1024    1  Thu Aug
20 23:31:41 2009 d33ff464
[...]
2556972232704 2556972231680  2560139979776     773376  4096    0  Tue
Jan 29 20:40:53 2013 da57c5f6 casper-rw
2557257444352 2557123226624  2560290974720     773376  4096    1  Tue
Jan 29 20:40:53 2013 da57c5f6 casper-rw
2557962087424 2557559434240  2560727182336     773376  4096    3  Tue
Jan 29 20:40:53 2013 da57c5f6 casper-rw
2558532512768 2557861424128  2561029172224     773376  4096    5  Tue
Jan 29 20:40:53 2013 da57c5f6 casper-rw
2559086160896 2558146636800  2561314384896     773376  4096    7  Tue
Jan 29 20:40:53 2013 da57c5f6 casper-rw
2559656586240 2558448626688  2561616374784     773376  4096    9  Tue
Jan 29 20:40:53 2013 da57c5f6 casper-rw
-- 8< ---------------------------------------------------------

That makes me think I should be able to recover those dd images with
the correct offsets, right? So for instance, looking at the
"casper-rw" label, I tried this:

-- 8< ---------------------------------------------------------
# dd if=/dev/ro_device of=/tmp/test.dd bs=4096 skip=2556972231680
count=773376 iflag=skip_bytes
-- 8< ---------------------------------------------------------

The resulting /tmp/test.dd file looks like a correct filesystem:
-- 8< ---------------------------------------------------------
# file /tmp/dd_test
/tmp/dd_test: Linux rev 1.0 ext2 filesystem data (mounted or unclean),
UUID=da57c5f6-1018-8a45-83b9-e12a39be7ce2, volume name "casper-rw"
(large files)
-- 8< ---------------------------------------------------------

But I can't seem to be able to mount it:
-- 8< ---------------------------------------------------------
[507159.565593] EXT2-fs (loop3): warning: mounting unchecked fs,
running e2fsck is recommended
[507165.114603] EXT2-fs (loop3): error: ext2_check_page: bad entry in
directory #2: : unaligned directory entry - offset=0,
inode=2263518911, rec_len=23425, name_len=177
[507165.129657] EXT2-fs (loop3): error: ext2_readdir: bad page in #2
-- 8< ---------------------------------------------------------

Did I misinterpret the output of findsuper?

Thanks!
-- 
Kilian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ