FHD playback / UHD listing about xbmc HOT 122 CLOSED

The CDM decides which exes and dlls need to be signed, including the main process itself, which wouldn't be chrome or firefox when you're using kodi, now would it? :)

Based on the time in which VMP appeared in ChromeCDM it seems like a direct response to the original wvdecrypt code, btw. :)

Anyway I don't know if Netflix enforces it, but presumably they don't, if the kodi plugin works on desktop.

from xbmc.

I'll copy my tests out of #224 in here, as it might be useful later on:

After a few tests [with operatingSystemName parameter to catalog/GetPlaybackResources API call, ndr.], selecting anything other than Windows (and a few other written below), with this specific capitalization, reduces the number of videos available for playback. If, for example, we select Linux, it hides all the high movie resolution streams (that are unplayable anyway, in our case), but along with it takes a few of the high resolution TV series that would be playable. Using the Windows parameter, seems to restore all video qualities.

With a bit of data mining, and several tests later, I found the following:

As far as movies go, Mac OS X, Windows and Windows RT have the full 1920 width available, although at least on my Win7 machine, only streams up to 1088x464 were playable. Anything higher would result in audio and a freezed frame. All streams reported as H264.

[…]

I think I noticed it depending on a few parameter combinations, some resolutions are added or removed to the list, but nothing higher than 1088 will ever play. I also noticed that HLS is also supported, but it returns AVC1 encoded videos. IS.A fails with a Could not open / parse mpdURL, uncertain if that's because I might be lacking some specific codecs.

from xbmc.

First of all, I ask everyone's forgiveness if I've been sounding relatively rude or just plain stupid. I've just realized that I'm increasingly fever-ish, and since it usually slowly turns me into a braindead grumpy cat I just want to reiterate that I'm not trying to attack anything/anyone, I'm just trying to solve this problem with increased frustration. So, if you'll excuse the tone I used so far, I'll try to explain myself better.

So this has to mean that to the very least there must be an L3-secured HD stream

Correct. Firefox streams are L3, as the license handshake I analysed suggests.

Therefore either L1 requirements on phones is bogus (at least for non-4K stuff that is), or the app is using different APIs that ends up offering you different streams.

I believe we provide android with the necessary native streams, but even if we were to pass them L3 protected H264 I'm unsure whether or not it could decrypt them. Imagining Android has all the codecs it needs, it's actually the OEM Decrypter, not even the WidevineCDM, that decides whether or not the content will be decrypted, with a whitelist based approach (afaik). It should be relatively easy to pass L3 encrypted content for any platform, previous studies suggest it won't matter anyway.

In fact, movies aside, I cannot think of once that youtube required me it

I was directly referencing the YouTube movie streaming issue, with problems decoding >480p with any Widevine CDMs. It was a bit ago, so my information might be outdated.

p.s. also which x86 system released in the past 5 years hasn't some sort of, if not TPM, at least TEE?

I have no idea, but I sure will hang tightly on my esa-cored ht-enabled TXT-free processor. I'm philosophically against any form of trusted computing, and no amounts of "necessary evil" or "inevitable doom" would convince me otherwise. On this, I'm strongly with Stallman.

Docs just say FF value means L3. Which I'm not sure how couldn't be available anywhere.

Correct, but part of the can/can't relies on CDMs that must be shipped/certified with binaries (roughly, not literally). This could absolutely not be our case, you're perfectly correct on the assumption. But then, again, both the Widevine CDM and the OEM Decrypter work with a whitelist based approach, and the extent of their "validation" is out of our scope. I know it works like this because it's in the specification, but they obviously omitted the details. I'm trying to analyse the docs to see if I can adapt our software to the problem we're facing.

UNVERIFIED doesn't even mean TAMPERED, it just entails the "verification code" isn't even plugged in

Exactly. The problem is that I actually requested and attached the server PSSH, but it doesn't work. So it's one of the following:

1. Just as for the linux version, the cdm we're currently using doesn't fully support VMP/client certification/whatever it is that it should.
2. Replacing the current IS.H wvcdm with Firefox's version should work, but doesn't because of reasons I'm not yet clear with.
3. wvcdm won't ever work with our custom software because we're not whitelisted with the decrypter.
4. The solution's simple as heck, but I can't see it because I'm increasingly feverish.

The good news is that I found quite a bit of docs, so at least I now can learn more about it and hopefully figure out what we/cdm/is.a are doing wrong. If I don't fall asleep on my desk due to the fever:thermometer:, that is :laughing:

P.S.: I've added a bunch of documentation on the post above, if you guys are curious.

from xbmc.

I've been hammering at it for the past 5 days, recompiled everything recompilable and have discovered the following:

1. PLATFORM_UNVERIFIED does not prohibit 1080p reproduction
2. I still have no idea why IS.A fails and what's so different with Firefox

On the bright side, we now know we don't need VMP, so that's out of the way (at least I think, but _UNVERIFIED speaks loudly in 1080p). Also, I now have Firefox, Kodi and InputStream.Adaptive in a compilable (and working) form. If it's anything that can be fixed by coding, I'll get to the bottom of this, even if I have to lose my mind over it for another week or three.

from xbmc.

I did some investigation and the conclution is if the content has HDR as WELL as UHD then adding deviceVideoQualityOverride=UHD&deviceHdrFormatsOverride=Hdr10 will provide 4k UHD HDR minefeast

URL

from xbmc.

Nope, it's still on my list of things to do for the addon but still haven't been able to look into it.

from xbmc.

Although I have quite some old expertise in reverse engineering, when it comes to this sort of things I usually go completely platform agnostic and just sniff the living sh*t out of the network transmission through a transparent proxy, and reverse engineer the protocol from there. That's the way I reverse engineered PrimeVideo's everything, and it worked (kind of) okay. Even then, replicating what FireFox and Chrome do to get and decode the streams doesn't let Kodi reproduce videos in the same way. I'm relatively new to Kodi as a whole, so if I had to analyse both Kodi and IS.A's sources it would take me months.

I've been away from the scene from quite a long time, and I especially know nothing of android reversing, so my only bet in this would be to either transparent proxy a TLS connection between my TV and amazon servers hoping that they don't use certificate pinning, or be stuck with about nothing. Which is the reason why I still haven't done anything, as I severely doubt that's going to work. (Because they use pinning, right?)

Anyways, I have a few days off work in front of me, so if you guys have suggestions or attack vectors, or want to set-up a mini reverse engineering collective effort, let me know.

from xbmc.

After you said that on Firefox 1080p ran find I got curious and installed a brand new portable version to dedicate to reverse engineering. At a glance, these are my findings:

• Firefox is using Widevine CDM 4.10.1196.0-win-x64, grabbing it from here: https://redirector.gvt1.com/edgedl/widevine-cdm/4.10.1196.0-win-x64.zip (apparently it's for Edge?);
• There are new APIs exposed that weren't there in the last two revisions, such as /gp/video/api/storefrontEnrichItems. Might reduce load times dramatically, but I'll have to look deeper at it;
• Firefox is reportedly showing as supporting 1080p HD streams on Win7 x64. I'm fairly sure that is correct, but I'll double check with the actual stream CDN location.

So, yeah, contrary to popular belief FHD might (could?) actually be obtained under Kodi, unless there's something weird going on with the Widevine library itself.

I'll analyze the handshakes and whatnot, maybe we can sort this out once and for all.

from xbmc.

Kodi decided to do “The right thing”™, so now I can't debug fucking anything coming out of it. None of the systems they listed to bypass certificate validation works. Fucking geniuses, the lot of them. What am I supposed to do now, revert to Alpha1?

This day started badly and it's gonna end poorly…

Edit: Kodi is now ignoring system CAs and is shipping with a CA bundle inside systems/certs. If you guys need to proxy/bypass, you can put your self signed root CA in there. All values back to nominal.

from xbmc.

1.)
Forcing the 08 04 request for android for encrypted messaging is done with setting private_mode attribute. There is no such attribute for libwidevine, if you guys find how it is triggered, pls. let me know.

Sure you can retrieve the server certificate by your own in addon and pass it using inputstream.adaptive listitem property, but I'm sure there is a way you don't have to do it this way.

2.)
4K streams are usually HEVC encoded. libWidevine does only decode H264 and VP9 (s/w) so it will be unlikely that 4K streams will be played using the internal decoder. There is only one chance for libwidevine + 4K: implement platform verification (as done in chromeos) to say that your system is "secure" and use libwidevine only for decryption. I doubt, that this will work in any way, because of many reasons (HDCP)

3.) would be worth a try setting inputstream.adaptive.license_flags=persistent_storage and watch traffic in kodi log

Edit: @Varstahl : regarding PSSH: https://w3c.github.io/encrypted-media/format-registry/initdata/cenc.html#common-system

from xbmc.

At least now I know why I had the "CAQ= is Server Certificate" in the back of my head all the time. Glad I'm not completely crazy.

If unencrypted client ID requests from your custom build of Firefox get 1080p on Amazon then your issue isnt service certs.

The playback from a compiled Firefox report as playing in 1080p, and the logs show that it's not VMP. Which is also the reason why I decided to dismiss the idea after finding it out.

Can you post a license request with unencrypted client id from a successful playback of 1080p in your browser and also one from a failure from Kodi? base64 is fine or just the binary file. Use the same video please.

Signed Firefox build:

