5 ms·

Can someone explain how he got a hold of the decrypted .mov files that he compared the encrypted ones with? It's not very clear to me from the post, and I'm not

by pav3l 14y ago

Can someone explain how he got a hold of the decrypted .mov files that he compared the encrypted ones with? It's not very clear to me from the post, and I'm not familiar with Leaping Brain. Either way.. wow... XOR encryption with just such a short repeating string! I bet it wouldn't be too hard to decrypt it even without the original file, since the file signature alone would probably be longer than the string. DISCLAIMER: I'm just speculating, I don't know the .mov specs.

tedreed 14y ago
"Well, since they load the file from a Python script, it's easy to make a copy of the "decrypted" file before it's reverted." He edited their Python script to make a copy.
doorty 14y ago
The player decrypts the file before it is played and then encrypts again when it is finished, so if you grab the file while it is being used by the player then it will be decrypted.
srdev 14y ago
The "proprietary player" was just a Python script that made a temporary decrypted the video and ran VLC against it. So he just changed the Python script to keep around a decrypted copy rather than re-encrypt it away.
NickPollard 14y ago
From what he says, it sounds like the app is really a standard movie player, plus their 'encrypter', plus a python script that does the following: > calls 'decrypt movie_file' to create 'decrypted_movie_file' > calls 'play decrypted_movie_file' > calls 'delete decrypted_movie_file' He just made a copy of the python script that calls their own decryption module but removed the delete line.
- pav3l 14y ago
  I don't even know what's worse - their "proprietary encryption algorithm" or the fact that they used Python for a critical piece of distributed software that you don't want to be reverse-engineered!
  - tvdw 14y ago
    For the record, distributing Python scripts doesn't have to mean distributing the source: it's possible to just execute the compiled .pyc files, which are harder to crack than (for example) Java's .class files. Also, since xor is just a CPU instruction, you won't immediately notice it in the decompiled script (if you get that far). With all the overhead that decompilers tend to produce, it's really easy to miss.
    - revelation 14y ago
      You should really take a look at one of these .pyc files. They are very very verbose to the point that they even contain local variable names and the python code can be trivially decompiled from the bytecode. Literally the only thing that goes missing from .py to .pyc is comments.
      - jrockway 14y ago
        That's what an assembly dump looks like to an experienced reverse engineer. Writing something in a "compiled language" because it's more secure is like XOR-ing your video with RANDOM_STRING and calling it DRM. (Not that any DRM scheme can ever work, ever, but hey. At least some try to try.)
        tptacek 14y ago
        Can't work ever? Are you taking orders for hacked DirecTV cards? :)
        daeken 14y ago
        I think you guys have two different definitions of "work". jrockway seems to be arguing from a technical perspective, but you're likely arguing from a practical perspective. Sure, DRM can "never work" in that there's always the analog loop and all that. But it's absolutely possible to make it so insanely complex and difficult that no one will ever break it; DirectTV has shown that angle works, without a doubt.
