Blu-ray and AACS

[Janvitos]

Well, since i was interested in HD DVD , i am now interested in blueray.
I bought an 800$ (CAD) Blueray burner and bought the "Lord of War " movie and will be working on this (for a while i guess).
PowerDVD BD doesn't play the movie properly AT ALL (looks like when you have a defective pipeline in your video card).
WinDVD plays it just fine, and i'm about to go through the memory with WinHEX.

Here is what the directory structure looks like:

Volume in drive E is LOGICAL_VOLUME_ID
Volume Serial Number is 3C05-DB57

Directory of E:\

05/31/2006 05:21 AM <DIR> BDMV
05/31/2006 05:21 AM <DIR> AACS
05/31/2006 05:21 AM <DIR> CERTIFICATE
0 File(s) 0 bytes

Directory of E:\BDMV

05/31/2006 05:18 AM 180 index.bdmv
05/31/2006 05:18 AM 33,714 MovieObject.bdmv
05/31/2006 05:21 AM <DIR> PLAYLIST
05/31/2006 05:21 AM <DIR> CLIPINF
05/31/2006 05:21 AM <DIR> STREAM
05/31/2006 05:21 AM <DIR> AUXDATA
05/31/2006 05:21 AM <DIR> META
05/31/2006 05:21 AM <DIR> BDJO
05/31/2006 05:21 AM <DIR> JAR
05/31/2006 05:21 AM <DIR> BACKUP
2 File(s) 33,894 bytes

Directory of E:\BDMV\PLAYLIST

05/31/2006 05:18 AM 470 00000.mpls
05/31/2006 05:18 AM 234 00001.mpls
05/31/2006 05:18 AM 216 00002.mpls
05/31/2006 05:18 AM 232 00003.mpls
05/31/2006 05:18 AM 159,954 00004.mpls
05/31/2006 05:18 AM 168 00005.mpls
6 File(s) 161,274 bytes

Directory of E:\BDMV\CLIPINF

05/31/2006 05:18 AM 65,924 00000.clpi
05/31/2006 05:18 AM 292 00005.clpi
05/31/2006 05:18 AM 824 00001.clpi
05/31/2006 05:18 AM 2,016 00002.clpi
05/31/2006 05:18 AM 940 00003.clpi
05/31/2006 05:18 AM 612 00004.clpi
05/31/2006 05:18 AM 292 00006.clpi
05/31/2006 05:18 AM 396 00007.clpi
8 File(s) 71,296 bytes

Directory of E:\BDMV\STREAM

05/31/2006 05:17 AM 22,602,240,000 00000.m2ts
05/31/2006 05:18 AM 4,546,560 00005.m2ts
05/31/2006 05:17 AM 142,307,328 00001.m2ts
05/31/2006 05:17 AM 372,750,336 00002.m2ts
05/31/2006 05:18 AM 167,755,776 00003.m2ts
05/31/2006 05:18 AM 61,009,920 00004.m2ts
05/31/2006 05:18 AM 1,419,264 00006.m2ts
05/31/2006 05:18 AM 7,127,040 00007.m2ts
8 File(s) 23,359,156,224 bytes

Directory of E:\BDMV\BACKUP

05/31/2006 05:18 AM 180 index.bdmv
05/31/2006 05:18 AM 33,714 MovieObject.bdmv
05/31/2006 05:21 AM <DIR> PLAYLIST
05/31/2006 05:21 AM <DIR> CLIPINF
05/31/2006 05:21 AM <DIR> BDJO
2 File(s) 33,894 bytes

Directory of E:\BDMV\BACKUP\PLAYLIST

05/31/2006 05:18 AM 470 00000.mpls
05/31/2006 05:18 AM 234 00001.mpls
05/31/2006 05:18 AM 216 00002.mpls
05/31/2006 05:18 AM 232 00003.mpls
05/31/2006 05:18 AM 159,954 00004.mpls
05/31/2006 05:18 AM 168 00005.mpls
6 File(s) 161,274 bytes

Directory of E:\BDMV\BACKUP\CLIPINF

05/31/2006 05:18 AM 65,924 00000.clpi
05/31/2006 05:18 AM 292 00005.clpi
05/31/2006 05:18 AM 824 00001.clpi
05/31/2006 05:18 AM 2,016 00002.clpi
05/31/2006 05:18 AM 940 00003.clpi
05/31/2006 05:18 AM 612 00004.clpi
05/31/2006 05:18 AM 292 00006.clpi
05/31/2006 05:18 AM 396 00007.clpi
8 File(s) 71,296 bytes

