|
|
||
|---|---|---|
| .github | ||
| docs/images | ||
| pywidevine | ||
| .gitignore | ||
| LICENSE | ||
| poetry.lock | ||
| pyproject.toml | ||
| README.md | ||
pywidevine
Widevine CDM (Content Decryption Module) implementation in Python.
Disclaimer
- This project requires the use of a Google provisioned private key and Client Identification blob.
- Neither of them are provided by this project.
- Public test provisions are available to use for testing this project.
- License Servers have the ability to block requests from test provisions.
- This project does not condone piracy or any action against the terms of the DRM systems.
- All efforts in this project have been the result of Reverse Engineering and Trial & Error.
Protocol
Credit: w3.org
Almost the entire Widevine Protocol seen above is implemented except for Sessions which I will be implementing soon. Currently, only one session can be made and used at a time or problems will happen.
Web Server
This may be an API/Server in front of a License Server. For example, Netflix's Custom MSL-based API front. This is evident by their custom Service Certificate which would only be needed if they had to read the License.
Net, Media Stack and MediaKeySession
These generally refer to the Encrypted Media Extensions API on Browsers.
Under the assumption of the Android Widevine ecosystem, you can think of Net as the Application Code, Media Stack
as the OEM Crypto Library, and MediaKeySession as a Session. The orange wrapper titled Browser is effectively the
Application as a whole, while Platform (in Green at the bottom) would be the OS or Other libraries.
Key and Output Security
Licenses, Content Keys, and Decrypted Data is not secure in this CDM implementation.
The Content Decryption Module is meant to do all downloading, decrypting, and decoding of content, not just license acquisition. This Python implementation only does License Acquisition within the CDM.
The section of which a 'Decrypt Frame' call is made would be more of a 'Decrypt File' in this implementation. Just returning the original file in plain text defeats the point of the DRM. Even if 'Decrypt File' was somehow secure, the Content Keys used to decrypt the files are already exposed to the caller anyway, allowing them to manually decrypt.
An attack on a 'Decrypt Frame' system would be analogous to doing an HDMI capture or similar attack. This is because it would require re-encoding the video by splicing each individual frame with the right frame-rate, syncing to audio, and more.
While a 'Decrypt Video' system would be analogous to downloading a Video and passing it through a script. Not much of an attack if at all. The only protection against a system like this would be monitoring the provision and acquisitions of licenses and prevent them. This can be done by revoking the device provision, or the user or their authorization to the service.
There isn't any immediate way to secure either Key or Decrypted information within a Python environment that is not Hardware backed. Even if obfuscation or some other form of Security by Obscurity was used, this is a Software-based Content Protection Module (in Python no less) with no hardware backed security. It would be incredibly trivial to break any sort of protection against retrieving the original video data.
Though, it's not impossible. Google's Chrome Browser CDM is a simple library extension file programmed in C++ that has been improving its security using math and obscurity for years. It's getting harder and harder to break with its latest versions only being beaten by Brute-force style methods. However, they have a huge team of very skilled workers, and making a CDM in C++ has immediate security benefits and a lot of methods to obscure and obfuscate the code.