CAQ=: CAUSwgUKvAIIAxIQCuQRtZRasVgFt7DIvVtVHBi17OSpBSKOAjCCAQoCggEBAKU2UrYVOSDlcXajWhpEgGhqGraJtFdUPgu6plJGy9ViaRn5mhyXON5PXmw1krQdi0SLxf00FfIgnYFLpDfvNeItGn9rcx0RNPwP39PW7aW0Fbqi6VCaKWlR24kRpd7NQ4woyMXr7xlBWPwPNxK4xmR/6UuvKyYWEkroyeIjWHAqgCjCmpfIpVcPsyrnMuPFGl82MMVnAhTweTKnEPOqJpxQ1bdQvVNCvkba5gjOTbEnJ7aXegwhmCdRQzXjTeEV2dO8oo5YfxW6pRBovzF6wYBMQYpSCJIA24ptAP/2TkneyJuqm4hJNFvtF8fsBgTQQ4TIhnX4bZ9imuhivYLa6HsCAwEAAToPYW1hem9uLmNvbS1wcm9kEoADETQD6R0H/h9fyg0Hw7mj0M7T4s0bcBf4fMhARpwk2X4HpvB49bJ5Yvc4t41mAnXGe/wiXbzsddKMiMffkSE1QWK1CFPBgziU23y1PjQToGiIv/sJIFRKRJ4qMBxIl95xlvSEzKdt68n7wqGa442+uAgk7CXU3uTfVofYY76CrPBnEKQfad/CVqTh48geNTb4qRH1TX30NzCsB9NWlcdvg10pCnWSm8cSHu1d9yH+2yQgsGe52QoHHCqHNzG/wAxMYWTevXQW7EPTBeFySPY0xUN+2F2FhCf5/A7uFUHywd0zNTswh0QJc93LBTh46clRLO+d4RKBiBSj3rah6Y5iXMw9N9o58tCRc9gFHrjfMNubopWHjDOO3ATUgqXrTp+fKVCmsGuGl1ComHxXV9i1AqHwzzY2JY2vFqo73jR3IElr6oChPIwcNokmNc0D4TXtjE0BoYkbWKJfHvJJihzMOvDicWUsemVHvua9/FBtpbHgpbgwijFPjtQF9Ldb8Swf
RQST: CAES6ysScQpvClkIARIQr9eKaJLrSluqx+2ZReWEFRoGYW1hem9uIjVjaWQ6ajc3SmJFeVZRVG11M1dNOWtoSTNnZz09LHI5ZUthSkxyU2x1cXgrMlpSZVdFRlE9PSoCU0QyABABGhB/hbmTRrE1x7j8wOxWK0g2GAEg4Inj4QUwFULrKgoPYW1hem9uLmNvbS1wcm9kEhAK5BG1lFqxWAW3sMi9W1UcGrAohz7fDPRAzvpgfAd8fu6FdwzenP32cm/Gky6ZI8dREX1VsL2ADYX6XMo8iwACQIPKJ9GPKXK9XKuQwa/Rg2o79k2zW3MJuQX3I8+7oaLgI/P3LJLzdOMMDrsRljlB0Qm8HtcF/EGrx7bNRqzZgiPWTwC0NVt+YcTz9Fe3VS8PQar40RLiCesWBY/FHGkqHBR5KaRafY6GyhVxzpaIEhCSEpNgHjjeMXyXQbK6f/JSN5Boe3AWGHyWX+5O1UkOciO7fUhKzPMUXDiUjH26q4R1DrqmNSHzZlncRhiirLxbScmfLVut8bgFcz9hMwPVVfPqB37qHeBp+hj0X0OMeM23BoTA/H4WsoXahIz+LtiiYRz557TPjIrZKRBNvfAVEi2aHiSjWt2fz6fReOBnRLcPY7vOjZJtvz3ylI6gMI48bxL8rHtcUon/MS5n60Gn2BWBK8o4AQFuN5p3MOXU/+HcpHjrAUy0mI87fib+xi3AREgimAhaIL1shCCCbaO+fo5C2zTsqdqMx/MEVWaJFuxzVDKuxtmCxqtz+8xjGg0wakkeIjJt/GFFz5Ui+RT9RcEwhTxCCORz8467drpwUoK3KmofxC62/M6hHEkQp7IalMgAa429GY4JliOeyWRPdYY0iRGspWnxo/CpdDbiOsY/5T+6vxtVTbKojmKtyAQVplKLQxVXjMt/0RHxI3Fau/Ncqe2sedhqji+dbzgGdsJyIrNyuzaR/FKPo+mpQiUuBQuunurj6wNNUX0VB0dmd3JXEtFgQPSEoBhuNzdw/yxz9JXRzmI38Gm6w3yezB57o1ryfso8Q7WGyGXPFNQ4Vo/thvDVGhqxIyrNZ2z3MGP/2chsYDoiIJUye+UrkHd9FhltEpFdQfO8gKjBVZwZcg8jXY+ayVHzOThg/+/a4Ld2bAOF3USlM+UgL/zfy7+E31TAsyYpbgXFa535RwIlXez8oKXhsnq13KMV2ZT2dt5Pw47u5qCeWd/Kpc/P0te2ia+40mexR5+OdaHY89ce+MjxcEZh7NOI/nOOXapv83KDbDNvS2TiG0e2ZJIHAJeTOxpXTFTYBDMzGJqgMM5p9b5QzLQ7BadNzeOz8v7H8qcPphUNdEA53VL2d9AkYdWaB8ParVfIrekksEKjwfshDFgAPR5vgsna48s9jPImF3GU1At5v41MJWW7Mi9t60hC3xq13SfQsyBfhYJ24ZHqJYtBAKZiQlR0C49JTzQSqdHnzb6O4tkRN8vnKV5u/oSUQPaSLqul00RacBilyF+leKlfTmHLqC0KY53rMA+F6Re/5MBIB4d8OU/w9drpZb/l1s2CQhy0UUt1tNqJJ3LPgJUYLjFyPGuNVYhTbIKYmL9AnjENTEOiwdL/YGhvgWAdPxfveFGorwTFjHDqWwS25win0y7XyLYYYqJ+KdrRRQHI6NYH6zKJwJ+FtR1wRCdl43EFSsiJ17paFQLw3+rKM6FuK45R+zhnR1ZRqVECEqCkBWoF8srKKMW/kDkRzrQ/TUpc1iE5HOP2KBRoomUT8kLqZpOfhst94f3IS4DOUwqsfsBa3uUX3DLkfyc0ofl1oMzkNvB5jwqhQ/hreLCiRRzOQoBRdajV58k8tIll8p2gSGvWW12QurtEFsQ3dJad3afK9cGfZ5TutkUZRH67MFJHHdrdCRn5rhCylkumgLto0yJmN7ciapDeMa3OPQ8UlhdR6bxcyiDM8ZooQkW2RA6+YuDFxOCbUzS3fT6yy2FtExiFObmETIPzC1DlZuAFAArpnDh1SvC3ME1H8DyNTMd8TB2CUnxG9jVZ0+LO/VfX4GN/TPng8BaWaFEJfOcyFV1mGEIfHaPDg/Suf0lFFgYfNh7UYYIY4s8M+/6xaL0XMUAxPQigQFUUFkY0gJVvnQk79On2aVqUTAOincjVdtYLhdjaVph6HZWQpx7vM88utBeSMAsyMzKVMH7txQKfFkesuoRRgr/fZ7ziBClSLwntttBvd+5jsn10l2Oxtfb1HL1BmirVm+nHO0DCvueqbzMBV1lr0QYtaI0SjaX3igTtDfR2IUlN7dff6AzHCd0il8LWS9LbCWnUaQivLi6etwzUPAA/OGP61kAT1lmMIIujAopielJfFP6+Mq9gcRPB2pifut54uCEapdKudv0+UBK0Fy7HQ1gVBIZ5+2sUjD05XYXQ88wh/fVYJmXX3eatw5erOgKNmzwrO8SGnnUPDpmtIL+AtS/eLclXI2r+AQXraP+RgQd31suxS1e3g6zG4C95Uyidg+/XJvmrsXcfRUpkRoSBTY93u/K1gDZ+eMak4ZFBUVW3gWvb3JbO6ubf7yJ+fz2bGEK/vNjN4e+9mxh2ZXRdv2RYBuSIivdWt4349mjNu7DU8QDSAizRt/off3cp7ABc4Bn8gE+4ZCHmMQ2IkPsPKoP3yHMibCQ7K0pYZQGr+7FWJ3YTGAEnSkdl41Rke7ruQfbPlXiUyi+1rMVATLzIpSegBpBbdLXWevBAy/AidRUAoBuoKATicQ0AZd6JySK15QzzgLyOdoytFZMRLNjdP4V5EepFLTAIUPgQ69YspiUEZXIAtCjckpTvhCqxX1i1js00y3PwxA8czgejq9CYH1HCc9SuhBgrAyU0T7Mx00tDgtu4NxZ5YGgvIxLA1gqGKBbQoRiDTv9Hnq3ia1668wn2xH22PPzX5ygXxc90qpfo910IY8kHJ8x/1fUJMwzioJUkbZMV89CXwR9eIuhvKnRNqUPXPojCYcdMblFsKAKcuwy3g723BX/nG0yaTdm9AyiFWRdIMLoN3/xJJPLcGbMQNfUXfGrHISRU/4UKN2SIuABoU/XkmjfY9/FgaWJwjLhF0Fv9lHQEnXJlMOiZQSWZdrvyqJqIQPpj3WcBIMprTZ745P135SNhzwFwgmosWklFQLzLDrx8P95nvmxfxgF1n5BQyRxgzj4riqyMth+rSH28QXiK+B4CKHPjDk+e6pgw4nBBWLZQZNUqzMy/5t4T6Ykc6TyxIzTIt163X30qJBbDwc6g6g/f+/YvBloPZjEsQuqmBi9cmHkSmaovwiqo2yz2YJ/wQaO0ssfSiWAgCLgX3EKO7IvQ2wo2Wx6VrIzLtFqrjycDI3OhEsB3pQuTxTKQ093F3c2kdP0nrfSn+9nRQDR+gWNtT3Obbud19H8MaCPMHTO6OBSRozsJzKzMy2N9R48BCTCgvhpFq2XAeoLAiv6l0g0TQVdBeL3ihih0rVP4Q5quMpGHo/4DxesO+nyzepfi3aXtfkLzOSulOrL1khR0UyskSTbohl3Iyybk3g4o4trZKlpHYNeANEsF1vUBAhXNt+HCPPHsrAS8Q00pKUbcVxUAcuAZlKJ56oRe0HB4H19CQVdvqbRHMoepQ9PR2/zCnBWJkKamDXY6CvEOEfS2Nn63esBxafSOU7jTcuETHMQbDbtRIvUPigYm1hLi9PXfJEUyoJdfn2tItU++8ZCH0TvHtivZp3Mzvre55aFzCovYIXTuPJfEwGAtgqv3ss9DAVGrd5ONNwnLPZzPCd3BMpnTcA9Qu4svZ9qW7dPilXpM8o0RUrdYrapcIYccwV74HBFv+XgqAjZULDdxetp4RiLak8vhF7q86QpU08OCYZYW/A9CNnlKuotCJxe61fiIAuSYH1vPdFKgBwdg7X3ZEIQd5nptwyGRr9T7/MJ51RB/p1Y8cLmksF/rmvb5bLyRGiuhCDNhT1yON8vR4bFBqDnR263zIbI3Ax1hPc5pmil0vJMelfmXfe/8SpOqYRR4pfXq3nXLPuYLnyy2gACrTnlL2jvH+XQIZtiAZFgGnlwF8vFON4HmHTW2yHNirU0GhmgbAkGmfYc6YkMzi1kS7X8TSypOh7+Bf5AKEmJAJdtsxHf3xKljFOs7p92LOBM+BuWubLEKW/LbSdfvNqhHycLFLY59l3gOCQ7eemdYFbbVHJ4CwoFnhefUdMVgrODYXYs/ayYFOfKyrijLYo7AzcPaO3cxq1mLouKe5dW2P9D5t2DuDFewz+u7Z1alfTJ5TNzycQkFK2JTMz2ENqojK+lwBZtQLWEqNWxURU8lrzwloLd38x69VtZDAMVQAULOGG1q7qUcAAds6oNK8/OnkldDYsgVW8y72RX1ZYcQscuG0P3jQA4KlbVWC0GBJW+1/PbegNg53KfOOHj/mUpp/eXBnDDgSmSZ2rW+nqUPYgwvjNU6BTmTwRaS+G+vX4OW2DTFx+mSfgkkGb6MefY5lS9Kn6NjcdVIZzq1J9x4LHFhjp9ubuqvkf4DZyRLMoAlpe3rdD3W9IxlMu6/gL2MwNb2QAflXLNN8Xyg3OUPi0qgkwjZCyllNsI8JEH5LDChX6BHQ6GOCnwnmC8lMh1zYP0auHB+DoDaF1Qw89TvY0ZMFWlPHy5BYPhsu8kRAFJ6IHojHE8OpcV1ncKBQcgtvgX5IIJdzlfYCYMLvk6AsUJJMS+S+NVZdchpWTCLQC0seJJIl9hL6tUhhyQ1s/Er1CCesIUfZREJnRbzsd5368dv7iJLML+eAgGQ5oJlh6jqlUF5tONi5FGJ4bPE/a8W6PbZcKAmIQ0AKct+nYfbolGF6v2fTOCdVxV8XTAHWy73vXqu/hMOXIa7LjxUmPG7+xQQKWQWOQAw6wGEOsw2CcJzFFmgRB7Tk+c5KHq2TCzif01/zcgSvKmRvplIE903oP2vN6a2K1gdwKQtXkPBU+Tzr9W7Pj6GGoSPK9kAAbkF/gI5TnKzWoUCex0F26LIRCTz3rWWwrXAgOUnrHp3SVd7+gopHSoasUoepLI3/iOZfUZOWua2rbRWg1KoG7XMRvYc0WD32Py49OLJsUBHpkqsdlpxN9KP51gy2kSKd/nN8LWRIggD2gWxT+jwbjvBhSz2yON4GgoBX5zR2UC97CATPuyrEI2Q9jCntXUYQY/1hBA7a/Ghdvl630lVSyJkhla1Ul8NdkHLKgNXwGSvoOtcQVST/hRByNdipJPlE3Zffu/qcupOQzJ6sB31Tm9Vn9RPWJ/U/U/5kmfhuktkLoZgVpVKzCXJbIS5RxatigYM8ahpkdKLFqtlMREJfNuAfJpgz9RhDZVyrvKOrJfjeY46QkZYbOtxo6MSnv6excp7ZgpZq1U5IjVIhYpxO6ITCZui1WJh9H7FheIEpAVQ1gQXQvmSi/zkaG8ukta6NcRzJsbJ1qzF5CFJwSmgJ9W2b1jxj+tqonv8R7nBqinIxPW6Hzeuty5N6pNwsed4EVOs7jgb9MgVRrsveqECEgTgByW2lvkcnz73Lfv5Ntjo12+SJjtAZkmgUBdRi1lAYVVGbOwApMWKkF9CFVCpXloU2lSFg1ZMwzcABbUo5vFVj0DJVwrgtqGLdMH4Hh7cVUtx71Xt7BvpbR54kHbbC2Sw/C1rFkm+EWbGUtnRTBoqMJny6JIiBT//dxwuY8Uy2qhoxJNL4fYs6GinHJIa+kI5zH844f53pJuzJMLtTCmJfn3GZLLHIIykPtcMw2XLMNBy8BTlOyjVdnS2O5jmZxM9TAi+0FxCAJmI7dHyDkCE5uhmvO1RVvoanHNNZYz08XREP1YH4B/o80VEtxPKiHK+R6+AXeZWC5ZJRd4RKfuuD4ap3WTR45uLmemRdOEikMc1eG6SlWdaQf+VThQbaHVNNfCWJBAU1EeJi1uaYyKokaLMrecMZhPgGsYYbhrIzQC3/Y4JzcdBMZSS0ZoQ6jQvTYBJy411IuTxqjZmt9oIwhvSYSO0+tTdEvuvwrlHc+Z5wrNh9efS5jFbWRuCH3BKwrb3NMrgMCaqUAnF+SCb683KYo+JXdA19ZqgQOT1k1ghOahYpP3ujI/H34RgUTF2g1lyY/v2kdHTwBpbf3TgVDQq0hsZtLGD6iZVZK02rNxT8+IYjDShVRhuDjrSoqwgDUEkqvB1J4SBY36luNNSA5d5hvR99z4VjANIVt8dOEPBCQ0TOInvOt5GrNetFKUPCOzmuun3VFoYmvaLDIFOo29MxAqhXj/Qjx/rMkj1VvV3JJWvOIYlALtyl5fNTKfPgygYp1NXzJdpvy+3c3r6E7uooXBR8HSroOzbOjXA4VmfDeLJrLDcUNKVgr2eNAWtVSr4909L4WYxTUNGIKRFJAzEbNBti6y/c0lk2ZyGQb3IF8eQ2YTwcI2RPczeT9gJEfOUNvejN+9T/GIgx30Rx7lHhCTy5dyLtooJ8+1BUCKH9blzyYRT1bX/Ce/T5hh3Z9Ujg2JZWSDn1TQY9ghq+/YGKlQRcywYManvS+K4tAm+c1EoKaLqTRsxcrWeelJMCP+zDnBDzzNxF4NmBfLdg56JG9XMQqw+ngDWhQwdV0ChAEZ23v88Mt+oqOrJmzLIoExz8LT4Pr38fcJo/Mv4AZh8qbwpkabzbfjmlcVNITyVNDa5U3gglYv1ttwcbjcjtHrO78jfttjbrNCARx90/7szIIJA72AV4mFE89h63LCYChDWjr8eIGtLGrX30dp21m293rl//ikWO+jxzIlgrlAPcIYU8leJV0KM3Vm7qnTovgJ10HA7SbkA39OKYjTq/jopceq7jUHiCdUyivjIUlvaFjbW/dKrC/5V/p37gvlUT3Q7g8Qh2I8e1fBVJxIhKPPW7eUkqNlgI2cdrPdfu6RuoCsiawi9GO24NUjnUABjv9fz/Lqn/R6Z71+9TGA0B1VXzL+YlLpmKuj2WmY/wOg0Z/N9xP8QYNBGtemVgpOBG4U8oBBhTGLGwP8CKrE5od/JkqPLXl81fMVak5UGKu5L/LElqkFPPcIyZ657sMYKuqus0/tx2vMUUbY9pfSyw/DT79oxeebEHewTjeym3e8QX0loyc3UooI20sc7/y5pu4WNXvYN8BfSGS4MTtIDhySw+64k/9F+WZRw1I4cqZlCnHAiEAtZbC2To+9NDFGzbacMtDkqgAJlw4/YThUqumpqH4o0irtkXhhqZ1qKHkNA07ZdI8mJxUydSr4/5hSo82tZCdGxXm8jiwg5bO2kzJxnqa9FE4lVOy2VAyrunu3mOi9uVSNgNB2miANQjR/1xelY0yFY3rx+W61gpRWrpmKTeCAOeLjsmDDpTgdkiy9yOI6KMAuNrb0YNvZeieJEpjcpX+MdobAzgYBGnJ57Rm5LP/8upoOliceWYN1Z+6EmUbI/CeRtcoloU7Oi0kRzf06fRPpuzUrqs/K10I9HmHro1bzobjE1jntTIGkzF4hVxy2QfzjqrcyHifzE++Opwpqa1VpGUsPF89ZzWujFVBrFctRmmjw1GoACOdJ+SEh2QPFZCO38SXLlstWCr3uoYYgPROIxA0pLljK0GoDwKRhZX0fiKTIofUwRSioaZffDHEA/KjJcnYpj+IX1sVQ2obrMN5uNVTdSe567kVpVZ/Ldo5LM588XkhN3HMr1jTDpOzE2/eup2hmNf0ymN+Ghfe43mY0LZMLeI/+Y4Nt7l+8S6Acf5E71nAiv8SjhCk6t5RBSlCRJhE20+KVJAIEy7A13qDVGfDFRgy+L2i1l56W+SuXtJmxYRzjN8GJsV4DsCaaFjyZJaYn4IKC5I+xtw2zrJt0nQoaAYhlPhaQPJfLaXqfr5A6sHQFevjTET/Scp9RqHplcd932JA==
RESP: CAIS6AIKIAoQf4W5k0axNce4/MDsVitINhII2glvUpoBk9cgASgAEhYIARAAGAAoADD/6A84AEIASABQAFgAGlYKEI++yWxMlUE5rt1jPZISN4ISEPdEN5FWTPjFIHFyp6AonH8aIOdcCTe9kU3kgSBfoVOc+yM4H7tCYsa+GW5TiqqdvRRzIAIoATICCAA6BggBECogABpyChCv14pokutKW6rH7ZlF5YQVEhAKKW7YLWp+F4p1Q8TcwcGWGiAJQf0Wq0Vu38J451Ufae3SrFwVIitr87VO9EbDEFvwYSACKAIyAggAOgYIARAqIABSCggAEL/eHxoCCABSDgjA3h8Q/////w8aAggBGlYKELdw1bS7a1lNr5hYRarpql8SEGDmtESrla46LD5CQaNfvUcaIO9aT9gwRQxjgTX+SZ58+mAE3fbqU6KCTAazGudj9AcfIAIoATICCAE6BggBECogACDgiePhBTgAUAIaIC7gttm1ojGfqfncoxtBx+CDdTN/gfsHjFADHk2Ej64TIoACR5fRCU12Y+mGNMLaAXAJEVL7YOpMXOVeH1eqWgpXJtfgRbl9L8fITgPYuO05zc1GMKn+9R00E14MY1SSNwBde8aiF+WkAkvTHR6YIff1n17PDCKFG8fr0KXMgVCtJb6bYspto7ITfq+6wE4L/NuS+IleHr5ZKFZHAYRTM7jAeW9SbBxa2/LsUtPJP9+UdN1erkquRBhaLNe2RHnuWDF12USge0cI5sHAZLdk8j82FzFcZHrfux/nv6RSsVH5up0pSxfBzKF4qd99a9AxnyX2G8l+atNW606EisDBPtNrwhb5jW7VJ6UVa8n2Rg11W03nT7oUW3JQtPhb/+XtgoXR+A==
{
	"id":{
		"requestId":"f4W5k0axNce4/MDsVitINg==",
		"sessionId":"2glvUpoBk9c=",
		"type":"STREAMING",
		"version":0
	},
	"policy":{
		"canPlay":true,
		"canPersist":false,
		"canRenew":false,
		"playbackDurationSeconds":"0",
		"licenseDurationSeconds":"259199",
		"renewalRecoveryDurationSeconds":"0",
		"renewalServerUrl":"",
		"renewalDelaySeconds":"0",
		"renewalRetryIntervalSeconds":"0",
		"renewWithUsage":false
	},
	"key":[{
		"id":"j77JbEyVQTmu3WM9khI3gg==",
		"iv":"90Q3kVZM+MUgcXKnoCicfw==",
		"type":"CONTENT",
		"level":"SW_SECURE_CRYPTO",
		"requiredProtection":{
			"hdcp":"HDCP_NONE"
		},
		"requestedProtection":{
			"hdcp":"HDCP_V1",
			"cgmsFlags":"CGMS_NONE",
			"disableAnalogOutput":false
		}
	},{
		"id":"r9eKaJLrSluqx+2ZReWEFQ==",
		"iv":"Cilu2C1qfheKdUPE3MHBlg==",
		"type":"CONTENT",
		"level":"SW_SECURE_DECODE",
		"requiredProtection":{
			"hdcp":"HDCP_NONE"
		},
		"requestedProtection":{
			"hdcp":"HDCP_V1",
			"cgmsFlags":"CGMS_NONE",
			"disableAnalogOutput":false
		},
		"videoResolutionConstraints":[{
			"minResolutionPixels":0,
			"maxResolutionPixels":519999,
			"requiredProtection":{
				"hdcp":"HDCP_NONE"
			}
		},{
			"minResolutionPixels":520000,
			"maxResolutionPixels":4294967295,
			"requiredProtection":{
				"hdcp":"HDCP_V1"
			}
		}]
	},{
		"id":"t3DVtLtrWU2vmFhFqumqXw==",
		"iv":"YOa0RKuVrjosPkJBo1+9Rw==",
		"type":"CONTENT",
		"level":"SW_SECURE_CRYPTO",
		"requiredProtection":{
			"hdcp":"HDCP_V1"
		},
		"requestedProtection":{
			"hdcp":"HDCP_V1",
			"cgmsFlags":"CGMS_NONE",
			"disableAnalogOutput":false
		}
	}],
	"licenseStartTime":"1547224288",
	"protectionScheme":0,
	"platformVerificationStatus":"PLATFORM_SOFTWARE_VERIFIED"
}

