What software can put back together
A protected playback flow has two halves. One half is application code: the calls that authenticate an account, the manifest and segment URLs the player is handed, the token placement on the licence request, the session bookkeeping around playback. That half is ordinary API work and it can be reconstructed in software, because it consists of requests an app composes and sends.
The other half belongs to the platform component. The CDM holds a device identity, performs the cryptographic operations for key exchange, and in hardware-backed configurations keeps the content keys where application code cannot read them. Software alone does not reproduce that half. It can construct the outer request and follow the response, and it cannot become the CDM.
Knowing which half a project needs is the question worth answering before commissioning anything. A flow built on entitlement calls, signed URLs and session tokens is reachable. A requirement to obtain content keys, or to implement a working CDM, is not reachable through reverse engineering and is not something a legitimate reconstruction service can offer.
Parts of the flow that reproduce in software
- Entitlement and catalog calls reproduce directly. They are HTTP APIs with tokens, and once the signing and session rules are known they run from a script.
- Manifest and segment handling can be rebuilt. Parsing the manifest, ordering the tracks and constructing segment URLs with the right CDN token is application-level work.
- Licence request framing is reproducible. The destination, the headers, the token, the retry behaviour and the error handling around the CDM call all belong to the app, and a client can perform them on a device that is already provisioned.
- Session and playback state can be modelled. Heartbeats, concurrency limits, position reporting and renewal calls are state machines that a headless client can run.
- Refusals can be attributed. A capture tells you whether a failure came from the app's backend, the licence server or the CDN, which is the diagnostic that most projects actually need.
Parts that depend on secure hardware
The device certificate and its private key are held by the CDM in storage the platform protects. A software client can shape a licence request, and the licence server still expects the identity that a genuine CDM presents. A device that has provisioned supplies that identity. A script cannot.
Content keys are the second dependency. Modern DRM deployments use hardware-backed decryption paths, so keys are unwrapped where application code cannot reach them, and protected frames are decrypted on a path that ordinary software does not sit in. Even when software runs on the same device, it does not gain access to that material, because the keys are not exposed to it in the first place.
Revocation is the third. A licence server can refuse an identity it no longer recognises, and it can bind the entitlement to the device that asked for it. A reconstruction that relies on a credential the operator can withdraw is a short-lived result, and its lifetime is not under the control of the team that commissioned it.
Key identifiers add detail rather than a way around any of this. Different tracks and different content use different keys, and some deployments choose key types or robustness levels that require a more capable execution environment. That changes the shape of the request and what the server will release, and it does not move the boundary.
Judging a case before it is commissioned
A first pass over a target answers the question in an afternoon. Which hosts does the player talk to? Which calls carry tokens the app obtained earlier? Does the licence request travel through the app's HTTP client or through a platform callback? Where does any signature get computed? The answers classify the work as application-level, protected at the request layer, or dependent on the DRM component.
The classification is useful even when the answer is no. A team that wanted keys and learns that its actual requirement is monitoring, migration or interoperability can usually be served by the app-level reconstruction instead. A team whose requirement genuinely depends on key material learns that before paying for an attempt.
The deliverable from a software reconstruction is a working client for the app's half of the flow: entitlement, manifest handling, licence request framing and session tracking, in the language the team uses, with documentation of each step. Where a case turns out to depend on secure hardware, the honest result is a written boundary rather than a partial client that fails at the first licence exchange. A short feasibility pass that states which calls are reachable and on what conditions is often the most valuable thing a project of this kind produces, because it prevents an expensive attempt at the half that cannot be rebuilt.
Related work
Reviewed 28 September 2026 · SReverse research desk