Directory of E:\AACS

05/31/2006 05:18 AM 1,048,576 MKB_RO.inf
05/31/2006 05:18 AM 1,048,576 MKB_RW.inf
05/31/2006 05:18 AM 1,048,576 ContentRevocation.lst
05/31/2006 05:18 AM 65,536 Unit_Key_RO.inf
05/31/2006 05:18 AM 192 Content000.cer
05/31/2006 05:18 AM 2,048 CPSUnit00001.cci
05/31/2006 05:18 AM 1,571 mcmf.xml
05/31/2006 05:21 AM <DIR> DUPLICATE
05/31/2006 05:18 AM 950,552 ContentHash000.tbl
8 File(s) 4,165,627 bytes

Directory of E:\AACS\DUPLICATE

05/31/2006 05:18 AM 1,048,576 MKB_RO.inf
05/31/2006 05:18 AM 1,048,576 MKB_RW.inf
05/31/2006 05:18 AM 1,048,576 ContentRevocation.lst
05/31/2006 05:18 AM 65,536 Unit_Key_RO.inf
05/31/2006 05:18 AM 192 Content000.cer
05/31/2006 05:18 AM 2,048 CPSUnit00001.cci
05/31/2006 05:18 AM 1,571 mcmf.xml
05/31/2006 05:18 AM 950,552 ContentHash000.tbl
8 File(s) 4,165,627 bytes

Directory of E:\CERTIFICATE

05/31/2006 05:21 AM <DIR> BACKUP
0 File(s) 0 bytes

Total Files Listed:
56 File(s) 23,368,020,406 bytes
16 Dir(s) 0 bytes free

--------------------------------------------

I hope i have some other people to help out with this...
We need to kick DRM in the butt ! :)

[Eeknay]

It wouldn't be too hard to modify BackupHDDVD to recognize the BD file structure. Just change a few things here and there, I don't see why it wouldn't work.

[mrazzido]

hey guys my first post :-) , i have a bluray burner too the "lg gbw-h10n" i have the german version of "ICE AGE II" as a bluray movie. its same powerdvd does not work :-( on Analog Monitor , WINDVD works for me fine to!!

i uploaded the directory structe of the movie to an upload center
LINK (http://www.file-upload.net/download-180669/ice.txt.html) my movie has more files then Janvitos movie .


i search the memory dump for .bdmv i think die index.bdmv its the same as VPLST000.XPL i found the .bmdv many times in memory.

sorry for the bad English writing :-) cant write good English :D

when i can help any one to cracking BD i am here :-)

[noclip]

Your best bet looks like Unit_Key_RO.inf in the AACS directory.

[Janvitos]

My Unit_Key_RO.inf is almost empty (full of zeros). Theres a few ones at the begining, and then a few lines below theres a 16 byte string.

[mrazzido]

i check my Unit_Key_RO.inf of ice age II pal german , its the same many 00 then some bytes , and then many 00 :-D

[Janvitos]

I have uploaded a WinHEX memory dump of the playback of "Lord of War" Blueray movie for the ones interested.

Here is the link:

* deleted for scecurity reasons *

Enjoy !

[Janvitos]

Alright. Here's an update on the situation with blueray.

I've been reading the documents concerning AACS and the blueray format.
There are a lot of interesting things in there but it seems that we're gonna have a harder time with this than HD DVD.

First of all, it seems like the blueray format has a tendency to only use 1 key instead of many.
This might be a problem when trying to search the memory dumps since we are looking for a single 128 bit key rather than 8, 11 or even 60.
Just to let you know, the blueray format employs the term "CPS Unit Key" rather than "Title Key" but both are the same.
They also talk about Volume Unique Key which means they most likely also use it.

One of the other major drawback would be the lack of clues residing inside the CPS Unit Key File (Title Key File).
The Title Key File for the HD DVD format has plain text strings (such as VPLST000.XPL) but the CPS Unit Key File has none.
The file is mostly comprised of zeros and the encrypted key.

In the end of the line, we pretty much will have to follow a different path than we did with HD DVD.

Another important matter, and a question i will dare ask, are the keys for blueray in WinDVD's memory ?
Unfortunately i cannot check PowerDVD's memory because the program tells me my graphics driver is not HDCP compliant (although i can playback blueray movies through WinDVD just fine).
I also tried a most recent version of PowerDVD but this one doesn't seem to playback video properly as i get sound, but really ugly / scrambled-like video.

