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
"# 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.
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:
> 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.
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.
Literally the only thing that goes missing from .py to .pyc is comments.
(Not that any DRM scheme can ever work, ever, but hey. At least some try to try.)
In a pure software solution, you control the hardware, and any hiding of the key is subject to reverse engineering the software.
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.
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.
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.
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.
Putting words in my mouth there. If it's popular, the probability it will be broken goes up.
> there hasn't been a DTV hack since 2004. None.
You're preaching to the choir here. Still, that's one tidbit I didn't already know. The old mainframe Mantis language is another example.
Compilation:
1 + 2 => (+ 1 2) => push 1, push 2, add
push 1 => 1
push 2 => 2, 1
add => (+ 1 2)
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.
[1] https://developer.apple.com/library/mac/#documentation/Quick...
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.