Forensic Imaging. So this should now boot... right?

Show left menu  
Hide left menu  
Hard Drive 2 Icon

By Matt Raeburn, 15 March 2017

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. 

Missing operating system error




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. 

MBR

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.

MBR partition type check














Utilizing Assembly

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

There are plenty of resources online to learn the difference between CHS addressing and LBA addressing [3], but all that’s needed for now, is that LBA has been in common use for such a long time that often people 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 the CHS 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 can be done easily within a hex editor: amend the value at offset 0x57h from 0x0Eh to 0x07h. The second theory was to change the type of the current partition to force it to use the LBA handler, such as 0x0Eh. We tried both. Unfortunately another one bites the dust as neither method worked.

Moving away from the reversing, but with a greater understanding that the disk geometry was essential for loading this partition, Steve suggested we look at VirtualBox’s configuration. This led us towards the vmdk files.

The vmdk file for the machine contains information about the disk 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:

Successful logon
















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 be completed.

Overall, in order to resolve this error, the MBR was disassembled and analysed. By doing so, a basic understanding of 16-bit Intel was required. The disassembly and open-source research led to the understanding of how this MBR handled partition types. Furthermore, recognition of the CHS values being used and the ability to interpret the information was essential – and nobody really thought this happens anymore because of LBA. Utilizing all this information and solutions found online, we analysed the vmdk’s configuration and implemented a working solution to fix the issue, with no changes 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

Back to Top