Forensic Imaging. So this should now boot… right?

Forensic Imaging. So this should now boot… right?

Often within forensics an investigation can benefit from analysing the machine as the user would see it. This can lead to artefacts being found that may not be obvious when using our analytical software. Take a user’s desktop as an example – physically viewing this may show how the user organises the machine and their preferences towards programs. This information can then be used when presenting evidence.

What would a jury better understand: a list of items found on the desktop and information on the background image, or a screenshot of the desktop as the user would have seen it?

Enter the Unbootable machine

During a recent investigation, a forensic image was used to create a bootable environment. However, upon booting, the process was interrupted and ‘Missing operating system’ message was displayed. 

This error was intriguing; on site the machine was seen to power back on without problems, but now it couldn’t pass the boot sequence. Because of the nature of this interruption, the Master Boot Record (MBR) was analysed. This blog’s intention is not to provide a comprehensive breakdown on the MBR; this has been covered extensively by several authors [1] [2]. However, the MBR can be broken down and summarized into two sections. Initially the boot code (blue) can be found. This is loaded into memory during the boot sequence and will subsequently handle the next stages of booting. Additionally the partition table (yellow) for the machine can be found within the MBR, this table gives information about the partitions found on the disk. 

Open-Source Information Gathering

Utilizing open-source information and the power of Steve – a Principal Software Engineer, within Context’s development team – this seemingly simple error would be our natural spring of frustration for the day.

As the error indicated a missing operating system, the first check was to ensure that the partition table pointed to the correct location. In this example, the first partition can be found at sector 0x20h (32d). This correlated with the partition in the image; that was the initial theory quickly shot down.

After completing some more information gathering and basic reverse engineering, we could see that this ‘Missing Operating System’ error could be reported if the MBR signature wasn’t correct. It should be 0x55AAh – as you can see in the image above that’s what ours is. This was a quick theory to rule out.

Continuing with the reverse engineering, some excellent write ups were found to contain useful information on the code’s structure and workings. Steve quickly found several stages in the boot code where the partition type was being checked.

Utilizing Assembly

Above shows the three partition type checks. The checksexamine the ‘partition type’ which is one of the bytes in each partition tableentry. Firstly, the MBR in this example checks for the type 0x0Eh. Thispartition type is FAT16 with LBA (Logical Block Addressing). The next twochecks are for 0x0Bh and 0x0Ch: FAT32 partitions with CHS (Cylinder, Head,Sector) addressing, and FAT32 with LBA respectively. If the partition found utilizesCHS addressing – or doesn’t match one of the predefined types – the code will handle this by parsing theCHS information.

There are plenty of resources online to learn the differencebetween CHS addressing and LBA addressing [3], but all that’s neededfor now, is that LBA has been in common use for such a long time that oftenpeople don’t even know what CHS is!

Nonetheless, this meant we could devise two work arounds.These in theory would force the MBR to use the LBA address (32d) rather than theCHS address (1:1:0). The initial theory was to change the first check (0x0Eh)to look for 0x07h; which is the correct type of our partition (NTFS). This canbe done easily within a hex editor: amend the value at offset 0x57h from 0x0Ehto 0x07h. The second theory was to change the type of the current partition toforce it to use the LBA handler, such as 0x0Eh. We tried both. Unfortunatelyanother one bites the dust as neither method worked.

Moving away from the reversing, but with a greater understandingthat the disk geometry was essential for loading this partition, Stevesuggested we look at VirtualBox’s configuration. This led us towards the vmdkfiles.

The vmdk file for the machine contains information about thedisk and its geometry, below is the section of the file that initially stood out:

ddb.geometry.biosCylinders="1024"

ddb.geometry.biosHeads="255"

ddb.geometry.biosSectors="63"

Here the file is defining the geometry of the BIOS. This is dynamically created during the first run on the machine.

At this stage, we were confident that the problem was that the MBR code simply wasn’t finding the correct starting location for the NTFS partition.

So, initially we replaced the geometry lines above to match the geometry of the disk defined by the partition table entry: C=1, H=1 S=0.

However this still gave the same error of ‘Missing operating system’ because the vmdk was automatically being restored to these default values when the VM booted.

During intelligence gathering, it was discovered that several people had also encountered similar problems. A common solution was padding the image with null bytes so the partition started at sector 63. They would then amend the partition table so the active partition’s starting sector was 0x3F (63d).

This solution had mixed results, and potentially caused more issues for some users.

As there was no quick way to pad our image and more importantly, to maintain the integrity of the image, Steve suggested we amend the vmdk file as follows.

ddb.geometry.biosCylinders="1024"

ddb.geometry.biosHeads="255"

ddb.geometry.biosSectors="32"

By doing so, we manipulate the geometry of the drive. In theory this should replicate the solution that was seen online, without padding the image. Hence the partition should become accessible.

Moment of truth, we run the VM, only to see:

Finishing with the now bootable machine

Success! This method therefore had no impact on the image,hence solving the problem and allowing the analysis of the machine to becompleted.

Overall, in order to resolve this error, the MBR wasdisassembled and analysed. By doing so, a basic understanding of 16-bit Intelwas required. The disassembly and open-source research led to the understandingof how this MBR handled partition types. Furthermore, recognition of the CHSvalues being used and the ability to interpret the information was essential –and nobody really thought this happens anymore because of LBA. Utilizing allthis information and solutions found online, we analysed the vmdk’sconfiguration and implemented a working solution to fix the issue, with nochanges made to the image.

[1] http://www.dewassoc.com/kbase/hard_drives/master_boot_record.htm

[2] http://thestarman.pcministry.com/asm/mbr/PartTables.htm

[3] https://www.thomas-krenn.com/en/wiki/CHS_and_LBA_Hard_Disk_Addresses

Subscribe for more Research like this

Please type your first name
Please type your last name
Please enter a valid email address

About Matt Raeburn

Trainee Analysis Consultant

CREST
CREST STAR
CHECK IT Health Check Service
CTAS - CESG Tailored Assurance Service
CBEST
Cyber Essentials
CESG Certified Product
CESG Certified Service
First - Improving Security Together
BSI ISO 9001 FS 581360
BSI ISO 27001 IS 553326