Exploring Widevine for Fun and Profit

Gwendal Patat Mohamed Sabt Pierre-Alain Fouque

Univ Rennes, IRISA, CNRS Univ Rennes, IRISA, CNRS Univ Rennes, IRISA, CNRS
Rennes, France Rennes, France Rennes, France
gwendal.patat@irisa.fr mohamed.sabt@irisa.fr pierre-alain.fouque@irisa.fr

Abstract—For years, Digital Right Management (DRM) sys- and video-streaming services, including Netflix and Disney+,
tems have been used as the go-to solution for media content pro- leverage Widevine to protect their content.
tection against piracy. With the growing consumption of content Widevine protects video streams at several levels. At the
arXiv:2204.09298v1 [cs.CR] 20 Apr 2022

using Over-the-Top platforms, such as Netflix or Prime Video,

DRMs have been deployed on numerous devices considered as heart of its protection is CENC (Common Encryption Pro-
potential hostile environments. In this paper, we focus on the tection Scheme) [4], specifying encryption standards and key
most widespread solution, the closed-source Widevine DRM. mapping methods that a DRM content decryption module
Installed on billions of devices, Widevine relies on crypto- (CDM) should implement to decrypt media files. Nevertheless,
graphic operations to protect content. Our work presents a the actual key exchanges and protection mechanisms are not
study of Widevine internals on Android, mapping its distinct
components and bringing out its different cryptographic keys
documented, because of the proprietary nature of Widevine.
involved in content decryption. We provide a structural view of
Widevine as a protocol with its complete key ladder. Based on our
A. Motivation
insights, we develop WideXtractor, a tool based on Frida to trace Despite the widespread of Widevine, surprisingly, not much
Widevine function calls and intercept messages for inspection. attention has been given to its underlying protocol design
Using this tool, we analyze Netflix usage of Widevine as a proof-
of-concept, and raised privacy concerns on user-tracking. In
and security. The main reason behind such a lack of public
addition, we leverage our knowledge to bypass the obfuscation of security analysis is that the DMCA’s 1201 clause makes it
Android Widevine software-only version, namely L3, and recover illegal to study DRM systems. The result is that, under the
its Root-of-Trust. DMCA, researchers cannot investigate security vulnerabilities
if doing so requires reverse engineering. This law has already
I. I NTRODUCTION been used against security researchers to censor their work,
as shown by Hewlett-Packard against Snosoft in 2002 [5].
Nowadays, people prefer media consumption on over-the- Unfortunately, more cases have followed, and over fifty court-
top platforms (OTT), such as Netflix and Amazon Prime, cases have been launched against research as of 2016 [6].
that distribute multimedia content over the Internet, allowing Fortunately, restrictions have been partially lifted recently.
users to play them whenever they wish. Such ease of viewing Indeed, in October 2018, the American Library of Congress
the same videos across devices creates challenges for content and the Copyright Office have expanded the exemptions to
producers and owners. The main challenge remains piracy; the DMCA’s 1201 clause. Consequently, in theory, security
namely, platforms delivering media content would like to researchers can now freely investigate, correct and publish
ensure that the receiving devices offer enough security at the security flaws on DRM solutions. However, such exemptions
level of hardware and software to prevent leakages. Indeed, did not stop Google that, in November 2020, took down
protection by authentication is not enough, as the OTT plat- all Github repositories including secret keys of Widevine.
forms need to prevent free redistribution of copyright protected That does not mean that exploits compromising Widevine
content. have never been published before. Indeed, the MITRE CVE
The de facto answer to these challenges is Digital Rights database [7] lists 25 CVE records since 2014, explaining
Management. DRM is a technology that is designed to prevent different security issues within Widevine implementations.
piracy of digital content. It protects the content owners by re- Despite such a public record, there is not much literature
stricting media consumption to authorized consumers. Despite providing deep insights about Widevine security.
begin cried out, DRM systems got increasingly adopted on
users’ devices. The World Wide Web Consortium (W3C) has B. Our Contributions
recently published the Encrypted Media Extensions (EME) [1], Our work aims at pushing this topic forward, as we believe
which is the first official Web standard for DRM, ignoring that stakes are high regarding the Widevine protocol. Our
all the expressed worries [2] about a web that should remain paper intends to fill this lack of public research by pro-
open. One of the most popular DRM solutions is Google’s viding the first thorough analysis of the Widevine protocol.
Widevine [3], which is currently deployed on web browsers Here, we overcome the restriction of signing a non-disclosure
(eg., Chrome and Firefox), Android OS on mobile devices agreement (NDA) to get the full description of the Widevine
and smart TVs among others. Most popular OTT players protocol by performing a complete reverse engineering of
the Android Widevine modules. Moreover, we show that a only protects the download URL of audio tracks, that
deep understanding of Widevine can allow attackers to easily can be effortlessly downloaded in clear even without a
recover its internal secret parts without requiring to defeat the Netflix account. Indeed, the second session only concerns
applied obfuscation. This is worrisome for two reasons. First, the decryption key of video tracks.
many streaming services rely on Widevine DRM to protect • We discuss two issues raised by our analysis. The first
content against piracy. Any harm to this technology can lead one is related to the use of a distinctive device identifier
to huge financial losses. For instance, in 2020, the OTT market by Widevine. This allows third-party servers to profile
size was estimated at $13.9 billion and expected to reach users’ behavior during media consumption without their
$139 billion by 2028 [8]. Second, zero-day vulnerabilities on consent. The second one concerns a methodology that we
Widevine can be exploited to harm countless users [9], since define to efficiently recover Widevine Android software-
Widevine is estimated to be installed on more than 5 billion only root of trust despite the underlying obfuscation
devices around the world. hiding the critical parts of Widevine. We timely report
In this work, our approach was to begin with a manual all findings to Google and Netflix and were assigned the
analysis to gain insights into the structure of the Widevine CVE-2021-0639. We were awarded by the bug bounty
protocol as well as its main cryptographic operations. Then, program of Netflix and the Vulnerability Reward Program
we design a Frida-based tool to automatically extract details of Google.
about the Widevine workflow as it is leveraged by Android Roadmap. This paper is organized as follows: section II intro-
OTT apps. Afterwards, we extend our tool to trace the duces the necessary background for our research. Section III
Widevine operations within web applications running in an offers an overview of the Android DRM and Widevine plugin
EME-supporting browser. Finally, we take a look at the components interaction. The Widevine protocol is presented
outcome of our analysis, and discuss its relevance regarding in section IV with a special focus on its key ladder in sec-
the security of the Widevine module or the OTT app. We tion V. Our reverse engineering efforts allow us to implement
emphasize that, throughout our work, we carefully play the WideXtractor that automatically inspects Widevine flow for
role of the security researchers who, as described by the OTT apps. We present the design of our tool in section VI and
DMCA’s exemptions, act in good faith. Indeed, we timely provide some insights gained by applying it on several OTT
report all our findings to Google, Widevine and Netflix. apps. Section VII discusses the concerns and security issues
In addition, we gave up all the keys that we succeeded to that emerge from our study. Related works are presented in
extract, so that they get revoked by the concerned parties. section VIII. We conclude in section IX.

