Where PlayReady sits in an Android app
Android exposes DRM through MediaDrm, which hands opaque challenge bytes to the app and accepts opaque licence bytes in return. PlayReady is implemented as a plugin behind that interface, so the Java layer you can read holds session management, provisioning state and the HTTP call that carries the challenge to the licence server. The cryptographic operations stay inside the plugin and, where the device supports it, inside hardware.
Players usually reach MediaDrm through a media library rather than calling it directly. A MediaDrm callback provides the request the player should send and receives the response, which is why the licence request often looks like any other API call in a capture, with the same authentication headers, the same signing scheme and the same session cookies as the rest of the client.
The licence flow in order
The player creates a DRM session and asks it for a licence request. The session produces a challenge that is bound to that session. The app wraps the challenge in an HTTP request to the licence server, usually adding the user's token and any request signature the service requires. The server answers with a licence response that the app passes back to the same session. Playback then decrypts through the session.
Two properties of that sequence decide what a usable client looks like. The challenge bytes are opaque, so they cross the wire unchanged, and the response is bound to the session that produced the challenge, so the caller has to be the process holding that session. A client that fetches a licence independently and stores the bytes has nothing to deliver them to.
What is worth reproducing
The useful target is the app's licence path rather than the DRM plugin itself, and reproducing it usually means these pieces.
- The HTTP request that carries the challenge, with its headers, body encoding and any signature, so the same call can be issued from a script or a service.
- The session lifecycle around it, so a client can obtain a licence, use it and re-request when the session is renewed.
- The authentication in front of the licence endpoint, which in most apps is the same token and signing logic used elsewhere in the client.
- The response handling that turns the licence bytes into something the app accepts and stores.
Apps that also keep persistent licences store a licence bound to the device and reuse it on later runs. Persistent licences remove some repeat traffic, but they remain device-bound, so reproducing a flow on a workstation still depends on holding a valid session on the device that plays the content.
Error responses from the licence server tell you which of those pieces you have wrong. A server that rejects a malformed challenge, a server that rejects the account token, and a server that accepts the request but refuses the device are three different problems, and the response body or status separates them before you spend time on the DRM layer itself.
Media libraries also expose the licence URL as configuration, and it is worth reading that configuration before assuming a single endpoint. Services commonly split licence acquisition from key delivery, or route different content through different servers, and a client written against the wrong one receives a response that looks like a refusal.
What does not move
MediaDrm ties a session to the device where it was created. Provisioning data and the DRM identity are part of that binding, and a licence fetched for one session is not usable in another. On devices with hardware-backed key handling, the keys used to decrypt content never exist in app memory, which is why extracting them is not the practical route and why the licence request is.
The work therefore lands on the ordinary API surface around the DRM call: the endpoint that issues licences, the headers the server requires, the sequence of session setup, and the error paths when a licence is refused. Treating that surface as an API problem gives something testable and reusable, while treating the DRM plugin as the target tends to produce partial results that stop working on the next device or the next session.
Related work
Reviewed 28 September 2026 · SReverse research desk