Giters

devine-dl / pywidevine

Python implementation of Google's Widevine DRM CDM (Content Decryption Module)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Proto Message Type Verifications aren't strict

rlaphoenix opened this issue · comments

commented

Describe the bug
For example, <html><body>Server error, sorry</body></html> (as UTF8 bytes) will be parsed successfully as a SignedMessage with ParseFromString() into a partial message (with minimal data supplied).

In this specific example, it will parse as a very bare LICENSE_REQUEST type SignedMessage. If this is supplied to the parse_license method it will fail in a weird way. It of course expects a LICENSE type SignedMessage, but gets a LICENSE_REQUEST type SignedMessage which would be very unexpected.

To Reproduce
Steps to reproduce the behavior:

  1. Install pip install pywidevine
  2. Construct a Cdm object.
  3. Generate a Challenge but pass <html><body>Server error, sorry</body></html> to parse_license instead of a real license response.
  4. It will raise an InvalidLicenseMessage exception stating, Expecting a LICENSE message, not a 'LICENSE_REQUEST' message.

Expected behavior
It should have failed to parse the message entirely stating a different error, being more accurate to the validity of the input data.

Screenshots
N/A

Additional context
N/A

commented

I should note that some of the message verification in the code is done differently around the codebase. The best way currently seems to be this method I've done with set_service_certificate of Cdm. That's where I parse, then serialize the parsed object, and compare the newly serialized object with the original input string. If they are an exact match then it can be considered a valid parse.

See: https://github.com/rlaphoenix/pywidevine/blob/2af929a83d32bb4afa734268c2809711bbdccd0f/pywidevine/cdm.py#L205-L207

I don't see any easier way of strict parsing. I've scrubbed through the docs and there is stuff like MergeFromString() that may be used in a somewhat similar way, but at the end of the day, it's not any easier.

This is intended behavior from the looks of things relating to the Optional flag within the proto schema, which I believe was recently dropped and is now unusable in the latest proto buffer schema and compilers.