BackupHDDVD, a tool to decrypt AACS protected movies

[Nomadic]

New version BackupHDDVD-GUI v0.0.5 (link removed)
changes:
- Added more GUI functionality.
- List of files with the possibility of choice.
- Added AboutBox with the developers working on this programme (was nobody forgotten?).
- Minor fixes
- Check the correctness of the Volume Unique Key using CMAC algorithm (by Nutrition24)

[noclip]

Oh, and since everyone is adding CMAC-baesd volume key checking algorithm, I'd like to suggest using the CMAC to identify disks instead of a SHA1 hash of the TK file.

[kad77]

Oh, and since everyone is adding CMAC-baesd volume key checking algorithm, I'd like to suggest using the CMAC to identify disks instead of a SHA1 hash of the TK file.

Why? There are optimized SHA1 implementations available, and it is perfectly valid for uniquely identifying the TK. A lengthy disc list is available using this format... Where's the advantage in your suggestion?

[noclip]

Why? There are optimized SHA1 implementations available, and it is perfectly valid for uniquely identifying the TK. A lengthy disc list is available using this format... Where's the advantage in your suggestion?

You don't have to do any hashing, just read the CMAC from the disk. Gets rid of an unnecessary step.

[He-Man]

Why? There are optimized SHA1 implementations available, and it is perfectly valid for uniquely identifying the TK. A lengthy disc list is available using this format... Where's the advantage in your suggestion?
You don't have to do any hashing, just read the CMAC from the disk. Gets rid of an unnecessary step.
Besides this another and IMHO more important advantage of using CMAC over SHA-1 is that you can always verify if submitted Volume Unique Keys are indeed correct. When someone submits keys to an online database, they could automatically be checked for correctness at the same time so people don't post invalid keys, either on purpose or by mistake.
As The_ByteMaster said: "This will help make the program a little more robust against fake or wrong keys".

I actually think it's a very good idea to switch from SHA-1 to CMAC. Then people don't need to implement SHA-1 hash calculations in key extraction software anymore. Key extrationn will mste likely be an integrated part of BackupHDDVD in the future along with extraction of CMAC, Movie Title and prodution date from the disc).

The online database isn't that big by now that it can't soon be changed. People who have submitted keys can soon find the CMAC value too to update the database. But because of this it's better to do the change from SHA-1 to CMAC now than wait 6 months or so.

By using CMAC instead of SHA-1 it will be possible to verify.
If the format of KEYDB.cg should be changed from uising SHA-1 to CMAC values, maybe it should be changed to have the titles in the first filed and then region/natiiom and date in the next filed and the CMAC and key files. It would improve readablity for human eayes to have the titles keys as the first thin I think.




An earlier post about CMAC by The_ByteMaster:
My bad! But yes, the idea was just to have a quick check whether the Volume Unique Key in the KEYDB.cfg is indeed correct. This will help make the program a little more robust against fake or wrong keys.

The format of VTKF.AACS file can be found in paragraph 3.4 of AACS_Spec_HD_DVD_and_DVD_Prerecorded_0_912, more specifically in Table 3-5. The TKF MAC field (16 bytes) is bytes 2464-2479.

The CMAC calculation is the one described in NIST SP800-38B, also described RFC 4493 with a C source.
I googled and found Java source (OMAC.java), placed in the public domain by author Paulo Barreto, here: http://www.larc.usp.br/~pbarreto/

[0xdeadbeef]

I want to clear a few things up about BackupHDDVD performance for the non-technical:
1. Software can be structured to be multi-threaded (not 'multi-core'), which would utilize multiple processors and/or cores.

When processing a stream, you'd need to divide the stream into packets which can be processed in parallel. Multithreading alone won't help. Also I'm not even sure if a multithreaded application running in a virtual machine will necessarily be distributed to multiple CPUs.


