FairPlay, Apple TV+, Netflix, hw DRM not working

[wittyofficer]

Hi,

Is anyone else having issue to play videos from Apple tv app ? I'm getting a blank screen while playing any episodes. I tried Netflix on browser and it's working fine. Only having issue with Apple TV+.

Configuration:

• HaC Mini version [e.g: 2.0]: 2.4
• OSX version [e.g: 10.14.6]: 10.15.1
• NUC model [e.g: NUC8i7HNK]: NUC8i7HVK
• Boot SSD model and protocol [e.g: Samsung EVO 860 1TB, SATA]: Western Digital SN500 NVMe 250GB
• First DIMM model [e.g: Patriot DDR4-2666 16GB]: Corsair Vengeance DDR4 2400Mhz 8GB
• Second DIMM model (if installed): Corsair Vengeance DDR4 2400Mhz 8GB
• Display port(s) used [e.g: USB-C, mini DP]: HDMI
• Display resolution(s) [e.g: 4K, 5K]: 1080p

Modifications

• DW1820A support

[goodbest]

I'm having the same issue, and I'm using mini-DP port with 4k. (It works fine on a real mac in the same network.)

[echoRelay]

Add me to the list, but I also cannot view any videos with iTunes DRM

[osy]

Can someone try it with WG disabled?

[goodbest]

@osy86 it's not working, even if disabling WEG in installer. I think the root cause is shiki for soft/hardware DRM decode.

Additionally, I did extensive tests, but no luck. System: 10.15.1, Monitor: 4k + dp (LG 27UL650)

My tests includes the newly updated weg 1.35 (and lilu 1.4) released yesterday, introducing some new feature in shikigva:

• release note 1
• manual update
• shikigva

The result benchmark for my test:

• TV App videos. Working on real mac.
• The sample drm trailer provided in whatevergreen manual. The video and audio are working on a real mac. I use quicktime player

I tried the following combinations

weg&lilu	shikigva	shiki-id	result-tv app	result-sample trailer file	note
--	--	--	working	working	real mac
1.3.4 + 1.3.9	32	BE0...	black screen	audio is OK, video is black	The default settings for Hac-mini
no weg	32	BE0...	won't play	can't decode	The default settings for Hac-mini, without weg
1.3.5 + 1.4.0	32	BE0...	won't play	can't decode	The default settings for Hac-mini, kexts updated
1.3.5 + 1.4.0	160	BE0...	black screen	audio is OK, video is black	shikigva hint from manual
1.3.5 + 1.4.0	144 or 16	BE0...	won't play	can't decode	shikigva hint from manual
1.3.5 + 1.4.0	160 or 16	7BA...	won't play	can't decode	shiki-id hint from manual
1.3.5 + 1.4.0	0	--	won't play	can't decode	ProductName, MLB, SN set as iMacPro1,1 (hint from manual)

[osy]

