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!