Unsigned Firefox build:

RQST: CAEShwwKhwsIARLrCQquAggCEhClyhWoPPCtgXQVfBFcDxnYGI22zdcFIo4CMIIBCgKCAQEA2DxCBE3/fBHAY5ifNYsmscwz87WfTDSXioACDSOb/rRr8L9RgfFFe/+3N0LOyiPPcwxHPwkzozwOPD1Qu3Edh+cobj3Pk7z+xjqi31hg/9ZIUB2suiSSz5ReLbv6MmlLYC01rUxqiGMGTfnjFlu19mcI4ckd0CivfrMXwW61ExZ4vlcQyTqX4TaiqcCM2n/bU9SL0YPSik87yDMszizz5MeaWgavJr9c3bU58W/7bN9SE4ZzosVYYzK8aMy6TXayI2HJ/i/zAdClYaJYL2ARGQqcNqhHSlPVabDb72O/xbPHpquT+LG6n0KkSOC6H2P+XQJS3mhfEODmq3IFCXUHHQIDAQABKOI7EoACj1gIxEnhc/5Bv/QfqsL/UAlTju0ie5Wjiw4RQ8lolRQ6xqOw3rOuQm60ALRFyr2e8NlKM/5u6hwYw1VOvbtg3jH53cB+PSOC16XyleELU9tWAXLiNR5TH0XMipgBQpxesUVBdcY4LTy5ZCuxwYfSmZ3x8fqS584uCCEoWqPx/+YUeUJb4VMdqyTd6EgRFp70mFgb83TE3W4wb1LSuLfuZQuqZgeaB6x+7T4HlgGW7GjQotAaeHYzk7cxjSEZDscXQRsh3/puNohVfkO0mx/ul/fYyQGwfT3WXW7Ee7cb7h0IJACZ5m1tjOmjmIGM/yuBiaR+KHJzEffcTkUVAC7mzBq0BQquAggBEhBTPD046AWb9VpLdNIONjAuGPyC5MsFIo4CMIIBCgKCAQEAwsB00VQL7FwCYFJ3VD7Ryj1sWtAIE4fd3B7SoLtxnZyquZUBqPNMSw3dBGACTXX56o/GO/7swFvgUlBcHuZmYxlR+fSgPZXsdqw9XsHQeQcWss+N3IwNDSKBD3hpFEEYNu4t1ZEAxoSsEr5WPFfeqgpfag6MqaRVmkD0bmGi3yCjvtg0tMwFQf2BOAAha/gTZ7N0KxFrIDcX8GUQiUUKI4l/4cvJwMOXDVNPXThvJk8GI2tpikMfApPwD+tCb6R6EfSeYt9rY0d5b2xRf5n6jx0TfzNsMz/MLxu5B9EGquvTkCWt6pJTi3uYrRG2ri7NqtGzhqPJ7VnFGW9CGJw54QIDAQABKOI7EoADcR7dmMcXcyCMLxGbm71P7EI4BmVShv3wUuLRTNDFFbSp8RhCLCXCxQnh+Gx4AnFewHTCGxqVzLfEukL5YG/sZCyNXxmjBjRqXIABumjUUZjTNjMHus6g8h1dMmQHc7e8Twi7TeYk7XLdmzB9OZZ0VC+sSmoWyh5M+psdzOTiGmHtjFVwiKpPbX6ceaqgi/XMDk3wz/V6TgfjbLJgn4aCRFXA7/5ow9Cez/pFygkK9+/DkIgC2fo4uQ9uLWnuhs8cm46yb87+y8wcrEETXuvsIS90pnjpvc094UzuY6T4e0ACql+zf/P0Cqdu+ZEZTjQpXuVgSZpdDfNoG6Z9EMlP6yz5D1uTEyCyvsYzIA1cFwE69rcUCH6EJ4+LYf2pl+9cmXUKbiBeUrCAfdK82ih+xaEYsTNBI1biUd1WPy0kzOVCA/4HeN7XfmDsAa/4XGod2IxDXXjWcLKPNllv6RGYIlvMKcDSquElyS9kVKr12Zz7+dvh0zjq9R2Y5xsSN7VUGhsKEWFyY2hpdGVjdHVyZV9uYW1lEgZ4ODYtMzIaFgoMY29tcGFueV9uYW1lEgZHb29nbGUaFwoKbW9kZWxfbmFtZRIJQ2hyb21lQ0RNGhgKDXBsYXRmb3JtX25hbWUSB1dpbmRvd3MaIwoUd2lkZXZpbmVfY2RtX3ZlcnNpb24SCzQuMTAuMTE0Ni4wMggIABAAGAEgARJxCm8KWQgBEhCPvslsTJVBOa7dYz2SEjeCGgZhbWF6b24iNWNpZDpqNzdKYkV5VlFUbXUzV005a2hJM2dnPT0scjllS2FKTHJTbHVxeCsyWlJlV0VGUT09KgJTRDIAEAEaEGmF60CJUlos6PvdoxlOJVIYASC9xvzhBTAVGoACaCDPuJ86j9hRgQ0whPkdEKkVLycD+dcEkqQZcd2/bw3ODjtvXLZSGyc+3vvSFtegC/Pf4ND1qTFwiahPR9deEcZGrIPDDgunG2bZqHEpelZa3YFTCS99vWcTqTybzXCPJpVGb39rhp0P7+t3vH+Hch9xK5FY+3m3k4onkIKjOx+3J9MJtnAqv8KfYI4G3d8jWs4qN79IhYyQUeOUgVKJfqkYTuAXHj+7Uc/DanHbZ86Ue2H9HyWUki2zEaHdfsrchDqawH47uoD5LVtHqz3osTsXk+rm2PhLWq2Ag55upK6B1H41hSIgATaibQbw1CZuuXPEfly1l2WyI+YOUKoOHA==
RESP: CAIS6AIKIAoQaYXrQIlSWizo+92jGU4lUhIIq+u7I0FAfMcgASgAEhYIARAAGAAoADD/6A84AEIASABQAFgAGlYKEI++yWxMlUE5rt1jPZISN4ISENvl6xktnffotxlU7BeBMt4aIMDg+x1P+zedOr9n6fjjq2Punlta3Geyt7w26HU7QSHLIAIoATICCAA6BggBECogABpyChCv14pokutKW6rH7ZlF5YQVEhC2Y2POhRWvJ03ztCS2e2O0GiAXN2qI4vgdS91jk4vAYTje4+uPSLUfyObiZ3YDR4diACACKAIyAggAOgYIARAqIABSCggAEL/eHxoCCABSDgjA3h8Q/////w8aAggBGlYKELdw1bS7a1lNr5hYRarpql8SEPAQ1CRDPmLgXw3hZ1xDemwaIBqUQtDtHZr9M0+Fj0fq0eTQ3Q3UgMockMW/izniT7lSIAIoATICCAE6BggBECogACC9xvzhBTgAUAAaIJFRnnXysNrN5gpot+zZ/CcmIViRjlADWJnBI0zFWFocIoACbko1gWM70eGvMAtHltWQPd8q1PFP5xpOgI8DLttlxiXYWzDY3brDduagJWPt1ygBhIs/xNA9Fbsi9Vm3+g+/U773Jc0QDt0WpTV26xZG5NugCIti7ySVkUfYr7WKVfuJ3TvgVC5hPqmYF749eTNRsxljUYvXU6QUUMGMAlMzIp7AsPAwRIpVaARijjv3rKhavfPjC6ChgnGNsw6HVrxEyqBSnKe82TR1XNUfk2mLgeBZfpRji+cCeDzCm4n/sT7E+Yqm8ozUVfbQyGBbZTpukl+tXXIvDY2MYyvjblulrdYxYqNVCPnLyW0p+LGDD4xXbEcNqlgmIlvk4Kn6VH4o8g==
{
	"id":{
		"requestId":"aYXrQIlSWizo+92jGU4lUg==",
		"sessionId":"q+u7I0FAfMc=",
		"type":"STREAMING",
		"version":0
	},
	"policy":{
		"canPlay":true,
		"canPersist":false,
		"canRenew":false,
		"playbackDurationSeconds":"0",
		"licenseDurationSeconds":"259199",
		"renewalRecoveryDurationSeconds":"0",
		"renewalServerUrl":"",
		"renewalDelaySeconds":"0",
		"renewalRetryIntervalSeconds":"0",
		"renewWithUsage":false
	},
	"key":[{
		"id":"j77JbEyVQTmu3WM9khI3gg==",
		"iv":"2+XrGS2d9+i3GVTsF4Ey3g==",
		"type":"CONTENT",
		"level":"SW_SECURE_CRYPTO",
		"requiredProtection":{
			"hdcp":"HDCP_NONE"
		},
		"requestedProtection":{
			"hdcp":"HDCP_V1",
			"cgmsFlags":"CGMS_NONE",
			"disableAnalogOutput":false
		}
	},{
		"id":"r9eKaJLrSluqx+2ZReWEFQ==",
		"iv":"tmNjzoUVrydN87QktntjtA==",
		"type":"CONTENT",
		"level":"SW_SECURE_DECODE",
		"requiredProtection":{
			"hdcp":"HDCP_NONE"
		},
		"requestedProtection":{
			"hdcp":"HDCP_V1",
			"cgmsFlags":"CGMS_NONE",
			"disableAnalogOutput":false
		},
		"videoResolutionConstraints":[{
			"minResolutionPixels":0,
			"maxResolutionPixels":519999,
			"requiredProtection":{
				"hdcp":"HDCP_NONE"
			}
		},{
			"minResolutionPixels":520000,
			"maxResolutionPixels":4294967295,
			"requiredProtection":{
				"hdcp":"HDCP_V1"
			}
		}]
	},{
		"id":"t3DVtLtrWU2vmFhFqumqXw==",
		"iv":"8BDUJEM+YuBfDeFnXEN6bA==",
		"type":"CONTENT",
		"level":"SW_SECURE_CRYPTO",
		"requiredProtection":{
			"hdcp":"HDCP_V1"
		},
		"requestedProtection":{
			"hdcp":"HDCP_V1",
			"cgmsFlags":"CGMS_NONE",
			"disableAnalogOutput":false
		}
	}],
	"licenseStartTime":"1547641661",
	"protectionScheme":0,
	"platformVerificationStatus":"PLATFORM_UNVERIFIED"
}