Our contributions are the following:

II. BACKGROUND
• We reverse-engineer Widevine components on Android.
In particular, we thoroughly explore its different crypto- A. Digital Right Management Systems
graphic components from the root of trust, aka keybox,
until the key decrypting the media, aka Content Key, and Digital Rights Management (DRM) system refers to tech-
provide an implementation of this key ladder.1 nology that plays two roles. First, it offers the tools that
• We uncover the structure of the Widevine protocol and
enable a content provider to encrypt their content. Second,
detail the contents of the exchanged messages between it builds an ecosystem, so that the content provider controls
Widevine and the different entities of the DRM ecosys- who can decrypt and consume their content. To this end,
tem. We also dissect Widevine internals during the ex- DRM systems define a set of business rules to be enforced.
ecution of an OTT app, and split them into three main In practice, DRM involves two parties: a Content Delivery
operations: provisioning of device-specific RSA key, pro- Network (CDN) supplying encrypted content and a License
visioning of content license keys, and content decryption. Server providing the necessary keys to decrypt such content.
• In order to automate Widevine inspection, we design
Only the DRM module on the user device can retrieve these
WideXtractor,2 which is a tool based on Frida to monitor keys, which makes it possible to control media consumption.
the inner working of Widevine during media playback The DRM module shall also protect the keys while using
and dump exchange messages. them. For instance, Widevine relies on ARM TrustZone based
• We leverage our tool to study Netflix usage of Widevine,
Trusted Execution Environment (TEE) when available for
in order to understand how it protects its media assets: strong security guarantee in many Android devices.
video, audio and subtitles. We find that Netflix mainly The DRM module performing sensitive operations, such
establishes two Widevine sessions: one to receive pro- as decryption and license requests, is implemented separately
tected media, and another one for obtaining the related and called CDM or Content Decryption Module. Every DRM
decryption keys. We spy on the first session using WideX- scheme provides its own CDM that includes proprietary mech-
tractor, and notice that Netflix, unlike other OTT apps, anisms for License Server communication, as well as rules
around local license storage and renewal. Of course, CDMs
1 https://github.com/Avalonswanderer/widevine key ladder are required not to leak license keys. By being closed-source,
2 https://github.com/Avalonswanderer/wideXtractor CDMs mostly rely on security-by-obscurity.

2
B. Google Widevine The obtained keys are only accessible through Media Crypto.
Widevine is a DRM solution acquired by Google in 2010. Indeed, the encrypted content is decrypted by a Media Codec
The earlier version of Widevine that had support in old instance to which the Media Crypto object was registered.
Android versions (up to Android 5.1) was called Widevine Thus, the keys are not accessed directly. In addition to the
Classic, working only with the proprietary .wmv format. The DASH mode, the DRM APIs provide the ability to establish
current version of Widevine is called Widevine Modular, a secure session to protect arbitrary data.
and implements a different DRM and streaming standards, B. Widevine Components
including MPEG-DASH and CENC. Widevine Modular, or
henceforth simply Widevine, is supported on Android 4.4+. In Android, Widevine comes as a dynamically loadable
Widevine defines three security levels: L1, L2 and L3, HAL plugin within the mediadrmserver process. Similar
where the L1 level is considered the most secure for playing to other HAL plugins, Widevine is manufacturers-provided.
HD videos from OTT platforms. Widevine depends on the In addition, it is not open-source; only provided as binary
TEE to implement L1 security. At L1, both cryptography and code and library files. To keep things secure, when a TEE is
video processing take place inside the TEE. It is worth noting available, the HAL plugin delegates all sensitive operations to
that applications inside the TEE are hardware dependent, and the Widevine component that runs inside the TEE. Roughly
therefore Widevine shall provide a different implementation speaking, the resulting architecture looks like this (other
for each one. L2 and L3 are implemented where the TEE components might exist depending on the Android version):
is not an option, such as legacy phones or Widevine locked • Widevine library: this library is used by the
ones due to device tampering. In Android, Widevine does not mediadrmserver process to translate Android DRM
propose L2 security. The L3 lets both cryptography and video API calls to Widevine CDM ones. The behavior of this
processing take place outside the TEE. They are considered library changes depending on the Widevine security level.
more vulnerable, given that the CDM is software-only. As for In L1, it plays the role of a proxy and communicates
users, L3 delivers sub-HD resolutions since Widevine supports with the TEE through liboemcrypto.so. As for L3,
HD and ultra-HD content only for L1. it contains the obfuscated CDM. Its name can change
depending on the version and SoC including but not
III. WARM U P : W IDEVINE IN A NDROID limited to: libwvdrmengine.so, libwvhidl.so,
In this section, we describe the integration of Widevine libwvm.so, libdrmwvmplugin.so.
into the Android ecosystem. In particular, we detail all the • liboemcrypto.so: this library performs marshalling and
components of which Widevine consists of and their interac- unmarshalling of requests to the Widevine trustlet. All
tion. This will help us to better frame our reverse engineering communications with the TEE go through a specific TEE
methodology by pointing out the relevant components to driver (e.g., QSEEComAPI.so for QSEE).
analyze in order to uncover the internals of Widevine. • Widevine trustlet: it runs inside the TEE and implements
all the needed functionalities for L1.
A. Android DRM API
In order to cope with the fragmented DRM ecosystem, C. Components Interaction
Android offers a unified API in Java/Kotlin for DRM systems. Android Widevine architecture is summarized in Figure 1.
Starting from API level 18, this is implemented by some In a top down architecture, components interact as follows.
HAL (Hardware Abstraction Layer) module called Media DRM services start from the OTT application calling the An-
DRM Server that abstracts the actual running DRM from the droid Media Framework API to interact with the MediaDRM
programming interface used by OTT apps. The Android DRM and MediaCrypto objects. All calls to the DRM API
API mainly consists of two modules: Media DRM and Media go through some Java Native Interface (JNI) layer via the
Crypto. The Media DRM is used to communicate with License libmedia_jni.so library. Calls are then forwarded to the
Servers and to manage keys for a given media. As for Media Media DRM Server instantiated by the mediadrmserver
Crypto, it is used to perform decryption. The DRM APIs process, which is the last module implemented by Android.
support the ISO/IEC 23002-7: Common Encryption standard The Media DRM Server reaches the Widevine specific im-
(CENC) [4], but implement other encryption schemes. plementation through the HAL APIs. Any communication
Playing encrypted content when leveraging DASH (Dy- with Widevine first goes to its specific library such as
namic Adaptive Streaming over HTTP) works as follows. First, libwvdrmengine.so. In L3, no further component is
the app constructs a Media DRM object with a given DRM involved. As for L1, whenever CDM is required, this library
through a unique identifier. Then, the app opens a new session calls liboemcrypto.so that sends the related requests to
with the Media DRM object and gets some session identifier. the Widevine TEE trustlet.
A Media Crypto object is then constructed and bound to Of particular interest, the Widevine library does the trans-
the opened session. Next, Media DRM retrieves keys (aka lation between the HAL API to Widevine functions. Once
licenses) from the License Server. To this end, a DRM-specific translated, if Widevine is in L1 mode the Widevine API
request object is obtained from the Media DRM object, and is used to call its equivalent in liboemcrypto.so. The
the server response is delivered to the Media DRM instance. OEMCrypto library role is to forge a message for the TEE