2. An interpreted language algorithm (ie Java byte code running in a Virtual Machine, or C# in the CLR) is always going to be slower than a native machine code algorithm. Non-threaded native C/C++ code will probably still outperform multi-threaded Java, btw.

The Java runtime uses a just in time (JTI) compiler, so in a processing loop, the code executed is "native" anyway. Indeed the JIT compiler might create better code than a static compiler under some circumstances.


3. If you are really impatient, you can try compiling muslix64's source in the GNU Java compiler to get a native binary executable. You might see some performance gains, but you probably will learn something.

This won't help. Indeed the EXE might even be slower.


I've partially written a platform independent C translation, and I'm sure others will rewrite the utility in a similar high-performance language (probably C++, with assembly sub-sections) that can be compiled to a specific processor-- C/C++ code will run significantly faster than the Java reference code currently floating around. C# may provide some marginal improvement, but it is still managed code and is not as portable as Java, C, or C++.

Well, a highly optimized C version might indeed be faster though I wouldn't expect a large improvement. I don't see any reason why a C#-version should be. Using ASM won't help much either, only if the purpose is to use SIMD instructions which of course could speed up things quite a bit.
Anyway, my impression is, that most of the runtime is disc IO. If the AES implementation in the Java runtime should really slow things down by a measurable degree, maybe it would be worth to implement an optimized version instead of starting conversions to other languages just because people think Java is generally slow (which it isn't).

[romgohan]

There is some talk about speed, decrypting speed and so on...
Can someone with a drive (and a lot of patience) compare the time of copying the encrypted evo file to HDD with decrypting it with BackupHDDVD?
That way we can see how much can be gained through program optimizations..

[2bigkings]

without copying to hdd first, it tooks about 55min to decrypt it from drive to hdd.

~27gb movie
p4 3,2ghz (HT)
1GB RAM
sapphire x1950pro

if you copy it first to HDD, it tooks much longer.. first i thought also it goes faster but it doesn't

[heman]

i can't decrypt with BackupHDDVD-GUI v0.0.5 version i get the following error

BackupHDDVD starting.
=== Start analyse ===
Scaning video directory...
Founded files...
=== Start decrypting ===
Could not find any ".AACS" file. Aborting...

i tested it on all 3 discs i have with the original jar file its working

[NghtShd]

Well, a highly optimized C version might indeed be faster though I wouldn't expect a large improvement. I don't see any reason why a C#-version should be. Using ASM won't help much either, only if the purpose is to use SIMD instructions which of course could speed up things quite a bit.

I don't see any reason there shouldn't be translations into any language people might want to develop in. I used C# for a several reasons (and, BTW, prior to now I've never done more than a couple dozen lines of C# code):

1) I use Visual Studio anyway, so it was there.

2) Going from Java to C# seemed more straight forward than going to C++ (my language of choice).

3) I wanted a to put a GUI on it*. VStudio made that pretty easy.

4) I felt like doing some C# code for a change and I thought someone else may also prefer to tinker with that instead--choice is good.

5) I thought I would also do a C++ version after the C# was done. Doing this has made me much more familiar with the code and was a lot more interesting than simply reading the code over and over. However, if others are working on C or C++ then I may not bother with that after all.

* When I first started this I was unaware of any other GUI versions and prior to last night I hadn't seen HDDVDBackup-GUI (good job, BTW). I was a little surprised at the similarity at first (oh noes! I'll get flamed for ripping off their UI:)), but I guess a having couple of lines for file paths and a button or two is the obvious way to go. Anyway, I considered not going forward with this when I saw that someone was working on a GUI, but as I said above, choice is good and I've enjoyed having some reason to learn a little C#.

So there are my reasons for a C# version. As melakai said, it's probably better to go ahead and get the source out, so I'll try to go ahead with that today, but I do want to add credits to muslix64 for the original code in all my source files and clean up a few things first.

Can you use XML-based key storage in future versions?

I think this was directed toward the Java version, but I was actually working on that a bit yesterday. Seems alike a good way to go and I like your layout.

[romgohan]

Thanks for info 2bigkings, but I wanted to compare decrypting copy with direct copy to get how much time does the decrypting algorithm take.

[jokin]

i can't decrypt with BackupHDDVD-GUI v0.0.5 version i get the following error

BackupHDDVD starting.
=== Start analyse ===
Scaning video directory...
Founded files...
=== Start decrypting ===
Could not find any ".AACS" file. Aborting...

i tested it on all 3 discs i have with the original jar file its working

I had the same error with Batman Begins.

BackupHDDVD starting.
=== Start analyse ===
Scaning video directory...
Founded files...
=== Start decrypting ===
Could not find any ".AACS" file. Aborting...

There is also a typo. Founded should be Found

Also one more column in the file listing with file size would be nice.

Any way to make it possible to pause decryption?

[He-Man]

