@matrix
Guess it ain't encrypted then lolololol

@r000t It is

@matrix
.... Are they just encrypting the video stream and not the container?

@r000t
Looks like it. All the streaming services use Widewine, but I'm not sure if it's the same everywhere or it's just HBO's implementation.

@matrix
Here's what I don't get

My GNU/compatible Firefox plays widevine content. How has widevine not been reverse engineered yet?

@r000t @matrix Most likely a patent/trademark reason, rather than a technical reason.

@r000t
What do you mean reverse engineered? People already know how to get the key and decrypt it.

@matrix @r000t Do you mean the hardware mode of operation has been cracked? I thought that relied on trusted execution cpu stuff that couldn't be trivially defeated.

The software has little practical value though.

@roboneko
No. I was sorta wrong since I wasn't sure. After looking up some stuff doesn't seem like the DRM was reversed engineered however streaming services use only level L3 which is done in software and you can hook into the browser and dump the keys.
@r000t

@r000t @matrix

> GNU/compatible Firefox

The browser downloads an opaque blob to process the DRM content with. This was highly controversial a few years back when it got incorporated into the spec. You can disable this "feature" under settings.

@r000t @matrix DRM is like that these days. HDCP is similar, if you grab the frame buffer there will be a rectangle that's either a black box or full of noise. Shits fucking retarded and now they've been adding support to the Linux kernel. Media companies need to die.

@roboneko @matrix that's the weird thing tho

I've captured widevine "protected" content with OBS, no problem, no workarounds required. It Just Works(tm). I even have a "Just Pirating" preset for OBS.

That said, if there's a way for, say, yt-dlp to grab the keys out of memory and grab the raw stream, I'd like that just a bit more.

@r000t @matrix I think that's due to software level implementation being used. Probably your distro hasn't gained support for the API for encrypting regions of the framebuffer yet. So once decoded it's sitting there free to grab.

Even once that API support lands as long as it isn't backed by GPU hardware attestation you will be able to fake it out with a custom kernel module or driver modification that misreports the status. However I expect the "feature" will eventually gain hardware level integrity similar to trusted execution on the CPU.

All of this is presumably a large part of why methods without hardware support are often not allowed to access the highest resolution streams. But even so you're still limited to recording as it plays back with such an approach and you have to reencode everything once you capture it. Better to grab the keys and use the original stream.