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.
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.
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
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".
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!
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.
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.
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.)
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.
I think the distinction is between software and hardware DRM. DirecTV controls the entire hardware chain. This means they can do various proper encryption schemes (public/pre-shared key etc) that are actually near impossible to crack and make it really, really hard to obtain the key by making the key write-only in the crypto-chip.
In a pure software solution, you control the hardware, and any hiding of the key is subject to reverse engineering the software.
There's also a distinction between access to the data stream vs the ability to make a duplicate of it.
For all of the success they've had in protecting DirecTV, if you've got a legitimate access card feeding HDMI data out, you can make a perfect digital copy of the video stream that has no copy protection whatsoever. So ultimately the DRM offers no protection for the media content companies (at least those that don't benefit from live performances like say sports games), though it does for the pipe provider who will surely get his monthly satellite fees.
I agree with your comment, except that "difficult" doesn't necessarily imply "insanely complex".
Counter-example: we once timed a release of a very minor protection update to when the main attacker typically took a holiday. We got 6 weeks out of something trivial, buying more time to work on the major release to greet him when he returned.
It all comes down to economics. Buy a beater bike, and sure, you can secure it well enough. (Mean time between stolen is low enough you don't care too much.) Buy a really nice one that everyone wants, and good luck with that.
Popular, recently produced media has too much value to too many attackers to protect. A celebrity's self shots -- same thing. A game console by Microsoft or Sony -- same thing.
> But it's absolutely possible to make it so insanely complex and difficult that no one will ever break it
A more accurate way to put it: If you make the return on effort ratio low enough, the probability of someone breaking it goes down, and it might even go down enough for you to get away with it for a useful amount of time.
It's not that simple. Sure, unpopular systems are more obscure and less likely to attract attention, but you're wrong in extending that to "if it's popular, it will be broken" (denying the antecedent).
As a counter-example, I propose DirecTV or even their competitor, Dish Network (Nagravision). Hacks of these systems are worth 6 figures, pay TV is widely desired, and there hasn't been a DTV hack since 2004. None.
.pyc files are actually really easy to decompile, it's just that most people have never encountered the tools required to do it. I believe they literally contain the entire abstract syntax tree for the Python source code.
No, they contain marshaled bytecode. I documented the format at http://daeken.com/python-marshal-format a while back (should still be more or less correct).
Python's bytecode is for a stack machine, if I'm not mistaken, and such bytecode is a serialization format for ASTs - a post-order traversal for expressions. Interpret stack machine bytecode symbolically and it reconstructs an AST:
Compilation:
1 + 2 => (+ 1 2) => push 1, push 2, add
Interpretation:
push 1 => 1
push 2 => 2, 1
add => (+ 1 2)
Control flow makes things slightly more complicated, but not for predictable code generation.
Obfuscated bytecode which e.g. doesn't maintain consistent interpreter stack depths for every code path (illegal for JVM or .net CLR) would make things a little harder to analyze, but I doubt that's often the case in practice with Python.
Yeah, the reconstruction isn't hard at all, but it's not a direct 1:1 mapping to the AST, since multiple control flow structures in the AST can become the same thing in bytecode. That said, it's quite simple to make it Good Enough (TM); the reason I wrote that and the RMarshal module was that I was writing a Python decompiler a part of a larger commercial project. I should release the decompiler at some point.
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.
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 (where the key is literally taken out of the picture)
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.
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.