I will continue to work on this like i did with HD DVD.

[2bigkings]

@janvitos, what tft screen you have? but you can playback hd-dvd or?

good luck with blu-ray cracking ;-)

[Janvitos]

I have a 37" 1080p (DVI / VGA) screen.
It's currently plugged through VGA since the DVI port is not HDCP compliant.

[2bigkings]

oh so thats a tv and not only a tft pc screen..
i got a non-hdcp tft screen and it works fine (hddvd). What says the cyberlink bd/hd advisor to your pc system?

[Janvitos]

It says my graphics driver is not compatible.
I believe i have the most recent Catalyst driver (7.1) and the problem might be that the PowerDVD version that shipped with the blueray drive doesn't recognize the drivers.

[2bigkings]

i don't got a bd-drive, but i got the catalyst driver 7-1_xp_dd_40211 and powerdvd ultra and bd advisor says that everythings ok!
which blu-ray powerdvd version you have?

[Janvitos]

The LG version that came with the drive.
As i said above, the newer standalone version doesn't play the movie well at all.

[muslix64]

In less that 24 hours, without any Blu-Ray equipment, but with the help of Janvitos, I managed to decrypt and play a Blu-Ray media file using my known-plaintext attack...

The file from the movie "Lord of war", play well with VideoLan.

Janvitos gave me few files on the BD disc and a memory dump...

Note that I don't address BD+. The file don't seem to be BD+ protected.

I will keep you informed If I found anything new...

[muslix64]

You can have a look at that file at:

http://rapidshare.com/files/12497232/00007decrypted.m2ts.html

[Adub]

Yeah!!!!!
Way to roll, muslix64! Kick ass!!
can't wait till the drives drop down in price though.

[honai]

PWNZ0RZ!

The nice thing about Bu-ray is that DD+ tracks are coded differently than for HD-DVD, namely that they contain a DD-compatible core, i.e. ripped DD+ tracks from Blu-ray titles should play fine with conventional A/52 (a.k.a AC3) audio decoders.

[Galileo2000]

Amazing.

Muslix64 should be served and protected by the freedom-loving HDCP-hating people of the world!

[woah!]

BR is now doing there encodes with the VC-1 codec aswell like hd-dvd does. these are mpeg2 files i assume yes?

[Shinigami-Sama]

BR is now doing there encodes with the VC-1 codec aswell like hd-dvd does. these are mpeg2 files i assume yes?

no
VC-1 is a WMV-9 type file

[MidnightWatcher]

BR is now doing there encodes with the VC-1 codec aswell like hd-dvd does. these are mpeg2 files i assume yes?
Some are VC1, some are MPEG4, most are MPEG2.

[noclip]

DHCP-hating people of the world!

Why do you hate DHCP? It's what allows you to connect your home network to the internet!

[Galileo2000]

Why do you hate DHCP? It's what allows you to connect your home network to the internet!


LOL, got caught on my first post. Of course I meant HDCP, thanks for pointing it.

[mrazzido]

wow very great muslix64!!! :-) i have BD to when i can help you dont hesitate to contact me :-)

[arnezami]

I just love this part :D

I'm really enjoying this. Somehow it feels like victory...

[2bigkings]

file works fine (1920x1080) :)

[Devinator]

Some are VC1, some are MPEG4, most are MPEG2.

Most are still mpeg2? That is awfully depressing...


What will muslix64 accomplish next?

[xyz987]

In less that 24 hours, without any Blu-Ray equipment, but with the help of Janvitos, I managed to decrypt and play a Blu-Ray media file using my known-plaintext attack...


Congratulations for you and Janvitos :-)

And a lot of thanks :thanks:

[ape]

I managed to decrypt and play a Blu-Ray media file using my known-plaintext attack...

if you can give some details about the fingerprint bytes and their offset from the volume key i can edit my memory searcher app to dump the volume key for BD's from windvd as its playing. :)

[muslix64]

Many people ask me more details about the known-plaintext attack. This is a very basic, but powerfull crypto attack that I have used to decrypt both format.

After reading posts of people trying to get the keys in memory, I realized, I have a different way of looking into the problem.

A lot of people try to attack the software, I'm attacking the data!

So I spent more time analysing the data, to look for patterns or something special to mount my known-plaintext attack. Because I know the keys are unprotected in memory, I can skip all the painfull process of code reversal.

I don't have any Blu-Ray equipment but I was able to recover the keys anyways... because I had access to a memory dump file and a media file.


To give you an example, let's take the Blu-Ray case.

