David Day , in Cyber Crime and Cyber Terrorism Investigator's Handbook, 2014
Master Boot Record
The MBR is stored on the first sector of the hard disk and is created along with the first partition on the drive. It is loaded into memory as one of the first actions during system start up. The MBR is comprised of a small section of operating system independent code, a disk signature, the partition table and an MBR signature. The disk signature is a unique four byte identifier for the hard drive, that is to say it should be unique for each drive attached to a system. It is used for purposes such as identifying the boot volume, and associating partitions and volumes with a specific drive. The MBR signature, sometimes referred to as the magic number, is set to value 0xAA55, which simply identifies it as a valid MBR. The partition table informs of the start position and length of each partition on the hard disk. During system start up the MBR code is executed first, and is responsible for parsing the partition table and identifying which partition is marked as active. Once the active partition is identified control is passed to that partitions boot sector, sometimes referred to as the volume boot record (VBR). The VBR is created when the drive is high level formatted for the use with a particular operating system.
Alijohn Ghassemlouei , ... Russ Rogers , in The Hacker's Guide to OS X, 2013
Master Boot Records
Historically, computers booted from hard disks by looking at the Master Boot Record (MBR). And each hard drive was addressed by cylinder-head-sector (CHS) addressing. The CHS schema was eventually replaced with logical block addressing, which is still in use today, even in GPT.
In systems where MBR partition tables are utilized, the actual information that describes how the partitions are laid out on the drive is contained in the MBR. The information here details how many partitions exists, what type of file systems are loaded on those partitions, and whether the partition is bootable or not.
Note
In a GPT based system, all information about partitions are stored in the GPT header. In order to avoid issues with legacy disk utilities overwriting the GPT, and destroying the information on the drive, the very first LBA on a GPT, LBA 0, contains legacy MBR information. The GPT boot header takes the next LBA, at LBA 1. In this manner, we provide a recognizable MBR for older disk applications, and ensure the GPT won't accidentally be overwritten. This is known as the Protective MBR, for just these reasons.
In How to Cheat at Microsoft Vista Administration, 2007
Partition Style
Most administrators who have not installed Windows 2003 Server with Service Pack 1 or the 64-bit version of Windows XP Professional will find the concept of partition styles a bit foreign. A partition style is the method that Windows Vista uses to organize partitions on a disk. Windows XP Professional only supported MBR partition styles on x86 computers while also supporting GPT on its 64-bit version. Windows Vista supports both on the x86 architecture.
Master Boot Record
The Master Boot Record (MBR) is the traditional partition style. The MBR contains a partition table that describes where the partitions are located on the disk. Before Windows 2003 SP1 and XP Professional 64-bit, administrators never had to worry about choosing the MBR, it was the only style supported. MBR disks can support up to four primary partitions or three primaries and one extended. Within the extended partition you can created unlimited logical drives.
Globally Unique Identifier Partition Table
The Globally Unique Identifier Partition Table (GPT) provides a more flexible way of partitioning disks than the older MBR scheme. It was introduced as part of Intel's Extensible Firmware Interface (EFI). This specification defines a new model for the interface between operating systems and platform firmware. You can find more information about EFI at www.intel.com/technology/efi. Although it may seem a bit more confusing with the use of GPT, this partition style can reside on either basic disks or dynamic disks. GPT in Windows Vista supports up to 18 exabytes and 128 partitions per disk. Since GPT does not limit administrators to four primary partitions, extended partitions and logical drives are not available with it. Figure 4.6 shows us being asked what type of partition style we want during the installation of a new hard drive.
Figure 4.6. The Partition Style during a New Drive Installation
Configuring a New Disk
In this section, we will configure and manage a new disk under Windows Vista. We will initialize the disk, create volumes, choose the file system for each volume, and even demonstrate how to shrink a volume. We'll start by partitioning a new drive after it has been installed.
In our example (as shown in Figure 4.6), when we first installed our new drive, we decided to use the MBR partition style. After selecting the partition style, you then decide if you want to use a basic disk or dynamic disk. As you know already, we converted a basic disk to a dynamic disk using the diskpart command. Now we need to create a volume on our new drive. In disk management, we must right-click the area of the new drive labeled as unallocated (shown in Figure 4.7). As you can see, the only option we have is to create a new simple volume. Remember, the reason for this is because we only have one disk we are creating this dynamic volume for.
Figure 4.7. Selecting a New Simple Volume
Now Windows Vista will run through a new simple volume wizard (as shown in Figure 4.8). At the New Simple Wizard initial screen, click Next.
Figure 4.8. The New Simple Volume Wizard
Next you are asked to specify the volume size. In our example, we will only choose 4GB (see Figure 4.9). After you have specified the volume size, click Next.
Figure 4.9. Specifying Volume Size
Now we assign the drive letter E to our newly created simple volume (see Figure 4.10). After doing so, click Next.
Figure 4.10. Assigning a Drive Letter to a Simple Volume
Now we come to the part regarding what file system we want to format this volume with. We will cover file systems in the next section, but as you can see in Figure 4.11, we have the choice of FAT, FAT32, and NTFS. Select NTFS and change the volume label to read Simple Volume. Keep the Allocation unit size as the default. After selecting NTFS, change the volume label and click Next.
Figure 4.11. Choosing the File System Type
We now come to the last screen in creating our simple volume. The Simple Volume Wizard provides us with a list of the settings we've chosen (see Figure 4.12). Since we know these are the settings we want, click Finish. If by chance you saw a setting you didn't mean to select, just click the Back button to the point where you made your mistake and make the correction there.
Figure 4.12. The New Simple Volume Wizard Completed
Once formatting of the new volume is complete, you should see the new simple volume listed in disk management, as shown in Figure 4.13.
Figure 4.13. The New Simple Volume Is Created
Something new in Windows Vista is the ability to shrink a volume without the use of third-party software. Shrinking a volume allows administrators to easily repartition drives without having to completely remove and re-create them. To shrink a volume, go to Computer Management | Storage | Disk Management. Select the volume you intend to shrink and right-click it. You'll see the option Shrink Volume, as shown in Figure 4.14.
Figure 4.14. Shrink Volume
When you select Shrink Volume, Windows Vista will query the volume for available shrink space. Next, you will see the screen to choose what size you want to shrink the volume to. In our example, we have chosen to shrink it to 1.95GB, but it will appear as 2.05GB, as shown in Figure 4.15. Click the Shrink button.
Figure 4.15. Choosing the Size for Volume Shrinkage
After Windows Vista has shrunk the volume, it will appear as shown in Figure 4.16. Our volume labeled Simple Volume is now 2.05GB, and the amount of unallocated space is up to 7.95GB.
Creating a Partition for Linux on an Existing Drive
If your machine is unable to support two hard drives (or you don't want to give up your DVD drive) it is possible to install Linux on a new partition. Partition Magic can be used to resize existing partitions to make room for the new installation.
The first step in this operation is to use the disk manager to defragment the drive. As a hard drive is used and files are allocated then deleted, a disk develops spaces between files. Modern file systems do a much better job of tracking and using these spaces, but spaces can develop none the less. By defragmenting the disk, the files on the disk are moved in such a way that these spaces are minimized. This ensures that the maximum amount of space is available for your alternate operating system.
After the disk is defragmented, the majority of its free space should be available in one large block. A new partition can then be created using a portion of this space. This operation requires a special tool such as Partition Magic shown in Figure 12.1.
Figure 12.1. Creating a New Partition with Partition Magic
At this point the new operating system can be installed in one of two ways. Most operating systems are able to install on any partition, and normal installation procedures can be followed. Be sure to select the correct partition (installing on the wrong partition will almost certainly destroy your data). The other option at this point is to assign the new partition to a virtual machine. By selecting the partition and assigning it to a virtual machine, your alternate operating system can be installed without having to shutdown the primary operating system. In addition you also get the fringe benefit of not having to burn DVDs or CDs to do the installation. (You may also be able to use a DVD image on a system without a DVD drive.) It should be noted that the process of performing an installation using multiple CDs can be done without too much trouble. Whenever the installation process requires a new CD, the ISO images can be "virtually" ejected and the next image inserted by "mounting" it.
Continue with the installation process, although the master boot record should not be replaced. Here again, using a virtual machine can protect your primary operating system boot loader from being replaced. Unless you assign the primary operating system partition to the virtual machine deliberately, the virtual machine will not be able to read the primary partition at all.
Notes from the Underground…
Avoiding Problems with Changing Hard Disk Numbers
It should be noted that booting in a virtual environment can result in different hard disk numbers than those assigned when a machine is booted on the native hardware. This situation can be partially resolved by configuring the boot process to look for devices by disk label instead of by hard disk number. The fstab file (found in the /etc directory) can also be modified so that disks are located by label. This will stabilize the changing environments and allow your server to boot both natively and in the virtual environment with fewer issues.
At this point it's time to make it possible to boot to either operating system. This can be done in a couple different ways. First you may be able to use the bios to boot to an alternate hard drive. This is the method I used because it seems simplest. The other option is to use a boot loader to choose the operating system to boot.
The boot loader software is the first program loaded on your system. The two most common boot loaders are the Windows boot loader and the Linux boot loader known as Grub. Either of them can perform the function of booting both Windows and Linux. In order to boot Windows using Grub, you have to make the correct entries in the /boot/grub/menu.lst file. The following entries assume that Linux is installed on your primary disk and Windows is on a second hard drive.
title Windows XP
root (hd1,0)
rootnoverify (hd1,0)
map (hd0) (hd1)
map (hd1) (hd0)
chainloader +1
Booting Linux with the Windows boot loader is slightly more complicated. The Windows boot loader needs a copy of the boot sector (first sector) from the Linux box. This sector is enough to initiate the boot onto another partition. The easiest way to obtain the boot sector from the Linux partition is to boot it using a virtual machine. If this is not possible most Linux distributions allow you to boot using a Live CD configuration. It may also be possible to boot using a standalone Linux distribution such as Knoppix. Once you have booted into a Linux environment, the first sector of the disk should be copied to a file. The command DD accomplishes this task.
dd if = /dev/hda2 of = bootsector.sec bs = 512 count = 1
The preceding command copies the single 512-byte sector from the disk into a file called bootsector.sec. This file must then be copied over to the Windows partition. I usually put it in the root of the C drive. The boot.ini file must then be modified with an entry pointing to this boot sector. An example is shown in Figure 12.2.
Figure 12.2. Modifying the boot.ini file with the Linux Boot Sector
The first entry was already present in the boot.ini file. If you want to boot to the original partition by default then it should be left as the first entry in the file. If you want your new partition to be the default, then it should be first in the table. The timeout parameter determines how long the boot loader waits before the default entry is chosen. If you make this time too short you won't have time to pick the alternate operating system and may find yourself having to reboot often. If you extend the timeout you may end up taking too long to boot up without interaction (note that you can always hit Enter at the boot screen to pick the currently highlighted choice). An example of the boot screen created by the boot.ini file in the preceding section is shown in Figure 12.3.
Figure 12.3. A Boot Menu with a Linux Option
At the completion of this procedure you will be able to boot either operating system on the machine natively.
At this point you need to configure a virtual machine hosted in one of the operating systems to boot the other physical partition. Chapter 4 discusses how to allow a virtual machine to access a physical drive. It is highly recommended that all of the other partitions be blocked from the virtual machine. Accessing an active partition can cause serious issues with your machine.
Prior to the execution of GRUB, the system BIOS loads into memory the Master Boot Record (MBR) and executes it contents. The total size of the MBR is 512 bytes, which contains the bootloader program and disk partitioning information. The preinstallation form of the GRUB program is divided into two stages and the MBR loads GRUB stage 1. The stage 1 program uses the first 446 bytes with the remaining 64 bytes allocated to the partition table of the hard disk drives. The purpose of GRUB stage 1 is to find and load GRUB stage 2 (which may reside physically elsewhere on the hard disk). GRUB stage 1 must be flexible enough to access many different file system types. This flexibility is accomplished because GRUB stage 1 has loaded a large number of mass storage device drivers. Once loaded, GRUB stage 2 can perform the following three different functions:
■
load a predefined Linux kernel (for example, vmlinuz-version.gz).
■
allow selection of which operating system to boot on dual boot system.
■
entry of different boot parameters.
Once GRUB stage 2 has loaded the Linux kernel, it must also load a virtual file system and execute the Linux kernel.
Fast Facts
Linux is started using a bootloader, often using GRUB which can be summarized as follows.
■
Is loaded by the BIOS and resides in the MBR.
■
Can access many different filesystems (ext3, file allocation table (FAT), VFAT, and so forth).
■
Is dynamically configurable after you have installed Linux.
Peter Barry , Patrick Crowley , in Modern Embedded Computing, 2012
OS Boot Loaders
In the context of a legacy Intel architecture boot-up from a mass storage device, the MBR contains the initial code sequence to the next boot stage. The boot loader is primarily responsible for getting the operating system from wherever it is stored and copying it to memory to launch. The OS boot loader must be aware of the local file system if the operating system is stored on a mass storage device. For example, a common file system format is FAT32; if you wish to use a USB key to load/store the OS, then the boot loader must have support for the target file system. There are a number of Intel architecture boot loaders:
•
GRUB2—A GNU unified boot loader, build time support for legacy and OS. It supports the selection of which of the installed operating systems to boot (multiboot). The boot loader supports a wide range of file systems and boots a number of operating systems.
•
VxWorks™—This is a widely used real-time operations system; we will cover the boot sequence in more detail below.
•
Syslinux—A boot loader for the Linux operating system that operates off an MS-DOS/Windows FAT file system.
•
Eboot—The Microsoft WinCE boot loader.
To give an idea of what issues are involved in implementation, we will describe the VxWorks boot loader further. The VxWorks RTOS supports a wide range of embedded architectures such as ARM, Intel architecture, MIPS, and PowerPC. The general debug deployment model is to use a bootROM image, which then downloads the kernel image; the bootROM image can load the kernel image from a number of locations either on a local file system or frequently over the network for debug environments.
VxWorks provides a bootsect.bin binary file. The file must be copied to the MBR of the boot mass storage device. The MKBT program (which works on Windows) can be used to copy the bootsec.bin file. You could use the Linux dd command for the same action. The bootsect.bin initial bootstrap loads the bootrom.sys file. The bootROM sysfile is the VXWorks boot loader, which can then load the OS. The VxWorks boot loader can support either legacy or UEFI by replacing a single INT 13h command with the equivalent UEFI command. The same steps are applicable for all environments; on Intel architecture the steps are partitioned into one additional step (Kernel Copy) since the actual boot loader(s) in the sequence may not all fit on the SPI flash image. Figure 6.5 shows examples of the different stages and location of images.
FIGURE 6.5. Examples of Boot Stage Image Locations.
Although the BIOS has a provision for transferring memory map and other platform details to the boot loader and on the target operating system, real-time operating systems such as VxWorks provide the flexibility to reuse the settings established during the BIOS phase or to have a predefined memory map and re-probe the platform capabilities. The RTOS may be configured to re-enumerate the entire PCI bus as part of the driver initialization sequence. For example, the Intel Atom Processor E6xx Series reference platform VxWorks BSP has a defined INCLUDE_MTRR_GET to true. This has the behavior of loading a copy of the MTRR registers set by the BIOS. Alternately, the BSP can statically allocate a table to set up the cache control in the MTRR tables. The normal/safest option is usually to rely on the BIOS set values, but you may want to have more control in an embedded OS.
ARM-based platforms also typically use a boot loader to initialize the platform directly from the reset vector and launch the OS. There are many loaders for embedded systems, of which Redboot and DAS U-Boot loaders are quite commonly used. They perform basically the same behavior as we described above except when it comes to the information exchange and services offered to the booting operations system. In general, an embedded boot loader will set up the hardware, initialize data tables to provide information exchange, and then transfer control. Once control is transferred, no further use of the boot loader is made. The transfer of information is far simpler than those that have evolved in the Intel architecture environment. The Intel architecture platform has evolved to have platform-specific firmware, table-driven boot loaders, and operating system initialization. This allows the industry to keep a very significant proportion of the platform changes as data table updates in firmware, and makes it less likely to have to make code-specific updates in the boot loaders or operating systems.
As a general rule, on other embedded platforms you must make modifications to the boot loader for each SOC or platform. The communication of information between the boot loader and the operating system is limited. For example, Redboot provides a memory map, and some other platform-specific knowledge is provided using ATAG_∗∗∗ parameters. You may also need to make kernel platform modifications; for example, Linux requires many runtime changes for machine_type() calls for specific platforms. This can be problematic for maintenance and the development of board support packages (BSPs). To get an indication of the differing approaches and the resultant changes that can be seen in the Linux kernel tree, the linux/arch/arm contains no less than 59 machine directories and 12 platform sub-trees. Naturally, not all variations are due to the boot model, but the partitioning of initialization between boot loaders and kernel is an aspect.
In How to Cheat at Windows System Administration Using Command Line Scripts, 2006
Clean
You use the Clean command to remove all volume and partition formatting from the disk in focus. All data is deleted. On Master Boot Record (MBR) partitions, the partition information and hidden sector information are overwritten, and on GPT disks, the GPT partition information and protected MBR are overwritten. The GPT partitions do not have any hidden sector information. The syntax of this command is:
The only parameter of this command is All, which specifies that each sector on the disk be written with a 0. This implies that the data on the disk will be deleted completely.
Littlejohn Shinder , Michael Cross , in Scene of the Cybercrime (Second Edition), 2008
Viruses
Viruses are programs that are usually installed without the user's awareness and perform undesired actions that are often harmful, although sometimes merely annoying. Viruses can also replicate themselves, infecting other systems by writing themselves to any diskette that is used in the computer or sending themselves across the network. Viruses are often distributed as attachments to e-mail or as macros in word processing documents. Some activate immediately on installation, and others lie dormant until a specific date or time or a particular system event triggers them. For more information, see the article "How Computer Viruses Work" at www.howstuffworks.com/virus.htm.
Viruses come in thousands of varieties. They can do anything from popping up a message that says "Hi!" to erasing the entire contents of a computer's hard disk. The proliferation of computer viruses has also led to the phenomenon of the virus hoax, which is a warning—generally circulated via e-mail or Web sites—about a virus that does not exist or that does not do what the warning claims it will do.
Real viruses, however, present a real threat to your network. Companies such as Symantec and other AV software vendors design their products to detect and remove virus programs. Because new viruses are created daily, it is important to download new virus definition files, which contain information required to detect each virus type, on a regular basis to ensure that your virus protection stays up-to-date.
The types of viruses include:
▪
Boot sector viruses These are often transmitted via a diskette. The virus is written to the Master Boot Record (MBR) on the hard disk, from which it is loaded into the computer's memory every time the system is booted.
▪
Application or program viruses These are executable programs that, when run, infect your system. Viruses can also be attached to other, harmless programs and can be installed at the same time the desirable program is installed.
▪
Macro viruses These are embedded in documents (such as Microsoft Word documents) that can use macros, small applications or "applets" that automate the performance of some task or sequence.
Viruses that are programmed to "go off" (activate and destroy data or files) on a certain date are called time bombs or logic bombs. One of the first of this type to gain worldwide attention was the Michelangelo virus in the early 1990s, which attempted to erase the hard disks of infected PCs on March 6, the birthday of the famous painter. A few years later, a disgruntled ex-employee of Omega Engineering planted a time-bomb virus on the company's network that resulted in approximately $10 million in loss and damage. He was convicted of the crime and sentenced to 41 months in prison.
On the Scene
Understanding the Virus Threat
The most dangerous aspect of computer viruses (as is true of their biological counterparts) is their ability to "mutate" into something else. Of course, this mutation doesn't happen spontaneously, but virus writers build on the code of others to make relatively benign viruses more destructive—and to avoid detection by AV software.
Littlejohn Shinder , Michael Cross , in Scene of the Cybercrime (Second Edition), 2008
Boot Sectors and the Master Boot Record
Although many sectors may exist on an HDD, the first sector (sector 0) on a hard disk is always the boot sector. This sector contains codes that the computer uses to start the machine. The boot sector is also referred to as the Master Boot Record (MBR). The MBR contains a partition table, which stores information on which primary partitions have be created on the hard disk so that it can then use this information to start the machine. By using the partition table in the MBR, the computer can understand how the hard disk is organized before actually starting the operating system that will interact with it. Once it determines how partitions are set up on the machine, it can then provide this information to the operating system.
Note
At times, you'll hear about boot viruses that infect your computer when it's started, which is why users have been warned never to leave a floppy disk or other media in a bootable drive when starting a machine. Because the MBR briefly has control of the computer when it starts, a boot virus will attempt to infect the boot sector to infect the machine immediately after it's started, and before any antivirus (AV) software is started.
0 Response to "How To Create A Master Boot Record"
Post a Comment