Developer reverse engineers CapCut's BDVE cache encryption and releases open-source recovery tool

CapCut and JianYing, the desktop video editors from ByteDance, keep large intermediate video files inside their draft folders — in paths such as Resources/combination and Resources/videoAlg — where a single cache file can run to hundreds of megabytes. According to a detailed write-up on dev.to, those files look like ordinary MP4s but will not play anywhere: VLC and QuickTime reject them, and ffmpeg aborts with a "moov atom not found" error even though the file size on disk is complete.

What the hex dump revealed

The post's author describes inspecting the first bytes of one such file. A standard MP4 opens with an ftyp box — a four-byte size followed by the ASCII characters "ftyp". The cache file instead begins 3B 3B 3B 1B 5D 4F 42 4B. XOR-ing those bytes with 0x3B yields 00 00 00 20 66 74 79 70, which is exactly a 32-byte ftyp header. A single-byte XOR key is clearly involved — but applying it across the entire file corrupts it further, signalling that only part of the stream is scrambled.

How BDVE Type 1 works

Scanning to the end of the file, the author found a 68-byte proprietary trailer that ByteDance appends after the media data. It contains a bdve box holding a crpt sub-box, and among its fields are a version identifier (1), an algorithm identifier (also 1, for periodic XOR), 16 bytes described as reserved or salt, and a 32-byte SHA-256 digest computed over the big-endian encodings of the scheme's three parameters.

The obfuscation itself works like this: every step bytes along the media payload, a slice of length bytes is XOR-ed with a single-byte key, while the gaps between slices remain plaintext. The trailer digest is calculated from step, length and key, which means any candidate parameter set can be checked for an exact match.

Solving the parameters without brute force

With two independent 32-bit values, brute force would mean on the order of 2^64 combinations. Instead the author leans on the structure of the container and codec. Scanning backwards from the trailer locates the moov atom and its sample tables (stsz, stsc, stco/co64), which record the precise file offsets of the H.264 samples. Valid NAL units start with the four-byte start code 00 00 00 01 followed by a type byte — 7 for SPS, 8 for PPS, 5 for an IDR slice. A sample offset that falls inside an encrypted slice only matches those signatures once XOR-ed with the key, while a plaintext offset matches directly.

Each classified offset then becomes a modulo constraint: an encrypted offset proves that length is greater than the offset modulo step, and a plaintext offset proves it is at most that value. Testing a small set of candidate steps derived from common chunk sizes such as 49,435 or 65,536 narrows the field to a single (step, length) pair, which the trailer's SHA-256 digest then confirms. The author reports this solve takes milliseconds.

Decryption is pure bitwise inversion: XOR the slices where position modulo step is below length, drop the 68-byte trailer, and write the file out. Because nothing is transcoded, the author reports throughput above 100 MB/s — roughly four seconds for a 500 MB file — and claims the recovered H.264 and AAC packets are bit-for-bit identical to what the editor itself produces, with no generational quality loss.

The tool

The engine ships as CapCut Cache Recover, an open-source Python project on GitHub under the repository name pikadexofc/export-capcut-pro-video-free, currently at release v1.0.1. Features listed in the post include an interactive terminal selector that auto-indexes recent CapCut drafts, a native Windows save dialog for choosing output paths, resolution of GUID-style filenames into real project and clip names by parsing draft_meta_info. and draft_content., a four-tab dark-themed desktop GUI with drag-and-drop, and a roughly 12 MB standalone Windows executable that requires no Python installation. Notably, the project's advertised install route is a PowerShell one-liner that downloads and executes a remote script, so the usual caution about piping web content straight into a shell applies.

Why it matters

For anyone whose footage exists only inside a CapCut draft, this offers a way to recover the original bitstream without re-exporting or re-encoding. Technically, it is a tidy case study in attacking obfuscation rather than cryptography: the cipher is a repeating single-byte XOR, and the break comes from combining container metadata, codec-level structure, and a verification digest the format helpfully carries along. The caveats are real, though. Everything here is self-reported in a single blog post — the format description and the performance figures have not been independently verified — and ByteDance can change the cache layout in any update, which would break the solver. Recovering media from an application's cache may also sit uncomfortably with the app's terms of service, even when the user owns the underlying footage.