What arrives at the licence endpoint
The licence server is a separate service from the streaming host. It usually sees a POST with a binary body, a content type the app chooses, and the headers the app added. The body is produced by the content decryption module on the device, not by the application. The application supplies the destination, the authorization and the timing, which is why two apps using the same DRM system produce requests that look completely different at the HTTP layer.
Finding the endpoint is a matter of watching which host receives a small binary POST immediately before playback starts. That call often follows an app-level request that returned a manifest URL, a token, or both.
The three exchanges inside the device
- Provisioning. The CDM obtains a device certificate from a provisioning service and stores it. Until that succeeds, the device cannot usefully ask for keys.
- Key request. The CDM builds a request from the content identification in the manifest, the key type, and its own certificate, then signs or encrypts it with material it holds.
- Key response. The licence server returns an encrypted licence containing the content keys and the policy attached to them. The CDM validates it and installs the keys into a session.
Each exchange is opaque to the app. The application hands bytes to the platform API and receives bytes back, and the meaning of either side is defined by the DRM system rather than by the app.
Where the content identity comes from
The manifest carries protection metadata for each track. In DASH it appears as a content protection element naming the scheme and holding a PSSH box; HLS carries a comparable construct. Those boxes identify the content and the key IDs the CDM should ask for. A licence server authorises a request against those identifiers, so a licence captured for one title does not work for another even when the endpoint and the token are unchanged.
This is also why a manifest fetched from a different source can produce a licence request the server refuses. The bytes in the PSSH determine what the CDM asks for, and the server checks them against the account and the playback session.
The part the app controls
Around the CDM message sits an ordinary HTTP request that the app shaped. Tracing it means reading the following, in this order:
- The licence URL, which may be hardcoded, returned by a playback start call, or defined in the manifest.
- Headers, most often a bearer token or a signed header produced by the same helper the app uses for its other API calls.
- Query parameters carrying a playback session identifier, a content identifier or a DRM token.
- Optional key request parameters, which the app can pass into the request so the CDM includes them in the message it builds.
- Retry behavior, including whether a failed licence call triggers a new session or reuses the existing one.
Some apps also provision a service certificate, which lets the CDM encrypt the content identification so an intermediary cannot read it. Whether an app does that changes how much a proxy capture reveals, and it does not change the endpoint or the authorization around the call.
Streaming, offline and renewal requests
A licence request is not always the first request for a title. The CDM distinguishes a streaming licence, which is used while the content plays, from an offline licence, which is stored so playback can happen later without contacting the server. A player may also send a renewal for a streaming session whose keys are close to expiring, and a release when a session ends. Those requests share an endpoint and differ in the message the CDM produces.
An analyst who assumes one request per playback will misread a capture that contains a renewal several minutes in. Treat the licence endpoint as a conversation that lasts as long as the session.
Security levels and device policy
Devices report the security properties of their DRM implementation, and a licence server can refuse to issue keys when the reported level does not meet the policy for the content. The level is a property of the CDM on that device, read through the platform DRM API. An app can request a level, and the device answers with what it supports. When a licence is refused with no useful HTTP error, the decision often comes from that policy rather than from the app's token.
Why a captured request usually fails on replay
- The message is bound to the device certificate the CDM holds, so it does not transfer to another device or another install.
- The token in the header is short lived and often tied to a playback session that the server tracks.
- The playback session may be single use, so the second request for the same session is refused.
- The key IDs in the message must match the manifest the server expects for that account.
- The body is consumed by the CDM and cannot simply be regenerated by a different client.
What a reconstruction can deliver
The reproducible half is the app's flow: how the client obtains a manifest, how it requests authorization, which headers and parameters travel with the licence call, how it reacts to a refusal, and how it refreshes a session that is running out of time. A working client performs those steps for a legitimate account on a device that is already provisioned, which removes the need to drive the interface by hand and gives the operator a documented interface to the same content the app plays.
Related work
Reviewed 28 September 2026 · SReverse research desk