The software implementation should be able to decrypt a 1080p30 stream given a suitably fast dual-core processor and about 1.6GB of RAM. The poor performance is due to the nature of the algorithm. HDCP was designed to be cheap and fast for hardware manufacturers, but operations that are quick and easy in hardware are often slow and inefficient in software. In spite of this, the developers believe they have opportunities for further optimization and improvement, making real-time decryption on more modest hardware feasible.

The purpose of their efforts is less than obvious. HDCP is used for the protection of content over the links between systems—for example, the cable between your video card and your monitor—to prevent the creation of perfect digital copies. An HDCP source—typically a video card or Blu-ray set-top box—will only transmit data if it can establish an HDCP-protected connection to a sink—a monitor or TV.

As such, to capture an HDCP-protected data stream, the capture device needs to appear to be a legitimate sink. This means that the capture device needs to be physically connected to the source (usually over an HDMI, DVI, or DisplayPort cable), and needs to be able to perform the right HDCP handshaking before the source will even begin playback. So to even get an HDCP-protected stream to use the software with, you need hardware that's able to "speak" HDCP to capture the data—and if you have that, the hardware will be decrypting the stream anyway.

The leak of the master key does allow anyone to create their own sources and sinks, in a manner that cannot be blocked or disabled, so it might yet be used to produce general-purpose HDCP strippers to allow, for example, capture of copy-protected cable programs. This software implementation, though, looks more like a novelty to prove that the keys are real than a practical anti-HDCP solution.

50 Reader Comments

I don't understand why you couldn't do the HDCP handshaking in software also, if you had an HDMI adapter and driver that didn't include the underlying HDCP algorithm, but that was sufficiently addressable via the driver. That would seem to me to be an easier problem to solve than making your own ASIC to do HDCP from top to bottom in hardware using the stolen keys.

This kind of decryption can be done on the GPU. Just wait for CUDA implementation. Decrypting HDCP content will be a breeze than. Now, how to get the HDCP content? Either we find a HDMI-In card that can be hacked to let include the handshake, OR you design some hardware that can do the handshake, than copy the stream into RAM or directly into the GPU memory over the PCI-E bus.

This kind of decryption can be done on the GPU. Just wait for CUDA implementation. Decrypting HDCP content will be a breeze than. Now, how to get the HDCP content? Either we find a HDMI-In card that can be hacked to let include the handshake, OR you design some hardware that can do the handshake, than copy the stream into RAM or directly into the GPU memory over the PCI-E bus.

Don't think HDCP crack is futile, it will happen sooner or later.

If you're going to design hardware to do the handshake, you might as well design hardware to do the full decrypt. It's designed to be possible in just a few thousand transistors.

There are a few HDMI In cards, but they don't support HDCP, and it's not clear that they can be readily made to support HDCP.

It would be nice if someone could figure out a way to get Apple displays to accept HDMI, since they've never supported HDCP.

This is probably one application where the crack would be useful. Someone could create an adapter that you plug in between your HDMI out and the Apple display, stripping the HDCP from the stream in the process.

So the people cheering about the cracking of HDCP seem to really have been cheering for nothing.

High processing requirements and hardware that can already decrypt it anyways.

Has HDCP really been cracked at all lol?

The underlying software has not been optimized. An assembly/SSE guru might be able to get more out of the algorithm. Combined with yet another performance leap early next year in CPUs, it's not something that is outrageous.

I don't understand why you couldn't do the HDCP handshaking in hardware also, if you had an HDMI adapter and driver that didn't include the underlying HDCP algorithm, but that was sufficiently addressable via the driver. That would seem to me to be an easier problem to solve than making your own ASIC to do HDCP from top to bottom in hardware using the stolen keys.

My thought as well (I assume you meant "handshaking in software") - surely with full access, someone will be able to figure out a way to spoof the handshake over existing HDMI connections? Then a quick software extension to XBMC or another media center and we would be able to DVR full quality streams. But perhaps the performace issue is really the critical roadblock - (along with file sizes perhaps - how big are these streams?).

You want a GPU based graphics card with an HDMI input. I don't know of one, all of the cards have HDMI outputs. But some bright company may build one now. A GPU is plenty fast enough to undo the HDCP and recompress the signal in real-time.

