Slashdot Mirror


Murdoch's Hacker Speaks Out

This article from a Swiss newspaper recounts the appearance of Christopher Tarnovsky at the European Black Hat conference (link is to a Google translation of the French original). Next month Tarnovsky will testify in a lawsuit brought by a maker of satellite TV encryption systems (Kudeslki) against an Israeli company (NDS), for whom Tarnovsky worked until recently. (NDS is owned by Rupert Murdoch's News Corp.) While with NDS, Tarnovsky cracked Kudeslki's crypto, but claims he didn't post the result on the open Net. His responses to audience questions are amusing, in particular when someone from Microsoft asks him about breaking the Xbox 360 console. Tarnovsky replies (in the translation): "I have been offered 100,000 dollars for the break, but I replied that it was not enough."

2 of 86 comments (clear)

  1. It's OK because everyone else does it? by NotQuiteInsane · · Score: 3, Interesting

    In his view, the lawsuit against NDS is an attempt to racketeering. "Of course I broke cards Kudelski, he begins annoyed. I was paid by NDS to do so. It's an activity that leads all companies in the sector. But why would I published these codes for free on the Net? I am not stupid, and I never had the intention to take that risk."

    Interesting.. so AIUI all the CA (conditional access) vendors routinely break each others' systems. That's not surprising in itself (I'll admit to having learned a fair bit from reverse engineering other peoples' code). It does seem a tad unethical though, especially the alleged release of the code. I wonder if the code release was a decision made by upper management at NDS / News Corp (and it wouldn't surprise me in the least if that turned out to be the case). From the outside, this looks a lot like a protection racket... "Buy our system, because it would be an awful shame if your revenue stream were to be... terminated"

  2. Re:Sky TV uses Linux by demallien2 · · Score: 5, Interesting

    Yes, yes they have. Not by you though, apparently.

    Jiminicus, my job is to crack decoders. Well, at least half the time. The other half is spent designing systems to make the cracker's life difficult, by blocking the attacks that I have used myself.

    For example, with your scheme, I would reverse engineer the official decoder, and then patch the code that checks the return code, so that the check always returns TRUE. Now, that can be defeated by making it so that the value returned by the server is actually a key. My next attack would then be to try and convince the server that I am a real official decoder, and that it should give me the key. Unless care is taken, I could probably get the necessary information for this by launching a man-in-the-middle attack on an official decoder.

    The typical defence against this attack is to protect the link by using certificates signed by the encryption provider, and linked to the decoder's serial number. As a pirate, I then just extract the official certificate either from the decoder itself, or from the conversation of a real box. I can then clone the certificate/identity of the decoder, and the server will talk to me as though I'm a real decoder.

    The response to that attack is to verify that there are not two decoders connected at the same time that use the same identity. But this is not as simple as it sounds. For performance reasons, servers are distributed to handle different 'parks' of decoders. But I have to maintain a synchronized list of currently logged in decoder identities across all servers. This is a definately non-trivial task, or at least that's what my collegues that work on the head-end code tell me.

    Other options for a cracker include trying to find a way to compromise the head-end server, and then poke around on it to dig up signing certificates and other good stuff to circumvent the protection. Or he might launch a denial of service attack - most server solutions have a 'degraded' fall back mode where the TV signal is encrypted with a key kept locally in the decoder, to be used if the key servers fail for whatever reason. That key can of course be extracted by the traditional means.

    Believe me, many, many, many people have tried to come up with solutions to this problem. The server approach that I have just outlined is the most secure that we have found to date, but as I have also described, it has problems too. Not to mention that it is expensive/complicated to implement.