BackupHDDVD, a tool to decrypt AACS protected movies

[Doormat!]

Nope. Please read the aacs specs. I know its complicated, but I believe the basic idea is fairly simple:


I've read the spec's ... but your explanation was better!

Correct me if I'm wrong - but what you're saying is that the MKB, which is different for each disk (not individual disks, obviously - but for each movie or release) contains a ton of keys - one of which is the specific key which, in conjunction with the key for the host (be it hardware or software player) is used to calculate the key needed decrypt the contents.

Therefore by not including a matching key for a compromised host, even if you manage to avoid the revocation mechanism in some way - the key you need just isn't there.

Is that correct?

BTW - off topic a bit, but what the hell - I was reading (unable to post at that time) as the ball dropped as it were, and people started to produce results. It made me feel as if I was at Bletchley Park during it's peak back in WW2.

It was a most amazing feeling.

[OverlordQ]

There might be many more so i guess it's time to start working on a solution for this.
Obviously, we will need a total re-write of the BackupHDDVD program and most importantly, an experienced coder who can work this out.

That's what I was thinking of doing when I set up the svn, the code works, and I"m sure is plenty readable by muslix, but was a pain to add in just the two minimal features I added.

So hopefully muslix could enlighten us as to what License the source is under since all the FAQ has is:
-Do you plan to do a user interface version?

No, other people will do. You have the source code, so enjoy it!


which one might guestimate to mean Public Domain, but I dont wanna guess.

[bass4040]

Anyone confirm?

well the movies i have i couldnt playback on my main rig as my x1800xt vcard wasnt hdcp. but after the dump to the HD it plays just fine on the x1800xt :)

so i would say that yes you can play them once on your drive.

[Warren]

Anyone confirm?

True.

[tonyp12]

Alot of movies are not ripping properly at the moment.
It seems like all the movies with some sort of enhanced experience content do not assemble properly after decryption.


Could it be that PowerDVD that is not playing it right?
They are still working out the bugs over at Cyberlink
and it could be just that PowerDVD gets confused when
playing back some enhanced type of EVO files compared to open up a HDDVD folder.

If the same file that studders with powerdvd plays back with Sonic Scenarist 4.1 (DirectShow filters, no sound)
When you know it's powerdvd that is at fault.

[woah!]

Could it be that PowerDVD that is not playing it right?
They are still working out the bugs over at Cyberlink
and it could be just that PowerDVD gets confused when
playing back some enhanced type of EVO files compared to open up a HDDVD folder.

If the same file that studders with powerdvd plays back with Sonic Scenarist 4.1 (DirectShow filters, no sound)
When you know it's powerdvd that is at fault.

i believe you have nailed it :)

i can playback kingkong (video only) in MPC using Sonic Scenarist 4.1 but in powerdvd it stutters bad.

[KornX]

Hi there,

i wonder about two things:
does anybody know a place where the evo container specs are and second why is the mainfeature sometimes split in two large files (layer splitting ?!?)

KornX

[Warren]

Yes but you need $5000 to get them. Correct.

[blutach]

As far as in my conutry is related, Copying for private use from a "legally acquired original" is legitimate fair use. A rented copy is a legally accquired copy, so it is legal to make a copy of it for private use-(Is the same action as time shifting when recording from a TV).

So what's all this warnings about something that is legal in many countries?

R.Yes, I am aware that the laws of various countries allow copying rentals. However, in order to cater to the international scope of this forum, we can only operate under one set of rules for everyone. That is what we are tasked to enforce and that is what we ask you to work under. If that is not acceptable to people in certain jurisdictions, they may post elsewhere.

Regards

[cwm9]

...It appears that the drive holds a Host Revocation List and the host holds a Drive Revocation List. Maybe I'm missing something here but it seems that the first time you place a disk that contains any given player in its revocation list into the drive, that player will forever more no longer function with that drive--even after a fresh reinstall of the player software. Drive firmware hacks may soon be useful.

I'm wondering if that's what the x-box 360 HDDVD drive's "memory devices" are for -- the ones that have no windows xp drivers.

At any rate, it shouldn't be hard to get around this. If the protocol for accessing the drive's memory is well defined, you can prevent this from happening by intercepting the USB messages and trapping any messages which write to the revocation block.

I don't think this is needed though... even if the player is revoked you can still read the encrypted files from the drive and you can still download VUKs from the forums.

[evdberg]

