PDA

View Full Version : HD DVD aca file extracter (and backuphddvd C++)


Zotty
24th January 2007, 22:46
For those who want to look inside the aca files aswell I've made a little tool that extracts and decrypts the ARF (=Advanced Resource File) files from it (png, wav, ttf, js, xmf and xmu). Could be usefull in making menu's work and what more.

I have no doubt that there are more gifted coders out there, but it works like a charm. It's very likely there are strange parts that can be rewritten. If you think so, say so and we can make this thing better. This is version 0.1 btw and only does extracting/decrypting. Verfication with hash/mac is planned.

There's 1 thing I'd like to specifically say; volume keys are read from an XML file (as suggested here http://forum.doom9.org/showthread.php?p=941284#post941284). However, this does not include the SHA-1 hash of the VTKF000.AACS file which is widely used. It only has the a TKFMAC field. As said the hash value is widely used, so I've been abusing TKFMAC to store the hash value. I'll change this in a later stadium, but for now it seemed like the right thing to do. Albeit I'm not thrilled with it. Just so you know.

Compiled executable and source are in there. Just run it from the console and usage is simple; arf_extracter source dest.
I've also tested it a bit on King Kong and output was 100% working.

Oh and there's a C++ version of backupHDDVD in there aswell ;) Also tested this one and the result is a 100% binairy compatible output compared to backuphdvd v1.00 (the original java version).

Disclaimer:
Don't hold me responsible if it crashes and burns down your computer gnagna. For the rest, feel free to use the code if you want (god knows I've kept a close eye at mulix64's code :)), but if you use (part of) it, it's only fair to give your source in return to the community. Well, you know what I mean.

edit:

Changelog
^^^^^^^^^
BackupHDDVD v0.5
- Complete overhaul of the code
- Fixed 4GB limit (only linux)
- Fixed memoryleak
- Disabled nav-chain fix
- Faster decryption

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)
[/quote]