Another strategy is to use a FPGA card with an HDMI input. The cards could be sold unprogrammed without problem. The user would then be free to install any software they choose.

As such, to capture an HDCP-protected data stream, the capture device needs to appear to be a legitimate sink. This means that the capture device needs to be physically connected to the source (usually over an HDMI, DVI, or DisplayPort cable), and needs to be able to perform the right HDCP handshaking before the source will even begin playback. So to even get an HDCP-protected stream to use the software with, you need hardware that's able to "speak" HDCP to capture the data—and if you have that, the hardware will be decrypting the stream anyway.

They make DVI capture cards capable of logging an encrypted HDCP stream to disk already. Combined with this software, those cards suddenly got a lot more useful.

In particular I could see this being quite interesting to the people who make those cam rips for bootleggers. If they can get access to an HDCP protected digital projector system (and I suspect they can since many cam rips seem to be done by people working at theaters), they can probably make some good money selling 1080p masters of newly released movies.

Here's why it isn't pointless.Get a computer with TWO ports. Connect one to a video source and the other to a video sink. Write code that accepts data from both ends and passes it straight through. Either store it for later decrypting, or put the decrypting code right there.

HDMI data is running at 10.2Gb/s. How do you plan on storing it? You need to decrypt and recompress in real-time to get the storage demands under control.

I suppose this can be also useful if you want to be cheap about decrypting HDCP streams, without having the need to buy special equipment for the task, nor having to sacrifice an existing HDCP device (for hacking purposes). One could just eavesdrop on the signals sent to the display and decrypt it raw via the software. Things will become even more interesting if you can somehow listen-in to the signals remotely, without intrusive intercept methods.

jonsmirl wrote:

HDMI data is running at 10.2Gb/s. How do you plan on storing it? You need to decrypt and recompress in real-time to get the storage demands under control.

Which is not a big deal. You can compress H264 in real time if you have enough cores at your disposal.

The best thing I can think of for something like this is something that should be doable (and legal) now, but is only possible in super high-end distribution systems. It would be great if one could take the stream, recompress it to something more network friendly, and then use it as part of a home video/audio distribution system over ethernet. The current offering of HDMI switching technology is over-priced and flaky at best (and the ones over ethernet recompress the signal without much loss of quality). It may also allow for things like myth tv to work with the current crop of cable tuners and satellite boxes (the myth tv box could evesdrop, and then use an HDMI connection without encryption for play back to the viewing device).

While I don't think this is a huge win for pirates or people who want lossless copies, it does seem to be a huge win for hobbyists, allowing them to do what should have been legal and easy to do in the first place. That is, it allows them to enjoy the content that they already paid for in the privacy of their own home, on their own schedule.

First, breaking their DRM is illegal and second, the content that you would get out can most likely be obtained from other, less complicated, sources (possibly also illegal).

This isn't breaking any DRM - it's decrypting the encryption. Not hacking, not cracking, not ripping, but decrypting. The encryption key isn't under copyright, so anyone can use it whenever they want to.

If you're going to design hardware to do the handshake, you might as well design hardware to do the full decrypt. It's designed to be possible in just a few thousand transistors.

There are a few HDMI In cards, but they don't support HDCP, and it's not clear that they can be readily made to support HDCP.

However, a HDMI-in card that can be made to do the HDCP handshadke would probably be legal. A card that does full decryption would not be, and the manufacturer would likely be sued out of existence in short order.

This kind of decryption can be done on the GPU. Just wait for CUDA implementation. Decrypting HDCP content will be a breeze than. Now, how to get the HDCP content? Either we find a HDMI-In card that can be hacked to let include the handshake, OR you design some hardware that can do the handshake, than copy the stream into RAM or directly into the GPU memory over the PCI-E bus.

Don't think HDCP crack is futile, it will happen sooner or later.

If you're going to design hardware to do the handshake, you might as well design hardware to do the full decrypt. It's designed to be possible in just a few thousand transistors.

There are a few HDMI In cards, but they don't support HDCP, and it's not clear that they can be readily made to support HDCP.

IIRC the handshaking is done out-of-band over the DDC (I2C bus). So one could use a simple microcontroller to do the handshaking.

