HD DVD aca file extracter (and backuphddvd C++)

[Oleg_Jdev]

ACA decrypter v0.3.1 (http://www.sendspace.com/file/co9opl)
Quick changelog:
ACA decrypter v0.3.1
- Addition of xts, xas, xss, evo, map, mng, cvi, cdw, otf and ttc MIME-types (thanks evdberg)
2 Zotty:
Can you upload source here.

[MrDVD]

It appears to run under wine on Linux too. Thanks, Zotty! This is a good step toward cross-platform solutions--no C# or .NET needed! Your release notes say you usually run Linux. Have you found a Linux UDF 2.5 driver that you like yet?

You have to patch your kernel sources and recompile it.
I found this patch here @ the forum but didnt test it.
http://sourceforge.net/tracker/?group_id=295&atid=300295

[tonyp12]

I have updated TitleSorter to use the new Key type name:
<Key type="Hash"></Key>

[calinb]

You have to patch your kernel sources and recompile it.(UDF-2.5 Linux support) Thanks! I'll try to find time to recompile. Looks like the patch is for 2.6.16 kernels and I'm mostly running 2.6.18 or 19 on my machines, but maybe it won't be too hard.

@Zotty, Your code, running under Wine on my Gentoo server with an 8-drive RAID-5 set, is by far the fastest solution and, once you get the stability resolved, it will be the best Linux solution. For fun, I managed to recompile your C++ with winelib to obtain a native binary. I have never compiled anything with winelib before and, after all the work, I was disappointed to learn the winelib binary still requires the wine runtime program--just like a Windows binary. :( Oh well, I learned something, regardless.

[Zotty]

2 Zotty:
Can you upload source here.
Once it's compiling again I will. The backuphddvd code is currently broken. Won't make it tonight anymore unfortunately.

I have updated TitleSorter to use the new Key type name:
<Key type="Hash"></Key>
Great! I've got this working aswell now. It checks both and if the CMAC (type TFKMAC = CMAC now) or hash is present it finds the volume key.

@Zotty, Your code, running under Wine on my Gentoo server with an 8-drive RAID-5 set, is by far the fastest solution and, once you get the stability resolved, it will be the best Linux solution. For fun, I managed to recompile your C++ with winelib to obtain a native binary. I have never compiled anything with winelib before and, after all the work, I was disappointed to learn the winelib binary still requires the wine runtime program--just like a Windows binary. :( Oh well, I learned something, regardless.
The good news is I've got the decrypter running naticely under Debian. It doesn't work yet, but it's getting there. So if all goes well, there's no need for Wine :)

edit:
Sweet, the decrypter is running under Linux now :D Only annoying thing is case-sensitivity (how is this stored on HD DVD, in capitals or not? (specs say capitals)) and permissions. Still gotta work on backuphddvd, but this is very nice. And it seem to be faster than under Windows hehe

[Emon]

Zotty .. so in my laptop when I used aca_decrypter to fix Serenity's menu it worked fine. But in my desktop (running Windows XP MCE) it crashes all the time when it tries to decrypt the "controller.js" file.

[Zotty]

Zotty .. so in my laptop when I used aca_decrypter to fix Serenity's menu it worked fine. But in my desktop (running Windows XP MCE) it crashes all the time when it tries to decrypt the "controller.js" file.
I'll have access to a MCE system tomorrow, maybe that'll clearify something. For the rest I'm stumped what it could be :(

[Zotty]

Another update! 3 tools this time, all 3 updated and all 3 running under Windows and Linux.

The first is offcourse the ACA decrypter. Uses new XML keydb where hash and cmac are seperated. But most importantly is the addition of a log file. When the tool runs, it creates a file called aca_decrypter.log. The log can be pretty large, but it's another attempt at tracking down potential problems.
Once again the whole thing runs stable over here, under Windows AND Linux. But I've learned that's not the case for everyone. Frankly, I'm at a loss here and if the existing problems still exist, help would be appreciated. Use the log when reporting problems and mention the movie and OS you're using.

BackupHDVD's code has been checked a bit for problems and parts have been rewritten (e.g. the part that passes files to the decryption code). Hopefully this fixes the 0kb problem, although I can't test with large files. Tried multiple 60+MB files (don't have any bigger) and all decrypt and work.

Last thing is the cfg2xml tool. It's simple thing that does nothing more than convert an existing keydb.cfg to keydb.xml. Do what you want with it, just know there will be no support and should be considered an extra.

Also included is a ready to use keydb with the 102 keys that Janvitos has been collecting.


Changelog
^^^^^^^^^
ACA decrypter v0.4
- Runs under Windows and Linux
- Added log output (aca_decrypter.log)
- Uses XML keydb

BackupHDDVD v0.2
- Runs under Windows and Linux
- Fixed potential problems with large EVOB's
- Uses XML keydb

cfg2xml v0.1
- Initial release (Windows and Linux)


hddvd_cpp_20070129_bin.rar (http://www.sendspace.com/file/0lb0k4)
hddvd_cpp_20070129_src.rar (http://www.sendspace.com/file/7lhkxh)

[Emon]

Yey !! will test it tonight .. and I guess I have to fix my app also and wrap the args with "s.

[Galileo2000]

Thanks Zotty, testing it inside Emon version 0.5 right now, will report soon.

[Oleg_Jdev]

Thanks Zotty, we will use your engine in our next versions.

[calinb]

Another update! 3 tools this time, all 3 updated and all 3 running under Windows and Linux.Thanks, Zotty. BackupHDDVD C++ runs under Linux, but it's skipping all large EVO files completely (not even zero size output). Haven't tried Windows yet.

[Zotty]

Thanks, Zotty. BackupHDDVD C++ runs under Linux, but it's skipping all large EVO files completely (not even zero size output). Haven't tried Windows yet.
Are by any change the files that do work smaller then 4,2 GB and the files don't 4,2+ GB? I've got a feeling the traditional mistake of thinking 32-bits should be enough is coming to hit me in the face like a truck with busted brakes riding downhill....

[Rectal Prolapse]

Zotty, can aca extractor be used to extract ACA files that have been backed up to the hard drive already by backhddvd? Or will I have to mount the original disk directly into the HD-DVD drive and point ACA Extractor to it?

Thanks!

[calinb]

Are by any change the files that do work smaller then 4,2 GB and the files don't 4,2+ GB? Yes--this seems to be true.

[-tK-]

Zotty, can aca extractor be used to extract ACA files that have been backed up to the hard drive already by backhddvd? Or will I have to mount the original disk directly into the HD-DVD drive and point ACA Extractor to it?

Thanks!

If you select a directory with the allready ripped HD-DVD files, aca extractor says the vtkf000.aacs file is missing.

So I created an empty vtkf000.aacs and run aca extractor again. This time it said No volume key found... aborting

So next i've added the Title key of the empty vtkf000.aacs to keydb.xml (TKFMAC) so it would atleast find the correct volume key for this movie.

When i tried it again it seem to work, but with every file it threw an error that Key 11 was not found.

Not sure what to do next, so i gave up :p

Hopefully Zotty could tell us if it's possible:)

[Zotty]

Yes it runs from HD. It just needs to proper source and destination paths and it doesn't matter if's the actual disc or a directory on you HD. It needs these 2: ADV_OBJ (the aca files) and AACS (the titlekey file). From those it needs the .aca files and the VTKF000.AACS file.

Encrypted data in the aca files have a title key pointer; as the name suggest it points to a title key. And this key is found in the title key file (TKF) which is located in the AACS directory. When creating an empty TKF it finds the file, but it points to nonsense and thus the key cannot be found. Hence the "Key 11 not found".

So the directory structure can be 'faked', but the TKF needs to be real.

[Metro]

I can also confirm that BackupHDDVD C++ produces 0-byte files if the input file is >4,2GB. I used it to rip "The Fugitive" today and the two feature files both ended up as zero size. Everything else was fine and planting versions of those two files ripped with the original Java app into the directory with your prog doing everything else worked perfectly.

[calinb]

I can also confirm that BackupHDDVD C++ produces 0-byte files if the input file is >4,2GB.With Linux, it just totally skips the large files.

[He-Man]

I can also confirm that BackupHDDVD C++ produces 0-byte files if the input file is >4,2GB. I used it to rip "The Fugitive" today and the two feature files both ended up as zero size. Everything else was fine and planting versions of those two files ripped with the original Java app into the directory with your prog doing everything else worked perfectly.
Also make sure not to use a FAT32 formatted hard drive but an NTFS formatted drive. FAT32 does not support file sizes above 4 GB, while NTFS supports much larger file sizes.
I don't know if there's any Linux filesystems with the 32 bit adressing limitation that the outdated FAT32 has. But for Windows use NTFS instead of FAT32.

Btw. why do you all say 4.2 GB? It seems like you use 1000 instead of 1024, but why? Windows explorer and just about everything else on PC's definesw "GB" as "bytes / 1024^3"
HDD manufactures are the exception using 1000 bytes per kB instead of 1024 like the rest of the digital world.

2^32 = 4,294,967,296 bytes

2^32 / 1024^3 = 4.00 GB (some prefer 4.00 GiB (giga binary byte) to aviod confusion, but GB is commonly used too even when 1024 is used instead of 1000).

[Metro]

Also make sure not to use a FAT32 formatted hard drive ....
Btw. why do you all say 4.2 GB?


Yes, it was NTFS (or I wouldn't have been able to copy the Java-decrypted files there :p ) - but a good point for those who might not know about this limitation.

Zotty mentioned 4.2 GB as being the potential sticking point as he'd used a 32-bit variable to store the value, and that's going to be 4,294,967,296 bytes as you rightly point out. I didn't test exactly where it falls over because all I have are the files on the original disc, but whichever way you calculate it the files less than 4.2 all worked and the files (significantly) greater than 4.2 didn't.

[Oleg_Jdev]

2 Zotty:
(about aca_decrypter)
How about set the path to keydb.xml file in the command line arguments ?

Like: aca_decrypter.exe "E:\" "D:\" "D:\keydb.xml"
??

[Poodle13]

I usually rip the movie to a dir, and then subst the dir in cmd, like subst l: d:\LAND_OF_THE_DEAD

Now i run "aca_decrypter.exe l: c:\menus.aca" to save the extracted files to c:\menus.aca

I've found that powerDVD likes playing the files better if I just erase the decrypted menus.aca file in the ADV_OBJ directory and instead make a menus.aca directory containing the unpacked files in the ADV_OBJ directory.

Now i trim off the top header and the last cryptic characters of the VPLST000.XPL file. Also remember to rename or remove the aacs and aacs-backup directories to avoid the player to crash. All files not being encrypted evo-files are copied from the original hd-dvd to the HVDVD_TS directory on the harddisk.


Now just pull the subst drive (in my case l: ) from explorer into the powerDVD window and you should get up the movie and a pseudo-working menu. Hit return and the main feature starts running, with options to choose subtitles and sound track.

Done this with several universal titles like serenity and land of the dead

[Galileo2000]

Oleg, I got my HD DVDs now.

What would you like me to test?

[Oleg_Jdev]

Oleg, I got my HD DVDs now.

What would you like me to test?
If it possible, please test last version:
http://sourceforge.net/project/showfiles.php?group_id=187320

Comments can be sent here:
http://forum.doom9.org/showthread.php?t=121092

[Pelican9]

Edit: Sorry for my post.

[Galileo2000]

Not sure mods will be happy with your post BTW.

[evdberg]

Could anybody send to me the decrypted menus.aca of Serenity?

The most logical thing is to decrypt them directly from your original ... which ofcourse you do not own, otherwise you would not have posted the question in the first place.

[blutach]

OFF:

Could anybody send to me the decrypted menus.aca of Serenity?
Thanks in advance.evdberg is 100% right and Galileo2000's suspicions are confirmed. Your post is against forum rules and our policy on requests.

Strike issued.

Regards

[Nimue]

So I just compiled this and I'm curious as to what exactly I do. You see I'm getting a 60gb PS3 shortly and I plan to slap Gentoo on it. But until then, I'd like to understand exactly what to do to actually get this happy.

nimue@localhost ~/sandbox/bluray-hddvd/hddvd_cpp $ ls
aacs aca_decrypter.log cfg2xml encryption makefile utils
aca_decrypter backuphddvd changelog.txt keydb.xml readme.txt

I've got these files (by the way, I had to get the keydb.xml file from the binaries rar - it was not in the source).

Now what does aca_decrypter do? What is it used for? I know the syntax, but... What does it do?

Just read the manual - but I still don't understand it so much. Does it slap out a file? And how do you use it to get the menus?

Similarly, what does cfg2xml do? By the look of it, it converts older versions .cfg files to the newer xml syntax. But I could be wrong.

Hah. Read the manual - I was right.

And the backuphddvd, I believe I do understand. I believe that takes the silly blu-ray/hddvd thingers and slaps out .evo files.

Anyway are there utilities for obtaining these keys in this little toolbox? You see I own Air on blu-ray. The wonderful three disk box set of my favorite anime series. And I don't want to watch the ruddy thing down-scaled.

http://ec2.images-amazon.com/images/P/B000H3075S.01._SS500_SCLZZZZZZZ_.jpg

But it's not in the keydb.xml file. So how would I go about obtaining it?

[lovekudu]

I've compiled a simple guide to HD-DVD playing under Linux (including using BackupHDDVD C++ to decrypt the content before mplayer plays it) at:
http://help.ubuntu.com/community/RestrictedFormats/BluRayAndHDDVD

Note that the following issues are yet to be resolved:
* BackupHDDVD C++ should write to a fifo, allowing mplayer to play it while its decrypting, as with an AACS_LA licensed player.
* The 4GB problem still exists - this is more than a simple typing issue, as it seems the current program tried to load the entire file into memory. A competant C++ programmer should be able to fix this, but I'm not a competant C++ programmer.
* mplayer still lacks support for one of the audio formats used in some films.

[awhitehead]

I've compiled a simple guide to HD-DVD playing under Linux (including using BackupHDDVD C++ to decrypt the content before mplayer plays it) at:
http://help.ubuntu.com/community/RestrictedFormats/BluRayAndHDDVD

Note that the following issues are yet to be resolved:
* BackupHDDVD C++ should write to a fifo, allowing mplayer to play it while its decrypting, as with an AACS_LA licensed player.
* The 4GB problem still exists - this is more than a simple typing issue, as it seems the current program tried to load the entire file into memory. A competant C++ programmer should be able to fix this, but I'm not a competant C++ programmer.
* mplayer still lacks support for one of the audio formats used in some films.

Hi.

While the guide itself seems solid, there are a few inaccuracies.

Specifically:
You say

Both Blu-Ray and HD DVD attempt to stop consumers from exercising fair use rights, including:


This is somewhat misleading, since (I presume) you are refering to AACS in the disks. For Blu-Ray AACS is mandatory. For HD-DVD it is optional, and quite a few studios opted out of using AACS (due to costs). Specifically "Chronos" (and according to the all future R&B Films HD-DVD releases), "Stalingrad" (Fox Pathe/Studio Canal collaboration), "Running Scared" (EMS GmbH), and a few others all are not using AACS. So in case of Blu-Ray it's the format that forces AACS on you (and on the studio). In case of HD-DVD it's the studio that forces the AACS on you as a consumer. This is a small but in my opinion important distinction, since there are examples of High Defenition releases that give fair use rights to the consumers.

I know I sound like HD-DVD fanboy (although I am about to be format neutral), however you might also want to mention the region code restrictions (none in HD-DVD, at least so far, and 3 regions with Blu-Ray)


Later on you say

The volume keys are easy to guess or brute-force, eliminating the need for either a player key or stored volume keys.


This is technically incorrect. I am not sure how the situation is on the Blu-Ray side of things, however on the HD-DVD side of things it is indeed possible to recover the volume ID (not Volume Unique Key)
in two different ways:

You can use Geremia and xt5's method that involves using a specific HD-DVD drive (TOshiba SD-S802A), sending the drive debug commands to bypass the requirement for cryptographic authentication, and convincing the drive that you authenticated already. In that case the drive lets you read the key. Note that this method requires a particular drive and a particular version of the firmware on the drive.

You can read the Burst Control Area (BCA) of the disk without a need for authentication. That will give you 8 bytes out of the possible 16. Bruteforcing 8 bytes gives you 16^8 = 4294967296 possiblities, that is currently not feasible to bruteforce in a reasonable period of time. While some disks use easy to guess volume IDs, some (Studio Canal releases, for example), use randomly generated Volume IDs


Later you you say:

Install [WWW] Zotty's BackupHDDVD C++ (not the regular BackupHDDVD, which only works on Windows).


This is incorrect. Original BackupHDDVD is written in pure Java (see my sticky in the decryptions tools forum for the link to the code). I, personally, had no problems running original BackupHDDVD under Mac OS X and under Linux x86. You must be refering to BackupHDDVD-GUI, that was modified to call Windows specific DLL files.


It might make sense to modify the guide somewhat, to say that

You need the UDF 2.5 FS drivers for your kernel
you need current ffmpeg and mplayer, built from the CVS/subversion repository.
You need 30 gigs of disk space to hold the decrypted disk
You need the keydb.cfg (http://forum.doom9.org/showthread.php?t=120611) from doom9 forum with the VUKs. If your disk is not in the list, currently you are SOL[1]
You need KenD00's DumpHD (http://forum.doom9.org/showthread.php?t=123111).

(Links to the above tools is in my sticky in the decryption forum)

Patch the kernel with UDF 2.5 driver to read the disk, Build the -current ffmpeg and mplayer, and see if you can play the disk. If you can, great - the disk doesn't have AACS on it. If you can't, you need to use DumpHD to decrypt the disk. Run DumpHD from the command line (The horror! The horror!), decrypt the disk, and play it with mplayer.

That's it.

Hope this helps.

[1] Technically it is possible to compile aacskeys under Linux. It's somewhat irritating, though.

darkstar:~/src/aacskeys$ file aacskeys
aacskeys: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped
darkstar:~/src/aacskeys$


But it works.

[lovekudu]

Thanks awhitehead for a very informative post ! I'll make the appropriate corrections, run DumpHD, add add screenshots / commands this evening.

[awhitehead]

Specifically "Chronos" (and according to the all future R&B Films HD-DVD releases),


Sorry. The above wasn't referenced and slipped through cracks. My information is from this (http://www.avsforum.com/avs-vb/showthread.php?p=10058863&&#post10058863) post on AVSforum by Richard J. Casey, president of R&B Films.


We are forced to use AACS for BD but have the option with HD-DVD. You may notice that we do NOT use AACS on any of our HD-DVD releases nor do we plan to in the future.


As usual, I urge everyone to support fair use friendly studios, and buy their releases.

[lovekudu]

I've updated the guide accordingly.

1 thing tho: where I said:

'The volume keys are easy to guess or brute-force, eliminating the need for either a player key or stored volume keys.'

You said:

'This is technically incorrect...on the HD-DVD side of things it is indeed possible to recover the volume ID...'

Your response seems to be about another topic - the article didn't say it wasn't possible to recover the volume ID.

Thanks very much for your help tho, I really appreciate a once-pver from someone who knows what they're doing - the info about unencrypted HD-DVDs was especially important.

[awhitehead]

I've updated the guide accordingly.

1 thing tho: where I said:

'The volume keys are easy to guess or brute-force, eliminating the need for either a player key or stored volume keys.'

You said:

'This is technically incorrect...on the HD-DVD side of things it is indeed possible to recover the volume ID...'

Your response seems to be about another topic - the article didn't say it wasn't possible to recover the volume ID.



I apologize.

Here is how it works, more or less:

On HD-DVD disc, there is a block of sectors of the disc that are normally not readable. In order to read from those sectors, player software needs to negotiate with the HD-DVD drive, and prove to the drive that it is allowed to read those sectors. In those sectors there is a part of disk's Volume ID.

Volume ID gets hashed together with media key, to generate volume unique key (VUK). VUKs are used to decrypt Title Keys. TKs, in turn, are used to decrypt individual elements of the disk - video files, menu files, etc.

Volume Unique Key can be recovered in fundamentally two ways:
Way #1: Listen in while a legitimate licensed player is accessing the disk, and intercept the VUK once the legitimate licensed player generated it, but before it obtained title keys and discarded it. This doesn't work for Linux, since there are no legitimate licensed players, however that worked with WinDVD software under Windows at first. Currently new versions of WinDVD and PowerDVD are supposed to close off this hole, however I don't know how successful they are.

Way #2a: Impersonate a legitimate player software, negotiate with the drive yourself, obtain volume ID, use a (stolen) legitimate processing key to hash against, and generate a VUK.

Way #2b: If you have a specific drive (Toshiba SD-S802A, drive used in Microsoft HD-DVD add-on for Xbox 360), and that drive has specific version of the firmware (version MC08), you can use the work of Geremia/xt5/arnezami, and first enable the drive's vendor specific commands (ie get drive to permit you to do things it would not normally do, unless you know a "magic password"), patch a couple of bytes in drive's RAM, and then tell drive to read off the volume ID from the disc bypassing authentication. At this point you still need a processing key to hash the Volume ID against to generate VUK, but you cut out the step where you need to impersonate legitimate software, and do the key exchange with the drive.

So being able to obtain Volume ID is a small but important part of the problem. However Volume ID consists of two parts. Half of it is accessible by reading the BCA, and doesn't require authenticating to the drive or enabling vendor specific commands on the drive. Now, some mastering houses (and currently it's up to the mastering houses to encrypt the contents they are sent by content providers, before duplicating the disks) use easy to guess Volume IDs, such as titles of discs, or dates of manufacture. Those are easily guessible just by reading BCA, and you don't need to do any magic. But some mastering houses/duplicators (such as whoever Studio Canal uses) fill out the VID with random data, and encrypt against that. Those are not guessible.

So basically, here is the situation:

A device key and a processing key were recovered from legitimate software. These can be used to impersonate a player, and fool the drive into revealing the volume ID, and then generate the VUK.

Encryption is expected to roll over in a short order to new set of keys, so newer disks will no-longer be decryptable using older processing key, and current device key will be added to the host revocation list (propogated on to the drive when you put in a new disc, before you even do anything), so the drive will not give out VID to anyone pertending to be older version of PowerDVD

But the end result: AFAIK VUKs are NOT POSSIBLE to guess or bruteforce. At least not before the heat death of the universe. It is (occasionally) possible to guess second part of the VID, but you still need processing key to obtain VUK.

Currently, before sequencing is introduced on the HD-DVD side, once you have the VUK for a particular title, you can decrypt that title and play it back for as long as you want, even if the keys you used to originally obtain the VUK get added to host revocation list on your drive.

I don't know... Is this easier to understand now? There are tons of acronims, and the entire AACS system has so many checks and balances, and so many components, that it is rather confusing.

I apologize for glossing over a bunch of detailes - my knowledge of AACS is not that good. However if you have any questions, please ask. There are a few people in this forum that have much more intimate knoledge of the actual decryption process, and they can be more specific if you ask the right questions.

Cheers

[FoxDisc]

Here is how it works, more or less:

You did a great job in the first half. I liked it so much I'd refer others to it, or maybe ask arnezami to link to it to keep the "explanation" posts together. However, at this spot you went a bit astray:
A device key and a processing key were recovered from legitimate software. These can be used to impersonate a player, and full the drive into revealing the volume ID, and then generate the VUK.

A "device key" is used to calculate a "processing key." Since the processing key was found first, the device key found later wasn't really needed. Neither is used to impersonate the player, but you are right,the player was impersonated. The impersonation is done with the "host private key," which was found by arnezami and is used to establish the encrypted AACS authorized session during which the volume id can be requested from the drive.

Encryption is expected to roll over in a short order to new set of keys, so newer disks will no-longer be decryptable using older processing key,

This is correct.
and current device key will be added to the host revocation list (propogated on to the drive when you put in a new disc, before you even do anything), so the drive will not give out VID to anyone pertending to be older version of PowerDVD
But this part is a bit off. The device keys are implicitly revoked using the Media Key Block process. The host and its Host Private Key can be revoked with the explicit revocation through the Host Revocation List. The first prevents the old processing key from working on new discs. The second is supposed to prevent the drive from giving out the volume ID to a revoked host who uses the old Host Private Key.

But the end result: AFAIK VUKs are NOT POSSIBLE to guess or bruteforce. At least not before the heat death of the universe. It is (occasionally) possible to guess second part of the VID, but you still need processing key to obtain VUK.

Currently, before sequencing is introduced on the HD-DVD side, once you have the VUK for a particular title, you can decrypt that title and play it back for as long as you want,
This part is all correct

even if the keys you used to originally obtain the VUK get added to host revocation list on your drive.
And this is too, provided you remember it's the host that gets added to an HRL and not device or processing keys.

I don't know... Is this easier to understand now? There are tons of acronims, and the entire AACS system has so many checks and balances, and so many components, that it is rather confusing.

Boy! That's sure the truth!

[TheRevoker]

You can read the Burst Control Area (BCA) of the disk without a need for authentication. That will give you 8 bytes out of the possible 16. Bruteforcing 8 bytes gives you 16^8 = 4294967296 possiblities, that is currently not feasible to bruteforce in a reasonable period of time. While some disks use easy to guess volume IDs, some (Studio Canal releases, for example), use randomly generated Volume IDs


That is incorrect; you are a magnitude off in your estimation.

8 bytes yields 2^(8*8) - not 16^8, thus 2^64 == 18446744073709551616 : not 4294967296

That is all. :D

[Zotty]

It's been a while (moved to the other side of the country, new job), but I'm back on the case. So this is just a little note to let you people know I'm back on the case ;)

2 Zotty:
(about aca_decrypter)
How about set the path to keydb.xml file in the command line arguments ?

Like: aca_decrypter.exe "E:\" "D:\" "D:\keydb.xml"
??
Will add it as an optional parameter. If no keydb is given it'll use the current dir.

I've compiled a simple guide to HD-DVD playing under Linux (including using BackupHDDVD C++ to decrypt the content before mplayer plays it) at:
http://help.ubuntu.com/community/RestrictedFormats/BluRayAndHDDVD

Note that the following issues are yet to be resolved:
* BackupHDDVD C++ should write to a fifo, allowing mplayer to play it while its decrypting, as with an AACS_LA licensed player.
* The 4GB problem still exists - this is more than a simple typing issue, as it seems the current program tried to load the entire file into memory. A competant C++ programmer should be able to fix this, but I'm not a competant C++ programmer.
* mplayer still lacks support for one of the audio formats used in some films.
Making use of a fifo would be a nice feature and that'll be the next order of business.
On a side note, I'll be getting a new dual core CPU soon. I mention this because it would be interresting to see how well it keeps up with streaming decryption. And I'd also like to add support for multiple core processors to make use of all processing power available.

The 4GB problem is fixed now. For past couple of days I'm been working on a major fix for the entire code. I was a big big mess. Anyways, I just did a testrun on a 10GB file and it decrypts the entire file, and there are no memory leaks. There was indeed a (very stupid) leak in the code, but not any longer.

I'm hoping to release the updated code within the coming days.

...
...
Thank you both for your insights. I noticed a lot has been going on the past couple of months, so I've been reading up. And it's impossible to miss your posts ;)

Btw, it looks like getting info like the VID requires an actuall drive. Anyone out there with a Debian/Ubuntu box with HD DVD drive hookup to it that's willing to provide a testing environment?

[dirio49]

Welcome back Zotty :)

[Zotty]

Oh another thing that needs to be done is getting rid of that nav chain bug/fix. As fas as I know there's no solid info on the subject available, except that the original backuphddvd didn't do this the way it was supposed to.
Haven't found specs anywhere yet, just some notes/various posts, so this is gonna take a bit of digging and reverse engineering I'm afraid. Info about this would be appreciated.

[Emon]

Oh another thing that needs to be done is getting rid of that nav chain bug/fix. As fas as I know there's no solid info on the subject available, except that the original backuphddvd didn't do this the way it was supposed to.
Haven't found specs anywhere yet, just some notes/various posts, so this is gonna take a bit of digging and reverse engineering I'm afraid. Info about this would be appreciated.

I have tested this .. if I keep the nav chain fix then I can play the individual .evo files without any issues. But once I remove this fix then individual .evo files does not play properly.

[KenD00]

As i already said in my first post, this bug is a player bug and it's not the task of the decrypter to "fix" it by altering the (correct) data from the HD-DVD. I am now using PowerDVD Ultra 7.3 and i am still NOT affected by this bug.

:rolleyes:

[dacium]

I have been trying to compile the source supplied. I think the one supplied has some version problems or mix ups because there seem to be problems that totally prevent it from compiling.

Like the make file assume they are .c files, not .cpp, i change this and still get numerous errors and even warning of unused variables. Has there been a mix up in that source since aca extracter has been upgraded multiple versions while the dvdhd c++ hasn't?

Maybe I am on the wrong compiler (g++)

[Zotty]

I have been trying to compile the source supplied. I think the one supplied has some version problems or mix ups because there seem to be problems that totally prevent it from compiling.

Like the make file assume they are .c files, not .cpp, i change this and still get numerous errors and even warning of unused variables. Has there been a mix up in that source since aca extracter has been upgraded multiple versions while the dvdhd c++ hasn't?

Maybe I am on the wrong compiler (g++)
I've been using g++ aswell, so that shouldn't be the problem. But you're right that the backuphddvd part has been neglected a bit. And as of now both will carry the same versionnumber, starting with 0.5.

Anyways, here's the new sourcepackage: backuphddvd_src_20070517.rar (http://www.sendspace.com/file/phvgou)

I would have liked to do a little more nice-to-have stuff, but I might aswell just upload the source already and keep you waiting no longer. Although the aca decrypter is also in there (they're kinda using the same code), the focus was backuphddvd.

I did change the .c to .cpp in the makefile. Hopefully it'll now compile for you.

PS, it also has the 4GB limit fix and the nav chain fix was disabled since it corrupts valid streamdata

[Zotty]

Note that the following issues are yet to be resolved:
* BackupHDDVD C++ should write to a fifo, allowing mplayer to play it while its decrypting, as with an AACS_LA licensed player.
...
Been working on this feature and at this time it appears to be impossible. After hours of testing and reading through the mplayer/ffmpeg mailinglists I've come to the conclusion that the ffvc1 codec has a bug and/or does not support streamed EVOs yet. Even a simple cat produces a console full of errors.
Right now I'm to tired (I really need some sleep LOL), but in the morning I'll file a bug report at the appropriate place. In any case I'd really like to get this working.

So for now this feature has been put on hold and we'll just have to wait for a response.

Btw, I can recommend everyone to get the latest mplayer source from SVN. Been working with source from Februari and it produced a few glitches in the stream during playback. After updating today, all glitches were gone, so apparently they fixed a few decoding errors. Highly recommended if you're using mplayer for playback.

On a sidenote, yesterday I've gotten a Xbox HD DVD rather cheap, so finally a real drive and real data to test with. Damn that feels good :D

Edit:
Little update on the streaming part. It does work! But only on the extra's that don't need to ffvc1 codec. Not the main feature yet, but it's more than I initially thought.

[jack_wuwei]

I've been using g++ aswell, so that shouldn't be the problem. But you're right that the backuphddvd part has been neglected a bit. And as of now both will carry the same versionnumber, starting with 0.5.

Anyways, here's the new sourcepackage: backuphddvd_src_20070517.rar (http://www.sendspace.com/file/phvgou)

I would have liked to do a little more nice-to-have stuff, but I might aswell just upload the source already and keep you waiting no longer. Although the aca decrypter is also in there (they're kinda using the same code), the focus was backuphddvd.

I did change the .c to .cpp in the makefile. Hopefully it'll now compile for you.

PS, it also has the 4GB limit fix and the nav chain fix was disabled since it corrupts valid streamdata

I download backuphddvd_src_20070517.rar (http://www.sendspace.com/file/phvgou), and build at MinGW. Run "backuphddvd.exe i: d:\temp". I can found some evo files, but MPlayer cann't play this files. The MPlayer version is update from SVN, and can play other decrypted evo files. My OS is windows XP SP2, HD DVD movie title is SERENITY.

[cyberdemon]

I get the feeling that you don't have many Linux testers out here. so let me tell you my experiences.

I am a Ubuntu 7.04 Feisty (kernel 7.4.20.16) user and have an external Xbox HD DVD player hooked up to my PC (just got it today). I only have one HD DVD (Phantom Of The Opera) to play with and do not plan getting any others until I can confirm that I can play them using this setup.


I have successfully patched my kernel with UDF 2.5

Tried DumpHD java file (I hate java) and got only grey screen for the GUI (I have installed sun java 1.6 and removed the generic ubuntu version) so I tried it with arguments (input, output) seemed to work for a while but crapped out after a while.

I have the latest SVN of mplayer compiled and installed.
I also have the latest SVN of FFMPEG compiled and installed.
I have verified that the keys are in the xml file

I compiled your software and am able to run it fine. backuphddvd runs and does not spit out any errors so I am sure everything there is working fine.

I however can not play anything with mplayer.

the following has been attempted on the decrypted output from backuphddvd....



when trying to play an intro I get nothing, (no video output) and the resulting info in terminal

server@server:~/hddvd$ mplayer -vc ffvc1 /home/server/hddvd/HDintro.EVO
MPlayer dev-SVN-r23739-4.1.2 (C) 2000-2007 MPlayer Team
CPU: AMD Athlon(tm) XP 2000+ (Family: 6, Model: 8, Stepping: 1)
CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE

Playing /home/gene/hddvd/HDintro.EVO.


Exiting... (End of file)



when trying to play the feature I still get no video output and the resulting information in terminal (after a serious delay)

server@server:~/hddvd$ mplayer -vc ffvc1 /home/server/hddvd/POTONBM6ME1_HD.EVO
MPlayer dev-SVN-r23739-4.1.2 (C) 2000-2007 MPlayer Team
CPU: AMD Athlon(tm) XP 2000+ (Family: 6, Model: 8, Stepping: 1)
CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE

Playing /home/server/hddvd/POTONBM6ME1_HD.EVO.
MPEG-ES file format detected.
VIDEO: MPEG1 17x34 (aspect 13) 12.000 fps 56207.2 kbps (7025.9 kbyte/s)
vo_cvidix: No vidix driver name provided, probing available ones (-v option for details)!
[cyberblade] Error occurred during pci scan: Operation not permitted
[mach64] Error occurred during pci scan: Operation not permitted
[mga] Error occurred during pci scan: Operation not permitted
[mga] Error occurred during pci scan: Operation not permitted
[nvidia_vid] Error occurred during pci scan: Operation not permitted
[pm3] Error occurred during pci scan: Operation not permitted
[radeon] Error occurred during pci scan: Operation not permitted
[rage128] Error occurred during pci scan: Operation not permitted
[savage_vid] Error occurred during pci scan: Operation not permitted
[SiS] Error occurred during pci scan: Operation not permitted
[unichrome] Error occurred during pci scan: Operation not permitted
[VO_SUB_VIDIX] Couldn't find working VIDIX driver.
==========================================================================
Forced video codec: ffvc1
Cannot find codec matching selected -vo and video format 0x10000001.
Read DOCS/HTML/en/codecs.html!
==========================================================================


Exiting... (End of file)


I believe that the software you have created works perfectly but am at a loss to prove it. maybe I have done something wrong with mplayer but I seriously doubt it. I have gone over the installation several times to be sure I had everything correct.

If only there were a HD DVD Player out there that would work in Linux. I think that is what is lacking with the Linux platform at the moment, no software to test the results. The current mplayer solution just does not work for me. maybe it does for others.

I would love to see a driver for VLC that would probably be the easiest solution for linux not to mention it would be cross platform. I am not fluent in any language so I must rely on smart folks like you guys to do all of the thinking for me.


I hope that I did not leave anything out there. I have done allot of things to get this to work and am sure I am missing telling you something important that I have already done.

I am not looking for help just thought I would post my experiences. Ill figure it out eventually.

[sl1pkn07]

Hi

Great work Zotty!

but...

sl1pkn07@SpinFlo:~/Desktop/backuphddvd_src_20070517$ make backuphddvd
g++ -c -o src/backuphddvd.o src/backuphddvd.cpp -I. -L.
src/utils/file.hpp:6: error: declaraciones de ‘typedef long long unsigned int uint64_t’ en conflicto
/usr/include/stdint.h:56: error: ‘uint64_t’ tiene una declaración previa como ‘typedef long unsigned int uint64_t’
make: *** [src/backuphddvd.o] Error 1
sl1pkn07@SpinFlo:~/Desktop/backuphddvd_src_20070517$ make aca_decrypter
g++ -c -o src/aca_decrypter.o src/aca_decrypter.cpp -I. -L.
src/utils/file.hpp:6: error: declaraciones de ‘typedef long long unsigned int uint64_t’ en conflicto
/usr/include/stdint.h:56: error: ‘uint64_t’ tiene una declaración previa como ‘typedef long unsigned int uint64_t’
make: *** [src/aca_decrypter.o] Error 1
sl1pkn07@SpinFlo:~/Desktop/backuphddvd_src_20070517$ make cfg2xml
g++ -c -o src/cfg2xml.o src/cfg2xml.cpp -I. -L.
src/utils/file.hpp:6: error: declaraciones de ‘typedef long long unsigned int uint64_t’ en conflicto
/usr/include/stdint.h:56: error: ‘uint64_t’ tiene una declaración previa como ‘typedef long unsigned int uint64_t’
make: *** [src/cfg2xml.o] Error 1
sl1pkn07@SpinFlo:~/Desktop/backuphddvd_src_20070517$

Ubuntu Feisty 64-bits

thanks

solved! http://forum.doom9.org/showpost.php?p=1013169&postcount=33

[Adub]

Sorry to dig up a old thread, but I am trying to update the current keydb file that is on the forums and post the cfg and xml versions. However, when I use the cfg2xml executable, it says that title keys are not supported. I am pretty damn sure that I don't have any title keys in there, but I can't be sure.

I tried to get a hold of your source, but all the links are dead. I would just have modified it to tell me which line it was finding the title key.

Here is the cfg. If you could either send me the source, or just tell me where the problematic entry is, that would be great.
http://www.sendspace.com/file/pfdbm6


Edit: scratch that. I managed to find your code in your SVN repository. I found the problem. It was a lower case "v". Fixed.