[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: about extracting grub2 files from mbr
Re: about extracting grub2 files from mbr
Sun, 22 Jan 2012 20:22:06 -0800 (PST)
The first 512 bytes of a hard drive (provided that the hard drive is MBR-structured) form the MBR. (Master Boot Record). If you do "sudo dd if=[device path of hard drive, possibly something like /dev/hda or /dev/sda] of=/home/[user name]/Desktop/mbr_of_station72 [or some name you feel good with] bs=512 count=1", that copies the MBR to a file on your desktop. But you won't own the file, root will (because sudo was used). I then do a "sudo nautilus" or "sudo pcmanfm" (or what ever your file browser is), to get a file browser running as root, right-click the file, go to permissions, and set myself as owner of the file, then close the root file browser.
The "if" stands for "input file" and the "of" stand for "output file". Yes, there really is a file called sda (or hda or whatever) in you /dev folder. The file is 0 bytes big,
and whenever you write to it, the kernel intercepts that write call and instead sends that data you tried to write to the file to the hard drive, keeping the file at 0 bytes. Likewise, when you read from it, the kernel intercepts that read call, and instead of reading from a file that contains nothing, it sends data from the hard drive at you.
The "bs" is the block size. That says how much to read and then write at a time. "count" says how many blocks of reading/ writing will be done. We want to copy the first 512 bytes of data from the hard drive, so one block of 512 bytes will do that. So we do "bs=512 count=1". "bs=256 count=2" would also work, but technically would be a little slower. The less you copy at a time, the less chance for an error, but it will take longer the less you copy at a time.
Here's an example:
sudo dd if=/dev/sda of=/home/addresshidden/Desktop/station0_mbr bs=512 count=1
But that's the whole MBR. You are
only interested in the boot code of the MBR, which is the first 440 bytes. So you could do something like this:
sudo dd if=/dev/sda of=/home/addresshidden/Desktop/station0_mbr_boot_program bs=440 count=1
After the first 440 bytes is a 4 byte disk signature, followed by 2 bytes that are usually all zeros (they just chill there), followed by 64 bytes that comprise the partition table, which says where each partition begins and ends, possibly marks one partition as "active", and also has a partition id for each partition. The partition id is a serving suggestion as to what the partition is to be used for. Examples of MBR partition ids: 83 is code for "this is a linux partiton", 82 is code for "this is a linux swap partition", 0C is code for "this is an LBA FAT32 partition", EE is code for "don't mess. This is a GPT-structured hard drive. If you don't know how to handle GPT, just back away now before it's too late.". And the last 2
bytes are 55 AA. They're always 55 AA. They just chill there. If the BIOS sees that the last 2 bytes of the MBR aren't 55 AA, then it knows something's up, and won't continue booting the hard drive.
So Grub2 stage one is the first 440 bytes. Correct me if I'm wrong and it is actually the first 446 bytes (which would mean there is no disk signature and those 2 chill bytes won't be zeros, is how it would work, I imagine).
Grub2 stage one's job is to load Grub2 stage 2, which is too big to fit in only 440 bytes.
On an MBR-structured hard drive, the next 62 sectors are up-for-grabs. The first 63 sectors of an MBR-structured hard drive is referred to as track0. The first sector is the MBR. The next 62 sectors are just up-for-grabs. There is no standardised usage for that space. Anyone can write anything there. That is where Grub2 stage 2 goes, if you have an MBR-structured hard drive.
In the case that your hard drive is
GPT-structured, the first sector (512 bytes) is still an MBR. It contains only one partition in it's partition table, which spans the entire hard drive and has a partition type of EE. So if an OS doesn't know how to interpret GPT structuring, but still knows MBR structuring, it will interpret the protective MBR as normal, see that there's one big partition spanning the whole hard drive, and then back off. If it weren't for the protective MBR, it would see the whole hard drive as unallocated space and might be tempted to make some partitions on it and format them, demolishing data you had on the drive.
But after that first sector on a GPT-structured disk, is the second sector, which is the GPT header, followed by usually 32 sectors worth of partition table entries. So Grub2 stage one can't start reading from the second sector to the sixty-third sector to load Grub stage 2 in the case of a GPT disk, because the second sector and the third
sector and other sectors thereafter are in other use. Important use. That space is taken, and Grub2 stage 2 can't occupy the same space. So you actually make a special partition, called a BIOS boot partition, just for storing Grub stage 2. You mark the partition for such purpose by giving it a GPT partition id of EF02. (MBR partition ids are only one byte long, like "EF", and GPT partition ids are two bytes long, like "EF02".)
This is an example of extracting Grub2 stage 2 from a BIOS boot partition:
sudo dd if=/dev/sda3 of=/home/addresshidden/Desktop/grub2_stage2_from_bios_boot_partition bs=512
*that's where /dev/sda3 is the hardware abstraction file linked to the third partition of sda. Replace with whatever your BIOS boot partition is.
Notice you don't supply a count. That means to keep copying off the partition until the whole thing's been copied, which is what you want.
But with an MBR-structured hard drive, stage
two is located in the wild, untamed region from the second sector to the sixty-third sector. You can extract it with something like this:
sudo dd if=/dev/sda of=/home/addresshidden/Desktop/grub2_stage2_from_no_mans_land bs=512 skip=1 count=62
That tells dd to skip the first block (where a block is defined as 512 bytes by "bs") and copy off 62 blocks, starting on the one we skipped to.
In case you start trying to replace Grub code to see if that takes the password protection off, I'm moderately certain of the following:
So I don't believe you can copy and paste those first 440 bytes from any hard drive with Grub2 to any other hard drive, and still have Grub2 work on the destination hard drive. You can probably get away with copying them from one MBR-structured hard drive to another MBR-structured hard drive because the first 440 bytes of an MBR disk with Grub2 are programmed to look to the non-MBR part of track0 for stage 2 to
load (just make sure that Grub2 second stage is in the non-MBR part of track0!), but the first 440 bytes of a GPT-structured disk with Grub2 are programmed to look to a certain partition (specified by number, i.e. partition 1, partition 2, etc.) to find and load Grub2 stage2. So those 440 from a GPT-structured drive won't look to the non-MBR part of track0, but rather to a certain partition. If that partition (specified by number, i.e. partition 1, partition 2, etc.) doesn't exist or doesn't have Grub2 stage 2 raw-written to it on the destination hard drive, those 440 bytes won't succeed on an MBR-structured drive. Even if there was a partition with Grub2 stage 2 raw written to it on an MBR disk, and even if the partition number of that partition matched the partition number of the BIOS boot partition on the GPT disk that you copied those first 440 bytes from (and thus is the partition that those 440 are programmed to look for), that Grub2 stage one is
programmed to look to the GUID partition table to find that partition, not the MBR partition table, and wouldn't find the partition, because MBR-structured hard drives don't have GUID partition tables (GPTs). Also, going from one GPT-structured disk to another, one GPT disk might have the third partition be the BIOS boot partition, another the 6th, another the first. It could be any partition. So if you put the Grub2 second stage on the 3rd partition of a GPT drive, and you put a Grub2 stage one onto that drive copied from a drive with it's 5th partition as the Grub2 BIOS boot partition, Grub2 stage one will be looking to the 5th partition for Grub2 stage 2, when it's actually on the third partition.
So just use grub-install to install grub to hard drives, ok? Then everything will hunky-dory, and you won't have to do weird copy-pasting.
Also, if the filesystem of the partition containing the operating system is encrypted, you will need the
bootloader to be able to decrypt the filesystem to load the kernel and initrd (initial ramdisk). Also, even if the filesystem isn't encrypted, the actual kernel file and/or initial ramdisk file might be, in which case the bootloader will need to be able decrypt it/them.
Anyways, once you have your bootloader dumps, you can view them in wxHexEditor. wxHexEditor strictly requires libpng 1.2. So if you're more up-to-date than that, you'll need to download and compile libpng1.2. "sudo make install" should put it in /usr/local/lib. Then make a shortcut to the library in /usr/lib. wxHexEditor will see the shortcut and use it. Launching wxHexEditor from terminal without libpng 1.2 will tell you the exact file name of what it's looking for. That will tell you what to name the shortcut and what you will be shortcutting to to begin with. You can also use gHex, but I perfer wxHexEditor. If you run wxHexEditor as root, you can view the hardware abstraction
files directly. Just be super-careful if you edit anything. In fact, I'd extract with dd first, then edit. If it was a goof-up, then I just apply my dd dump back to the disk to put it back how it was. Don't edit the original dumps. Keep them. Another tactic is to not run any hex editors as root, copy the dumps, edit the copies of the dumps, then use a "sudo dd" to apply the edited dump copies back.
Further more, Grub stage 2 is programmed to look to a certain partition for grub modules and grub.cfg. So you got to get all those files where Grub expects them.
So there's really three parts to Grub: stage 1, stage 2, and files.