Correct me if I am wrong, but isn't there really no point to decrypting HDCP whether it is in software or hardware?First, breaking their DRM is illegal and second, the content that you would get out can most likely be obtained from other, less complicated, sources (possibly also illegal).

A "point" for use of a hardware dongel that strips HDCP might be for people who subscribe to cable or satellite services who have trouble with the cable or satellite provided equipment not aways working properly with their HDCP compliant HDTVs. Personally, I have the problem with any purchased PPV content giving me periodic "HDCP not supported" messages. The provider claims it's the TV, the TV manufacturer claims it's the provider (changing equipment and cables doesn't fix it). So my point would be to use it to watch PPV content.

Now the manufacture and use of such a dongel might be deemed by illegal, but HDCP is broken or a lot of people and there needs to be a way to fix it.

The best thing I can think of for something like this is something that should be doable (and legal) now, but is only possible in super high-end distribution systems. It would be great if one could take the stream, recompress it to something more network friendly, and then use it as part of a home video/audio distribution system over ethernet.

AllVid will fix this. With AllVid HDMI can die. STBs can die. The world rejoices. Write the FCC and tell them to hurry up and approve AllVid.

AllVid transmits the video streams over Ethernet and then you run a small decrypt app in the target device. A Bluray player could take the compressed feed straight off from the disk and send it over Ethernet to the TV.

First, breaking their DRM is illegal and second, the content that you would get out can most likely be obtained from other, less complicated, sources (possibly also illegal).

This isn't breaking any DRM - it's decrypting the encryption. Not hacking, not cracking, not ripping, but decrypting. The encryption key isn't under copyright, so anyone can use it whenever they want to.

I'm not a lawyer, but as far as I understand, you need to buy a license to use (i.e. encrypt or decrypt) HDCP, so without that, you are illegally breaking their DRM.

johnbuk wrote:

maxtz wrote:

Correct me if I am wrong, but isn't there really no point to decrypting HDCP whether it is in software or hardware?First, breaking their DRM is illegal and second, the content that you would get out can most likely be obtained from other, less complicated, sources (possibly also illegal).

A "point" for use of a hardware dongel that strips HDCP might be for people who subscribe to cable or satellite services who have trouble with the cable or satellite provided equipment not aways working properly with their HDCP compliant HDTVs. Personally, I have the problem with any purchased PPV content giving me periodic "HDCP not supported" messages. The provider claims it's the TV, the TV manufacturer claims it's the provider (changing equipment and cables doesn't fix it). So my point would be to use it to watch PPV content.

Now the manufacture and use of such a dongel might be deemed by illegal, but HDCP is broken or a lot of people and there needs to be a way to fix it.

I was not aware of such problems, but even so it seems like a pretty damn complicated solution just to watch a live PPV event.

dlux wrote:

maxtz wrote:

Correct me if I am wrong, but isn't there really no point to decrypting HDCP whether it is in software or hardware?

Leverage, man. Leverage.

And hackers 5-10 years from now will thank us for getting the groundwork started.

Right, though I was referring to actual implementations like the software one that this article is calling pointless.

That is where you are wrong. Devices will come out that will decrypt and compress the stream on the fly. It won't be hard to do. Also, what about devices that aren't HDCP compliant like my Dell FPW2405 monitor? I think this will do wonders for those scenarios also.

I don't understand why you couldn't do the HDCP handshaking in software also, if you had an HDMI adapter and driver that didn't include the underlying HDCP algorithm, but that was sufficiently addressable via the driver.

I don't think any such hardware exists. They try to keep the DRM all in hardware precisely to avoid such hacks (er, "unintended uses").

alphahelix wrote:

surely with full access, someone will be able to figure out a way to spoof the handshake over existing HDMI connections?

Maybe someone can also release some microcode to upgrade my Nehalem to a Sandy Bridge.

jonsmirl wrote:

AllVid will fix this. With AllVid HDMI can die. STBs can die. The world rejoices. Write the FCC and tell them to hurry up and approve AllVid.

AllVid transmits the video streams over Ethernet and then you run a small decrypt app in the target device. A Bluray player could take the compressed feed straight off from the disk and send it over Ethernet to the TV.

I'm not so positive on AllVid, since devices will still have to implement DTCP-IP, which carries just as much BS around with it as HDCP and just as many possibilities for failed handshakes. Also, the "send a compressed stream to the TV" approach was previously proposed (over Firewire) by HAVI and it failed because that approach does not adequately support menus or any other advanced user interface. AllVid looks like a better replacement for Tru2way, but I don't expect it to replace HDMI.

Call me naive, but couldn't someone write a virtual display driver that claimed to have a physical HDCP compliant output? Redirect your video stream to that virtual port, and the driver could decrypt and save the stream.

I'm not so positive on AllVid, since devices will still have to implement DTCP-IP, which carries just as much BS around with it as HDCP and just as many possibilities for failed handshakes. Also, the "send a compressed stream to the TV" approach was previously proposed (over Firewire) by HAVI and it failed because that approach does not adequately support menus or any other advanced user interface. AllVid looks like a better replacement for Tru2way, but I don't expect it to replace HDMI.

The world has changed, digital TVs have CPUs in them - in the Firewire days TVs did not contain CPUs. My Samsung TV can already decrypt WMA encrypted streams, I should be able to do DTCP-IP with the addition of new software.

Everyone except the cable industry is salivating at making their own menuing apps that run inside the TV. My 2010 Samsung already implements a menu system (web apps, media player, games, Netflix, etc) and it internally runs Linux. Of course the Samsung can't integrate with any TV content since it is an encrypted subsystem owned by the cable company.

The AllVid boxes are suppose to provide an API for the guide/search instead of building the screens. For example this will let you combine search results from different VOD providers. Of course cable is fighting this since they want a monopoly on the UI.

Give me an ARM link library for DTCP-IP and the source to the Samsung code and I can have it running as an AllVid player in a few weeks.

Besides, my number one reason for wanting AllVid is to get rid of STBs. I have a new house with four wall hung flat panels. It has been an incredible pain finding a place to put STBs, run IR and power to them and then get the HDMI to the TV (CAT5 converters). All of these TVs have Ethernet access.

Call me naive, but couldn't someone write a virtual display driver that claimed to have a physical HDCP compliant output? Redirect your video stream to that virtual port, and the driver could decrypt and save the stream.

I was thinking the same thing. Would be useful for people without HDCP monitors.

For television sets, I would imagine a hardware box that simply strips the encryption would be much easier. All it needs to do is present itself as a HDCP sink on one side and pass an unencrypted stream to the other.

I would love to know the legal ramifications of all this. I think my roommate bought his very nice (expensive at the time) HDTV prior to HDCP. I really would hate for it to be a big paper weight. DRM only hurts those trying to do things legally.

Call me naive, but couldn't someone write a virtual display driver that claimed to have a physical HDCP compliant output? Redirect your video stream to that virtual port, and the driver could decrypt and save the stream.

1) The Windows protected audio and video paths require drivers with special signatures, and those special signatures won't be granted to such virtual devices. So software would just enable the protected video path and refuse to use your driver.2) The virtual port wouldn't need to disable HDCP in this case, since it would be entrusted with adding HDCP encryption anyway. It would just be lying, and do no such thing.

For television sets, I would imagine a hardware box that simply strips the encryption would be much easier. All it needs to do is present itself as a HDCP sink on one side and pass an unencrypted stream to the other.

Exactly. A manufacturer would not be granted a HDCP key for a device such as this, since it would output an unencrypted data stream. If you were granted a key for another device, and used it in a device such as this, that key would be added to the revocation lists, making your device useless. As a manufacturer, you'd probably also be charged with a DMCA violation. Even if a manufacturer used the master key to manufacture HDCP -> HDMI (or any other unencrypted output) devices, they could still be sued under DMCA. That is why Intel claims HDCP is still effective.

Now, if a manufacturer wants to make a device with that has two HDMI ports and flashable firmware, there is nothing wrong with that. That is where a software HDPC implementation can come in handy. Purchasers of such a device just flash it with firmware that handles the HDCP functionality. Now, instead of simply being able to target a few manufacturers, it becomes the equivalent of putting the DeCSS genie back in the bottle.

What you do with your unencrypted data stream, and your ability to do so is a separate issue, but at least you now have easier access to it.