WidevineCdm Plugin crashes when loading DRM content

[p735h]

When trying to load Netflix, the WidevineCdm plugin crashes meaning the DRM protected content couldn't loaded.

Any help would be much appreciated.

Cheers

[i3roly]

it doesn't work on older macs, or so i'm told.

i personally think there should be a way to override getentropy with arc4random_buf but @Wowfunhappy insists there will be a checksum verification (server-side) which makes this hard.

if the checksum verification is within software i don't think firefox cares much. just not sure how the whole protocol works and it'd be @krackers or @Wowfunhappy who'd know. maybe @RJVB has something to say too

[Wowfunhappy]

i personally think there should be a way to override getentropy with arc4random_buf

I do too! I do suspect there will be some other symbol we also have to override, because I'm pretty sure Chromium Legacy was doing this already, and while that was sufficient in a previous Widevine version, it's not anymore. But maybe Chromium Legacy doesn't work anymore for some other reason.

but @Wowfunhappy insists there will be a checksum verification (server-side) which makes this hard.

I don't necessarily think it's a server-side check, but I assume there is some checksum verification. It doesn't really help us if it's local since the binary is obfuscated.

But there are a couple of ways I could do it, previous discussion here for reference: #16 (comment)

What I really feel like I need right now in order to explore further is a way to get crash logs from Widevine. Otherwise, I have no way to know whether a polyfill is working.

[RJVB]

On Friday December 27 2024 10:44:41 gagan sidhu wrote: maybe @RJVB has something to say too

For widevine, all I know is that a few years back the Waterfox-G3 build I was using then update the plugin to a version that no longer loaded. I managed to revert to a backup of the previous version and (presumably) prevent further updating. That old version still worked fine then but I think that must have ceased being the case since. To be expected if they figured out a way to checksum the output of a supposedly more secure random generator!?

[RJVB]

On Friday December 27 2024 10:57:46 Jonathan wrote: I don't necessarily think it's a server-side check, but I assume there is _some_ checksum verification. It doesn't really help us if it's local since the binary is obfuscated.

Local or remote, how do you check if properly random numbers are generated by the one or the other generator of compatible specs?

What I really feel like I need right now in order to explore further is a way to get crash logs from Widevine. Otherwise, I have no way to know whether a polyfill is working.

Do you know if the plugin is run in a separate process? If it is, it can just call `ptrace(PT_DENY_ATTACH, 0, 0, 0)` and not worry about anyone ever attaching a debugger, even post-mortem. Is this the actual implementation? https://github.com/3052/widevine

[RJVB]

On Friday December 27 2024 10:44:41 gagan sidhu wrote: maybe @RJVB has something to say too
For widevine, all I know is that a few years back the Waterfox-G3 build I was using then update the plugin to a version that no longer loaded. I managed to revert to a backup of the previous version and (presumably) prevent further updating.

Had a look at that, and indeed I found widevine 4.10.2557.0 in my Waterfox-Gr profile directory *). I replaced the 2830 version from my current profile dir with that old version, and changed media.gmp-widevinecdm.version with the old version string. With that I no longer get a plugin crash but a DRM_FAILED_LICENSE_REQUEST error on https://bitmovin.com/demos/drm/.

*): When I started using FF Dynasty I cloned my main profile directory so as to be able to revert to Waterfox-G3 easily if needed. I created a new profile via the profile manager, and then replaced its contents with a copy of the contents of my Waterfox-G3 main profile directory. I fixed all references to that directory in the cloned content to point to the new profile directory, all done.

[Wowfunhappy]

To be expected if they figured out a way to checksum the output of a supposedly more secure random generator!?

I don't follow. They're just checksumming the binary Google shipped to make sure it hasn't been tampered with. I assume. I haven't verified if this is actually the case, I suppose I could but I still need a way to get crash logs out of Widevine.

With that I no longer get a plugin crash but a DRM_FAILED_LICENSE_REQUEST error on https://bitmovin.com/demos/drm/.

Yeah that's what I'd expect. The providers don't allow old Widevine versions, I guess they used to but not anymore.

[i3roly]

i guess my concrete question would be this:

1. is there an easy way to simply hexedit a supported version of widevine so that we replace getentropy with arc4random_buf?
2. if we do this, is there an easy way to decode the binary signature file (libwidevinecdm.dylib.sig) so that we can edit the value that it presumably contains and see if that will fool firefox?

