[ale] {Really} recovering an ext3 drive

[Danny Cox]

James,

On Mon, 2003-01-20 at 13:06, James P. Kinney III wrote:
> On Mon, 2003-01-20 at 12:43, Danny Cox wrote:
> > 	Here's what I have: an ext3 fs as a "magic number" of 0xef53 at offset
> > 0x438.  So, here's another stab at the problem:
> > 
> > 	Copy the 4 gigs or so that have the actual data info to a file you can
> > play with.  This also protects the original.  Write a small program that
> > reads 1024 byte blocks at a time, and search for that magic number at
> > offset 56 (decimal) in that block.  When found, you'll need that block
> > less one.  Copy those blocks into another file.  You should be able to
> > mount that file via the loop interface.  Perhaps then you'll see some
> > files, perhaps not.  At any rate, you can play with the copies as much
> > as you wish, while still protecting the original.
> 
> I'm not up on the physical layout of the data on the drive. How does the
> file system interact with the physical (or logical) structure of the
> hard drive. 
> 
> For instance, I have a hard drive that reports x sectors of y size and z
> cylinders. I have an inode size of w. It seems to me from your example
> that the offset is from the beginning of the inode marker? So the read
> size needs to be the block size?

	Inode marker?  Nope.  The beginning of the partition.  The read size is
whatever you want it to be.  This is just for finding the beginning of
the partition.  After that, copying the partition data to a file, and
mounting via loop will take care of block size differences.

> I really need to learn more of this.

	Blocks is blocks ;-).  From the filesystem point of view, it speaks in
blocks.  When first mounting an FS, the blocks are 1024 bytes.  After
that, it may change, according to info stored in the super block.  It
doesn't know or care where/how the data is laid out.  That's pretty
useful, meaning that you can build a filesystem on an IDE or SCSI disk,
RAID array (type 0, 1, 4, 5), a USB SmartMedia card, extra RAM, or even
a disk file via "loop".  The fs simply sez "gimme block 1", and the
lower level driver does so.  The blocks on any disk are simply numbered
zero through N, where N is the last accessable block on the drive.

	This also works with the /dev interfaces.  If I say "od -j1080 -x
/dev/hda1", I'll see ef53 as the first group of numbers.  So, with the
drive attached, you can try that (on the partition mentioned), and see
for yourself.  You can also copy (using dd perhaps) the data from that
partition to a file elsewhere, and play with that image.  If you have a
corrupt partition table, you can use the method I wrote about earlier,
to find the beginning of a partition.

	The hard part comes in *identifying* what type of fs is contained
within.  Each one has it's own way of burying the magic number somewhere
within the partition.  Ext2 and 3 both skip the first block (1024
bytes), but XFS doesn't.  The software RAID drivers place their "super
block" at the end of the partition.  I don't know (or, currently, care)
where DOS puts it's magic number, or even if it has one.

	Try this if you wish: run 'strings' on your various partitions.  With
most fs's, you'll find the name of the directory this fs is mounted on
amongst the first strings listed.  That's how fsck can tell you "last
mounted on /home".

	You may be amazed what you can find with 'strings', and 'od -c'.

-- 
kernel, n.: A part of an operating system that preserves the
medieval traditions of sorcery and black art.

Danny

_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale