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. |
20th January 2007, 16:43 | #31 | Link |
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? |
20th January 2007, 17:02 | #32 | Link |
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. |
20th January 2007, 17:43 | #37 | Link | |
Registered User
Join Date: Jun 2005
Posts: 12
|
Quote:
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! |
|
20th January 2007, 17:45 | #38 | Link |
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 |
20th January 2007, 17:54 | #39 | Link |
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. |
20th January 2007, 17:58 | #40 | Link | |
Registered User
Join Date: Jun 2005
Posts: 12
|
Quote:
|
|
Thread Tools | Search this Thread |
Display Modes | |
|
|