Thanks for testing. I think what's happening is that when we use IGPU to hardware decode, it doesn't work because of provisioning (see https://github.com/acidanthera/bugtracker/issues/586). However, currently it's not possible to activate AMD hardware decode (see comments in #18). I think to resolve this, we need to either get IGPU decode working or AMD decode working (or both).

[vit9696]

Lilu & WEG master with shikigva=16 or shikigva=80 (for Netflix) should work on your setup without any other arguments with Macmini8,1 SMBIOS model. If it does not, then most likely AMD drivers for Vega 20 are borked.

[piotrasd]

DRM checking HDCP if is in use, IGPU intel doesn't have physical HDMI connection so there is no HDCP. only way I think is do this over AMD. second thing now with new Macs, MacBooks etc. and macOS it will harder get HW acceleration at least for HEVC because apple now using T2 chip for it.

[wittyofficer]

I also tried disabling iGPU and changing SMBIOS to iMacPro 1,1. With this setup I was able to see the 30 sec video trailers before any episode on AppleTV + but the Episode didn’t play

[osy]

@goodbest Can you test with shikigva=256 (no shiki-id)?

Also put com.apple.AppleGVA.plist.zip in ~/Library/Preferences.

First test with released WG. Second, test with the attached WG. WhateverGreen-1.3.6-RELEASE.zip

[goodbest]

Here's some quick results, @osy86

weg	shikigva (w/o shiki-id)	AppleGVA.plist	tv-app result
1.3.5	256	w & w/o	won't play
1.3.6	256/128/80/32/16	w	audio is fine, video show up for ~1 second, and then turns into glitches and green blocks
1.3.6	256	w/o	won't play

I shot a clip to show the "glitches and green blocks" (I hit the play button at around the 3 second.) IMG_9502.mp4.zip

[osy]

Please try shikigva=208. The plist is no longer needed (you can delete it or leave it).

Also, try testing with iGPU disabled.

[goodbest]

I'm afraid the result is still the same. either with shikigva=208 or iGPU disabled in BIOS.

Maybe it's better to wait for some test results by someone else (to ensure that my results are not mis-leading)?

[osy]

After spending significant time on this, it seems to be very difficult/not possible.

Basically, we have two hardware video engines: AMD and Intel.

Intel

So the Intel IGPU DRM decoder requires GuC/HuC loading + PAVP to work. I've documented what I've reversed here but basically the underlying issue is that

1. Springboard fails likely because the PAVD config is wrong. However, Intel BIOS locks in the config so it's not possible to change it (without patching the BIOS which is also not possible because of Boot Guard).
2. Say we somehow get Springboard to work. We would then need to provision EPID with Apple's keys. It seems like some boards do not have EPID provisioned (so we can provision it), but this is not true for the NUC, which provisions EPID in the BIOS.
3. What if we somehow manage to provision EPID? Then we would need an Apple signed certificate for the group id of each NUC. Some people report their CPU's group id being in Apple's set of signed certificates and that's great but my NUC's CPU is not in the set and I am willing to bet nobody else's is either.

Conclusion: Intel route is impossible.

AMD

AMD UVD engine can decrypt DRM. However, the UVD drivers need to be patched to work. I actually went ahead and fixed that. However, even with working UVD/VCE hardware drivers, we run into the above mentioned artifact/block/corrupted image issue.

I tried to see if there's any quirks listed in the Linux drivers, but afaik Linux doesn't actually implement any hardware DRM decoding (this is why you can't watch Disney+/Hulu Plus on your Linux machine). Since the decode issue doesn't affect non-encrypted streams, there is no point in looking for UVD hardware bug workarounds in Linux (there are a few but if they affected us, then normal video playback would be broken also, but we only see encrypted video playback broken).

If there is indeed a hardware bug/issue then maybe reversing the Windows drivers (which does support DRM) might help, but that's a lot of work.

Conclusion: AMD route is very difficult and probably not worth doing (honestly there is no show on Apple TV+ that I care about anyways).

Alternatives

I have not tested any eGPUs but it's probably possible to play with an officially supported AMD card in an eGPU.

[goodbest]

@osy86 Thank you for your hard work. Nice try.

[AkimoA]

i gave it also a try using iMacPro1,1 and RX580 -radcodec ... the freeze on netflix and amazon is gone but aint working either pressing play ends up on help page from netflix. also all variants of shikigva didnt change anything .

[vit9696]

@osy86, well, TV+ decoding, unlike Netflix, can be done entirely in software, so it is not that bad, but it needs reversing Apple drivers to be allowed when IGPU is visible.

[osy]

I tried that Shiki flag with IGPU disabled in BIOS and it didn’t work. Maybe it’s looking for nvidia gpu since it’s a fallback for systems without hardware decode?

[vit9696]

Do not think so, from what I remember it was designed to allow watching TV+ on MP5,1 and MP6,1. The key there was EXTSLOTS patch. I think the IGPU thing is not particularly relevant, but rather it will fallback to software renderer only when no hardware render exists.

[osy]

I see, it doesn’t work without -radcodec either so maybe the check is more strict than “did create accelerator call fail”? Anyways I see that the amd ucd ucode is not loaded by AMDRadeonX4000HWLibs (unlike the other ucodes; which has vegam support) but is loaded by AMDRadeonX4000 which does not have any vegam specific code. I will try to replace this ucode with the vegam one from Linux and see if that makes a difference. Even if sw workaround for Apple tv+ works I would rather have Netflix working as well.

[osy]

~The UVD ucode is encrypted in AMDRadeonX4000 and is loaded with PSP. On Linux, the UVD ucode is plaintext and loaded directly by the kernel. My guess is that Linux's ucode is not able to do any hardware decryption.~

Upon farther inspection I can’t say for certain PSP is involved here. There’s some obfuscation of the firmware but even unobfuscated it still seems to be encrypted.

[crhendo]

This could be unrelated so I apologize in advance. (Catalina 10.15.2)

Last night I upgraded the WiFi BT card in my 2012 Mac Book Pro Retina to a BCM943602CS. Immediately after I rebooted I was required to re-authorise my TV app and Music app and in both cases I noted that the number of authorisations left had reduced by one..... in other words I was running DRM protected files on what was effectively a new machine.

I then started loading other apps that were sourced from both the app store and 3rd parties and in a number of cases I was asked to re-enter the apple ID and password associated with each app (I have 3 Apple ID's). For two of my 3rd party apps I was asked to re-enter their licence keys.

How is this related? If changing the WiFi BT card triggers these events, perhaps Apple is also checking hardware before making DRM decisions. For example, @wittyofficer is using the Dell DW1820A.

Just a thought....

[lmshsqlc]

This could be unrelated so I apologize in advance. (Catalina 10.15.2)

Last night I upgraded the WiFi BT card in my 2012 Mac Book Pro Retina to a BCM943602CS. Immediately after I rebooted I was required to re-authorise my TV app and Music app and in both cases I noted that the number of authorisations left had reduced by one..... in other words I was running DRM protected files on what was effectively a new machine.

I then started loading other apps that were sourced from both the app store and 3rd parties and in a number of cases I was asked to re-enter the apple ID and password associated with each app (I have 3 Apple ID's). For two of my 3rd party apps I was asked to re-enter their licence keys.

How is this related? If changing the WiFi BT card triggers these events, perhaps Apple is also checking hardware before making DRM decisions. For example, @wittyofficer is using the Dell DW1820A.

Just a thought....

I guess the serial number is bond to your WiFi card, right on the sticker.

[osy]

It’s unrelated. The basically the keys sent to your device is based on unique id generated from serial, MAC address, guid, etc. But when hw decryption is used that key is passed to either IGPU or AMD GPU to perform the content decryption. That part is broken.

[osy]

This whole time I was going under the assumption that DRM works on Windows, but that may not be the case. Can someone confirm that Netflix 4K works on Windows? Also test if Netflix 4K works on Windows with IGPU disabled.

[iiicwx]

Apple TV+ suddenly works now.

upgraded to 2.6 yesterday, apple tv+ still didn't work at that time, had audio only, half screen was green and lots of blocks and glitches.

[iiicwx]

AMD decoder in the installer was chosen.

[osy]

Does it work with Intel?

[iiicwx]

Even AMD doesn't work any more after the reboot when I tried to test the intel decoder.

[iiicwx]

after an auto sleep, it works again.

if you know how to collect more information, please let me know, I will send it to you.

[osy]

Even AMD doesn't work any more after the reboot when I tried to test the intel decoder.

Make sure you reset boot-arg or cleared NVRAM after reinstall as per the new instructions.