Working complete PC
Student Diskette, "New Boot A Ver 2.0+"
Student CD-ROM, "Room 6359"
The student will become familiar with:
Determining that the MBR is damaged/destroyed,
using the BIOS INT 13h Interface to read the MBR and DBR,
Analysis of the Microsoft FAT16 DBR,
Design and implement a new MBR.
The student will continue learning how to use the BIOS INT 13h interface for the purposes of data recovery including routine acquisition of the MBR and DBR of BIOS drive 80h, analysis of the DBR, and use the information it holds to design a new partition table to point to it. The student will then develop the new MBR in the DEBUG RAM workspace and use the INT 13h call to write it to the HDD. Upon reboot the original C: drive will be accessible once again.
The student should GHOST the DOS image onto the hard drive with a partition size of 600MB. Then run DEBUG and write zeros to the MBR with the following series of instructions:
f 100 2ff 0 a 300 mov ax, 301 mov bx, 100 mov cx, 1 mov dx, 80 int 13 int 3 g=300
Upon reboot the drive will fail to boot with the BIOS Boot Strap Loader "disk boot failure" message. Booting to a floppy and attempting to read the C: drive will result in the "Invalid drive specification" error. With the MBR destroyed, the usual response is: "So sorry, all data has been permanently lost." We shall see that this is certainly not so.
Upon completion of the preparation steps above, the student should boot to a floppy, run DEBUG and use the INT 13h call to read the MBR and then display it on screen. Obviously it will be all zeros because of the damage done purposely to it in the preparation steps above, but these procedures must always be done on systems that fail to boot and that fail to allow access to the C: drive in order to determine the nature of the problem. Corrupted values in the partition tables can result in the "Invalid partition table" message from the MBR 1st stage OS boot strap loader code, but ONLY if that code is in tact. Otherwise the system will simply hang after the BIOS startup screens. Again, in true data recovery scenarios the HDD should never be allowed to boot up in the event that the agent that has caused the damage is a virus many of which operate from the MBR and load into RAM immediately and begin doing damage. Logic bombs can also insert themselves into the MBR or be purposely inserted into there by the PC's owner such that they will wipe the HDD if booted by someone who does not know how to stop the bomb from going off.
Having ascertained the nature of the damage, a completely zeroed out MBR, the next step is to try to acquire the DBR. Under almost all circumstances the DBR will be located at C = 0, H = 1, S = 1. Write the DEBUG program to read this sector and run it. Display the top half of the DBR on screen:
-a 300 242C:0300 mov ax, 201 242C:0303 mov bx, 100 242C:0306 mov cx, 1 242C:0309 mov dx, 180 242C:030C int 13 242C:030E int 3 242C:030F (press [Enter] here to exit the assembler) -g=300 AX=0001 BX=0100 CX=0001 DX=0180 SP=FFEE BP=0000 SI=0000 DI=0000 DS=242C ES=242C SS=242C CS=242C IP=030E NV UP EI PL ZR NA PE NC 242C:030E CC INT 3 -d 100 1ff 242C:0100 EB 3C 90 4D 53 44 4F 53-35 2E 30 00 02 20 01 00 .<.MSDOS5.0..@.. 242C:0110 02 00 02 00 00 F8 00 01-3F 00 FF 00 3F 00 00 00 ........?...?... 242C:0120 CE DF 12 00 80 00 29 76-04 21 22 4E 4F 20 4E 41 ..?...)v.!"NO NA 242C:0130 4D 45 20 20 20 20 46 41-54 31 36 20 20 20 FA 33 ME FAT16 .3 242C:0140 C0 8E D0 BC 00 7C 16 07-BB 78 00 36 C5 37 1E 56 .....|...x.6.7.V 242C:0150 16 53 BF 3E 7C B9 0B 00-FC F3 A4 06 1F C6 45 FE .S.>|.........E. 242C:0160 0F 8B 0E 18 7C 88 4D F9-89 47 02 C7 07 3E 7C FB ....|.M..G...>|. 242C:0170 CD 13 72 79 33 C0 39 06-13 7C 74 08 8B 0E 13 7C ..ry3.9..|t....| 242C:0180 89 0E 20 7C A0 10 7C F7-26 16 7C 03 06 1C 7C 13 .. |..|.&.|...|. 242C:0190 16 1E 7C 03 06 0E 7C 83-D2 00 A3 50 7C 89 16 52 ..|...|....P|..R 242C:01A0 7C A3 49 7C 89 16 4B 7C-B8 20 00 F7 26 11 7C 8B |.I|..K|. ..&.|. 242C:01B0 1E 0B 7C 03 C3 48 F7 F3-01 06 49 7C 83 16 4B 7C ..|..H....I|..K| 242C:01C0 00 BB 00 05 8B 16 52 7C-A1 50 7C E8 92 00 72 1D ......R|.P|...r. 242C:01D0 B0 01 E8 AC 00 72 16 8B-FB B9 0B 00 BE E6 7D F3 .....r........}. 242C:01E0 A6 75 0A 8D 7F 20 B9 0B-00 F3 A6 74 18 BE 9E 7D .u... .....t...} 242C:01F0 E8 5F 00 33 C0 CD 16 5E-1F 8F 04 8F 44 02 CD 19 ._.3...^....D... -_
The DBR is here, but it must be analyzed to be sure that it does not contain corrupt data. There are only two actions that are taken against these sensitive sectors by malicious code: total destruction (overwriting them completely with zeros or any other value), or corruption of the critical values within them. Those attacks that only corrupt the data fields within the MBR or DBR are particularly nasty because it is impossible to tell that this has happened at a casual glance; the values must be tediously analyzed to be sure that they are uncorrupted. At this point follow the Analysis of the DBR module and verify all fields.
Once the DBR has been confirmed, the DBR worksheet should be filled out and look like this:
|00h||3 bytes||EB 3C 90||Jump Instruction to bypass the DPB|
|03h||8 bytes||"MSDOS5.0"||File System Driver Signature|
|0Bh||1 word||02 00||Bytes/Sector|
|0Eh||1 word||00 01||Reserved Sectors|
|10h||1 byte||02||# of FAT's|
|11h||1 word||02 00||max. # of root dir entries|
|13h||1 word||00 00||total sectors (partitions < 32MB)|
|15h||1 byte||F8||Media Descriptor|
|16h||1 word||01 00||sectors/FAT|
|18h||1 word||00 3F||sectors/track|
|1Ah||1 word||00 FF||total heads|
|1Ch||dword||00 00 00 3F||Hidden sectors|
|20h||dword||0012 DF CE||total sectors (partitions > 32MB)|
|24h||1 byte||80||BIOS drive #|
|25h||1 byte||00||current head|
|26h||1 byte||29||extended DPB signature|
|27h||dword||22 21 04 76||volume serial #|
|2Bh||11 bytes ASCII||"NO NAME "||Volume Label|
|36h||8 bytes ASCII||"FAT16 "||File System Type|
All values are valid. That is to say, they make sense. For example, the cluster size of 32 sectors/cluster (16KB) is correct for a 600MB partition according to the standard cluster size to partition size chart for FAT16B:
|Partition Size||Sectors/cluster||Cluster Size|
|16MB to <64MB||2||1KB|
|64MB to <128MB||4||2KB|
|128MB to <256MB||8||4KB|
|256MB to <512MB||16||8KB|
|512MB to <1024MB||32||16KB|
|1024MB to <2048MB||64||32KB|
There is enough information within the DBR to perform two important tasks: 1) Manually configure translations in the BIOS (if necessary) and 2) rebuild a partition table in the MBR that will allow DOS to recognize this partition again. For now it will be assumed that the translations are correct ,which they are since the BIOS was not modified in this exercise, (and known in this case to be Heads = 255 and Sectors/track = 63) and that only the partition table within the MBR needs to be rebuilt. The reconstruction of the partition table will now begin.
The reconstruction of the partition table must begin with an empty worksheet:
For now, the partition will be left non-bootable so the first field at offset 00h will be left as 00h.
The next three fields comprise the CHS address of the starting sector of the partition which is this DBR sector located at the expected address of C = 0, H = 1, S = 1. This means that the field at offset 01h will be 01, the field at offset 02h will be 01 and the field at offset 03h will be 00h.
The partition type is determined by the fields at offsets 13h, 20h and 36h of the DBR. The field at offset 36h reads "FAT16 " but this does not differentiate between types 04 (early FAT16 not supporting clusters), 06h (FAT16"B" supporting clusters), and type 0Eh (WIN9X FAT16B supporting LBA access to the HDD). Since the largest FAT16 partition is 2GB which does not require LBA the type 0Eh partition type is exceedingly rare and only needs to be tried when the type 06h does not work properly. So the work is to determine if the partition is a type 04 versus a type 06. If the field at offset 13h is empty and the field at offset 20h holds the partition size in sectors, then it is a type 06. On the other hand if the field at offset 20h is empty, and the field at offset 13h holds the partition size in sectors, then it is a type 04. In this example the field at offset 13h is empty and the field at offset 20h holds the partition size, therefore this is a type 06 partition and this is the value that must be placed into the partition table at offset 04h. Here is the new partition table worksheet so far:
The next three fields of the partition table hold the CHS coordinate of the ending sector of the partition. This information is not found directly in the DBR, but it can be determined directly from the information that is provided. Given that the partition starts in the sector at C = 0, H = 1, S - 1 and given the size of the partition in sectors, then adding the size to the LBA address of the starting sector will yield the LBA address of the sector that follows the last sector. Subtract one and the LBA address of the last sector will be found. Convert that back to CHS and the address will have been found that can then be placed into the fields at offsets 05h, 06h, and 07h:
SSLBA + StrucSize - 1 = ESLBA 63 + 1,236,942 (00 12 DF CE from field at offset 20h of the DBR) - 1 = 1,237,004 LBA-to-CHS LBA (TH X TS) = C, R1 R1 (TS) = H, R2 R2 + 1 = S So: 1,237,004 (255 x 63) = C:76, R1:16064 16064 63 = H:254, R2:62 62 + 1 = S:63
Therefore the CHS of the ending sector of the partition is C = 76, H = 254, S = 63. These numbers make sense, the sector is located on the last sector of the last head of a cylinder, exactly where FDISK likes to put it. Converted to hexadecimal: C = 4Ch, H = FE, S = 3F. The cylinder number is NOT larger than FFh so there will be no bits to carry into the sector number field. The field at offset 05h is then FE, the field at offset 06h is 3F, and the field at offset 07h is 4Ch. Here is the updated partition table worksheet:
The field at offset 08h of the partition table must be identical to the field at offset 1Chof the DBR. It means the same thing in both structures. In the case of the partition table it means the LBA-style offset to the starting sector or the distance to it in sectors. In the DBR it means the distance back to the MBR or EMBR that holds the partition table that defines it. Inserting the value of the field at 1Ch of the DBR the partition table worksheet now reads:
|08h||4 bytes||00 00 00 3F|
The partition size field at offset 0Ch of the partition table is obtained directly from the field at offset 20h of the DBR. The two both mean exactly the same thing (the size of the partition in sectors):
|08h||4 bytes||00 00 00 3F|
|0Ch||4 bytes||00 12 DF CE|
At this point the entire partition table has been designed. Now it must be implenmented on the hard drive and then the system will be rebooted to see if IO.SYS recognizes the new partition table and assigns a letter that is then accessible. Clear the DEBUG RAM workspace froom offset 100 to 2FF with zeros:
-f 100 2ff 0 -_
Now write the partition table into offset 2BEh of the planned new MBR. Important safety tip: DON'T FORGET ABOUT BYTE REVERSAL! Use the values directly from the partition table worksheet:
-e 2be 00 01 01 00 06 FE 3F 4C 3F 00 00 00 CE DF 12 00 -_
Now write the boot signature into the last two bytes of the planned new MBR for the hard drive:
-e 2fe 55 aa -_
At this point the MBR is ready to be written to the hard drive. Create the program code to write the data from offset 100 to 2FFh to the first physical sector of the hard drive, then execute it:
-a 300 242C:0300 mov ax, 301 242C:0303 mov bx, 100 242C:0306 mov cx, 1 242C:0309 mov dx, 80 242C:030C int 13 242C:030E int 3 242C:030F (press [Enter] here to exit the assembler) -g=300 AX=0001 BX=0100 CX=0001 DX=0180 SP=FFEE BP=0000 SI=0000 DI=0000 DS=242C ES=242C SS=242C CS=242C IP=030E NV UP EI PL ZR NA PE NC 242C:030E CC INT 3 -_
At this point the new MBR has been designed by hand, created in DEBUG RAM and written to the first physical sector of the hard drive. Reboot, remember that the hard drive is NOT bootable, to a floppy or bootable CD-ROM and then try "DIR C:" and the drive will be fully accessible at this point. The MBR has been recreated by hand and all files on the C: drive can be safely copied out to another drive. In the next module, the DBR will be the one that is destroyed and it will be rebuilt using the MBR.
Copyrightę2000-2006 Brian Robinson ALL RIGHTS RESERVED