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:	Fri, 6 Nov 2009 10:02:10 -0500
From:	Greg Freemyer <greg.freemyer@...il.com>
To:	Alexey Fisher <bug-track@...her-privat.net>
Cc:	Theodore Tso <tytso@....edu>,
	Alexey Salmin <alexey.salmin@...il.com>,
	Jesper Jensen <linux-ext4_mailinglist@...ctor.dk>,
	linux-ext4@...r.kernel.org
Subject: Re: Formatted/repartitioned wrong disk, arrgh!

On Fri, Nov 6, 2009 at 9:43 AM, Alexey Fisher
<bug-track@...her-privat.net> wrote:
> Am Freitag, den 06.11.2009, 09:04 -0500 schrieb Theodore Tso:
>> On Fri, Nov 06, 2009 at 05:57:14PM +0600, Alexey Salmin wrote:
>> > I think the only thing I can recommend to you is to "grep for your
>> > files and hope for the best" (c)
>> > I don't know any automated way to restore files after complete
>> > destroying of fs, but there always is grep and hexdump :)
>>
>> Unfortunately, there isn't much else that can be done, since the inode
>> table has been zero'ed out.
>
> Do _not_ever_ change the disk after crush or what ever you did with it.
> Make an image of your partition (dd if=/dev/you_partition
> of=backup_of_partition) and try testdisk (photoreck) and/or sleuthkit.
>
>        Alexey

Totally agree with Alexey, but if the virtual drive was using a file
and not a partition or full drive, then you can just make a copy of
the virtual drive.  Then try to recover from the copy.  Make more
copies as you have problems, etc.

If the inodes are gone (and likely they are), then the only other
option you have left is "data carving".

Data carving depends on having your files useing contiguous blocks.
With ext4 and files less than 128MB (one extent), there is a reasonble
chance I believe that they will be contiguous.

I use a professional ($) tool to data carve, but I'm pretty sure there
are some opensource tools out there.

The way the work is to scan all the sectors on the drive (of virtual
drive) and look for file header signatures.  A lot of complex file
types have those.  And then they either find the file length somehow
from the internal file header, or they just grab x bytes of contiguous
data after the header.

Files over 128 MB will use 2 ext4 extents and I don't think there is
much chance of the extents being contiguous.  Possibly Ted or Eric can
comment on that?

Greg
-- 
Greg Freemyer
Head of EDD Tape Extraction and Processing team
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
Preservation and Forensic processing of Exchange Repositories White Paper -
<http://www.norcrossgroup.com/forms/whitepapers/tng_whitepaper_fpe.html>

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