Fully secured iOS streaming... unrippable. Testers required
 

OK, tagging on from my continued saga against the rippers, I've finally gotten extremely well protected iOS streams going....

Just so you can test:
http://bw.borkedcoder.com/iOS/

*NOTE* (and I know the GFY crowd won't read this)
if you *aren't* on an iOS device, you won't see the beauty - you'll just get a SWF stream
This test is purely for iOS (which as you know doesn't support flash).

If you're into this stuff, you know the problems of iOS support - html5, agent spoofing, chunk downloads... all meaning a ripper's playground to get your swf-protected content out there...
Well, this fucks with all that and makes it unrippable. Everything, including the actual stream is 128bit-strong encrypted.

Have a bash, and try rip the iOS stream... game on.

btw, *if* you have apple TV, the iOS stream *should* be projectable to your AppleTV. This is something I'm interested in testing, but don't have one to test... if you have, can you try projecting (little button on iOS device during stream to send to AppleTV) and see...

Porn on Apple TV in a secure way - that would be cooooool :thumbsup

Very impressive, if I thought I had the knowledge to trumph you, I would give it a shot. But knowing that it's you behind it, I won't even waste my time. Five years ago, I would have taken on the challenge...

what is to stop someone from doing a low level analysis of the data going to the video at the os level, and saving that data to be re-assembled into an unencrypted ripped and viewable format? just curious

Can I just use a program like FRAPS, etc, combined with a user agent spoofer to grab 'em? Trying to save myself the effort if you've already coded around that. ;)

Sounds kind of interesting.

So by using any user agent other than ios it's easily ripped? Maybe we can work together on a complete solution.

If it's HTML5 then I guess it's using User-Agent combined with HTTP Referrer to detect where the client is coming from.

User-Agent alteration doesn't seem to work though.

I've managed to get it to load in Mac Safari.

In this regard no matter what you do will prove naive and futile.
This is taking place in a browser?
People modify browsers.

...just ripped it with snapz pro :(

haha - I have already thought of that, I'm not that naïve :winkwink:
The html5 <video> stream will only work for iOS devices (ipad/pod/phone) and I'm *hoping* for restreaming to AppleTV.

not any more.... :winkwink:

that is a screen ripper, which has ripped the movie playing from the flash file. However, it has also ripped the user-identifiable info that is showing every 5 seconds randomly on the screen :winkwink:
The player is customisable to show some server-determined string every x seconds for y milliseconds to be able to identify the source of a screen rip...

However, snapz pro didn't rip the iOS stream, which is what this is about :winkwink:

Well, for the iOS stream, it would have to be done from an iDevice... the server will reject any attempt to stream if the device isn't an iDevice... and user-agent spoofing *will not* get around this....

iDevices send out http requests for videos at a level much deeper than the browser, and you cannot get around this as it's within the iOS webkit. You can't get around that and so the streaming server will reject the request :thumbsup

It's true that jailbroken iDevices can then recover the video from the cache. However, this is useless since the cached video is 128bit encrypted and the public key has long disappeared from the cache :thumbsup

cool, well best of luck with it!

You're alive!

thanks testers - I could see iOS5.x users would receive "not permitted", but now that's fixed.
iOS 5 now supported

:1orglaugh:1orglaugh
yeah, but with retinal burn in.... been hard at work

So are you! Thought you may have gotten washed away :(

Oh yeah, I forgot to say, in this test the streams are time-sensitive, so your iOS will get a forbidden if you open up the page and wait to stream... or try re-streaming later on
Thought I'd play around with that option as well, cos it's useful for live streams like cams n shit.

Nice idea. Streaming the great race is it ?

Edit: at 1:09 it dies.

yup,

I would like to implement this also for android, although I don't have an android device to test with :(

If anyone with android could test this link

I can see things better my end - you probably will be able to stream, but at least I can see server-end to secure it...

The stream was valid only for 1 min for testing, I've extended this to 1 hr

I don't know what you have changed but I'm getting quite a bit of stutter on the stream now from time to time.

Nothing changed to create lag, but the server is located in France, and France just started working so the pipes between server and you may be blocked ;)

Not to mention even at the speed of light it's approx 234ms to Australia from France :-)

looks like its just wowza and apple's live http streaming.

seems like it wouldnt be too hard to bypass since the encryption key is also sent at the same time

there are many levels of security added at each stage, from browser page load to end-video play.

That is why I have asked for attempts at cracking the stream into a un-encrypted video on a computer, or any device.

I know it seems like it wouldn't be too hard, and that's why I put a *lot* of time and effort into it ;) And no - there is no encryption key sent. Only an encrypted stream name.
The private secure key is server-side only. Known only to apache and the streaming server.
The beauty is in how iOS handles live http streaming... which is actually a plus for Apple

lacks fresh poo... fail...

Sorry this video cannot be played.

Android 2.3 browser

Hmm. It works using Skyfire browser which converts it for the phone, but is only a small size on the screen and won't expand to anything bigger than the size of a large postage stamp.

Interesting. Detecting window frame size maybe?

I was with you up until this.

A HTTP request is a HTTP request. If it's deeper then that's just a TCP socket.

Yes it's still a http request. However it isnt the browser making the request, its lower down than the safari engine. Bad choice of words perhaps on my part

Interesting. Thats on android?
Im not too familiar at all with android but i thought 2.3 supported m3u8 plalists in httplive requests...
Do you know of any urls working for html5 android streaming of m3u8 playlists so i can look?

Blank page on 2.2.2

new android device in by friday for testing purposes mostly.

That's on Android 2.3 but it's a custom rom not something official.

Fairly low spec phone (zte blade) as I got it specifically to fuck about with and not care about if I was going to turn it into a paperweight.

Skyfire is this and I only use it on video sites as the phone doesn't officially support flash. Although I have got Adobe Flash Player 10.2 on there since someone fixed it to work with the Arm6 processor but it struggles and plays things a bit shakily.

I don't understand enough about Linux to even start thinking about how to save your video :(

It's streaming just fine for me in IE8. Is it not supposed to?

With Flash though?

It's not working for me now iOS5.

Yes if I right click it I get flash player info.

grrrr don't make me install iOS5 to debug :(

Are you sure it was a new page refresh and not an already-watched video? A video that has already been watched will require a page refresh since the encryption keys for the actual video have long expired - they are single-use keys.

Can you hit up the page again, refresh and try again? If still not, I'll have to fire up itunes and update from 4 to 5 which I didn't really want to do!

Yar, that's a fallback... if you aren't viewing the page with an iOS device, you'll get the flash player. Streaming via html5 through a regular web browser isn't secure. But as browsers can support flash, there's no need to put out html5 streaming to them... This is about mobile devices since:
1. Apple have never supported flash
2. Adobe are giving up on flash mobile.

So, got to get secure streams to mobiles/pads....

What, NOONE has an AppleTV to test on??? Damn, you lot disappoint me!
Imagine the potential buying power.... HD porn in a secure way on your big phat plasma....

--edit
if someone wants to buy me one, I'll happily test it :P

Works again now. I had to open a new page in Safari. Refreshing alone didn't work.

there definitely is a key sent, otherwise the client would not be able to decrypt the file. in the m3u8 file there's the following field for example:

at best this is perhaps good for preventing people from ripping streams using browser plugins.

Someone else on the wowza forum also posted a step by step guide of easily decrypting the streams:

http://www.wowza.com/forums/showthre...7600#post67600

thanks pstation - I wouldn't say "at best this is good for preventing from browser plugins". It is a real effort to lock down iOS streams.
This is exactly what I wanted testers for (hence the title). I know what every step entails and where keys are sent. The point is is to make it so darn difficult to rip the stream that it won't be worth it.

Sure, if you have an ass-to-mouth exclusive of David Cameron on Barack Obama , then it's gonna get ripped one way or the other. If you want 100% security, don't put it on the internet ;)

Anyways, I see how you did it and so I can probably close that door...
Additionally, I found a bug in the streaming logic - where the request for the key didn't go through the same checks to verify it was coming from an embedded <video> tag.

If you would like to hit me up on email (see sig), I would like for you to test further once I've modified a few things...

It works fine with AirPlay and AppleTV. :)

Actually - I take all that I said previously back...
You didn't get the key at all, just the URL, so there wasn't a bug in the logic. :thumbsup

Sure, I see you got the encrypted chunks but never the key.

that is excellent news :thumbsup
I saw how airplay works now and it really is a restream from the ipad - I was thinking the ipad was simply sending the URL and AppleTV was grabbing the stream (in which case this wouldn't work), but nope - it really is restreaming to the tv
many thanks

bump for a good cause