3
 Application
e.g., Netflix, • Pixel 3: Android version 11, build blueline rq3a.210805.
PrimeVideo, Disney+

Widevine L1 mode version 15.

All tested smartphones integrate the Qualcomm TEE (QSEE),
MediaDRM / MediaCrypto
Android Media and therefore our analysis includes some QSEE-related details.
API Framework Public
API (Java/Kotlin)
Henceforth, we will be careful to distinguish what is true for
Widevine as a protocol, and what is specific to QSEE.
Trustlet Extraction. The first step to reverse the proprietary
android_media_MediaDRM Java Native
android_media_MediaCrypto
Interface API implementation of Widevine was to extract the binaries from
the file system either from a physical (rooted) mobile or by
downloading and extracting the phone factory images on the
libmedia_jni.so Google website [10]). These binaries, including the trustlet,
can be found in the /vendor/ directory.
Binder
IPC For Qualcomm SoC based phones, Widevine trustlet is
Native Framework

(Media DRM Server)

located in /vendor/firmware/ and is divided into several
libmediadrm.so
.bXX files, where XX is a counter. To reconstruct the complete
HIDL IPC
trustlet, we can simply concatenate each of these files in order
to obtain a standard ELF binary with an additional hash table
*
Widevine Library
section used for integrity verification.
L1 calls
Trustlet Analysis. The Widevine L3 CDM within the
Widevine library (e.g., libwvdrmengine.so) being obfus-
L3 calls
liboemcrypto.so
* cated, we preferred to start with another implementation in
Vendor Specific order to figure out how Widevine works. We notice that the L1
Implementation

trustlet is not obfuscated at all. Worse still, it provides verbose

TEE Drivers
clear debugging strings in its internal code, thereby leading
Android
to a better understanding of the overall structure and control
flow of the protocol. Leveraging tools such as Ghidra [11]
TEE
and Radare2 [12], we were able to retrieve function names
*
Widevine trustlet
and cryptographic keys within the Widevine protocol. Relying
on our knowledge of the L1 trustlet, we then went back to
* Widevine components the library to discern the HAL calls to L1 and to analyze the
obfuscated L3 layer.
Fig. 1. Widevine Architecture in Android
Libraries Analysis. Our reverse engineering of the trustlet
allowed us to map the Widevine protocol functions called
trustlet containing the function arguments and command code. OEMCrypto with function symbols ( oeccXX for L1 and
For a given TEE, each Widevine function corresponds to a lccXX for L3). The correspondence for Widevine Modular
specific command code used by the TEE driver in order to be L1 functions is summarized in section A. We also leveraged
received by the Widevine command handler within the trustlet. the Frida toolkit [13] to trace the execution of these functions
in the mediadrmserver process, as both the Widevine
IV. W IDEVINE I NTERNALS library and liboemcrypto.so are instantiated in the Media
A. Methodology DRM Server. This leads us to figure out the workflow of the
Widevine protocol regarding the called operations as well as
Given the Widevine component layout described in sec- the related cryptographic keys.
tion III, three main components of Widevine come to light:
the Widevine library, liboemcrypto.so, and the Widevine B. Widevine Protocol
trustlet running in the TEE. To study Widevine inner work- In section III, we present the components enabling protected
ing, we have inspected both statically and dynamically these content playback within Android devices using Widevine.
components starting from the Widevine trustlet. Taking a look at the bigger picture to highlight the commu-
Analysis Environment. We examine four smartphones and nications behind these elements, we can distinguish 7 agents:
their respective factory images: a CDN (Content Delivery Network), a provisioning server, a
• Nexus 5: Android version 6.0.1, build hammerhead license server, an OTT application, the Android Media servers,
m4b30z. Widevine L3 mode with version 3.1.0. the Widevine library and Widevine CDM.
• Nexus 5X: Android version 8.1.0, build bullhead bhz32c. Indeed, when playing protected content using an OTT app
Widevine L1 mode, version 5.1.0, security patch level 2. (e.g., Netflix), content decryption is managed by the Android
• Pixel: Android version 10, build sailfish Media Servers that relies on the underlying DRM system,
qp1a.191005.007.a3. Widevine L1 mode version here Widevine. All key requests for provision and license
14. servers are generated by Widevine components, especially the

4
 Android Widevine Widevine
Application
Media Servers
Library CDM

new MediaDRM Initialize Initialize

OpenSession OpenSession OpenSession

ctxID

getProvisionRequest getProvisionRequest

Cert Provisioning
GenerateNonce(ctxID)

nonce

GetKeyData

provisioning token

prov_blob = provisioning token || nonce

enc_context = ENCRYPTION || provisioning token

mac_context = AUTHENTICATION || provisioning token

GenerateDerivedKeys(ctxID, enc_context, mac_context)

GenerateSignature(ctxID, prov_blob)

hmac(prov_blob)
Provisioning

request, hmac request, hmac request, hmac

Server

, hmac(       , nonce) provideProvisionResponse(        , hmac)         , hmac

RewrapDeviceRSAKey(ctxID,        , hmac, nonce)

wrapped_rsa_key

media request
CDN

media , keyID
getKeyRequest getKeyRequest

License Provisioning
LoadDeviceRSAKey(ctxID, wrapped_rsa_key)

GetArchitectureName() ,GetDeviceID(ctxID), GetAPIVersion(), GetHDCPCapability() ...

device_blob, request_ID

GenerateNonce(ctxID)
nonce

request = device_blob || request_ID

GenerateRSASignature(ctxID, request, padding_type)

signature(request)
License Server

request, signature, nonce request, signature, nonce request, signature, nonce

                     , hmac(              ) provideKeyResponse(                         , hmac) , hmac

enc_context = ENCRYPTION || request

mac_context = AUTHENTICATION || request

DeriveKeysFromSessionKey(ctxID, enc_context, mac_context,          )

LoadKeys(ctxID,                 , hmac)

Content Decryption

queueSecureInputBuffer
media , keyID SelectKey(ctxID, keyID)

DecryptCENC

...

DecryptCENC

CloseSession CloseSession CloseSession(ctxID)

Destroy MediaDRM Terminate Terminate

Content Key RoT Derived Client Key RoT Derived Server Key Session Derived Server Key Device RSA Key Server Key (Optional)

Device Key (RoT) RoT Derived Asset Key Session Derived Client Key Session Derived Asset Key Session Key

Fig. 2. Widevine Protocol for Media Decryption

