aSUS
Improper protection of DRM Root of Trust (OTA UPDATE) on ASUS ROG 3
Device Fingerprint:
asus/WW_I003D/ASUS_I003_1:11/RKQ1.200710.002/18.0410.2201.192-0:user/release-keys
… aaand, newer firmware versions
What is Widevine?
Widevine is a DRM scheme owned by Google used to protect content delivered by OTTs (ex. Amazon Prime Video, Netflix, etc.) and is also used by educational content providers to prevent piracy. Widevine uses a robust mechanism for the encryption of delivered content and offers a secure mechanism for the CEK (AES-128) delivery.
Widevine has three security levels,
L1 – Content decryption and cryptographic operations are carried out in a secure enclave such as TEE.
L2 – Cryptographic operations are carried out in a secure enclave.
L3 – Both decoding and cryptographic operations are carried out in the userland.
The Issue
ASUS ROG 3, on its release, was a Widevine L1 certified device. But due to some unknown reasons, many random devices of the model had their Widevine level downgraded to L3, which resulted in many customers not being able to stream content in HD quality.
ASUS pushed out a software update to install L1 in the affected devices to address the issue.
Although it is recommended that phones be physically brought to the factory to install the L1 keyboxes (root of trust, more on that later) in the device TEEs, OEMs sometimes make provisional arrangements to deliver these secrets through OTA, especially when the affected number of devices is high.
Google recommends that OEMs shall have some type of secure cryptographic secret to encrypt these keyboxes through OTA delivery, and it is solely the OEM’s responsibility to take care of it. This is where ASUS went wrong.
The Widevine Keybox
Widevine uses a 128/132 byte secret key unique to a device which it authenticates with its provisioning servers to securely install a corresponding certificate and a private key to the device which could then be used to authenticate with Widevine license servers to retrieve licenses.
A device can provision an unlimited amount of different private keys which are all valid and can be used for License retrieval.
The Mechanism
In the newer firmware versions with which the fix was shipped, one can, on close inspection, find a bash script named ‘ReInsWDKey
’, which I think stands for ‘ReInstall WiDevine Key
’. Anyways, it performs the following steps:
Look for
/ADF/keybox.bin
If it exists, call a binary
/vendor/bin/install_key_server
with the argumentdecryptWD
Delete
/ADF/keybox.bin
Naturally, the next step was to look what this ‘install_key_server
’ does, and what I found was this:
We will come to server_main()
later

Relevant part of function decrypt_WDkey()
:

Here, we see that the binary opens the file situated at /ADF/WDKEY
, performs bitwise operations on it, and saves it into /ADF/keybox.bin
, for which ReInsWDKey
checks for in the bash script.
And guess what? The output of the bitwise operations is the PLAINTEXT KEYBOX!
Where aAsus is simply the string "ASUS".
Yes, the OTA “encryption” (which might not be the right word) key of ROG 3 keyboxes is ‘ASUS’, which is beyond absurd for an international OEM of a scale this big as ASUS.
To confirm this finding, porting the relevant bitwise operation code to Python reveals the plaintext keybox.

Which is a 128 byte value, and is installed to the TEE later with the help of the OEMCrypto API using the function server_main()
we saw earlier.
I confirmed that it was indeed the plaintext keybox since it contains the magic ‘kbox’ which is defined in the keybox format by Google, followed by a crc32 checksum.
I am not sure if the same “encrypted” keybox (WDKEY
) has been provided to each device.
Going by the rules, every device should have a different keybox, but I cannot confirm the same because of a lack of another phone of the same model.