Alot of movies are not ripping properly at the moment.
It seems like all the movies with some sort of enhanced experience content do not assemble properly after decryption.
I have ripped and tried all of my HD-DVD movies and around 1/3 of them don't play well at all (very choppy playback, image distortion).

This is a list of my movies that DON'T work properly once ripped:

- V for Vendetta
- Batman Begins
- King Kong
- Mission Impossible 3
- Charlie and the Chocolate Factory
- Enter the Dragon

There might be many more so i guess it's time to start working on a solution for this.
Obviously, we will need a total re-write of the BackupHDDVD program and most importantly, an experienced coder who can work this out.

I already mentioned it before, but I will say it again: how about the nav chain problem and fix? I do not trust this at all, see also my post (http://forum.doom9.org/showthread.php?p=933636#post933636) earlier in this thread.

[arturner]

Hi Everyone,

I was just wondering about something, can the known plaintext approach not be used to further reverse decrypt up the key chain in AACS?

The Volume unique key is a cyptographic function of the Volume ID (according to AACS spec, somewhere in a safe place on the disk) and one of the other keys ( can't rememeber) which one, haven't got time to go through the whole thought process atm, but anyone got any thoughts on this?

[generalnewbie]

ive been reading the AACS spec pdf that someone linked to and all i can say is a lot of it doesn't make sense and then a lot of it does.

But if someone could share some light on my question that would be great. And i know that its been talked about a few times but i absorb things slowly.

Ok so it states that the AACS Optical Drive has a "Host Revocation List" or better know as "Device Keys" and a host "Drive Revocation List" also known as device keys. Those are the exact words in the document.

Correct on the statement above?

Now then What exactly are those two?

In our case is the Xbox HD-DVD? Host revocation list?
And the HD-DVD movie? Drive revocation list?
Or is the actual software the Drive revocation list?


In any event they say they can black list these device keys if they are compromised by two methods they add they Device keys to the Revocation list on the host. That mean the future HD DVDs
will contain a blacklist? But what does The Media Key Block (MKB) that enables system renewability do exactly?

[arturner]

@General Newbie

In this case, the XBOX drive has a device key (and can be revoked) and WinDVD/PowerDVD have host keys (can be revoked).

So they can revoke the Hardware & Software players individually.

Done through revocation lists which are (correct me if I'm wrong someone) part of the MKB.

[JackSnap]

@General Newbie

In this case, the XBOX drive has a device key (and can be revoked) and WinDVD/PowerDVD have host keys (can be revoked).

So they can revoke the Hardware & Software players individually.

Done through revocation lists which are (correct me if I'm wrong someone) part of the MKB.

So , if they decide to revoke the xbox360 usb HDDVD drive, that means that EVERYONE that has brought one will not be able to play new movies? surely that would piss off 10's of thousands of people, what would they do offer a free replacement?

Sorry if these are obvious questions , just trying to get my head around it.

[He-Man]

So , if they decide to revoke the xbox360 usb HDDVD drive, that means that EVERYONE that has brought one will not be able to play new movies? surely that would piss off 10's of thousands of people, what would they do offer a free replacement?

Sorry if these are obvious questions , just trying to get my head around it.
They will not revoke the drive since it has not been compromised in any way. It's the player (WinDVD) that has been compromised. So if they will revoke anything it will be the compromised player(s), not the drive.
The drive will still work after this with new updated players that has not been revoked, but the old revoked player will not work anymore.

[JackSnap]

They will not revoke the drive since it has not been compromised in any way. It's the player (WinDVD) that has been compromised. So if they will revoke anything it will be the compromised player(s), not the drive.
The drive will still work after this with new updated players that has not been revoked, but the old revoked player will not work anymore.

Yes at the moment, i was just thinking in the future, if we find a way to stop the revocation with that drive etc. I was just wondereing how they would handle a hardware situation without annoying so many people.

[He-Man]

I am still wondering on the Nav chain problem and the fix. From the source I saw that Muslix64 sets the MSB of the VOBU_EndAddress to 0x7F (in V0.99 to 0x0F). This can never be a good idea. It would also explain why the bitrate spiked to 300Mbit/s. Would it be possible that the problem was in PowerDVD 6.5 and that 7.2 plays the files fine with the original value? Because from what I checked in the original streams, the value for VOBU_EndAddress is just correct.
It would be easy to test for someone with a drive and PowerDVD 7.2.
Just decrypt the movie with v0.99 + title key instead of v1.00 + volume unique key and then play it back with the newest version of PowerDVD.

[arturner]

So , if they decide to revoke the xbox360 usb HDDVD drive, that means that EVERYONE that has brought one will not be able to play new movies? surely that would piss off 10's of thousands of people, what would they do offer a free replacement?

Sorry if these are obvious questions , just trying to get my head around it.

Correct, so very doubtable that they will do this.

Most likely they will revoke the current version of WinDVD which actually is (currently) allowing people to read the decrypted title/volume unique keys...

But, as stated before, this only means that people will have to find them again. And, it is technically possible to do the same with hardware players! Which is more interesting, seeing as people will be p***ed off if their player gets revoked :)

And on top of all this, because we now HAVE devrypted keys, this makes future work easier, for software players i.e. you know what you'e looking for in memory. For hardware pplayers, the same is true :)

[He-Man]

Yes at the moment, i was just thinking in the future, if we find a way to stop the revocation with that drive etc. I was just wondereing how they would handle a hardware situation without annoying so many people.
If the XBOX360 drive key was revoked, then owners would probably have to update the drive firmware to a newer and more secure version via the USB connetion.

[JackSnap]

ok, as far as software players go, so far I have found the following that apparently play HDDVD.
Can anyone confirm if they show their keys or not.

Player, Keys

PowerDVD, Version Dependent?
WinDVD Platinum, Yes
DirectDVD Pro, No
Cineplayer Surround, No
DVD X Player, No
BlazeDVD, No
RioDvd, No

[Dreassica]

Just a verification note and brief comment (if I may have a pass on strikes for the support to the project)

1) Van Helsing works just fine with the volume key I posted earlier.

2) Now that this project is well on it's way I can finally go buy HD DVD's and start storing them on my 10TB media server and keeping the originals safely stored in their cases. I've been waiting for this since HD was released. Looks like Blu Ray will be left in the cold *** wondering what happend when HD DVD takes off like a sky rocket now. Also the PR0n disks won't get covered in goo now that they announced HD DVD instead of Blu Ray.

Piracy/backups so soon will only have a negative effect on hd-dvd, because the evil movie distributors will ditch it for teh safer option, since they want to protect their IP.

[Nutrition24]

@evdberg: Did you in the meantime manage to dump the keys directly from the key schedule routine ? I did see your output in your post, but could not match it to known keys from the "Volume Unique Keys" thread.

I'm a bit surprised that apparently the most successful method for now is a plain memory dump of the running process. Or am I missing something ? What took so long then to have this confirmed ? The creation of a keyfind/test program for the retrieved memory perhaps ?

I think it's more difficult to defend against key schedule dumping than against memory dumping. If you distribute the different parts throughout memory, the chance that you see a key during runtime is a lot lower than it's now, because the keyfind/test program doesn't have a clue how to re-assemble the key. (you'll only be able to see it before the keyschedule is called because the keys must be reassembled before that. I think that recomputing title keys before every CRC decrypt'll be way too slow, and anyway they'll be shortly in memory then)
The AES part however cannot be taken out and it'll always happen in registers/memory whatever the vendors tell us. What could happen is some crc check against the loading dll to see if it's tampered with, but a simple JZ to JMP conversion should be able to defend against that, isn't it ?

