Monday, 18 February 2013

HDCP is dead. Long live HDCP. A peek into the curious world of HDMI copy protection...

I must confess, I'm confused!

HDCP (the copyright protection mechanism in HDMI) is broken. I don't mean just a little bit broken, I mean thoroughly, comprehensively, irredeemably and very publicly broken. Broken in such a way that any possible recovery would mean layering it with so much additional new infrastructure as to render it entirely pointless. Broken. B-R-O-K-E-N.

How can I put this?

It doesn't work.

So why, then, is it still being shoved down my throat?

Why is it that if I go to iTunes to buy or rent a movie, it will tell me that my PC must support HDCP? Why does my home theatre amp need to support HDCP? Why does my HDMI switcher need to support HDCP? Why is anything on Bob's Green Earth being made with HDCP anywhere near it any more???

I'm confused.

Normally, if something is this badly broken, particularly in the security world, at least some effort will be made to replace it with something that actually works. 

Take WEP for example: Broken. Replaced. 

HDCP: Broken. Let's have some more! Come on in, the HDCP's lovely!

I should point out here that I'm not claiming to have anything to do with breaking it. I'm not even going to tell you about some new and interesting way of breaking it that I've discovered (although I will show you how easy it is to exploit the vulnerabilities). 

What I will tell you is what I've learned about it, which, if you're like me and thoroughly confused, you may find interesting and/or useful. I know I found it hard enough to get my head around it, so maybe my little experiments in figuring out what's really going on will help someone, somewhere, to realise the jig is up and switch the damn thing off. Not likely I know, but here's hoping!

Or maybe someone will explain that I've completely misunderstood and actually it's all perfectly OK.

Whatever. For what it's worth, here it is...

So in what way is it broken?

I've previously talked about attacking crypto systems, and the fact that your cryptographic keys are your most precious possession.  It follows, therefore, that the highest priority in the design of a crypto system should be protection of those keys. HDCP not only fails to protect the keys, but by it's very design almost guarantees that not only will the keys be compromised, but that through this one compromise, ALL devices will go with it. Yes, by ALL I mean literally every HDCP capable device on the planet. This is because of the way keys are managed. The way it's done may seem elegant in theory, but as a practical solution it is a catastrophic failure. Way back in 2001 a paper was published explaining why this was the case.

And, yes, of course, the inevitable happened. The master key data, from which all private keys are derived, was compromised.

However, you may argue that even armed with the master key data, the recovery of a specific device's key will still take considerable effort, and will be beyond the capabilities of most potential attackers (this is an argument much favoured by industry, and is often used to discount such attacks). I thought the same, and so my contribution to the debate today is to determine if I can recover an arbitrary device's key, armed only with tools I have lying around the workshop (or can be bought cheaply on the net), using information that can be freely searched on the net, and, most importantly, without damaging the device(s) in question.

So how do we go about figuring out what's really going on under the hood? 

Well, the first thing I did was to build myself an HDMI breakout cable. This turned out not to be as daunting a task as I at first thought. In fact it's pretty simple: 

Get a nice short HDMI cable and cut one end off, or, better still, get a longer one and cut it in half, make two, and give one to your local hackspace! 

I had one that had been stepped on, so I just cut the broken end off (my other half thinks I'm more than a little mental for "hoarding" this kind of crap: "Why the hell would you want to keep that broken cable???", but being able to do stuff like this on the spur of the moment on a rainy Sunday afternoon (did I mention I live in England?) is the lifeblood of the hacker!)

Get one (or two) of these:



The magic search term for this is "HDMI Screw Terminal". Once you know that you'll find loads of them, and you'll wonder why it took you so long to figure that out in the first place. :)

Now you can plug the remaining end of your HDMI cable into the socket, and then buzz through each wire on the cut end to each of the screw terminals. As you find each one, screw it in. This will only take a couple of minutes, and once you've finished, the cable will be entirely looped back on itself, with each pin connected one for one, like this:


You now have a breakout cable. Add some probe wires to any of the lines you're interested in, stick it in the middle of any HDMI connection, and you can monitor it in realtime.

Monitor it with what, though, and what are we looking for?
 
Well, HDMI is not just a video cable. It is also a data cable which can be used to send messages between the devices at each end. The messages can be for various purposes (including transporting the video and audio signals themselves) not least of which is the crypto key exchange for our friend HDCP. It also does things like tell the transmission device such as your PC or TV what the other end's capabilities are - resolution, colour schemes,  manufacturer's name, model, etc. There are also control capabilities, like switching an amp to a different source, or turning volume up and down, powering devices off, etc. Loads going on!

