Once I had both versions of the files, I looked at them in a hex editor. Since there were some null bytes at the beginning of the video file, it wasn't hard to guess the string they were using. I'm not going to post the file themselves (for obvious reasons), but here's the first 16 bytes of the unencrypted and encrypted files (in hex and ascii, from xxd). Unencrypted:

0000000: 0000 0020 6674 7970 7174 2020 2005 0300 ... ftypqt ...

Encrypted:

0000000: 5241 4e64 2939 2623 2526 696e 6705 0300 RANd)9&#%&ing...

Maybe OP just xor'd the files with each other and the result was the RANDOM_STRING string followed by a pile of \0 bytes, repeat.

Edit: To clarify, I meant the encrypted and temporarily-decrypted-by-the-wrapper-script versions of the same .mov file.

The XOR of two ciphertexts under P XOR K isn't K (you have to know a plaintext to make that trick work, which, granted, you likely would here). The solution that doesn't require a known plaintext is comparably simple.

As the post says, he gained access to both decrypted and encrypted version. Then (p XOR k) XOR p = k.

It's so easy to solve repeating-key XOR for the key that the solution is a practical way to detect the scheme; you wouldn't even necessarily bother trying to detect it, you'd just run the "solver" (even calling it a solver sort of dignifies it a bit too much).

So that's generally true--Babbage's solution to the Vigenere was one of my favorite things to learn in basic crypto--but amusingly I'm not sure it would be easy in this case!

In particular, while I don't know the .mov file format backwards, the last step (after lossy encoding) is probably a lossless encoder, either LZ-type or some sort of entropy coder. This means that the plaintext is going to be a very good approximation of IID coinflips; in other words, a one-time pad _key_.

"Decoding" the repeated-key XOR also decodes the one-time-pad encryption of the repeated-key interpreted as plaintext. This is, well, hard.

(mov may have enough frame structure/boilerplate that this doesn't apply; I don't know.)

Is the solver just (cyphertext XOR plaintext)?

No (although that's how this guy solved this system).

After recovering the original file, he "compared the binary files". Likely this means he popped them both up in a hex editor and noticed the difference. XORing by a string is a very common very very trivial thing to do, so it would be pretty high on your list of things to notice.

He said it was decoded by a Python script.. so easy to understand from the script I guess.