backuphddvd_src_20070517.rar (http://www.sendspace.com/file/phvgou)
hddvd_cpp_20070129_bin.rar (http://www.sendspace.com/file/0lb0k4) (OLD!)

LokiHD
24th January 2007, 23:40
ur next!

edit: for the life of me, i cannot run it, sorry.. i thought its gui

Zotty
24th January 2007, 23:51
ur next!

edit: for the life of me, i cannot run it, sorry.. i thought its gui
Sorry, no GUI. Maybe in the future, but atm my priority is to get the underlying code functioning properly and get a better understanding of the whole picture.

Anyways, this should dump the extracted files in a directory called "acaoutput";
arf_extracter source destination_dir

Momotte
24th January 2007, 23:54
do you know if the .aca file has to be remastered so that power dvd will be able to show menu / U-CONTROL?

If so, I was thinking that instead of extracting all those files from it you could just decrypt them in place and have a .aca file that is unencrypted...

Zotty
25th January 2007, 00:07
do you know if the .aca file has to be remastered so that power dvd will be able to show menu / U-CONTROL?

If so, I was thinking that instead of extracting all those files from it you could just decrypt them in place and have a .aca file that is unencrypted...

arg, just found that out 5 mins before I read your post. Guess I must have missed that post, so that's what I'll be what I'll be doing tomorrow morning. On the other hand, it is called extracter and that's just what it does. When started I never thought that it might be usefull in getting menu's to work, just wanted a look inside.

On a side note, I've already got a message from someone who's messing with the data that is outputted, so at least it's usefull from a educational point of view ;) Besides, in the meantime editing that data is possible, which isn't an option if the data is written directly back into the aca file.

Emon
25th January 2007, 02:15
where's your "arf_extracter"? You have only linked your C++ version of backuphddvd

aerox87
25th January 2007, 02:23
where's your "arf_extracter"? You have only linked your C++ version of backuphddvd

Try the rapidshare link. That one contains the right tools.

Janvitos
25th January 2007, 02:40
I have tested the arf_extracter program, congradulations for that it did work on some movies.
But there are actually 2 important problems with it:

- In some movies, there is more than one aca file.
Right now, the program seems to choose the first aca file it encounters.
Maybe add an option to specify our own input filename.

- Unfortunately, the program crashes on more than 3/4 of my movies.
I currently have 15 titles and was only able to rip the aca files on 4 of them.
It looks like the arf_extracter is crashing on certain filenames because it decrypts some of the files and then suddenly crashes.

If it would be possible to have these issues corrected that would be amazing.
I currently was able to rip the menus for 4 of my movies and successfully recompress them unencrypted with CreateACA.exe (included with Microsoft HD DVD Interactivity Jumpstart).
The menus worked fine in the movies once everything was re-assembled properly.

P.S. Since CreateACA.exe only takes filenames or filelist as an input, my trick was to generate a file list from the unencrypted aca contents using the "dir /B > temp.txt" command.

2themax
25th January 2007, 03:45
Nice work. I was able to decrypt both ACAs from King Kong, recreate them, and use them for playback. The full menus and U-Control work perfect.

frogman
25th January 2007, 04:20
i "HATE" rabbitshare ... I been unable to get anything from them in weeks. Any where else.

abe2000
25th January 2007, 06:15
Could someone please upload CreateACA.exe? 'cause I cant install the jumpstart crap on Vista. Says I need atleast XP SP2.. nice coding there microsoft. (and no you cant use compatability mode on .msi files)

Emon
25th January 2007, 06:17
Could someone please upload CreateACA.exe? 'cause I cant install the jumpstart crap on Vista. Says I need atleast XP SP2.. nice coding there microsoft. (and no you cant use compatability mode on .msi files)

Direct link (http://download.microsoft.com/download/0/f/f/0ff3512c-fe1e-4526-96e7-dd4ccaaca6e8/HDDVDJumpstart.msi)

abe2000
25th January 2007, 06:21
Direct link (http://download.microsoft.com/download/0/f/f/0ff3512c-fe1e-4526-96e7-dd4ccaaca6e8/HDDVDJumpstart.msi)

No thats to the msi file which i cant install, thanks anyway though.

Emon
25th January 2007, 06:24
No thats to the msi file which i cant install, thanks anyway though.

http://www.sendspace.com/file/eljf22

abe2000
25th January 2007, 06:27
http://www.sendspace.com/file/eljf22

Thank you very much! :)

Zotty
25th January 2007, 09:07
- In some movies, there is more than one aca file.
Right now, the program seems to choose the first aca file it encounters.
Maybe add an option to specify our own input filename.
Hmmz, that's something I've overlooked. Should be easy enough to fix.


- Unfortunately, the program crashes on more than 3/4 of my movies.
I currently have 15 titles and was only able to rip the aca files on 4 of them.
It looks like the arf_extracter is crashing on certain filenames because it decrypts some of the files and then suddenly crashes.
That was unexpected. It could be related to related to MAC encapsulated ARF's, but atm that's a guess. In my test aca file these are not present, but I've had a message that for example the EU version of MI3 has MAC ARF's and that it crashes the thing. I've also noticed the test aca seems to order the type of capsulation according the spec. First encrypted, then encrypted and hashed, etc. Could be coincidence, but might explain why you're getting at least part of the data.
Looking into that today.

Thanks for the feedback Janvitos!

edit: it's not the MAC encapsulation, so time for a 2nd bugtrack attempt...
edit 2: ok, finally been able to reproduce a crash with serenity

He-Man
25th January 2007, 10:20
No thats to the msi file which i cant install, thanks anyway though.
You don't have to extract the msi archive, you should be able to just extract the files you want from the msi archive without installing it.
An msi archive is like a zip or rar archive, just use WinRAR or similar to extract files.

ape
25th January 2007, 10:27
hi again, i felt like helping out with the menu situation on hd-dvds, so i made an extractor for the .aca files.
the files this extracts should be decryptable with backuphddvd (i haven't tried, it will probably require a few modifications).
they will need to be packed into an .aca file again (i will try and code a program to do this tommorow).

usage:
place extract_aca.exe in the same folder as your .aca file (or vice versa)
in a command prompt from the directory containing both files type:
extract_aca.exe whatever.aca
it will output to a folder with the same name as the aca file.

binary:
http://mihd.net/2p1cy0

source (feel free to post bugfixes, improvements, etc):
http://mihd.net/kldzen


edit:
i just saw the post with zotty's program that does the same thing, so nevermind this i guess. his even decrypts the files :P.

ape
25th January 2007, 10:30
just posted my own .aca extractor, i didn't know zotty had already written one. i posted source as well incase anyone wants to mess with it/implement it into backuphddvd heh.

Momotte
25th January 2007, 13:08
I have tested the arf_extracter program, congradulations for that it did work on some movies.
But there are actually 2 important problems with it:

- In some movies, there is more than one aca file.
Right now, the program seems to choose the first aca file it encounters.
Maybe add an option to specify our own input filename.

- Unfortunately, the program crashes on more than 3/4 of my movies.
I currently have 15 titles and was only able to rip the aca files on 4 of them.
It looks like the arf_extracter is crashing on certain filenames because it decrypts some of the files and then suddenly crashes.

If it would be possible to have these issues corrected that would be amazing.
I currently was able to rip the menus for 4 of my movies and successfully recompress them unencrypted with CreateACA.exe (included with Microsoft HD DVD Interactivity Jumpstart).
The menus worked fine in the movies once everything was re-assembled properly.

P.S. Since CreateACA.exe only takes filenames or filelist as an input, my trick was to generate a file list from the unencrypted aca contents using the "dir /B > temp.txt" command.

LOL ! you are always ahead. I performed the same task last night and got KK working...

@Zotty: Great work ! Now just decrypting the .aca and allowing more than one file would be perfect. Big Thanks !

Momotte
25th January 2007, 13:56
just posted my own .aca extractor, i didn't know zotty had already written one. i posted source as well incase anyone wants to mess with it/implement it into backuphddvd heh.

Works fine, TY. Tested with KK.

blutach
25th January 2007, 15:16
just posted my own .aca extractor, i didn't know zotty had already written one. i posted source as well incase anyone wants to mess with it/implement it into backuphddvd heh.Threads merged.

Regards

Zotty
25th January 2007, 15:34
k, found a potential crasher within the code. The problem is that the filesize of certain files is too big for keeping it in mem within the decrypting code. Already fixed that thing, but not yet ready for upload. Soon, but also need to do my normal dayjob ;)

PS, only happend with one big file so far; Serenity, file navBGV2_Root.png which is 1,5 MB.

aerox87
25th January 2007, 16:09
Yep. Crashed at the same file with Happy Gilmore also.

d1g1ta7
26th January 2007, 02:19
I've noticed that it only takes the first *.aca file. So if there's an ime.aca file, it'll only decrypt that, and not the menu.aca that follows. So just copy the AACS and ADV_OBJ folders to the root of a drive, and delete the ime.aca file after you've decrypted it, etc.

Also, it still always seems to want to enable subtitles. Is there a fix for this without completely removing the subtitles?

aerox87
26th January 2007, 02:59
I've noticed that it only takes the first *.aca file. So if there's an ime.aca file, it'll only decrypt that, and not the menu.aca that follows. So just copy the AACS and ADV_OBJ folders to the root of a drive, and delete the ime.aca file after you've decrypted it, etc.

Also, it still always seems to want to enable subtitles. Is there a fix for this without completely removing the subtitles?

Just bring out the menu (there is a menu button in PowerDVD or you can right click and find Menu Title menu option) and just disable/enable subtitles in settings/set-up.
Works fine on the ones i tested with (serenity and Happy Gilmore).

d1g1ta7
26th January 2007, 04:40
Just bring out the menu (there is a menu button in PowerDVD or you can right click and find Menu Title menu option) and just disable/enable subtitles in settings/set-up.
Works fine on the ones i tested with (serenity and Happy Gilmore).

I know that works, but why does PowerDVD automatically enable subtitles?

On Smallville Season 5, Disc 1, when IME is activated, the subtitles turn on, and the option to turn them off is no longer in the settings.

evdberg
26th January 2007, 12:21
just posted my own .aca extractor, i didn't know zotty had already written one. i posted source as well incase anyone wants to mess with it/implement it into backuphddvd heh.

I had also already made my own resource extractor, but zotty released his before I had found the time to test it properly ... also I wanted it to be able to output a new resource file, instead of only extracting the files. Anyway, no need for it now anymore ...

Zotty
26th January 2007, 20:14
Quick changelog:
- Changed name to ACA decrypter
- Supports multiple ACA files
- Bugfix that caused crashes when working with large ARF's (e.g. 1,5MB in size)
- Seperate files are now stored in a directory called "<nameofaca>_files"
- A decrypted ACA file is constructed in the destination directory
- Replaced win32 specific filesystem calls with something more portable

See initial post for link

I've tested it with multiple aca files from different discs (King Kong, Batman Begins, MI3, Serenity). It runs stable over here and output looks good. The decrypted aca file I've compared with the results of createACA.exe on the king kong files and is 100% binary compatible. Since there's no such thing as perfect, let me know if you run into any trouble.

Usage is the same, except it's now called aca_decrypter. I hope crashes are solved now and the 1 decrypted aca file is also helpfull.

Emon
26th January 2007, 20:53
ACA decrypter v0.2 (http://www.sendspace.com/file/xuo37f)

Quick changelog:
- Changed name to ACA decrypter
- Supports multiple ACA files
- Bugfix that caused crashes when working with large ARF's (e.g. 1,5MB in size)
- Seperate files are now stored in a directory called "<nameofaca>_files"
- A decrypted ACA file is constructed in the destination directory
- Replaced win32 specific filesystem calls with something more portable

I've tested it with multiple aca files from different discs (King Kong, Batman Begins, MI3, Serenity). It runs stable over here and output looks good. The decrypted aca file I've compared with the results of createACA.exe on the king kong files and is 100% binary compatible. Since there's no such thing as perfect, let me know if you run into any trouble.

Usage is the same, except it's now called aca_decrypter. I hope crashes are solved now and the 1 decrypted aca file is also helpfull.

Sweet !!! I was eagerly waiting for you to release the new version.

Momotte
26th January 2007, 22:32
I will try it later tonight and let you know of my results...

Zotty
26th January 2007, 22:51
I will try it later tonight and let you know of my results...

That would be great. Been eagerly awaiting results from others.

Edit:
Reported and confirmed V for Vendetta is still an issue. I'll be damned...

mb2696
26th January 2007, 23:40
Zotty, despite any issues, this is still a great tool. Keep up the great work!

Zotty
27th January 2007, 00:11
Fixed: ACA decrypter v0.3 (http://www.sendspace.com/file/tlss7p)

Same memory allocation problem, only different place. Sorry for the inconvenience. Working with the feedback you and others give me ;) Just walking through the entire source to see if there are any other spots. At least now I know what to look for.

Btw, the XML format is still bothering me. Right now the TKFMAC is being occupied by the SHA-1 hash value that's been used all along. How about adding a hash field aswell so these can be seperated before too many keys are added to the DB in in essence the wrong field?

Momotte
27th January 2007, 00:39
I just tried it with T.I.J., works fine... thanks!

moshmothma
27th January 2007, 00:56
How do you rebuild the ACA file? MS's tool leaves a lot to be desired. Also, there are differences between the size of the original aca and the recreated one. Thanks

Zotty
27th January 2007, 01:22
How do you rebuild the ACA file? MS's tool leaves a lot to be desired. Also, there are differences between the size of the original aca and the recreated one. Thanks

As I didn't find any information on the exact format, I kinda reverse engeneered it with help from the MS tool. There's no AACS encryption, so it's not in the AACS specs. That also implies I don't have all the details (see below).

Here's what I do; allocate a block of memory (let's call this M) the size of the original encrypted file. The decrypted version has no extra data such as protection type, title key pointer, hashes and so on, so the end result will always be smaller than the original. Btw, make sure the order in which the ARF's are processed does not differ from the original or the rest of the story doesn't work.

Next I copy the original headerinfo, the ACA header and file index, to M. This contains offsets, filesizes, CRC values and MIME-types. At this stage these are unknown so they will need to be updated later.

Now I start decrypting all ARF's, one by one. Since only one ARF is processed at a time, right after decryption M needs to be updated since all needed info is now available. First the decrypted data is appended to M and next I overwrite the initally copied filesize and offset in M with the new values and determine the MIME-type and calc the new CRC.

This is done till all ARF's are decrypted and stored in M. Last thing to do is update the total filesize in the header and write the whole thing to disk. Tada, you've got a new and decrypted ACA file.

The only unknown is that I don't know all MIME-types. In the encrypted ACA all have an ID of 0xFF. Decrypted they need to have a specified value. So far I know the values for:
xpl, xmf, xmu, js, jpg, png, wav, ttf and xml.
Don't know them for these files (haven't encountered them yet):

- Advanced subtitle (.XAS)
- Capture image format (.CVI, .CDW)
- Multiple-network-graphic (.MNG)
- OpenType Font (.OTF)
- Style sheet (.XSS)
- Time map (.MAP)
- Timing sheet (.XTS)
- TrueType collection (.TTC)
- MMF
- XTS
- LPCM

Info on those would be appreciated.

Emon
27th January 2007, 01:41
I am having trouble getting it to work with "Lady in the Water" HDDVD.

Here's what I got when I first ran it:

Title Key File MAC: 8A21D06E2EE1A0EC1FC26161119ADD6E
Title Key File hash: A14D5F731B4A11524EF17BDED1B6FA0ED6B88B34
No Volume Key found... aborting!

So I took the the TKFMAC value and added a new entry into your keydb.xml like the following way:


<KeySet>
<Description>Lady in the Water</Description>
<Origin>US</Origin>
<Key type="TKFMAC">8A21D06E2EE1A0EC1FC26161119ADD6E</Key>
<Key type="Volume">DFCFFF93F0DA12BF8284D45B2779F704</Key>
</KeySet>


But it still failed.

EDIT: got it working. Sorry my bad .. I didn't RTFM

2bigkings
27th January 2007, 10:02
but i have to edit the VPLST000.XPL also or not? Or is this aca decrypter a 1:1 Copy? i've got kingkong , so what i have to do with all these files?

evdberg
27th January 2007, 11:24
Snippet from my source:

{ "XPL",1 },
{ "XMF",2 },
{ "XMU",3 },
{ "XTS",4 },
{ "XAS",5 },
{ "XSS",6 },
{ "JS", 7 },
{ "EVO",8 },
{ "MAP",9 },
{ "JPG",10 },
{ "PNG",11 },
{ "MNG",12 },
{ "CVI",13 },
{ "CDW",14 },
{ "WAV",15 },
{ "OTF",16 },
{ "TTF",16 },
{ "TTC",16 }

calinb
27th January 2007, 12:17
Oh and there's a C++ version of backupHDDVD in there aswell ;) Also tested this one and the result is a 100% binairy compatible output compared to backuphdvd v1.00 (the original java version).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?

2bigkings
27th January 2007, 13:01
the c++ version copy all files, but the most of the files are 0 bytes big.
this version decrypt the feature1.evo file only to 1,69gb and the feature2.evo is 0 byte big. But it says everythings okay. anybody got this problem too?

Zotty
27th January 2007, 14:17
A quick update after updating the MIME-types posted by evdberg: 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

Snippet from my source:
<cut>
Thanks! May I ask how you got it so complete, curious?

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?
Sweet! Having it portable is the intention, but didn't get around yet to actually try it. So it's very nice to hear the first Linux result is a positive one. Been compiling with GCC, so I'm hoping it will run natively under Linux before the end.
Haven't looked at UDF drivers yet, since I don't have a real drive to experiment with. So unfortunately I can't tell you much about that... yet ;)

the c++ version copy all files, but the most of the files are 0 bytes big.
this version decrypt the feature1.evo file only to 1,69gb and the feature2.evo is 0 byte big. But it says everythings okay. anybody got this problem too?
I must confess you're the first to actually try the backuphddvd app and reported back about it. It was writen before the aca decrypter, so I'm pretty sure there will be bug in there looking at how it went with the decyrpter.
It was never tested on a real HD DVD. So I got encrypted menu and intro material to test it out and no bugs were found. But those were files of a couple of hundred MB's, not GB's. Will look into it this weekend. Need to clean up the source, so I'll try to address this issue aswell.

evdberg
27th January 2007, 15:06
Thanks! May I ask how you got it so complete, curious?
Quite simple actually ... I just created test files with all possible extensions, made an aca file using the MS CreateAca tool and used an hex editor to look at the mime type ...

calinb
27th January 2007, 18:57
the c++ version copy all files, but the most of the files are 0 bytes big.
this version decrypt the feature1.evo file only to 1,69gb and the feature2.evo is 0 byte big. But it says everythings okay. anybody got this problem too?
Yes--I reported too soon about Linux and Wine. I see this too.

tonyp12
27th January 2007, 23:57
I have tested this C++ port, it works with my TitleSorter GUI (http://forum.doom9.org/showthread.php?p=943657#post943657)

Just move Zotty's backuphddvd.exe to the same folder as the original backuphddvd.cmd
and my program with launch the C++ exe instead.

OR move my titlesorter.hta and keydb.cfg to Zotty's folder.

If you had problem with my xml, it have now been fixed.

markrb
28th January 2007, 03:50
Bourne Supremacy crashes when starting.
It finds the keys and such and then crashes hard.

I will try another title as this has been the only one I have tried so far.

Mark

Edit same thing with Dazed and Confused.

More info. .2 of aca_decrypter works while .3 crashes for me.
Both in stand alone and Gui mode.

markrb
28th January 2007, 06:19
.2 version does work for me.
Subtitles are forced on and won't shut off, but I will just kill them in the file myself.
I haven't tried switching audio yet, but I don't see any need to do that anyway as long
as the default continues to be English 5.1.
.3 and .31 both continue to crash.

Is there anyway to get the gui to write the keys to the xml file while saving it to the keydb file
or is that even needed anymore?

Mark

Zotty
28th January 2007, 15:15
Just a few words on the current situation; what started out as a quick experiment has turned into something with a much larger audience. Now I don't mind this (it's actually pretty nice to see it's been so usefull to so many people), but there apparently there are some problems with stability which I'm having a hard time to track down due to the lack of suffient testmaterial (HD DVD isn't sold here yet).
That combined with the fact that I also added a quick port of backuphddvd in the first packages (which still used the cfg instead of xml) and that other programs are including the decrypter in their own packages has led me to believe a few things should change before it get's too confusing for all of us.

So here's what I'm planning to do;

- Both apps will use the same keydb in XML format. So far the decrypter was using XML where the MAC filed was occupied by the hash value. Both values can be used now. Also backuphddvd was still using the old keydb.cfg, but the next update will work with the XML keydb. So one keydb for both apps.


<KeySet>
<Description></Description>
<Origin></Origin>
<Key type="CMAC"></Key>
<Key type="Hash"></Key>
<Key type="Volume"></Key>
</KeySet>


- I'll add a small tool to convert existing keydb.cfg to keydb.xml. This should make the transition easy. If I have the time I'll try to include a complete db. Think the counter is at 88 keys or something like that.

- Source and executables will be released seperate. Hopefully this will solve the "help how do I compile?" questions from people who only want to run the tool. It also speeds up the release of executables a bit.

- Last thing that'll be added is a log file. If you run into problems at least it'll be visible where the problem occured. PM or upload the log and it'll be much easier for me to track down potential problems.

So that's about it. I'm hoping it will work out in terms of improved stability and usabilitly. I'm no wizzkid or whatever, but I'll try to do my best to make the tools stable and usefull to everyone.

Metro
28th January 2007, 15:54
Nice work, Zotty! Can't wait to test it :)

Oleg_Jdev
28th January 2007, 16:03
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
28th January 2007, 16:28
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
28th January 2007, 20:39
I have updated TitleSorter to use the new Key type name:
<Key type="Hash"></Key>

calinb
28th January 2007, 20:59
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
28th January 2007, 22:01
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
29th January 2007, 07:24
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
29th January 2007, 23:44
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
30th January 2007, 00:02
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
30th January 2007, 00:20
Yey !! will test it tonight .. and I guess I have to fix my app also and wrap the args with "s.

Galileo2000
30th January 2007, 05:38
Thanks Zotty, testing it inside Emon version 0.5 right now, will report soon.

Oleg_Jdev
30th January 2007, 08:48
Thanks Zotty, we will use your engine in our next versions.

calinb
31st January 2007, 09:36
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
31st January 2007, 10:54
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
31st January 2007, 17:14
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
31st January 2007, 18:05
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-
31st January 2007, 19:46
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
31st January 2007, 21:59
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
1st February 2007, 03:35
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
1st February 2007, 05:23
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
2nd February 2007, 01:05
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
2nd February 2007, 03:00
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
2nd February 2007, 14:02
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
8th February 2007, 03:07
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
8th February 2007, 03:50
Oleg, I got my HD DVDs now.

What would you like me to test?

Oleg_Jdev
8th February 2007, 10:19
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
8th March 2007, 01:05
Edit: Sorry for my post.

Galileo2000
8th March 2007, 02:28
Not sure mods will be happy with your post BTW.

evdberg
8th March 2007, 09:26
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
8th March 2007, 09:54
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
4th April 2007, 23:08
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
23rd April 2007, 09:58
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
23rd April 2007, 16:30
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
24th April 2007, 03:01
Thanks awhitehead for a very informative post ! I'll make the appropriate corrections, run DumpHD, add add screenshots / commands this evening.

awhitehead
24th April 2007, 04:38
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
27th April 2007, 08:43
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
27th April 2007, 20:58
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
27th April 2007, 23:12
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
1st May 2007, 05:37
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
12th May 2007, 22:44
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
12th May 2007, 23:51
Welcome back Zotty :)

Zotty
13th May 2007, 18:58
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
14th May 2007, 23:59
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
15th May 2007, 01:43
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
16th May 2007, 14:15
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
17th May 2007, 13:54
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
20th May 2007, 01:00
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
6th June 2007, 09:29
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
8th July 2007, 09:13
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
13th July 2007, 02:17
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
12th March 2008, 21:23
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.

Derrow
7th October 2008, 14:45
backuphddvd C++ is no longer available for download.

Can somebody help me out here?

BTW: Any C++ source codes for Blu-ray and hd-dvd are welcome.

KenD00
8th October 2008, 19:02
backuphddvd_src_20070517.rar (http://rapidshare.com/files/152111016/backuphddvd_src_20070517.rar.html)

IIRC DecryptHD is the successor of this program, but it's sources aren't available anymore too. I don't have the latest version 0.5 of it, only 0.4, if you like to have that, i can upload it too.

I don't know of any Blu-Ray decrypter sources except the ancient BackupBluRay (which is java).

:rolleyes:

Derrow
10th October 2008, 11:54
Thanx a ton!
I am all set now.

setarip_old
10th October 2008, 17:53
@Derrow

Working on a new IFOEdit-like program?