[aklug] Re: Using DD to find partition table

From: Jim <jim.wadell@gmail.com>
Date: Mon Nov 19 2012 - 12:22:39 AKST

Thanks

Really good stuff

On 11/19/2012 12:12 PM, Leif Sawyer wrote:
> Okay, so basically, for a normal disk:
>
> # dd if=/dev/sdb bs=1k count=2048 of=sdb.head
> 2048+0 records in
> 2048+0 records out
> 2097152 bytes (2.1 MB) copied, 0.0493305 s, 42.5 MB/s
>
> # file sdb.head
> sdb.head: x86 boot sector, Microsoft Windows XP MBR, Serial 0xf8000000; partition 1: ID=0xde, starthead 1, startsector 63, 96327 sectors; partition 2: ID=0x7, active, starthead 0, startsector 96390, 156135735 sectors, code offset 0xc0
>
> # fdisk -l sdb.head
> You must set cylinders.
> You can do this from the extra functions menu.
>
> Disk sdb.head: 2 MB, 2097152 bytes
> 255 heads, 63 sectors/track, 0 cylinders, total 4096 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0xf8000000
>
> Device Boot Start End Blocks Id System
> sdb.head1 63 96389 48163+ de Dell Utility
> sdb.head2 * 96390 156232124 78067867+ 7 HPFS/NTFS/exFAT
>
> -----------
>
> But if there's garbage (i.e., a RAID header) at the beginning of the actual disk data, you want to skip ahead.
>
> # cat gparted-live-0.14.0-1.zip sdb.head> fake-sdb.head
>
> # file fake-sdb.head
> fake-sdb.head: Zip archive data, at least v1.0 to extract
>
> So my 'disk' is no longer a disk. But we can use dd to find the offset of the disk.
> This will take a while, depending on how large of a header you have. Yes, there's probably a faster way, but this is dirty and thorough.
>
> # i=1; while true; do dd if=fake-sdb.head bs=1 skip=$i count=512 of=tempsdb.dd; echo $i; file tempsdb.dd; i=$((i+1)); done 2>&1 | grep -B1 tempsdb.dd | grep -i -B1 'boot sector'
> 15796
> tempsdb.dd: x86 boot sector, code offset 0xc5
> --
> 63333
> tempsdb.dd: x86 boot sector, code offset 0xa0
> --
> 88251
> tempsdb.dd: x86 boot sector, code offset 0x7c
> --
> 172526
> tempsdb.dd: x86 boot sector, code offset 0x76
> --
> 178180
> tempsdb.dd: x86 boot sector, code offset 0xa4
> --
> 391124
> tempsdb.dd: x86 boot sector, code offset 0x30
> --
> 391236
> tempsdb.dd: x86 boot sector; partition 3: ID=0x51, starthead 205, startsector 1451942962, 3943943424 sectors, code offset 0x32
> --
> 391501
> tempsdb.dd: x86 boot sector, Microsoft Windows XP MBR, Serial 0xf8000000; partition 1: ID=0xde, starthead 1, startsector 63, 96327 sectors; partition 2: ID=0x7, active, starthead 0, startsector 96390, 156135735 sectors, code
> offset 0xc0
> --
> 423757
> tempsdb.dd: x86 boot sector, code offset 0x46, OEM-ID "Dell 4.1", sectors/cluster 4, root entries 512, Media descriptor 0xf8, sectors/FAT 94, heads 255, hidden sectors 63, sectors 96327 (volumes> 32 MB) , serial number 0x7d
> 3090b, label: "DellUtility", FAT (16 bit)
>
> ^c
> ---------------------------------
>
> Okay, so, we've got some options. The first few are fake, obviously, because there's no information about them.
>
> The last one is the start of a partition- this can also be useful, if you just want to grab partition data off of a drive and ignore the partition table entirely.
>
> The second-to-last is the winner, which we can prove thisaway:
>
> # dd if=fake-sdb.head bs=1 skip=391501 count=16384 of=tempsdb.dd
> 16384+0 records in
> 16384+0 records out
> 16384 bytes (16 kB) copied, 0.0272675 s, 601 kB/s
>
> # fdisk -l tempsdb.dd
> You must set cylinders.
> You can do this from the extra functions menu.
>
> Disk tempsdb.dd: 0 MB, 16384 bytes
> 255 heads, 63 sectors/track, 0 cylinders, total 32 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0xf8000000
>
> Device Boot Start End Blocks Id System
> tempsdb.dd1 63 96389 48163+ de Dell Utility
> tempsdb.dd2 * 96390 156232124 78067867+ 7 HPFS/NTFS/exFAT
>
>
>
> if you're -lucky- you'll find the offset is power-of-two divisible, and you can set
> the block-size to something appropriate, and then skip+copy via dd.
>
>
> Enjoy!
>
>
>
>> -----Original Message-----
>> From: aklug-bounce@aklug.org [mailto:aklug-bounce@aklug.org] On Behalf
>> Of Jim
>> Sent: Monday, November 19, 2012 8:09 AM
>> To: aklug@aklug.org
>> Subject: [aklug] Using DD to find partition table
>>
>> Good Morning
>>
>> Leif, can you post a bit more about finding the partition table? I tried
>> to build binwalk, but no luck so far.
>>
>> Thanks
>>
>> ------------------------------ Date: Mon, 19 Nov 2012 00:19:57 -0900
>> (AKST) Subject: [aklug] Re: Wife's hard drive is failing From:
>> bryanm@acsalaska.net On Sun, November 18, 2012 6:44 pm, Leif Sawyer
>> wrote:
>>>> Use dd to grab the first meg or so of the drive, and put the
>> resulting file on
>>>> a usb key or different drive, so your not exercising the failed drive
>> during
>>>> the next process.
>>>>
>>>> Use dd on the extracted file to search for a partition table, using
>> seek to
>>>> skip ahead in the file 1 byte at a time until you find the correct
>> offset.
>>>> Then you can dd the failing drive into a new drive, skipping ahead
>> that
>>>> offset, so that the partition table is written correctly on the new
>> drive.
>>>> I've done this with a couple of failed raid'd drives, and it has
>> worked for
>>>> me.
>>> There is a utility called binwalk:
>>> https://code.google.com/p/binwalk/
>>>
>>> that will do the stepping-through for you, so you don't have to
>>> manually increment the seek. I haven't used it personally, but
>>> it's a great idea.
>>>
>>> --
>>> Bryan Medsker
>>> bryanm@acsalaska.net
>>>
>>>
>>> ------------------------------
>>>
>>> End of aklug Digest V11 #168
>>> ****************************
>>> ---------
>>> To unsubscribe, send email to<aklug-request@aklug.org>
>>> with 'unsubscribe' in the message body.
>>>
>> ---------
>> To unsubscribe, send email to<aklug-request@aklug.org>
>> with 'unsubscribe' in the message body.

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Mon Nov 19 12:22:52 2012

This archive was generated by hypermail 2.1.8 : Mon Nov 19 2012 - 12:22:52 AKST