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 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:
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
Article Link: http://contextis.com/resources/blog/overcoming-problems-within-forensic-analysis/