And this is where it starts to get a little tricky to follow. A lot of the standards relating this stuff have been taken from other areas, such as VGA, and so when you start poking around, you find yourself having to figure out which standard applies to what, and what packets belong to who when they're all sharing the same cable. Interesting stuff! 

However, for the purposes of this exercise, the only thing we care about is the HDCP key exchange. This is done over the DDC (Display Data Channel), which is also used for plug-and-play information etc. This is basically an I2C serial bus, living on pins 15 (clock) & 16 (data) with ground on pin 17. I2C is a well known standard and so we can take our pick of tools in order to monitor it. To verify I was getting sensible data, I reached from my trusty USBEE protocol analyser and plugged my breakout cable between the secondary HDMI port on my desktop PC and a little Bush TV. Powering on the TV triggered the data capture:




Good, so we are seeing 'real' I2C traffic. This decodes as the raw data stream: '<START> <A1 Read> <ACK> <00> <NAK>'. If we zoom out a bit we can see this is the start of a much longer conversation...



A little bit of research revealed that this particular bit of data was part of the plug-and-play info in the form of MCCS (Monitor Control Command Set), which is not relevant to this discussion, so I'll say no more other than that if you're interested in digging deeper, these packets can be monitored (and manipulated) purely in software, using tools like softMCCS.

So now we've got access to the raw data, we need to be able to filter what we're looking for and decode it fully. It is possible to write custom decoders for the USBEE, but to be fair, this device falls outside my "cheap" criteria - I only wanted to use it as a quick check that the pins I'm looking at are the correct ones, and that we see the type of data we expect to see. The device I had in mind to do the actual decoding is an off-the-shelf tool that can read, write and sniff I2C: the Bus Pirate. It's extremely cheap as well, so fits the bill perfectly...




Hooking it up and switching to I2C mode, we can do a simple address scan and we should see our TV on A0 and A1:

HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. LCD
x. exit(without change)

(1)>4
Set speed:
 1. ~5KHz
 2. ~50KHz
 3. ~100KHz
 4. ~400KHz

(1)>3
Ready
I2C>(0)
 0.Macro menu
 1.7bit address search
 2.I2C sniffer
I2C>(1)
Searching I2C address space. Found devices at:
0xA0(0x50 W) 0xA1(0x50 R)


Nice! So let's see what we get if we run the built-in I2C sniffer macro and power on the TV:

I2C>(2)
Sniffer
Any key to exit
[0xA0+0x00+[0xA1+0x00+0xFF+0xFF+0xFF+0xFF+0xFF+0xFF+0x00+0x0E+0xD4+0x4C+0x54+

0x01+0x00+0x00+0x00+0x14+0x10+0x01+0x03+0x80+0x47+0x28+0x78+0x0A+
0x0D+0xC9+0xA0+0x57+0x47+0x98+0x27+0x12+0x48+0x4C+0x20+0x00+0x00+
0x01+0x01+0x01+0x01+0x01+0x01+0x01+0x01+0x01+0x01+0x01+0x01+0x01+
0x01+0x01+0x01+0x01+0x1D+0x80+0xD0+0x72+0x1C+0x16+0x20+0x10+0x2C+
0x25+0x80+0xC4+0x8E+0x21+0x00+0x00+0x9E+0x01+0x1D+0x00+0xBC+0x52+
0xD0+0x1E+0x20+0xB8+0x28+0x55+0x40+0xC4+0x8E+0x21+0x00+0x00+0x1E+
0x00+0x00+0x00+0xFC+0x00+0x48+0x44+0x4D+0x49+0x20+0x54+0x56+0x0A+
0x20+0x20+0x20+0x20+0x20+0x00+0x00+0x00+0xFD+0x00+0x1E+0x3D+0x0F+
0x44+0x0B+0x00+0x0A+0x20+0x20+0x20+0x20+0x20+0x20+0x01+0xCA-][0x6E-][0x6E-][0x6E-]

Again, very nice! I was expecting to have to do some fiddling around, but this just worked first time. Good job, Bus Pirateers! :)

Right, so we've established that we can use the Bus Pirate to sniff the traffic, but what about those pesky HDCP crypto keys?

First job is to read the HDCP specification, which will make your head hurt. A lot. However, since I've now done it, you don't have to. You're welcome. :P

