February 16, 2018
In late December 2017 I was alerted to someone looking for help to repair a damaged video from a dash cam, video which may have captured a horrible accident.
I got in touch with Erik and he gave me more detail. While Erik was driving to work, he saw a car accident a fair distance away at an upcoming intersection. After pulling over to the side of the road, he unplugged his dash cam because he was concerned about video being overwritten due to its limited memory if he left it on. Unfortunately, by unplugging the dash cam shortly after the accident he prevented the video from being written properly to the storage media inside the camera. When he tried to view the video later in the day to see if it would be valuable to the police (because he did not get a good look at what happened with his own eyes), he realized the video was damaged:
Fortunately, I work for a company that encourages pro bono work. This case seemed to be a good fit, so I asked Erik for the damaged video file and started to work on it. I also asked Erik to secure the storage media from within the dash cam, because after all we are digital forensics practitioners and we might be able to access more relevant data on the storage media itself.
I was hoping initially that the repair would be as simple as adding a footer to the partially saved video file, so we could at least view up until Erik unplugged the camera. A good resource for looking up file headers and footers is Gary Kessler’s File Signatures Table (https://www.garykessler.net/library/file_sigs.html).
Using Gary Kessler’s file signatures resource, I confirmed Erik’s video was a QuickTime movie file based on its header (in hex) of 66 74 79 70 71 74 20 20 (or, “ftypqt ”). Great!
Or, maybe not so great. There was no footer associated with that header in Gary Kessler’s file signatures resource, so repairing QuickTime video files might not be as simple as I had hoped.
Next up, knowing how many different QuickTime video codecs exist (see https://www.loc.gov/preservation/digital/formats/fdd/fdd000052.shtml for starters), maybe I just needed to use the right codec to view the partially written video. I used multiple video players (VLC Media Player, Irfanview, etc.) with a variety of QuickTime video codecs, without success
Maybe I could carve video from the file by using PhotoRec? Again, no success.
It turns out that repairing a QuickTime video file can be complicated. See this excellent resource from Aero Quartet (http://aeroquartet.com/movierepair/fix-mov-files). At this point I chose to use a tool designed specifically for repairing damaged QuickTime video files. Stellar Phoenix Video Repair (“Phoenix”) was my first choice as it cost less than $100 USD and I’ve had some success with their other tools.
Loading the damaged video file into Phoenix and beginning the repair was easy – there are very few options to worry about. Unfortunately, the file could not be repaired. We were not out of luck however, as Phoenix includes an option for adding a reference file which leverages the reference file’s headers and other metadata to assist in the repair.
Erik provided me with a short 15 second video from his dash cam of his car pulling into a parking lot. Using this short video as a reference, Phoenix was able to repair the damaged video file and recover 2 minutes and 40 seconds of previously inaccessible dash cam footage – including a clear view of the accident involving one car running into another head on. It is worth noting that another video repair tool we used was also able to recover video from Erik’s damaged video file, but it recovered 33 seconds less video than Phoenix.
I hope you enjoyed this Arsenal Insights case study!
Please support us, as we work to make maximum exploitation of electronic evidence more accessible, by learning more about the powerful and unique functionality our tools provide. You can learn more about our tools at https://ArsenalRecon.com/#products. Thank you!
Digital forensics practitioners may not be aware of the nuances of what happens when introducing various BitLocker activities into the mix of hibernation and in-file TRIM.
Once you think through the implications of what can be done not only with multiple document versions extracted from FSD files as ODC Recon has always done, but what can be done with the granular revision information that can be found within FSD files and temporary collaboration data, you should be having a “lean back in the chair” moment.
The workflow for launching virtual machines has been significantly improved in Arsenal Image Mounter v3.1.101! You will now see a single dialog box (rather than a series of prompts) which consolidates important options related to launching virtual machines.
Join our mailing list to arm yourself with updates about Arsenal tools, training, and research. Our mailing list is double opt-in so you will need to check your email and confirm your subscription before receiving our mailings.
or (617) 277-3625
Terms & Conditions