without copying to hdd first, it tooks about 55min to decrypt it from drive to hdd.

~27gb movie
p4 3,2ghz (HT)
1GB RAM
sapphire x1950pro

if you copy it first to HDD, it tooks much longer.. first i thought also it goes faster but it doesn't
The reason it takes longer time decrypting when you copy to the HDD first is probably because you read and write from the same HDD. And since the program has to read and write a large amount of data things will most likely be slowed down by using the same drive as both source and destination. The drive can only do one thing at the time. If you use the HD-DVD drive as source instead, then the drive can spend all the time writing instead of only 50% of the time.
Things will probably also be faster if you use two different HDD's on different HDD controllers as source and destination (not two different partitions on the same HDD).

[kad77]

Besides this another and IMHO more important advantage of using CMAC over SHA-1 is that you can always verify if submitted Volume Unique Keys are indeed correct. When someone submits keys to an online database, they could automatically be checked for correctness at the same time so people don't post invalid keys, either on purpose or by mistake.
As The_ByteMaster said: "This will help make the program a little more robust against fake or wrong keys".


Thanks for this clarification, and your other points. You make the case quite well! The past few posts have persuaded me that the change to CMAC is a simple but elegant change.

It reduces the code base, and provides increased functionality.

What are the downsides? (Any show stoppers?)

[kad77]

When processing a stream, you'd need to divide the stream into packets which can be processed in parallel. Multithreading alone won't help. Also I'm not even sure if a multithreaded application running in a virtual machine will necessarily be distributed to multiple CPUs.

Thanks for expanding on this point. Following what you've pointed out, a C/C++ (C#?) implementation would pull ahead of Java in this situation.

The Java runtime uses a just in time (JTI) compiler, so in a processing loop, the code executed is "native" anyway. Indeed the JIT compiler might create better code than a static compiler under some circumstances.

