Quote:
Originally Posted by Yelloworanges
I was using the legacy name. As kingstaytheking pointed out earlier, the more precise name is Adobe Access. No flash player need be involved.
https://helpx.adobe.com/adobe-media-...ction-hls.html
As described in the above link, the content can be protected using three modes:
Vanilla
PHLS
Adobe Access 4.0
Sure, but there is the small matter of actually getting the key in the first place. For HLS implementations of Adobe Access and PlayReady, this is an entirely different proposition than vanilla AES-128 where the key is in plaintext in the first instance.
I can't argue with you not caring. Some members here are interested in content that uses actual hls drm methods to protect the key, which is distinct from vanilla AES-128 hls which is not really drm at all. |
I've reverse engineered plenty of flash media players and have yet to see one using AdobeAccess. Currently I'm ripping HD streams from a lot of big sites and they all use HLS which is a Apple patent and doesn't include any Adobe spec because it wouldn't work with native <video> HTML5 support.
If you see any of the tags I mention in this thread and there is no flash object embedded(so they can have their own custom ASC HLS handling) you can 100% guarantee there is nothing to do with any Adobe spec.. Since most browsers disable FlashPlayer by default they all use HTML5.. Worse Case Scenario: Session timeouts on key URIs with a referrer header check.. Anything else literally breaks playback..
The native HTML5 DRM engine also uses cleartext key exchange over TLS. I haven't seen it used yet but it's well documented.
I'm currently working on a generic tool but FFMPEG is still working when I feed it fresh m3u8. My tool will work the same except I spoof referrer and get a fresh session.