library, with the help of the CDM. Overall, the Widevine On request creation, the CDM generates a nonce to ensure
protocol involving these actors is divided into three main freshness. Then, it derives keys for certificate decryption and
phases: Certificate Provisioning, License Provisioning and integrity checks, based on the Widevine Root of Trust (RoT)
Content Decryption. An illustration of the protocol can be seen called the Device Key, and dynamically generated buffers.
in Figure 2. These buffers are based on a token within the RoT structure
detailed later. Using OEMCrypto_GenerateSignature,
Certificate Provisioning. The provisioning phase is usually the request is HMAC-protected with the RoT derived client
done once to recover a cryptographic certificate and does not key, and sent to the provisioning server.
need to be done for future media decryption. The private key
within this certificate protects the fresh session keys. A new The received response is passed to the CDM through
request is sent to the provisioning server when no certificate the OEMCrypto_RewrapDeviceRSAKey function. After
can be found, the one installed is corrupted, or the OTT needs nonce check and integrity verification using the RoT derived
to install a new certificate. server key, the certificate is decrypted using the previously

5
derived key and stored on the persistent storage of the device Device Key Content Key

after being rewrapped (i.e. re-encrypted) by a device-specific

key. This marks the end of the installation process of the encrypted content key

certificate private key called the Device RSA Key. AES-128 CMAC
enc context buffer
AES-128 CBC

License Provisioning. The OTT receives all required in-

formation about the protected content from the CDN in
order to ask for the corresponding Content Keys, also known RoT Derived Session Derived
Asset Key Asset Key

as license keys. After loading the stored certificate using

OEMCrypto_LoadDeviceRSAKey, a request is forged us-
enc context buffer '

ing a generated request ID and various device specific info

AES-128 CBC
encrypted rsa key AES-128 CMAC

concatenated within a device blob. This message is then signed

by the Device RSA Key and sent with a newly generated nonce
to the License Server.
The corresponding response will be received by the CDM Device RSA  Key
RSA-OAEP
Session Key

through OEMCrypto_DeriveKeyFromSessionKey that

will extract and decrypt a Session Key using the Device
encrypted session key
RSA Key. The Session Key is then used to derive other
HMAC and encryption keys based on buffers containing
Fig. 3. Widevine Key Ladder
a dynamically generated device blob. These keys are later
used to verify the integrity of the response received by
OEMCrypto_LoadKeys and to decrypt the Content Keys.
Here, Content Keys are associated with a Key Control Block Keybox storage. While exploring the structure of the
(KCB), encrypted or not by its related content key. KCB Widevine trustlet, we looked at the Qualcomm Secure File
contains the previous nonce and various information that we System (SFS) that allows trustlets to encrypt their sensi-
will detail in subsection V-C. It is important to note that, tive data before storage. On our setup, the SFS persis-
once all Content Keys have been added to the CDM, the tently stores the encrypted files on /persist/data/sfs/.
nonce is cleared from memory. During key reception, the Then, we continued our exploration and found the function
License Server can provide a new Server Key protected by init_tzdrm_config_path initializing paths for several
the derived asset key. This key constitutes a new server mac elements. Here, the string names are explicit, and we think that
key for integrity verification of future response, such as in the keybox lvl1.dat file refers to the keybox for L1. We also
OEMCrypto_RefreshKeys. found the OEMCrypto_InstallKeybox function that can
Content Decryption. Note that more than one Content be called from libwvdrmengine.so to re-install a factory
Keys can be loaded in the CDM memory at the same time. keybox supposed to exist in the /factory/wv.keys file.
Therefore, the right one for the media is selected using its key Nevertheless, we have never found such a file. As for L3,
ID in OEMCrypto_SelectKey before content decryption we noticed that the library libwvdrmengine.so loads
within OEMCrypto_DecryptCENC. the keybox from the ay64.dat file that can be found in
/data/mediadrm/IDMXXXX/L3/.
V. W IDEVINE C RYPTO L ADDER
Keybox structure. In order to figure out of what the
In this section, following our reverse engineering analyses, keybox consists, we looked deeper at the trustlet functions
we succeed in depicting a complete picture of Widevine cryp- that verify keybox integrity, because they display an explicit
tographic mechanisms. In particular, we uncover the Widevine error log message that clearly identifies the concerned field.
internal key ladder from its root of trust to the content We began with OEMCrypto_isKeyBoxValid. Indeed, this
decryption key. An overview is summarized in Figure 3. Note function shows us that the keybox structure is 128 bytes
that our study holds for both L1 and L3. Moreover, we provide long with two special fields at the end. The trustlet checks
an implementation of the key ladder in Python.3 For ethical the integrity of the decrypted keybox by verifying that the
and legal purposes, we did not include the root keys. Thus, last eight bytes are composed of a magic number “kbox”
nobody can use our project to actually pirate OTT contents. followed by a 4-byte Cyclic Redundancy Check (CRC-32)
A. Widevine Root of Trust: Keybox code. In this paper, we will not discuss the effectiveness of
this integrity verification despite being broken in other con-
Widevine, in [14], mentions that its RoT is established by a
texts [15]. We retrieved the remaining fields by looking at the
factory-provisioned component called the keybox. While doing
functions loading the keybox: OEMCrypto_GetKeyData,
our static analysis, we noticed that this keybox is mainly used
OEMCrypto_GetDeviceID, and the internal function
to secure the provisioning of certificates. We will discuss more
OEMCrypto_GetDeviceKey. The Device ID is a 32-byte
about this in subsection V-B. Now, let us focus on the nature
unique device identifier for Widevine. The Key Data, or the
of this RoT and where it is stored.
Provisioning Token as referred to by libwvdrmengine.so,
3 https://github.com/Avalonswanderer/widevine key ladder is 72 bytes long and is used wihtin provisioning requests. The

6
 TABLE I its associated Content Key. The KCB is identified by the magic
