Needed DRM key request (challenge) and session ID to manifest proxy callback

[CastagnaIT]

Ntflx service recently implemented new changes in order to request the Manifest,
it appears necessary to provide these info:

• DRM key request (challenge)
• DRM session ID

Currenlty ISA do not provide these info in any way, and i do not know how to do in future if it becomes mandatory for all platforms

The Key request is already mandatory to have HD content on ARM linux devices
and currently i use a hack workaround by hardcoding the value in the addon (of my device) for the first manifest request, and i sniff the value from the license callback for all others manifest callbacks.
This hack is really ugly and is not correct to provide data from different devices and sniffed from the license calllback
I wish to have this fixed in ISA a day...

A good solution would be provide these info directly when ISA make the proxy manifest callback (http request to the addon to get the manifest)
but seem that ISA create the DRM session only after the manifest (addon) callback
and i have no idea on how this can be done

I tried to investigate the situation, but i am not able to make these changes by myself

[glennguy]

Yes drm session needs pssh/kid to begin, which we only know from the manifest.

Off the top of my head (and without seeing what you're doing in nf add-on) you could make a bare-bones version of InitializeDRM():

Roughly:

• ensure ssd_wv is loaded (GetSupportedDecrypterURN)
• call decrypter_OpenDRMSystem(....)
• create CDMSESSION in cdm_sessions_[1]
• assign this session's ssd through decrypter_->CreateSingleSampleDecrypter(...)
• call ssd->getSessionId()
• do other stuff to get the challenge.

Getting this data back to your add-on though would be very hacky using a plugin call. And probably even worse trying to signal back to IA the mpd.

Please correct me if my thinking is wrong. I think the proper solution is implementing a way for binary add-ons to call back to Kodi. This would be useful for much more situations as well, like signalling that playback failed and how/why.

[CastagnaIT]

Getting this data back to your add-on though would be very hacky using a plugin call. And probably even worse trying to signal back to IA the mpd.

with nflx addon i use ISA proxy callbacks to provide manifest and license, as wiki guide:
https://github.com/xbmc/inputstream.adaptive/wiki/How-to-provide-custom-manifest-and-license
i do not think that is needed implement others type of plugin calls or kodi interactions

when ISA call the addon to ask the manifest (via http proxy), my addon should make the http request to the netflx server to get the manifest data, but my addon to make this request (and construct the MPD) have the need of the mentioned DRM info

for example in the ISA license callback is already implemented the sending of some DRM data (see wiki)
i was thinking that is possible to do the same thing for the manifest
so could be possible do a ISA POST proxy request in order to include also the DRM info (like already happen with license)

[glennguy]

Ok I understand a little better now.

Again off the top of my head...
So one way is as stated above, with a listem property to provide the callback url that we POST to. Lost of work to do on IA side, your add-on works nice and clean :). Again though referring to my last post, is this a hacky workaround to suit a very specific case, or legitimate use of the drm workflow that other providers may also be using?

Another workaround could be that similar to the challenge data we dump the session id to a file in the cdm folder. Then provide a 'dummy' mpd through the proxy that is live/dynamic with possibly a dummy segment in period 0 (this will allow license process to happen), then when mpd updates for new segments we provide the proper mpd and make static. Least amount of work in IA, very hacky on your end and Kodi may not cooperate with getting a very short stream initially.

Neither idea is a perfect solution, though I think the first idea is preferable.

Ultimate solution I think would involve making a proper callback to Kodi that add-on could listen for i.e xbmc.Player().Inputstream().onInputstreamMessage() or similar, and same for add-on to signal back to IA - xbmc.Player().Inputstream().sendMessage(message) . But that is for someone much more skilled than me to hopefully be able to do one day.

[CastagnaIT]

Again off the top of my head...
So one way is as stated above, with a listem property to provide the callback url that we POST to. Lost of work to do on IA side, your add-on works nice and clean :). Again though referring to my last post, is this a hacky workaround to suit a very specific case, or legitimate use of the drm workflow that other providers may also be using?

yes my case could be specific, but in future also other VOD could be need of this,
could be an idea to have a switch with a listitem property to have a POST call with drm info

but if you want try see if it useful @wagnerch has discovered some other things referring to have these drm info, has wrote in the PR CastagnaIT/plugin.video.netflix#1129
but i understand little and i'm starting to get confused

[glennguy]

Yes the big problem is making all this happen in one instance of inputstream.adaptive so we keep the same cdm session. I can't be 100% sure but I think we can open a cdm session without pssh/kid. We can add pssh later.

[wagnerch]

It looks like to me Netflix pre-generates the pssh/kid and is available in their Cadmium Player, and that is used in the EME generateRequest call. So I think what we would need, assuming we can get our hands on the PSSH, is a parameter to pass in the PSSH on the ListItem, and ISA would use that, create the session (CreateSessionAndGenerateRequest) BEFORE downloading the manifest, and as a part of the manifest be able to pass back a parameter with the license data and session id.

Then on the NF end, we would need to parse the Cadmium Player JS (and/or maybe hardcode the pssh/kid -- could it be that easy?) and pass that pssh on the ListItem, and modify our manifest callback service to capture the license from ISA and include it in the MSL request back to Netflix for the licensedManifest call and generate the manifest (MPD) for ISA.

I think that's it.

[matthuisman]

