help needed extracting the initrd...

[digitalAir]

I'm trying to extract the initrd from /dev/hda6 on my DSR6k running 2.0.

What I do know:
1. I know that the gzip signature starts with "1f8b" (which is actually a byte swapped 8b1f, I think)
2. I know you can extract the entire partition with this command: dd if=/dev/hda6 of=hda6.bin

What I did:
on the TiVo: dd if=/dev/hda6 of=~/hda6.bin
on the TiVo: sz ~/hda6.bin

What I found:
the only 1f8b I found in the file was at offset 0x084793 -- NOT on a word boundary, so I'm very confused...

Can someone give me a pointer on where to look for more info on how to do this? or tell me what I'm doing wrong...

thanks,

[BubbaJ]

look at your extracted partition with a hex editor.. look at the dd command that clears the initrd, you'll see where it starts..

[digitalAir]

Ahh, so it starts in the same place -- no matter which kernel...

I didn't bother to look at that since the only one I found was for clearing 2.5 and I'm trying to get the 2.0 initrd...


thanks,

[digitalAir]

Okay... I'm still not getting it...

I assume that you are referring to this command:
dd if=/dev/zero of=/dev/hdx3 bs=1k seek=852 count=1196

So, I believe this says that the initrd starts at an offset of 852 * 1024 (0x0d5000) and ends at the end of the partition at (852 + 1196) * 1024 (0x200000). Correct?

So, I should be able to extract the initrd with 1 of these 2 commands:

dd if=./hda6.bin of=./hda6.img bs=1024 skip=852 count=1196
or
dd if=./hda6.bin of=./hda6.img bs=1024 skip=852 count=1196 conv=swab


Correct?

but gunzip says neither of these files is in gzip format. And, mount doesn't recognize the files either.

So, what piece of logic am I missing??? :confused:

[BubbaJ]

There's a different (also posted, but by me) command for extracting from 2.0

The piece of logic you are missing is the part wehere you LOOK at the data with a hex editor around those locations.

[digitalAir]

BubbaJ,

Ok. I found your post about 2.0.1 where you said the offset is 844 instead of 852. In that post, you also questioned whether 2.0 had an initrd. Did you ever confirm whether or not it does?

I dl'd a 2.5 kernel image from here and it very clearly has a gzip signature at 0d5020.

But I can't find anything that even remotely resembles an initrd around d5020 or 0d3000 (the offset referenced for 2.0.1) -- not even in an uncompressed format...

I looked at it in a hex editor and around that area, it contains text strings like "bdzf", which is seen both above and below this offset...


arrrgghghhh... :(

[digitalAir]

I don't think 2.0 has an initrd...

1st block of data from /dev/hda6 (2.0)

000000: 00 52 50 4f 80 01 00 00 00 00 06 70 00 00 00 00
000010: 80 01 00 00 00 0c e0 00 00 0c e0 00 00 00 00 00
000020: 3c 00 80 01 7c 16 f3 a6 3c 20 80 0c 60 21 c0 00
000030: 38 00 00 00 94 01 ff f0 3c e0 80 01 38 e7 21 90
000040: 7c e8 03 a6 4e 80 00 20 00 00 00 00 00 00 00 00


1st block of data from /dev/hda3 (2.5)

000000: 00 52 50 4f 80 01 00 00 00 00 08 5e 00 00 00 00
000010: 80 01 00 00 00 0d 50 00 00 10 bb e7 00 00 00 00
000020: 3c 00 80 01 7c 16 f3 a6 3c 20 80 0d 60 21 30 00
000030: 38 00 00 00 94 01 ff f0 3c e0 80 01 38 e7 21 90
000040: 7c e8 03 a6 4e 80 00 20 00 00 00 00 00 00 00 00


in examining the 2.5 image, I found that the value in red corresponds to the starting offset of the initrd. The value in blue corresponds to (what appears to be) the end of it. Exactly 32 bytes after the address in blue is the "kernel release key".

then, re-examining the 2.0 image, I found that the values in red and blue are the same... thus a zero-length initrd. And, exactly 32 bytes from the address in blue is the "kernel release key"...

am I right? or did I make another huge (and flawed) logic leap? :)

[BubbaJ]

nope... that looks perfectly reasonable..