In a previous post, we acquired the image. In this post, let's learn about the disk image which was acquired.
Let's verify the MD5 hash of the image:
kali@securitynik:~/forensics$ md5sum linux_mint_usb.raw e995c8773f355b895792fafdc24e80d4 linux_mint_usb.raw
Looks like a match with what we saw in the previous post.
kali@securitynik:~/forensics$ cat linux_mint_usb.hash | grep md5 Total (md5): e995c8773f355b895792fafdc24e80d4
Before mounting the disk, let's see what we learn from "fdisk --list"
kali@securitynik:~/forensics$ sudo fdisk --list linux_mint_usb.raw [sudo] password for kali: Disk linux_mint_usb.raw: 29.3 GiB, 31457280000 bytes, 61440000 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 Disklabel type: dos Disk identifier: 0x00051443 Device Boot Start End Sectors Size Id Type linux_mint_usb.raw1 2048 61437951 61435904 29.3G c W95 FAT32 (LBA)
Above, we see we have a disk reported as "29.3" GiB
We see the sectors are of size 512 bytes
Units: sectors of 1 * 512 = 512 bytes
We also see the disk seems to have one partition which is Win95 FAT32.
Device Boot Start End Sectors Size Id Type linux_mint_usb.raw1 2048 61437951 61435904 29.3G c W95 FAT32 (LBA)
Let's now look at the raw bytes, to confirm some of the information above.
What we know so far, is the disk has sectors of 512 bytes. The first sector contains the Master Boot Record (MBR). The MBR is considered the most important data structure on the disk and is created when the disk is partitioned. It loads code from the bootable partitions which in turn execute your operating system bootloader. While every hard disk contains an MBR, its code is only used if the disk has an active primary partition.
Let's look at the first 512 bytes where the MBR resides.
00000000: fab8 0010 8ed0 bc00 b0b8 0000 8ed8 8ec0 ................ 00000010: fbbe 007c bf00 06b9 0002 f3a4 ea21 0600 ...|.........!.. 00000020: 00be be07 3804 750b 83c6 1081 fefe 0775 ....8.u........u 00000030: f3eb 16b4 02b0 01bb 007c b280 8a74 018b .........|...t.. 00000040: 4c02 cd13 ea00 7c00 00b0 a103 0000 0000 L.....|......... 00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000110: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000120: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000130: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000001a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000001b0: 0000 0000 0000 0000 4314 0500 0000 0020 ........C...... 000001c0: 2100 0cfe ffff 0008 0000 0070 a903 0000 !..........p.... 000001d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000001e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa ..............U.
Above shows the first 512 bytes of the master boot record.
Here is a breakdown of those 512 bytes
Offset 0 - 445 (length 446 bytes):
This is the boot code area. However, this may be broken down further. It may instead be offset 0-439 representing the boot code, with offset 440-444 (4 bytes) representing the disk signature and this is finally followed by 2 bytes of NULL bytes (0x00 0x00) starting at offset 444. As you see we still have 446 bytes.
Let's verify this using "xxd":
First we tell "xxd" to start at offset 0, span a length of 439 bytes and group the results in groups of 4 bytes.
kali@securitynik:~/forensics$ xxd --seek 0 --len 439 --groupsize 4 linux_mint_usb.raw 00000000: fab80010 8ed0bc00 b0b80000 8ed88ec0 ................ 00000010: fbbe007c bf0006b9 0002f3a4 ea210600 ...|.........!.. 00000020: 00bebe07 3804750b 83c61081 fefe0775 ....8.u........u 00000030: f3eb16b4 02b001bb 007cb280 8a74018b .........|...t.. 00000040: 4c02cd13 ea007c00 00b0a103 00000000 L.....|......... 00000050: 00000000 00000000 00000000 00000000 ................ 00000060: 00000000 00000000 00000000 00000000 ................ 00000070: 00000000 00000000 00000000 00000000 ................ 00000080: 00000000 00000000 00000000 00000000 ................ 00000090: 00000000 00000000 00000000 00000000 ................ 000000a0: 00000000 00000000 00000000 00000000 ................ 000000b0: 00000000 00000000 00000000 00000000 ................ 000000c0: 00000000 00000000 00000000 00000000 ................ 000000d0: 00000000 00000000 00000000 00000000 ................ 000000e0: 00000000 00000000 00000000 00000000 ................ 000000f0: 00000000 00000000 00000000 00000000 ................ 00000100: 00000000 00000000 00000000 00000000 ................ 00000110: 00000000 00000000 00000000 00000000 ................ 00000120: 00000000 00000000 00000000 00000000 ................ 00000130: 00000000 00000000 00000000 00000000 ................ 00000140: 00000000 00000000 00000000 00000000 ................ 00000150: 00000000 00000000 00000000 00000000 ................ 00000160: 00000000 00000000 00000000 00000000 ................ 00000170: 00000000 00000000 00000000 00000000 ................ 00000180: 00000000 00000000 00000000 00000000 ................ 00000190: 00000000 00000000 00000000 00000000 ................ 000001a0: 00000000 00000000 00000000 00000000 ................ 000001b0: 00000000 000000
After the 439 bytes, above I stated the next 4 bytes represents an optional disk signature. Let's verify this.
kali@securitynik:~/forensics$ xxd --seek 440 --len 4 --groupsize 4 linux_mint_usb.raw 000001b8: 43140500
If we look above at the "fdisk --list" output, we see the disk label is "0x00051443". This is basically the same value we see above from our last "xxd" output, with the exception that the bytes have been reversed, with the least significant byte being written first. This CPU is Little Endian byte order as shown below.
kali@securitynik:~/forensics$ lscpu | grep Endian Byte Order: Little Endian
Let's now verify offset 444-446. Above we stated, these two bytes are usually null bytes (0x00 0x00)
kali@securitynik:~/forensics$ xxd --seek 444 --len 2 --groupsize 4 linux_mint_usb.raw 000001bc: 0000
Good stuff, we have verified the first 446 bytes of the MBR.
Following that 446 bytes is 64 bytes, which represents the partition table. Each partition is represented as 16 bytes. Hence 16*4 is where the 64.
Let's now look at 64 bytes, starting at offset 446. This will take us to offset 510.
kali@securitynik:~/forensics$ xxd --seek 446 --len 64 --groupsize 16 linux_mint_usb.raw 000001be: 002021000cfeffff000800000070a903 . !..........p.. 000001ce: 00000000000000000000000000000000 ................ 000001de: 00000000000000000000000000000000 ................ 000001ee: 00000000000000000000000000000000 ................
Above, I started at offset 446, which represents where the boot code region ends, spanning 64 bytes while grouping the output in 16 bytes sequences. Each of those 16 bytes (row) represents a partition. At this point, we are able to confirm the disk has one partition, similar to what was presented to us via "fdisk --list".
Let's now peak into that partition. The partition table follows a standard layout, which is independent of the OS.
From a Hexadecimal view, those 16 bytes of partition 1 are:
kali@securitynik:~/forensics$ xxd --seek 446 --len 16 --groupsize 1 linux_mint_usb.raw 000001be: 00 20 21 00 0c fe ff ff 00 08 00 00 00 70 a9 03 . !..........p..
Breaking those bytes down further
offset 446: 0x00 above indicates this partition should not be used for booting. Valid values are "0x80" can be used for booting and "0x00".
offset 447: 0x20: "Starting Head"
offset: 448: 0x21: 6 of these bits (bits 0-5) are used for the "Starting Sector". Bits 6 and 7 are used by the "Starting Cylinder" field. Note and according to Microsoft "do not accurately represent the value of the fields, because the fields are either 6 bits or 10 bits and the data is recorded in bytes."
If we look at offset 448, from a bits (binary) perspective, we see:
kali@securitynik:~/forensics$ xxd --seek 448 --len 1 --groupsize 1 --bits linux_mint_usb.raw 000001c0: 00100001
Offset 449: 0x000c: 10 bits are used by the "Starting Cylinder" value. The maximum value across these 10 bits is 1023. Here is what the bits look like for this field. Note and according to Microsoft "do not accurately represent the value of the fields, because the fields are either 6 bits or 10 bits and the data is recorded in bytes."
kali@securitynik:~/forensics$ xxd --seek 449 --len 1 --groupsize 1 --bits linux_mint_usb.raw 000001c1: 00000000
Offset 450: 0x0c: defines the volume "System ID". if we look at the "fdisk --list" output again, we see "Id" has "c" and this is associated with "Type" W95 FAT32
kali@securitynik:~/forensics$ xxd --seek 450 --len 1 --groupsize 1 linux_mint_usb.raw 000001c2: 0c
Offset 451: 0xfe: "Ending Head"
kali@securitynik:~/forensics$ xxd --seek 451 --len 1 --groupsize 1 linux_mint_usb.raw 000001c3: fe
Offset 452: 0xff: "Ending Sector". Only bits 0-5 are used. Bits 6 and 7 are used by the "Ending Cylinder" field. Note and according to Microsoft "do not accurately represent the value of the fields, because the fields are either 6 bits or 10 bits and the data is recorded in bytes."
kali@securitynik:~/forensics$ xxd --seek 452 --len 1 --groupsize 1 linux_mint_usb.raw 000001c4: ff
Offset 453: 0xff: Another 10 bits field and once again according to Microsoft "do not accurately represent the value of the fields, because the fields are either 6 bits or 10 bits and the data is recorded in bytes."
kali@securitynik:~/forensics$ xxd --seek 453 --len 1 --groupsize 1 linux_mint_usb.raw 000001c5: ff
Offset 454: 0x00080000: This double word (DWORD) or 32 bits, represent the number of "Relative Sectors" starting at the beginning of the disk to the beginning of the volume.
kali@securitynik:~/forensics$ xxd --seek 454 --len 4 --groupsize 4 linux_mint_usb.raw 000001c6: 00080000
If you remember, we mentioned previously, this value is in Little Endian. This means we need to reverse these bytes to find the real decimal values. Therefore bytes "0x00080000" now becomes "0x00000800" or simply "0x800" as we can remove the leading 0s. This "0x800" when converted to decimal, represents the "2048" reported by "fdisk --list" as the "Boot Start"
Offset 458: 0x0070a903: The final 4 bytes of the partition represents the total number of sectors on this volume.
kali@securitynik:~/forensics$ xxd --seek 458 --len 4 --groupsize 4 linux_mint_usb.raw 000001ca: 0070a903
Similarly to what we did above, let's convert "0x0070a903" to become "0x03a97000" as we need to change the byte order. When "0x03a97000" is converted to decimal, we get "61435904" which represents the "Sectors" as returned by "fdisk --list"
Finally, multiply "61435904" * 512 (number of sectors) and we get the number of bytes as reported by "fdisk --list" for this partition. My calculation produced "29.294921398" which equates to the "29.3G" as reported by "fdisk --list"
We will ignore the 3 other partitions which falls at 459 - 509 as they are empty. The final 2 bytes at offset 510-512 reparents the signature or the end of sector marker. This signature is also used to mark the end of an extended boot record (EBR) and the boot sector.
kali@securitynik:~/forensics$ xxd --seek 510 --len 2 --groupsize 2 linux_mint_usb.raw 000001fe: 55aa
Now that we have a better understanding of the drive, let's now move to mounting it in the next post.
PS. I have to admit, the destination disk I was copying to ran out of disk space. I thought about redoing the post. However, I thought that would not add or take away from the analysis. However, I do believe by letting you know about my error, you will ensure that you don't fall for the same trap. As a result, always ensure your destination drive has at least 10% more disk space than your source drive.
References:
No comments:
Post a Comment