WideLeak: How Over-the-Top Platforms Fail in Android
WideLeak: How Over-the-Top Platforms Fail in Android
Abstract—Nowadays, most content providers rely on DRM business ecosystem. Android has anticipated such a trend,
(Digital Right Management) to protect media from illegal dis- and provided a DRM framework allowing the decryption of
tribution. Becoming a major platform for streaming, Android protected media streams. This framework supports many DRM
provides its own DRM framework that does not comply with ex-
isting DRM standards. Thus, OTT (over-the-top) platforms need systems; which DRM a device supports varies regarding the
to adapt their apps to suit Android design, despite a fragmented device manufacturer. The most dominant one is Widevine [4],
ecosystem and little public documentation. Unfortunately, the which is also deployed on web browsers (eg., Chrome and
security implications of how OTT apps leverage Widevine, the Firefox), and smart TVs among others.
most popular Android DRM, have not been studied yet. The ecosystem of DRM in smartphones is quite peculiar.
In this paper, we report the first experimental study on the
state of Widevine use in the wild. Our study explores OTT First of all, starting from Android 7, Widevine takes advantage
compliance with Widevine guidelines regarding asset protection of hardware-backed security, such as TrustZone-based Trusted
and legacy phone support. With the evaluation of premium OTT Execution Environment (TEE) [5]. In the past decade, much
apps, our experiments bring to light that most apps adopt weak work has been done to evaluate the security of software-
and potentially vulnerable practices. We illustrate our findings only DRM solutions based on obfuscation and cryptographic
by showing how to easily recover media content from many OTT
apps, including Netflix. whiteboxes [6], [7]. TEE-based Widevine arguably provides
Index Terms—Android, Digital Right Management, Over-The- stronger protection, despite some successful attacks in the
Top, Widevine literature [8]–[11]. Second, the Android DRM API, is quite
different from the standardized EME specifications that are
I. I NTRODUCTION defined for the Web. Therefore, apps developers need to
The world almost fully moved over earlier days of owning rewrite a large part of their code, which may lead to incon-
media. Instead, many people watch videos on over-the-top sistency in security practices. This is especially true given
platforms (OTT), such as Netflix and Amazon Prime, that that Widevine public documentations are sparse, which limits
distribute multimedia content over the Internet. Today, the community discussions and sharing. Third, any DRM system
most prevalent model is subscription-based services, where has a long history of hacking and patching. Thus, they require
media can be played as often as the user wishes, but becomes to be updated in a regular basis. Unfortunately, it is not
unavailable when a user stops paying for the service. The common that smartphones receive a long-term support from
large distribution of media in what can sometimes be hostile their manufacturers. Even Google used to only guarantee a
environments, like untrusted devices, creates challenges for three-year support for their Pixels [12], before Pixel 6.
content producers. The main challenge remains piracy; in In order to address such concerns, Widevine has issued
2020, the OTT market size was estimated at $13.9 billion and a set of guidelines and recommendations to follow by OTT
expected to reach $139 billion by 2028 [1]. apps. However, little has been done to explore how these
Thus, content providers rely on DRM (Digital Right Man- apps actually implement Widevine recommendations to protect
agement), which is a technology that aims to protect media their contents. In this paper, we focus on whether the security
from illegal distribution. Modern DRMs ship content in an features offered by Widevine are properly leveraged. For
encrypted form, and then control their decryption through instance, we empirically study if apps actually encrypt their
authorized players on users’ devices. DRM systems are often contents with Widevine keys. One might argue about the
cried out because of their insecurity. However, the recent relevance of such a question, especially that OTT developers
surge of OTT platforms has led to ongoing adoption and are well aware of piracy threats. However, our evaluation
evolution of such systems. For instance, World Wide Web shows that, for example, Netflix, which is the leader app with
Consortium (W3C) has published, despite being criticized [2], more than one billion installations, does not even encrypt audio
the Encrypted Media Extensions (EME) [3], as the first official tracks and just delivers them in clear. Our goal is to identify
Web standard for DRM. Android devices have become a missing conformance of OTT apps regarding three Widevine
major platform for streaming content consumption. This has security guidelines: content protection, usage of encryption
drawn interests from OTT platforms to develop mobile apps keys, and support of discontinued devices.
in order to reach a large number of audience in a thriving We performed our evaluation on premium OTT apps. One
might expect that Android has defined their DRM API, while end, they mostly rely on closed-source proprietary protection
taking into account Widevine guidelines, since both is owned mechanisms. Thus, every DRM system provides its custom
by Google. A surprising result of our work is to uncover that CDM with its own interface.
there is some gap between actual implementation practices
and what Widevine wants. By switching to TEE-based by B. Android DRM API
default, the hope was that content piracy becomes old news. In order to cope with this fragmented ecosystem, An-
Nevertheless, we show that OTT apps might introduce new droid offers a unified API in Java/Kotlin for DRM systems.
attack vectors rendering Widevine protection ineffective. We Starting from API level 18, this is implemented by some
demonstrate the practical impact of our dire observations by HAL (Hardware Abstraction Layer) module called Media
obtaining DRM-free contents from six popular OTT apps, DRM Server that abstracts the actual running DRM from the
including Netflix, Hulu and Showtime. We insist that we do programming interface used by OTT apps. The Android DRM
not look to introduce yet-another attack against DRM systems, API mainly consists of two modules: Media DRM and Media
but to better frame the misunderstood pitfalls of the rapidly Crypto. The Media DRM is used to communicate with License
growing Android DRM. We assess their prevalence, showing Servers and to manage keys for a given media. As for Media
a rather concerning scenario. Crypto, it is used to perform decryption. The DRM APIs
Our contributions can be summarized as follows: support the ISO/IEC 23002-7: Common Encryption standard
1) New findings and understandings. We conducted the first (CENC) [13], but implement other encryption schemes.
empirical study on how OTT apps leverage Widevine Playing encrypted content when leveraging DASH (Dy-
in Android. Notably, we automate apps monitoring by namic Adaptive Streaming over HTTP) is summarized in
intercepting all calls to the Widevine process related to Figure 1 and works as follows. First, the app constructs a
the DRM API. Our study reveals that almost no OTT Media DRM object and opens a new session. A Media Crypto
app follows the Widevine recommendations in terms of object is then constructed and bound to the opened session.
cryptographic operations and revocation policy. Next, Media DRM retrieves keys (aka licenses) from the
2) Real-world impact. To confirm the potential threats of License Server. The obtained keys are only accessible through
our findings, we shed light on how certain practices Media Crypto. Indeed, the encrypted content is decrypted by
allow an easy long-term compromise. We show that old a Media Codec instance to which the Media Crypto object
still supported Widevine can be easily broken by recov- was registered. Thus, MovieStealer as defined in [6] does not
ering their software-only root of trust. Then, we reverse- work anymore, since the app has never access to the decrypted
engineered the proprietary cryptographic operations of buffer. In addition to the DASH mode, the DRM APIs provide
Widevine to automatically obtain the decryption keys of the ability to establish a secure session to protect arbitrary data.
any media. Our work results in CVE-2021-0639.
C. Google Widevine
3) Our automated monitoring tool and Proof-of-Concept
source code are available online1 for reproducibility Widevine is a DRM solution acquired by Google in 2010.
purpose and to assist future work on this topic. Its earlier version (supported up to Android 5.1) worked only
Roadmap. The rest of the paper is organized as follows: with the proprietary format .wmv. The current version, called
section II presents the background information for our study. Widevine Modular, implements various standards, including
In section III, we present the research questions that we ex- MPEG-DASH and CENC. Widevine Modular, or henceforth
plore and that are related to Widevine security guidelines. Our simply Widevine, is supported on several platforms: Android
findings and their practical impacts can be found in section IV. (4.4+), Android TVs, Smart TVs, and Web Browsers (e.g.,
Section V details the limitations and future directions of this Chrome, Firefox and Edge). Widevine defines three security
work. Section VI surveys the prior related research. levels: L1, L2 and L3, where L1 is considered for playing HD
videos. At L1, all operations take place inside a TEE. L2 and
II. BACKGROUND L3 are used when the TEE is not available. Android Widevine
A. DRM Systems does not propose. For L3, the CDM is processed outside the
Modern DRM systems allow content providers to encrypt TEE. Being less secure, L3 can only play sub-HD content.
their media, and control who can decrypt them. The related In Android, Widevine comes as a dynamically loadable
architecture involves three parties: a Content Delivery Network HAL plugin. Widevine is not open-source; only provided as
(CDN) supplying encrypted content, a License Server provid- binary code. In a top down architecture, Widevine-backed
ing the necessary keys to decrypt such a content, and a DRM Android DRM works as follows. All calls to the DRM
module on the user device to retrieve these keys. For flexibility API go through some Java Native Interface (JNI) layer
purposes, the part performing sensitive operations, such as via the libmedia_jni.so library. Instantiated by the
decryption and license request, is implemented separately and mediadrmserver process, the Media DRM Server receives
called CDM or Content Decryption Module. Obviously, CDMs these calls, and accordingly, reaches Widevine using HAL.
are required to protect the keys while using them. To this Any communication with Widevine first goes to its specific
library such as libwvdrmengine.so or libwvhidl.so.
1 https://github.com/Avalonswanderer/widevinel3 Android PoC In L3, no further component is involved. As for L1, whenever
2
Media DRM
Application CDM
Server
MediaDRM(UUID)
Initialize()
openSession()
openSession()
MediaDRM
getKeyRequest()
getKeyRequest()
License License
provideKeyResponse()
Server provideKeyResponse
Get Media
Media
CDN queueSecureInputBuffer()
MediaCrypto
Decrypt()
CDM is required, this library calls liboemcrypto.so that less straightforward. Indeed, in most OTT apps, users are
sends the related requests to the Widevine TEE trustlet. allowed to change the language (i.e., audio and subtitles) at any
moment without negatively impacting users’ experience. Thus,
III. R ESEARCH Q UESTION video tracks are obtained only once, while subtitles or audio
are downloaded again for each language selection. In practice,
Despite the recent surge of streaming on Android devices,
these parts are sent separately, and thus might be differently
little has been done to understand how Android most popular
protected depending on the OTT app that might choose for
DRM, namely Widevine, is used in practice within the Android
instance to only protect the video and not the audio. Moreover,
DRM framework. Our paper takes the first step in this direc-
the Android documentation of DRM API does not clearly
tion and explores the implementation choices of OTT apps
explain this common scenario, which might inadvertently lead
regarding Widevine security guidelines. To better frame the
to unprotected contents. Our work investigates whether all
scope of our study, we also quantify the usage of Widevine
media assets are DRM-protected for OTT apps: video, audio
in the wild. Our goal is to gain insights into how do OTT
and subtitle tracks.
apps follow Widevine recommendations to protect content? By
addressing this question, we show OTT apps would introduce Q3: Do OTT apps use multiple keys for content en-
new attacks vectors that render DRM protection ineffective cryption? Widevine has issued a set of recommendations
while leveraging Widevine. Accordingly, we aim to answer concerning DRM cryptographic key usage [15] (similar ones
the following four questions: are defined by W3C DRM standard EME [16] adopted by
Q1: How often do OTT apps rely on Widevine? The main Widevine [17]). These recommendations state that video with
benefit of the unified Android DRM API is that developers different quality settings should be encrypted using a different
can effortlessly rely on Widevine, or any Android integrated key, and that audio files should be protected by an additional
DRM, to protect content. The first question we intend to key. Obviously, such guidelines are defined to minimize the
answer is how effective this API is for Widevine adoption. impact of a content key recovery, and therefore should be
In particular, we intend to quantify the OTT apps leveraging enforced. However, the use of multiple keys might make the
Widevine or custom DRM implementation like in Indian music code to manage more complex if no external media playback
industry [14]. Because most apps do not disclose whether library is used, such as ExoPlayer [18]. Consequently, there
Widevine is supported (an official list can be found in [4]), might be some tension between Widevine recommendations
we need to fill this gap by conducting several experiments for about using multiple keys and apps implementations. In this
both L1 and L3. The support for L1 is an important security paper, we intend to quantify the DRM keys received for each
trait, since it resists most attacks against software-based DRM. media. If an app does not encrypt audio tracks, or does not
Q2: Do OTT apps encrypt their media contents using use distinct keys, we note such a practice as minimal.
Widevine? In any DRM ecosystem, CDN servers deliver Q4: Do OTT apps still support L3 outdated devices?
media contents to OTT apps. In a standard work flow, these Widevine regularly updates their software. For instance, the
contents are encrypted, and DRM modules in users’ devices release cadence for Android CDM is annual (per Android
(aka CDM) require to decrypt them first. Nevertheless, the release). In order to keep away some vulnerable implemen-
prevailing way of media consumption makes this operation tations, Widevine may revoke devices due to non-compliance
3
with their security rules, e.g. no longer receiving security some of our questions, we will still need to note OTT-
update. Nevertheless, OTT apps can ignore such revocation specific information. Accordingly, we design our methodology
and deliver content keys to users [15]. This practice is not considering a human in the loop, which also implies to
recommended, since old Widevine implementations could be limit the number of evaluated apps. Furthermore, the lack
broken at some point without any security patch. The problem of documentation on Widevine made the manual analysis
of outdated devices is not straightforward, because following necessary before implementing our monitoring tool.
revocation rules restricts the number of OTT potential clients. DRM API Monitoring. Here, we take a two-pronged method-
Here, we identify to which extent OTT apps still support po- ology. First, we decompile the Java classes of the evalu-
tentially vulnerable Android devices to underline the delicate ated OTT apps to identify some of the included Android
trade-off between availability and security. We emphasize that classes. More specifically, we scan all calls to MediaDrm and
this problem is quite different from the fact that Widevine, by MediaCrypto methods that are required within a Widevine
design, supports L3 that is inherently bypassable [19]. Indeed, session. However, we are aware that some apps might include
breaking into legacy L3 should be easier than the latest L3 some dead code. Thus, in order to err on the side of soundness
version. In addition, it should have longer impact, because no (i.e., low false positives), we monitored Widevine component
vulnerability will be patched. functions linked to the Android Media DRM framework
while playing protected content. Indeed, for both L1 and L3
IV. E XPERIMENTAL E VALUATION security levels, we intercept and note any function called
As stated previously, our goal is to analyze the implemen- within the CDM process linked to the Widevine protocol
tation choices of OTT apps while leveraging Widevine. In (namely _oeccXX functions), loaded in mediadrmserver
this section, we first describe our experiment setup to address starting from Android 7 and mediaserver otherwise.
our research questions, and review the methodology that we To this end, we leverage Frida [22] to hook CDM calls.
used to perform our evaluation. Then, we present our findings. The use of L1 is confirmed whenever the control flow
Finally, we show how some of the existing practices can be reaches liboemcrypto.so, since L3 is characterized by
abused to bypass DRM by targeting its weakest link. the fact that all calls stay within libwvdrmengine.so (the
Widevine library name can differ between devices). In our
A. Evaluated Apps Github2 , we provide a Frida script that automates OTT app
monitoring. Moreover, to allow more in-depth analysis, we
In our work, we evaluate the following Android OTT apps
dumped input and output buffers related to various functions,
(with their number of installation in millions at the time
including non DASH mode (e.g., generic encrypt and decrypt).
of writing): Netflix (1,000M+), Disney+ (100M+), Amazon
Prime Video (100M+), Hulu (50M+), HBO Max (10M+), Content Protection. By protection, we mean cryptographic
Starz (10M+), myCANAL (10M+), Showtime (5M+), OCS encryption by Widevine. When an OTT app asks for some
(1M+), and Salto (1M+). media, the related CDN server does not deliver it directly.
The selection was based on the list of Widevine clients [4] Instead, it sends several URI links that are used by apps
as well as their popularity on the Google Play Store. Unfor- to download all required video, audio and subtitle tracks.
tunately, we could not extend our study to more apps because Contents might come encrypted or clear. Our approach mainly
of platforms restricting their client to register with a bank consists of obtaining these URI links for each OTT app, to
account in a particular country. However, our code can be determine whether the downloaded contents are protected or
easily applied for other apps. not. For this purpose, we just rely on video or audio players to
read the downloaded files. As for subtitles, we check whether
B. Methodology they contain ascii characters for English ones.
The main challenge in our approach is that apps also protect
We could have answered all our research questions by look-
these URI links, and thus we have to find them. First, we
ing directly into OTT apps. However, we did not consider such
keep monitoring all function calls to the CDM process, and
an option for two main reasons. First, they are closed-source,
more particularly non DASH mode, as it might be used as
and their design and implementation differ considerably. This
a secure channel to protect arbitrary data. In addition, we
would have required substantial amount of reverse engineering
intercept the received network packets when selecting and
that is specific for each app. Second, most evaluated OTT apps
displaying protected content to recover media URI and Media
apply anti-debugging techniques such as time checking [20],
Presentation Description (MPD) files. Because of the use of
or rely on SafetyNet [21] to hinder any dynamic analysis.
TLS, we require to implement SSL repinning technique using
Therefore, we preferred to focus on the Widevine HAL plugin.
Burp [23] and Frida. Moreover, we note the used key IDs for
In particular, we precisely identify the work flow for each
each content by parsing the MPD files and their related OTT-
app regarding Figure 1, by monitoring all Widevine activities
specific metadata. Finally, we perform our experiments for L1
involved in the DRM API. This approach presents multiples
and L3 to assess that it does not depend on security level.
advantages. Indeed, it bypasses all protection mechanisms
implemented by apps to block dynamic analysis. Moreover,
it can be easily automated. Nevertheless, in order to address 2 https://github.com/Avalonswanderer/widevinel3 Android PoC
4
TABLE I
W IDEVINE U SAGE AND A SSET PROTECTIONS BY OTT S
Outdated Device. Our approach is straightforward: we use In fact, for these apps, audio in any language can be played
Nexus 5 phone to display content. Released in 2013, it did anywhere without any OTT account.
not receive an official Android 7.0 in 2016, and thus Android Q3. As noted in Q2, most OTT apps protect their video
6.0.1 becomes its last update. It runs Widevine in L3 mode and audio. Here, we explore whether they are encrypted with
with CDM version 3.1.0. This is quite old, as the current different keys. Of course, we cannot tell by just looking into
CDM version is 15.0 in 2021. In our experiments, we attempt the encrypted files. Thus, as explained previously, we analyzed
to display some media content on Nexus 5. We also keep some metadata indicating the identifier for every decryption
monitoring all calls to Widevine. We distinguish two cases: keys. Our observations show that all evaluated OTT apps
(1) the app can display Widevine protected content, and (2) properly encrypt their videos with different keys depending
the app uses Widevine, but no content can be displayed. on the resolution. This implies that we cannot trivially recover
C. Results HD resolution, while breaking L3 mode. However, given the
same resolution and the same content, many OTT apps are
Our results are summarized in Table I.
confirmed to use the same key for both video and audio, which
Q1. All the evaluated apps depend on Widevine for content
is not recommended for DRM solutions by Widevine or EME.
playback, and not on some custom app-specific DRM solution.
As for apps that do not protect audio, namely Netflix, myCanal
One exception is Amazon Prime Video using an embedded
and Salto, Widevine also considers this practice as a minimal
Widevine library when just the L3 software-only mode is
recommendation setting. Only Amazon Prime Video strictly
available. We also find that the L1 TEE-based mode is popular,
follows Widevine recommendation by always using distinct
unlike what was predicted in [7]. This is an important trend,
keys. For Hulu and HBO Max, we were unfortunately not able
since TEE becomes mandatory starting from Android 7.
Q2. Based on our findings about Widevine usage, we check to conclude our analyses due to some regional restrictions.
whether OTT apps protect their contents. We first look for Q4. On our Nexus 5 with its Android 6, the installation
URI links related to content assets: video, audio and subtitles. process succeeds for all OTT apps. Connected to a valid OTT
First, using public Frida resources, we succeeded in bypassing account, we attempted to display some media. We notice that
SSL repinning on all OTT apps, which shows how ineffective Disney+, HBO Max and Starz reject to provision Widevine
such a security mechanism is. Then, we analyzed the network with valid licenses, implying that Nexus 5 is actually revoked.
packets for each app. Once we found the URI links for a Thus, media contents and their decryption keys were not even
given media, we downloaded the associated assets and checked delivered to our Nexus 5. However, the remaining seven apps
their protection status. A notable exception is Netflix that do provision Nexus 5 as a valid device, and therefore display
creates a secure channel between Widevine and the CDN the required media. One restriction was on the video quality,
to protect URIs through the non DASH Widevine API. This since Nexus 5 only supports L3, hence no HD video.
protection does not prevent us from recovering Netflix links by Insights and Learned Lessons. Our evaluation highlights
intercepting the output of some Widevine functions. Overall, the large adoption of Widevine by OTT apps on Android
we obtained all URI links for all OTT apps, except the subtitles devices. More importantly, we find that TEE-backed Widevine
URI for Hulu and Starz. Our investigation finds that video is widely leveraged thanks to the unified Android DRM API.
tracks are always encrypted, contrary to subtitles that are This shows that OTT apps are aware of piracy threats, and
always in clear (we could not confirm this for Hulu and Starz). therefore look to rely on modern security technologies, such
The case of audio tracks is more peculiar. Most OTT apps as TEE. However, we also find that this does not prevent
encrypt their audio, except for Netflix, myCanal and Salto. developers from opting for bad security practices. Indeed, OTT
5
apps do not protect subtitles. There might be two reasons for specific keybox structure (e.g., magic number). Thus, we
this. First, OTT frameworks do not consider subtitles as a succeeded in recovering the L3 keybox on our deprecated
valuable asset to protect. Second, there is no API to deal Nexus 5 due to an insecure storage of sensitive information
with encrypted subtitles in the Android DRM API. This might (CWE-922), that lead to our CVE-2021-0639.3
also uncover the rational behind why most apps do not follow Once we recovered the keybox, we were able to obtain the
Widevine recommendation to use distinct keys for video and provisioned Device RSA Key. Then, we mimic the rest of the
audio. The case of subtitles is more special though. Indeed, key ladder by intercepting Widevine function arguments to
we notice that many apps call DRM API through ExoPlayer recover derivation buffers and encrypted keys. We implement
as recommended by Widevine [17]. This playback library this key ladder to automatically recover the media-related Con-
proposes some API allowing developers to provide encrypted tent Key. During our experiments, we found out that OTT apps
audio and video, but not subtitles. However, this API is not yet use the same keys for all their subscribers for a given media.
widely used with different keys. We highlight an unexpected Finally, we use MPEG-CENC [13] to decrypt all protected
result in our study: Netflix does not protect audio tracks. contents. With some processing, we reconstruct the pirated
During our responsible disclosure, we discovered that Netflix media and play it on another device (i.e., personal computer)
was not even aware of that, because they believed that non- without any OTT account. Since keys depend on the required
Dash mode was sufficient. App developers should not take all quality and all media in our experiments was requested from
the blame, since the Android API does not make it easy to Widevine L3, the best quality that we get is unsurprisingly
implement Widevine guidelines. However, we think that our 960x540, which is qHD (quarter high definition).
results are surprising, since Widevine recommends ExoPlayer Our PoC (proof of concept) of the key ladder can be
providing a demo app with best practices [18]. found in our GitHub4 . Following our ethical approach, we
Finally, we shed light into the problem of license dis- only provide the implementation of the key ladder without
tribution. We notice that many OTT apps care more about the associated Device RSA Key, nor keybox. Thus, nobody
reaching more clients than applying the revocation rules of can use it to actually pirate OTT contents. Note that our PoC
Widevine: they allow the playback of protected content on works for both L1 and L3. However, we only applied it on
devices no longer receiving security update. Note that most Widevine L3. Our purpose is not to define yet another attack
Android devices have short security update support period with against DRM systems, but to show that some outdated L3
for instance three years for Google Pixels [12] and five only security protection can lead to a simple long-term compromise
for the latest model. This might seem anecdotal, but we will because of discontinued devices. We stress the fact that there is
show in subsection IV-D how an attacker might exploit a weak currently no clear solutions to the upgradeability of deprecated
Widevine implementation to recover media contents. phones, even if the situation might be improved in the future.
For this reason, we believe that OTT apps must strictly abide
D. Practical Impact
to Widevide revocation rules to avoid piracy.
We argue that discontinued phones constitute one of the
weakest link in the DRM ecosystem. Indeed, the threat model V. D ISCUSSION
of DRM includes attackers that have full control on their A. Responsible Disclosure
devices. This is due to the fact that the same media, with
different resolution, is played everywhere, and the only incen- Our findings have been timely reported to all concerned
tive of an attacker is to recover that media, regardless of the parties following their responsible disclosure process. Netflix
targeted device. We demonstrate the practical impact of our was quite responsive and we got rewarded via their bug
results by obtaining DRM-free contents from all OTT apps bounty program. Regarding Google Widevine, our security
still supporting old devices (except Amazon). To do so, we report was assigned with the highest priority within the Google
first analyzed Widevine internal key ladder from its root of Vulnerability Reward Program (VRP). The Widevine security
trust to content decryption key. By reverse engineering, we team investigated our findings and issued a patch to mitigate
found three main keys: our identified flaws. Google assigned the CVE ID ’CVE-2021-
0639’ for us, and acknowledged us in the Google Hall of Fame
• Keybox: 128-byte structure including a magic number
and the Android Security Acknowledgments. Our goal is to
and a 128-bit AES Device Key. This key is installed by
improve the state-of-the-art knowledge of DRM internals and
the manufacturer, and constitutes the root of trust (RoT).
not to provide copyright infringement tools.
• Device RSA Key: 2048-bit private RSA key. This key
is installed when needed by the Provisioning Server. The B. Not Just Another Attack
installation process is protected by the keybox. This RSA
We insist that our work does not present a new attack
key protects the Content Key sent by the License Server.
against DRM solutions. Instead, we show that bad imple-
• Content Key: 128-bit AES key for media decryption.
mentation practices imply new attack vectors that can be
During our reverse engineering. we find that the keybox abused to recover DRM-free contents in Android smartphones.
is used to initiate the key ladder. By dynamically monitoring
memory regions that are used during obfuscated cryptographic 3 https://www.cve.org/CVERecord?id=CVE-2021-0639
6
In particular, we show that OTT apps do not use Widevine targeting content decryption to recover decrypted buffers
protection to the fullest, and this might be due to lack of public within the decoder when no TEE is available. Analog loophole
documentation (therefore community discussion) and complex was also used to capture analog signals of the protected content
proprietary design. Moreover, we show that DRM protection by screen-recording or through connectors.
is quite brittle if we include all the supported, yet outdated, In 2019, David Buchanan claimed to have broken Widevine
versions. We successfully demonstrate that deprecated phones L3 DRM on Linux Chrome browsers. In a tweet [27], which
create more risks than benefits. Note that no SafetyNet or anti- is the only available information about this attack, Buchanan
screen recording techniques can be of any use, since attackers mentioned that Widevine L3 relies on AES-128 Whitebox
only need to monitor Widevine that runs in a different process. to protect the keybox. This attack gets a large number of
articles on the web, all of which relied merely on the tweet
C. Limitation & Future Work of Buchanan who has never provided any further detail.
As any study, our work is not exempt from limitations. Our In October 2020, Tomer Hadad released widevine-l3-
paper focuses on the most popular DRM solution on Android decryptor in Github. This project is a Chrome extension on
smartphones, namely Widevine. However, Huawei’s devices Windows that contains a hard-coded value of an RSA key pair
offer their custom DRM solution, called WisePlay. Moreover, used by Widevine L3 unique for all Windows devices. Hadad
outside the smartphone ecosystem, Widevine is present on mentioned that he extracted the RSA private key “by applying
Android TVs, web browsers on different operating systems, some mathematical tricks to Arxan’s whitebox algorithm”. In
and small devices (e.g., Chromecast). Studying similarities and November 2020, Google issued a DMCA takedown request
differences among these different implementations constitutes against widevine-l3-decryptor and all its forks [19]. This
the main future direction of this work. We hope that our proves that Google still views L3 security as a serious matter.
tools will encourage more work on these topics to reach other In May 2021, Zhao [8] broke into the Widevine L1 trusted
platforms and CDMs with fully automated approches. app to recover the Widevine keybox of a Pixel 4. However, he
Another limitation is that our PoC can only recover video did not show how a recovered keybox can be used to decrypt
with sub-HD quality. It is not clear how Widevine enforces protected contents. In our work, we took this further step and
the control on video transmission regarding the security level. implemented the cryptographic mechanisms of Widevine.
On PCs, the Github project netflix-1080p [24] explains
how to get HD quality on L3 by just modifying the profiles C. Closed Source API Analysis
to be sent to the CDN. This implies that there is no strong Our work inspects the misusage of the Widevine API by
verification for web browsers. An interesting future work is to OTT apps. Similarly, other works have been made to analyze
adapt this exploit to Android in order to get the license keys closed source proprietary API on Android. For instance,
of HD contents without breaking into the Widevine L1. Bianchi et al. [28] have inspected the fingerprint API and
its misuage by app developers, leading to multiple attacks
VI. R ELATED W ORK
ranging from confused deputy problem to full fingerprint
A. DRM Researches and DMCA bypass. In their work, Ibrahim et al. [29] looked at the
Despite the widespread of Widevine, surprisingly, no much SafetyNet Attestation API used to detect if an app is running
attention has been given to the security of its underlying pro- in a non compromised Android environment. Their findings
tocol. The main reason behind such a lack of public security point out that more than half of analyzed apps were using
analysis is the DMCA’s 1201 clause that makes it illegal to trivially bypassable checks while none were correctly using
circumvent controls preventing access to copyrighted material. the SafetyNet API.
Consequently, researchers cannot investigate and discover se-
VII. C ONCLUSION
curity vulnerabilities if doing so requires reverse engineering
or circumventing controls such as obfuscated code. This law In this paper, we report on an empirical evaluation of
has already been used against security researchers to censor the protection mechanisms used by content providers within
their work, as shown by Hewlett-Packard against Snosoft in Android to protect their media assets. Our study shows that
2002 [25]. Unfortunately, over fifty court-cases have been OTT apps relies on Widevine using TEE protection when
launched against security research as of 2016 [26]. available but do not comply with Widevine recommendations
Nevertheless, restrictions have been partially lifted recently. in encrypting video and audio with distinct keys or regarding
Indeed, in October 2018, the American Library of Congress revocation of old devices. We investigate the OTT apps support
and the Copyright Office have expanded the exemptions to of Android legacy devices running the software-only Widevine
DMCA. Therefore, in theory, researchers can now freely DRM no longer receiving security updates. We expose that by
investigate and publish security flaws on DRM solutions. choosing large content distribution over security, OTT apps
have extended the device attack surface. We show that such
B. Bypassing DRM & Widevine Keys Recovery vector can be trivially exploited to recover DRM-free movies
In the past decades, multiple techniques have been devel- from six OTT apps including Netflix, Hulu and Showtime. We
oped to circumvent now outdated DRM solutions without hope that this paper will push research forward in this domain
having to break the underling scheme, like MovieStealer [6] and encourage furture works.
7
R EFERENCES [27] David Buchanan, “Breaking Widevine L3 on Linux Chrome browser.”
https://twitter.com/david3141593/status/1080606827384131590, 2019.
[1] Fortune Business Insights, “Over The Top services market to reach USD [28] A. Bianchi, Y. Fratantonio, A. Machiry, C. Kruegel, G. Vigna, S. P. H.
139.00 billion in 2028; emergence of Smart TVs by various companies Chung, and W. Lee, “Broken fingers: On the usage of the fingerprint API
to bolster growth.” https://www.globenewswire.com/news-release/ in android,” in 25th Annual Network and Distributed System Security
2021/08/17/2281647/0/en/Over-The-Top-Services-Market-to-Reach- Symposium, NDSS 2018, San Diego, California, USA, February 18-21,
USD-139-00-Billion-in-2028-Emergence-of-Smart-TVs-by-Various- 2018, The Internet Society, 2018.
Companies-to-Bolster-Growth-states-Fortune-Business-Insights.html, [29] M. Ibrahim, A. Imran, and A. Bianchi, “Safetynot: on the usage of the
2021. safetynet attestation API in android,” in MobiSys ’21: The 19th Annual
[2] H. Halpin, “The crisis of standardizing DRM: the case of W3C encrypted International Conference on Mobile Systems, Applications, and Services,
media extensions,” in SPACE, vol. 10662 of Lecture Notes in Computer Virtual Event, Wisconsin, USA, 24 June - 2 July, 2021 (S. Banerjee,
Science, pp. 10–29, Springer, 2017. L. Mottola, and X. Zhou, eds.), pp. 150–162, ACM, 2021.
[3] D. Dorwin, J. Smith, M. Watson, and A. Bateman, “Encrypted media
extensions.” https://www.w3.org/TR/encrypted-media/, 2019.
[4] Google Widevine, “Widevine.” https://widevine.com/.
[5] M. Sabt, M. Achemlal, and A. Bouabdallah, “Trusted execution envi-
ronment: What it is, and what it is not,” in TrustCom/BigDataSE/ISPA
(1), pp. 57–64, IEEE, 2015.
[6] R. Wang, Y. Shoshitaishvili, C. Kruegel, and G. Vigna, “Steal this
movie: Automatically bypassing DRM protection in streaming media
services,” in 22nd USENIX Security Symposium (USENIX Security 13),
(Washington, D.C.), pp. 687–702, USENIX Association, Aug. 2013.
[7] S. Y. Chau, B. Wang, J. Wang, O. Chowdhury, A. Kate, and N. Li, “Why
johnny can’t make money with his contents: Pitfalls of designing and
implementing content delivery apps,” in Proceedings of the 34th Annual
Computer Security Applications Conference, ACSAC ’18, (New York,
NY, USA), p. 236–251, Association for Computing Machinery, 2018.
[8] Q. Zhao, “Wideshears: Investigating and breaking widevine on QTEE,”
BlackHat Asia, 2021.
[9] G. Beniamini, “QSEE privilege escalation vulnerability and ex-
ploit (CVE-2015-6639).” https://bits-please.blogspot.com/2016/05/qsee-
privilege-escalation-vulnerability.html, 2016.
[10] D. Cerdeira, N. Santos, P. Fonseca, and S. Pinto, “Sok: Understanding
the prevailing security vulnerabilities in trustzone-assisted TEE sys-
tems,” in IEEE Symposium on Security and Privacy, pp. 1416–1432,
IEEE, 2020.
[11] A. Machiry, E. Gustafson, C. Spensky, C. Salls, N. Stephens, R. Wang,
A. Bianchi, Y. R. Choe, C. Kruegel, and G. Vigna, “BOOMERANG:
exploiting the semantic gap in trusted execution environments,” in 24th
Annual Network and Distributed System Security Symposium, NDSS
2017, San Diego, California, USA, February 26 - March 1, 2017, The
Internet Society, 2017.
[12] Google, “Learn when you’ll get software updates on Google Pixel
phones.” https://support.google.com/pixelphone/answer/4457705, 2021.
[13] ISO/IEC, “Common encryption in ISO base media file format files -
2nd edition,” 2015.
[14] A. Dabholkar, S. Kakarla, and D. Saha, “Looney tunes: Exposing the
lack of DRM protection in indian music streaming services,” CoRR,
vol. abs/2103.16360, 2021.
[15] Google Widevine, “Widevine News.” https://web.archive.org/web/
20210903150435/https://www.widevine.com/news, 2021.
[16] Can I Use, “Encrypted media extensions.” https://caniuse.com/eme,
2021.
[17] Google Widevine, “Widevine DRM Overview.” https:
//developers.google.com/widevine/drm/overview, 2021.
[18] Google, “Exoplayer.” https://github.com/google/ExoPlayer, 2021.
[19] Github, “DMCA.” https://github.com/github/dmca/blob/master/2020/11/
2020-11-09-Google.md, 2020.
[20] L. Xue, H. Zhou, X. Luo, Y. Zhou, Y. Shi, G. Gu, F. Zhang, and
M. H. Au, “Happer: Unpacking android apps via a hardware-assisted
approach,” in 42nd IEEE Symposium on Security and Privacy, SP 2021,
San Francisco, CA, USA, 24-27 May 2021, pp. 1641–1658, IEEE, 2021.
[21] Android, “Protect against security threats with SafetyNet.” https://
developer.android.com/training/safetynet, 2021.
[22] O. A. V. Ravnås, “Frida.” https://frida.re/.
[23] PortSwigger, “Burp suite.” https://portswigger.net/burp, 2021.
[24] truedread, “netflix-1080p.” https://github.com/truedread/netflix-1080p,
2021.
[25] D. McCullagh, “Security warning draws DMCA threat.” https://
www.cnet.com/news/security-warning-draws-dmca-threat/, 2002.
[26] Electronic Frontier Foundation, “Reported case list.” https:
//www.eff.org/files/2016/03/17/1201 reported case list revised.xls,
2017.