it's entirely possible though, since this plugin is premised on accessing data remotely (DRM), that there are server-side checks.

[RJVB]

To be expected if they figured out a way to checksum the output of a supposedly more secure random generator!?

I don't follow. They're just checksumming the binary Google shipped to make sure it hasn't been tampered with.

Ahhh, doh, of course. I'm not at my best these days :-/

Running a stock profile with the current widevine version I see this on the calling terminal:

dyld: Registered code signature for /Users/bertin/Library/Application Support/Firefox/Profiles/v4bc1sft.Test/gmp-widevinecdm/4.10.2830.0/libwidevinecdm.dylib
[Parent 95934, IPC I/O Parent] WARNING: process 95966 exited with status 1: file /Users/Gagan/Downloads/mozilla-unified/ipc/chromium/src/base/process_util_posix.cc:341

which FF considers to be a crash (that I haven't been able to report) but the system apparently doesn't. Maybe because the widevine disables debugger attachment.

Just loading both versions of the wvcdm dylib via my dlsym tool fails on other symbols than getentropy but those must be weakly linked and behind a runtime OS version test or else the old version would "crash" too.

[RJVB]

1. is there an easy way to simply hexedit a supported version of widevine so that we replace getentropy with arc4random_buf?

That would fail if there is an online checksum of the dylib. (Note that there is also media.gmp-widevinecdm.hashValue .)

Assuming that the WV dylib gets loaded in a Firefox process, I suppose that it wouldn't work if the host exported a getentropy() function of the appropriate signature?

[Wowfunhappy]

which FF considers to be a crash (that I haven't been able to report) but the system apparently doesn't. Maybe because the widevine disables debugger attachment.

So here's the problem I'm having.

Let's say I polyfill getentropy with arc4random_buf. What I intend to try first is replacing libSystem.B.dylib itself (!) with a new library that has the polyfill and re-exports the original libSystem.B.dylib (which I'll rename to libSystem.B.orig.dylib or something). This is horrible, but it should verify if the polyfill works without actually modifying the Widevine library (and I'll do it in a disposable VM).

If it works on the first try, and Netflix magically loads, great! But I think the chance of that happening is approximately zero, if only because code I write never ever works on the first try.

So if (when) it doesn't work, how do I know whether:

• Widevine didn't even see or load my polyfill.
• My polyfill was loaded but caused Widevine to crash.
• My polyfill worked but Widevine crashed for some other reason.

I would be happy to jump on this as soon as I can think of a way to not be working with a total black box!

[RJVB]

On Saturday December 28 2024 10:04:13 Jonathan wrote: So if (when) it _doesn't_ work, how do I know whether: - Widevine didn't even see or load my polyfill.

That one shouldn't be too hard to verify with very basic, traditional debugging. Let your `getentropy()` replacement have a side-effect that widevine is unlikely to prevent actively.

[RJVB]

BTW, here's a cute article about how to get around PT_DENY_ATTACH: https://alexomara.com/blog/defeating-anti-debug-techniques-macos-ptrace-variants/

All this is probably going to be a lot easier if you can find some example code that allows using FF's libwidevinecdm.dylib in a standalone application that attempts only to get the required benediction(s) from the server. You could then start that application in a debugger and follow the instructions above to avoid PT_DENY_ATTACH if that turns out to be required.

[Wowfunhappy]

That one shouldn't be too hard to verify with very basic, traditional debugging. Let your getentropy() replacement have a side-effect that widevine is unlikely to prevent actively.

...good point. Okay.

---

My plan to replace libSystem.B.dylib is, um, not working.

With my replacement library sitting on the desktop of my VM:

optool install -c reexport -p /usr/lib/libSystem.B.orig.dylib -t /Users/Jonathan/Desktop/libSystem.B.dylib
cp /usr/lib/libSystem.B.dylib /usr/lib/libSystem.B.orig.dylib
cp -f /Users/Jonathan/Desktop/libSystem.B.dylib /usr/lib/libSystem.B.dylib

This... did not work even a little bit. If I try to start virtually any binary, I get:

dyld: Symbol not found: __NSConcreteGlobalBlock
  Referenced from: /usr/lib/system/libcorecrypto.dylib
  Expected in: /usr/lib/libSystem.B.dylib
 in /usr/lib/system/libcorecrypto.dylib

Any idea why the re-export didn't work? It should be getting these symbols from /usr/lib/libSystem.B.orig.dylib. I know what I'm trying to do is kind of nuts but the re-export should be seamless, shouldn't it?

[RJVB]

Any idea why the re-export didn't work? It should be getting these symbols from /usr/lib/libSystem.B.orig.dylib. I know what I'm trying to do is kind of nuts but the re-export should be seamless, shouldn't it?

On my system:

> dlsym /usr/lib/libSystem.dylib _NSConcreteGlobalBlock
/usr/lib/libSystem.dylib::_NSConcreteGlobalBlock: 0x7fff7d7a04d0 (/usr/lib/system/libsystem_blocks.dylib::_NSConcreteGlobalBlock)
> dlsym /opt/local/lib/libMacportsLegacySystem.B.dylib _NSConcreteGlobalBlock
/opt/local/lib/libMacportsLegacySystem.B.dylib::_NSConcreteGlobalBlock: 0x7fff7d7a04d0 (/usr/lib/system/libsystem_blocks.dylib::_NSConcreteGlobalBlock)

What if instead of actually replacing libSystem.B.dylib you relink a test binary to ~/Desktop/libSystem.B.dylib?

Another thing to try would me to inverse the order of the 1st two steps in your recipe above. If you did exactly as described you were reexporting from a file that didn't exist at the time.

[Wowfunhappy]

What if instead of actually replacing libSystem.B.dylib you relink a test binary to ~/Desktop/libSystem.B.dylib?

The test binary doesn't work either.

Another thing to try would me to inverse the order of the 1st two steps in your recipe above.

It doesn't matter, optool is just writing whatever path I give it. But I did try changing the order just for the heck of it, and as expected it didn't work.

[RJVB]

On Saturday December 28 2024 15:15:00 Jonathan wrote: > What if instead of actually replacing libSystem.B.dylib you relink a test binary to ~/Desktop/libSystem.B.dylib? The test binary doesn't work either.

That's weird (and we *are* talking here about a restored system or one that was never hacked, right? ;) ). And what about relinking the test binary to the MacPorts legacy system.B wrapper? That project would be a logical target for a `getentropy()` implementation (if it doesn't already have one).

It doesn't matter, optool is just writing whatever path I give it. But I did try changing the order just for the heck of it, and as expected it didn't work.

The only sensical explanation I can see is that the OS has anti-tamper measures for libSystem, though you would expect those to behave differently. And there could be something going on at the level of circular dependencies (or indirections) which need to find the real libSystem at its designated location, and not a reexported version. But that wouldn't explain why you can't relink an executable to a reexporting libSystem in a custom location.

[MacBiter]

When trying to load Netflix, the WidevineCdm plugin crashes meaning the DRM protected content couldn't loaded.

Any help would be much appreciated.

Cheers

You don't say what Mac and which OS you're using?

[Wowfunhappy]

^ It honestly doesn't matter in this case. We can tell from the screenshot they're on 10.9 or below and we know Widevine doesn't work there.

[MacBiter]

I can stream DRM in my High Sierra VM, while keeping Mavericks as my main OS - I was going to suggest something similar to the OP

[RJVB]

I have a strong hunch that a Linux VM would be less resource hungry for that kind of thing!

[Wowfunhappy]

^ or Windows 10, not because of the operating system itself but because VM vendors have put tons of resources into optimizing Windows guests, so that people can play e.g. 3D games. Using Windows inside a VM is a remarkably better experience than macOS in a VM.

However, I have suggested this to MacBiter multiple times on MacRumors, and he hasn't taken me up on it, so oh well. 🤷‍♂️

[RJVB]

On Thursday January 02 2025 09:42:01 Jonathan wrote: ^ or Windows 10, not because of the operating system itself but because VM vendors have put _tons_ of resources into optimizing Windows guest

Indeed. You just need a license. Officially ;) That said, running 10.9 in a Parallels VM was sufficiently smooth ... for rebuilding all of my MacPorts tree of the time.

[MacBiter]

^ or Windows 10, not because of the operating system itself but because VM vendors have put tons of resources into optimizing Windows guests, so that people can play e.g. 3D games. Using Windows inside a VM is a remarkably better experience than macOS in a VM.

However, I have suggested this to MacBiter multiple times on MacRumors, and he hasn't taken me up on it, so oh well. 🤷‍♂️

Only because I've successfully run 10.6.8, 10.12, and now 10.13 in Parallels, so would only resort to Windows if Google stopped supporting Widevine in High Sierra.