Hi folks,

I've been working on another video recovery project, this time involving a WolfBox dashcam that records three separate video streams, with audio present on only one.

What started as a recovery job turned into a fairly interesting reverse-engineering exercise. The recorder uses HEVC/H.265 video with proprietary structures, including tbgp metadata and interleaved media wrappers. One of the challenges was that conventional file carving and filesystem-based recovery couldn't reliably reconstruct recordings once the original allocation information was missing or damaged. There is also additional GPS data scattered around which really messes up carvers.

I ended up writing a native Windows C application to work directly against the physical media.

- Scans raw disk images for WolfBox recording structures.
- Identifies moov atoms, tbgp structures and physical media units.
- Reconstructs logical HEVC sample sequences from physical offsets, sample sizes and timing information.
- Handles the three video streams independently, without expecting AAC audio on every stream.
- Recovers video without requiring a working FAT filesystem.
- Can reconstruct usable video from orphaned physical fragments even when the original recording index is unavailable.
- Recovers JPEG images, which may provide additional clues about recordings.
- Exports playable MP4 video where sufficient data survives.

The current implementation is specific to the WolfBox recording structures we've studied, and results will depend on what physical data survives. It also cannot reconstruct bytes that have genuinely been overwritten.

I'm making the WolfBox tool and source available on GitHub for anyone interested in using it:
https://github.com/mkinderwater/wolfboxrecovery

Many thanks! This is getting to be a habit.

_________________
A backup a day keeps DR away.

... said the thousands of people YOU helped before my time...

The point about not requiring a working FAT filesystem is the part that stands out to me. If the directory entries are gone but the physical fragments survive, scanning for the recording structures directly seems like the sensible route rather than trying to rebuild the filesystem first. I'd be curious how reliable the sample-size matching is when fragments from the three streams are interleaved, since that seems like where false positives would creep in. Does the JPEG recovery help confirm offsets for the video samples, or is it handled separately?

No, JPEG is simply a mechanism to assist if there is underlying video which was not recovered (eg: overwritten).

The program does not require any filesystem to work, it's agnostic.

I would go as far to say most of camera's out there write FAT for the user, not for camera function. The camera already knows where the data is... although it speeds things up (indexing and such). It's likely a balance of function...

The interleave is deterministic, so once you figure out the formula sample sizes are indicated by camera operation. There is no guesswork involved.

But then again, you already knew that.

Yeah… emdash. Best check your rules…

Hopefully someone else understands what the heck I’m saying. It sure is getting annoying.

That’s the problem perfection, it’s just not normal.

The point about recovering from orphaned physical fragments without a working FAT filesystem is the part that matters most for dashcam cards, since the directory is usually the first thing to go. Building separate handling for the three video streams makes sense given how these units multiplex. Do the tbgp structures give you enough to bound each sample reliably, or do you fall back to heuristics when atom data is incomplete? Also curious whether the JPEG extraction is just for triage or whether it feeds timing back into the MP4 reconstruction.