[revelation]

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]

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]

Can't work ever? Are you taking orders for hacked DirecTV cards? :)

[daeken]

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.

[mseebach2]

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.

[georgemcbay]

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.

[NateLawson]

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.

[stcredzero]

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.

[NateLawson]

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.

[stcredzero]

> you're wrong in extending that to "if it's popular, it will be broken" (denying the antecedent).

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.