Kodi with the Inputstream.Helper downloaded Widevine CDM:

RQST: CAEShgwKhgsIARLrCQquAggCEhAZj62gkJOXXXaMFkjqJD0tGNqb5MsFIo4CMIIBCgKCAQEA5ErxleIO2jsTG/3iGdvRLuL/EU73oLS+dGCvrSXynYRgOCo8uXkrIgoPZ0kCWK3JIcoUezix7w8yC2W5AmbyJ/af9Nq1Tyj8lMAIj14RWioXCAOxo+nH0wcz3lXQ9xdnLDCyO32Q2ieSR6ztFfn7f3U0FqOMkXloUKQhGTeqskuIz1PS8oIPVdgLQuASseQfSF8joOo4el64pAu70nGq0mxQhPWqxbVmSmwK6ll1hERLwRqeWaeWvWl+BsmPBATzvvCzavyP/INLd0jk25tYwB8fdskUTGa4EsEy1/m1jbYHKYV0KyPJ4HhceITPeRc7yEfLurwfsZxB3mcjxP9PCQIDAQABKOI7EoACgLrYCAjdgUp4LCRVy8bDxl/UL2YW91D7VTCMOmCpfRYShnBSgNJ7Lyl/ZPWwmo0Um4kbt3/j0gHh6c0w8S2mFE/cE9J9O4L7ud4YgdDInh6LRzvlJ0XGt6c8uxY05Cp85C+VLp7HW9WIGL4S3MhT5jQkfPSOiKCNEC5gtaUmFdrNNMvXUH3OSyX68r+IXs3eBsyBV1mSdJYfFqHyB8zWAX4RWghgEhWVL8TQ2o4Ahji7vSvbrZydZsSA8mswIvfpL3AN+iD+Dc9090DObj5hNIyBA9vEIbCNENPpTLSvBb1eaH7XQG7Z2SvPofDBO8h8RD5ewQfRF/kgidgkhVT2Uhq0BQquAggBEhBTPD046AWb9VpLdNIONjAuGPyC5MsFIo4CMIIBCgKCAQEAwsB00VQL7FwCYFJ3VD7Ryj1sWtAIE4fd3B7SoLtxnZyquZUBqPNMSw3dBGACTXX56o/GO/7swFvgUlBcHuZmYxlR+fSgPZXsdqw9XsHQeQcWss+N3IwNDSKBD3hpFEEYNu4t1ZEAxoSsEr5WPFfeqgpfag6MqaRVmkD0bmGi3yCjvtg0tMwFQf2BOAAha/gTZ7N0KxFrIDcX8GUQiUUKI4l/4cvJwMOXDVNPXThvJk8GI2tpikMfApPwD+tCb6R6EfSeYt9rY0d5b2xRf5n6jx0TfzNsMz/MLxu5B9EGquvTkCWt6pJTi3uYrRG2ri7NqtGzhqPJ7VnFGW9CGJw54QIDAQABKOI7EoADcR7dmMcXcyCMLxGbm71P7EI4BmVShv3wUuLRTNDFFbSp8RhCLCXCxQnh+Gx4AnFewHTCGxqVzLfEukL5YG/sZCyNXxmjBjRqXIABumjUUZjTNjMHus6g8h1dMmQHc7e8Twi7TeYk7XLdmzB9OZZ0VC+sSmoWyh5M+psdzOTiGmHtjFVwiKpPbX6ceaqgi/XMDk3wz/V6TgfjbLJgn4aCRFXA7/5ow9Cez/pFygkK9+/DkIgC2fo4uQ9uLWnuhs8cm46yb87+y8wcrEETXuvsIS90pnjpvc094UzuY6T4e0ACql+zf/P0Cqdu+ZEZTjQpXuVgSZpdDfNoG6Z9EMlP6yz5D1uTEyCyvsYzIA1cFwE69rcUCH6EJ4+LYf2pl+9cmXUKbiBeUrCAfdK82ih+xaEYsTNBI1biUd1WPy0kzOVCA/4HeN7XfmDsAa/4XGod2IxDXXjWcLKPNllv6RGYIlvMKcDSquElyS9kVKr12Zz7+dvh0zjq9R2Y5xsSN7VUGhsKEWFyY2hpdGVjdHVyZV9uYW1lEgZ4ODYtNjQaFgoMY29tcGFueV9uYW1lEgZHb29nbGUaFwoKbW9kZWxfbmFtZRIJQ2hyb21lQ0RNGhgKDXBsYXRmb3JtX25hbWUSB1dpbmRvd3MaIgoUd2lkZXZpbmVfY2RtX3ZlcnNpb24SCjEuNC45LjEwODgyCAgAEAAYASABEnEKbwpZCAESEK/XimiS60pbqsftmUXlhBUaBmFtYXpvbiI1Y2lkOmo3N0piRXlWUVRtdTNXTTlraEkzZ2c9PSxyOWVLYUpMclNsdXF4KzJaUmVXRUZRPT0qAlNEMgAQARoQxMIPzM1DVYbcWcWT4/zW/hgBIOPJ/OEFMBUagAKSwtuGZVmOGzgRiXICnGHXVNPZsoZgtMiOGL5hMCJDOOwMHDjsFj53XWCAxFazGG2qdU4muV9urUFSsPaSQuaiqwMLtm8xIkhKLjYrvEesHwkBcW9YmciUczwOii0KbSTQVFom1Fi+YIzt1vwsWfbxcx3UtzhwIPE1cwQCg8KnsmOFSjMkUI+k9BEUMfjnPccnHABeSZDwss7ehLksWBd2jbQkwRFvA3HyIjv4318jOKqhYNKR8g0otTDzH+tchruEaOcOVrzXVyQLrutlDwVZrn67yF63tcRb5gO2ok5+FKeD85Xtz69yG3hx6y6uaMf0O1Iuzkp3z3pjyNImKVBD
RESP: CAIS6AIKIAoQxMIPzM1DVYbcWcWT4/zW/hIIeMIpKZHlIUggASgAEhYIARAAGAAoADD/6A84AEIASABQAFgAGlYKEI++yWxMlUE5rt1jPZISN4ISEK4riVmZJPz8Ezd55h9l+UoaICMYjht43KF+Uc2nyQdHyYfW0Dc32FfE/MjoS8ar0qbRIAIoATICCAA6BggBECogABpyChCv14pokutKW6rH7ZlF5YQVEhD0L/upmCD1EBnVHV1YVws/GiBXypDlOLWp3vgX9YSBk7eQzGrQVIqBFxY6YcLIR3k9EiACKAIyAggAOgYIARAqIABSCggAEL/eHxoCCABSDgjA3h8Q/////w8aAggBGlYKELdw1bS7a1lNr5hYRarpql8SEOAAd25HPZbmU2iT6PazDo4aIAmvERqRB1hBO9lXW91Sawd4IpGH+ffOUpXgk1fv8a8NIAIoATICCAE6BggBECogACDjyfzhBTgAUAAaIL//zXVVCezRgHISSQBbyI/EbE8l+JqxviYsLK/cNVIGIoACBiPpHmeZ2hiv4BO18uay0awVDmviq77oTqgHBRN/cBSLTh5Z6CKPiq2OX/p1H2wDpI3FF7wTLBLmWTe5edafwZijtST7HT4RZI332lau+EYk3S75WC7q+mxvB6/xWSP2aL76T5uTlHFbVL8/nx5V07cbMgki6XIeG9iLzD7Yet1MP8eAOj4lkQC43DJaHCDNxb5NKfVfRwexmhr/OAw3hi/YtGkxb4I8+hUSEA1mJ/7NsgRBHUwsYTUV4wL18JrnHSaQGlMAaT0/OuinwUTbzbdIjGvUGAi6Lo3vNRgHVtST5koFscumf0XvJj9Q5RIixia27zlKofBeVWBhVUfvHQ==
{
	"id":{
		"requestId":"xMIPzM1DVYbcWcWT4/zW/g==",
		"sessionId":"eMIpKZHlIUg=",
		"type":"STREAMING",
		"version":0
	},
	"policy":{
		"canPlay":true,
		"canPersist":false,
		"canRenew":false,
		"playbackDurationSeconds":"0",
		"licenseDurationSeconds":"259199",
		"renewalRecoveryDurationSeconds":"0",
		"renewalServerUrl":"",
		"renewalDelaySeconds":"0",
		"renewalRetryIntervalSeconds":"0",
		"renewWithUsage":false
	},
	"key":[{
		"id":"j77JbEyVQTmu3WM9khI3gg==",
		"iv":"riuJWZkk/PwTN3nmH2X5Sg==",
		"type":"CONTENT",
		"level":"SW_SECURE_CRYPTO",
		"requiredProtection":{
			"hdcp":"HDCP_NONE"
		},
		"requestedProtection":{
			"hdcp":"HDCP_V1",
			"cgmsFlags":"CGMS_NONE",
			"disableAnalogOutput":false
		}
	},{
		"id":"r9eKaJLrSluqx+2ZReWEFQ==",
		"iv":"9C/7qZgg9RAZ1R1dWFcLPw==",
		"type":"CONTENT",
		"level":"SW_SECURE_DECODE",
		"requiredProtection":{
			"hdcp":"HDCP_NONE"
		},
		"requestedProtection":{
			"hdcp":"HDCP_V1",
			"cgmsFlags":"CGMS_NONE",
			"disableAnalogOutput":false
		},
		"videoResolutionConstraints":[{
			"minResolutionPixels":0,
			"maxResolutionPixels":519999,
			"requiredProtection":{
				"hdcp":"HDCP_NONE"
			}
		},{
			"minResolutionPixels":520000,
			"maxResolutionPixels":4294967295,
			"requiredProtection":{
				"hdcp":"HDCP_V1"
			}
		}]
	},{
		"id":"t3DVtLtrWU2vmFhFqumqXw==",
		"iv":"4AB3bkc9luZTaJPo9rMOjg==",
		"type":"CONTENT",
		"level":"SW_SECURE_CRYPTO",
		"requiredProtection":{
			"hdcp":"HDCP_V1"
		},
		"requestedProtection":{
			"hdcp":"HDCP_V1",
			"cgmsFlags":"CGMS_NONE",
			"disableAnalogOutput":false
		}
	}],
	"licenseStartTime":"1547642083",
	"protectionScheme":0,
	"platformVerificationStatus":"PLATFORM_UNVERIFIED"
}

from xbmc.

Don't worry, there's no difference between PlayReady & Widevine streams, the keys are shared, the DRM is just responsible for key exchange and protection.

The Playready part is discarded, the PSSH format is something like this:

int32 size
int32 magic ('pssh')
int32 ???? (padding maybe)
uuid schemeId (widevine is edef8ba9-79d6-4ace-a3c8-27dcd51d21ed, playready is 9a04f079-9840-4286-ab92-e65be0885f95)
int32 size of init_data
rest is init_data

If you're curious whats actually in the init data for Widevine itself, I believe the protobuf's in one of the 20 widevine pdfs you linked above, actually..

algorithm: AESCTR
key_id: "\257\327\212h\222\353J[\252\307\355\231E\345\204\025"
provider: "amazon"
content_id: "cid:j77JbEyVQTmu3WM9khI3gg==,r9eKaJLrSluqx+2ZReWEFQ=="
track_type_deprecated: "SD"
policy: ""

For what it concerns the CAQ= request, both the signed and unsigned Firefox have roughly the same Widevine proxy calls, except for the fact that after receiving the init data, the signed Firefox requests the CAQ=, while the unsigned doesn't.

Yes, privacy mode is enabled probably due to VMP being enabled, so it has to request the service certificate to encrypt the client ID.

from xbmc.

Yeah, those were pretty much my conclusions as well, but was worth the time to actually check. Given that the service certificate isn't needed after all, the only question which comes to mind (disregarding the questions whose answers would see the need to break the WidevineCDM.dll protection for the sake of doing it) is how does Firefox create the "hardware proxy" (I think that's how it's called, internally) that allows video reproduction even with recompiled sources. If we could figure that out and re-implement it in IS.A, we're golden.

from xbmc.

I'm sorry, I don't understand what hardware proxy you mean?

In one of the sources (possibly Firefox?) there was code relative to (roughly) WidevineCDM Proxy with some sort of "secure context for Intel", or something of the sort. If I'm correct that's the code to enable HDCP secure context for Widevine to reproduce the video into. Going off the top of my head, so take everything with a grain of salt.

@Varstahl if you have played the same movie, pssh initdata should not vary.

From my logs, pointing at the same video, the "total" bytestream passed changes each and every time, with each and every request. I need some serious sleep so I didn't really look into it too much, but I can assure you that I can provide at least half a dozen of "init data" that each change slightly between themselves. What doesn't change is the init_data of Widevine's PSSH.

Lol, please. Bruno is already going crazy for HD. Put 4K aside for the moment.

Q_Q
Wish I kept up with my reverse engineering challenges. My old brain's exploding :D

:-) yes, @Varstahl should try to limit web browser to smaller resolution (best possible same as used in kodi)

All the platforms try to reproduce the same movie with an upper limit of 1080p. Not that it matters until we fix HDCP, but yeah.

1.) pssh initdata differs because the GetPlaybackRecource request / other session things are invalid.

The binary blob differs, the widevine initdata field inside the PSSH doesn't at least in my small tests.

IIRC there is a calling home loop in amazon which tells amazon secrets about the current device (??)

There is a query somewhere that takes device capabilities, I don't remember the endpoint atm though.

VMP is detected via file access

Couldn't you hook/load some whatever big enough subset of signed dlls to get VMP working though?

The file access that you're detecting is probably checking for .sig files. In order for VMP to work while using Kodi + ChromeCDM you'd need a signature file for at the very least the Kodi exe itself which is impossible to get.

If I understood what he meant then yes, it's probably the bundle of signature files.

D/GMP AnswerStartPlugin CDM host paths=(…\widevinecdm.dll,…\widevinecdm.dll.sig),
                                       (…\plugin-container.exe,…\plugin-container.exe.sig),
                                       (…\firefox.exe,…\firefox.exe.sig),
                                       (…\xul.dll,…\xul.dll.sig)

So, without having the dll reversed (but with a "that's what I'd do" mentality), when the WidevineCDM is loaded, it start looking up its parents(/siblings?), Firefox.exe, xul.dll, plugin-container.exe and of course itself. Each of them must be signed (the PGP .sig you find along with the executables), and the results of the checks (or the signature bundle, or whatever it is) is sent somewhere.

So, to enable VMP, one would either crack WidevineCDM open or do some esoteric stuff, such as loading Firefox as a hidden window, inject a DLL through one of the undetectable methods (there are plenty), and then proxy the Widevine calls between the two applications. It's really stupid though, especially since it's useless in this context.

