3 ms·

Could someone (OP?) provide more of the steps that might have gone (went) into discovering it was an XOR operation and the original string? Seems like an impres

Could someone (OP?) provide more of the steps that might have gone (went) into discovering it was an XOR operation and the original string? Seems like an impressive intuitive leap to me!

alxbrun 14y ago
He said it was decoded by a Python script.. so easy to understand from the script I guess.
jlgreco 14y ago
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.
ben0x539 14y ago
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.
- tptacek 14y ago
  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.
  - sold 14y ago
    As the post says, he gained access to both decrypted and encrypted version. Then (p XOR k) XOR p = k.
tptacek 14y ago
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).
- tekromancr 14y ago
  Is the solver just (cyphertext XOR plaintext)?
  - tptacek 14y ago
    No (although that's how this guy solved this system).
- ahh 14y ago
  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.)
asherlangton 14y ago
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...

Could someone (OP?) provide more of the steps that might have gone (went) into discovering it was an XOR operation and the original string? Seems like an impressive intuitive leap to me!

alxbrun 14y ago

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

jlgreco 14y ago

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.

ben0x539 14y ago

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.

tptacek 14y ago
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.
- sold 14y ago
  As the post says, he gained access to both decrypted and encrypted version. Then (p XOR k) XOR p = k.

tptacek 14y ago

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).

tekromancr 14y ago
Is the solver just (cyphertext XOR plaintext)?
- tptacek 14y ago
  No (although that's how this guy solved this system).
ahh 14y ago
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.)

asherlangton 14y ago

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...