Support for server returning multiple SignedDrmCertificates about pywidevine HOT 8 CLOSED

This is an interesting case. I've not seen this anywhere else before. What service is doing this? Both certificates are the common service certificate for Google's production license server, and both service certificates are identical, including their signatures.

The cert.txt you provided, the response from the server, is a SignedMessage message. Your one has two values for the message type, two values for the message itself, and no signature(s) (normal for service certs). Normally SignedMessage is expecting just one value each, hence SignedMessage not SignedMessages. Therefore, I don't think I'll add this to the protobuf schema, not even as an alternative SignedMessages definition, as I feel like this is either a bug in that service, or they are intentionally doing it to try and break software and services parsing with the original schema.

Why you get a partial decode error is when it parses that cert.txt data and then re-serializes it with our schema, the data is different because it effectively discarded one of the two message types and message messages. I could try and add a manual check if the original input data was in fact a message like this one where it had more than two values for type and message, and then just continue anyway keeping what was likely the first value (which in your case would be fine).

from pywidevine.

Thank, for the reply. The service is the VOD service of the french TV channel TF1.

from pywidevine.

So after looking into it more, this response doesn't even seem to be a message containing repeated SignedMessage items, but rather just two consecutive responses of SignedMessage messages concatenated together. For example, return Cdm.common_privacy_cert + Cdm.common_privacy_cert.

Are you sure you aren't somehow trying to set a service certificate twice at the same time? I.e. set_service_certificate(res.content + res.content) or something along the way, or is the service responding like this exactly?

Dealing with this even by making a protobuf message is more problematic than I first thought because since they have it as effectively two separate SignedMessage's but concatenated together, I can't make a protobuf Message schema for it and have it serialize exactly alike. It would parse correctly, but not serialize to the exact same result as they sent it.

from pywidevine.

This is what I get when I dump the whole network trace (using Chrome "Save all as HAR with content" option).
The response is defined like this and you can see that the size if indeed 1432 bytes :

          "content": {
            "size": 1432,
            "mimeType": "application/octet-stream",
            "text": "CAUSxwUKwQIIAxIQFwW5F8wSBIaLBjM6L3cqjBiCtIKSBSKOAjCCAQoCggEBAJntWzsyfateJO/DtiqVtZhSCtW8yzdQPgZFuB…",
            "encoding": "base64"
          },

from pywidevine.

I pushed a fix as you can see above.

I'd love it if you can follow development instructions to run the latest code and test with that if you could. I took your cert.txt and tested with that by hardcoding it in the test CLI command and it works for me. But it would be great if you could test it against TF1 itself. It should work though. :)

from pywidevine.

Thank you, I will give it a try and let you know.

from pywidevine.

I works well.
I would not be surprised this unexpected behavior is a way to make it harder to fetch keys, as they are trying hard with dynamic license url server with short expiration and other measures, but with your change, I finally managed to fetch some keys :-)

from pywidevine.

I works well. I would not be surprised this unexpected behavior is a way to make it harder to fetch keys, as they are trying hard with dynamic license url server with short expiration and other measures, but with your change, I finally managed to fetch some keys :-)

Glad it works 👍

from pywidevine.