Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Decrypting

Reply
 
Thread Tools Search this Thread Display Modes
Old 20th January 2007, 07:26   #21  |  Link
Shinigami-Sama
Solaris: burnt by the Sun
 
Shinigami-Sama's Avatar
 
Join Date: Oct 2004
Location: /etc/default/moo
Posts: 1,923
Quote:
Originally Posted by woah! View Post
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
__________________
Quote:
Originally Posted by benjust View Post
interlacing and telecining should have been but a memory long ago.. unfortunately still just another bizarre weapon in the industries war on image quality.
Shinigami-Sama is offline   Reply With Quote
Old 20th January 2007, 07:44   #22  |  Link
MidnightWatcher
Registered User
 
Join Date: Apr 2006
Posts: 9
Quote:
Originally Posted by woah! View Post
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.
MidnightWatcher is offline   Reply With Quote
Old 20th January 2007, 07:48   #23  |  Link
noclip
Registered User
 
Join Date: Dec 2006
Posts: 154
Quote:
Originally Posted by Galileo2000 View Post
DHCP-hating people of the world!
Why do you hate DHCP? It's what allows you to connect your home network to the internet!
noclip is offline   Reply With Quote
Old 20th January 2007, 08:01   #24  |  Link
Galileo2000
Registered User
 
Join Date: Jan 2007
Posts: 224
Quote:
Originally Posted by noclip View Post
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.
Galileo2000 is offline   Reply With Quote
Old 20th January 2007, 09:19   #25  |  Link
mrazzido
Registered User
 
mrazzido's Avatar
 
Join Date: Jan 2007
Posts: 114
wow very great muslix64!!! :-) i have BD to when i can help you dont hesitate to contact me :-)
mrazzido is offline   Reply With Quote
Old 20th January 2007, 10:39   #26  |  Link
arnezami
Registered User
 
Join Date: Sep 2006
Posts: 390
I just love this part

I'm really enjoying this. Somehow it feels like victory...
arnezami is offline   Reply With Quote
Old 20th January 2007, 10:44   #27  |  Link
2bigkings
Registered User
 
Join Date: Jan 2007
Posts: 117
file works fine (1920x1080)
2bigkings is offline   Reply With Quote
Old 20th January 2007, 10:46   #28  |  Link
Devinator
Registered User
 
Join Date: Aug 2003
Posts: 27
Quote:
Originally Posted by MidnightWatcher View Post
Some are VC1, some are MPEG4, most are MPEG2.
Most are still mpeg2? That is awfully depressing...


What will muslix64 accomplish next?
Devinator is offline   Reply With Quote
Old 20th January 2007, 11:53   #29  |  Link
xyz987
Registered User
 
Join Date: Dec 2006
Posts: 142
Quote:
Originally Posted by muslix64 View Post
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
xyz987 is offline   Reply With Quote
Old 20th January 2007, 11:55   #30  |  Link
ape
Registered User
 
Join Date: Sep 2004
Posts: 16
Quote:
Originally Posted by muslix64 View Post
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.
ape is offline   Reply With Quote
Old 20th January 2007, 16:43   #31  |  Link
muslix64
Registered User
 
Join Date: Dec 2006
Posts: 35
More about the "known-plaintext attack"

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?
muslix64 is offline   Reply With Quote
Old 20th January 2007, 17:02   #32  |  Link
tonyp12
Registered User
 
Join Date: Oct 2002
Location: Florida, USA
Posts: 90
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?

Last edited by tonyp12; 20th January 2007 at 17:06.
tonyp12 is offline   Reply With Quote
Old 20th January 2007, 17:06   #33  |  Link
muslix64
Registered User
 
Join Date: Dec 2006
Posts: 35
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.
muslix64 is offline   Reply With Quote
Old 20th January 2007, 17:20   #34  |  Link
noclip
Registered User
 
Join Date: Dec 2006
Posts: 154
Quote:
Originally Posted by muslix64 View Post
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.
noclip is offline   Reply With Quote
Old 20th January 2007, 17:35   #35  |  Link
jkenzie
Registered User
 
Join Date: Jan 2007
Posts: 40
By chance, is the 5th byte "0A" in Lord of War?
jkenzie is offline   Reply With Quote
Old 20th January 2007, 17:39   #36  |  Link
muslix64
Registered User
 
Join Date: Dec 2006
Posts: 35
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.

Last edited by muslix64; 20th January 2007 at 17:52.
muslix64 is offline   Reply With Quote
Old 20th January 2007, 17:43   #37  |  Link
dito
Registered User
 
Join Date: Jun 2005
Posts: 12
Quote:
Originally Posted by muslix64 View Post
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!
dito is offline   Reply With Quote
Old 20th January 2007, 17:45   #38  |  Link
noisehole
Registered User
 
Join Date: Feb 2004
Posts: 10
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
noisehole is offline   Reply With Quote
Old 20th January 2007, 17:54   #39  |  Link
muslix64
Registered User
 
Join Date: Dec 2006
Posts: 35
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.

Last edited by muslix64; 20th January 2007 at 18:00.
muslix64 is offline   Reply With Quote
Old 20th January 2007, 17:58   #40  |  Link
dito
Registered User
 
Join Date: Jun 2005
Posts: 12
Quote:
Originally Posted by noisehole View Post
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...
dito is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 13:33.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.