[blutach]

For some reason Dreassica, you seem to not have absorbed warnings by Doom9 or me about irrelevant posts.

Strike issued.

Regards

[crashd]

ok, as far as software players go, so far I have found the following that apparently play HDDVD.
Can anyone confirm if they show their keys or not.

Player, Keys

PowerDVD, Version Dependent?
WinDVD Platinum, Yes
DirectDVD Pro, No
Cineplayer Surround, No
DVD X Player, No
BlazeDVD, No
RioDvd, No

By the very nature of their existence (ie: they are software) they will have to have their keys in memory at some point, it just so happens that Win DVD is designed in such a way that the unencrypted key is in contigous memory rather than split across multiple memory locations (which is harder to find, or at least, more legwork)

[Bystander]

ok, as far as software players go, so far I have found the following that apparently play HDDVD.
Can anyone confirm if they show their keys or not.

Player, Keys

PowerDVD, Version Dependent?
WinDVD Platinum, Yes
DirectDVD Pro, No
Cineplayer Surround, No
DVD X Player, No
BlazeDVD, No
RioDvd, No

I suggest not revealing more information on players until the current one is stopped. But to keep working on solutions to reveal them when it is needed.

The keys can be found in all HD players whether software or hardware. You just have to have the right debugging tools for both; and the patience/motivation/time to step through the program. One could also write a debugging script to do it for you.