W IDEVINE K EY B OX number kctl or one of the form kcXX, where XX is related to
Field Description Size (bits) Widevine version. The Content Key is accepted only when the
Device ID Internal Device ID 256 associated KCB is checked by verifyKeyControlBlock.
Device Key 128-bit AES key 128
Provisioning Token Used by provision requests 576
This function helped us to understand the structure of KCB:
Magic Number “kbox” 32 a nonce, time to live (TTL) of the key, and 32-bit of control
CRC32 CRC32 validating the keybox integrity 32 bits. These control bits define usage right (e.g., encryption,
Total 1024
MAC tag generation, etc.) and anti-rollback features. During
the lifetime of a Content Key, the KCB can be updated
remaining 16 bytes correspond to an AES key that is called, through the OEMCrypto_RefreshKey function that, unlike
according to the API, Device Key. This key is the real RoT. its name might indicate, cannot change the key or usage
We summarize the five fields of the keybox in Table I. rights but only its TTL. Such refresh requests work as li-
cense ones with the exception that the OEMCrypto function
B. Device RSA Key GenerateSignature is used for integrity protection in-
As explained in section IV, Widevine does not directly use stead of GenerateRSASignature.
its RoT to protect licenses. Instead, it leverages an RSA key Keys Usage. During loading in the CDM memory, Content
pair that, unlike the keybox, can be installed dynamically on Keys are stored in a key table structure with an identifying
the device through a process called certificate provisioning. key ID for OEMCrypto_SelectKey. For media playback,
This process is protected by the Device Key that is derived into encrypted buffers are decrypted with the chosen key by
several keys in OEMCrypto_GenerateDerivedKeys. OEMCrypto_DecryptCENC implementing MPEG-CENC.
Upon reception, the OEMCrypto_RewrapDeviceRSAKey
D. Nonces
function first verifies the integrity of the key pair by re-
computing an 256-bit HMAC tag. Then, it decrypts the key The Widevine protocol mitigates replay attacks
pair, and re-encrypts it again with a device-unique (TEE- and ensures message freshness using nonces. By
specific in L1 or keybox-related in L3) 128-bit AES key. OEMCrypto_GenerateNonce, the Widevine library
These keys never leave the CDM. This function also checks can ask the CDM to generate up to 20 nonces per second
the key pair format after decryption and before re-encryption. stored in a First In, First Out (FIFO) queue of 16 elements
Indeed, the key pair, aka the Device RSA Key, is expected within the CDM memory. These 32-bit nonces are generated
to be an RSA certificate with PKCS#5 padding in PKCS#8 using a Pseudo Random Number Generator (PRNG) and used
format as indicated by the qsee_secpkcs8_parse and at each request creation and response reception. If the nonce
get_len_with_pkcs5_padding functions. is valid, it is removed from the queue and the message is
Once re-encrypted, aka re-wrapped, the Device RSA Key is processed, otherwise the message is dropped. During Content
stored on the standard file system by the Widevine library Keys loading in OEMCrypto_LoadKeys, a single nonce
in a cert.bin file on /data/mediadrm/IDMXXXX/. can be used in multiple KCBs. In this case, the nonce is only
Widevine distinguishes L1 from L3 by using different direc- removed once all keys have been processed.
tories. This persistent data is later used in future instances of
E. Summary of Cryptographic Algorithms
the Widevine CDM to avoid making new provisioning. Here,
OEMCrypto_LoadDeviceRSAKey is used to recover the Widevine Generic Crypto API. In addition to media
stored certificate. We note that re-wrap is MAC-and-Encrypt, decryption, the Widevine CDM allows applications to perform
as it also computes an 256-bit HMAC tag on the key pair. arbitrary cryptographic operations within a dedicated session.
Please note that a new provisioning process is performed In Android, using the CryptoSession class of Media
whenever the cert.bin file is deleted or corrupted. DRM, an application can leverage the underlying DRM plugin
to protect data using the OEMCrypto_Generic_XXX family
C. Content Keys of Encrypt, Decrypt Sign and Verify functions. Here,
Keys protection. As introduced previously, content keys, each operation must have the appropriate key usage rights.
or license keys, are obtained from provideKeyResponse. Key Derivation. Widevine never uses received or stored
Here, Widevine first calls DeriveKeysFromSessionKey keys directly. Instead, it relies on key derivation algorithms,
from OEMCrypto to decrypt a special field; Session Key, implemented in OEMCrypto_GenerateDerivedKeys
using the Device RSA key. This key is later used to derive and OEMCrypto_DerivedKeyFromSessionKey, in or-
a 128-bit AES key as well as two 256-bit HMAC keys. Then, der to generate three different keys each time: a 128-bit Asset
these keys are used in OEMCrypto_LoadKeys to decrypt key, a 256-bit MAC Client Key, and a 256-bit MAC Server
the license key and verify its integrity. Key. The leveraged PRF (Pseudo-Random Function) is AES-
Key Control Block. Alongside the Session and Content 128-CMAC to generate the required 640 bits. In addition to
Keys, the response from the License Server also contains secret keys, the derivation algorithm uses two buffers, called
additional 128-bit metadata called Key Control Block (KCB), encryption context and mac context, that are created based
one for each license key in the response, and is encrypted by on device-unique information and used respectively for the

7
Asset key and both MAC keys. For each chunk, the device operations make the tool uncover the secret keys that should
blob is appended to a string that begins with a string counter exist in the memory at a particular point of time, despite of
and the word “ENCRYPTION” for encryption context or the applied obfuscation.
“AUTHENTICATION” for the mac ones. Only one encryption We implement WideXtractor using Frida to monitor all calls
context with counter “1” is needed, while the mac context to the OEMCrypto functions in the Media DRM Server.
includes four counters starting from 1. Monitoring the mediadrmserver process has two advan-
Symmetric Cryptography. All CDM operations re- tages: (1) it allows us to bypass anti-debug techniques at the
lated to key decryption, generic encryption API (i.e. application level, such as SafetyNet [16], and (2) both L1 and
Generic_Encrypt, Generic_Decrypt), and media L3 workflow can be recovered.
protection are performed using AES 128 bits. Both key decryp- Our monitoring traces any call to Widevine functions,
tion (e.g. OEMCrypto_LoadKeys) and encryption API im- hence the underlying protocol outline, while dumping the
plement AES in CBC mode, while media decryption relies on used arguments, such as buffers for requests and opaque
OEMCrypto_DecryptCENC which supports MPEG-CENC reply data. To this end, WideXtractor relies on a Frida server
(i.e. AES-128-CTR). running on the Android device with sys ptrace capability.
AES Initialization Vectors. Within key decryption func- This can be achieved by running as the media group or a
tions, IVs are being received alongside their respective system/root privileged user. Our script hooks the OEMCrypto
cyphertext in server responses. On Device RSA Key rewrap, functions after attaching to the mediadrmserver process
IV generation is handled by a PRNG algorithm with instantiating DRM libraries.
OEMCrypto_GetRandom. For protected content, MPEG- Once launched and attached, WideXtractor logs every
CENC standard is used to deal with IVs. method of the Widevine protocol and received buffers from
MAC Generation. The MAC Client Keys and Server Keys the Android OS. Our traces correspond to the library symbols
respectively protect requests and responses to provisioning that we reverse engineered and summarized in section A. Our
and license servers using HMAC-SHA256. The same algo- tool allows attackers to inspect exchanged messages during
rithm is used by the OEMCrypto API Generic_Sign and key reception and media decryption before opaque requests
Generic_Verify using the currently loaded Content Key. and responses. WideXtractor can be found on our Github.4
RSA Operations. The Device RSA Key includes a 2048-
bit private key that is used for both decryption and signature B. Case Study: Netflix
during Session Key loading and license request creation. For Leveraging WideXtractor, we automatically monitor the use
decryption, this key is used in the RSA-OAEP-SHA1 mode, of Widevine by the Netflix app, which is the most popular
while RSASSA-PSS-SHA1 and RSASSA-PKCS1-v1 5 can OTT with 200 million subscribers around the world [17]. Our
both be used for requests depending on function argument. analysis shows a large number of calls to the Widevine Generic
Crypto API compared to other OTT apps.
VI. W IDE X TRACTOR
Following our observation, we dig deeper to understand
Most OTT apps, including Netflix, Disney+ and Hulu, apply Netflix internals. We find that Netflix requires to manage
anti-debugging mechanisms in order to prevent attackers from two Widevine sessions: one to get Content Keys and de-
easily intercepting and tracing calls to Widevine. In addition, crypt protected media, and one to exchange data using the
our reverse engineering shows that it is quite demanding to Widevine Generic Crypto API. Henceforth, we will call these
untangle the Widevine interface between its different com- two sessions License Session and Generic Crypto Session
ponents. This is due to the fact that dissecting the Widevine respectively. Both sessions are initialized in the same way until
workflow provides an important insight into its internals. Thus, OEMCrypto_LoadKeys.
we implement WideXtractor; a tool tracing the Widevine calls Indeed, the License Session loads the Content Key that de-
made by an OTT app. In this section, we present an overview crypts the displayed media, while the Generic Crypto Session
of the design and the implementation of this tool. Then, we loads several keys for confidentiality and integrity protection
show the effectiveness of our tool by highlighting interesting of arbitrary data. We note that Content Key can only be
findings while analyzing the most downloaded OTT app on accessed through the queueSecureInputBuffer method
Android, namely Netflix. Finally, we extend WideXtractor to from the MediaCodec class. Thus, only keys loaded within
inspect Widevine as a plugin on Chrome. the Generic Crypto Session can be used to decrypt arbitrary
data using the Android CryptoSession. Here, each key
A. WideXtractor Design
has its own usage rights to perform specific cryptographic
We design WideXtractor to automatically trace the exe- operations. As explained in subsection V-E, Widevine asso-
cution flow of Widevine on Android. Our goal is twofold. ciates these functions to the following OEMCrypto ones:
First, researchers can easily and systematically study how OTT Generic_Encrypt and Generic_Decrypt for AES op-
apps leverage Widevine while displaying protected content. erations, and Generic_Sign with Generic_Verify for
Interesting findings can be revealed by analyzing the actual HMAC tag computation and verification.
calls and their parameters, as we demonstrate for Netflix in
the following subsection. Second, our insights about the used 4 https://github.com/Avalonswanderer/wideXtractor

