I downloaded NF videos in HD, I can play off line,need a little help W/.key file

[ItsAngel]

Originally Posted by BlueCop

One can still get playready keys for non-HD content. I am still unsure how to enable higher qualities.

I would make a tweak but I don't really know how. I haven't done that before. You can modify it while running with cycript though.

cycript -p Netflix

choose(BuiltinConfig)[0]->_mediaServerValidationPolicy = null

will null the media server validation and allow UVD to get the correct key. This with the tweak to disable DashFairplayStreams from this thread allows UVD to function on the current Netflix version. It will only allow the SD streams though.

You can also grab the correct key from memory like this

choose(NetflixPlaybackSession)[0]->playReadyKey_

actually the current version of UVD and Netflix won't save the audio stream actually.

I made a tweak with Flex, I uploaded it. Not sure if you use flex but you should check it out. I've disabled the FairPlay streams but again that kills HD streams. I named it "Netflix Nfdrm tweak inspect"

[BlueCop]

I haven't used flex. I will check it out.

I found something interesting. The KeyID is the same for the HLS and DASH streams(just endian swapped but flagged as such). This makes me think the keys we have for the SD will work for for HD.

The problem is I think they are using subsample encryption. This mixes encrypted and unencrypted data.

The video track is divided into samples and sub samples. The M3U8 actually just provides the offset and length of each sample. The samples are sub divided into subsamples with unencrypted parts. All encrypted sub samples are treated as a contiguous block for decryption though. So we would need a way to read the subsamples are a contiguous segment to decrypt it properly. I don't know the proper way to read the needed meta-data to accomplish this.

So I believe we have everything to decrypt the HD streams but need a way to properly decrypt it.

I am looking into libraries that could parse the mp4 atoms for me. I found the PIFF Sample Encryption box atom which has the list of IVs and which parts are encrypted and which parts are clear.

[krystallinity]

Originally Posted by BlueCop

I haven't used flex. I will check it out.

I found something interesting. The KeyID is the same for the HLS and DASH streams(just endian swapped but flagged as such). This makes me think the keys we have for the SD will work for for HD.

The problem is I think they are using subsample encryption. This mixes encrypted and unencrypted data.

The video track is divided into samples and sub samples. The M3U8 actually just provides the offset and length of each sample. The samples are sub divided into subsamples with unencrypted parts. All encrypted sub samples are treated as a contiguous block for decryption though. So we would need a way to read the subsamples are a contiguous segment to decrypt it properly. I don't know the proper way to read the needed meta-data to accomplish this.

So I believe we have everything to decrypt the HD streams but need a way to properly decrypt it.

I am looking into libraries that could parse the mp4 atoms for me. I found the PIFF Sample Encryption box atom which has the list of IVs and which parts are encrypted and which parts are clear.

Thanks for all of this research! This is getting me all excited!

[BlueCop]

I wouldn't get too excited. I am not sure I will accomplish anything.

I saved some 1080p H264/AC3 streams via my chromecast. I have been attempting to parse them for decryption(same KeyID). the 5.1 AC3 stream is unencrypted like the 2.0 AAC tracks. The highest quality I was able to save via an iPad was 720p and stereo sound.

I have been examining the files in isoviewer currently. It allows you to examine most of the atom data.

I was hoping to find a good mp4 atom parser for python. I haven't found much that works to get the information I need. I will probably have to pore over the standards to figure out all the structures.

if anyone is good with java they could use https://github.com/sannies/mp4parser which is what the isoviewer was made from. I haven't really coded much java though.

[BlueCop]

I tried to use mp4box to perform the decryption. I believe this is PIFF and CENC compatible file. It always seg faults when attempting to decrypt though.

http://gpac.wp.mines-telecom.fr/mp4b...on-encryption/

I wrote something to parse the file and decrypt the encrypted NALs. I couldn't get it to work properly though. I would just get a green screen with some corruption at the top on playback.

I discovered http://www.bok.net/trac/bento4/ after doing that. I attempted to use their mp4decrypt to decrypt. That file also didn't seem to work either.