I can also confirm King Kong is not decoded properly.

[bass4040]

I think this is only with Powerdvd 6.5. With PD 7.2 Ultra, I get a black screen with lines and an advisory pop up.

well the movies i have i couldnt playback on my main rig as my x1800xt vcard wasnt hdcp. but after the dump to the HD it plays just fine on the x1800xt :)

so i would say that yes you can play them once on your drive.

[2bigkings]

second try:

hi guys,

first post here.
i don't like this java thing, everytime i try to start backuphddvd it says "unable to access jarfile backuphddvd.jar".
What i have to do? i have jre 1.4.2, jre 1.6.0 and jre 1.5.0.10 but everytime i get the same error. It would be helpful to make a tool without java!
please help me, thank you very much.

regards

[Wookie Groomer]

What are the numbers after each line of the decrypting files when using the utility? I see several screen shots that all have different numbers like in post #666 but mine always say =1 and don't always play properly. For example:

From the example in post #666:
Processing DELOGO.EVO key = 5

Mine will say:
Processing DELOGO.EVO key = 1

Any ideas?

[tonyp12]

[U]i don't like this java thing, everytime i try to start backuphddvd it says "unable to access jarfile backuphddvd.jar".


Are you CD to the directory: backuphdvd/run

I got java to run when I did this:
I uninstalled all versions that was on my computer, downloaded the newJDK 6 (http://java.sun.com/javase/downloads/index.jsp)
Copied the folder
C:\Program Files\Java\jdk1.6.0\jre\bin\server
to
C:\Program Files\Java\jre1.6.0\bin\server

[The_ByteMaster]

I'm a bit surprised that apparently the most successful method for now is a plain memory dump of the running process. Or am I missing something ? What took so long then to have this confirmed ? The creation of a keyfind/test program for the retrieved memory perhaps ?

Taking this one step further, a program that discovers the volume key the way the current compromised program does, by processing the MKB (according to spec but skipping revocation list checks). That way, 'one' only needs to search for new host keys once compromised host keys get revoked.

[2bigkings]

hi tony,

perhaps backuphddvd is only programmed for US-Windows? because my path is c:\programme\java.... (german)
i don't find any SERVER folder!
i start backuphddvd trough "cmd" right?

update: okay i uninstalled all old versions of java, installed the new one (jdk 1.6.0) to c:\program files\ java... i found the server folder and copy it from jdk1.6.0\jre\bin to jre1.6.0\bin but i get the same error.

[evdberg]

I can also confirm King Kong is not decoded properly.
This is most likely caused by the fact that BackupHDDVD only loads titlekeys from VTKF000.AACS. On my European version of King Kong there are 17 VTKFxxx.AACS files. I will check this out further ...

[Mistar Muffin]

As I reported earlier, my feature evo's from King Kong were unplayable in Power DVD 6.5 after decrypting. I'm back to report the same result with Batman Begins. All other evo's are playable, even the mpeg2 special features.

Also, since OverlordQ has modified BackupHDDVD to calculate the SHA-1 itself, would it be possible to have it connect to a site and retrieve the volume keys for that disc (based on the unique identifier of the SHA-1 hash)? I've got a server with a mysql db with a current list of volume keys and it wouldn't be any trouble to write a simple php file to take the hash via url and report the volume key, if anyone is interested.

[He-Man]

Also, since OverlordQ has modified BackupHDDVD to calculate the SHA-1 itself, would it be possible to have it connect to a site and retrieve the volume keys for that disc (based on the unique identifier of the SHA-1 hash)? I've got a server with a mysql db with a current list of volume keys and it wouldn't be any trouble to write a simple php file to take the hash via url and report the volume key, if anyone is interested.
There's already a separate topic discussing web retrieval of keys based ot the hash values:
http://forum.doom9.org/showthread.php?t=120664

[evdberg]

I checked the AACS docs and every playlist (the VPLSTxxx.XPL files in the ADV_OBJ folder) have there own titlekeyfile (the earlier mentioned VTKFxxx.AACS files in the AACS folder). So my guess is that all EVO files that are referenced in a certain playlist must be decrypted using titlekeys from the corresponding titlekeyfile. I am going to verify this further ...

... hmmm, on King Kong the different playlists are just for all different languages. So every playlist references the same files, except for the difference in language (the 1st file). I compared the titlekey files, and they are all the same except for 1 key. BackupHDDVD does not take this into account !!!

[Mistar Muffin]

What effect would this have when using the volume key to decrypt?

[moshmothma]

Could someone please help? I have not been able to get any decrypted discs to play back with powerdvd. I can play the evo file (without audio) but get no response when trying to play a folder from the hard disk. When decrypting the files none of the map files are decrypted. Could anyone help me understand what they are doign iwth the map files? Thanks

[Golgot13]

Could someone please help? I have not been able to get any decrypted discs to play back with powerdvd. I can play the evo file (without audio) but get no response when trying to play a folder from the hard disk. When decrypting the files none of the map files are decrypted. Could anyone help me understand what they are doign iwth the map files? Thanks

Because the ACA file in ADV_OBJ folder is crypted.
If you decrypt it you will can play HD DVD on your hard disk.



Golgot13

[cwm9]

I was trying to look into the nav_chain bug, so I decided to look into the decryption algorithm. I figured that the files is probably being incorrectly decrypted at times. It does seem that the decryption algorithm is pretty simple: snag a NAV_PCK, rip out the title key number, use that key to decrypt anything subseqent that isn't a NAV_PCK.... OR A ADV_PCK. Then I went to look at BackupHDDVD and see if it properly skips the decryption of ADV_PCKs since both NAV_PCK and ADV_PCKs are never supposed to be decrypted. (Is the incorrect decryption of ADV_PCKs possibly the nav chain bug?) I found the patent, but I don't have time to sift through how the software works right now. I did determine that the stream id of ADV_PCKs is 10111111 and the substreamid is 10000000. It's possible this PES&3 code segment makes sure ADV_PCKs aren't encrypted::


public EVOBPack(byte[] rawData){
...
if ((PES&3)==1){
isEncrypted=true;
System.arraycopy(rawData,84,keySeed,0,4);
}
...


I'm not to sure what's in an ADV_PCK, except that it's supposed to hold "extra" information of some sort. Maybe the player his a "decrypted" adv_pck and freaks out because the data is now scrambled... some players crash, other players get choppy as they try to seek through the garbage looking for a place where the data is good again?

Even if ADV_PCKs are being skipped properly, I still suspect the file is not being decrypted properly at all times.

So just to be clear, the existing HDDVDBackup code has a PATCH in it to "fix" (really work around without fixing) the author's so-called "nav-chain" bug, and t's probably this "nav-chain" bug that's causing some discs to be unreadable. (see the documentation that came with the software!)

Most of the details of the format can be found in patent 20060182418 and downloaded complete with images in PDF form from patentreader.com

As I understand it, the author did not actually write the code but rather downloaded the algorithm from already available sources... does anyone know what that source was? Was it copied by hand? Maybe it just has a typo somewhere? Maybe that document has more information of value?

[evdberg]

I never seen an ADV_PCK, so can you please give a hex dump of the first 128 (0x80) bytes? Based on your description above I would say that BackupHDDVD indeed tries to decrypt this kind of block.

[cwm9]

I never seen an ADV_PCK, so can you please give a hex dump of the first 128 (0x80) bytes? Based on your description above I would say that BackupHDDVD indeed tries to decrypt this kind of block.

I wish I could. All of that was based on the sentence "NV_PCK and ADV_PCK are not allowed to be encrypted." found in AACS_Spec_HD_DVD_and_DVD_Prerecorded_0_912.pdf

I did find references to ADV_PCKs in the patent, but the header and subheader IDs were the only thing I could find.

Worse, when I tried to match up the code to the patent, it didn't seem to jive. There's no reference to stream id 0xbb in the patent, but thats exactly what's looked for in the code. (it looks like t and t2 are the packetid and subpacketid but i forget which is which -- and i might be wrong) Also the patent refers multiple packets per pack (at least in one example), but the code assumes only one with a header length of 128 bytes ... and that length doesn't jive with the patent either. Maybe a navigation pack has a specific format that has only one packet in it?

The whole pack/packet thing was a source of confusion for a while. I guess a pack is 2048 bytes long which contains packets of various types.

What's really needed is a copy of the HD-DVD 1.0 spec, but you have to be a DVD Forum member to get a copy.

I'm guessing they probably will be filing an amended patent later with updated information?

I could be way off base here. All of this info is based on sifting through what I could find in just a couple of hours.

[noclip]

I wish I could. All of that was based on the sentence "NV_PCK and ADV_PCK are not allowed to be encrypted." found in AACS_Spec_HD_DVD_and_DVD_Prerecorded_0_912.pdf

I did find references to ADV_PCKs in the patent, but the header and subheader IDs were the only thing I could find.

Worse, when I tried to match up the code to the patent, it didn't seem to jive. There's no reference to stream id 0xbb in the patent, but thats exactly what's looked for in the code. (it looks like t and t2 are the packetid and subpacketid but i forget which is which -- and i might be wrong) Also the patent refers multiple packets per pack (at least in one example), but the code assumes only one with a header length of 128 bytes ... and that length doesn't jive with the patent either. Maybe a navigation pack has a specific format that has only one packet in it?

The whole pack/packet thing was a source of confusion for a while. I guess a pack is 2048 bytes long which contains packets of various types.

What's really needed is a copy of the HD-DVD 1.0 spec, but you have to be a DVD Forum member to get a copy.

I'm guessing they probably will be filing an amended patent later with updated information?

I could be way off base here. All of this info is based on sifting through what I could find in just a couple of hours.

PCKs are described in a good amount of detail in those docs. Look at the section after HD-DVD protection on a medium.

[evdberg]

The code of BackupHDDVD does look specifically for a nv_pck using a number of byte markers. First of all this is not an elegant way of doing it, and second it might be error prone. So if we would actually find a adv_pck in the wild, we can see whether it will be decrypted or not. I was making a small demuxer, so I will see if I can find something. The only problem is that I do not own any of the movies that are mentioned to not work properly.

[noclip]

The code of BackupHDDVD does look specifically for a nv_pck using a number of byte markers. First of all this is not an elegant way of doing it, and second it might be error prone. So if we would actually find a adv_pck in the wild, we can see whether it will be decrypted or not. I was making a small demuxer, so I will see if I can find something. The only problem is that I do not own any of the movies that are mentioned to not work properly.

Look at the docs. PCKs' data is stored in their "unencrypted portion" right on the disk. All BHDVD has to do is not try to decrypt them.

[He-Man]

The only problem is that I do not own any of the movies that are mentioned to not work properly.
But the "Nav Chain bug" is also on all the movies that "work properly" isn't it?

[cwm9]

But the "Nav Chain bug" is also on all the movies that "work properly" isn't it?

Yes. My SWAG is that the ADV_PCK contains "extra" information that may or may not be needed for playing back the film. In the case of ucontrol movies, the extra data might be in the ADV_PCK. If there are references back and forth between the video content and the ucontrol structures, that would cause serious problems if the ADV_PCKs were unreadable. For non-ucontrol films, the extra info just gets lost but it doesn't matter.

Remember: this could be completely and totally wrong, it's just a GUESS at this point.

[Mistar Muffin]

Here is a modified version of BackupHDDVD that will compute it's own hash, thanks to OverlordQ, and then retrieve a key from the online database at http://www.hdkeys.com/

It also writes the key to keydb.cfg for later use.

http://www.hdkeys.com/files/BackupHDVD_HDKeys.com.rar

The syntax it uses to retrieve the keys is as follows:

http://www.hdkeys.com/getkey/hddvd/hash

It then reports:

Title|VolumeKey

Have fun!

[evdberg]

Acccording to the doc, the Advanced packet contains 'specific data structure for copyright protection system' ...

But the "Nav Chain bug" is also on all the movies that "work properly" isn't it?
BackupHDDVD does perform the 'fix' for it on all titles, if that is what you mean. It is corrupting the VOBU_EndAddress by setting the MSB to 0x7F (V0.99 set it to 0xF, but this is ofcourse just as wrong). I have no idea if there is really a 'nav chain bug' !

[rack04]

I'm anxious to try this backup method but I'm wondering how and if I can connect an Xbox HD DVD drive to my PC. My system specs are listed below:

MB: ABIT NF7-S v2.0
CPU: AMD XP-M 2400+ @ 2475
VC: ATI Radeon 9800Pro->XT Cat 7.1 430 mem / 385 core
Mem: PDP PC3200LLK 512mbx2
PSU: Ultra XConnect 500 Watt ATX
HD: 2 x Seagate Barracuda 120.0GB Ultra ATA/100
Optical Drives: BenQ DW1620 Pro and Liteon SOHD-167T
LCD: LG Flatron L17108
Case: Kingwin KT-424-BK-WM
OS: Windows XP Professional w/ SP2