8
 Our study shows that all communications with the Net- MediaKeySession managing the lifetime of a DRM li-
flix CDN go through the Generic Crypto Session. Thus, cense. Next, the MediaKeySession object generates a
Netflix avoids relying solely on HTTPS to protect assets. license request by calling generateRequest. This message
For instance, from the Android OS view, the app asks is sent to the license server to require the necessary decryption
the Widevine CDM to decrypt and verify the received keys. Once the response is received, MediaKeySession
messages. The decrypted data are sent back to the app calls the update method to parse the obtained license inside
without any particular protection. Therefore, by monitoring the CDM. Now, we can decrypt the media using the keys
OEMCrypto_Generic_Decrypt, we were able to inter- loaded from the license.
cept all exchanged messages between the CDN and the In PC browsers, Widevine comes as a plugin in different
Netflix app. These messages contain download URLs for browsers, such as Firefox and Chrome, supporting the EME
timedtexttracks (for subtitles), video_tracks and standard. It is true that our work focuses mainly on Android
audio_tracks. Each of this category contains multiple Widevine. In order to overcome this limitation, we study
links corresponding to different languages for subtitles and the Widevine flow as it is implemented within the browsers
audio in addition to different qualities for video. Although the providing EME. Here, we note that the CDM software is
downloaded videos are encrypted using the Widevine CDM, obfuscated and hides its symbols. Therefore, we follow a
both audio and subtitles can be obtained in clear. We perform different approach: instead of hooking the browser EME
several experiments with the audio and subtitles URLs to functions, we implemented a browser plugin that intercepts
evaluate their validity. We find that they are accessible from all EME related data. Then, we parse these data and compare
any platform (PC web browsers, smartphones, tablets), by them with the ones obtained in Android Widevine. We notice
anyone (no need for Netflix account), from anywhere (no a big reciprocity between the Widevine messages in Android
location verification), and for a limited period of time (12 and PC browsers. This confirms that the Widevine protocol
hours approximately). We also find that there is no limit of in Figure 2 works similarly in different systems. The main
simultaneous accessed devices. difference that we noticed is that the Widevine RoT in browser
Our learned lesson is that Netflix seemingly makes it harder consists of a whitebox implementation of the Device RSA Key.
to spy on messages sent by the CDN by adding an extra Thus, we extend WideXtractor to trace the Widevine flow by
layer of protection provided by Widevine. Thus, attackers merely looking into the EME received messages. Our approach
might be clueless, since defeating Android certificate pinning has the advantage of successfully following the Widevine flow
is not enough. However, WideXtractor easily allowed us to without regard to the applied obfuscation or the actual called
identify the use of the Widevine Generic Crypto API. Thus, it functions. Based on a Chrome EME logger plugin [19], as
becomes even more straightforward to obtain the exchanged in WideXtractor we log buffer values and use key usage info
messages in clear by just recovering the returned buffer of from update calls to identify the message purpose within
OEMCrypto_Generic_Decrypt. The advantage of our the Widevine protocol. This allowed us to log additional
approach is that we no longer need to bypass certificate information to link EME calls to Widevine functions.
pinning implemented by the OTT app. We were surprised that
Netflix does not protect audio tracks by a Content Key. During VII. D ISCUSSION
our responsible disclosure, we discovered that Netflix was not
even aware of that, because they believed that non-Dash mode Widevine enthusiastically pitches the virtue of their DRM
was sufficient. We went further and analyzed six other popular solution. Widevine being proprietary, there is no easy way to
OTT apps: Disney+, Amazon Prime Video, Hulu, HBO Max, verify the security claims of this piece of software running in
Starz and Showtime. We find that, unlike Netflix, all of them billions of devices. The goal of our reverse-engineering efforts
encrypt their audio tracks with the Content Key. is to go beyond this market irrationality. In this section, we
show how our study conveniently helps in highlighting a gap
C. Widevine Over EME between what Widevine promises and their technical solution.
Similar to the unified DRM API of Android, the World Wide The raised issues concern not only OTT, but also final users.
Web Consortium (W3C) defines the Encrypted Media Exten-
sions (EME) standard to provide a standardized API enabling A. Privacy Concerns
web applications to interact with the browser-supported DRM. The Widevine protocol comes with privacy concerns for
EME is designed to make the same web application to run on users in the streaming ecosystem. These issues are due to
any browser regardless of the DRM implementation. Despite the need of Widevine to identify users’ devices for bailing
being optional, EME is supported in major browsers: Edge, purposes. Indeed, Widevine collects device specific data, and
Firefox, Chrome, Safari, Opera, and their mobile versions [18]. sends them to distant servers, such as the provisioning or
The logic of the EME standard is quite similar to the license ones. For instance, in Android these data includes the
Android DRM system. Indeed, when the web application Widevine Device ID within the Widevine keybox, and the
attempts to play an encrypted video, it starts by creating device blob containing several device-identifying fields, such
a MediaKeys, which is the object providing access to as the device architecture, phone model, CDM version, or build
the CDM. Then, it calls createSession to instantiate info.

9
 Ironically, Widevine commits to respect users’ privacy. As a the Google Hall of Fame and the Android Security Acknowl-