We obviously don't want to do this in a serial terminal window, so I wrote a little python wrapper to drive the Bus Pirate and interpret the results:

 $ hdmi-sniff.py /dev/ttyUSB0

  Connecting...
  Detected Bus Pirate
  Switching to I2C mode
  Sniffing...


    Address: A1 (DDC2B Monitor (memory)) (read)
      Payload:
    Address: A1 (DDC2B Monitor (memory)) (read)
      Payload:
    Address: A1 (DDC2B Monitor (memory)) (read)
      Payload: 

    Address: A0 (DDC2B Monitor (memory)) (write)
      EDID: 00FFFFFFFFFFFF000ED44C540100000014100103804728780A0DC

9A05747982712484C20000001010101010101010101010101010101011D80D072
1C1620102C2580C48E2100009E011D00BC52D01E20B8285540C48E2100001E000
000FC0048444D492054560A2020202020000000FD001E3D0F440B000A20202020
202001CA
 
OK, that looks pretty good. We've intercepted the EDID (Extended Display Identification Data), and checking this against the softMCCS output, I can see that we're getting exactly what was transmitted, so everything seems to be working. Now let's see what happens when we generate an HDCP packet.


Basically, what we should see is packets being sent to either the "Primary Link HDCP Port" (74) or the "Secondary Link HDCP Port" (76), and what the standard refers to as an "offset" address tells you what type of packet it is. We are looking for Aksv (HDCP Transmitter KSV) or Bksv (HDCP Receiver KSV). "KSV" stands for "Key Selection Vector", and is the magic number that allows the devices to calculate a common shared key. If we can sniff those, and we have the master key material, then we can calculate the corresponding private keys. Job done.

However, playing a copy-protected DVD onto the TV display did this:

 $ hdmi-sniff.py /dev/ttyUSB0

  Connecting...
  Detected Bus Pirate
  Switching to I2C mode
  Sniffing...


    Address: 74 (Primary Link HDCP Port) (write)
      Offset: Bksv (HDCP Receiver KSV)
        00000075A6 (INVALID)
    Address: 74 (Primary Link HDCP Port) (write)
      Offset: Bksv (HDCP Receiver KSV)
        00000075A6 (INVALID)
    Address: 74 (Primary Link HDCP Port) (write)
      Offset: Bksv (HDCP Receiver KSV)
        00000075A6 (INVALID)


So we're seeing the expected packets, but they don't decode correctly (according to the spec, we can tell if it's a valid KSV as it should be 40 bits long and have exactly 20 '0' bits, and 20 '1' bits). Just to be sure it wasn't my code getting it wrong, I viewed it back in the terminal:

I2C>(2)
Sniffer
Any key to exit
[0x74+0x00-0x75+0xA6+]][0x74+0x80-0x75+]][0x76+0x00-0x77+0xA6+]][0x74+0x00-0x75+0xA6+]][0x74+0x80-0x75+]][0x76+0x00-0x77+0xA6+]