Anyway I don't know if Netflix enforces it, but presumably they don't, if the kodi plugin works on desktop.

I've studied Netflix a bit (passively, I don't have a Netflix account), but as far as I can tell they have an easily accessible endpoint, with none of the problems Amazon streams has. And we're still having it good, because I read Google's "recommended settings" for Widevine encryption and it made me shiver (L1 for freakin' 720p? Are you kidding me?)

from xbmc.

No, some years ago this parameter displayed the HD content. To get UHD content listed, you have to use the HideNum=F parameter.
But it makes no sense, because the devicetypeID that is used for playback doesn't support UHD.

from xbmc.

Thanks for the response. Tried with HideNum=F and no luck. Any other hints? Maybe I need a valid devicetypeID that can actually supports UHD?

from xbmc.

Maybe for listing it, but not for playback.
You cannot change the playback devicetypeid, that's the only one which is currently working.

from xbmc.

Are there any news for uhd?

from xbmc.

@greystashh some android reverse engineering has probably to be done, but I didn't find the time yet.

from xbmc.

Have you been able to look at it in the meantime?

from xbmc.

Any updates? Just a side note, it looks like instantwatcher (which I believe has partner-level API access) only has 4 items listed as UltraHD (used to be a lot more) https://instantwatcher.com/a/search

from xbmc.

asciidisco/plugin.video.netflix#86 (comment)
https://www.amazon.com/gp/help/customer/display.html?nodeId=201648150
Ideas

EDIT: https://www.amazon.com/gp/help/customer/display.html?nodeId=201460880
this seems to cover way more devices (and even though it's still far from 100% comprehensive, at least it gets near to recognizing my XZ2 can access HDR)

from xbmc.

Yeah, one of my devices that I was targeting to reverse engineer the 4K video playback is on that amazon's support list. The problem that peak3d is describing is different though: it's not enough to "have" those in the lists, if you can't playback. And you can't reproduce those videos, without a full reverse engineering of the Widevine drm encryptions that is shipped in those devices, which is different from what is publicly available.

Short example: we have support for FHD movies in Amazon VOD, but nothing is able to reproduce them. If we can't playback FHD why bother with UHD?

It sucks, but that's Google for you.

from xbmc.

I thought that was just a matter of various WV levels..

from xbmc.

I'm not exactly "in the know", but when I talked with some devs (under NDA) they hinted at the fact that even for PrimeVideo.com, several chromium-based browsers are not able to decode properly videos, even when taking the Widevine straight from Chrome and putting it in the other browser, because along with the the DRM management they would need to ship with particular codecs, that all bundle for a fair amount of millions of dollars.

I admit I never even began reverse engineering my TV's handshake, but from what I understood even if we were to replicate and get both 4K and up to date Widevine from whatever source, chances are it will never ever be rendered to video. FHD decoding can maybe work on Windows 10, if what I heard is correct, but 4K probably won't on any platform.

from xbmc.

Ok, it's true that amazon's streaming "parameters" are bonkers, but for as much as codecs are concerned the only peculiarity should be the usage of H265. End. How could they get hw accelerated otherwise?
Nothing that isn't already handled by inputstream imho.

Then, as I was saying.. I know instead *DRM* is the thing pretty famous to be finicky.

I've spent all day trying to understand what particular kinds Prime Video have been using, but to no definitive avail.
Of course Widevine plays a role... With L3 being the minimum requirement to do *any thing at all*.
But then for some reason, computers can get away with 1080p easily, while on android not even L1 seems to be enough for 720p sometimes (though that could be as well some coarse device model check...).

Proceeding with the analysis, a breadcrumb trail, led me inside the android apk, whose biggest library is literally libAIVPlayReadyLicensing.so.

So, I was almost going to call it a day, they may be using the same super pesky hardware-baked thing of netflix (which in this case they aren't offering on x86, just out of laziness or whatever)
And it would also explain why a lot of android TVs are fine with it - since they are all reportedly required to support it (even though I couldn't find anything in the official documentation... which is really poor in documenting drm)

But I could only find PlayReady SL2000 certificates inside of com.amazon.avod.thirdpartyclient.apk\assets\PlayReady\.... Which is not actually the playready 3.0 I was theorizing about.
... and at that point I realized android TVs uses a completely different application (com.amazon.amazonvideo.livingroom).. Unfortunately protected AF, but that could still cover my hypothesis
....

Until the last blow arrived, when I eventually found out Xperia XZ Premium can actually do 4K with the normal app. On the "normal" android.
And even though its oreo firmware has a vendor\lib\qcdrm\playready\ folder... I know from both drminfo and exoplayer tests on its sibilings sony phones with the same board, that it always was inert.

So... TL;DR I'm back to square one.
FHD anywhere shouldn't be rocket science to be honest anyway.

p.s. when you'll eventually get to look into UHD titles, take also notice they are total asses with their interface/api.

from xbmc.

Also, thanks for the additional information, I had no idea that (at least on some platforms) Microsoft's PlayReady 3.0 was used. Which explains why Windows 10 is fucking required to play 4k.

* exhausted sigh *

from xbmc.

That's for netflix though, as I said.
Aside of this specific instance though, I know of no particular "merit" of W10 on anything.
(and, even then, there seems to be plenty of samples floating around for playback, at least under UWP...)

Then, if you want to work on the android app, I know there are plenty of xposed tools that can uncheck/unpin certs on the fly.
But at least for 1080p everything should be already more than doable on x86 alone.

from xbmc.

Seen? It wasn't that hard after all 🙃
(I wonder if hls is what the official applications use then, or if there's still even more to discover)

AVC1's just normal plain H.264 anyway...

from xbmc.

Seen? It wasn't that hard after all

To do what? Playback still doesn't work. Neither DASH nor HLS, MPD nor M3U8, AVC1 or not plays above 1088x464. And since I'm a complete noob when it comes to video streaming technologies, I have no idea how to analyze the issue.

I've just poked and prodded to solve a different problem, but we're nowhere near where we should be, for the moment.

Edit: ERROR: AddOnLog: InputStream Adaptive: DecodeVideo: kNoKey for key <KEY>
At least now we also have something to relate the problem to.

from xbmc.

@Varstahl Thanks for your investigation. I'm actually more interested in finding out WHAT is available in UltraHD vs. actually being able to play content in UHD (I'm a data geek). Are you able to get anything out of the API that shows UHD "possible" content? I've tried many device types to no avail ...

from xbmc.

The only surefire way is to:
A. Obtain a valid apk and reverse engineer that
B. Find if there's a possibility to sniff the traffic and reverse the protocol (generally this is my preferred route)

I've spent the past 8 hours setting up everything for a MitM attack, and I mostly succeded except for the fact that I came late to the party. Samsung has been bashed for insufficient security, and apprently they now took things ultra safely. I can sniff all the traffic no problem, but when it comes to HTTPS it has a reject by default policy, even in the browser. So, I either find a way to download/modify/sideload browser/amazon apks, or I need a way to inject a root certificate onto my TV.

It's now 4:30 am and I'm tired af, so I'm headed to bed.

Also, to elaborate better:

Are you able to get anything out of the API that shows UHD "possible" content?

Once upon a time @Sandmann79 found a way to do it for amazon.de, but several endpoints behaviour changed dramatically during the last few months. I don't think I can find out UHD streams with what I have at the moment. The only way would be to crack my damn TV open, but as far as the first attempt went, I fell short TLS. I can tcpdump and maybe bruteforce the TLS, but it's quite unrealistic.

Don't know, I'm sad, I'm going to bed.

Also, for added fun: Amazon removed the 4k section even on my freakin' 4k TV, listed as supported even on Amazon's website. Didn't test 4k content though, yet, so don't know about that. But even if I could previously find out of an URL API endpoint to discover 4k streams, now I just can't. Yay.

from xbmc.

https://blog.netspi.com/four-ways-bypass-android-ssl-verification-certificate-pinning/
https://techblog.mediaservice.net/wp-content/uploads/2017/10/HackInBo-2017-Winter-Edition-Federico-Dotta-Advanced-mobile-penetration-testing-with-Brida-141017.pdf#page=13

from xbmc.

Interesting, but Samsung 4k TVs run on Tizen. I can develop something for it and load it into the TV, but it's not Android. It's also a minimal distro, with no rooting possible (as of now). Also since I can't tell which are the endpoints for the samsung website, I'm not really able to download the package off the main repository, so even that didn't work out for me yet. Thanks for the reference though, I didn't know of Frida, that's an interesting read.

from xbmc.

XZ premium 4K compatibility broke with Pie, and it seemingly never had playready to begin with. amazon broke compatibility with standard android

So my last, definitive, eventual, guess is just that they are performing stupid server-side checks, and nothing more than L1 should be required.. "high-end-security" wise at least.

from xbmc.

I can tell you that they are doing a number of client/server side checks. Different codecs, lists, streams, and whatnot may or may not be displayed, and may or may not be served. Even with Widevine no more than L1 should be needed (for tv series at least), except that movies won't go higher than 480p (L3?). And since a lot of the checks and the "device" parameters are server/client side assessed, but in the most obscure way possible, I still can't find a way to wrap my head around the issue.

As far as HD movies go, Chrome is (possibly?) able to unlock the streams (I didn't actually check the stream contents yet so it might just pop up the HD and have a 480p quality, for all I know). But IS.A and most other browsers aren't able to decode them. Multiple Widevine licenses? I have no idea, and every time I see a change on Amazon's backend I die a little.

Hell, I'm even using Vivaldi on a daily basis, which is basically an "Opera" skin on top of the Blink/Webkit, and it still doesn't work. PrimeVideo on Vivaldi only works if you spoof the UA to match Opera, not even Chrome.

I have so many questions, and not enough answers… I just keep hating Amazon every day a little more.

from xbmc.

I get the "HD light" (whatever it might actually entail) on firefox on windows..
And as I reported above, if you spoof enough the user agent, even on android you can basically get the same.

So.. to be honest, now that we solved the 4K "standards" conundrum, I think the only mystery left is why (just like with netflix tbh) 720p/1080p requires L1, while on "desktops" you can get away with the lowest security level

from xbmc.

Soo, after a few tests:

1. fetched the server certificate through a CAQ= query, and embedded it into the request. No dice.
2. took away our version of the Widevine CDM and used the Firefox/Edge, only to see nothing. No dice.
3. tried to modify the Widevine queries, but even though the result seem equal and perfectly fine, no dice.
4. plenty of InputStream Adaptive: DecodeVideo: kNoKey for key <KEY1> or InputStream Adaptive: DecryptSampleData: Decrypt failed with error: 2 for key <KEY1/KEY2>
5. judging by the MPDs the video streams have the exact same properties, but they just won't decode (again, google being google?)

We're going from nothing gained to everything lost. I'm exhausted, out of ideas, and extremely unfamiliar with Widevine DRM, no matter how much I try to tackle this problem I get nowhere every time. Short of bombarding @peak3d with questions and mpds, I've tried mostly everything. I don't think analysing/re-compiling IS.A would get me any further anyway.

from xbmc.

(what's the difference between VOD and prime video?)
Aaanyway as I have kind of hinted in #217...... Maybe we'd all have better to wait for inputstream to handle its last woes.
Maybe check the last cookie PR they have there in the meantime idk..

from xbmc.

Just like every other DRM it's a game of cat and mouse. There's a lot of money at stake, I doubt we'll ever have a proper solution that will last long enough. Which is still pissing me off, because I now have TWO different .DLLs that are able to decrypt the content, but nothing that works with either of them.

I'm half tempted to download the damned firefox sources and see if there's anything I can reverse engineer to retro-fit into IS.A, Kodi, or whatever the hell would make it work.

from xbmc.

Lolwat. You aren't trying to crack it (fun fact)
You are just trying to play to its rules.. except amazon cannot get their shit stable together.

from xbmc.

Lolwat. You aren't trying to crack it

That's the theory, but then again what's the actuality of it? Like peak3d said, there are a number of hardware vendors (Google included) who have vested interests in keeping the most significant portions of the DRM out of public usage (buy our chromecast/pvr/whatever to see Netflix/Prime/YouTube in 4K!). Just like Google killed Edge, I've heard many reports of them throwing wrenches around.

I'm also fairly sure that what is going around Widevine is quite illegal, although it's slightly dressed up as "open" and "community friendly", whatever that means.

You are just trying to play to its rules.. except amazon cannot get their shit stable together.

Then let me ask you this, unless there are recent developments I'm not aware of, why is YouTube not working with high definition videos, using Widevine CDM? YouTube's owned by Google, and so is the Widevine DRM, and so is the Widevine CDM distribution. Then why doesn't it "work"?

Netflix's stuff is the only thing that works because they decided it should. Amazon seems to be using Google's suggested settings, and the world's suffering for it.

OH, but if you buy the 4k TV, or Google's Chromecast, or Amazon's Fireshtick or what have you, then everything suddenly works.

And if I'm to be true to myself, in all honesty, I don't even care for FHD or 4k. It's just that their keeping content locked up by blocking access to portions of implementation details makes me nauseous. And the more it goes on, the more it pisses me off.

I know this sounds quite the rant — because it is —, so let's cheer things up 🎉

from xbmc.

Throwing these for future reference:

• https://archive.mozilla.org/pub/firefox/releases/64.0.2/
• https://storage.googleapis.com/wvdocs/Widevine_DRM_Architecture_Overview.pdf
• https://storage.googleapis.com/wvdocs/Widevine_DRM_Proxy_Integration.pdf
• https://storage.googleapis.com/wvdocs/Widevine_DRM_Encryption_API.pdf
• https://storage.googleapis.com/wvdocs/Widevine_DRM_HLS.pdf
• https://integration.widevine.com/documentation/Widevine%20DRM
• https://integration.widevine.com/diagnostics

Other Widevine docs (unused atm, but while I'm at it…):

• https://storage.googleapis.com/wvdocs/Widevine_DRM_Getting_Started_Devices.pdf
• https://storage.googleapis.com/wvdocs/Chrome_EME_Changes_and_Best_Practices.pdf
• https://storage.googleapis.com/wvdocs/Widevine_DRM_Partner_License_SDK.pdf
• https://storage.googleapis.com/wvdocs/Widevine_DRM_Device_Provisioning_Models.pdf
• https://storage.googleapis.com/wvdocs/Widevine_DRM_Getting_Started_Device_Management.pdf
• https://storage.googleapis.com/wvdocs/Widevine_CAS_Overview.pdf
• https://storage.googleapis.com/wvdocs/Widevine_DRM_Using_Shaka_Packager_and_Player.pdf
• https://storage.googleapis.com/wvdocs/Widevine_DRM_Encoding_and_Packaging.pdf
• https://storage.googleapis.com/wvdocs/Widevine_DRM_Working_With_Foreign_Keys.pdf
• https://storage.googleapis.com/wvdocs/Widevine_DRM_Getting_Started.pdf
• https://storage.googleapis.com/wvdocs/Widevine_DRM_Android_Using_Key_Rotation.pdf
• https://storage.googleapis.com/wvdocs/Widevine_DRM_Android_Vendor_Extensions.pdf
• https://storage.googleapis.com/wvdocs/Widevine_DRM_Group_License.pdf
• https://storage.googleapis.com/wvdocs/Widevine_DRM_Using_License_Renewal.pdf
• https://storage.googleapis.com/wvdocs/Widevine_DRM_Key_Rotation_Encryption.pdf
• https://storage.googleapis.com/wvdocs/Widevine_DRM_License_Renewal_Overview.pdf
• https://storage.googleapis.com/wvdocs/Widevine_DRM_Accessing_the_CDM_Repository.pdf

Also, @mirh:

I think the only mystery left is why (just like with netflix tbh) 720p/1080p requires L1, while on "desktops" you can get away with the lowest security level

Your question is answered on page 13 of the pdf I linked above. I'll post an excerpt:

They can't enforce L1 on PCs, because there is a big number of users, including myself, who strongly oppose and refuse to buy any platform with TTX/TPM. I specifically nitpicked my Mobo, socket and processor to have no trusted computing on it. Although hardware vendors keep pushing it, market's nowhere near the point where they can enforce something like that. Here's hoping they never will.

from xbmc.

So, I've found the tools and I started analysing the content exchanges between Kodi and the server, and Firefox and the server. It looks pretty much the same except for the little thing down here:

Which is to say the CDM/OEMCrypto module doesn't trust our code, so it won't work. Possibly nothing we do will ever fix that. Did I mention that CDM/OEMCrypto are also closed source, and independently controlled by Google? Yeah… I think I did…

What am I even supposed to look for… The CDM would most likely access the parent's hierarchy and declare "I don't trust this guy", is there even anything we can do?

Edit: added the proxy integration PDF in the references post above. Page 22, Verified Media Path (VMP).

Update: so, long story short, clientId in widevine requests is deprecated in favor of encryptedClientId, through keys obtained via a widevine request with a CAQ= request body. As soon as I find out if that's even possible through IS.A/CDM I'll let you know. Also, if anybody can help, I'd greatly appreciate.

from xbmc.

Yes, again, I know L1 requires some whatever sort of hardware "secure predisposition", while L3 is "a program just like another".
So this has to mean that, given my FF report, *to the very least* (notwithstanding recommendations) there must be an L3-secured HD stream.
Therefore either L1 requirements on phones is bogus (at least for non-4K stuff that is), or the app is using different APIs that ends up offering you different streams.

As for your rant, again there isn't just DRM in the grand scheme of things. In fact, movies aside, I cannot think of once that youtube required me it.
And I'm not sure what you are talking about that it doesn't work. Once people managed to understand "enable inputstream DASH" means they have to do it, everything seems perfect. If >1080p doesn't work it is just because (dejavu) inputstream doesn't support VP9 in a webm container.
That seems to be the only different standard from netflix, for as much as they are concerned.

p.s. also which x86 system released in the past 5 years hasn't some sort of, if not TPM, at least TEE?

Which is to say the CDM/OEMCrypto module doesn't trust our code, so it won't work. Possibly nothing we do will ever fix that.

Ehrm.. Docs just say FF value means L3. Which I'm not sure how couldn't be available anywhere.
UNVERIFIED doesn't even mean TAMPERED, it just entails the "verification code" isn't even plugged in.
(to be fair, it seems like linux's CDM doesn't support it yet, but if netflix is working then VMP ain't the hard problem)

from xbmc.

Just to be on the safe side, instead of hardcoding the PSSH keys I implemented an automatic fetch and then attached it to IS.A. I'm also using Firefox/Edge WidevineCDM. It still doesn't encrypt the client information, so something is still off. I'm downloading FF's sources, maybe I can find some information there.

Edit: actually the answer may be a Widevine CryptoSession, Kodi ref., Android MediaDrm.
Also added another couple links above.

Edit 2: after a day of building a proxy I realized while reading the documentation that the PSSH are embedded inside MPDs. It could be useful if we want to switch to HLS eventually, but it's just wasted code atm.

Edit 3: cryptosession might be an android-only thing. The solution might be EME?

Edit 4: tried to sniff Widevine API calls, turns out Widevine is not so keen on sharing and is protected against DLL injection on the target. Currently there are two possible reasons why it's not working:

1. wvcdm needs a cryptoproxy which is not yet implemented in IS.A
2. wvcdm actually checks if the parent executable is signed by a reputable CA

I'll try to recompile FF to check if the latter's the problem, in which case we're doomed.

from xbmc.

Update: so, long story short, clientId in widevine requests is deprecated in favor of encryptedClientId, through keys obtained via a widevine request with a CAQ= request body. As soon as I find out if that's even possible through IS.A/CDM I'll let you know. Also, if anybody can help, I'd greatly appreciate.

Encrypted client ID just required the server's service certificate to be loaded into the CDM, it will then automatically encrypt the client ID. This is used to protect the client ID from being in plaintext; the service cert is simply a RSA keypair generated by the service, allowing them to decrypt the client ID encrypted with it. "SetServiceCertificate" or something like that should be the function call.

Requesting the service certificate for any widevine service takes sending the bytes "08 04", which is probably CAQ= base64'd as you said.

As an aside VMP doesnt work at all without encrypted client IDs, since encrypting the client ID is used to hide the VMP data from being read by, well, you guys.

Also there was an earlier discussion about Amazon 4K. Amazon uses Playready for 4K on the majority of devices, even Android. They don't even serve regular 4K via Widevine, only 4K HDR. Playready is done using SL2000 certs (not SL3000 certs, aka Playready 4.0, which is only really supported by Windows 10 and maybe some very new devices right now). Those certs you found in the apk are generic test certs I believe.

PS: there's no difference in protocol for L1 vs L3; the level of your device is verified via a giant intermediate cert list that basically says whether or not your client is L1 or L3 based on some fields in the clientID. All ChromeCDM keys are L3, and Firefox uses ChromeCDM.

from xbmc.

Went to take a look at inputstream's CDM adapter. You want this:

void SetServerCertificate(uint32_t promise_id,
const uint8_t* server_certificate_data,
uint32_t server_certificate_data_size);

It needs to be called before generating the license request with the service cert.

from xbmc.

the service cert is simply a RSA keypair generated by the service, allowing them to decrypt the client ID encrypted with it. "SetServiceCertificate" or something like that should be the function call.

I was unsure of the use of what Google calls PSSH, since even in the entirety of the documentation I read it wasn't really specified. I read back IS.A's source code and noticed there isn't any SSC calls, so the server certificates we provide are just never used for that. It seemed trivial enough, up until the point where the entire "promises" management needs to be implemented. I'll see what I can do.

Requesting the service certificate for any widevine service takes sending the bytes "08 04", which is probably CAQ= base64'd as you said.

I just checked and yes, that is correct.

As an aside VMP doesnt work at all without encrypted client IDs, since encrypting the client ID is used to hide the VMP data from being read by, well, you guys.

It's so true it hurts.

Also there was an earlier discussion about Amazon 4K. Amazon uses Playready for 4K on the majority of devices, even Android. They don't even serve regular 4K via Widevine, only 4K HDR. Playready is done using SL2000 certs (not SL3000 certs, aka Playready 4.0, which is only really supported by Windows 10 and maybe some very new devices right now).

Very interesting, I'll have to dig in the subject after I'm done with regular FHD.

PS: there's no difference in protocol for L1 vs L3; the level of your device is verified via a giant intermediate cert list that basically says whether or not your client is L1 or L3 based on some fields in the clientID. All ChromeCDM keys are L3, and Firefox uses ChromeCDM.

Yup, while analysing the sources I found the ChromeCDM as well inside Firefox, which also supports hardware proxying, if I read correctly.

@aers thank you so much for sharing the information, here's hoping I can put them to good use :)

from xbmc.

I was unsure of the use of what Google calls PSSH, since even in the entirety of the documentation I read it wasn't really specified. I read back IS.A's source code and noticed there isn't any SSC calls, so the server certificates we provide are just never used for that. It seemed trivial enough, up until the point where the entire "promises" management needs to be implemented. I'll see what I can do.

PSSH is called init data internally (PSSH is a legacy term). It is used to identify which key is being requested in a license request; the init data is effectively just straight up included in the license request message sent to the server.

You can probably see this if you use protobuf raw decode on the widevine messages, they are all protobufs ('08 04' is actually a valid protobuf message, and in widevine's protobuf definition its "request service cert").

1.)
Forcing the 08 04 request for android for encrypted messaging is done with setting private_mode attribute. There is no such attribute for libwidevine, if you guys find how it is triggered, pls. let me know.
Sure you can retrieve the server certificate by your own in addon and pass it using inputstream.adaptive listitem property, but I'm sure there is a way you don't have to do it this way.

ChromeCDM and the CDM adapter don't handle requests on their own. It's the responsibility of the player javascript to provide the service certificate to the CDM via setServerCertificate: https://developer.mozilla.org/en-US/docs/Web/API/MediaKeys/setServerCertificate

I don't know how this is implemented in the code inputstream uses, I'm not really familiar with any of this Kodi stuff, just widevine in general. But libwidevine dll from Chrome will not do any requests like this on its own.

2.)
4K streams are usually HEVC encoded. libWidevine does only decode H264 and VP9 (s/w) so it will be unlikely that 4K streams will be played using the internal decoder. There is only one chance for libwidevine + 4K: implement platform verification (as done in chromeos) to say that your system is "secure" and use libwidevine only for decryption. I doubt, that this will work in any way, because of many reasons (HDCP)

It is impossible to use ChromeCDM to decrypt 4K because no service will return a 4K license from a L3 request, and in addition all 4K licenses will have HW_ALL mode flagged, so you can't even use SW_DECRYPT mode in ChromeCDM.

Amazon licenses for ChromeCDM are flagged SW_DECODE which is why CDM can only decode them and output raw frames, and not decrypt them, btw.

from xbmc.

Sure you can retrieve the server certificate by your own in addon and pass it using inputstream.adaptive listitem property, but I'm sure there is a way you don't have to do it this way.

Assuming the server certificate is the same one that's streaming through the MPD (and it should, given Google's specs), there is no need to fetch it differently. We would need to manually get it only if we were using HLS streams instead, just like Netflix. Since the PSSH is already parsed from within the stream it doesn't seem necessary. The only problem, in regard to VMP, is that the PSSH is not passed to the Widevine CDM through the SSC.

would be worth a try setting inputstream.adaptive.license_flags=persistent_storage and watch traffic in kodi log

Will do

It is impossible to use ChromeCDM to decrypt 4K because no service will return a 4K license from a L3 request, and in addition all 4K licenses will have HW_ALL mode flagged, so you can't even use SW_DECRYPT mode in ChromeCDM.

At the moment in the 4k department we can't even get the list of videos that support them. There was a small-ish chance when Amazon had the 4k section on its TV apps, but I didn't reverse engineer it in time, and now that it's gone is all up in the air. If we manage to make 4k videos available, I guess people with secure devices might still find use for it. After all, in theory, we're here to use the content we're already paying for, not breaking the DRM it's shackled by, although the two often seem one and the same nowadays…

from xbmc.

Amazon's MPD does not include service cert. Its really easy to check Chrome/Firefox's behavior, if its making the 0804 request to Amazon's widevine2license endpoint or whatever its called then its loading it separately.

PSSH is not!! service cert, PSSH is init data.

Netflix actually includes the cert in their manifest responses (aptly named "cert") to avoid doing multiple requests.

VMP is impossible to make work in Kodi without doing things that would get you in legal trouble with Google, but you can definitely do privacy mode just by loading the service cert.

At the moment in the 4k department we can't even get the list of videos that support them. There was a small-ish chance when Amazon had the 4k section on its TV apps, but I didn't reverse engineer it in time, and now that it's gone is all up in the air. If we manage to make 4k videos available, I guess people with secure devices might still find use for it. After all, in theory, we're here to use the content we're already paying for, not breaking the DRM it's shackled by, although the two often seem one and the same nowadays…

Theres no support for 4k on MPD endpoint, only 4k HDR, unless this changed in 1.5 years (okay maybe it changed but it has been that long since I investigated). You could feasibly support 4K HDR on android TV and other such things but Amazon can block this easy.

from xbmc.

1.)
Forcing the 08 04 request for android for encrypted messaging is done with setting private_mode attribute. There is no such attribute for libwidevine, if you guys find how it is triggered, pls. let me know.
Sure you can retrieve the server certificate by your own in addon and pass it using inputstream.adaptive listitem property, but I'm sure there is a way you don't have to do it this way.

ChromeCDM and the CDM adapter don't handle requests on their own. It's the responsibility of the player javascript to provide the service certificate to the CDM via setServerCertificate: https://developer.mozilla.org/en-US/docs/Web/API/MediaKeys/setServerCertificate

My own Chromium compilation logs every CDMAdapter call, I'm sure that Server Certificates are managed.

For Amazon initialization starts with reading a fileIo object, but I had no time so far to investigate what information is readthere. Inputstream.adaptive returns 0 byte from this read, Chromium provides some bytes.

I'm quite sure that if we know / understand what file is read at initialization time, that server certificate is requested automatically.

Edit: What Im 100% sure about is that 08 04 license challenge comes out of libwidevine before the real license challenge is provided. 08 04 is not provided using kodi / inputstream.adaptive, but from log traffic the only difference is the file.

from xbmc.

Amazon's MPD does not include service cert. Its really easy to check Chrome/Firefox's behavior, if its making the 0804 request to Amazon's widevine2license endpoint or whatever its called then its loading it separately.

You're correct, I'm going stupid. For what it concerns Firefox though, it's not easy, because funnily enough, the behaviour is not reproduced when compiling from the sources. When Firefox is compiled and ran it doesn't encrypt the request and returns a PLATFORM_UNVERIFIED. So there's something missing from the picture.

In the grand scheme of things probably none of this matters, since Firefox is also able to decode FHD with no VMP. I'd be glad enough to figure out how to make 1080p play.

Theres no support for 4k on MPD

We are able to get a variety of streams, it's just that at the moment we don't know where to look.

My own Chromium compilation logs every CDMAdapter call, I'm sure that Server Certificates are managed.

I wonder if a compiled version of Chromium fetches the server certificate, because Firefox doesn't.

For Amazon initialization starts with reading a fileIo object, but I had no time so far to investigate what information is readthere. Inputstream.adaptive returns 0 byte from this read, Chromium provides some bytes.

I have a log of everything going out and coming into my machine, but I didn't find anything specific to RSA certificates. I can check back.

I'm quite sure that if we know / understand what file is read at initialization time, that server certificate is requested automatically.

I've been hammering at this from a while and I haven't figure out yet. I've got access to PrimeVideo.com, a few compilers, and traffic logs. If there's anything specific you want me to take a look at or provide you, just ask.

In the meanwhile I'll dive back into the logs. Although I could swear I checked everything and didn't see the server cert, unless it was hidden somewhere.

from xbmc.

When Firefox is compiled and ran it doesn't encrypt the request and returns a PLATFORM_UNVERIFIED. So there's something missing from the picture.

VMP is disabled since your files aren't signed so it probably doesn't bother to enable privacy mode, although it really still should use privacy mode... Chromium will act the same way, probably.

BTW what version of ChromeCDM are you using in Kodi? Version number of widevinecdm.dll

from xbmc.

@aers https://github.com/peak3d/inputstream.adaptive/blob/master/wvdecrypter/cdm/media/cdm/cdm_adapter.cc#L56

But not everything is implemented,

from xbmc.

VMP is disabled since your files aren't signed so it probably doesn't bother to enable privacy mode, although it really still should use privacy mode... Chromium will act the same way, probably.

Makes sense, but it still makes my head spin.

BTW what version of ChromeCDM are you using in Kodi? Version number of widevinecdm.dll

At the moment from the test I'm using the 4.10.1196.0 that is fetched by Firefox (which probably will never work). The version Kodi fetches is 1.4.9.1088.

from xbmc.

At the moment from the test I'm using the 4.10.1196.0 that is fetched by Firefox (which probably will never work). The version Kodi fetches is 1.4.9.1088.

Okay this is fine, Amazon will block anything below 1.4.9.1029. (after November 1st, they will block anything below 4.10.1185.0).

If unencrypted client ID requests from your custom build of Firefox get 1080p on Amazon then your issue isnt service certs.

Can you post a license request with unencrypted client id from a successful playback of 1080p in your browser and also one from a failure from Kodi? base64 is fine or just the binary file. Use the same video please.

Also, when it fails in Kodi, does it return a license and then fail to play afterwards, or just not return a license at all? If it does return a license post the licenses too.

from xbmc.

I was just checking the licenses back, so basically all these problems are due to the fact that there's no proper setup for HDCP_V1 (1088x464=504832, shy of ~15k pixels from the HDCP requirement).

Edit: granted, request encryption is still desirable, but still… also @aers if keyType=SERVICE_CERTIFICATE doesn't indicate the certificate to be used in the SSC, do you know what it is?

from xbmc.

Yes, that's exactly whats happening. CDM is checking for HDCP and failing, so it wont run decrypt routine. There is no issue here with your requests to Amazon or the version or anything, the license Kodi is getting contains all the proper keys. I didn't actually know someone had the protobuf for License available to decode publicly :)

And that is the SSC. That image is from the CAQ= request, right? That's what you need to provide to the CDM via SetServerCertificate to enable encrypted client IDs. As binary data, not b64, of course.

The CAQ= message is just this, in terms of the Widevine protobuf messaging format:

SignedMessage, type = SERVICE_CERTIFICATE_REQUEST, all other fields blank

or binary data "08 04", since type=04 is SERVICE_CERTIFICATE_REQUEST :)

For ChromeCDM privacy mode this needs to happen:

• make request to Amazon for MPD
• make request to Amazon for service cert
• call SetServerCertificate with cert
• call CreateSessionAndGenerateRequest with init_data (PSSH), generated request is now encrypted

(yes, Chrome CDM adapter code calls it Server cert, when widevine spec calls it Service cert, some miscommunication here :P)

from xbmc.

@Varstahl for kodi simply pass the b64 encoded server certificate using the listitem property
Edit: I still believe that the information from the FileIo object are still required for the workflow.

from xbmc.

Uh can you tell what file its reading because its probably the signature files for VMP. Which you cannot have for Kodi.

(widevinecdm.dll.sig, chrome.dll.sig, chrome.exe.sig, chrome_child.dll.sig on Chrome)

from xbmc.

And that is the SSC. That image is from the CAQ= request, right? That's what you need to provide to the CDM via SetServerCertificate to enable encrypted client IDs. As binary data, not b64, of course.

Yes, that is from the CAQ= challenge request. I don't think I can avoid passing the b64 though, since it's in the license response. Or maybe you just mean "take the response, b64 decode it and pass the response license binary blob"? It's still not implemented in IS.A but I can try that.

or binary data "08 04", since type=04 is SERVICE_CERTIFICATE_REQUEST :)

Yay, I'm just stubborn, not stupid.

@Varstahl for kodi simply pass the b64 encoded server certificate using the listitem property

I did, but it didn't change anything. It's not used within IS.A I think. At least unless I'm looking at the wrong tree, there's no SetServerCertificate.

I still believe that the information from the FileIo object are still required for the workflow.

As I'm using PrimeVideo.com and not Amazon.TLDs I'm not sure we're experiencing the same things. I haven't encountered any FileIo as far as I can tell, so far.

from xbmc.

@aers I have to recompile newer windows version tonight. Unfortunately the file is inside sandboxed FS storage, this one is not nice to read

from xbmc.

Yes, that is from the CAQ= challenge request. I don't think I can avoid passing the b64 though, since it's in the license response. Or maybe you just mean "take the response, b64 decode it and pass the response license binary blob"? It's still not implemented in IS.A but I can try that.

The license response for '0804' IS the service cert, its not actually a license :)

https://ybin.me/p/7a4b85be6c992dab#I2RLfIt4ZZfZpwEyu+cUe5F1BvPeadswVnyVeXUWbBU=

With HDCP issue I dunno its been 2 years since i looked at wvdecrypter code (since old days of original version on libertydev's github in 2016), I dunno if its even possible to 'enable' HDCP in ChromeCDM without using browser. Kodi would need to support enabling HDCP, because then CDM will query and see it. I guess.

from xbmc.

The license response for '0804' IS the service cert, its not actually a license :)

Yeah, I expressed myself poorly, what I meant is that in theory the JSON value associated with widevine2License.license can't be parsed to extract the keyId without the widevine verification toolset, so I assume you meant take the response, decode it into binary form and pass the blob to the function. Poor wording, sorry.

https://ybin.me/p/7a4b85be6c992dab#I2RLfIt4ZZfZpwEyu+cUe5F1BvPeadswVnyVeXUWbBU=

Great, that's one thing clear at least.

I dunno if its even possible to 'enable' HDCP in ChromeCDM without using browser

Wish I knew more myself.

Edit: also I just went back and retraced the service certificate issue. @peak3d Yes, in the code it seems used, but that didn't change the fact that the license request was not signed.

from xbmc.

Recompiled IS.A and checked the logs, but

  NOTICE: Creating InputStream
   DEBUG: ADDON: Dll Initializing - InputStream Adaptive
   DEBUG: Loading settings for plugin://plugin.video.amazon-test/?mode=PrimeVideo_Browse&path=root-!!-Watchlist-!!-Film-!!-0RZECTRBZS9IAHQ8A88PBMXQBK
   DEBUG: SECTION:LoadDLL(C:\Users\Varstahl\AppData\Roaming\Kodi\addons\inputstream.adaptive\inputstream.adaptive.dll)
   DEBUG: Thread BackgroundLoader start, auto delete: false
    INFO: AddOnLog: InputStream Adaptive: SetVideoResolution (1920 x 1080)
   DEBUG: AddOnLog: InputStream Adaptive: Open()
   DEBUG: AddOnLog: InputStream Adaptive: found inputstream.adaptive.license_key: [not shown]
   DEBUG: AddOnLog: InputStream Adaptive: found inputstream.adaptive.license_type: com.widevine.alpha
   DEBUG: AddOnLog: InputStream Adaptive: found inputstream.adaptive.manifest_type: mpd
   DEBUG: AddOnLog: InputStream Adaptive: found inputstream.adaptive.server_certificate: [not shown]
   DEBUG: AddOnLog: InputStream Adaptive: found inputstream.adaptive.stream_headers: user-agent=Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0

with a valid server certificate still doesn't encrypt.

from xbmc.

@Varstahl for what reason you need to recompile is.a ?

from xbmc.

@Varstahl for what reason you need to recompile is.a ?

No reason whatsoever. I set up a fast way on my development machine to easily have updated binaries, since I wanted to poke around the server certificate issue. The recompiled version is straight from the master branch though, so feel free to disregard that, I didn't actually touch the code yet.

from xbmc.

Ok, just wanted to make sure that you don't implement already existing features

from xbmc.

The only thing I can think of is that it's rejecting the service cert for some reason. You would have to have a way to check the Promise result for that, I think.

from xbmc.

Yes could be, @Varstahl you can add some

client_->CDMLog("Text");

inside these 3 methods:
https://github.com/peak3d/inputstream.adaptive/blob/master/wvdecrypter/cdm/media/cdm/cdm_adapter.cc#L452-L468

from xbmc.

Question. shouldn't SetServerCertificate and the subsequent CreateSessionAndGenerateRequest have the same promiseId? Because as it stands SSC is always called with a promiseId=0 https://github.com/peak3d/inputstream.adaptive/blob/master/wvdecrypter/wvdecrypter.cpp#L437.

Yes could be, @Varstahl you can add some client_->CDMLog("Text"); inside these 3 methods

SetServerCertificate
  DEBUG: AddOnLog: InputStream Adaptive: VARSTAHL: OnRejectPromise
CreateSessionAndGenerateRequest
  DEBUG: AddOnLog: InputStream Adaptive: VARSTAHL: OnResolveNewSessionPromise
  DEBUG: AddOnLog: InputStream Adaptive: CDMMessage: 3 arrived!

  DEBUG: AddOnLog: InputStream Adaptive: VARSTAHL: OnResolvePromise

I'll check the content of the certificate.

from xbmc.

This is lazyness, each call should become a unique id so you can reference in resolve / reject to the request (its async)

Edit: Can you post the server_certificate b64 string you pass to is.a ?

from xbmc.

Edit: Can you post the server_certificate b64 string you pass to is.a ?

It's here in the first code block, as CAQ=.

Edit: I've double-checked that the b64 string is the same one as passed to IS.A. Also the decoded string matches the length that it's supposed to match. So, assuming b64_decode in helpers.cpp works properly (which I didn't check yet), it's either one of the following:

1. we are messing something up with the requests
2. widevine won't accept anything from non verified binaries (possible, if not probable).

After all, come to think of it, if Widevine was to accept any service cert coming its way, wouldn't that mean that by forging a server cert one could use the publicly available wv tools on the fly to decrypt the VW VMP data? That would also explain why firefox/chromecdm, after being recompiled, won't even bother asking the service certificate in the first place.

from xbmc.

So, to sum up the situation:

1. Encrypted client id is forbidden by Widevine.
2. Resolutions higher than 1088x464 is forbidden by HDCP_V1.
3. I wasted a week chasing the impossible.

Which means that if I want to watch a 1080p movie off amazon servers on Kodi, I can download the encrypted DASH, let a bruteforcer run overnight, get the decryption key, reassemble the mp4 automatically and watch it to my heart's content. But if I want to do it legitimately without breaking the DRM, I can't. Reminds me a lot of videogames DRMs, they do nothing to stop piracy but hinder legitimate use. Which brings us back to the point of DRMs being stupid.

I guess I'll go study HDCP for the sake of it, since I learnt quite a bit from this journey. Thanks a lot to you both, @aers and @peak3d, much appreciated :)

from xbmc.

They're 128bit AES keys you're gonna be brute-forcing for more than a night. :P

Amazon used to only require HDCP for movies and not show episodes, but I guess they do for all content now?

from xbmc.

They're 128bit AES keys you're gonna be brute-forcing for more than a night. :P

There are multiple attack approaches nowadays that can help break even RSA in a manner of hours. It all depends on the algorithm and the ability to parallel process.

Amazon used to only require HDCP for movies and not show episodes, but I guess they do for all content now?

Still does afaik, the limit is only for movies. Unless they changed something overnight.

from xbmc.

Oh I didn't even know that was the context for this discussion. Its always been that way then.

from xbmc.

So.. I bend down to master reversers.
Very quickly I just wanted to apologize for my forgetting above, that you don't need "system DRM" if you ship yours in the apk..
Which is sad because it means any kind of "quick" support will have to rely on the system indeed (though, hurray, on the other hand SL2000 still isn't into "impossible even in principle" territory?)

Just for the very records of you all gentlemen then.. I just tried my monitor over the famously as free and unprotected as you can get VGA, and the aforementioned prime video from firefox was still giving me HD.

from xbmc.

Just for the very records of you all gentlemen then.. I just tried my monitor over the famously as free and unprotected as you can get VGA, and the aforementioned prime video from firefox was still giving me HD.

"disableAnalogOutput":false. Unless we're going back to VGA support for Kodi… it's working as expected. Digital gets protected, analogues gets a free pass. Remember that it's Widevine that decides how to show it to monitor. So, in theory, if you disconnect your monitors and connect a VGA to your graphic card (or maybe to your Intel GPU?) it should work. For anyone else, unless/until Kodi/IS.A support HDCP, it won't.

Which has me curious, but in all reality, shouldn't HDCP really only consist in supporting Intel's hardware passthrough, through CDM_Proxy?

BTW, I didn't give up, I'm just exhausted by a week of reversing, and supporting HDCP is kind of more complicated than simply "fetching stream X or certificate Y".

from xbmc.

(I'm not sure why kodi would need something special to support vga cables) EDIT: I understood now you meant the other way around

Anyway, well it seems for some dank reason they seem to call already a day with CGMS protection on here.
But I'm digressing now. Good luck.

from xbmc.

I'm not sure why kodi would need something special to support vga cables

Playback over VGA from Kodi should already work, unless it needs the chrome_cdm proxy stuff, I'm not sure.

from xbmc.

@Varstahl the server_certificate you picked from trace is meant to be passed to UpdateSession().
I could believe that this binary blob is not valid for SetServerCertificate() as we do if you pass it through listitem property.

Still the big question is what happens before the first call to force widevine to request the certificate. Coulkd be that PSSH from file is modified / appended in the js player.

Have you compared the PSSH init data from what is fed in FF and what is fed in is.a ?
is.a writes a file called [HEX].init in the cdm folder

Edit: I f*** up my windows server during chromium compilation -> need some time to set up the device again

from xbmc.

I haven't touched anything yet past the point I last wrote an update, I focused a bit on the immediate problems the addon had elsewhere. I was also interested in checking the implementation differences (if any) between Firefox and Chromium, so at the moment I'm setting up the workspace for the latest, so I can poke & prod at my leasure.

Still the big question is what happens before the first call to force widevine to request the certificate. Could be that PSSH from file is modified / appended in the js player.

The only way to know for sure would be to break the anti-debug embedded in the widevinecdm.dll, attach a debugger and sniff the API calls. In part I did, but without breaking the anti-reversing techniques wvcdm refuses to work properly.

As a side note, @peak3d, if you want to actively debug the issue, I could probably set up a private proxy server for Widevine authentication, in a while. MPD & data streams don't require authentication, so that shouldn't be a problem.

from xbmc.

I'm sorry for the delay, but I've had quite a few workstation problems of my own. Plus, Chromium is refusing to properly load Widevine despite my best efforts. I might drop Chromium altogether and just get the data off Firefox. I'll compare the PSSH data as soon as these toolchains start to collaborate…

from xbmc.

Have you compared the PSSH init data from what is fed in FF and what is fed in is.a ?
is.a writes a file called [HEX].init in the cdm folder

At first glance everything seems quite the same:

Full PSSH as reported by Firefox:
00000000  00 00 02 8C 70 73 73 68 00 00 00 00 9A 04 F0 79  ...Œpssh....š.ðy
00000010  98 40 42 86 AB 92 E6 5B E0 88 5F 95 00 00 02 6C  ˜@B†«’æ[àˆ_•...l
00000020  6C 02 00 00 01 00 01 00 62 02 3C 00 57 00 52 00  l.......b.<.W.R.
00000030  4D 00 48 00 45 00 41 00 44 00 45 00 52 00 20 00  M.H.E.A.D.E.R. .
00000040  78 00 6D 00 6C 00 6E 00 73 00 3D 00 22 00 68 00  x.m.l.n.s.=.".h.
00000050  74 00 74 00 70 00 3A 00 2F 00 2F 00 73 00 63 00  t.t.p.:././.s.c.
00000060  68 00 65 00 6D 00 61 00 73 00 2E 00 6D 00 69 00  h.e.m.a.s...m.i.
00000070  63 00 72 00 6F 00 73 00 6F 00 66 00 74 00 2E 00  c.r.o.s.o.f.t...
00000080  63 00 6F 00 6D 00 2F 00 44 00 52 00 4D 00 2F 00  c.o.m./.D.R.M./.
00000090  32 00 30 00 30 00 37 00 2F 00 30 00 33 00 2F 00  2.0.0.7./.0.3./.
000000A0  50 00 6C 00 61 00 79 00 52 00 65 00 61 00 64 00  P.l.a.y.R.e.a.d.
000000B0  79 00 48 00 65 00 61 00 64 00 65 00 72 00 22 00  y.H.e.a.d.e.r.".
000000C0  20 00 76 00 65 00 72 00 73 00 69 00 6F 00 6E 00   .v.e.r.s.i.o.n.
000000D0  3D 00 22 00 34 00 2E 00 30 00 2E 00 30 00 2E 00  =.".4...0...0...
000000E0  30 00 22 00 3E 00 3C 00 44 00 41 00 54 00 41 00  0.".>.<.D.A.T.A.
000000F0  3E 00 3C 00 50 00 52 00 4F 00 54 00 45 00 43 00  >.<.P.R.O.T.E.C.
00000100  54 00 49 00 4E 00 46 00 4F 00 3E 00 3C 00 4B 00  T.I.N.F.O.>.<.K.
00000110  45 00 59 00 4C 00 45 00 4E 00 3E 00 31 00 36 00  E.Y.L.E.N.>.1.6.
00000120  3C 00 2F 00 4B 00 45 00 59 00 4C 00 45 00 4E 00  <./.K.E.Y.L.E.N.
00000130  3E 00 3C 00 41 00 4C 00 47 00 49 00 44 00 3E 00  >.<.A.L.G.I.D.>.
00000140  41 00 45 00 53 00 43 00 54 00 52 00 3C 00 2F 00  A.E.S.C.T.R.<./.
00000150  41 00 4C 00 47 00 49 00 44 00 3E 00 3C 00 2F 00  A.L.G.I.D.>.<./.
00000160  50 00 52 00 4F 00 54 00 45 00 43 00 54 00 49 00  P.R.O.T.E.C.T.I.
00000170  4E 00 46 00 4F 00 3E 00 3C 00 4B 00 49 00 44 00  N.F.O.>.<.K.I.D.
00000180  3E 00 62 00 4D 00 6D 00 2B 00 6A 00 35 00 56 00  >.b.M.m.+.j.5.V.
00000190  4D 00 4F 00 55 00 47 00 75 00 33 00 57 00 4D 00  M.O.U.G.u.3.W.M.
000001A0  39 00 6B 00 68 00 49 00 33 00 67 00 67 00 3D 00  9.k.h.I.3.g.g.=.
000001B0  3D 00 3C 00 2F 00 4B 00 49 00 44 00 3E 00 3C 00  =.<./.K.I.D.>.<.
000001C0  43 00 48 00 45 00 43 00 4B 00 53 00 55 00 4D 00  C.H.E.C.K.S.U.M.
000001D0  3E 00 41 00 53 00 59 00 4B 00 68 00 4D 00 78 00  >.A.S.Y.K.h.M.x.
000001E0  56 00 45 00 70 00 59 00 3D 00 3C 00 2F 00 43 00  V.E.p.Y.=.<./.C.
000001F0  48 00 45 00 43 00 4B 00 53 00 55 00 4D 00 3E 00  H.E.C.K.S.U.M.>.
00000200  3C 00 4C 00 41 00 5F 00 55 00 52 00 4C 00 3E 00  <.L.A._.U.R.L.>.
00000210  68 00 74 00 74 00 70 00 73 00 3A 00 2F 00 2F 00  h.t.t.p.s.:././.
00000220  70 00 72 00 6C 00 73 00 2E 00 61 00 74 00 76 00  p.r.l.s...a.t.v.
00000230  2D 00 65 00 75 00 2E 00 61 00 6D 00 61 00 7A 00  -.e.u...a.m.a.z.
00000240  6F 00 6E 00 2E 00 63 00 6F 00 6D 00 2F 00 63 00  o.n...c.o.m./.c.
00000250  64 00 70 00 3C 00 2F 00 4C 00 41 00 5F 00 55 00  d.p.<./.L.A._.U.
00000260  52 00 4C 00 3E 00 3C 00 2F 00 44 00 41 00 54 00  R.L.>.<./.D.A.T.
00000270  41 00 3E 00 3C 00 2F 00 57 00 52 00 4D 00 48 00  A.>.<./.W.R.M.H.
00000280  45 00 41 00 44 00 45 00 52 00 3E 00 00 00 00 79  E.A.D.E.R.>....y
00000290  70 73 73 68 00 00 00 00 ED EF 8B A9 79 D6 4A CE  pssh....íï‹©yÖJÎ
000002A0  A3 C8 27 DC D5 1D 21 ED 00 00 00 59 08 01 12 10  £È'ÜÕ.!í...Y....
000002B0  8F BE C9 6C 4C 95 41 39 AE DD 63 3D 92 12 37 82  .¾ÉlL•A9®Ýc=’.7‚
000002C0  1A 06 61 6D 61 7A 6F 6E 22 35 63 69 64 3A 6A 37  ..amazon"5cid:j7
000002D0  37 4A 62 45 79 56 51 54 6D 75 33 57 4D 39 6B 68  7JbEyVQTmu3WM9kh
000002E0  49 33 67 67 3D 3D 2C 72 39 65 4B 61 4A 4C 72 53  I3gg==,r9eKaJLrS
000002F0  6C 75 71 78 2B 32 5A 52 65 57 45 46 51 3D 3D 2A  luqx+2ZReWEFQ==*
00000300  02 53 44 32 00                                   .SD2.

[HEX].init for the same video:
00000000  08 01 12 10 AF D7 8A 68 92 EB 4A 5B AA C7 ED 99  ....¯×Šh’ëJ[ªÇí™
00000010  45 E5 84 15 1A 06 61 6D 61 7A 6F 6E 22 35 63 69  Eå„...amazon"5ci
00000020  64 3A 6A 37 37 4A 62 45 79 56 51 54 6D 75 33 57  d:j77JbEyVQTmu3W
00000030  4D 39 6B 68 49 33 67 67 3D 3D 2C 72 39 65 4B 61  M9khI3gg==,r9eKa
00000040  4A 4C 72 53 6C 75 71 78 2B 32 5A 52 65 57 45 46  JLrSluqx+2ZReWEF
00000050  51 3D 3D 2A 02 53 44 32 00                       Q==*.SD2.

As far as I can tell, aside the random data changing with every request, the init feels the same, at least in the final part. I haven't analysed the full PSSH as read by Kodi, so I don't know if the PlayReady information is discarded by IS.A or by the server.

For what it concerns the CAQ= request, both the signed and unsigned Firefox have roughly the same Widevine proxy calls, except for the fact that after receiving the init data, the signed Firefox requests the CAQ=, while the unsigned doesn't.

Firefox's logs are split and not really easily readable, I've put together an aggregator of sorts, but being asynchronous even within a single thread, comparing two logs is proving quite the challenge. Hopefully I can find a bit more about this tomorrow.

(inb4, plot twist, the HD streams are encrypted with PlayReady *faints*)

Edit: formatted the PlayReady init to combat my migrain while reading the above

<WRMHEADER
    xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader" version="4.0.0.0">
    <DATA>
        <PROTECTINFO>
            <KEYLEN>16</KEYLEN>
            <ALGID>AESCTR</ALGID>
        </PROTECTINFO>
        <KID>aIrXr+uSW0qqx+2ZReWEFQ==</KID>
        <CHECKSUM>v45+UVynPLQ=</CHECKSUM>
        <LA_URL>https://prls.atv-eu.amazon.com/cdp</LA_URL>
    </DATA>
</WRMHEADER>

from xbmc.

I'm sorry, I don't understand what hardware proxy you mean? The reason compiled Firefox works is its passing the "is HDCP enabled" check. Since Amazon doesn't enforce the use of VMP the signature stuff doesn't matter, that part is correct.

from xbmc.

@Varstahl if you have played the same movie, pssh initdata should not vary.
Not sure what the content_id is (if it is fixed or not), but now that we know that there are differences in pssh data (for widevine) it could be that the key of UHD streams is already in the manifet request.

from xbmc.

For Amazon, content_id is extra key IDs base64'd, you can verify this by looking at the license key IDs compared to the content_id. This is why the license has 3 key IDs even though the init data only supports one key ID. Providers can do whatever they want with content_id field.

from xbmc.

Great info! So then the question is if the extra KID's are necessary for decrypting UHD streams (??)
Because pssh for the same movie should be static (except amazon does magic in JS code) or simply provides streams with different initialization data, I would first look why its not identical.

Interesting would be hardcoded sending the FF pssh to the license server and look if maybe the server_certificate request appears automatically first....

Edit: I remember from earlier times that you had to pass "IncludeHDCPkey" or similiar into the GetPlaybackResources URL. I never did things with that, but leads into the direction we're searching here

from xbmc.

4K streams use different keysets but the key IDs for those will be in the pssh of a MPD containing 4K content, that's not an issue.

from xbmc.

Lol, please. Bruno is already going crazy for HD. Put 4K aside for the moment.

from xbmc.

:-) yes, @Varstahl should try to limit web browser to smaller resolution (best possible same as used in kodi)
Comparing apples and pies is not much fun. From current pov I see 2 things:

1.) pssh initdata differs because the GetPlaybackRecource request / other session things are invalid.
IIRC there is a calling home loop in amazon which tells amazon secrets about the current device (??)

2.) VMP (not yet clear what it is) is detected via file access (what I'm hunting for, unfortunately currently blocked by other kodi issues)

from xbmc.

1.) pssh initdata differs because the GetPlaybackRecource request / other session things are invalid.
IIRC there is a calling home loop in amazon which tells amazon secrets about the current device (??)

initdata shouldn't vary for a given stream+quality level, its just a list of keyids to request in the license, this init data is actually included in the stream .mp4 itself as well.

2.) VMP (not yet clear what it is) is detected via file access (what I'm hunting for, unfortunately currently blocked by other kodi issues)

Sorry, I didn't realize you don't understand what VMP is.

VMP stands for verified media path. It is applicable only to browsers (and, specifically, "ChromeCDM", which is the widevinecdm.dll used by Chrome, Firefox, and other browsers, currently, although the spec requires all browser-based implementations support it). It's a way for the service provider (Amazon, Netflix, etc) to verify that the client's browser and ChromeCDM are not compromised in any way. The way it does this is pretty simple: there are signature files included with Chrome, Firefox, etc. releases that are signed by Google's VMP cert. The content of those signature files, along with some data gathered by ChromeCDM as it runs, is sent to the server in the license request, allowing the service provider to verify your browser and CDM are unmodified.

The ".sig" files in your Chrome install (chrome.dll.sig, chrome.exe.sig, chrome_child.dll.sig, widevinecdm.dll.sig) are these signature files.

In addition, VMP requires the use of "privacy mode", aka "encrypted client ID", which triggers a request to the server of 08 04 in order to get the service cert. This allows the VMP data to be encrypted so no one can easily sniff traffic and see what exactly is included in VMP data.

This is actually irrelevant for Amazon because Amazon does not require VMP for their content to work - this is why compiled versions of Chromium and Firefox still work.

The file access that you're detecting is probably checking for .sig files. In order for VMP to work while using Kodi + ChromeCDM you'd need a signature file for at the very least the Kodi exe itself which is impossible to get.

from xbmc.

How is electron.... Ok nvm, separate licensing agreements are required.
Couldn't you hook/load some whatever big enough subset of signed dlls to get VMP working though?
(and wouldn't netflix already be requiring it?)

from xbmc.

In one of the sources (possibly Firefox?) there was code relative to (roughly) WidevineCDM Proxy with some sort of "secure context for Intel", or something of the sort. If I'm correct that's the code to enable HDCP secure context for Widevine to reproduce the video into. Going off the top of my head, so take everything with a grain of salt.

I want to say this is prep for using hardware secured keys to support L1 in ChromeCDM via modern Intel CPU+iGPU the same way Edge supports SL3000 Playready on KabyLake+.

In this case the CDM would be proxying everything out to a hardware decrypt+decode+playback that never touches unsecured memory.

Theres some stuff about this in the CDM adapter source iirc. But dont quote me on this one because I honestly don't know :)

And we're still having it good, because I read Google's "recommended settings" for Widevine encryption and it made me shiver (L1 for freakin' 720p? Are you kidding me?)

No serious service will lock everyone out of HD on PCs (yet), so don't worry... Google doesn't even enforce L1 on paid HD Youtube content unless as far as I know :P

from xbmc.

Not sure, along with Intel there were comments about supporting other stuff like DX11 contexts (which I interpreted as DirectX 11, could be absolutely wrong). I'll have to check later today, I'll fill my Dr. Who Tardis cup full of tea, take the magnifying glass, and start the investigations.

from xbmc.

What the heck, when I tested it a few days ago it was not working. Did they fix it in yesterday's updates? Let me test it.

from xbmc.

u can acess UHD using this method if and and only if the content is avalable in both UHD & HDR else it wont work

from xbmc.