F12 Temptations

BIOS one-time boot menus are tempting, especially if you are a frequent forensics boot disc user like me.  I use boot discs to conduct preview examinations, something many people know as "device triage," and for imaging.  In fact, boot discs can be essential tools in certain device imaging scenarios (see Difficult Disk Imaging).  One-time boot menus make it easy to select alternate boot devices, like CD-ROM or USB, without wading into the BIOS settings.

I'm in the habit of accessing the BIOS, however, and not using the boot menu.  First, it gives me the opportunity to record the BIOS time settings and evaluate detected hardware, but also because one-time boot menus are not always clearly defined in startup messages.  They also vary from BIOS to BIOS, computer model to computer model, even from the same manufacturer!


But Dell does a good job of letting you know how to access their menu: F12.  And, there are a lot of Dell computers in the world.  And, let's admit it, its a lot easier to access the one-time boot menu (meaning, boot from a different device than default this time) than to access the BIOS Settings.  But, there is a very good reason not to be tempted by this Boot Device Nirvana, and I encountered it this weekend.

On Friday afternoon, I booted a Dell server with a Linux-based forensics boot disc.  It was a hardware-based stripped array.  After determining that the server had evidence on board, I chose to image it with Guymager.  The process was to take 8 hours, and I went home in the bliss of knowing that when I returned to work on Monday, my image would be waiting for me, along with a hash verification of the source drive (array).

What I discovered upon my return--both from an email and the condition of my equipment--is there had been a power failure during the imaging process.  Well, shortly after, in actuality.  But, the server had been set to reboot on power failure, and I failed to note that.  What I didn't fail to do, was change to boot order to ensure my book disc booted before the internal drives.  Therefore, the system was sitting at the boot disc OS desktop and not running the server!  In other words, no data had changed.  Had I used a one-time boot menu, this would not have been the case.

You might be thinking, "Well, it didn't really matter in this case, because the imaging process had completed."  To that I say, "Yes, you're right."  But, I didn't have a verified image, because, for an unknown reason, the hash digest of the source device did not match the hash digest of the data in the image.  However, because the server booted from the boot disc, and not the internal drives, I was able to hash the source device again and verify the data was the same in the image as on the drive!

Why did the Guymager source hash differ from the image and from my post-power failure verification?  I don't know.  But I had the opportunity to check the discrepancy, which is the point of this post.