The server can send an encrypted blob to your browser which hands it off to the DRM module which can hand it off to the system's ring -2 PAVP/Trustzone/etc. stuff that only runs signed firmware which passes it encrypted over the PCIe bus to the gfx hardware which passes it encrypted via HDCP2 to the monitor.

So in principle fully encrypted paths that can'e be screengrabbed exist. Not all DRM makes use of those components because it excludes users which don't hardware which supports it. But it is there.

Thanks for the detailed description.

> .. which passes it encrypted via HDCP2 to the monitor.

And where does the decryption actually takes place?

> EDIT

https://en.wikipedia.org/wiki/High-bandwidth_Digital_Content...

> In order to make a device that plays HDCP-enabled work, the manufacturer must obtain a license from Intel subsidiary Digital Content Protection LLC, pay an annual fee, and submit to various conditions.[5][6][7] For example, the device cannot be designed to copy; it must "frustrate attempts to defeat the content protection requirements";[7] it must not transmit high definition protected video to non-HDCP receivers; and DVD-Audio works can be played only at CD-audio quality[7] by non-HDCP digital audio outputs (analog audio outputs have no quality limits).

This sounds quite far-fetched though. I'm quite sure we're going to see people literally recording their TV screen with a hand-camera soon.

How about the case where the hardware doesn't support it. Would screen-grabbing be possible then? Where will the decryption take place in that case?

> How about the case where the hardware doesn't support it. Would screen-grabbing be possible then? Where will the decryption take place in that case?

There essentially are several tiers of DRM

  - hardware-assisted encrypted pipelines (described above)
  - kernel module assisted
  - pure userspace obfuscated code

If it's in userspace, such as some software DVD players or game DRM then you can use a debugger to dump the keys or maybe hook some method that sends the frames to the gfx card.

If it's kernel-assisted you would have to bypass kernel module signing and hook deep into the operating system because the OS will also prevent screengrabbing of the protected surface.

If it is hardware assisted you will have to find a flaw somewhere in the pipeline or buy devices that contain decryption chips that basically are repurposed official decryption chips.

> How about the case where the hardware doesn't support it. Would screen-grabbing be possible then? Where will the decryption take place in that case?

You don't get the content then. Full stop.

With many providers, you do still get the content, just limited to 480p.

You can screengrab at the interface between the decoder in the monitor and the panel itself, using an LVDS capture card. Not cheap at the moment, and you still have to process the gigabits per second of uncompressed video, but you can expect the Chinese to come up with some inventive and low-cost solutions if they start locking down the other routes... in fact a lot of DRM-stripping hardware already exists for sale, if you know where and what to look for.

But what about literally recording your screen with a hand-camera? That would be quite tech-proof right? It's been done in cinemas for decades.

With a bit more dedication and electro knowledge, I'm sure one could open up a screen and capture the data straight from the output circuit. Few people can do this, but piracy doesn't need more than one source to be distributed over the world.

>So in principle fully encrypted paths that can'e be screengrabbed exist

This is the worrying part. While DRM has always existed, it has always been possible to defeat it largely because any software can be reverse engineered. Once you get down to the processor, it's close to impossible. And it's not like we have a lot of processor companies.