I am not sure if the decryption is incorrect or the key is just wrong.

[BlueCop]

I am giving up on decrypting these other formats. I can't seem to get it working. I don't think the key is correct even though the Key IDs used are the same. I was looking at the source for mp4decrypt and it supports PIFF with AES CTR mode. So if we have the correct key then it should work to decrypt those files.

[ItsAngel]

Originally Posted by BlueCop

I am giving up on decrypting these other formats. I can't seem to get it working. I don't think the key is correct even though the Key IDs used are the same. I was looking at the source for mp4decrypt and it supports PIFF with AES CTR mode. So if we have the correct key then it should work to decrypt those files.

So you're trying to decrypt the apple.Streamkey files right?
I think we should try(as I've been unsuccessfully) to get HD in the playready method (the way that's easy to decrypt) like before. I'm not sure what netflix is doing to prevent us from getting the HD files but I'm determined to find a work around.

[BlueCop]

ItsAngel: yeap I believe they are moving all the clients to the new DASH format with Common Encryption because it supports multiply drm schemes. I know they at least support fairplay and playready concurrently using the same AES key for the same file. They have several DRM specific boxes in the mp4 that contain the needed data for the drm module to retrieve the key.

They could turn off HLS support completely. They already limit quality options. I think they only really support it still for ipad1.

[ItsAngel]

Originally Posted by BlueCop

ItsAngel: yeap I believe they are moving all the clients to the new DASH format with Common Encryption because it supports multiply drm schemes. I know they at least support fairplay and playready concurrently using the same AES key for the same file. They have several DRM specific boxes in the mp4 that contain the needed data for the drm module to retrieve the key.

They could turn off HLS support completely. They already limit quality options. I think they only really support it still for ipad1.

You sure they have the same .key files even tho they use different key delivery methods? If that's the case then the crypt0.key file from another file can ultimately decrypt an Apple.streamkey file? Hmm I'm going to test it out

[BlueCop]

They use the same Key ID. It is the key identifier and not the key. it identifies the key it was encrypted with.

The same content(movie or specific episode) was using the same keyID in the files. So that indicated they were encrypted with the same key. That is the whole point of what I have been attempting.

The decryption could be failing because I didn't implement the IV counter for AES_CTR correctly. They use a 64bit IV. It is expaned to 128bit by padding. I am not sure I did that right.

I thought maybe we could get the apple media play to play it correctly. The "#EXT-X-MAP:URI=" value needs to be changed to the name of the local video file UVD downloads. It is actually pointing to data embedded in the file.(length:2067 @ offset 0)

the "#EXT-X-KEY:METHOD=" value of ISO-23001-7 indicates a CENC(Common Encryption) for the video. I thought maybe we could bypass the key delivery by changing the URI to the local key file. I could never get it working. I am not sure if I should remove or change the value of the keyformat.

Originally Posted by krystallinity

#EXTM3U
#EXT-X-KEY:METHOD=ISO-23001-7,
URI="f10niQg0DsZqw5uIro8MDucooPo=",
KEYFORMAT="com.apple.streamingkeydelivery",
KEYFORMATVERSIONS="1"
#EXT-X-MAP:URI="http://23.246.6.145/?o=AQGST62xhTHsk1jsUJHdtSI4ryVV4kye3ZFYFbTgvJKrhw3 SkDEAulihIXOeFm662b7G4n4UiY0e4_ElClKi6g9te9cfl2m6k 2FKRT8dtMS5SlhYArKXZV4Z1BVEKWdaBRxgHbg&v=3&e=14100 65726&t=2-KEygddY3nVRFovfQcFObAptDg",
BYTERANGE="2067@0"

#EXT-X-KEY:METHOD=AES-128,URI="crypt0.key"

The files also have header values that indicate wedevine(google) drm support. I really think this format is going to be used in their future for a while.

Edit: I'm an idiot. I misread the Kids. It is actually incremented by 1. The decryption was simply failing because the key was wrong.
00000000-03C1-23FC-0000-000000000000
00000000-03C1-23FD-0000-000000000000