tshtf 14y ago
He just performed a bitwise XOR of the plaintext and ciphertext stream to obtain the key. From the post: By comparing the binary files, I discovered the "proprietary video encryption" algorithm: for the first 15kB, each 1kB block has its initial bytes xor'd with the string "RANDOM_STRING". See: https://en.wikipedia.org/wiki/XOR_cipher https://en.wikipedia.org/wiki/XOR_cipher
mikeash 14y ago
Looking briefly at the .mov file format[1], it appears that any such file is guaranteed to have exactly the same bytes 4-11 (atom identifier and major brand identifier), is almost guaranteed to lead with three zero bytes (first four bytes are the length of the first atom, which is likely to be small), and will probably have the same bytes 12-15 (minor version number). If you know it's a .mov file, then you can extract "RAN" and "OM_STRIN" trivially, and the rest is easily guessable from there. In fact, since the first three bytes are probably zero, "RAN" will be right there in the file, ready for pondering. [1] https://developer.apple.com/library/mac/#documentation/QuickTime/QTFF/QTFFChap1/qtff1.html#//apple_ref/doc/uid/TP40000939-CH203-BBCGDDDF https://developer.apple.com/library/mac/#documentation/Quick...
asherlangton 14y ago
The wrapper script is GPL'd, so I copied it here: http://dl.dropbox.com/u/15447644/brainplayer_py.txt http://dl.dropbox.com/u/15447644/brainplayer_py.txt My modifications are on lines 553-556. The compiled app "fixes" the .mov file just long enough for it to be loaded into the player. If you have Leaping Brain's player installed (often branded with the content owner's name), the .mov files are in a hidden .media folder. On my Mac, they were in $HOME/Library/Application Support/LeapingBrain/catalog/$VIDEONAME/.media
- pav3l 14y ago
  Thanks for sharing! Hope you won't get in trouble for your post.
  - nacs 14y ago
    Not sure how he could get in any trouble from it due to the license at the very top of the file he linked: "# BrainPlayer is free software: you can redistribute it and/or modify # it under the terms of the GNU General Public License I'm sure Leapfrog hated to put that GPL license on there but were likely forced to due to the VLC components they're using that are GPL/LGPL.
    - alexkus 14y ago
      And, as per https://www.gnu.org/licenses/gpl-faq.html#DRMProhibited https://www.gnu.org/licenses/gpl-faq.html#DRMProhibited the DMCA cannot be applied to this software.
0x0 14y ago
Reusing one-time-pad keys means you can often very easily recover the plaintext simply by XOR'ing the two encrypted files, since it effectively takes the key out of the picture, see for example http://www.cryptosmith.com/archives/70 http://www.cryptosmith.com/archives/70 (where the key is literally taken out of the picture)

by pav3l 14y ago

tedreed 14y ago

"Well, since they load the file from a Python script, it's easy to make a copy of the "decrypted" file before it's reverted." He edited their Python script to make a copy.

doorty 14y ago

The player decrypts the file before it is played and then encrypts again when it is finished, so if you grab the file while it is being used by the player then it will be decrypted.

srdev 14y ago

The "proprietary player" was just a Python script that made a temporary decrypted the video and ran VLC against it. So he just changed the Python script to keep around a decrypted copy rather than re-encrypt it away.

NickPollard 14y ago

From what he says, it sounds like the app is really a standard movie player, plus their 'encrypter', plus a python script that does the following: > calls 'decrypt movie_file' to create 'decrypted_movie_file' > calls 'play decrypted_movie_file' > calls 'delete decrypted_movie_file' He just made a copy of the python script that calls their own decryption module but removed the delete line.

pav3l 14y ago
I don't even know what's worse - their "proprietary encryption algorithm" or the fact that they used Python for a critical piece of distributed software that you don't want to be reverse-engineered!
- tvdw 14y ago
  For the record, distributing Python scripts doesn't have to mean distributing the source: it's possible to just execute the compiled .pyc files, which are harder to crack than (for example) Java's .class files. Also, since xor is just a CPU instruction, you won't immediately notice it in the decompiled script (if you get that far). With all the overhead that decompilers tend to produce, it's really easy to miss.
  - revelation 14y ago
    You should really take a look at one of these .pyc files. They are very very verbose to the point that they even contain local variable names and the python code can be trivially decompiled from the bytecode. Literally the only thing that goes missing from .py to .pyc is comments.
    - jrockway 14y ago
      That's what an assembly dump looks like to an experienced reverse engineer. Writing something in a "compiled language" because it's more secure is like XOR-ing your video with RANDOM_STRING and calling it DRM. (Not that any DRM scheme can ever work, ever, but hey. At least some try to try.)
      - tptacek 14y ago
        Can't work ever? Are you taking orders for hacked DirecTV cards? :)
        daeken 14y ago
        I think you guys have two different definitions of "work". jrockway seems to be arguing from a technical perspective, but you're likely arguing from a practical perspective. Sure, DRM can "never work" in that there's always the analog loop and all that. But it's absolutely possible to make it so insanely complex and difficult that no one will ever break it; DirectTV has shown that angle works, without a doubt.

tshtf 14y ago

He just performed a bitwise XOR of the plaintext and ciphertext stream to obtain the key. From the post: By comparing the binary files, I discovered the "proprietary video encryption" algorithm: for the first 15kB, each 1kB block has its initial bytes xor'd with the string "RANDOM_STRING". See: https://en.wikipedia.org/wiki/XOR_cipher https://en.wikipedia.org/wiki/XOR_cipher

mikeash 14y ago

Looking briefly at the .mov file format[1], it appears that any such file is guaranteed to have exactly the same bytes 4-11 (atom identifier and major brand identifier), is almost guaranteed to lead with three zero bytes (first four bytes are the length of the first atom, which is likely to be small), and will probably have the same bytes 12-15 (minor version number). If you know it's a .mov file, then you can extract "RAN" and "OM_STRIN" trivially, and the rest is easily guessable from there. In fact, since the first three bytes are probably zero, "RAN" will be right there in the file, ready for pondering. [1] https://developer.apple.com/library/mac/#documentation/QuickTime/QTFF/QTFFChap1/qtff1.html#//apple_ref/doc/uid/TP40000939-CH203-BBCGDDDF https://developer.apple.com/library/mac/#documentation/Quick...

asherlangton 14y ago

The wrapper script is GPL'd, so I copied it here: http://dl.dropbox.com/u/15447644/brainplayer_py.txt http://dl.dropbox.com/u/15447644/brainplayer_py.txt My modifications are on lines 553-556. The compiled app "fixes" the .mov file just long enough for it to be loaded into the player. If you have Leaping Brain's player installed (often branded with the content owner's name), the .mov files are in a hidden .media folder. On my Mac, they were in $HOME/Library/Application Support/LeapingBrain/catalog/$VIDEONAME/.media

pav3l 14y ago
Thanks for sharing! Hope you won't get in trouble for your post.
- nacs 14y ago
  Not sure how he could get in any trouble from it due to the license at the very top of the file he linked: "# BrainPlayer is free software: you can redistribute it and/or modify # it under the terms of the GNU General Public License I'm sure Leapfrog hated to put that GPL license on there but were likely forced to due to the VLC components they're using that are GPL/LGPL.
  - alexkus 14y ago
    And, as per https://www.gnu.org/licenses/gpl-faq.html#DRMProhibited https://www.gnu.org/licenses/gpl-faq.html#DRMProhibited the DMCA cannot be applied to this software.

0x0 14y ago

Reusing one-time-pad keys means you can often very easily recover the plaintext simply by XOR'ing the two encrypted files, since it effectively takes the key out of the picture, see for example http://www.cryptosmith.com/archives/70 http://www.cryptosmith.com/archives/70 (where the key is literally taken out of the picture)