bergman on 14 Feb 2008 15:11:02 -0800

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] "unerase" for linux ext3?

In the message dated: Thu, 14 Feb 2008 17:15:41 EST,
The pithy ruminations from Eric on 
<Re: [PLUG] "unerase" for linux ext3?> were:
=> JP Vossen wrote:
=> >> Date: Thu, 14 Feb 2008 09:48:15 -0500
=> >> From: Eric<>
=> >> Subject: [PLUG] "unerase" for linux ext3?
=> >>
=> >> I have a program that zero'ed out a file with some important data.

How did it "zero" out the file? If it really wrote 0 (NULL) to each byte in the 
file, you're probably SOL, except for going the NSA SEM route.

	(Evidently, today is TLA day around here.)

=> >> The file itself is still here but of zero byte length.
=> >>
=> >> Any way to recover that?
=> >
=> > I did that a year or two ago and spent a lot of time researching the
=> > issue.  At the time, there was no "good" way to do it.  All of the tools
=> > I found only work for ext2, and while you can trivially downgrade from
=> > ext3 to ext2, there is something about the ext3 journaling that
=> > basically makes it pointless.

Yep. There are limited recovery options with unrm.

Also look into the The Coroner's Toolkit (a terrific forensics package, now 
superceded by Sleuthkit.

See also:

=> >
=> > What I was able to do successfully was grep the raw device for strings I
=> > remembered from the file (Perl code).  Since my file was only a few
=> > hundred lines, "grep -C500 'string' /dev/hda1" or something like that
=> > worked.  Now when I say worked, it was ugly, but it got back enough to
=> > put the file back together.  Since then I've improved my backups and am
=> > a little more careful what I move where.
=> >
=> > If the file is binary, you are out of luck AFAIK.  I'd be delighted if
=> > someone could prove me wrong though.

Consider yourself delighted.

=> >
=> > Good luck,
=> > JP
=> When I ran the grep command it told me that "binary file /dev/sdb2 matches" :-)

Well, that's a Good Thing, depending on how complex the string you were using 

I hope that you've got /dev/sdb2 unmounted, or at least mounted read-only.

=> I need a command that finds the matching string and outputs the next block of 
=> characters to a file (on another device of course.).  Hummm  Perl comes to mind.

I've got a tool that will do that, as do the TCT and sleuthkit.

In my case, the hardware RAID controller on one system puked all over it's
magic bits at the beginning of the disk which exist to tell the hardware how the
array is layed out. Luckily, this was RAID1 (if it was RAID 0 or RAID 5 I would
have been SOL). Unfortunately, since the RAID data at the beginning of the
physical disk was gone, the hardware didn't know what to do with the drives, and
Linux (correctly) claimed that there was no boot sector and that the filesystem
table wasn't at the beginning of the disk.

I mounted the disk onto another (working) linux box, and wrote some perl to walk
through the unmounted disk, searching for binary data that matched the beginning
of a disk partition. This allowed me to recover the two partitions (~70GB of
data) on the disk as filesystem images onto the host machine. I then mounted
those as loopback images and wrote the data to new disks.

Anyway, here are the perl scripts. They might provide a starting point for your
endeavor. They might also eat all the pickles in your fridge, cover your cat in
pink Silly String, and swear in Albanian. The scripts are worth exactly what
you've paid for them.

	run the script, generating a list of disk blocks containing
		the data pattern you specify

	[optional] run the script, specifying the starting
		block and the end block (or data size) to recover from the


=> Thanks!
=> Eric



Philadelphia Linux Users Group         --
Announcements -
General Discussion  --