i use a few functions here to generate cenc init data:
https://github.com/matthuisman/slyguy.addons/blob/master/script.module.slyguy/resources/modules/slyguy/util.py#L448
https://github.com/matthuisman/slyguy.addons/blob/master/script.module.slyguy/resources/modules/slyguy/util.py#L502
(they are Py2 / Py3 compatible)

This site is pretty handy too:
https://tools.axinom.com/decoders/PsshBox

If you use EME Call and Event logger chrome extension, that logs the init data in a base64 string to the web tools console.
You then just paste that into the site above and it'll give you all the keys etc

Or simply pass it to IA using the license_data property
That is what sent to the Widevine blob to generate the challenge.
the challenge is then sent to the license server (which you can intercept)

Seems to me that you should have everything you already need as far as IA goes?
You can control the data that is used to create the challenge with license_data and you can proxy the request to the server if needed.

yes, you may need to request the manifest first to pull cenc:pssh data to then create the true init data.
But if you proxy the manifest - you could just cache it to save the 2nd call when IA starts playback?

Oh sorry - ignore me.
Just re-read initial post - you need that data to even request the manifest itself....
Hmmmmmm. Tricky!

But yes, callbacks would be very nice.
To edit manifest etc without needing to proxy.
that way cookies etc aren't messed up either.

[CastagnaIT]

@matthuisman on the basis of @glennguy of "rougly" solution
@wagnerch managed to theorise a possible solution on post:
CastagnaIT/plugin.video.netflix#1129 (comment)

we have found the pssh, and ISA already has the function to extract the KID, this would make it possible to initialise the DRM
and send the challenge/session id to the proxy manifest callback
of course require some changes to the current implementation or make a separate implementation

[matthuisman]

Are you sure the manifest request needs the actual challenge / session Id? Is it using that to authenticate? Or is it using that data to create the cenc:pssh data in the file? Can you just send some old / static data to get the manifest? Then strip out the cenc:pssh and just use license_data to set the pssh data?

[CastagnaIT]

netflix has introduced a new manifest request that require these data,
@wagnerch have found that use an hardcoded pssh to initialize the drm,
and attach to the ntflx manifest request these data
the hardcoded pssh is different from the pssh obtained from the manifest response

from what i know these drm data is used to have HD content, at least for now is required for ARM devices

[CastagnaIT]

Can you just send some old / static data to get the manifest?

currently i use a hacked workaround but i can do it only for challenge data
the initial manifest request is done by sending an hardcoded challenge data of a my device,
all the subsequent manifest requests use the old challenge data sniffed from a previous ISA license callback

I would really like to get rid of this hacked workaround as soon as possible
because in addition to sending wrong data all the time
the new manifest require also the sessionid
and i don't know how good this path will be...

[wagnerch]

I would really like to get rid of this hacked workaround as soon as possible
because in addition to sending wrong data all the time
the new manifest require also the sessionid
and i don't know how good this path will be...

I think the concern is at what point does Netflix actually validate the license data or change the pssh and causes this static data to break. As far we know the pssh embedded in Netflix's player is static, but they could be using a different pssh per region or dynamically generating the player client (javascript) on a per client basis. So far I pulled down 3 versions of cadmium player and the pssh has been the same. I'll keep monitoring that end of it, @CastagnaIT not sure if you checked the cadmium player for your region to see if they use the same pssh?

But personally, that would be my biggest fear, is they change something or start validating the data we are sending in the manifest request and start rejecting it.

https://gist.github.com/wagnerch/192464e938dec116cc783d353a0fda31

/home/wagnerch/cadmium-playercore-6.0030.185.911.js:
PSSH Box v0
  System ID: edef8ba9-79d6-4ace-a3c8-27dcd51d21ed
  PSSH data (size: 20): 080112100000000003d267490000000000000000
Widevine PSSH found -- AAAANHBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAABQIARIQAAAAAAPSZ0kAAAAAAAAAAA==

/home/wagnerch/cadmium-playercore-6.0030.094.911.js:
PSSH Box v0
  System ID: edef8ba9-79d6-4ace-a3c8-27dcd51d21ed
  PSSH data (size: 20): 080112100000000003d267490000000000000000
Widevine PSSH found -- AAAANHBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAABQIARIQAAAAAAPSZ0kAAAAAAAAAAA==

/home/wagnerch/cadmium-playercore-6.0030.049.911.js:
PSSH Box v0
  System ID: edef8ba9-79d6-4ace-a3c8-27dcd51d21ed
  PSSH data (size: 20): 080112100000000003d267490000000000000000
Widevine PSSH found -- AAAANHBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAABQIARIQAAAAAAPSZ0kAAAAAAAAAAA==

[CastagnaIT]

the cadmium player js is always the same, can change when they update the website
and i saw that they can update the website for groups of users of selected countries before applying them worldwide

here you can see my is same:

PSSH Box v0
  System ID: edef8ba9-79d6-4ace-a3c8-27dcd51d21ed
  PSSH data (size: 20): 080112100000000003d267490000000000000000
Widevine PSSH found -- AAAANHBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAABQIARIQAAAAAAPSZ0kAAAAAAAAAAA==

[matthuisman]

What's stopping you replacing the cenc data in the manifest with the real data?

You have the real cenc data before manifest. So request manifest with generic challenge. Then replace the cenc:pssh with the real data in it?

I suspect they are using the challenge you send to pull out the cenc pssh data and device info. Then generating the manifest around that. So you could just update the manifest after you grab it?