First, I had to read the documentation about the media file format.

In the case of Blu-Ray, the media files are divided in blocks called "Aligned unit". Let's simply call them "Unit" for short. A Unit is a block of 6144 bytes. The first 16 bytes are unencrypted, and the rest are encrypted using AES in CBC mode.

A unit is composed of 32 blocks called "MPEG source packet". Each packet is 192 bytes long. The first 16 bytes of the first MPEG source packet of a Unit are decrypted.

Just to see the decrypted part of the packet, I have printed a few. Have a look:

D13BF428474000100000B0110000C100
D13C5DE84710111C6E3468D1861B8D1A
D13CC7A84710111CE3468D1861B8D1A3
D13D31684710111C1A346186E3468D18
D13D9B284710111C6186E3468D1861B8
D13E04E84710111C8D1861B8D1A34618
D13E6EA84710111CD1861B8D1A346186
D13ED8684710111C186E3468D1861B8D
D14D57924710111CFCC810FE80107F08
D14DC1524710111C1007647E401C002E
D14E2B124710111C8001880350400300
D14E94D24710111C007690DE581426A3
D14EFE924710111C80800E8081F9E081
D14F68524710111CA01300C007408C00
D14FD2124710111C005200B002E00D49

Do you see something special? Do you see any pattern?

The first byte is always D1 and the 5th byte is always 47. Can we use that to mount the known-plaintext attack? Of course!

Because we know we have multiple MPEG source packet inside a Unit, we know the decrypted version of the unit at position 192 will probably look like the sequences shown above.

In most cases, the know-plaintext attack is in fact a guessed-plaintext attack. We "assume" the data will look like something we "guessed" when decrypted. Most of the time, it works!

Knowing that, all you have to do, is to write a small program that scan a memory dump file, that comes from of a software player while it was playing the movie. The key is in that file, you have to locate it.

You just have to decrypt the first 2 MPEG source packets of the first unit until, you find a key that decrypt to something like:

D1??????47?????????????????????? at position 192.

That's it!

I also do something similar for the HD-DVD format.

Once you know the value and the position of the key in memory, you can do like people are doing here. Use "memory landmark" to locate the key.

Any questions?

[tonyp12]

So if the memory dump is 2mb, you would try every 128bit section,stepping up one byte at at time
So you would only have to run the decrypt algorithm (up to) 2 million times.

To look for a pattern, did you use a non-decrypted source
or looked in mem dump for decrypted file?

[muslix64]

That is correct. But to speed things up, I discard keys that don't make sense. Like all zeros, for example.

For a pattern, I look in the decrypted portion (first 16 bytes of each unit) of the encrypted media file.

[noclip]

That is correct. But to speed things up, I discard keys that don't make sense. Like all zeros, for example.

For a pattern, I look in the decrypted portion (first 16 bytes of each unit) of the encrypted media file.

You can probably discard any potential key with any 0s at all. It's very unlikely they'd appear in a key.

[jkenzie]

By chance, is the 5th byte "0A" in Lord of War?

[muslix64]

No, it's 47. My example is "Lord of war". Sorry I did not mention it.
This is from the file 00007.m2ts, not the main movie.

[dito]

In less that 24 hours, without any Blu-Ray equipment, but with the help of Janvitos, I managed to decrypt and play a Blu-Ray media file using my known-plaintext attack...

The file from the movie "Lord of war", play well with VideoLan.

Janvitos gave me few files on the BD disc and a memory dump...

Note that I don't address BD+. The file don't seem to be BD+ protected.

I will keep you informed If I found anything new...

OT
Ops, I did it again...
I played with some files, decrypted them well... Ohh baby, baby...
/OT

I guess we'll be seeing BD+ soon enough, what's the information on this? Is it bit by bit protection or is it encryption based?

Great work BTW...

Best regards!

[noisehole]

hi muslix,

this example is blueray specific (.m2ts i assume), do evob's have a similar pattern (1st/5th byte)?

if i understood correctly, this attack is possible because the container ruins the whole encryption scheme. as written in the specs, some bytes at known positions (16bytes every 6144bytes) have to be written non-encrypted. how could they allow that potions of these plain values keep occurring at known positions (every 192bytes) in *encrypted* data?
while i consider the aacs system safe, who developed the evob/m2ts container?

damnit, which crypto expert did tell the studios that their data is safe with aacs? thats no reason to fire, thats a reason to get shot. well ok, ill take that back, happy we are where we are.

lets see how bd+ works out for them

regards

[muslix64]

