LibreOffice: An Unlikely Image Viewer

I encountered a series of deleted Enhanced Metafiles (EMF) files during the examination of a Window's-based system the other day.  EMF files are second generation Windows Metafiles (WMF), and early on in in most forensics careers, forensics examiners are taught to seek out those files as printer artifacts.  And, it just so happens, the path of these deleted files and a time stamp analysis suggested these files were in fact printer artifacts.

Sidebar: EMF is not only a printer artifact.  In fact, its not really accurate to call it a printer artifact.  Windows applications, like Microsoft Office, use the EMF format to make images portable between applications.  In printing from these applications, the document (even text documents) is converted to an EMF image and sent to the printer.

None of my native Linux image viewers was capable of displaying the EMF files.  I was considering downloading and running XnView, and excellent image viewer with over 400 supported image formats.  The new version being developed, XnViewMP (Multiplatform), is capable but unstable, so I didn't relish using it other than as a last resort. (And, as it turns out, EMF is not on the list of supported formats.)

A little poking around the Internet, and I discovered that OpenOffice supports EMF files.  Open Office, for the uninitiated, is and open office sweet with Microsoft Office document compatibility.  I have a fork of OpenOffice installed, called LibreOffice.  I opened the Draw program (though Writer would have worked as well), and I dragged the EMF into the document window.  Voila!  I had a perfect representation of the document sent to the printer.

LibreOffice can save the image as a PDF for distribution, if required.  While it might seem untenable to process numerous images in this manner (opening one at a time in LibreOffice to covert to another format), you may not be limited to this approach.  The unoconv program can be used to convert any document that can be opened by LibreOffice into any format that can be written by LibreOffice.  Automation, anyone?

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.