matter of fact, Widevine claims to follow the EME standard. edgments. Our goal is to improve the knowledge about DRM,
Despite being non-normative, user-tracking issues are being and not to provide copyright infringement tools.
pointed out in the privacy section of the EME standard [18]. VIII. R ELATED W ORK
However, the usage of Distinctive Identifier or Distinctive
Permanent Identifier allows origins crossing information to A. Closed Source Proprietary Protocol
spot a single user based on these device-unique values. This Closed source protocols are often studied in the literature
is harmful for privacy, since it allows third-party servers to to provide building grounds or to point out security flaws of
profile users’ behavior during media consumption. Moreover, the analyzed protocol. For instance, Wouters et al. [20] show
users never consent to such device tracking. that the proprietary autonomous car keyless protocol of Tesla
is vulnerable to key injection, which allows an attacker to
B. Recovering Widevine L3 RoT steal a car in a matter of minutes. Moreover, in their work
Widevine presents their DRM for OTT platforms as a ARIstoteles, Kröll et al. [21] reverse engineered the Apple
solution to protect them from piracy. There exist several levels Remote Invocation undocumented protocol on iOS and found
of compromise; each one relates to some cryptographic keys several vulnerabilities. Their work also includes the design of
in the key ladder. Obviously, RoT recovery constitutes the a tool to foster future research on this topic.
most severe compromise level, since attackers can derive all B. Widevine Keys Recovery
keys allowing to decrypt any protected content. Widevine
In 2019, David Buchanan claimed to have broken L3
distinguishes L1 RoT and L3 RoT, as it is more challenging
Widevine on Linux Chrome browsers in a tweet [22] being
to compromise L1 compared to L3. Indeed, Widevine relies
the only available information about this attack. Buchanan
on software-only protection mechanisms to hide L3 RoT. It is
mentioned that L3 relies on AES-128 whitebox to protect me-
true that such protection is brittle and doomed to be broken.
dia and was vulnerable to Differential Fault Analysis (DFA).
However, advanced obfuscation techniques might make the
Buchanan has never provided any further detail.
compromise quite involving and resources demanding. Here,
Tomer Hadad released widevine-l3-decryptor on Github at
we show how our understanding of the Widevine protocol may
the end of 2020. This project is a Chrome extension on
allow attackers to get L3 RoT without specific knowledge of
Windows that contains a hard-coded value of an RSA key
the underlying obfuscation in an automated matter.
pair used by Widevine L3. Hadad mentioned that he extracted
As explained in subsection V-A, the Widevine RoT is the RSA private key “by applying some mathematical tricks to
encapsulated inside a keybox that is used to initiate the key Arxan’s whitebox algorithm”, before releasing a full writeup
ladder in order to retrieve clear content. Starting by certificate after Google’s patch. Unlike Buchanan, Hadad explained that
provisioning, the RoT is also used in L3 to protect the received the L3 RoT in Chrome browsers is a whitebox of RSA, and not
Device RSA Key for persistent storage (i.e. rewrap operation) AES. In November 2020, Google issued a DMCA takedown
or using keybox related data in device blob. Accordingly, we request against widevine-l3-decryptor and all its forks [23],
build the following approach to recover L3 RoT. We know proving that L3 security is still seen by Google as a serious
that, by design, the RoT must somehow be loaded during the matter. In a BlackHat Asia talk, Zhao [24] explained how
execution of the Widevine protocol, but the applied obfusca- he broke into Widevine L1 within the TEE to recover the
tion hides the loaded RoT. Here, we rely on WideXtractor Widevine keybox of a Pixel 4. However, he did not show how
to better discern the moment, where the RoT is actually in a recovered keybox can be used to decrypt protected contents.
the memory in clear. At this point, we dynamically analyze In our work, we took this further step and implemented the
all memory regions used during obfuscated cryptographic cryptographic mechanisms of Widevine.
operations within the Widevine library. We search for the
keybox structure (e.g., magic number, device ID). Thus, we IX. C ONCLUSION
were able to recover the L3 keybox on a Nexus 5, including In this paper, we presented the undocumented closed-source
the 128-bit AES Device Key, due to an insecure storage of Widevine protocol with its cryptographic components. By
sensitive information (CWE-922). Technical details can be reverse engineering the Widevine CDM on Android, we ex-
found in appendix B. Our method is efficient, since we limit tracted the logic behind its key ladder and provisioning phases.
the spatial and temporal memory monitoring. Based on the gained insights, we design WideXtractor, a tool
Responsible Disclosure. Our findings have been timely analyzing the protocol workflow and all message exchanges
reported to all concerned parties following their responsible between clients and distant servers. We show the effectiveness
disclosure process. Netflix was quite responsive and we got of WideXtractor by inspecting the use of Widevine by Netflix,
rewarded via their bug bounty program. Regarding Google thereby uncovering interesting findings about Netflix asset
Widevine, our security report was assigned with the highest protection. Furthermore, we were able to trivially recover
priority within the Google Vulnerability Reward Program the L3 RoT, which allows attackers to obtain any content
(VRP). The Widevine security team investigated our findings of sub-HD quality. Being widely deployed, DRM security
and issued a patch to mitigate our identified flaws. Google becomes critical. Our objective is to encourage and foster
assigned the CVE-2021-0639 for us, and acknowledged us in further research about DRM-related technologies.

10
 R EFERENCES A PPENDIX A
