In a result of its research investigation efforts, Security Explorations, a research lab of AG Security Research company, conducted security analysis of Microsoft Warbird and Protected Media Path technologies.
This section of our website presents initial information regarding the project.
Microsoft Protected Media Path (PMP) is a set of technologies of which goal is to enforce security of content (security of PlayReady DRM) in a Windows OS environment (Wikipedia).
In Windows OS, Protected Media Path is implemented both in kernel and user space. It relies on crypto, code integrity, auth checks, white-box crypto and code obfuscation.
Microsoft Warbird is a compiler technology from Microsoft of which goal is to make reverse engineering (such as static and dynamic analysis) of code components comprising certain Windows OS components hard. More specifically, the goal is to make it hard to extract secrets pertaining to code implementation in an untrusted (under attacker's control) environment.
Binaries produced by Warbird can be encrypted and its code obfuscated. These binaries can execute "encrypted" code too.
As a result of the research several deficiencies have been discovered in various PMP components, which could be exploited to gain access to plaintext content keys guarded by PlayReady (Windows 10 / Windows 11 environment and SW DRM case).
It has been demonstrated that these plaintext keys could be successfully used to decrypt high definition (1080p) movies protected by PlayReady content protection (Canal+ Online VOD platform scenario).
On Windows platforms with HW DRM capability, the attack can still proceed as this feature can be easily disabled. Also, none of the streaming platforms tested enforced HW DRM for Windows (with HW DRM disabled, SW DRM was used and content key extraction could proceed both in Windows 10 and 11).
The root cause of the issue lies in SW DRM implementation used by default on Windows 10 without HW DRM capability. This version of Microsoft OS still (as of Mar 2024) has a 69% market share worldwide, which is partially caused by inability for users to upgrade to Windows 11 as their systems do not meet minimum upgrade requirements, such as having a TPM 2.0 chip. Windows 10 is set to retire on Oct 14, 2025. As such, a potential weak chain is to still persist for 1.5 year (due to the implementation done solely in SW, on a client side and in an environment under attacker's control).
Please, note that this is a different research than our research from 2022 (and different Canal+ VOD service). The results and know-how obtained by this new research make the previous research obsolete in many ways.
DRM technology lies at the core of a security of the industry that is valued at $544 billion.
In that context, content security should not be different than the usual information security safeguarding organizations' trade secrets, IT assets or personal data.
Exposure of the weaknesses, negligence or false security claims in the PayTV / video streaming / content security industry is equally important too.
This research is a continuation of our journey spanning 12 years during which we investigated security of PayTV / content security systems such as DVB chipsets / Conax Conditional Access System, SAT TV Platforms, set-top-boxes / VOD platforms and implementation of a DRM system.
On Apr 12, 2024, Microsoft PlayReady team reached to us with a request to report technical details and POC code through MSRC channel claiming that "by following the MSRC process to report your finding, it may be eligible for a reward" and that "close partnerships with the researcher community make customers more secure and we play an integral role by sharing issues under Coordinated Vulnerability Disclosure").
As a response, we informed Microsoft that we cannot provide the company with additional details / codes pertaining to our PlayReady security research on Windows as this can only happen through a commercial agreement, not MSRC reporting channel (Apr 15, 2024).
The rationale for it is quite simple. The research took us nearly 9 months of work (on top of the 6 months of R&D done in 2022, which has been "consumed" and in some way ignored by the company). One more extra month needs to be added to this too (attacks #2-#4 and crypto proofs investigated due to platforms' avoidance to confirm the initial XOR key attack).
The new research embeds some potentially valuable IP / know-how, which we need to protect too (see "Additional materials" paragraph describing potentially unauthorised, commercial use of our original idea for a rogue subscriber detection / deactivation along Microsoft Bounty Terms and Conditions, which implicate commercial use with unknown payment terms, all non-negotiable and under Microsoft control). Finally, disclosure of our know-how / toolset to Microsoft might jeopardize our future projects targeting Windows OS platform.
On Oct 18, 2024, we notified Microsoft / PlayReady team that public disclosure is to be conducted in a way that will not make it possible to immediately exploit the issues.
Microsoft asked to share draft of the publication with the company and allow 2 weeks for review (Oct 23, 2024). We provided Microsoft with access to the complete research package comprising of a technical document, all toolsets with sources and test data (285MB ZIP file) on Nov 18, 2024 and free of any charge (two weeks prior to the planned disclosure). We indicated to Microsoft that sharing of the material was not done as part of MSRC vulnerability reporting process (thus no obligation for any confirmation / follow ups / rewards / confidentiality / implicit license granting, etc.), Microsoft was however informed that the research could be acquired by the company upon evaluation. We indicated to Microsoft that sharing of the research along draft of a publication with the company prior to the disclosure has been an exceptional courtesy (Google who rewarded us for App Engine research wasn't given that courtesy).
As inidicated in our public post announcing the disclosure, commercial companies do not pay bills / run business by waving a glossy "thank you from Microsoft" coupon at the cashier stand / checkout.
Microsoft's disinterest to get into any commercial talks over this research / avoidance of a commercial angle indicate some/or all of the following holds:
1) the company doesn't perceive our research in terms of any valuable (commercial) work
2) Microsoft is not willing to pay (or even negotiate conditions and payment) for a research exposing weaknesses in the "most trusted DRM technology by studios and content owners", the "Widest Deployed Content Protection Technology in the World", which is licensed by more than several hundred companies. It could be Microsoft is not willing to pay for the research as it took 9-10 months of work (no matter the result), but only a fraction of the actual time it took. Is Microsoft really expecting commercial companies to accept such terms ?
3) Microsoft expects to receive information about flaws in its products by strictly following Microsoft rules, these do not warrant any payment or IP protection for the reporting party, it looks more like "you follow our rules or forget about any payment", doesn't it ? Microsoft seems to forget who is the primary beneficient of a private / early vulnerability, exploit information and know-how.
For a contrast, 10 years ago we received $100k (*) in total from Google for our research exposing weaknesses in Google App Engine (above the initial $50k reward issued merely ~3 weeks following submission of the research to Google). The research of Google App Engine took us much less efforts...
Some streaming companies openly offer salaries of $100,000 - $700,000 range for remote Security Software Engineer roles (Netflix). If we followed this model, 10 months of work would correspond to $580k (assuming top range seems fair as we are the first to show successful PlayReady hack on Windows 10/11 x64). How does Microsoft Bug Bounty fit the above ? It obviously does not.
Finally, it's worth to keep in mind that Microsoft wants to charge users $30 for Another Year of Windows 10 Security Updates. So, it is ok for Microsoft to have Windows users pay for extra work of their SW devs / security engineers, but the company doesn't want to pay for the work of external parties clearly making work of its own personell much easier and security of its products better.
(*) back in 2015, we donated $10k out of our Google reward (matched / doubled by Google to $20k) to charity organization (shelter organization for poor children).
Our tests indicate that the following streaming platforms are affected:
The keys above should constitute a sufficient prove for the platforms mentioned to be able to confirm the attack. Yet, according to the SecurityWeek article, none of the platforms provided clear confirmation or denial of the keys upon inquiry. Amazon Prime Video reported the research to Microsoft for investigation and said that there is currently no evidence of misuse of the technique described in the research against the Prime Video platform. This along no strong denial from the platforms could be perceived as an indirect confirmation that posted keys correspond to real ones.
All licenses received during testing were issued with SL2000 security level, which indicate the default presence of "Software-DRM Clients" on Windows 10 and 11 (clients backed mostly with software means, secrets protected through software or hardware means).
Taking into account the technique used to extract plaintext value of content keys, we assume that key extraction might also work for some other platforms relying on SW Microsoft PlayReady technology in a Windows OS environment (VOD and Live TV services). We verified it to work for Canal+ Live TV services and the following 6 sample live TV channels available through it:
In general, the ability to extract plaintext value of a content key from a DRM system constitutes a base for considering it to be compromised. This is especially valid taking into account the amount of efforts at Microsoft end (vide 10 years of innovation and more than $1B invested) to make it hard to conduct static and dynamic analysis of PlayReady operation on Windows platform.
A successful cryptographic check proving that extracted key values correspond to real keys has been conducted for Canal+ Online, Netflix, HBO Max, Amazon Prime Video and Sky Showtime.
The check relies on a digital cryptographic signature verification. Such a signature is appended at the end of each license issued by PlayReady license server.
The crypto check works as following:
The above mechanism is also used by Microsoft to verify the correctness of decrypted content keys received from a license server. It relies on the fact that signature key is part of the same encrypted license blob as content key. Thus, successful extraction of a signature key implicates successful extraction of a content key.
In the context of no confirmation / denial from the platforms indicated above as being affected, the crypto check should constitute sufficient proof to support that claim alone.
Private encryption keys (obtained through attack #4 depicted below) provided additional confirmation for the validity of the keys extracted for each of the affected platform. In all cases content and signature keys decrypted with the use of a private ECC key matched the keys extracted by the sniffer tool.
The attack scenario makes it possible to extract plaintext values of content keys from a Protected Media Path process. The attack proceeds by exploiting a time window during which content keys have a XORed form - the plaintext value of such keys can be obtained by the means of a simple XOR operation with a magic 128-bit key sequence.
Our tests indicate that there are only two such magic key sequences used across Windows OS versions released since 2022 (one for Windows 10, the other for Windows 11).
The above has been confirmed on Windows 10 / 11 x64 systems across various builds from late 2022 till Dec 2024 (systems without and with HW DRM capability):
A screen snapshot illustrating a successful attach to unprotected MFPMP.EXE process and callstack dump taken at the time of a content key sniffer operation can be seen below. The screenshot has been taken on Windows 11 system with supported HW DRM capability disabled. It clearly shows the unprotected status of the MFPMP.EXE process.
There is yet another attack possible against Protected Media Path process that may result in the extraction of a plaintext content key value.
The attack has its origin in a white-box cryptography implementation. More specifically, one can devise plaintext content key from white-box crypto data structures of which goal is to make such a reconstruction difficult / not possible. This alone breaks one of the main security objective of white-box cryptography which is to protect the secret key (unbreakability).
Contrary to the initial (XOR key) attack, the white-box crypto attack is not limited to the narrow time window (white-box data structures need to be present for the time of a movie decryption / playback). Fixing it might require a completely new approach / implementation (current one is obviously flawed). In that context, white-box crypto attack seems to be more severe than the XOR key one.
We have come up with two attack scenarios that make it possible to extract private ECC keys used by a PlayReady client (Windows SW DRM scenario) for the communication with a license server and for the identity purposes.
More specifically, we successfully demonstrated the extraction of the following keys:
While PlayReady security is primary about security of content keys, ECC keys that make up client identity are even more important. Upon compromise, these keys can be used to mimic a PlayReady client outside of a Protected Media Path environment and regardless of the imposed security restrictions.
In that context, extraction of ECC keys used as part of a PlayReady client identity constitute an ultimate compromise of a PlayReady client on Windows ("escape" of the PMP environment, ability to request licenses and decrypt content keys).
The impact of a PlayReady client identity compromise has been already demonstrated by our research from 2022 (vide standalone toolkit mimicking STB device for license acquisition, movie download and decryption).
A proof for a successful extraction of a private ECC encryption key from a PlayReady identity file is shown in this log file.
It's also worth to mention that neither Microsoft, nor streaming platforms have any means to detect a compromised client identity.
The use of non-persistent licenses (licenses that are only present in memory, not stored on a disk) do not prevent this attack either.
WMRMECC256 Key / root key issue (attack #5)There is an architectural / design issue of PlayReady, which can be successfully exploited to gain access to license server by arbitrary clients. The problem has its origin in flat certificate namespace / reliance on a single root key in PlayReady along no auth at license server end by default (deemed as no bug by Microsoft).
PlayReady client certificates encountered in Windows 10 / 11 and CANAL+ STB device environments share a common feature. They are all digitally signed by the so called ECC256MSBCertRootIssuer Key (root key) identified by the following public component:
86 4D 61 CF F2 25 6E 42 2C 56 8B 3C 28 00 1C FB
3E 15 27 65 85 84 BA 05 21 B7 9B 18 28 D9 36 DE
1D 82 6A 8F C3 E6 E7 FA 7A 90 D5 CA 29 46 F1 F6
4A 2E FB 9F 5D CF FE 7E 43 4E B4 42 93 FA C5 AB
Additionally, all PlayReady clients in Windows 10 / 11 and CANAL+ STB device environments make use of the so called WMRMECC256 Key to securely deliver client identity to the license server. This key is identified by the following public component:
C8 B6 AF 16 EE 94 1A AD AA 53 89 B4 AF 2C 10 E3
56 BE 42 AF 17 5E F3 FA CE 93 25 4E 7B 0B 3D 9B
98 2B 27 B5 CB 23 41 32 6E 56 AA 85 7D BF D5 C6
34 CE 2C F9 EA 74 FC A8 F2 AF 59 57 EF EE A5 62
Such an approach (the use of shared root keys) implicates the following:
WMRMECC256 Key for client identity decryption purposes. Compromise of one provider can potentially impact other providers too (the ability to encrypt / decrypt client identities, the ability for MITM attacks / license server requests redirection and/or proxying),ECC256MSBCertRootIssuer Key.We exploited the above flat certificate namespace / reliance on a single root key (ECC256MSBCertRootIssuer Key) in PlayReady in the context of CANAL+ environment.
On Aug 12, 2024, the compromised STB certificate used by us to demonstrate the possibility of a massive piracy in CANAL+ environment has been finally revoked (two years after Microsoft notification and company's agreement that the cert should be treated as compromised).
Compromised device certificate revocation hasn't addressed the core of the issue though (no client auth at PlayReady license server end). It took us less than an hour to change the code of our POC (PlayReady Toolkit) in order to make it work again, successfully obtain licenses for content and download arbitrary movies from CANAL+ VOD library, all regardless of the certificate revocation.
We imported the identity file generated for Windows 10 PlayReady client to it (some arbitrary identity from Mar 2024) along private signing and encryption keys corresponding to it and obtained through attacks #3 and #4 (complete client identity compromise). This is illustrated below:
The end result was a fully functional POC and Windows PlayReady client working in what one would assume to be an isolated (and unrelated to Windows) PlayReady environment of CANAL+ set-top-boxes. Yet, Microsoft PlayReady license server successfully accepted and processed identity certificate chain associated with obfuscated keys and leaf certificates specific to Windows environment. This is illustrated on a picture below:
Such an operation of PlayReady license server makes any certificate revocations to be rather irrelevant (vide hundreds of millions of identities associated with Windows PlayReady clients and signed by ECC256MSBCertRootIssuer Key).
It is also worth to note that Windows client PlayReady certificates have no expiration time set (value -1). Their uniqueid 16-byte long field vector is set to 0 (sample Windows 10 client certificate). Such certificates content may impact both attribution and certificate revocation.
Finally, we also verified that Windows client PlayReady certificates associated by Windows CDM with Netflix, Amazon Prime Video or Sky Showtime services could be all successfully used for CANAL+ VOD piracy (Aug 15, 2024). Tested clients certificates were generated by Windows 10 in Mar/Apr 2024. This additionally illustrates the impact of the described issue.
PlayReady Communication Protocols include services for PlayReady clients (such as Secure Clock), device owner's services (Activation / Provisioning) and content service (License Server).
Back in 2022, we reported to Microsoft an issue pertaining to no auth at PlayReady license server end, which was evaluated by Microsoft as no bug.
There is yet another auth issue, which builds on the above and affects PlayReady Activation service used for initializing client identity certificates for Windows 10 / 11 clients.
PlayReady Activation service does not implement real authentication, but some form of obfuscated identification scheme where static (shared) data specific to PlayReady library is encrypted with the use of AES CTR algorithm and sent along the key material (randomly chosen) to the server for "authentication" purposes.
Arbitrary PlayReady identity can be requested by the client through public API and potentially abused for a successful license server access (such as depicted in attack #5 above).
We verified that Microsoft PlayReady Activation service doesn't fully check the validity of the HW / MF system identity sent as part of the request. As a result, arbitrary fake identity (such as random one) can be used for leaf certificate generation (and client identification). This can impact attribution (identification of rogue clients).
Finally, there seems to be no limits on the number of PlayReady identities requested for a given system identifier (such as fake one) or in a given time frame. This can impact security of the whole ecosystem (vide massive valid leaf certificates generation that can be abused and that are hard to follow for revocation).
A ZIP archive containing sample fake PlayReady client identity (corresponding to FAKE.PR.ID string) generated through the abuse of the Activation protocol can be downloaded from this location.
We would like to emphasize that the project should not be deemed as complete or illustrating all attack / toolset ideas we came across during investigation.
There are at least 3 potential attacks and 2 ideas for toolsets that we haven't verified in practice.
At this point of time, we have no reason to dig deeper / prove PlayReady is broken even more taking into account what has been shown so far (Microsoft PlayReady broken / shown to provide no security of content in both SAT TV provider and Windows environments). We cannot exclude having another look some time in the future.
We have not noticed / are not aware of any fixes / security improvements done by Microsoft with respect to the issues uncovered (the most recent tests from Nov 19, 2024 confirmed successful content key sniffer operation and attacks #1-4). This indicates potential failure to locate / address the root cause of the issues by Microsoft engineers (nearly 8 months following wider public notification of the research results)
We decided to give Microsoft (a company consisting of 100,000+ software engineers, with access to all the know-how, internal docs and source codes) approx. the same amount of time to fix / address the issues as it took us (a 1 man shop relying on binaries and public info only) to analyze and reverse engineer the technology, discover the issues, develop illustrating POCs and dedicated toolsets.
With respect to the above, the disclosure of a technical document pertaining to the issues uncovered took place on Dec 03, 2024.
We believe the disclosure provides both important contribution along a valuable perspective on the state of the art / security provided by PlayReady content security technology (vide the nature of the issues uncovered / verification of vendor's claims).
On Jun 11, 2024 Microsoft engineer posted on a public forum information about a crash experienced with Apple TV service on a Surface Pro 9 device.
The post had an attachment - a 771MB file (4GB unpacked), which leaked internal code (260+ files) pertaining to Microsoft PlayReady such as the following:
In general the above leaked key information related to PlayReady internals and implementation. Leaked data should be sufficient to completely reverse engineer Microsoft PlayReady content protection technology operation (HW based one in particular).
As such, on Jun 12, 2024 we notified Microsoft PlayReady team and MSRC about the leak shortly following its discovery.
We verified that it is possible to build Windows.Media.Protection.PlayReady.dll library (debug build and without Warbird encryption / obfuscation) from the leaked code. A follow up post by another Microsoft engineer provided guidelines on how to proceed with the building process.
We also verified that Microsoft Symbol Server didn’t block request for PDB file corresponding to Microsoft internal warbird.dll binary (another leak / bug at Microsoft end).
The leak violated Microsoft's own guidelines for posting link repro information in public. These guidlines clearly state the following among others:
While Microsoft removed the post (within 12 hours from the notification), the company hasn't addressed the leak itself (this took place 2 weeks later).
On Jun 26, 2024, MSRC informed us that "upon investigation, the company determined that this is not considered a security vulnerability for servicing, since the post was already removed". We confirmed that the leak file was finally taken down by Microsoft (not available for download any more) around that time too.
It's worth to note that while Microsoft claimed no security vulnerability for servicing, the company did block access to ZIP archives accompanying posts of company employess sent to VS Developer Community portal such as this one (candidate posts could be searched with the use of a web query, ZIP archives posted by MSFT users could be also discovered in an automatic way). These were likely deemed security risk due to potentially leaking internal code and/or credentials (sometimes present in memory crashes).
The described leaks (along their handling) are yet another manifestation of what we have been already aware of - the problems and inconsistencies observed at Microsoft end with respect to PlayReady security and the way secrecy of the implementation is implemented and/or maintained by the company.
A worth to read summary on implications, future prospects and considerations regarding the leak for Microsoft and other companies can be found in Red Hot Cyber article.
Due to the open / developer nature of the Windows platform, a web browser alone (or its custom plugin) is completely sufficient for the exploitation of a compromised PlayReady identity (attack #4).
Sample decryption of a license server response acquired with the use of a web browser (its built-in network monitoring functionality / developer console) is illustrated in this log file (HBO Max and Wonka movie case, May 11 2024).
Successful use of a web browser as an exploit tool has been verified for all affected platforms and Live TV channels depicted above. This includes Netflix, which uses additional encryption mechanism for a communication with a license server. This does not prevent the attacker from acquiring PlayReady license server responses from the browser in clear as illustrated by the screenshot below:
Netflix license decryption with the use of a compromised identity is illustrated by the following screenshot, which yet again reveals same key as in posted crypto proof / sample keys files:
We verified that content key extraction can be also performed in an offline manner. What is needed for that purpose are the encrypted license blobs and a client identity file.
In that context, a theft of a client identity and accompanying license store files from a user system does constitute a potential risk too (Windows 10 / 11 and SW DRM scenario).
The risk related to unauthenticated Content Delivery Network (CDN) has been signalled by us at the time of 2022 research. Yet, we noticed that some providers still rely on publicly available CDN (Canal+ and Orange Web Cache scenario).
Public CDN makes it difficult to detect anomalous and/or unauthorised download behaviours.
Even though the content is encrypted, it does carry valuable information. A leak or extraction of a content key (such as demonstrated through this research) may result in the information to become immediately decrypted and compromised.
The above makes protection of content keys even more important (and content keys extraction even more severe).
It's worth to note that validity of content keys issued for tested VOD content was set as following:
All live TV channels tested (Canal+ Online service) had key validity set to 8 hours.
These validity times are far longer than the validity of the decryption key (the so called Control Word key) used in a digital satellite TV (valid for 10 seconds only). Yet, sharing of the keys has been a significant problem for SAT TV providers.
Validity times implicate the exploitation window in case of content keys leak or extraction (how frequently the keys would need to be extracted by attackers for sharing before they get changed).
In general, it is questionable whether VOD and LiveTV content keys get changed at all. Our tests indicate this might not be the case. For instance, license data for "Boska Florence" movie available through Canal+ Online service carried the same content key on Mar 21, 2024 and May 11, 2024. This implicates key validity beyond initially granted license period (1 month). Similarly, same content keys were issued on Apr 24 and May 11, 2024 (beyond the designated 8 hours license period) for all previously mentioned (tested) Live TV channels. Finally, same results were obtained for other platforms too (no key change for content accessed on Apr 04 and Apr 28, 2024, this is visible in posted crypto proof / sample keys files).
Custom DRM system products or services such as multi-drm or cloud-drm ones are usually offered by Microsoft's license service and system integration partners. These products support Microsoft PlayReady among other major DRM systems. They might not be able to detect or prevent the attacks either if they are built on-top of Microsoft PlayReady (if they act as wrappers / proxies for the PlayReady protocol and original Microsoft PlayReady Windows client is not replaced, which could be the case for compatibility / integration reasons).
Public sources and/or data acquired by our end implicates that watermarking might be implemented by some streaming platforms.
It is important to state that watermarking is a forensic mechanism though. As such, it cannot protect against attacks aimed at DRM systems such as content key or identity compromise. Watermarking can facilitate tracking source of a leaked content though.
While watermarking is far beyond the scope of this research, one should be aware of its limits too. Watermarking operation requires that content gets leaked at some point of time or that attribution is always possible at the time of a CDN access (or other watermarking application location). This is not usually the case. Just to mention content access solely for online viewing (through content key sharing), public CDN (with no auth) or several rogue subscribers working together with the aim to both discover the operation of a watermark and to break it (by removing watermarks from A/V segments and/or combining the segments in the order that would not reveal or confuse the identity of the user, such a theoretical attack scenario might work against some watermarking solutions).
Streaming / VOD platforms that are either dissatisfied with PlayReady security or would like to implement a temporary mitigation might consider transition to / enforcement of other widely supported (by web browsers applications) content protection technologies.
The research shows that the underlying technology such as Microsoft PlayReady can constitute a significant weak point. As such, it should not be ignored if streaming platforms are concerned about security of content.
The research also serves as a reminder that PlayReady content protection implemented in software and on a client side has little chances of a "survival" (understood as a state of not being successfully reverse engineered and compromised). In that context, this is vendor’s responsibility to constantly increase the bar and with the use of all available technological means.
One needs to keep in mind that a cost for a streaming platform subscription is in the range of 10-15 EUR (Poland). But, streaming platforms need to secure assets, which in some cases can generate nearly a billion in profits alone (vide Oppenheimer movie Box Office data, of which key is part of the posted key samples).
The attack that is able to extract content keys to premium movies for an arbitrary streaming platform requires just one rogue subscriber.
Content key extraction is also one of the worst things that can happen from a content security point of view as extracted keys can be shared online, they can be used to access premium video content without paying a subscription fee or decrypt and distribute movies over the Internet. Content key extraction and its impact is further explained in this blog post.
Some changes have been observed and information received with respect to "Terms of Use" service agreements of some streaming platforms / video services.
On 23 Apr 2024, a message has been received from Sky Showtime (to e-mail subscription address), which informs about changes to the terms of use of the service. The new terms seem to free Sky Showtime from a responsibility (liability) related to no reception of the programming (service) and no support for old applications versions (users might need to apply latest application / OS upgrades in order to be able to continue using Sky Showtime streaming services).
It's also worth to mention that Sky Terms and Conditions have a separate "Microsoft PlayReady Notice" stating that "if the PlayReady technology fails to protect the content, content owners may require the service to restrict or prevent the delivery of protected content to specified devices or PC software applications".
The above could implicate potential disruptions in some streaming services reception occurring as a result of a delivery of a fix / mitigation for this (or future) DRM hack or a switch off of the affected content protection technology.
On Dec 12, 2024, Roku company annonced that it will remove support for the PlayReady DRM in the United States, Canada, and Latin America by the end of Jun 2025. The company indicated that arbitrary Roku apps should migrate to Widevine DRM to protect content.
It is not clear if Roku's move is due to the lost of trust to Microsoft PlayReady technology as a content protection technology or a more general shift of the streaming industry towards using Widevine due to its favorable royalty-free approach.
On Dec 18, 2024, Media Rights Technologies company filed a lawsuit against Microsoft for alleged intellectual property theft with PlayReady DRM being at its focus.
Back in Apr 2024, we have been contacted by a US attorney representing Media Rights Technologies (MRT) and interested in our PlayReady research(*), but we refused to provide any assistance / consultation for the usual principal reasons (no information sharing with any 3rd party prior to the disclosure, Microsoft as a vendor being the only party potentially eligible for such a sharing).
If our Dec 03, 2023 publication has given extra fuel for the lawsuit to materialize and Microsoft loses it, that would constitute an epic failure at Microsoft end (vide company's disinterest to discuss commercial access to / acqusition of our research).
(*) according to the court documents, MRT experts were able to reverse engineer some, but still not all of Microsoft’s PMP code.
The following technical materials are available with respect to the security analysis conducted for Microsoft Warbird and PMP technologies.