This is blueray specific. It's different for EVOB. But it's the same concept. Guessing plaintext values...

Secure crypto is all about key protection. I cannot do this attack if the keys are protected in memory.

[dito]

hi muslix,

this example is blueray specific (.m2ts i assume), do evob's have a similar pattern (1st/5th byte)?

if i understood correctly, this attack is possible because the container ruins the whole encryption scheme. as written in the specs, some bytes at known positions (16bytes every 6144bytes) have to be written non-encrypted. how could they allow that potions of these plain values keep occurring at known positions (every 192bytes) in *encrypted* data?
while i consider the aacs system safe, who developed the evob/m2ts container?

damnit, which crypto expert did tell the studios that their data is safe with aacs? thats no reason to fire, thats a reason to get shot. well ok, ill take that back, happy we are where we are.

lets see how bd+ works out for them

regards

I think thier mistake is to allow software players... There are chips for HD format that has layers of hack protections inside thier CPU core (and handles the keys in the memory of the CPU, making hacks like the xbox hack very hard), using such chips would make HD-DVD and BluRay really safe...

[jokin]

You can probably discard any potential key with any 0s at all. It's very unlikely they'd appear in a key.

Looking at the current list of VUKs it appears a majority have one 0 in them. Bot none have 00.

[orbitlee]

192 bytes are TS packet. Normal TS packet has 188 bytes, with 47 as leading sync byte. m2ts adds 4 bytes timestamp before the sync byte. Actually 47 is always there(TS spec), but D1 is not guaranteed, since it is only timestamp, it could be any value, but timestamp won't change too quickly between adjacent TS packet, and D1 is MSB byte.

For EVOB, there is similiar pattern. 00 00 01 BA, then system clock reference , per 2048 bytes(program stream packet). For more details, read ISO13818-1.

PS: muslix64, thanks for your excellent job :-)

[tonyp12]

Looking at the current list of VUKs it appears a majority have one 0 in them. Bot none have 00.

I guess that what he mean is a byte.
And mostly always represented as two digits when displayed as hex

Hex is just a text string and it would be really hard to decode it to unicode (decimal)
if it was not even pairs unless you split each number with a ,
(A, 10, 4, F) = '0A10040F' and that would defeat the purpose as you could use dec is the first place.

decimal 0, hex 00 , Binary 00000000

[kad77]

This is blueray specific. It's different for EVOB. But it's the same concept. Guessing plaintext values...

Secure crypto is all about key protection. I cannot do this attack if the keys are protected in memory.

It is a dead certainty that any future revisions of software players (with new player keys) will have the disc AACS keys obfuscated to the extent where only top crackers (think scene release groups) will be able to wade their way through the spaghetti code.

Amateur slueths will be shut out of direct key retrieval soon (amateur programmers working on WinDVD let us in the door anyway).

[MrDVD]

Anyone know for what this AES keys in the PowerDVD BD Edition are ?
The are located @ .\PowerDVD\NavFilter\key\

[jokin]

Seeing as how alot of people own PS3 and you can run linux on a PS3. It should be possible to decrypt my blu-ray discs from the PS3 correct (with a java decryption program)? This would work out great.

[snurregrekk]

Seeing as how alot of people own PS3 and you can run linux on a PS3. It should be possible to decrypt my blu-ray discs from the PS3 correct (with a java decryption program)? This would work out great.



you're talking of some type of method like this, right? http://www.hdtvblogger.com/?p=39 (has yet to be confirmed though...)

[tonyp12]

It is a dead certainty that any future revisions of software players (with new player keys) will have the disc AACS keys obfuscated

The people at windvd did sure make a blunder.

If it wanted to keep the keys in memory, just a simple
left roll circular before saving it and a right roll circular when
it's back in the cpu registry would have stopped us to find it.

Now that we know a alot of keys, we would have to use a debugger in the next version of player that stops when a register have the known key (it most be in the register at least one time)

So we could apply a patch that write this register to some known space in memory.

[MrDVD]

I think the mainprob atm is UDF 2.5 for linux ? Is there an update out ?

[Lord_KiRon]

I think thier mistake is to allow software players... There are chips for HD format that has layers of hack protections inside thier CPU core (and handles the keys in the memory of the CPU, making hacks like the xbox hack very hard), using such chips would make HD-DVD and BluRay really safe...

I believe you are wrong here.
Almost any hardware player can be read out (including the RAM state) with chip relevant "debugger" tool (same as EPROM programmer but more advanced.
Of course this is not for amatures but still can be done.