Key word here is 'might'. There have been numerous comparisons showing Java pulling equal or better performance numbers to compiled C++ code (usually against GNU, but not Intel's CP). But hand tuned C++/asm will always win. This is hardly debatable for tuned implementations.

This won't help. Indeed the EXE might even be slower.

I would find the attempt interesting. I can't say how you can definitively state this without testing it. I'll grant you the GCJ compiler is not very mature...

Well, a highly optimized C version might indeed be faster though I wouldn't expect a large improvement. I don't see any reason why a C#-version should be. Using ASM won't help much either, only if the purpose is to use SIMD instructions which of course could speed up things quite a bit.

'Might' indeed. Of course that type of implementation would be faster. Brian Gladman's AES implementation will beat the pants off any conceivable Java implementation.

http://fp.gladman.plus.com/cryptography_technology/rijndael/index.htm

Anyway, my impression is, that most of the runtime is disc IO. If the AES implementation in the Java runtime should really slow things down by a measurable degree, maybe it would be worth to implement an optimized version instead of starting conversions to other languages just because people think Java is generally slow (which it isn't).

Java isn't generally slow, and hasn't been for years. My main point that was lost in your replies was that the core decryption algorithm needs attention before 10 incorrect implementations are floating around.

The disc I/O issue likely is a large bottleneck. Block reading EVO chunks into large memory buffers might be a better approach than sequentially hammering the drive. A multi-threaded approach may help here as well.

[arnezami]

Besides this another and IMHO more important advantage of using CMAC over SHA-1 is that you can always verify if submitted Volume Unique Keys are indeed correct. When someone submits keys to an online database, they could automatically be checked for correctness at the same time so people don't post invalid keys, either on purpose or by mistake.
As The_ByteMaster said: "This will help make the program a little more robust against fake or wrong keys".

Just wanted to point out that simply changing from SHA-1 to CMAC won't enable an online database (containing lots of user submitted keys) to check whether or not these keys are correct.

In order for that to work someone (preferably the one who has found a key for a disc) would have to upload the title key file himself. He cannot simply post the key and cmac on (for example) a forum without posting the title key file itself because the cmac needs the entire title key file to check the title key. In practice this sometimes means that others would have to upload this title key file to the online database in order for this to work (preferably before or around the same time the key is found so you can immediatly check whether the key is correct).

Furthermore: cmac is not an identifier, its an authenticater (when you do not yet have the key the cmac has no meaning at all). When using cmac as an identifier the above could get more difficult (that is: key uploading as a separated event from the title-key-file uploading). In that case an online database has to deal with people that (pretend to) want a key for a certain title key file (and upload a title key file to the online database). But since there is no proper identifier of this file (anybody can change the file and add the same cmac) its less easy to determine whether a given key is correct. There could be hundreds/thousands of fake title key files uploaded (not much to do about that btw) but all with the same cmac. When a key arrives (including a cmac as identifier) all these files have to be checked. However if a sha-1 hash (of the title key file) is used and the person who has found the key accompanies his key with this hash then only one file has to be checked (keep in mind the title key file includes the cmac so it can be checked even when using a sha-1 hash as identifier).

I'm not saying using the cmac as identifier is by definition a bad thing (I kinda like the idea of removing all that is not required ;)). But there is more to this story that (at least) has to be considered as I hopefully explained above...

Just my thoughts on this matter. :)

Regards,

arnezami

PS. When using title key files to check cmacs on an online database there is no way of preventing uploading of (deliberate) fake title key files (even including keys). Since anyone with some crypto experience can create files that have valid cmacs but have no relation to any released HD DVD at all.

[NghtShd]

Here's an XML version of KEYDB.cfg in case anyone wants to work on using this format or comment on which elements should be included/excluded and/or better idea in general.

http://users.adelphia.net/~m.crane/bin/KEYDB.xml (http://users.adelphia.net/~m.crane/bin/KEYDB.xml)

-

[noclip]

arnezami:

CMAC would mainly be a time saver. The user feeds the program a key and it instantly knows whether or not it's valid. No need to involve online key DBs.

[arnezami]

arnezami:

CMAC would mainly be a time saver. The user feeds the program a key and it instantly knows whether or not it's valid. No need to involve online key DBs.

I agree. CMACs should be used offline only. Just leave the sha-1 hash as it is.

[Shadowfax3000]

For other softwares which require an actual HD-DVD drive for playback, there are two options:

1. The Sonic Scenarist software already includes a drive emulator ("Multiplexed software emulation of HD DVD Advanced Content Volumes (http://72.14.205.104/search?q=cache:HB351aJtR9UJ:www.transtec.nl/download.php%3Fid%3D3%26file%3DPro%252Fsonic%252FScenaristBrochure0406.pdf+sonic+%22hd-dvd%22+emulation&hl=en&ct=clnk&cd=3)").

2. The Microsoft HD DVD Interactivity Jumpstart (http://www.microsoft.com/downloads/details.aspx?FamilyID=f8ada3f5-0ec6-4392-84ab-cb4860db30ed&DisplayLang=en) is available. It provides an HD-DVD emulator for testing applications and is free to download provided you can pass the Genuine Advantage check.

Is anyone aware of an HD-DVD emulator that will work with Vista? Microsoft's thing won't install on Vista. I'm sure Scenarist would, but I'd rather actually buy the HD-DVD drive for $200 rather than the software for $5,000.

[tonyp12]

Here's an XML version of KEYDB.cfg in case anyone wants to work on using this format or


XML Programs can not read a regular text file?

I could make the option in TitleSorter1.4 (http://forum.doom9.org/showthread.php?p=938127#post938127)to output to xml format if this is requested by a few people.

[noclip]

I agree. CMACs should be used offline only. Just leave the sha-1 hash as it is.

I wouldn't go that far. Obtainment of a CMAC (reading a fixed offset from a file) is less tedious and error-prone than generating a SHA-1 hash. CMAC is certainly cleaner as it serves to both hash the title keys and allow verification of a volume key. Muslix's solution was analogous to duct tape (it works, but isn't pretty). Future releases which use an XML-based KDB should also use CMAC-based disk recognition.

A slightly cleaner version of an XML keyset:


<KeySet>
<Description>A Movie (US)</Description>
<Key type="CMAC">00000000000000000000000000000000</Key>
<Key type="Volume">00000000000000000000000000000000</Key>
<Key type="Title" order="1">00000000000000000000000000000000</Key>
<Key type="Title" order="2">00000000000000000000000000000000</Key>
</KeySet>

[Nutrition24]

i can't decrypt with BackupHDDVD-GUI v0.0.5 version i get the following error

BackupHDDVD starting.
=== Start analyse ===
Scaning video directory...
Founded files...
=== Start decrypting ===
Could not find any ".AACS" file. Aborting...

i tested it on all 3 discs i have with the original jar file its working

Hi, this is a (now) known problem with the V0.0.5 BETA release, only VTKF.AACS files are found. We'll fix the problem and we'll post as soon as possible a fix.

[He-Man]

I wouldn't go that far. Obtainment of a CMAC (reading a fixed offset from a file) is less tedious and error-prone than generating a SHA-1 hash. CMAC is certainly cleaner as it serves to both hash the title keys and allow verification of a volume key. Muslix's solution was analogous to duct tape (it works, but isn't pretty). Future releases which use an XML-based KDB should also use CMAC-based disk recognition.

A slightly cleaner version of an XML keyset:


<KeySet>
<Description>A Movie (US)</Description>
<Key type="CMAC">00000000000000000000000000000000</Key>
<Key type="Volume">00000000000000000000000000000000</Key>
<Key type="Title" order="1">00000000000000000000000000000000</Key>
<Key type="Title" order="2">00000000000000000000000000000000</Key>
</KeySet>

You forgot a field for production date as muslix64, I and others reccomended recently: http://forum.doom9.org/showthread.php?p=938991#post938991
I think the country code shouldbe in a seperate filed instead of included in the title name, this way it will be easier to sort the list by country.
In future versions of BackupHDDVD the title name, prodution date and CMAC will probably be extracted automatically from the disc along with the Volume Unique key automatically being extrated from a memory dump at the same time.
The title name is stored on the disc in VPLST000.XPL like you can see here: http://forum.doom9.org/showthread.php?p=939400#post939400
displayName="Batman Begins HD DVD"

[generalnewbie]

I had the same error with Batman Begins.

BackupHDDVD starting.
=== Start analyse ===
Scaning video directory...
Founded files...
=== Start decrypting ===
Could not find any ".AACS" file. Aborting...

There is also a typo. Founded should be Found

Also one more column in the file listing with file size would be nice.

Any way to make it possible to pause decryption?

Wouldnt it be...

"Files Found...:"

[blutach]

Let's not get hung up on the trivial please. jokin has been notified about the typo.

Regards

[sensite]

Hi, this is a (now) known problem with the V0.0.5 BETA release, only VTKF.AACS files are found. We'll fix the problem and we'll post as soon as possible a fix.

the logic can be changed to the following so it will find either of the AACS files

BackupHDDVD.java::getKeySet

if(!keyFile.exists()) {
mainFrame.printLogMessage("Could not find any \".AACS\" file. Aborting...");
return(null);
}

[muslix64]

Sorry, I don't want to cross post, but may be you will be interested to know that I have decrypted and play back my first BluRay AACS protected media file!

I will post all my Blu-Ray investigation results in the thread "BlueRay and AACS"

See you there!

[kad77]

Sorry, I don't want to cross post, but may be you will be interested to know that I have decrypted and play back my first BluRay AACS protected media file!

I will post all my Blu-Ray investigation results in the thread "BlueRay and AACS"

See you there!

Great job, of course. Have you had any feedback on correcting your decryption algorithm? Others have posted AACS specs, and seem to have some good ideas on what packets need to be handled differently...

What say you?

[muslix64]

I'm aware that BackupHDDVD don't fully implement AACS, so there are some glitches here and there. There are a lots of good coders here so I leave that to them. I focus on Blu-Ray now...

[kad77]

I'm aware that BackupHDDVD don't fully implement AACS, so there are some glitches here and there. There are a lots of good coders here so I leave that to them. I focus on Blu-Ray now...

Thanks for the clarification about your intentions with the AACS algorithm. Wish you well on the Blu-Ray reversing.

I will try and summarize what the community has publicly posted about correcting the code here soon, so new members can catch up on what needs to understood to move forward.

[hajj_3]

muslix64, great to hear about blue-ray.

2nd of all some people have pretty much got IME working in here: http://forum.doom9.org/showthread.php?t=120842&page=3

hope you might be able to contribute a bit to it, even if you just add it to your command line version then we can create a gui version like we have done.

[2bigkings]

The reason it takes longer time decrypting when you copy to the HDD first is probably because you read and write from the same HDD. And since the program has to read and write a large amount of data things will most likely be slowed down by using the same drive as both source and destination. The drive can only do one thing at the time. If you use the HD-DVD drive as source instead, then the drive can spend all the time writing instead of only 50% of the time.
Things will probably also be faster if you use two different HDD's on different HDD controllers as source and destination (not two different partitions on the same HDD).

thanks for info, i will try this. i got 2 HDDs, but i dont know which partition is on which hdd (i got 4 partitions). more infos later..
@muslix good luck with blu-ray!

[He-Man]

A slightly cleaner version of an XML keyset:


<KeySet>
<Description>A Movie (US)</Description>
<Key type="CMAC">00000000000000000000000000000000</Key>
<Key type="Volume">00000000000000000000000000000000</Key>
<Key type="Title" order="1">00000000000000000000000000000000</Key>
<Key type="Title" order="2">00000000000000000000000000000000</Key>
</KeySet>

Wouldn't it better to change the name from CMAC to TKF MAC (Title Key File MAC) like in the AACS HD DVD and DVD Pre-recorded Book:
http://www.aacsla.com/specifications/AACS_Spec_HD_DVD_and_DVD_Prerecorded_0_912.pdf
This way we make it clear what CMAC value is used.
CMAC is just a general term (like SHA-1), while TKF MAC is the specified name in the AACS HD DVD and DVD Pre-recorded Book.
I prefer to use the TFK MAC name instead of just CMAC, so nobody doubts what CMAC value it is.
TKF MAC is a specified 16-byte data filed in Title Key File, while CMAC could be the CMAC value of many things.

[blutach]

Just a short note to members here.

This thread is getting long and is meandering from topic to topic. I would like this thread to be confined to discussions about the core algorithm please.

Discussions about GUI development (and associated grammatical errors!!! :() in whatever programming language merit their own thread, as do calls for help on decrypting your DVDs using the programs. (I can see this has started anyway).

During the next few days, I will clean out this thread a bit along these lines.

I hope this will make things a lot easier to follow.

Thank you.

Regards

[choiceltd]

after reading the other threads am i to assume that muslix has now cracked the blue ray format also, or am i a bit premature this is good stuff, i have posted a region problem for blue ray also but not sure if its the right kind of question for this forum but im sure someone out there knows how to change it the search continues, clueless but hungry to learn.

[hajj_3]

hopefully this can be added to the next version of GUI: http://forum.doom9.org/showthread.php?t=120970

would be great to auto scan for the key.

[cwm9]

Wonder if that might be their next protection layer - adding IME to everything?

Regards


Yes, there is. I've finished a rather exhaustive analysis of the format and now pretty much fully understand why certain things are not working, including the "nav chain bug" (at least I think so.)

The nav chain fix needs to be rewritten. Also, the code to determine if a pack should be decrypted or not needs amending. Last there is an entire class of keys that are not being used yet, and for the moment certain blocks are being left encrypted in the file.

I'm now working on fixing these three problems.

[muslix64]

@choiceltd
Just to clarify, I have only decrypted the AACS layer of Blu-Ray. It's good news but not that cool. BD+ is the other protection of Blu-Ray. I need a BD+ protected movie to crack it too.
By the way, if you are interested about details on my known-plaintext attack, I have written an article on the Blu-Ray thread...

[Eeknay]

AFAIK no current movies employ BD+. It's pretty much vaporware right now.

[2bigkings]

eeknay is right, bd+ is not out yet.

[muslix64]

When you say "BD+ is not out yet", do you mean the players or the movies? (Or both!)

[The_ByteMaster]

I'm now working on fixing these three problems.

Great! cwm9, would you say that some of these problems aren't directly AACS related but more related to the way HD-DVD (Video) is enhanced compared to DVD-Video? What I mean is, suppose NASA would put out a HD-DVD in the public domain (without AACS) but with IME. Wouldn't just copying the .EVO files cause the same problem? I'm just curious.

[2bigkings]

the movies and i think the ps3 is at the moment the only player that can handle bd+

[cwm9]

Sooo...

I was asked to elaborate, so elaborate I shall. First, let's be clear: this is the HDDVD thread and this is about BackupHDDVD, not blu-ray.

NAV CHAIN BUG
---------------
In the NAV (Navigation) packets there are three packets, one of which is a Data Search Information (DSI) packet. The DSI is supposed to tell you where the next and prior NAV packets are along with other similar info. The field being fixed-up in the sorce is the poorly named VOBU_ea, or VOBU_end address. It's supposed to be an offset to the next NAV packet from the begining of the next packet (VOBU_ea=next_nav_address-this_nav_address-1.

In the days of DVD, VOBU_ea was supposed to be in bytes -- at least that's what I gathered from various net sources. Looking at the raw binary on the HDDVD, it's clear VOBU_ea is written in sectors, not bytes. This is logical because the value is always a multiple of 2048, and more than one person thought it was silly that VOBU_ea called for bytes and not sectors.

My guess is that the NAV CHAIN BUG is one of two things: 1) the authors that wrote the authoring software for HDDVD didn't use bytes by mistake. I think this is unlikely, but if this is the case, the fix would be rewriting all of these values, a pretty easy task. 2) the writers of the HDDVD player software assumed VOBU_ea would be the same as it used to be when in fact it has been changed to a sector offset. I think this is more likely.

The numbers in the field make sense for what they are, and I can see no reason why the fixup should be applied. Indeed, when I recompiled with the nav-chain-bug fix completely removed, the files still played on my system. I suspect the problems the author had with this bug may have been due to a bug in the player and not a bug in the HDDVD.

For the moment, I'm just deactivating this "fix" in my source code, until I find out more information. This is probably a non-bug.

DECRYPTION DECISION
----------------------
The specification says that HL_PCK MUST be encrypted even if the PES_scrambling_control bit is set to 0. Since noone seems to know what the MPEG start code for an HL_PCK (highlight pack) is, it's not possible to know when to force it's decryption at this time. This probably isn't that critical... I don't even know what highlight packs are for. No one probably cares about this, for now.

ILVU DECRYPTING
-----------------
All ILVU packs are decrypted with Sequence Keys Kc = AES-G ( SEG_KEY*, Dtk || CPIlsb_96 ) which are being totally ignored at this time. All ILVU packs are currently being decrypted with the TITLE key which is wrong since they have their PES bit set but the code to recognize ILVU packs is not in place, nor is there any mechanism in the code to retrieve the appropriate keys. (Well, that's assuming ILVU packs are actually stored in .evo files, which I haven't had time to verify, but I assume that is the case. Otherwise, why store the key IDs for them in the .evo?) I thought this might be needed for IME, but I hear some people have IME working, so it's probably only used for multiple angles. If that's the case, this may be another issue that noone
cares about.

Fixing this is multi-step... first the start code of an ILVU needs to be found. Second, the code to get the seg_keys must be
written. Finally, the actually decryption must be added.

All in all, probably everything anyone cares about is already decoded correctly, and there are only minor details left to care for. I've decided not to go after fixing any of this as it's all stuff no one cares about. Maybe someone else can take this info and run with it.

...so that's the current state of the decoder.

Attached is a bit-by-bit description of the first (NAV packet) in the stream. It's very useful for understanding what the heck the thing is doing.

[He-Man]

Seems like you are on the right track cwm9, keep up the good work.

Since noone seems to know what the MPEG start code for an HL_PCK (highlight pack) is, it's not possible to know when to force it's decryption at this time.
MPEG? Shouldn't it be VC-1 instead of MPEG?


Can't the .map file from the disc be re-used in some form for the decrypted HDD file?

[cwm9]

MPEG? Shouldn't it be VC-1 instead of MPEG?


Can't the .map file from the disc be re-used in some for the decrypted HDD file?

The VC-1 stream is chopped up into a PES stream and muxed just like mpeg, so yes, an mpeg start code.

It shouldn't surprise you; ac3 isn't mpeg, yet it's stored on DVD's in mpeg files. ;)

Yes, the map files can be moved, so it's not that critical, and no, I don't know if the map files without the nav bug patch work correctly.

[KornX]

could backuphddvd join the files of the main movie?
could you add them without trouble?

KornX

[cwm9]

could backuphddvd join the files of the main movie?
could you add them without trouble?

KornX

copy /b FEATURE_1.EVO+FEATURE_2.EVO FEATURE_ALL.EVO
=)

[Emon]

I was working on a C# port myself but looks like NghtShd beat me to it. I did create a nice looking wrapper GUI for BackupHDDVD using C# .. just couldn't post it earlier because of the 5 day posting restriction for new users.

Get it from this (http://forum.doom9.org/showthread.php?t=121042) thread.
let me know if you guys like it or not.