Rats! We're losing significant amounts of data. We should be seeing 7 byte packets: 0x74 + 0x00 + 5 bytes of KSV. I guess this type of data is transmitted faster than the Bus Pirate can cope with (their notes say it's only expected to work up to ~100kHz, and the HDCP spec says we may be going at either 100kHz or 400kHz). Back to the drawing board! :(

I was hoping to use something entirely off the shelf, but at Aperture Labs we often come across situations like this, where the tool either doesn't exist, is too expensive, or simply doesn't have the appropriate capabilities.  Accordingly, we've developed an in-house device  (inspired by the Bus Pirate!), called GPHHT (pronounced "gift"), which stands for General Purpose Hardware Hacking Tool. It works very similarly to the Bus Pirate, in that it allows me to talk to it over USB, connect anything I want to play with and it will interpret arbitrary data lines in any way I like, but it is much faster, running at 60MHz, and has loads of memory so the firmware can be easily extended to support just about anything. It runs on an off the shelf microprocessor development platform, so is also very cheap and easy to get hold of.

GPHHT doesn't currently do I2C, so the first stage was to write the sniffer module. As it's an open standard this was pretty trivial, and I used the same output notation as the Bus Pirate so I wouldn't need to change my wrapper script:

gphht Bin> hex
gphht Hex> raw
gphht RAW Hex> i2c
I2C RAW Hex> readl

[0x74+0x40+[0x75+0x9C-]
[0x77+0x53+0x58+0x8A+0xF8+0xB6-]
[0x74+0x00+[0x75+0x53+0x58+0x8A+0xF8+0xB6-]
[0x76+0x00+[0x77+0x53+0x58+0x8A+0xF8+0xB6-]
[0x74+0x00+[0x75+0x53+0x58+0x8A+0xF8+0xB6-]
[0x76+0x00+[0x77+0x53+0x58+0x8A+0xF8+0xB6-]
[0x74+0x00+[0x75+0x53+0x58+0x8A+0xF8+0xB6-]
[0x76+0x00+[0x77+0x53+0x58+0x8A+0xF8+0xB6-]
[0x74+0x10+0xB7+0x25+0xC4+0xF2+0x2A+]
[0x74+0x08+[0x75+0x2B+0x84-]
[0x74+0x08+[0x75+0x2B+0x84-]
[0x74+0x08+[0x75+0x2B+0x84-]
[0x74+0x08+[0x75+0x88+0xF0-]
[0x74+0x08+[0x75+0x88+0xF0-]
[0x74+0x08+[0x75+0x88+0xF0-]
[0x74+0x08+[0x75+0xD5+0xF7-]
[0x74+0x08+[0x75+0xD5+0xF7-]


That looks better - now our 0x74+0x00+ and 0x76+0x00+ packets are followed by 0x75 / 0x77 and the expected 5 bytes of KSV. 

Interestingly, now we can see what's really going on, the second chunk includes another 'START'  (shown as '[' below) :  

[0x74+0x00+[0x75+0x53+0x58+0x8A+0xF8+0xB6-]

This is known as a 'RESTART', and changes the direction of the I2C bus. I suspected, therefore, that the problem with the Bus Pirate was not speed at all, but mis-handling of a RESTART, as in our earlier capture it's flagging it as a 'NAK' instead of a 'START' (shown as '-'): 

[0x74+0x00-0x75+0xA6+]

Looking at the Bus Pirate source code, I could see a lot of changes had been made since my last update, so I flashed it with the latest firmware (6.2-beta-1), and happy, happy, joy, joy:

I2C>(2)                                                                    
Sniffer                               
Any key to exit                         

[0x76+0x00+[0x77+0x53+0x58+0x8A+0xF8+0xB6-]
[0x74+0x00+[0x75+0x53+0x58+0x8A+0xF8+0xB6-]
 
We are now seeing the RESTARTs, and when we run the script we get:

$ ./hdmi-sniff.py /dev/ttyUSB0

  Detected Bus Pirate
  Switching to I2C mode
  Sniffing...


    Address: 74 (Primary Link HDCP Port) (write)
      Offset: Bksv (HDCP Receiver KSV)
          KSV: 53588AF8B6

    Address: 76 (Secondary Link HDCP Port) (write)
      Offset: Bksv (HDCP Receiver KSV)
          KSV: 53588AF8B6

    Address: 74 (Primary Link HDCP Port) (write)
      Offset: Aksv (HDCP Transmitter KSV)
          KSV: B725C4F22A

    Address: 74 (Primary Link HDCP Port) (write)
      Offset: Ri' (Link verification response)
        RI: F84F

    Address: 74 (Primary Link HDCP Port) (write)
      Offset: Ri' (Link verification response)
        RI: F84F

    Address: 74 (Primary Link HDCP Port) (write)
      Offset: Ri' (Link verification response)
        RI: F84F

    Address: 74 (Primary Link HDCP Port) (write)
      Offset: Ri' (Link verification response)
        RI: F84F

 
    Address: 74 (Primary Link HDCP Port) (write)
      Offset: Ri' (Link verification response)
        RI: C31D

    Address: 74 (Primary Link HDCP Port) (write)
      Offset: Ri' (Link verification response)
        RI: C31D


etc. It now sits there sending a new Ri' every couple of seconds, which is the link integrity check being rolled as per the spec.


Great, so now what? We've got the KSV for both receiver and transmitter, so in theory we can generate the private keys. Although this is technically not difficult - all we are doing is selecting elements of the master key array based on the KSV and performing some very minor mathematics on them - I am not a great fan of re-inventing the wheel (yes, lazy), so I had a quick look to see if someone's already done it for me. Of course they have: Rich Wareham has helpfully provided hdcp-genkey. We can take the KSV output from above and feed it to his program and we get:

$ ./generate_key.py  -k --ksv=53588af8b6
KSV: 53588af8b6

Sink Key:
07fbf213e9ca75 c9964fc6e8e7f8 6484e809582eea b8f03477efb166 245150b693dda3
3f1447c4080ed7 46ac3de434d1fc 6c5251d4f26e20 b44a36970c3832 cc4f5af96cbd75
0651c2db48cf59 4ed0f06fcd927a a33b970e3d0abc ffc3e1a9980eb0 5920bb4240ed76
24025e0ebc35ec cf99b68b95cfd7 23616535d292ad 471e2e8d7512e8 1ea828fc50f651
d6b5483e171157 8e57f9df3ca465 1dc20f8fe4394f 4730f09cb7372f 9f93706e572503
38c9ed91e6ed19 4a05391a803786 eea18880318af5 f8ca423dda9f73 6b0c8506c5bd8a
1f460918ccc29b d446972e83a614 585d1ff636cad4 fb0a9dc56c3681 497a8886d3f49a
8f15fec96a69fd 9dce6d17d77068 b600fecd2da322 d87bd0cda9739e e2ce65bc3f3a09


Or better still, call his code from my script and get it automatically:


 $ ./hdmi-sniff.py /dev/ttyUSB0 

  Detected Bus Pirate
  Switching to I2C mode
  Sniffing...


    Address: 74 (Primary Link HDCP Port) (write)
      Offset: Bksv (HDCP Receiver KSV)
          KSV: 53588AF8B6

Sink Key:
07fbf213e9ca75 c9964fc6e8e7f8 6484e809582eea b8f03477efb166 245150b693dda3
3f1447c4080ed7 46ac3de434d1fc 6c5251d4f26e20 b44a36970c3832 cc4f5af96cbd75
0651c2db48cf59 4ed0f06fcd927a a33b970e3d0abc ffc3e1a9980eb0 5920bb4240ed76
24025e0ebc35ec cf99b68b95cfd7 23616535d292ad 471e2e8d7512e8 1ea828fc50f651
d6b5483e171157 8e57f9df3ca465 1dc20f8fe4394f 4730f09cb7372f 9f93706e572503
38c9ed91e6ed19 4a05391a803786 eea18880318af5 f8ca423dda9f73 6b0c8506c5bd8a
1f460918ccc29b d446972e83a614 585d1ff636cad4 fb0a9dc56c3681 497a8886d3f49a
8f15fec96a69fd 9dce6d17d77068 b600fecd2da322 d87bd0cda9739e e2ce65bc3f3a09


    Address: 74 (Primary Link HDCP Port) (write)
      Offset: An (Session random number)
        Payload: 7B86869FA8EEEBCE


    Address: 74 (Primary Link HDCP Port) (write)
      Offset: Aksv (HDCP Transmitter KSV)
          KSV: B725C4F22A

 
Source Key:
92af82fbb07fff a2632f3ddbeb4e 56a24325e28ec9 292df9fb3946ed 99c8ffaf619607
928cd5d0a01253 58b273ab09aab3 5bea73fddbe139 474059feea93f2 f5d34950a91d63
1c8087bfceab0a 9fd711c734bb8d 635d7cb7141fb0 b0f89e8ddad43f 754a4464d33b6b
f11aa1eb87b8e3 bc58a1dc908520 86206c2dda2a83 9066cfbb3cf870 068d6b9725939c
80ba2f0d915c50 e9f9c6f60f7820 e3e8cde8fd7418 e5f1f1970c19c5 f921dc6f751380
8869f1505a2557 b54ac17e0a91f0 e31486ff6730ed 84503b00fef20d afb76def4694f4
29aa9778cbbba5 e5c07e0cb49c84 8f14d5c80e71c8 2ad8660de0bd09 79c7ebbf7d8a70
b7952a1ae14ff5 afc7f5822a001d a60199bde07143 79070ac716f68e 88534d26956da1

    Address: 74 (Primary Link HDCP Port) (write)
      Offset: Ri' (Link verification response)
        RI: AD66

    Address: 74 (Primary Link HDCP Port) (write)
      Offset: Ri' (Link verification response)
        RI: AD66

    Address: 74 (Primary Link HDCP Port) (write)
      Offset: Ri' (Link verification response)
        RI: AD66

 
What was that? Oh, yes: job done! :)


So why is this important?

Well, quite simply, it renders not only the encryption utterly pointless, as armed with the keys anyone can decrypt the traffic, but also the entire defence mechanism for the protocol. The system relies on the uniqueness of each device key, and incorporates a mechanism for issuing key revocation lists. The idea being that if someone were to manufacture and distribute an HDCP stripper (i.e. a device that accepts encrypted input but then outputs plaintext), its own unique key can be revoked by the powers that be simply by publishing its KSV on the revocation list (which is distributed on every new piece of media, such as DVD, Bluray etc.). However, since the master key material is now "out there", any such device need not have a static key. It can make them up on the fly, or simply imitate one of the ones in the 'real' device chain.

Like I said: broken. 

BTW, hdmi-sniff can be found on the Aperture Labs tools page.

51 comments:

  1. Great article, but I feel as if you are missing the general idea behind the entertainment industry's continued use of the HDCP protocol. HDCP, although broken, cannot and will not be defeated by the general public. They have no clue as to what encryption keys are and how they work. HDCP is like a padlock that you put on a shed. It provides minimal security as any mischievousness person with a set of bolt cutters can get in, but it keeps the honest man and the general public out of the shed. At this point HDCP compliant devices are too far spread to try pushing a new standard. This could potentially break a very large number of devices, so instead of providing no encryption the industry is still sticking with what little security is afforded to them by the HDCP protocol.

    ReplyDelete
    Replies
    1. The problem is that we are talking digital content here. Locks work because if I want to steal something from a shed, I need to go and break the lock myself.

      Digital content just requires one person to break the lock, and then share out copies of the unlocked content.

      Whilst it might provide a modicum of security, it's very scant. The issue is really that the industry don't seem to have learnt from this - if the HDCP system had been adequately reviewed and tested before it was deployed, we wouldn't be here.

      Delete
    2. I think the nub of the matter is this: How much license money is collected for the HDCP IP?

      Who cares if HDCP does not "work as advertised" as long as it works as *intended*? HDCP is a private tax on every, single, digital device in the market!

      Delete
  2. I noticed you were using the Bus Pirate v3, wouldn't the Bus Pirate v4 work (still in development, but obtainable), as i thought the BPv4 1MHz (logic analyzer)

    ReplyDelete
  3. It might keep the general public out, but it won't keep pirates out. HDCP is theoretically intended to ensure that people can't capture HD content in pristine digital form, but now it's trivial for anyone with the technical skill and a few bucks to do so, and in the end, the general public doesn't need to decrypt HDCP; they just need to be able to download the fruits of others' labour.

    ReplyDelete
  4. The cryptology doesn’t have to be any good to invoke the DMCA...

    ReplyDelete
  5. As a 'general public' type of person without the necessary skills, I hope someone makes a generic usb powered box that can be inserted in the hdmi chain to do the decode for me. To avoid infringing it could be simply a hdmi cable extender in essence until flashed with suitable software. It would be up to user download necessary break code from other internet sources and flash the device. Any takers?

    ReplyDelete
  6. The significant thing is this: “if someone were to manufacture and distribute an HDCP stripper (i.e. a device that accepts encrypted input but then outputs plaintext), its own unique key can be revoked [...] However, since the master key material is now "out there", any such device need not have a static key. It can make them up on the fly, or simply imitate one of the ones in the 'real' device chain.”

    It's true that the general public is not going to be sniffing HDCP keys. And in fact pirates weren't deterred by HDCP even before it was known to be compromised. But the general public can now buy an HDCP stripper on eBay, if someone is willing to make one. If only there were a country in the world with cheap electronics manufacturing facilities and a loose attitude to intellectual property law...

    ReplyDelete
  7. Fantastic read, great work.

    ReplyDelete
  8. HDCP has always been about making it more convenient for the consumed to re-pay for content than to convert to whatever the preferred viewing mode is. Nobody ever believed it would actually prevent real piracy.
    But, meanwhile, it's prolonged an existing business model for several years, generating good bonus checks for those involved.

    ReplyDelete
  9. Hello Adam, very interesting walkthrough. It was enlightening to me, I always found hardware hacking to be too laborious. Better stick to software and theory then, I guess.

    I will echo once again what others have said: WEP as well as HDCP keeps most people out and that is all they can really hope for.

    The cat is staring at me so I must be going now.

    ReplyDelete
  10. I think Intel's current solution is that if you were to mass market such a device, they'd sue you. A lot.

    ReplyDelete
  11. Perhaps the industry's "fix" for HDCP is Cinavia audio watermarking system?

    http://en.wikipedia.org/wiki/Cinavia


    ReplyDelete
  12. The standard was broken before it was ever ratified. Pretty common knowledge for everyone in the industry. But that’s not the point. This blog post being made 12 years after it was broken is the point. And no one really cares about HDCP when AACS has also been broken for years. It about slowing people down. They can never be stopped.

    Even if you have the keys, you still need a history of the entire transmission as it’s an adaptive symmetric session algorithm and you have to decipher a very high bit rate TMDS stream to get the base-band content.

    ReplyDelete
  13. They still keep it because 1, "They" paid for the licence so might as well use it, and 2, to help prevent "casual copying."

    ReplyDelete
  14. the general public can now buy an HDCP stripper on eBay, if someone is willing to make one.
    http://www.hqew.net

    ReplyDelete
    Replies
    1. Is that some sort of exotic dancer with a g-string? Oh, wait, you said HDCP, not HDMI.. nevermind.


      Lets see how long it takes some people to get that joke.

      Delete
  15. No security mechanism is totally secure, I agree with dammitdave, WEP was broken well before WPA was introduced and there is still a legacy. HDCP only needs to make it illegal to crack, it doesn't need to make it particularly difficult. People don't commercially break DVD security because that would put them at commercial risk, making hardware that circumvents HDCP puts you out on a limb and that is sufficient to keep it from becoming mainstream.

    ReplyDelete
  16. Pah... forget the technical stuff. Props for the Ren & Stimpy reference ;-)

    ReplyDelete
  17. I2C supports clock stretching, so you might be able to configure the Bus Pirate in such a way that it slows down the I2C stream...

    ReplyDelete
    Replies
    1. Unfortunately would the underlying source device be able to deal with the bottleneck? If it only has a small margin of overhead (to deal with the occasional transmit error or system lag), its internal buffers may fill up and confuse the firmware (or maybe even crash the device). Given the high probability of the data rate being reliable under normal conditions, I find it unlikely manufactures would bother to test such a situation. I know normal software often is never tested for "known" external caused failures (as they are sometimes more difficult to simulate).

      Delete
  18. Not many remember that once Microsoft Excel was disccopy protected (5"1/4 1.2MB Floppy disk version). Unprotecting it was matter of 30 minutes using onthefly Debug from DOS. That to say that most companies don't have a clue of what making a good protection scheme means.
    Although I believe that fighting piratery isn't something you should do with this kind of protection

    ReplyDelete
  19. Great hacking job...and funny how broken it is :-)

    ReplyDelete
  20. "So why, then, is it still being shoved down my throat?"

    Because the industry want to make everyone believe they can control their content. This has _never_ been true, ever.. since worse case scenario one could always point a hi-res camera at their HD monitor, line it up, block out glare and such and start recording. Sure.. it may not be "as-good" as the pure stream, but 95% HD (in digitally replicable form) would still be far better than standard def. And this assumes people _care_ about the quality that much. This certainly isn't true for bootlegged movies in theaters.. I've [allegedly!!] seen a bootleg movie and it was HOOORRRRRRIIIBLE quality (camcorded in some movie theater I guess).. poor lighting, poor audio.. poor everything. It basically half ruins the movie, almost forcing you to watch the legit thing anyway. And the fact there was enough demand for that crap bootleg to be worth making just shows that even a ding/disaster in quality won't stop anything.. artificial copy-protection only serves to piss off real [paying] customers.

    Actually.. for a while I think the bandwidth issue is the main thing that slowed it down. Even if you decrypted the raw HDMI stream, what were you going to do with it? Unless you had a custom hi-res real-time hardware compressor, or a huge, fast hard drive ["That's what _she_ said!" =)] to store it. Now a days there's both of those, so not as much a limiter anymore.


    "HDCP, although broken, cannot and will not be defeated by the general public."

    This is probably what some once said about DVD's.. then came along a person that wanted to play _legally_bought_ DVD's, but not want to play them only on platforms the industry deemed worthy.. thus DeCCS (or DeCSS? hmm.. anyway..) came to being. And soon it (or its derivatives) where available to the general public without too much effort.


    ... [so I just cut the broken end off (my other half thinks I'm more than a little mental for "hoarding" this kind of crap: "Why the hell would you want to keep that broken cable???",] ...

    I do the same thing. ;) Only mine are usually old broken mice and keyboards that "Maybe I'll use its connector/cable for something one day!" In my case, I'm still waiting to use them. :\

    ReplyDelete
  21. Another great (and somewhat cheap) USB logic analyzer is: http://www.saleae.com/logic/

    ReplyDelete
  22. Nice, thanks.

    Now please read up on the difference beteen "its" and "it's". :-P

    ReplyDelete
    Replies
    1. Argh. Yes, I know the difference... 'twas a typo (or two), honest! :) Thanks.

      Delete
  23. Excellent write-up, good to see it all put together again the way you did, even if it's all old news...
    Hopefully it'll sink into the heads of the "powers that be", then again, do we really want them to come up with something unbreakable or far more formidable?

    ReplyDelete
  24. it's trivial for anyone with the technical skill and a few bucks to do so. http://www.hqew.net

    ReplyDelete
  25. It is now (& for sometime), but only thanks to work done previously by others.

    ReplyDelete
  26. Hi Adam. Great post!

    Can you confirm which exact rev number of BP firmware you used for successful I2C sniffing?

    I am replicating your BP setup to analyse my own HDMI/HDCP comms (at low cost). However, I seem to be having problems with the BP's I2C Sniffer macro munging the data. I've checked my DDC lines (with Open Logic Sniffer on my BP v3a) and can clearly see that it's clocking at up to 100kHz. I've tried BP firmware v5.10 (r559), v6.1 (r1676), and v6.2-beta1 (r1981).

    I want to try and get to your BP "happy, happy, joy, joy" mental state before putting my hand in my pocket for a faster I2C sniffer... :-)

    Thanks!

    ReplyDelete
  27. This was the image I used:

    http://code.google.com/p/dangerous-prototypes-open-hardware/downloads/detail?name=BusPirate.package.v6.2-beta1.zip

    ReplyDelete
    Replies
    1. Thanks Adam! I've tried that image v6.2-beta1 (r1981) with no success. However, I think I may have spotted something...

      ...your USBEE traces seem to imply that your DDC was clocking at around 20kHz (screenshots show 50us per div and ~1 cycle per div). Could it be the case that your test devices were clock stretching or something, and running the I2C bus at a lower frequency? Or have I misread your screenshots?

      My clock is definitely running at 10us per cycle (100 kHz) - i.e. I see around 4-5 cycles per 50us period. Which I am now thinking is may well be too fast for the BP I2C Sniffer.

      Thanks again for the quick response!

      Delete
  28. I'm afraid I no longer have either of the devices I was testing so can't shed any further light other than the screenshots, sorry.

    However, if you simply need a bit more power than the standard bus pirate, I can recommend the USB 32-Bit Whacker:

    https://www.sparkfun.com/products/9713

    gphht runs on this now instead of the original dev board we used to use and I hope to release it soon (I just need to take some proprietary stuff out first)...

    ReplyDelete
  29. Great - thanks again Adam!

    UBW32 looks very interesting (thanks for the pointer). I also came across the Open Bench Logic Sniffer FPGA hardware (Dangerous Prototypes and Gadget Factory).

    Also thinking of using an Arduino with data logger shield, in case I want to leave an I2C/DDC logger running unattended for a few days. One of my HDCP issues is intermittent.

    Anyway, thanks again for the original post and inspiration.

    ReplyDelete
  30. HDMI, DisplayPort and DVI are all digital standards used for High Definition video signals. DVI & DisplayPort (V1) solely carry the video-image signal but no audio, where as HDMI covers each. Therefore if you employ a DVI or DisplayPort (V1) cable, you'll need to connect audio cables from your DVD-player, CPU, games console or cable/satellite receiver to your TV.

    ReplyDelete
  31. Did anyone try to make the code work on a Raspberry Pi ? It has a i2c bus working at 400khz. The scripts could run on the device itself.

    ReplyDelete
  32. Okay, clearly I am a novice here: Once you have your decryption key, what can you do with it? Can I hook the HDMI cable to it and save some video? How would I do that?

    Or must it be a hardware dongle? If so, how does one go about implemeting it in hardware? Most of the stuff you mention can be done on a microprocessor. Can an Arduino decrypt it?

    ReplyDelete
    Replies
    1. Arduino will not work because of the hardware limitation but you can integrate it in a Ras Pi on the hdmi to be hdcp compl. But you don`t even need the pi if you have the master key. You simply generate your own key or replicate one Adam used.

      Delete
  33. I would like to be able to re program the roku III , so this HDCP error goes away. It blocks all content , not just HDMI . some one cut the head off the snake at that end plz . and I have no need to record content I am 61, not enuff time left to watch the content avail for free.

    ReplyDelete
  34. totally agree... so much stuff on youtube and the like. Like i need to get a bootleg copy. Why. The content on Netflix and other services is pretty cheap. My plasma screen doesn't support the HDCP protocol. Pioneer PDP-433 CMX and i don't want to spend $3k to watch TV. The receiver i have also doesn't have HDMI or HDCP. Works fine without it... why does the content side put you under house arrest, simply because a few people might watch a movie. If i had that sort of time and attention- i could install a bit torrent or go to a pirate site...

    ReplyDelete
  35. Fast Services – We make sure that our IT services are always in time ensuring the smoothness of your business process.
    visit:VoIP Provider

    ReplyDelete
  36. This comment has been removed by the author.

    ReplyDelete
  37. Thank you! I came to your blog simply because i searched if someone had ever used the ATMEL 4bit microcontrollers and found a lot of very interesting article about device security :)

    ReplyDelete