Today I made a python script that can extract the master boot record from devices connected to the computer. It’s not very great, but it’s an achievement for me.
While developing a filetype search toolkit (more to come of that in a later post), my acting as managing director advised me on making a cross platform master boot record (MBR) analyser. At first I was set back to the thought of making one, I’ve never dealt with extracting such low level data from a computer before; without the use of commercial forensic tools anyway. I’ve done some basic analysis on MBRs before, locating the partitions, and building up an image of what the partitions would look like in a visual way given their partition locations and sizes.
The first decision was what programming language to use. At first, it was C++, with the thought that it’s cross platform compatible, and no doubt allows the ability to read the MBR. Downsides of course, means a lot of code to not blow my leg off with the pit falls of C++. There was some pieces of code around that is able to extract the MBR with C, but it needed some modification for my own requirements. The initial plan was that the program would extract the MBR into a file, then the user could upload the file to the filetype search toolkit, which would then analyse it and show graphical results. Then I started to see some pit falls, making the program work for windows was easy, but then to also work on Linux, and OSX was when I decided to jump off C++ and think of an alternative language. There was just too much code writing platform checks, than actual code that did the job I wanted.
So a new language… Python! Why didn’t I go with python to begin with? It’s cross compatible (to an extent), supports a GUI (tkinter), and doesn’t need to be recompiled for each platform. I think the main reason I didn’t go with python to begin with is because I wasn’t 100% sure of its capabilities. So after a few hours browsing around, I found a few techniques on how to extract the MBR which I could then analyse. Awesome! Time to start programming. A few more hours past, debugging, testing, cleaning up code, restructuring code execution layout, more testing, and manual MBR analysing just because I found it interesting being able to view the MBR on all my devices. Here’s a screenshot of what was happening:
This picture shows quite a lot of information. It shows a MBR of physicaldrive6 (the SanDisk Cruzer USB memory stick), list of disk drives, the SanDisk Cruzer properties, Samsung SSD properties (more on that later), a calculator, and the Administrator Command Prompt showing the bytes per sector for the SanDisk Cruzer (as well as the remains of the output of the MBR extractor. So what really went on in this image? Well, after running the MBR extractor upon all paths known (yes, I know, it’s trying to get the MBR from osx/linux directories, the program isn’t complete yet for platform detection), it outputs *.mbr files for each drive. You can download the PhysicalDrive6.mbr here to follow along. Now lets do some analysis on it!
Open the file up in your favourite hex editor, in my case it was wxHexEditor since it supports a feature that allows tagging bytes to a colour and giving them a name (very useful for this kind of thing; an alternative is HxD. In the next picture there are five blocks highlighted, the first four are the partitions, the last is the MBR boot signature 0x55 0xAA. The last four bytes of the first partition are highlighted red, this represents the number of sectors (in little endian; so read them backwards!).
Lets shamelessly plug these numbers into our programmers calculator and see how many sectors there are:
Now we know how many sectors there are, lets find out how many bytes are stored within a sector:
So now we know there are 15630336 sectors, and within each sector is 512 bytes. The next logical step is to multiply the values together to get total available bytes: 15630336 * 512 = 8002732032B
You can go further and divide it into number of kilobytes now: 8002732032 / 1024 = 7815168KB
and further for number of megabytes: 7815168 / 1024 = 7632MB
once more to gigabytes: 7632 / 1024 = 7.453125GB
or the shameless way: (including the 1000 trick of marketing bytes)
and that’s how you determine the size of a partition! What else is there?
The first byte 0x80 means it’s a bootable partition, the next three bytes are the start of the cylinder/head/sector (CHS), the 0x0B is the partition type code for WIN95 OSR2 FAT32, the next three bytes are the end of the CHS, another four bytes for the logical block address (LBA) and then finally as we covered, the number of sectors.
The CHS and LBA will be for another post… But now you can do basic analysis of a master boot record!
Also here’s a (incomplete) script of the MBR extractor python source code. Use it at your own risk!
I’ll do some more development on this script as I have more
bugs to kill features to implement in the future, as well as how to incorporate it into the filetype search toolkit currently under development.