View Full Version : BackupHDDVD, a tool to decrypt AACS protected movies
noclip
17th January 2007, 22:44
There is still a long list of modifications that need to be made to the BackupHDDVD before multi-core support is anywhere near a top priority.
Proper handling of PCKs and ability to deal with IME are the major ones.
He-Man
17th January 2007, 23:06
If anyone is wondering how to run .jar extension files its really not hard. You just need to download the java binaries if your running windows. I downloaded Java Run Time for Windows Multilanguage (http://download.java.net/download/jdk6/6u1/promoted/b02/binaries/jdk-6u1-ea-bin-b02-windows-i586-p-12_jan_2007.exe)
Then you need to open the jar file in a Command Prompt and run using javaw -jar name_of_jar_file
Example
javaw -jar BackupHDDVD-GUI.jar
I just double-clicked on BackupHDDVD-GUI.jar and it opened like it was an .exe file. Doesn't this method work just as well as opening it from a command promt?
zeroprobe
17th January 2007, 23:19
someone help nightshd out with the encryped keys.
noclip
17th January 2007, 23:51
Meh, here's a logo:
http://img405.imageshack.us/img405/9972/bhdvdjs6.png
Small logo (for icon, etc.):
http://img444.imageshack.us/img444/3640/bhsmallbp5.png
hajj_3
18th January 2007, 00:12
nice logo:) hope its in the next version:)!
Mistar Muffin
18th January 2007, 00:15
Meh, here's a logo:
http://img405.imageshack.us/img405/9972/bhdvdjs6.png
Great logo, but a couple of things:
1) Trying to keep things legal, I don't think basing off the existing HD DVD logo is in fact legal. I do beileve there is some copyright on that since it is not parody etc.
2) It looks great, what font did you use to match the DVD font? I looked at one point for a font but could not find one.
Not trying to be a buzzkill, just thought I would mention that!
Bye.
Nutrition24
18th January 2007, 01:24
someone help nightshd out with the encryped keys.
I adapted BackupHDDVD-GUI to check the correctness of the Volume Unique Key using CMAC algorithm, but since I don't have a title key file myself, I'd also like to receive some sort of valid title key file to test the changes against.
(If anyone else want to try out ahead: it's at http://www.sendspace.com/file/slqvdw)
tonyp12
18th January 2007, 01:31
I but since I don't have a title key file myself, I'd also like to receive some sort of valid title key file to test the changes against.
a few in earlier post
http://forum.doom9.org/showpost.php?p=933495&postcount=638
noclip
18th January 2007, 01:45
I set up a project at Sourceforge for BackupHDDVD. I should know if it's approved by Friday.
Ábudos
18th January 2007, 04:55
Assuming my crypto translation is correct, I believe the following are the keys, but its quite possible I've not done the encryption correctly.
Encrypted Title Keys
01 = 80316BF135FFA74C08182D30D874BC6A
02 = DD2704D0783CECDFE14265B3B923AD33
03 = BF82FE9CB8BE988ABB6C3FBD0790C20A
04 = 02982C6AF396EA2F59B5A00BC80188A6
05 = 70992BB480F33349318AAEE5F091ABC6
06 = C793FAF1CE708DF61BE6D7D4B38B4D20
07 = D57516650AFDA7A17C24DD17BAE50DDB
08 = 6CA32B401277EE7E651DECBF72867A53
09 = EC1EAF02DE3E72C618462328853184BD
10 = 3EBAAB244BC47B43281BF27A04D88528
11 = 0BDB4CF03F89075EFCCC119583B1893A
Here's what I found:
01 = D32238519C4DA3BD395348B3E50B274E
02 = 92946B88A06967661B8491B18E488BF7
03 = 9810826ECB07414312CBA26245823942
04 = DD96EF42FF22B228EE9284DCB6180C43
05 = 2D81BC9FBB80FB5D25ED53616C9A0E79
06 = 9F269E568097C7CCD83BAD3511D82BA7
07 = 5E465FF6144864A0D23AE3CB776A15BC
08 = 8902AC657C91297DB03C21285FDD5B5D
09 = 7418D2A78417D093665321BED1790EF1
10 = 8DA3FBCC6E585DF13C28418EB2D10283
11 = FC087EBBC632EFBE4F48158009CF4E7D
@ 1-core it took a little bit over 2 hours to backup king kong from 1 hdd to another hdd.. anyone out there willing to do a multi-threaded backuphddvd? badly needed..
Multi-threading this app wouldn't do a whole lot to help. What's slowing it down is 1: the maximum bitrate of the USB connection / drive read speed, and 2: The fact that this is a Java program using its crappy crypto functions.
2bigkings
18th January 2007, 06:19
Here's what I found:
01 = D32238519C4DA3BD395348B3E50B274E
02 = 92946B88A06967661B8491B18E488BF7
03 = 9810826ECB07414312CBA26245823942
04 = DD96EF42FF22B228EE9284DCB6180C43
05 = 2D81BC9FBB80FB5D25ED53616C9A0E79
06 = 9F269E568097C7CCD83BAD3511D82BA7
07 = 5E465FF6144864A0D23AE3CB776A15BC
08 = 8902AC657C91297DB03C21285FDD5B5D
09 = 7418D2A78417D093665321BED1790EF1
10 = 8DA3FBCC6E585DF13C28418EB2D10283
11 = FC087EBBC632EFBE4F48158009CF4E7D
Multi-threading this app wouldn't do a whole lot to help. What's slowing it down is 1: the maximum bitrate of the USB connection / drive read speed, and 2: The fact that this a Java program using its crappy crypto functions.
You should decrypt the movie directly from the HDD, my quality of the movie is better now and it's faster!
jokin
18th January 2007, 06:29
I seem to have no trouble with speed. Mine takes ~1hr with a P4 3.4 2GB of RAM. I dont think thats too bad for 20+ GB
Janvitos
18th January 2007, 06:33
Just to let you people know, i've started working on Blueray keys and have created a new thread for those interested.
Yep, i bought a 800$ Blueray burner for the sake of the community :D
hajj_3
18th January 2007, 06:51
bloody hell Janvitos!!!
$800 is a hell of alot of money, which burner did you buy? you should have waited for the new combo writer from lg, it reads hd-dvd's and burns/reads blue-ray @ 4x i think.
let us know the progress with decrypting blu-ray.
woah!
18th January 2007, 08:26
You should decrypt the movie directly from the HDD, my quality of the movie is better now and it's faster!
that makes no sense what so ever.. how can the image be worse just because the ripping to HD from the disc is slower??? its data it doesnt change unless its told to like in transcoding eg: dvdshrink where it re-adjusts bitrate.
so your saying its quicker to copy the encrpyted files to the HDD which will take a while anyways for 18-20gig and then run it again from there to another HDD through backuphddvd and this will be quicker and give you better Q??
Nomadic
18th January 2007, 08:36
Who can share small hddvd iso working with BackupHDDVD for debug development??
firewan
18th January 2007, 09:06
Who can share small hddvd iso working with BackupHDDVD for debug development??
A small HDDVD iso with AACS? BackupHDDVD need a VTKF000.AACS file to work
blutach
18th January 2007, 09:28
Be careful please about sharing EVO files (or other copyrighted video files) or mentioning the sharing of them here.
We allowed publication of title keys on the basis that the people who could use them actually had the disks anyway. We do not make a presumption that someone has rented a disk and is using a published key.
Asking for the video content itself (or a part thereof) is entirely another matter - it needs little thought to figure out you don't have the DVD.
Sharing files are best done via PM and certainly not in open forum and we at Doom9 do not condone the sharing of files. Please refer to rule 6.
Regards
madshi
18th January 2007, 10:16
I don't have a HDCP compatible graphics card, so I'm thinking about using BackupHDDVD to be able to play my HD DVD discs. Now my question is:
Can I find out the keys of my own HD DVD discs by checking WinDVD memory without having a HDCP compatible graphics card? Or won't WinDVD have the keys in memory if I don't have a HDCP compatible graphics card?
Thanks!
Touffi
18th January 2007, 10:36
Hi everybody,
The following is based on what I read in the docs founds at : http://www.aacsla.com/specifications/
And specially this one :
http://www.aacsla.com/specifications/specs091/AACS_Spec_Prerecorded_0.91.pdf
I have a few questions about Sequences Keys, or Volume Unique Keys Variants (chapter 4). Well, first my english is not good enough for me to understand what exactly they are used for and how they work (first question) although I undestand that it's a revocation-scheme protection mecanism similar to the MKB.
Second question, BackupHDDVD seems to work with Volume Unique Keys only, so what are the Variants used for ? Section 3.5 states that Title Key is computed with this formula : Kt = AES-128D(Ku, Kte). Kte being the encrypted Title Key and Ku "one of the volume unique keys defined in Section 3.3". Section 3.3 explains how to compute Volume Unique Keys (Kvu) and Volume Unique Keys Variants (Kvvu). So that would mean that we can feed BackupHDDVD either with a Kvu or au Kvvu and that you only need one of them to decrypt Title Keys ?
Well, I'm confused :)
Nomadic
18th January 2007, 11:56
New version BackupHDDVD-GUI (http://rapidshare.com/files/12229227/BackupHDDVD-GUI.zip)
changes:
- Decrypting file in separate thread (as yet one!)
- Progress bar while decrypting
- Minor fixes
hajj_3
18th January 2007, 12:04
nomadic, what does this mean??
" Decrypting file in separate thread (as yet one!)"
thanks.
Nomadic
18th January 2007, 12:07
that not to freeze an interface in the process of decoding
jokin
18th January 2007, 12:11
Sendspace Mirror for updated GUI (http://www.sendspace.com/file/045l4k)
Also,
1. Maybe you can have it list files and allow one to select certain files to decrypt. (File mode and a disc mode)
2. Make a button to stop or pause decryption?
Thanks for the great work.
Obveron
18th January 2007, 13:55
I don't have a HDCP compatible graphics card, so I'm thinking about using BackupHDDVD to be able to play my HD DVD discs. Now my question is:
Can I find out the keys of my own HD DVD discs by checking WinDVD memory without having a HDCP compatible graphics card? Or won't WinDVD have the keys in memory if I don't have a HDCP compatible graphics card?
Thanks!I would also like to know the answer to this question.
From the following post from Muslix64, it seems that he was able to retrieve keys without a HDCP capable video card... But I can't be sure. But when I realized the 2 software players on windows don't allowed me to play the movie at all, because my video card is not HDCP compliant and because I have a HD monitor plugged with DVI interface, I started to get mad... This is not what we can call "fair use"! So I decide to decrypt that movie.
He-Man
18th January 2007, 14:05
Second question, BackupHDDVD seems to work with Volume Unique Keys only, so what are the Variants used for ? Section 3.5 states that Title Key is computed with this formula : Kt = AES-128D(Ku, Kte). Kte being the encrypted Title Key and Ku "one of the volume unique keys defined in Section 3.3". Section 3.3 explains how to compute Volume Unique Keys (Kvu) and Volume Unique Keys Variants (Kvvu). So that would mean that we can feed BackupHDDVD either with a Kvu or au Kvvu and that you only need one of them to decrypt Title Keys ?
Well, I'm confused :)
Here's an article discussing Volume Variant Unique Keys, maybe this will be to some help?
AACS: Sequence Keys and Tracing: http://www.freedom-to-tinker.com/?p=1110
Touffi
18th January 2007, 14:30
Here's an article discussing Volume Variant Unique Keys, maybe this will be to some help?
AACS: Sequence Keys and Tracing: http://www.freedom-to-tinker.com/?p=1110
Great reading :thanks:
I went to this site yesterday while googling but this post hadn't been published yet ;)
The_ByteMaster
18th January 2007, 16:54
Here's an article discussing Volume Variant Unique Keys, maybe this will be to some help?
AACS: Sequence Keys and Tracing: http://www.freedom-to-tinker.com/?p=1110
From the article:
"The effect of this is that the movie will look slightly different, depending on which player was used to decrypt it."
So depending on your player, Han will shoot first, or not?
I'm only kidding of course, it stands to reason the differences wouldn't be noticable to the human eye. This will just result in a cat-and-mouse game between Fair Use people who compromise players (nab required decryption keys from memory) and the content providers. It doesn't really matter if you only get updates say a couple of times per year, as long as those updates work with all currently available discs.
Once a future version of BackupHDDVD encounters a P-EVOB which needs SKB processing it perhaps will just consult the file SKBDB.cfg to get the required keys.
For now the BackupHDDVD modders can just check for the presence of AACS/SKB.AACS and AACS/SKF.AACS: "no SKBF and no SKF shall be present on a HD DVD-Video ROM medium which contains no P-EVOB with Sequence Key Sections."
jokin
18th January 2007, 16:55
With the newest version of the GUI I get this error on 4 discs.
Could not find keyFile "O:\aacs\VTKF.AACS". Aborting...
NghtShd
18th January 2007, 17:18
Here's what I found:
01 = D32238519C4DA3BD395348B3E50B274E
02 = 92946B88A06967661B8491B18E488BF7
03 = 9810826ECB07414312CBA26245823942
04 = DD96EF42FF22B228EE9284DCB6180C43
05 = 2D81BC9FBB80FB5D25ED53616C9A0E79
06 = 9F269E568097C7CCD83BAD3511D82BA7
07 = 5E465FF6144864A0D23AE3CB776A15BC
08 = 8902AC657C91297DB03C21285FDD5B5D
09 = 7418D2A78417D093665321BED1790EF1
10 = 8DA3FBCC6E585DF13C28418EB2D10283
11 = FC087EBBC632EFBE4F48158009CF4E7D
Thanks very much, Ábudos. Setting up the decryption in C# is a bit different than in Java.
Update:
Somehow I had put the wrong volume key in my test CFG file. Everything looks good now that I fixed that. Thanks again for your help.
muslix64
18th January 2007, 18:41
By now, some people may wonder "Why did he put a date field in the keydb.cfg?"
Even if this field seems useless for now, it will be very usefull in the future. When revocation and, may be other countermesures will kick in, it will be usefull.
Movies manufatured in a certain time frame may have special features, we never know...
So I strongly suggest you to use the date field now to prepare for the future...
evdberg
18th January 2007, 18:44
Hi Musli-X64 ... I wonder more why you write 0x7F to the MSB of VOBU_EndAddress? This value is correct in the original files, so why change it? I know you did some experimenting and it *seemed* to fix the 'nav chain problem', as you call it, but it also may cause new problems (see reported problems on this forum).
muslix64
18th January 2007, 18:50
You are right. Try to play a evo file with PowerDVD without that fix. It do a lot of frame skipping. This is a PowerDVD problem, so this fix is just a workaround a player problem.
Coderjoe
18th January 2007, 18:53
By now, some people may wonder "Why did he put a date field in the keydb.cfg?"
Even if this field seems useless for now, it will be very usefull in the future. When revocation and, may be other countermesures will kick in, it will be usefull.
I don't really think revocation matters. Kvu and Kt are both after the revocation steps (from the version of the specs I have read, anyway). The only place the revocation currently matters is in WinDVD or PowerDVD, where everyone is currently snatching the keys from.
muslix64
18th January 2007, 18:57
But, may be other countermesures we don't even think of, will kick in sooner or later. It's always usefull to know the manufaturing date of a movie.
evdberg
18th January 2007, 19:17
This is a PowerDVD problem, so this fix is just a workaround a player problem.
I assume you mean it is a specific problem of PowerDVD 6.5? Did you also try V7.2? Or do you have the same problem as I do that V7.2 is bitching that your system is not qualified to play HD-DVD?
hajj_3
18th January 2007, 19:22
muslix64, what do you think about the GUI version of 1.00. any ideas how the IME can be fixed?? you havent posted in a few days, there has been alot of development since then.
muslix64
18th January 2007, 20:40
@evdberg
Yes it's a bug with 6.5. I don't have V7.2. may be it work well with 7.2
@hajj_3
I did not try the GUI version yet. I'm not working on IME bug. I think you have to remove some sub streams in the stream, but I leave that to demuxing experts. I'm more into crypto than media format stuff.
This is a player bug, not a BackupHDDVD bug. The decryption works fine.
Did someone was able to play a movie with IME so far?
noclip
18th January 2007, 20:42
Muslix: Do you have a SourceForge account? PM me your username and I will add you as a developer.
muslix64
18th January 2007, 20:47
Thanks noclip. But I leave that to serious coders. I'm good at proof of concept software, not production grade software.
Coderjoe
18th January 2007, 21:37
noclip: developer on what project?
btw, I am getting more and more tempted to get a drive and a movie or two and start poking around...
He-Man
18th January 2007, 21:47
noclip: developer on what project?
BackupHDDVD on SourceForge http://forum.doom9.org/showthread.php?t=120896
DanITman
19th January 2007, 04:05
I have an HD-DVD that I cannot find the VK for. I'm starting to think it doesn't even have one or the disc might not be encrypted.
Here is the disc: Musicares person of the year tribute honoring James Taylor
http://www.buy.com/retail/product.asp?sku=203172501&loc=107&sp=1&queryType=video_vhs&
I'm more interested in hunting down keys then I am actually backing this thing up. I'm just practicing finding keys and this is the only one that has stumped me. Could it be possible that it doesn't have a VK? Would anyone be willing to take a look at the dumped memory and give me a hint to it's location?
Thanks
jokin
19th January 2007, 04:44
I have an HD-DVD that I cannot find the VK for. I'm starting to think it doesn't even have one or the disc might not be encrypted.
Here is the disc: Musicares person of the year tribute honoring James Taylor
http://www.buy.com/retail/product.asp?sku=203172501&loc=107&sp=1&queryType=video_vhs&
I'm more interested in hunting down keys then I am actually backing this thing up. I'm just practicing finding keys and this is the only one that has stumped me. Could it be possible that it doesn't have a VK? Would anyone be willing to take a look at the dumped memory and give me a hint to it's location?
Thanks
Try just dragging an EVO to the desktop and playing it.
NghtShd
19th January 2007, 07:27
Please read the following before downloading.
HDDVDBackupG is C# port of HDDVDBackup with a GUI interface.
I'm pretty sure title key decription works properly. It may not work on EVO files however. Since I don't have encrytped EVO files and a corresponding VTKF000.AACS to test with I couldn't do much more than guess at the crypto setup. If you feel it would be a waste of your time if the app fails to decrypt your files then don't bother.
The C# source code will be released, but I'd like to get some feedback regarding EVO decription while I do some code clean up and maybe add a bit more error control. I'll also look at more informative output a progress bar and multithreading if I have time.
http://users.adelphia.net/~m.crane/bin/HDDVDBackup.rar
Below is the main decryption setup. If any crytpo people see any obvious errors please let me know.
class AESFunc
{
static byte[] AESCBCConstantIV = { 0x0B, 0xA0, 0xF8, 0xDD, 0xFE, 0xA6, 0x1F, 0xB3, 0xD8, 0xDF, 0x9F, 0x56, 0x6A, 0x05, 0x0F, 0x78 };
public static byte[] AESG(byte[] x1, byte[] x2)
{
RijndaelManaged AES = new RijndaelManaged();
AES.Mode = CipherMode.ECB;
AES.Padding = PaddingMode.None;
AES.KeySize = 128;
//AES.BlockSize = 128;
ICryptoTransform decryptor = AES.CreateDecryptor(x1, x1);
MemoryStream memoryStream = new MemoryStream(x2);
CryptoStream cryptoStream = new CryptoStream(memoryStream, decryptor, CryptoStreamMode.Read);
byte[] plainTextBytes = new byte[x2.Length];
// Start decrypting.
int decryptedByteCount = cryptoStream.Read(plainTextBytes, 0, plainTextBytes.Length);
return Utils.xor(plainTextBytes, x2);
}
public static byte[] decryptPack(byte[] pack, byte[] contentKey)
{
RijndaelManaged AES = new RijndaelManaged();
AES.Mode = CipherMode.CBC;
AES.Padding = PaddingMode.None;
AES.KeySize = 128;
//AES.BlockSize = 128;
ICryptoTransform decryptor = AES.CreateDecryptor(contentKey, AESCBCConstantIV);
MemoryStream memoryStream = new MemoryStream(pack);
CryptoStream cryptoStream = new CryptoStream(memoryStream, decryptor, CryptoStreamMode.Read);
byte[] plainTextBytes = new byte[pack.Length];
// Start decrypting.
int decryptedByteCount = cryptoStream.Read(pack, 0, plainTextBytes.Length);
return pack;
}
}
arnezami
19th January 2007, 11:18
I adapted BackupHDDVD-GUI to check the correctness of the Volume Unique Key using CMAC algorithm, but since I don't have a title key file myself, I'd also like to receive some sort of valid title key file to test the changes against.
(If anyone else want to try out ahead: it's at http://www.sendspace.com/file/slqvdw)
This is a great feature. Has this been tested yet by anyone? Maybe change a key slightly and see if it is detected?
New version BackupHDDVD-GUI (http://rapidshare.com/files/12229227/BackupHDDVD-GUI.zip)
changes:
- Decrypting file in separate thread (as yet one!)
- Progress bar while decrypting
- Minor fixes
Looking at your source Nutrition24's cmac check still has to be added to your program. Am I right? Or is it already in the exe?
hajj_3
19th January 2007, 13:52
its prob best to use the c#.net version when thats fully working instead of just a .exe, this way you can have access to the keys.cfg file. we could create an installer for it to install it to $:\Programs Files\BackupHDDVDgui.
melakai
19th January 2007, 15:43
The C# source code will be released, but I'd like to get some feedback regarding EVO decription while I do some code clean up and maybe add a bit more error control. I'll also look at more informative output a progress bar and multithreading if I have time.
Don't worry about trying to stuff all these features in right away. It might be better to get the source out so others can help rapidly develop that don't do Java.
I don't have my HDDVD drive hooked up at home to test, but I'll give it a shot tonight if no one beats me to the punch.
kad77
19th January 2007, 15:49
I want to clear a few things up about BackupHDDVD performance for the non-technical:
1. Software can be structured to be multi-threaded (not 'multi-core'), which would utilize multiple processors and/or cores.
2. An interpreted language algorithm (ie Java byte code running in a Virtual Machine, or C# in the CLR) is always going to be slower than a native machine code algorithm. Non-threaded native C/C++ code will probably still outperform multi-threaded Java, btw.
3. If you are really impatient, you can try compiling muslix64's source in the GNU Java compiler to get a native binary executable. You might see some performance gains, but you probably will learn something.
4. Most importantly: as others have stated, the encrypted AACS data streams still need to be handled properly! Guesswork hacks remain in muslix64's code that don't follow AACS spec... When these unknowns are addressed, then you'll see worthwhile optimized versions. In the meantime, you are likely archiving 'corrupt' backups that will need to be redumped in the future.
I've partially written a platform independent C translation, and I'm sure others will rewrite the utility in a similar high-performance language (probably C++, with assembly sub-sections) that can be compiled to a specific processor-- C/C++ code will run significantly faster than the Java reference code currently floating around. C# may provide some marginal improvement, but it is still managed code and is not as portable as Java, C, or C++.
Remember, this entire process is still in the testing/development stage. BackupHDDVD is not a production utility ready for prime time quite yet. GUI development is a nice coat of paint, but the core algorithm needs to be fixed first!
Thanks for firing the first shot muslix!
noclip
19th January 2007, 15:53
Can you use XML-based key storage in future versions?
Example format:
<?xml?>
<keyset>
<description>Movie name</description>
<cmac>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</cmac>
<key type="volume">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</key>
<key type="title">
<title id="3">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</title>
<title id="10">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</title>
</key>
</keyset>
<keyset>
<description>A different movie name</description>
<cmac>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</cmac>
<key type="volume">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</key>
</keyset>
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.