[1] D. Dorwin, J. Smith, M. Watson, and A. Bateman, “Encrypted Media OEM C RYPTO L IBRARY S YMBOLS E QUIVALENTS
Extensions,” https://www.w3.org/TR/encrypted-media/, 2019.
[2] H. Halpin, “The Crisis of Standardizing DRM: The Case of W3C Symbols OEMCrypto Functions Symbols OEMCrypto Functions
Encrypted Media Extensions,” in SPACE, ser. Lecture Notes in Computer oecc01 Initialize oecc25 Generic Decrypt
Science, vol. 10662. Springer, 2017, pp. 10–29. oecc02 Terminate oecc26 Generic Sign
oecc03 InstallKeybox oecc27 Generic Verify
[3] Google Widevine, “Widevine,” https://widevine.com/. oecc04 GetKeyData oecc28 GetHDCPCapability
[4] ISO/IEC, “Common encryption in ISO Base Media File Format files - oecc05 IsKeyboxValid oecc29 SupportsUsageTable
2nd Edition,” 2015. oecc06 GetRandom oecc30 UpdateUsageTable
[5] D. McCullagh, “Security warning draws DMCA threat,” https:// oecc07 GetDeviceID oecc31 DeactivateUsageEntry
www.cnet.com/news/security-warning-draws-dmca-threat/, 2002. oecc08 WrapKeybox oecc32 ReportUsage
oecc09 OpenSession oecc33 DeleteUsageEntry
[6] Electronic Frontier Foundation, “Reported Case List,” https: oecc10 CloseSession oecc34 DeleteUsageTable
//www.eff.org/files/2016/03/17/1201 reported case list revised.xls, oecc11 DecryptCTR oecc35 LoadKeys*
2017. oecc12 GenerateDerivedKeys oecc36 GenerateRSASignature*
[7] MITRE, “CVE List,” https://cve.mitre.org, 2022. oecc13 GenerateSignature oecc37 GetMaxNumberOfSessions
[8] Fortune Business Insights, “Over The Top services market to reach USD oecc14 GenerateNonce oecc38 GetNumberofOpenSessions
oecc15 LoadKeys* oecc39 isAntiRollbackHwPresent
139.00 billion in 2028; emergence of Smart TVs by various companies
oecc16 RefreshKeys oecc40 CopyBuffer
to bolster growth,” https://www.globenewswire.com/news-release/ oecc17 SelectKey* oecc41 QueryKeyControl
2021/08/17/2281647/0/en/Over-The-Top-Services-Market-to-Reach- oecc18 RewrapDeviceRSAKey oecc42 LoadTestKeybox
USD-139-00-Billion-in-2028-Emergence-of-Smart-TVs-by-Various- oecc19 LoadDeviceRSAKey oecc43 ForceDeleteUsageEntry
Companies-to-Bolster-Growth-states-Fortune-Business-Insights.html, oecc20 GenerateRSASignature* oecc44 GetHDCPCapability
2022. oecc21 DeriveKeysFromSessionKey oecc45 LoadTestRSAKey
oecc22 APIVersion oecc46 Security Patch Level
[9] G. Beniamini, “QSEE privilege escalation vulnerability and ex- oecc23 GetSecurityLevel oecc47 LoadKeys*
ploit (CVE-2015-6639),” https://bits-please.blogspot.com/2016/05/qsee- oecc24 Generic Encrypt oecc48 DecryptCENC
privilege-escalation-vulnerability.html, 2016. * Duplicated entries differ in version.
[10] Google, “Factory Images for Nexus and Pixel Devices,” https://
developers.google.com/android/images.
[11] National Security Agency, “Ghidra SRE.” https://ghidra-sre.org/. A PPENDIX B
[12] “Radare2,” https://rada.re/n/. L3 K EYBOX R ECOVERY
[13] O. A. V. Ravnås, “Frida,” https://frida.re/.
[14] Widevine, “Widevine DRM,” https://www.widevine.com/solutions/ Being the root of trust, we are motivated to recover the
widevine-drm. keybox. Widevine maintains a different keybox for the differ-
[15] C. Garman, M. Green, G. Kaptchuk, I. Miers, and M. Rushanan, “Danc-
ing on the Lip of the Volcano: Chosen Ciphertext Attacks on Apple ent levels of security. In subsection V-A, we explained that
iMessage,” in USENIX Security Symposium. USENIX Association, L1 protection is TEE-dependent. In QSEE, it is based on the
2016, pp. 655–672. Secure File System, whose security is outside the scope of
[16] Android, “Protect against security threats with SafetyNet,” https://
developer.android.com/training/safetynet, 2022. this paper. Here, we will focus on L3 keybox. Note that L3
[17] The Verge, “Netflix surpasses 200 million subscribers, but has more implementations are diverse. Our analysis shows that Widevine
competition than ever in 2021,” https://www.theverge.com/2021/1/ is as secure as the weakest one, since license keys for a given
19/22238877/netflix-200-million-subscribers-q4-earnings-bridgerton-
emily-paris-cobra-kai-queens-gambit, 2022. media are shared among all L3 implementations. Therefore,
[18] Can I Use, “Encrypted Media Extensions,” https://caniuse.com/eme, someone might take advantage of outdated implementations
2022. to break into Widevine. Indeed, they can intentionally display
[19] Google, “Eme Call and Event Logger,” https://
chrome.google.com/webstore/detail/eme-call-and-event-logger/ content on vulnerable smartphones, so that they can easily
cniohcjecdcdhgmlofniddfoeokbpbpb, 2022. recover protected media. This works as long as OTT platforms
[20] L. Wouters, B. Gierlichs, and B. Preneel, “My other car is your car: keep support for old Android smartphones, as they target wide
compromising the Tesla Model X keyless entry system,” IACR Trans.
Cryptogr. Hardw. Embed. Syst., vol. 2021, no. 4, pp. 149–172, 2021. audience. In this paper, we study the L3 of Google Nexus 5
[Online]. Available: https://doi.org/10.46586/tches.v2021.i4.149-172 that still runs many OTT apps.
[21] T. Kröll, S. Kleber, F. Kargl, M. Hollick, and J. Classen, “ARIstoteles By taking a closer look at libwvdrmengine.so, we
- Dissecting Apple’s Baseband Interface,” in Computer Security -
ESORICS 2021 - 26th European Symposium on Research in Computer notice that OEMCrypto L3 functions are obfuscated. This
Security, Darmstadt, Germany, October 4-8, 2021, Proceedings, Part I, makes our analysis more complex, since the keybox is only
ser. Lecture Notes in Computer Science, E. Bertino, H. Shulman, and used within these functions. Moreover, we find that all ob-
M. Waidner, Eds., vol. 12972. Springer, 2021, pp. 133–151. [Online].
Available: https://doi.org/10.1007/978-3-030-88418-5 7 fuscated functions apply anti-reverse transformations, such as
[22] David Buchanan, “Breaking Widevine L3 on Linux Chrome browser,” control flow flattening, that make static analysis less relevant.
https://twitter.com/david3141593/status/1080606827384131590, 2019. In addition, memory regions are mapped with read and exe-
[23] Github, “DMCA,” https://github.com/github/dmca/blob/master/2020/11/
2020-11-09-Google.md, 2020. cute permissions. Because of ARM architecture blurring line
[24] Q. Zhao, “Wideshears: Investigating and breaking widevine on QTEE,” between code and data, we find it hard to tell if these mapped
BlackHat Asia, 2021. regions are destined for data to load or code to execute.
The approach that we followed to recover the keybox was
not to directly break into the layer of obfuscation. This would
have made of our work technology-dependent, while we aim
for more long-term lessons. Instead, we stepped back and
monitored the unprotected functions calling the OEMCrypto
interface using WideXtractor. Indeed, we notice that most
functions of libwvdrmengine.so are not protected. Thus,

11
we managed to collect a lot of memory data loaded during the
execution of the obfuscated functions. Of particular interest,
we were able to observe all memory unmapping that happens
through calls to munmap. We noticed that the OEMCrypto
functions load a significant amount of data though these calls
especially sensitive ones.
Thus, our next target is to look for a function requiring
the keybox for its operations. We recall that the keybox
is regularly used in OEMCrypto_LoadDeviceRSAKey to
decrypt the rewrapped Device RSA Key in L3 mode, but
also during device blob creation with OEMCrypto methods
like GetDeviceID or GetKeyData. Accordingly, these
functions map a proper region of memory for the keybox, loads
the keybox value inside it, and finally unmaps that region at
the end of the function. Because of the obfuscation, it is hard
to observe the loading step. However, these functions do not
clear the memory before unmapping. Therefore, we retrieved
the content of the unmapped regions. Then, relying on what
we know about the keybox, we filtered this content to keep the
regions of size 128 bytes including the keybox magic number.
It turns out that there is only one. We verify our finding
by checking the CRC-32 value. The keybox being recovered,
we can now decrypt the license keys, hence the video tracks
destined to L3. It is worth noting that this is particularly
interesting, especially that we did not even get to break into
the underlying obfuscation. In fact, our analyses were guided
by the conceptual structure of the Widevine protocol.

12