#EXT-X or m3u8 or TS or AES-128? You got HLS.. Howto Beat it in 2017

[streamcrank]

It's called HTTP Live Streaming and it's a standard..

There is usually a master m3u8 with, for example different resolutions or audio only. Then each version of the content has it's own m3u8 that has the ts files you download and copy(copy *.ts example.mp4 on Windows for example). Then run it through ffmpeg to clean it up.

If it uses encryption then each .ts has it's own crypto key url("#EXT-X-KEY:METHOD=AES-128,URI=") and iv(example:"IV=0x00000000000000000000000000000007" ) that is used to decrypt it. The key is the body of the response of that http GET to the key url. Each key is for each TS there is no inheritor or weird padding or mixing going on..

How big networks make it more secure: The spec allows for a global key also in the ts-m3u8 that is used to decrypt each ts key, and the hosts usually timeout sessions on these and only server over https/tls. FFMPEG can still beat this security if you pass it a fresh enough URL. Sometime you have to manually dump using a cookie but not often. Grab the page with python and use the cookie header to grab ts files and either decrypt with a python encryption library(no native library) or use openssl CLI. Some might start using HTML5 storage too. With spec security just use the following.

How to easily get the m3u8:

//F12 then in console:
document.getElementsByTagName('video')[0]

How to rip even the secure ones(since HTML5 player has strict rules on key exchange). NOTE: if FFMPEG stops for any reason use the -ss option in front of input to resume ripping to a new file and just concat later; this happens with me with 1080 stream ripping.

ffmpeg -protocol_whitelist file,udp,rtp,crypto,tcp,https,rtsp,tls -i "TS-M3U8 URL HERE" -c:a copy -c:v copy "OUTPUT FILE HERE.ts"

Best transcode

//remove -hwaccel auto if you get errors
ffmpeg.exe -hwaccel auto -i "TS FILE HERE" -c:a copy -c:v x265 "OUTPUT PATH HERE.mp4"

P.S. I only got in to streaming a couple days ago but have seen this before on paid podcast networks except not encrypted.. It's easy.. If you use it I suggest tighter rulers on the global key. THE future: Using TPM hardware for decryption with binding to HTML5 video internals.

[kingstaytheking]

this isn't gonna work for encrypted streams .. like hbogo, showtime anytime etc...

[streamcrank]

Originally Posted by kingstaytheking

this isn't gonna work for encrypted streams .. like hbogo, showtime anytime etc...

If it works on Uplynk HLS streams it'll work on all of them. Uplynk uses master+segment keys in AES-128.. I feed them directly to FFMPEG and get clean 1080p rips..

Unless they use a custom player with FlashPlayer they have to comply with the HLS standard to get it to work with HTML5 <video>.. Most browsers shut off FlashPlayer based on domain policy or MAC so HTML5 is pretty much their only option.. Third party players like JWPlayer are even defaulting to HLS standard now.. All of their developers have to be force fed knowledge like most textbook CS grad software people so don't expect them to tighten security around the key URIs anytime soon..

[arec]

This is the kind of stream I am having difficulty with. When I try your code...

ffmpeg -protocol_whitelist file,udp,rtp,crypto,tcp,https,rtsp,tls -i "TS-M3U8 URL HERE" -c:a copy -c:v copy "OUTPUT FILE HERE.ts"

using my own filenames I get an error about "unable to open key file". I am not sure how to get that key file from the m3u8 file. I have read that it could be found in a cookie but also that it could be found in them m3u8 file itself.

[streamcrank]

Originally Posted by arec

This is the kind of stream I am having difficulty with. When I try your code...

ffmpeg -protocol_whitelist file,udp,rtp,crypto,tcp,https,rtsp,tls -i "TS-M3U8 URL HERE" -c:a copy -c:v copy "OUTPUT FILE HERE.ts"

using my own filenames I get an error about "unable to open key file". I am not sure how to get that key file from the m3u8 file. I have read that it could be found in a cookie but also that it could be found in them m3u8 file itself.

second red text is from first red text. They likely use cookies or referrer or timeout or all of the above to protect individual and/or master key URI. With these you need to use a python script the uses cookie header and sets referrer header. This isn't an uplynk thing it's a client thing.

[arec]

Roger that, thank you steamcrank!

[Yelloworanges]

Originally Posted by streamcrank

P.S. I only got in to streaming a couple days ago

Originally Posted by WHOOKIDSON

Last time I checked it was #EXT-X-KEY:METHOD=SAMPLE-AES,URI="faxs://faxs.adobe.com",KEYFORMAT="com.apple.streamingkeyd elivery",KEYFORMATVERSIONS="1",IV=

Nothing streamcrank has said indicates that he is familiar with flash access.

[streamcrank]

Originally Posted by Yelloworanges

Nothing streamcrank has said indicates that he is familiar with flash access.

What is "flash access".. It doesn't exist..

Flash can use custom same-domain protocols and encryption and has a a few codecs because it has ASC which you can code anything. You dump the ASC with a flash decompiler then reverse engineer it.. Again "flash access" does exist. JWPlayer is flash based and I've extracted TEA encryption keys from it before.

AES-SAMPLE works the same as AES-128 except they can change keys instead of just IV per segment. I don't care about these other networks because all the big networks use uplynk and zype and uplynk and zype only use variants of HLS that are all standards compliant..

https://bitmovin.com/tutorials/hls-encryption/

[Yelloworanges]

Originally Posted by streamcrank

What is "flash access".. It doesn't exist..

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

Originally Posted by streamcrank

AES-SAMPLE works the same as AES-128 except they can change keys instead of just IV per segment.

https://bitmovin.com/tutorials/hls-encryption/

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.

Originally Posted by streamcrank

I don't care about these other networks because all the big networks use uplynk and zype and uplynk and zype only use variants of HLS that are all standards compliant..

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.

[streamcrank]

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.