BackupHDDVD, a tool to decrypt AACS protected movies [Archive]

muslix64

27th December 2006, 20:05

The Saga of decrypting an AACS protected movie, by Muslix64.

December 6:

I just bought a HD-DVD drive to plug on my PC, and a HD movie, cool! But when I realized the 2 software
players on windows don't allowed me to play the movie at all, because my video card is not HDCP compliant and because I
have a HD monitor plugged with DVI interface, I started to get mad... This is not what we can call "fair use"! So I
decide to decrypt that movie. I start reading the AACS specification I have found on the net. I estimate it will take
me about 4 weeks of full time job to decrypt that. I was wrong, it was in fact, easy...

BTW, when I disable my HD monitor, I can watch the movie,on my old VGA screen, but, what is the point of having
a HD monitor and not being able to watch a HD movie on it!

December 7 to December 12:

Nothing, I try many things, but I'm going nowhere. I change my technique

December 13:

Now I focus only on title key. I was very surprise to realize that the title key is there, in memory! Can it be
that easy? Around 7PM, I decrypt my first movie "pack". Around 11PM, I have now a totally decrypted movie! But there is
a problem. Frame skipping.

December 14:

After many tests, I found a field in the Nav pack, that fix the frame skipping problem.
Wow! Now I can watch a smooth playback of an HDDVD film that I have decrypted!
After only 8 days of work, I was able to decrypt an HD-DVD movie! What's the problem? There is a major
security problem somewhere.

December 15 and December 16:

I put together a small program called "BackupHDDVD", a java based command line utility to decrypt movies.

December 17:

I made a small video called "AACS is Unbreakable" where you can see the output of the program while decrypting.
You can also see a playback of a decrypted movie.

December 18:

Upload that video on YouTube
http://www.youtube.com/watch?v=_oZGYb92isE

December 20:

Upload the program and source code on RapidShare (V0.99)
http://rapidshare.com/files/8318838/BackupHDDVD.zip.html

December 21:

I want to go further in the decryption, so I decide to track down the "Volume unique key" instead of title key.
I found it also! I'm preparing BackupHDDVD V1.00, that will support volume key and title keys.

December 25:

Merry Christmas!

December 26:

I create a thread on the Doom9 forum about BackupHDDVD. People don't believe it...

strider01

27th December 2006, 21:33

Hi Muslix64... could you please upload this to an alternative download source besides the infamous rapidshare? Unfortunately, I'm not having much luck with it... i just got an invalid download session after waiting 23 mins,,and now it wants me to wait 49 mins...grrrr

bourtzovlakas

27th December 2006, 22:46

Try this one...
http://zavlakas.googlepages.com/BackupHDDVD.zip

CruNcher

28th December 2006, 01:58

muslix64 nice work, but you know as good as me and everyone else (including Hollywood and the Content Industry) here that without a Secured PC Platform it will allways be possible to catch the stuff somewhere. The major error by them was to bring it to the PC in the first place, that way it would have been more likely unbreakable and i don't remember they ever said it's unreakable either.
They wouldn't implement something as the revocation possibility if it was (in certain enviroments), and in terms of encryption their right AES-128 isn't (officialy) broken yet. I just waited for someone to announce this, hehe seems this time it's PowerDVD, last time it was Xings Player :d wonder how fast this will go arround for sure it allready reached Microsoft and Toshiba by now :D

Ah and a late Merry Christmas too everyone and thx for your efforts keeping the Fairuse Balance, god bless ya :)

Adub

28th December 2006, 02:20

I like your journal. And good idea about the Xbox 360 drive.

appleguru

28th December 2006, 04:14

Now just make me a mac version and I'll be happy (actually, it's java.. so I guess I need UDF 2.5 drivers for os x...)

XStylus

28th December 2006, 05:20

Make sure you've taken appropriate measures to protect your identity, muslix64. You've done great work, and I'd hate to see you become another victim in the DRM battle.

IMO though, you should've sat on this fix a bit longer. HD-DVD is still in first gen with little market penetration, so it's not too late for them to tweak the HD-DVD spec. Or worse, the studios could jump ship and go Blu-Ray exclusively. Wait until one of the formats hit a penetration point to where there's no return, then drop the bomb.

But anyway, what's done is done, and I hope this fix stands the test of time. If so, I know what format I'm buying.

Time to tinker with Blu-Ray anyway though, just to make sure the studios don't have anywhere to run. I'd buy you a Blu-Ray drive for the effort if I had the money.

Deihmos

28th December 2006, 06:17

This is interesting. Was it wise to put this video on youyube? How long would it take for a law suit to be filed? I totally agree with XStylus..this could cause many studios to jump ship from HD DVD and sign up for blu ray as it has two layers of protection. Thanks a lot.

djdafreund

28th December 2006, 06:22

Hey thanks SO much muslix64!!!!!! My friend just bought an XBOX HD-DVD drive yesterday when i was over there, and watched some 'Full Metal Jacket' and some 'King Kong'. THe Fullmetal Jacket wasn't so much WOW as it IS an old movie (Albiet a really good one!)
But he had the original dvd to compare, and still see a nice difference in quality either way. The King Kong was much better of course, Kongs hairs blowing in different directions, so sharp in detail.
I was just telling him yesterday while messing around with things, "I betcha someone will crack it and make it possible to copy it pretty soon already." Boy, your fast though!!!!!!!!!

Thankx SOOOO much, as i might be getting one soon myself now after seeing the quality of them, and i get HD-DVD's through work and such. Can't wait for the Jan. 2nd version!!!

Thanks for the hint at the end of the video ;-)

Deihmos

28th December 2006, 06:24

supposedly the decryption keys come off the disk. well actually they are encrypted, but when played the keys are decrypted, the rest is kind of left a mystery by the author. Let's see what happens on January 2nd.

I think he gets the keys from powerDVD. I am sure they will get some heat because of this.

hajj_3

28th December 2006, 06:30

Yes, protect your identity and IP. use proxies, firewalls etc etc.

dont release loads of versions, wait until your next version you release is perfect. the less releases the less likely you will be caught, we dont want you being sued for $10m.

Keep up the great work, i wouldnt have shared the source code just yet as they can change the code in future players and discs to stop this. i would have just created the code and then in 6 months release the code when hd-dvd players are more standard and more titles are out.

I'd delete the link to the sourcecode, ask people to stop sharing it and just release the executable for the time being we want as many hd-dvd's ripped and put out by the scene as possible.

please can you show some screenshots off the directories as your video showed a movie file that was about 4gb, unless its really short like a "making of" then surely a movie would be 10gb+.

this guy has done some serious coding!!! even the documentation is nice:)!

I could see hd-dvd getting hacked to death like the 360 firmware, once the hack has been released into the wild load of others will disect and improve it, this could be the next smartripper:)! hope slysoft anydvd incorporates some of this:)

thanks alot, keep up the FANTASTIC WORK!!!

Devinator

28th December 2006, 06:47

Make sure you've taken appropriate measures to protect your identity, muslix64.

I agree. Not only would the people behind draconian copy protection BS sue you, they would disapeer you if they thought they could get away with it.

hajj_3

28th December 2006, 06:53

I agree. Not only would the people behind draconian copy protection BS sue you, they would disapeer you if they thought they could get away with it.

they could then make a movie about it, maybe something along the lines of "Leon The Professional".

CruNcher

28th December 2006, 07:07

I'd delete the link to the sourcecode, ask people to stop sharing it and just release the executable for the time being we want as many hd-dvd's ripped and put out by the scene as possible.

:eek: :eek: :eek:
that's maybe what you wan't, but definately not the author of this decrypter or anyone else here on doom9.

and about the "protect your id thing" why should he, he did nothing wrong and nothing the industry didn't except to happen.
And everyone involved in AACS knew this would happen, their is no way to protect against such stuff on the PC Platform as we have it today, see all the HD-DVD/Blue-Ray Player and PS3/XboX 360 those are Platforms that can be called Secure but the PC isn't yet but industry is working on it to make it more Secure the first steps are made TPM 1.2 and Vista more will follow in the Future.

hajj_3

28th December 2006, 07:16

:eek: :eek: :eek:
that's maybe what you wan't, but definately not the author of this decrypter or anyone else here on doom9.

and about the "protect your id thing" why should he, he did nothing wrong and nothing the industry didn't except to happen.

i think their lawyers would disagree!!! the industry has accepted it will be cracked, however its still illegal and they will indeed hunt him down.

i dont want this guy to end up in jail for 5yrs, he's done a great job:)

djdafreund

28th December 2006, 07:32

I love it. It IS 100% LEGAL (Read you lawbooks on this!!!) to make a COPY of media you OWN (Reason why he did this, as he said, the media is VERY touchy to scratches.) "An individual is allowed to make 1 copy, per for archive purposes, of the media he owns. You, however, are not allowed to sell the copy, per said, for profit. "

It is the same reason ALL the dvd copy (ALL LEGAL) software, as well as all CD backup software/Music CD backups, Audio rippers to devices ('Because you own the original' in there eye's).

It's irritating to still watch people "Eh-eh-it's against the law!!" when they clearly don't understand the law one bit and THINK by assuming what they hear or there own believe's. I've actually asked the written law with my lawyer and how it's translated by definition in the courts systems. And more or less said the same thing i researched on the internet myself. I would agree to not post the source, so they don't learn so quick their mistake's however, and keep it the execution file/docs only.

Moves to rein in the DMCA have been initiated in the U.S. Congress, where at least two bills have been introduced that grant exemptions for consumers who crack encryption for certain legitimate purposes--for example, to make a backup copy of a legally purchased DVD.

daddy_fizz

28th December 2006, 07:43

Yeah, because it turned out so good for Lightning UK when he didn't release the source code and they came after him for DVD Decrypter...

I would take the advice to play it safe and do what you can to protect yourself, and get that source code spread across the net as far as it will go...

~Fizz

XStylus

28th December 2006, 08:46

Moves to rein in the DMCA have been initiated in the U.S. Congress, where at least two bills have been introduced that grant exemptions for consumers who crack encryption for certain legitimate purposes--for example, to make a backup copy of a legally purchased DVD.

Sure, whatever, that's nice. But until those bills are passed though, breaking a copy protection measure--even for the purpose of asserting a perfectly legal right--is illegal and punishable by prosecution. Thus, heroes the likes of DVDJon and now muslix64 need to make sure their identities are protected. The two **AAs have been churning out lawsuits against good people for a couple years now. It's easy for them to get YouTube or some other site to cough up an IP addy on this guy.

I'm also doubtful those bills you speak of (assuming they are reintroduced when the new congress convenes) will be passed anytime soon. Past history has shown congress to be very friendly to the media industries. For example, it's the US that is holding back Russia's entry into the WTO, and AllOfMP3.com's existence is cited as a primary reason.

OverlordQ

28th December 2006, 08:54

I think he gets the keys from powerDVD. I am sure they will get some heat because of this.

the 'nice' thing about ACSS though is they can revote PowerDVD's current key which will not allow any future media to be decrypted w/o updating PowerDVD :)

XStylus

28th December 2006, 09:17

the 'nice' thing about ACSS though is they can revote PowerDVD's current key which will not allow any future media to be decrypted w/o updating PowerDVD :)

If I understood correctly, the Title Keys were yanked from active memory, which would render revocation of PowerDVD's key moot. The player's key decrypts the encrypted title key which is the key needed to decrypt the video (somebody correct me if I'm wrong here).

Hence, if all you need is a way to yank the Title Keys, What's to prevent the next version of PowerDVD (or any software player, for that matter) from falling to this same tactic? They could also try to deauthorize the old software players and find some way to scramble the title keys in memory on the next versions, but reverse engineering the software itself to find the scrambling method will reveal those keys once again.

However, even if they do decide to go to an extreme and yank software players off the market (at least, for any OS other than the ass-puckered WinVista64), I could easily see someone cracking open a perfectly good HD-DVD player, probing the memory, and just create a list of HD-DVD keys that gets posted to some online website. The only trick is that you'd need to keep REAL QUIET on what players you're modified to pull title keys from.

That obviously would make it difficult for just anybody to make their own keys, so I foresee key distribution as the next big craze. This would relegate disc backups to an as needed sort of thing. You can back up a disc you bought if you really want (if, for example, you want to watch a movie on your laptop but prefer to leave the disc at home), but you'll need to go online and hunt down a key first.

Nocturno

28th December 2006, 09:59

hajj_3

28th December 2006, 10:18

Actually in large parts of Europe it's not illegal to make a copy for home use, but it IS illegal to break copy protections, even on your own bought movies, therefore usage of this tool is illegal imho

EXACTLY. in the u.k the DMCA (digital millenium copyrights act) forbids circumventing copy protections. im pretty sure there is a law for the u.s too. if it dosent have a copy protection on a disc then you can indeed make 1 copy (aslong as you keep both of them and not transfer to a 3rd party).

cant remember what the U.S law is for this as im from the u.k.

i really hope a GUI of the 2nd jan of this tool is made, GUI's for the win:)!

blutach

28th December 2006, 11:50

Let's please focus on the technical and practical aspects of this exciting new program rather than debate legal issues in different jurisdictions.

Thanks folks and thanks to muslix64

Regards

fairyliquidizer

28th December 2006, 11:51

EXACTLY. in the u.k the DMCA (digital millenium copyrights act) forbids circumventing copy protections. im pretty sure there is a law for the u.s too. if it dosent have a copy protection on a disc then you can indeed make 1 copy (aslong as you keep both of them and not transfer to a 3rd party).

cant remember what the U.S law is for this as im from the u.k.

i really hope a GUI of the 2nd jan of this tool is made, GUI's for the win:)!

The US Law is the DCMA. Are we not governed by the Copyright, Designs and Patents Act 1988 in the UK? Is there a newer one that gives DCMA like restrictions. If so what is it?

Just found this looks like you may be wrong in name, right in principle: http://www.out-law.com/page-4168

dukey

28th December 2006, 12:09

should have posted the source from a internet cafe or library or something. Then don't have to worry about getting caught by IP/ISP :) But legal or not it doesn't make much difference because people will do it regardless.

bob0r

28th December 2006, 12:13

bcrabtree

28th December 2006, 12:25

For those who may get this error:
Error: no `server' JVM at `C:\Program Files\Java\jre1.5.0_10\bin\server\jvm.dll'.

do this:
copy
C:\Program Files\Java\jdk1.5.0_10\jre\bin\server
to
C:\Program Files\Java\jre1.5.0_10\bin\

Backup HD-DVD V0.999 Starting
Usage: BackupHDDVD SourceDrive Destination_directory
Example: BackupHDDVD f: e:\movie\somemovie

Download JDK from:
http://java.sun.com/javase/downloads/index_jdk5.jsp
JDK 5.0 Update 10 is what i used (full offline version)

bob0r,

Am I correct to take your posting as confirmation that you've used this tool and that it works?

Can anyone else confirm that they've successfully saved an AACA-protected movie to hard disk and then been able to play it from there?

Bob C

Taktaal

28th December 2006, 12:45

The Java source code is only an implementation of the AACS decoder which in itself is only a wrapper around AES. It looks like the OP found a way to take the title key through out of a HD-DVD player through reverse engineering, but he can't tell us because if the movie studios know which player has a weakness they'll revoke its player key.

It's much better to wait with that until after there's more HDDVD/Bluray releases because then doing a key revocation would
a) Be much less useful because there's already more movies out
b) Create more resentment towards movie studios among the consumers if they can't play a newly bought movie because their player was cracked

chadamir

28th December 2006, 13:15

It's nice to see that every lawyer who ever registered an account on doom9 in the last 4 years is coming out of the woodwork to give advice to this guy.

Cyberace

28th December 2006, 13:59

It looks like the OP found a way to take the title key through out of a HD-DVD player through reverse engineering, but he can't tell us because if the movie studios know which player has a weakness they'll revoke its player keyhmm, but if that player is a software player like PowerDVD, (like version 6.5 which is shown in the YouTube video)- then aren't studios are out of luck as people will always be able to install that exact same 'old' version of the software player on their own computer that is not connected to the internet (and can thus not get revoke updates) and thus use that to grab the keys from the RAM memory when it is playing/decoding the movie?

By the way, did any notice that YouTube video shows the title keys of some movies when he films the contence of his TKDB.cfg file? if those are the real keys, then people with the knowledge and software to scan/dump the active RAM memory should be able to search find one of those specific keys if he/she have one of those exact same movies, and then he/she can use that as a map to find the location where keys of others movies are 'stored' in the memory while the movie is being played/decoded by PowerDVD. As I assume PowerDVD always stores that key in memory the same way in the same version of the software?

AlphaWolf

28th December 2006, 14:03

Sure, whatever, that's nice. But until those bills are passed though, breaking a copy protection measure--even for the purpose of asserting a perfectly legal right--is illegal and punishable by prosecution. Thus, heroes the likes of DVDJon and now muslix64 need to make sure their identities are protected. The two **AAs have been churning out lawsuits against good people for a couple years now. It's easy for them to get YouTube or some other site to cough up an IP addy on this guy.

I'm also doubtful those bills you speak of (assuming they are reintroduced when the new congress convenes) will be passed anytime soon. Past history has shown congress to be very friendly to the media industries. For example, it's the US that is holding back Russia's entry into the WTO, and AllOfMP3.com's existence is cited as a primary reason.

It could happen. Over the years there have been more and more exceptions being added to the DMCA.

FWIW the DMCA is not something that the US congress wanted per se, at least not in the lobbying sense. The reason we have the DMCA is to be in accordance with the WTO and WIPO treaties. In fact when that and the CTEA were challenged by Lessig and his crew, the supreme court cited these treaties as the reason for justifying these laws as being constitutional, because the constitution says that treaties are the law of the land.

The US happened to be the first country to adopt the policies of these treaties in the form of the DMCA and the CTEA. Because of this many people on the internet go around blaming the US for being the reason that their country adopted similar, often more restricting copyright laws (I know many aussies that do this especially.) This isn't the case actually. These countries are enacting these laws as part of these treaties as well. In fact if you look at the tenets of these treaties, they call for far more restrictive policies than what the DMCA calls for.

Whenever you see some trolling site like slashdot or something mention that some country is enacting a new "Super DMCA" it is actually that country falling more in-line with the treaty than the US is.

If you ask me, eventually the DMCA will eventually boil down to this: don't decrypt or talk about decrypting any content unless there is significant fair use for doing so. E.g. backing up a DVD would be allowed, but stealing cable by decrypting the signal without authorization wouldn't be. Which I think would be very fair.

IMO though, you should've sat on this fix a bit longer. HD-DVD is still in first gen with little market penetration, so it's not too late for them to tweak the HD-DVD spec. Or worse, the studios could jump ship and go Blu-Ray exclusively. Wait until one of the formats hit a penetration point to where there's no return, then drop the bomb.

But anyway, what's done is done, and I hope this fix stands the test of time. If so, I know what format I'm buying.

Time to tinker with Blu-Ray anyway though, just to make sure the studios don't have anywhere to run. I'd buy you a Blu-Ray drive for the effort if I had the money.

IIRC doesn't blu-ray also use AACS?

In either case I don't imagine it mattering much. No form of video media will ever have a renewable security system, period. With that said, once it has been decrypted, its all over. Whether it happens now or later, it makes no difference in the end. Maybe a little more effort on the part of the crackers and content providers, if that. The AACS standard is for the most part set in stone already, and as we sit, it's mostly broken.

Mostly as in, we still need to obtain some decrypt keys before we can fully decrypt the video.

hajj_3

28th December 2006, 14:12

also, i hope a non-java version of the 2nd jan version is released. lots of ppl dont want to install java runtimes, if sourcecode for that is released then im sure someone will port it into c++ with a GUI.

=A=RGOS

28th December 2006, 14:31

The licence GPL may be add to this source code and a sourceforge project may be add for future contribution.
The C++ port is intersting but not GUI, the compatibility with linux may be possible for linux player and eventual libdeaacs.

sorry for my little english ...

0xdeadbeef

28th December 2006, 14:47

Some thoughts on this:

1) The player key was not yet compromised as far as I understand. Also the authentification mechanism was not found and recreated. Both should be possible by reverse engineering the software player, but it's not done yet and thus currently HD-DVD can't be called "hacked" yet IMHO.

2) As far as I understand, the player keys can be backlisted this way or the other. There is even a mechanism for this for normal DVDs - where all valid player keys are stored on each DVD. This mechanism was most probably improved for HD-DVD and BlueRay, so I guess as soon as the PowerDVD player key is compromised, it will be backlisted. Maybe even earlier, if a way is found to remote control PowerDVD to provide people with title/volume keys.

Anyway: very interesting topic, especially since this would allow many users to use their notebooks without HDCP to playback HD-DVDs on highres beamers and displays.

DeepBeepMeep

28th December 2006, 14:49

hmm, but if that player is a software player like PowerDVD, (like version 6.5 which is shown in the YouTube video)- then aren't studios are out of luck as people will always be able to install that exact same 'old' version of the software player on their own computer that is not connected to the internet (and can thus not get revoke updates) and thus use that to grab the keys from the RAM memory when it is playing/decoding the movie?

The studio may able to prevent existing titles to play with the compromised Dvd Player even if no upgrade is done through the internet. Indeed each device that participates in the AACS decoding is supposed to keep a revocation list. This revocation is updated whenever a new title is played.

So let's say you play a movie in the future that has blacklisted the software player. From this moment your HD DVD drive will refuse to communicate with the software player even to play old titles.

Now even if you prevent your Hd Drive from updating its revocation list with some form a reset, although old titles may still work, newer titles won't because they will no longer contain a valid device key which is required by the player.

By the way, did any notice that YouTube video shows the title keys of some movies when he films the contence of his TKDB.cfg file? if those are the real keys, then people with the knowledge and software to scan/dump the active RAM memory should be able to search find one of those specific keys if he/she have one of those exact same movies, and then he/she can use that as a map to find the location where keys of others movies are 'stored' in the memory while the movie is being played/decoded by PowerDVD. As I assume PowerDVD always stores that key in memory the same way in the same version of the software?

It seems the code we can see is in the video are only hash values of titles names, the title keys are obviously hidden behind a black box.

colinhunt

28th December 2006, 15:05

ttringle

28th December 2006, 15:16

If this does work, then it's only probably going to end up killing HD-DVD, unless it does also work on Blu-Ray which I doubt because Blu-Ray has an extra level of Copy Protection that HD-DVD does not. If that is the case then the studios will NEVER switch over support to HD-DVD no matter how many people buy discs.

Still I hope that this is true and that it does work for HD-DVD, because whether or not they like it the reason that DVD is as popular as it is has to do with the fact that for the last 5 years we have been able to do what we want with our DVD's. Without the ability to decrypt to HD or on the fly you wouldn't be able to stream video to another room off your HTPC playing a DVD etc, or from your 1st Gen XBOX.

TimT

Dr Cain

28th December 2006, 15:18

I tried this, and it didn't work. The config file has keys for a few titles, but there's no way to tell if the titles are US or European discs. Tomb Raider (US) did not work, got 18GB of crap on my HDD.

You'll still need to extract the key manually from memory in order to decrypt it.

The source code comes with all keys nulled.

EDIT: typed the wrong thing X_x

colinhunt

28th December 2006, 15:21

You'll still need to extract the key manually from memory in order to decrypt it.

The source code doesn't come with all keys nulled.
You mean it comes with all keys nulled? Took another look at the keyfile, and sure enough, the actual keys are all nulls. D'oh.

DeepBeepMeep

28th December 2006, 15:24

I tried this, and it didn't work. The config file has keys for a few titles, but there's no way to tell if the titles are US or European discs. Tomb Raider (US) did not work, got 18GB of crap on my HDD.

It doesn't look like what has been released contains any title key. It seems the title key has been delibarately replaced with "1-00000000000000000000000000000000". I think title keys are supposed to be "copyright information" and the lack of them in the code "may" protect the author since what has been provided so far is only a AACS decoder which still needs the right keys to work. No reverse engineering was necessary to write this code, all the information to write it is available publically.

The real exploit lies in extracting the title key from the memory of the software player. It is quite likely that if we had one title key it shoudn't be hard to get the others as long as the player is not considered as compromised. But unless the author of this program releases the key extractor or that somebody else writes ones knowing now that it is possible, beside greater hope we are almost at the same point as before.

zeroprobe

28th December 2006, 15:32

what it comes down to the "players" key in question is able to decrypt ALL of the hddvds out there today. Future ones can be barred out but for the 150+ out today the keys will work.

Wilbert

28th December 2006, 15:34

The reason we have the DMCA is to be in accordance with the WTO and WIPO treaties.
Yeah right (assuming you are talking about US DMCA). You are turning things around. The reason that we have that stuff in the WTO and WIPO treaties in the first place is because US pushed for it.

It doesn't look like what has been released contains any title key. It seems the title key has been delibarately replaced with "1-00000000000000000000000000000000".
In a \. post about this subject someone claimed that those keys are released into the wild, so you should be able to find them.

Susana

28th December 2006, 15:37

With keys or without keys, :thanks:

Gradius

28th December 2006, 15:38

1st of all, congratulations to muslix64 for this (yeah, kinda same way as xing player was w/ DVDs).

But I totally aggree with 1st XStylus's post, this stuff was too soon to be released to public/masses, the best way was to wait more 2 years to release this, but yeah, what is done, is done.

Keep in mind to clean up all your cache around, even change your ISP, etc, etc, and good luck with your identity. :thanks:

Hollywood and other EVIL guys think, in a digital world, something will be 100% unbreakable, in reality they're as stupid as they can be. They keep themselves busy to find new ways to protect your sh** while forget to provide us GOOD stuff to market (at fair price of course), so good that I'll BUY them, and not just to try to make a mere copy.

But fell sorry for them, after all, they're VERY poor doing just $1 trillion/year. :rolleyes:

Btw, Blu-ray is the next target! ;) :p

PS: About the upgrade stuff, just keep the good old ones working. ;)

BUZZARD1

28th December 2006, 15:49

Good job man. Forget them people telling you that it was a bad idea to release it when you did ect. ect. Some people cant be pleased no matter what. I do hope you protect your identity cuase I would like you to stick around. Keep up the good work bro!

cwm9

28th December 2006, 15:50

I don't think this is going to affect the studios one whit.

Consider who DRM is really aimed at:

In the end, no matter how good the encryption, you can always crack open a TV and wire up an analog to digital converter directly to whatever outputs are driving the pixels on the display. Do it with high enough quality ADCs, and the capture will be nearly perfect. Once you've done that, it's a simple matter of streaming the data to a very fast hard drive array and then re-compressing it. Too much work for the average joe, maybe, but not too much work for a dedicated counterfeiter that intends to make 100,000 units and make a $300K profit. Yes, but what happens when the counterfeiter's player keys are revoked, you say? If you're making $100K+ from each title you counterfeit you throw away the player with the revoked key and buy a new one.

Thus, this exploit really means very little to a determined counterfeiter.

So if the DRM wasn't meant to stop a determined counterfeiter, then who was it meant to stop? Probably the average joe. And if that's the case, this hack probably won't mean much. Why? Think about what the studios really want... They want piracy to go away, obviously. But if you can't have your wish, what's the next best thing? To reduce it, of course.

The goal of this DRM is to make it more difficult for the average joe to copy his friends movies. With DVDs, you can download DVDShrink which "just works" pretty much all the time. That was a disaster for the studios because once someone was shown how to copy a DVD one time, they had no problem doing it over and over.

But there will (probably) never be such a solution with HDDVD because of the way keys are distributed. Sure, you'll be able to download the most current Title Encryption Key database that contains every key known to date, and there will probably be newsgroups dedicated to keeping up with the latest 0-day exploit, but a very large percentage of people who now copy DVDs will not be able to keep up with these tit-for-tat exchanges between the crackers and the publishers. They'll get shown how to copy an HD DVD by someone, and they'll be able to copy any HD DVD that was released prior to that date, but they won't know where to go to update their software with the latest keys or exploits needed to copy title released AFTER that date.

If instead of having one icon that you click on you have to go searching for the latest exploit on Google, that's a win for the studios because ANY added complexity to the process of piracy necessarily excludes those people without the skills to overcome that added complexity gap.

How much of a dent in piracy would it take for the studios to be happy? 5%? 10%? I doubt very much the studio executives ever expected this to make piracy go away forever. I do think they are hoping to see a small decrease in piracy because of it.

Blu-Ray is just as vulnerable to the FET-Driver to ADC hack as HD DVD is, so it wins no points there. Will it make a difference that the "advanced joe" can't copy Blu-Ray? Maybe. Hard to say.

I don't think studios will be jumping ship over this because I imagine they fully expect Blu-Ray to fall to the exact same kind of exploits. Blu-Ray also has a standard encryption scheme, and it's keys will likely be exposed by a bad Blu-Ray implementation as well. What's the point in spending all that money to convert?

Blu-Ray has has the ROM Mark -- but it's a pseudo advantage. If a title is released on Blu-Ray and counterfeiters capture the output via any exploit, they might not be able to release their re-compressed version on Blu-Ray, but nothing prevents them from pressing the exact same re-compression on HD DVD.

So if the watermark can't prevent the distribution of movies, what can it do? It's really only effective for one application... games for the PS3, which only uses with Blu-Ray. Given the PS3s lackluster acceptance, one has to wonder if that means anything anyway, and even if it does, we all know there are hackers out there hard at work trying to find a hardware mod exploit to circumvent that DRM too.

Blu-Ray's one real advantage is BD+ which lets them change the encryption method from AACS to something else.... but what are they going to replace AACS with? As far as I know, there is nothing better than AACS that could be used to replace AACS. It will probably be at least a year before they do have a decent replacement that COULD be deployed via BD+, and I'm not sure what they can come up with that doesn't involve some sort of key that can be revealed by faulty software just like AACS and DVD has.

In summary, no matter what you do as a studio -- release on HD DVD or Blu-Ray -- some professional counterfeiter can hack open a TV, digitize the output, re-compress the movie, and release the title on HD DVD (or dvd, or super-dvd, or whatever.) Because the profit margin is so high, they could afford to trash their revoked player and buy a replacement for every movie if they had to. Every (smart) studio exec knows this; there's no reason for them to bail out just because of this. The "average joe" is probably screwed by either DRM even if this exploit turns out to work. The "advanced joe" will probably still find a way to copy movies. Overall, the best the execs can hope for is a small reduction in "average-joe" piracy which might or might not translate into a small boost in sales, which, over the next decade, might eventually amount to something more than a hill a beans after paying for the development of the DRM.

You know what I really think? I think some of the less knowledgeable suits at the studios wanted a pipe dream, and I think some engineers were more than willing to be paid to work on that pipe dream. If someone waves money in your face and asks you to do the impossible, what's a man to do but take the money and do his best?

BUZZARD1

28th December 2006, 15:55

Logik

28th December 2006, 16:24

very :cool:

0xdeadbeef

28th December 2006, 17:06

Well, worst case scenario would be:

- Compromised software player ist blacklisted immediately, so it won't be possible to extract title/disc keys with it any more as soon as the revocation list entry is activated.

- HD-DVD/BlueRay-Support for XP is generally cancelled. Player software will only run on Vista with fully AACP compatible hw/sw chain.

- Vista's new content protection functionality could make it really hard to read out more title/disc/player keys.

- Since no fast attack on AES is known (as it is for CSS), it will be impossible to decrypt HD-DVDs without valid keys.

One could imagine a way though to circumvent AACP without breaking AES: if the firmware/hardware of the HD drive could be altered to NOT update/use the revocation list, even a blacklisted player could be used as "zombie"-application to read out disc/title keys. Indeed only a few altered drives would have to exist to create a database of keys. Hosting this database would be a legal problem though. Then again, if there are countries which assume hosting of torrent hashs legal, there should be some which consider hosting decryption keys to be ok.

Just my 2 cents though.

TehMark

28th December 2006, 17:14

TYVM!! I love this community!

drbuzz0

28th December 2006, 17:16

Some observations:

1. A lot of people have been saying AACS is the end of backing up your media. They claim this because of all the measures against it and how the devices are updatability and keys are individual per movie. I've heard this all before (many times). Any protection system is only as strong as it's weakest link, if a system uses a crazy-secure rolling-key 512bit encryption algorithm, that does not mean the system is necessarily secure if there is a backdoor method of telling it that you are authorized. Example would be Nagravision, a satellite encryption that was hacked to pieces by figuring out how to fake being authorized. The more complicated a protection system is, the greater the chances that there's a weakness in it somewhere.

2. Having keys which need to be obtained or distributed is not that big a problem. Remember that it only has to be figured out once, whether by sniffing, leaking or even brute force... only needs to be done ONCE and then it's out. The studios can keep changing the key, but there are limits. Again using the satellite comparison, a while back distributing "seed codes" was how the Videocipher was hacked. They never really managed to close that hole until they completely redid the hardware.

3. AACS can be updated, but there are limits. It can only be updated to a certain degree, legacy support has to be maintained and there is a need to keep ontop of things. It's much like software protection. It's damn near impossible to keep a piece of software truely secure. As soon as it gets out the cracks and keygens start popping up left and right. The more popular the software, the faster it happens.

4. The DMCA is something I do not worry about. It's not a law, because it's an *ILLEGAL LAW* That is, it is superseded by the US Constitution and International principals of expression.
Gahndi said something like (to paraphrase) "To break an unjust law is a crime against the government. To follow an unjust law is a crime against justice and the human spirit."

This law is not valid. It is unjust and illegal. It may not have been struckdown (yet). But recall Dred Scott.

My sincere hope is that AACS weaknesses are not confined to underground discussion and groups. I hope that it will eventually end up like CSS and other DVD protection methods. I think at this point there's no point in trying to protect DVD's and crack down on DeCSS/DVD43/DVDDecrypter. The protection has been hacked to pieces. The cats out of the bag. It's something they have to live with and they have decided that they won't make the same mistake with AACS. Looks like maybe they have though :-P

nonphixion

28th December 2006, 17:27

First, great job on this.

Second, i am receving an error when running the app.

C:\hd\backuphddvd
Error occurred during initialization of VM
Unable to load native library: The specified procedure could not be found

java.exe gives the err "The procedure entry point _JVM_GetClassConstantPool@8 could not be located in the dynamic link library jvm.dll

i copied jvm.dll to the dir specified in the earlier post, and i get the first error. Any ideas?

0xdeadbeef

28th December 2006, 17:47

My sincere hope is that AACS weaknesses are not confined to underground discussion and groups. I hope that it will eventually end up like CSS and other DVD protection methods. I think at this point there's no point in trying to protect DVD's and crack down on DeCSS/DVD43/DVDDecrypter. The protection has been hacked to pieces. The cats out of the bag. It's something they have to live with and they have decided that they won't make the same mistake with AACS. Looks like maybe they have though :-P
There are two fundamental differences between CSS and AACS.

Firstly, CSS used a positive list of player keys, which has proven to be an error, as nearly all of the 408 supported player keys were published shortly after the first player key was compromised. AACS uses a negative list - this mechanism could only become useless if hundreds of player keys were compromised, which could only happen in a few years as there only a few players on the market right now. While for hardware players, this is still problematic, this is a nearly perfect solution for software players as they can just blacklist any compromised player and force the users to update their software.

Secondly, the encryption algorithm of CSS was flawed in a number of ways. In contrast to this, AES (used by AACS) is a pretty secure algorithm. In the last few years, several apporaches were discussed how to break a key faster than using a brute force attack. Then again until know, it's unclear if any of the suggested attacks could even be theoretically faster than a brute force attack. Don't get me wrong: as with most (if not any) other encryption scheme, some mathematician could come up with an algorithm tomorrow to break AES in a few iterations. However, this could also take until 2030 or may even never occur.

Deihmos

28th December 2006, 17:51

Did anyone confirm this working? It does not look that way so is this a hoax or is it real?

Sirber

28th December 2006, 17:59

look at page 1, it's for real.

Malow

28th December 2006, 17:59

Did anyone confirm this working? It does not look that way so is this a hoax or is it real?

just wait a few hours, someone in 2,710 user acessing this forum now, should have an xbox hd-dvd drive and some disks... ;)

edo1080

28th December 2006, 18:04

Hi, I posted a topic moths ago about D-Theater backup, and now all is almost done. I'm programming an FPGA and hope to be able to backup on HDD drive all my D-Theater tapes in one or 2 weeks.

I've tested this program and seems working, I obviously have to find a way to find the keys in memory. Maybe a way like to UN-DRM the old WMV-HD discs? In that case also the key was recovered from memory and dumped on an file on HDisk dirve

DVDCake

28th December 2006, 18:20

Howdy all,

The xbox hddvd drive works great on the 360, bought one for my Pop. AMAZING news that the ball is rolling on backing up HDDVDs! I'll pick on up this week to connect to my PC to see what this thing is all about.

To continue the tech discussion, what's known about the file format for HDDVD? Those files we saw on the youtube video, any way to analyze them to find the main feature A/V components?

Maybe I’m jumping the gun here, I feel like a kid with my face pressed up against the window of toy store =]

I’ll post anything I find once I get the xbox drive.

~DC

Deihmos

28th December 2006, 18:25

look at page 1, it's for real.

The person from the first page isn't the author? I meant if anyone else confirmed it working. I read many forums and no one got it to work.

Nic

28th December 2006, 18:35

It's very hard for anyone to actually test the software decrypts a HD-DVD as no decryption keys are available with the software. Someone would need to reverse engineer a key (perhaps from software such as Power DVD 6.5).

However, his story and code appear very plausible and at present there is no reason to believe this is a hoax. If it is a hoax, it is a very good one.

-Nic

monkeycz

28th December 2006, 18:50

wonderful!

Malow

28th December 2006, 19:12

It's very hard for anyone to actually test the software decrypts a HD-DVD as no decryption keys are available with the software.
-Nic

and the keys in the file tkdb.cfg?

EDIT: oops, my mistake. there are no keys, just example of code to identify the hd-dvd i guess..

0xdeadbeef

28th December 2006, 19:19

In the version linked to in this thread, there are only hash values and blank keys. It's however said that there's a version out there with valid keys. Can't confirm though.

ChronoCross

28th December 2006, 19:57

The source code basically shows that you need to manaully enter the keys into a list. You can get them because the DVD software leaves the key resident in memory. So it's not actually breaking the protection it's simply using a legal key to decode the video. AACS will simply change the decryption key and this software won't work once the patch is introduced to the HDDVD player that has this leak.

Efficient program for ripping too bad it's a little over exagerrated in what it actually does.

Krawhitham

28th December 2006, 20:14

The source code basically shows that you need to manaully enter the keys into a list. You can get them because the DVD software leaves the key resident in memory. So it's not actually breaking the protection it's simply using a legal key to decode the video. AACS will simply change the decryption key and this software won't work once the patch is introduced to the HDDVD player that has this leak.

Then the cat & mouse game begins, they release new players that store the key differently and hackers figure out how to get the key from memory each time

SeeMoreDigital

28th December 2006, 20:31

Then the cat & mouse game begins, they release new players that store the key differently and hackers figure out how to get the key from memory each timeWell if the consortium behind the HD-DVD format were dumb enough to allow the manufacture of HD-DVD drives and the creation of software players for use in PC's... what did they expect was going to happen ;)

I bet they wish they had confined the release of HD-DVD to "stand-alone" players only!

Looks like it might be worth getting an external HD-DVD drive (for the Xbox 360) after-all.....

bagel

28th December 2006, 20:40

Dia de los Santos Inocentes ?

I hope not...

Solo

28th December 2006, 21:32

mmm looks promising ....

At least I won't have to replace my expensive 24" LCD screen + non-HDCP GFX to watch future HD-DVD movies.

I have a feeling there is going to be an increase in HD-DVD drive sales soon ;)

Adub

28th December 2006, 21:36

I wonder how DVD Jon will react to this? Do you think he will take it and run? As in, make it better?

So far there is no word on his site, the last post was on december 1st. I can't wait to hear what he says.

Edit: did anyone else notice the black bar in the youtube video when the camera scans over the tkdb.cfg file? It seems the author was being safe, as he doesn't release the keys themselves, so technically he is not doing anything wrong. It is the next step that may be considered illegal.

zeroprobe

28th December 2006, 21:37

Has anyone actually tried doing anything with powerdvd yet?? If I had the drive I would be playing already.

Cant be that hard find if the key is decrypted somewhere.

edo1080

28th December 2006, 21:40

zeroprobe

28th December 2006, 21:42

OverlordQ

28th December 2006, 21:53

28th December 2006, 21:54

So the question is where are the keys.... hmmm... I don't have cyberlink or a hd-dvd drive to search for them but here are a couple of thoughts.

when playing a hd-dvd does cyberlink write a file to its install directory with the sha1 code so that it can identify the disk easily? is that where the original TKDB.cfg came from? How about in the registry? Else it looks like you are gonna need a way to dump the memory and scour through that.

~Sy

swiego

28th December 2006, 22:16

Interesting! I will have to try this to see if the same vulnerability affects WinDVD HD (which comes with my Toshiba HD-DVD laptop).

On the one hand, it would be nice to reduce wear and tear on what I feel is a pretty flimsy notebook drive. On the other hand, I'd hate to see this affect the popularity of a format that I very much enjoy.

Gradius

28th December 2006, 23:15

Yeah, WinDVD is vulnerable too.

Gradius

blutach

28th December 2006, 23:23

@cwm9 - :goodpost:

Hollywood and other EVIL guys think, in a digital world, something will be 100% unbreakable, in reality they're as stupid as they can be. They keep themselves busy to find new ways to protect your sh** while forget to provide us GOOD stuff to market (at fair price of course), so good that I'll BUY them, and not just to try to make a mere copy.You are implying that you don't buy but rather illegally copy digital video. This is against rule 6.

The DMCA is something I do not worry about. It's not a law, because it's an *ILLEGAL LAW* That is, it is superseded by the US Constitution and International principals of expression.
Gahndi said something like (to paraphrase) "To break an unjust law is a crime against the government. To follow an unjust law is a crime against justice and the human spirit."

This law is not valid. It is unjust and illegal. It may not have been struckdown (yet). But recall Dred Scott.Whatever your feelings, the law is passed in the US and is valid. What you are saying amounts to incitement to forum members and guests to break this law. Rule 6 is very pertinent in this regard.

The program which the author is referring to as exposing the key in memory is probably PowerDVD 6.5. I'm trying to locate where in the memory the key is located, anyway if someone could post at least one key, I could be able to tell where PowerDVD will place the keysAnyone posting a key on this forum is in direct violation of rule 6. Please read that rule carefully as well as the announcement at the top of this forum.

I really think this discussion needs to have very careful regard to forum rules and the laws of the various lands. Future posts which do not have such regard will incur strikes.

Regards

Gradius

28th December 2006, 23:34

@cwm9 - :goodpost:

You are implying that you don't buy but rather illegally copy digital video. This is against rule 6.

Not here, THANKS GOD I'm not in US. :devil:

Btw, I'm not implying anything, I let that to other ppl around. :cool:

Gradius

Bathrone

29th December 2006, 00:08

Edited - my words came out the wrong way my apologies.

blutach

29th December 2006, 00:16

Let's stay on topic please bathrone. And might I remind you of rule 4.

Regards

swiego

29th December 2006, 00:22

hirez80

29th December 2006, 00:28

Gotta agree with Bathrone,
plus I read the rules, i do not think he was "NOT nice" and I do think you can respect someone even though you think he is hypocritical or ??

But I know on the other hand, that this site and many others have to have this dubbel standard sort of speak, as it would otherwise directly violate isps, hosting services etc.
So there is a fine line between endorsing someone to do something, and just showing and talking about it.

Even though you guys have tutorials etc. which basically show stuff which is not allowed, as long as you say that i guess its possible?
Anyway, their our "doing their job" so THAT we should respect, but yes, this is a hypocritical world.. too bad..

Nuf said, I like many others am very happy about the progress with the HD DVD backups. My questions is, are they able to block a piece of software from FUTURE dvds just because a few ppl hacked it?? thats like asking everyone to reinstall windows, or word etc. (ok you get the point). even standalone players, say that a Pioneer chip gets compromised, thats it? i cant watch more recent movies after they update the key?? sounds like they are diging their own grave.. ppl will be VERY pissed if this happens...

Bathrone

29th December 2006, 00:55

ChronoCross

29th December 2006, 00:57

Not here, THANKS GOD I'm not in US. :devil:

Btw, I'm not implying anything, I let that to other ppl around. :cool:

Gradius

remember anyone who has a trade agreement with the US (basically anyone who gets legal hollywood movies/TV) has to respect US copyright law. This includes DMCA.

ChronoCross

29th December 2006, 01:00

What I am particularly interested in is how this exploit might be patched. How can volitile memory be completly protected from dumping? Encrypt the decrypt key? But then that has to have another decryption key so the cycle starts again.

TCP. Basically the key would never pass through memory but rather it would be stored in the TCP Chip and all DRM'ed data would have to pass through this. The TCP Platform is supposed to be separate from a OS and would prevent anything the is designed to use TCP from leaking out.

TCP is the ultimate in evil DRM and with all these companies pushing it, any new hardware in the future might have it so there may be no way around it........which is why I joined the EFF and steadfastly oppose the TCP.

TCP is trusted computing platform.

dukey

29th December 2006, 01:05

Someone correct me if I am wrong. But normally you can't read the memory of a program unless it is an area of specifically shared memory. However unless you 'zero' the memory before you exit the program that data will still be left in RAM. In the same way as when you delete files off your hard disk, they are not 'really' deleted, the sectors on the drive are just marked as aviaiable to write over.

If the program zeros the memory it uses for the keys before it exits (like it should really ..) u could probably get around this by just killing the app and forcing it to close before it can do this.

0xdeadbeef

29th December 2006, 01:46

Someone correct me if I am wrong. But normally you can't read the memory of a program unless it is an area of specifically shared memory.

Firstly, a ring0 process can read and write any memory. This includes kernel debuggers of course.
Secondly, every normal process can read and write in another process' memory if it is able to load a dll into that process' memory. Which is usually pretty easy to do.

However unless you 'zero' the memory before you exit the program that data will still be left in RAM. In the same way as when you delete files off your hard disk, they are not 'really' deleted, the sectors on the drive are just marked as aviaiable to write over.

Using a memory dump is a somewhat dumb attempt to find the key. Usually you would use a debugger and set a breakpoint on certain API calls. At some point some call will return the key on the stack or in some registers.

If the program zeros the memory it uses for the keys before it exits (like it should really ..) u could probably get around this by just killing the app and forcing it to close before it can do this.
Anyway, dumping the memory doesn't make much sense. Indeed since the application allocates memory dynamically, the key might land in different locations depending on order of things done before. E.g. if a HD-DVD has more chapters or whatever, more memory is allocated on the heap for internal structures and the key lands at a higher address.

Best guess would be to examine which routines are called after you inserted a disk. The key exchange has to be one of the first operations, so disc insertion should be a good place to start.

zilexa

29th December 2006, 01:59

F A N T A S T I C ! ! !

hey muslix64,
now that you made the playback of HD-DVD almost as easy as a normal DVD movie, this could very well be THE reason for people to upgrade to a HD-DVD player!
(And since Bluray uses AACS as well this could mean the same thing for Bluray).

Since there has not been a bump for HD-DVD and Bluray like there was when DVD was released, it didn't seem very realistic these new HD players would break through.
But now with your work, this could lead to a breakthrough in the near future!
Congratulations man, and thanks!

hechacker1

29th December 2006, 02:53

so who is going to take this program to the next step?

Right now there is nothing illegal about the program because it doesn't provide any keys. It's just a nice proof of concept.

But for decryption to be useful I would think we need some automated way of extracting the key from the dvd. At that point we have a viable method of copying dvd's.

If we are forced to share keys through warez sites or download lists from offshore locations it makes the decryption unreliable and poorly supported (because we all know legitimate places like doom9 won't support the sharing of keys). +, there are so many variations of dvd's, probably each with it's own key.

I guess somebody is going to have to reverse engineer the playback and decryption of the key similar to the way commercial software players do it. Otherwise there will always be a cat and mouse game of updates to circumvent the protection.

Anyways, thank you so much for your program!

Gradius

29th December 2006, 03:00

remember anyone who has a trade agreement with the US (basically anyone who gets legal hollywood movies/TV) has to respect US copyright law. This includes DMCA.

Not here in Mars. :p

The world can live w/o US, never the inverse. :cool:

harycover

29th December 2006, 03:23

Hi muslix64

I know nothing about decrypting but I congratulate you and fully support you : you bought it, you should be able to watch it !

That said, HDmovies are now quite common on newsgroups, allready ripped and ready to watch with a pc, I think that's mainly HD streams ripped

Movies industry should resign and adopt other strategy such as price drop to sell more, if they Imagine That I would pay 25 euros or such per movie giving that I've already paid to watch it at the movie theater then they will wait a (very) long time for my money to come their way.

Cheers all

OverlordQ

29th December 2006, 03:47

Well, the players aren't adhering to AACS spec if the decrypted title key can be snooped from RAM, although that does call into question the ability to have a PC-based player. The spec basically says that the decrypted title key should be discarded if the disc is ejected, power is lost, an AACS boot sequence initiates or the player stops. I would think a memory dump or a freeze of a process to inspect its memory contents would constitute stopping the player!

Anyway, getting the volume id is easy enough but I'm still searching for the right title key from a ram dump of windvd hd. For all I know, WinDVD has gotten it right and the decrypted key just ain't there.

Reading memory would not stop playback unless you freeze the program to get an exact snapshot of it's current ram contents, I'd think pausing the movie within the player to guarantee the important values will not change would be enough so that a sequential scan would reveal what you need to know.

BUZZARD1

29th December 2006, 04:03

This has got me all excited again and it looks like im not the only one. A few more smart people and the problem is history.

Cheers to you all!
:stupid:

OverlordQ

29th December 2006, 04:18

Craigular.B

29th December 2006, 05:07

I don't think it's a problem that he released this crack so early.

If the industry suddenly changed the encryption scheme, they'd have to have a way to be able to update all the players currently on the market with the new encryption (I think?). I'm pretty sure there wouldn't be a way to make the two encryption methods compatible without compromising the new one's security, right? Then again, maybe they'd keep up the age-old tradition of leaving the early adopters without a pot to p*** in, and revamp the discs/players for a new generation.

Please, correct me if I'm wrong. I really don't know much about DRM. But (to me, at least) it seems like two different encryption methods would be too different to make them work.

-Craig

Gradius

29th December 2006, 05:58

BUZZARD1

29th December 2006, 09:56

You can make titles where connection with the Internet is mandatory to be able to playback the s*** on your TV, so the player can send the firmware version to some EVIL Studio Server, if the version is old, the ESS will send a new firmware version using a new crypto engine, simple like that. :readfaq:

It can be done directly from some movie disc too, while you wait for the player to start the playback, it can just put a huge "please wait, you stupid noob", or something, message on your TV, while doing the firmware upgrade, just like that.

Now TCP is so EVIL that people around need to know this thing well to NOT buying a single piece of TCP implement or compliant. :sly:
But is they did that then they would have to make sure every one who buys a HD-DVD player woudl have to have a internet connection, and it would have to say it on the box or walmart would get a trillion returns (this is when it is main stream of course). As far as them adding firmware updates on the disks, I would doubt it very much since there will be a crap load of models made in the next 5 - 10 years and it would be alot of space waested on the disk. Not to mention all the time and effort to make updates for all that firmware. But hey what do I know.

0xdeadbeef

29th December 2006, 10:41

I don't think it's a problem that he released this crack so early.

It's not a crack, not a hack, nor was a weakness of the encryption (AES 128) found. It's just a weakness of the player which delivers the keys esier than it should. This was somewhat expected by the industry and that's what the revocation list is for.

If the industry suddenly changed the encryption scheme, they'd have to have a way to be able to update all the players currently on the market with the new encryption (I think?). I'm pretty sure there wouldn't be a way to make the two encryption methods compatible without compromising the new one's security, right? Then again, maybe they'd keep up the age-old tradition of leaving the early adopters without a pot to p*** in, and revamp the discs/players for a new generation.

The encryption scheme doesn't need to be changed since it was not compromised. If we have really bad luck, PowerDVD will be blacklisted by entering a newly released HD-DVD in the drive in the next 1-3 months. If then nobody is able to read the keys from another player, we're were we started at.

Please, correct me if I'm wrong. I really don't know much about DRM. But (to me, at least) it seems like two different encryption methods would be too different to make them work.
-Craig
HD-DVD doesn't allow changing the encryption algorithm. BlueRay however does. But then again, it's unlikely that AES 128 gets hacked in the next years.

zeroprobe

29th December 2006, 11:43

and still no one has sucessfully done this.

cmon guys someone out there get a good memory dumper and post the results so we can have a look for yas.

Susana

29th December 2006, 11:56

and still no one has sucessfully done this.

cmon guys someone out there get a good memory dumper and post the results so we can have a look for yas.

Yeah, memoryman have had success:

http://www.memoryman.com/images/moviesm.jpg

;)

yodoso

29th December 2006, 12:43

LOL, this happens right after our guy leaves for vacation. Who cares if one change to the encryption can render this program useless, we have our first real progress in the world of HD. Now if these files are fully decrypted, and since the files are mpeg-2(are the first hddvd's still mpeg-2, or did they switch yet), we may only need to make a slight change if any to our favorite mpeg-2 decoder to actually make backup copies of our favorite movies. Thanks alot, Muslix64 you're not the only one with a monitor/vid card that doesn't support hdcp, your work is greatly appreciated.

This is gonna start a chain reaction of software development, just think of dess when it first came out. Actually forget that, before dess we'd started up a small program before launching our favorite dvd player(lol I think it was windvd back then too), and that program would actually frame grab from windvd. The software was buggy as hell, and the quality was terrible. LOL, I'd love to see an old doom9 guide using this method.

(btw, a couple of months ago, someone discovered that all you have to do is push the print screen in an old version of an hddvd program, and the frame was not encrypted. You could actually paste it into paint or any other program one wanted. Looks like the dvd, and the hddvd scene are progressing in the same way)

Next dess came out, and you guys know that program started the chain reaction of the dvd scene. I don't know the status of guy wrote the program, but hopefully the authorities gave him a break. But lets see someone rip a dvd of today with the software of yesterday. Thats right, it won't work. Like I said this program will start the domino effect

johner23

29th December 2006, 12:47

See above:

http://forum.videohelp.com/viewtopic.php?t=317738

http://forum.videohelp.com/viewtopic.php?t=317715

http://podcasts.engadget.com/2006/04/25/engadget-podcast-076-04-25-06/

http://www.engadget.com/2006/12/27/aacs-drm-cracked-by-backuphddvd-tool/

PS: now, people around the world can test and find / cause some weak point in that protection system. :)

Or, for those who has some proper knowledge, can create some similar tools that can be more succesful about that task.

And, of course, the industry will strike again very fast, I guess !! Be prepared !! LOL

Thanks.

xerces8

29th December 2006, 15:30

Hi Muslix64... could you please upload this to an alternative download source besides the infamous rapidshare?

I don't know how strict the moderators are , so I'll say just this: the MD4 hash of the file is 4860e9248663d52dc47bfc98d61ec6d7

(and I don't see any problems with this, since a few posts above a direct HTTP link to the file was posted; mods, please be consistent )

Regards,
xerces8

Wookie Groomer

29th December 2006, 15:40

ttringle

29th December 2006, 15:49

Next dess came out, and you guys know that program started the chain reaction of the dvd scene. I don't know the status of guy wrote the program, but hopefully the authorities gave him a break. But lets see someone rip a dvd of today with the software of yesterday. Thats right, it won't work. Like I said this program will start the domino effect

You don't know the status of the guy who wrote DeCSS?

He's probably one of the most well known hackers due to his cracking the dvd protection scheme and distributing the code around to the point it appeared on T-Shirts. Not sure how you could know about this website yet not know who DVD Jon is.

http://www.theregister.co.uk/2003/01/07/dvd_jon_is_free_official/

TimT

dchard

29th December 2006, 15:54

This has to be a hoax...

Should be, but noone can proved that yet.

Otherway: the guy should be right: the decrypted title-key where else could be, but in the RAM?

What all we need is a programmer with a HD-DVD drive and at least one encrpypted HD-DVD disk, to find out, that the Title-key is stored in the ram during playback.

Dchard

Atamido

29th December 2006, 16:23

This has to be a hoax since it appears not a single person in the entire world except the original poster is claiming this works or can confirm anything.
The reason people are excited is that his story is completely plausible. It has happened numerous other times that a program left the decryption key in open RAM to be used. And several people have looked at his program and determined that it is certainly a plausible set of code.

There are two reasons that people that have duplicated this wouldn't want to admit to it.
1. They don't want the legal trouble when their identities are discovered.
2. They hope to gain financially from this exploit (through the sale of pirate discs).

Honestly through, I suspect that there just aren't enough people out there with an HD-DVD drive to be able to work on this. Remember that some of the most able hackers don't have significant financial status.

Atamido

29th December 2006, 16:40

The program which the author is referring to as exposing the key in memory is probably PowerDVD 6.5. I'm trying to locate where in the memory the key is located, anyway if someone could post at least one key, I could be able to tell where PowerDVD will place the keys
Actually, you don't need to know where the key is, you can just test every byte sequence in PowerDVD's RAM. It would take a while, but not as long as you think. The secret is that you must know some byte sequence that occurs in the decrypted output to see if you have the correct key.

Lets say you know that somewhere in the first 1MB, this sequence is likely to occur: "0x2e513a5f2b9f3c5980". I assume you would pick some byte sequence from the HD-DVD specs or H.264/MPEG-2 specs.

1. Take 128bits at offset 0x0.
2. Take first 1MB of data from HD-DVD.
3. Feed both into decryption program.
4. Test output for test sequence.
5. If not found, start at step 1 and increment offset.

If a memory dump for PowerDVD is 50MB, and you want to test every 128-bit byte sequence, that means you will need to test a maximum of around 51 million offsets (the key is likely in the earlier section of RAM). This sounds like a lot, except for a few things:

1. The memory dump, 1MB of data, and output are all small enough to fit in RAM, so total speed will be limited by CPU+RAM.
2. Decryption of AES-128 is pretty fast (or else you couldn't decrypt the disc fast enough for real time playback).
3. The key is likely to be early in the RAM dump, before cached decrypted/unencoded output.

0xdeadbeef

29th December 2006, 18:13

Besides the fact that the key is unlikely to begin at unaligned addresses, I still would say that it's much more promising to set breakpoint on calls to DeviceIoControl. If the key challenge/response algorithm is similar to that of CSS, this functions should be called for the authentification process.
Indeed, I guess any call of DeviceIOControl which returns a 16 byte buffer is pretty likely to return a disc/title key.
So tracking the calls ot DeviceIOControl should also be a good start to retrieve the player key.

BTW: a quick look into the Win32 API shows that DeviceIOControl accepts 8 parameters.

BOOL DeviceIoControl(

HANDLE hDevice, // handle to device of interest
DWORD dwIoControlCode, // control code of operation to perform
LPVOID lpInBuffer, // pointer to buffer to supply input data
DWORD nInBufferSize, // size of input buffer
LPVOID lpOutBuffer, // pointer to buffer to receive output data
DWORD nOutBufferSize, // size of output buffer
LPDWORD lpBytesReturned, // pointer to variable to receive output byte count
LPOVERLAPPED lpOverlapped // pointer to overlapped structure for asynchronous operation
);

As the first parameter is the last to be pushed on the stack, the size of the output buffer is the 6th parameter or the 6th PUSH operation "above" the function call in the ASM listing.
Well, I have neither the ressources nor the time to do it myself - and admittedly I don't really want to get into trouble. But I would guess this appoach is pretty likely a good beginning.

Gradius

29th December 2006, 18:19

This has to be a hoax since it appears not a single person in the entire world except the original poster is claiming this works or can confirm anything. Let's see some proof. A fancy edited You Tube Video is worthless without at least one key to test for ourselves.

Keep in mind, really FEW people around have a HD-DVD on your PC or Mac, I would say not even 1%, including myself.

calinb

29th December 2006, 19:27

Now if these files are fully decrypted, and since the files are mpeg-2(are the first hddvd's still mpeg-2, or did they switch yet),Aren't most HD DVD titles shipping in VC-1? I don't know if they're good ol' WMV9/WMVA or if they're using the new WMV9 Advanced profile.

http://en.wikipedia.org/wiki/VC-1

dchard

29th December 2006, 19:36

Keep in mind, really FEW people around have a HD-DVD...

Thats the point: many people here are able to test the software, but they don't have the appropirate hardware to do it.

And ofcourse: the author also should give us some detailed information about how and where to find the Title-Key in RAm or whereever it is, or which debugger did he(?) use, etc.

Dchard

Zag

29th December 2006, 19:45

Thats the point: many people here are able to test the software, but they don't have the appropirate hardware to do it.

And ofcourse: the author also should give us some detailed information about how and where to find the Title-Key in RAm or whereever it is, or which debugger did he(?) use, etc.

Dchard

He is trying to stay on the legal side of things. If he gave instructions on how to obtain the title key he would be on the wrong side of the DMCA.

Atamido

29th December 2006, 20:03

Besides the fact that the key is unlikely to begin at unaligned addresses, I still would say that it's much more promising to set breakpoint on calls to DeviceIoControl.That is true. I was simply pointing out a method to do an exhaustive search of all allocated RAM, and that it could be done in a reasonable amount of time. He said he wanted to know the address, and I showed him how he could find it. Though, if one has reasonable experience with a debugger, and it isn't well hidden, that would be much faster to use that.

easy2Bcheesy

29th December 2006, 20:07

In summary, no matter what you do as a studio -- release on HD DVD or Blu-Ray -- some professional counterfeiter can hack open a TV, digitize the output, re-compress the movie, and release the title on HD DVD (or dvd, or super-dvd, or whatever.) Because the profit margin is so high, they could afford to trash their revoked player and buy a replacement for every movie if they had to. Every (smart) studio exec knows this; there's no reason for them to bail out just because of this. The "average joe" is probably screwed by either DRM even if this exploit turns out to work. The "advanced joe" will probably still find a way to copy movies. Overall, the best the execs can hope for is a small reduction in "average-joe" piracy which might or might not translate into a small boost in sales, which, over the next decade, might eventually amount to something more than a hill a beans after paying for the development of the DRM.

The more obvious solution would be to purchase an HDCP stripper, a Blackmagic Intensity and simply capture digitally into an enormous AVI file, then compress that. The only limitation would be the 4:2:2 colourspace, but at 1080p, believe me, you don't really notice.

0xdeadbeef

29th December 2006, 20:13

That is true. I was simply pointing out a method to do an exhaustive search of all allocated RAM, and that it could be done in a reasonable amount of time. He said he wanted to know the address, and I showed him how he could find it. Though, if one has reasonable experience with a debugger, and it isn't well hidden, that would be much faster to use that.

This would only be faster if you already had all the tools. Writing the tool to do this "brute force" approach would most probably cost much more time than debugging directly. Also unpredictable things like inverse byte order etc. could make the approach fail although the key is in there. Last but not least, it's not sure that the offset of the key inside the RAM dump will be the same for any disk. Tough this depends on the implementation, it could as well be that the key is at a different location each time depending on the HD-DVD structure or other things.
Last but not least, for the next step (extraction of the player key, recreation of the authentication algorithm) identifying the calls which return the disc/title keys is an important landmark.

calinb

29th December 2006, 20:17

He is trying to stay on the legal side of things. If he gave instructions on how to obtain the title key he would be on the wrong side of the DMCA.
I agree. This forum is certainly not a good place for getting anywhere near DMCA violations, so everyone must talk very generally.

Personally, I'm boycotting these anti-consumer technologies so I have no interest or means to test any of the methods, suggestions, or theories described in this forum that might be used to view or obtain decrypted keys from an HD DVD. That said, it seems to me that an HD DVD key changes each time a new DVD is inserted in the drive and it's pretty easy to focus on what's changed in a memory dump.

0xdeadbeef

29th December 2006, 20:47

That said, it seems to me that an HD DVD key changes each time a new DVD is inserted in the drive and it's pretty easy to focus on what's changed in a memory dump.
It has to be expected that a lot of things in the memory change when you exchange the disc. E.g. it would be sensible of a player to cache information about the disc structure etc.
Furthermore, though I don't know too much about the AACS decryptin process, it might be that the title key is only extracted when a new title is played. It's obvious that lots of things are cached in the memory for that and this will be completely different for another disc.

neviens

29th December 2006, 22:58

Some hints for reversers with HD-DVD players (I haven't).
Easiest way to find the key is look for for code and not data.
AES code is easy to find in executable or memory because
code is standartized.
Then attach the debugger, and put the breakpoint on key
expansion routine input. When decryption of title begins,
routine will be called, and program breaks in debugger.
Pointer to key will be on the stack or in register. Then Ctrl-C,
Ctrl-V or write down it.
Well I oversimplified the process, in real life there may be problems
with antidebugging, code obfuscation, etc, but it's possible to
overcome these too.
Next step is write patch for keys collecting code, or inject such
a code in working process.

Atamido

29th December 2006, 23:17

This would only be faster if you already had all the tools. Writing the tool to do this "brute force" approach would most probably cost much more time than debugging directly.
It all depends where your experience lays. The method I mentioned is pretty trivial, even for a programmer with limited experience. As I said, if you already are experienced debugger that would be much faster. If you've never used debugging software in your life, but you know how to program...

0xdeadbeef

29th December 2006, 23:47

It all depends where your experience lays. The method I mentioned is pretty trivial, even for a programmer with limited experience. As I said, if you already are experienced debugger that would be much faster. If you've never used debugging software in your life, but you know how to program...
My experience of programming versus ASM debugging is about 10000:1 in favor of programming. Still I would use the debugger approach for the named reasons. Also the suggestions posted by neviens is interesting. If one of the common AES tables could be located, this would be a good start as well. Still I think looking closely at the calls of DeviceIOControl would be the approach with the least effort.
The basic conditions for your suggestions assume to many things that first need to be worked out. The time alone to get the crypted and decrypted data and the memory dump would probably suffice to find the key with the debugger. Then you have to code the tool (which indeed should not be too much work). However if this approach fails (and it sure will) the first time you run it, there are too many factors which could be the reason for this: the input data or the expected output could be wrong, the tool could be buggy or it could be something you didn't consider like the byte order or storing the key as a string or whatever. It not even sure when exactly a title key will be visible in RAM and for how long.

hajj_3

30th December 2006, 00:19

the creator of this hasn't replied in about 3days, wonder if he's been arrested lol.

hope he replies soon and answers all these questions and hopefully creates a nice new shiny version that finds the key's automatically, even if the program takes 2hrs to find it that would be cool.

if cracking hd-dvd is this easy (well i say easy) why on earth was hd-dvd and blue-ray delayed for so long, why didnt they just hire stephen hawking and dvd-jon to create an unbreakable algorithm.

if a new version can auto find the key for the hd-dvd drive and the disc itself instantly or pretty quickly i will prob have to purchase a 360 hd-dvd drive. £130 aint too bad. £117 with 10% discount codes.

blutach

30th December 2006, 00:24

I don't know how strict the moderators are , so I'll say just this: the MD4 hash of the file is 4860e9248663d52dc47bfc98d61ec6d7

(and I don't see any problems with this, since a few posts above a direct HTTP link to the file was posted; mods, please be consistent )

Regards,
xerces8Posting an MD5 hash of a program is OK. Posting keys is not OK.

Nor is there need to somehow challenge the mod team to be consistent.

why didnt they just hire stephen hawking and dvd-jon to create an unbreakable algorithm.Does such a thing exist?

Regards

0xdeadbeef

30th December 2006, 00:39

And again (though it becomes boring): the crypting algorithm (AES128) is in no way broken and thus HD-DVD is not "cracked".
I would be happy if these statements were true, but at the moment, they aren't and there's no hint they will be soon.

hajj_3

30th December 2006, 00:39

Does such a thing exist?

Regards

Yes it does, the SSL256bit encryption hasnt been cracked, its approx 402 numbers long, its 2 prime numbers multiplied together. there is a $1m prize for anyone who can crack it.

zeroprobe

30th December 2006, 02:00

ahh well new years nearly here so we shall see sooner or later.

xerces8

30th December 2006, 02:34

Posting an MD5 hash of a program is OK. Posting keys is not OK.

Eh, the hash is not MD5 but MD4. A hash code used in a popular P2P network. Knowing it is as knowing an URL, only better, since it can not break due to a closing of a single server.

PS: For easy use, the size of the file must also be known, it is 17964 bytes

Alxemi

30th December 2006, 04:23

Well, i also hope this is not a hoax, but like other guy said, 12-28 is santos inocentes day, (fools day in spain) let´s hope it´s just a coincidence....

Anyway, if this is a hoax, the crack will come. We all now it, and the industry should know it.

plonk420

30th December 2006, 05:42

it would be badass if the key used was a standalone player's key ;)

dukey

30th December 2006, 05:51

Just some thoughts ..

I'm pretty sure brute forcing the memory is a viable solution. Probably could brute force 4gig of ram in under an hour on a fast machine. 1gig of ram in 15 mins .. etc

You could probably even speed up the process and see when the program allocates x amount of memory. Where x is the number of bytes a key will take up in memory. That might be a give away :p

zacox

30th December 2006, 07:04

It's easy for them to get YouTube or some other site to cough up an IP addy on this guy.

You honestly believe a person who has the skill necessary to write this software doesn't know how to cover his tracks?

After seeing what charges DVDJon faced (though he was eventually found not guilty), I'm fairly certain he used several layers of proxy servers and anonymizers to post here, on YouTube, and anywhere else. Hell, he probably routed his IP traffic around the world twice before hitting a destination. Good luck with that, MPAA.

It sort of underscores the beauty of collaboration and desire to be free of limitations and boundaries only made available through a worldwide network of minds. It's a game. Any 1000 software engineers can build an encryption scheme for DRM, and any million hackers can find a way to break it quicker than those 1000 engineers ever imagined. Sort of like a prison in that the guards work 8 hour shifts trying to keep drugs, gangs and weapons out, while the inmates have 24/7/365 to figure out how to get them in. Who do you think wins the war?

The only way this guy will ever be found out is if he gets drunk and starts bragging to his college buddies that he is the new DVDJon.

Unless of course, he is looking for the DMCA fight, in which case, more power to him.

JarrettH

30th December 2006, 08:27

you're on reuters...

http://today.reuters.com/news/articlenews.aspx?type=technologyNews&storyID=2006-12-29T104641Z_01_N28191949_RTRUKOC_0_US-DVDS-HACKER.xml

a "hacker" lol :p

daft009

30th December 2006, 08:45

wow! impressive stuff!

OverlordQ

30th December 2006, 10:22

Yes it does, the SSL256bit encryption hasnt been cracked, its approx 402 numbers long, its 2 prime numbers multiplied together. there is a $1m prize for anyone who can crack it.

No, that doesn't mean that it's unbreakable as you claim. The only unbreakable encryption is a properly setup one time pad.

XStylus

30th December 2006, 11:33

He is trying to stay on the legal side of things. If he gave instructions on how to obtain the title key he would be on the wrong side of the DMCA.

He's still not quite on the legal side of things simply because of his YouTube video. It's proof that he used his tool to violate the DMCA. I don't know if that's a civil infraction or a criminal infraction, but it's a risk to him nonetheless, thus why I suggested earlier that he take steps to protect his identity unless he's willing to do what 2600 lost the will to do back when they published DeCSS--that being taking it all the way to the Supremes. Although with the current corrupted political climate, I don't hold much hope there, to be honest.

Perhaps it's all just paranoia, but considering the extreme public importance of what muslix64 is doing against the unconscionable viciousness of the **AAs, it's justified.

cc979

30th December 2006, 11:50

He's still not quite on the legal side of things simply because of his YouTube video. It's proof that he used his tool to violate the DMCA. I don't know if that's a civil infraction or a criminal infraction, but it's a risk to him nonetheless, thus why I suggested earlier that he take steps to protect his identity unless he's willing to do what 2600 lost the will to do back when they published DeCSS--that being taking it all the way to the Supremes. Although with the current corrupted political climate, I don't hold much hope there, to be honest.

Perhaps it's all just paranoia, but considering the extreme public importance of what muslix64 is doing against the unconscionable viciousness of the **AAs, it's justified.

spooky stuff, law is not my field but posting the title-keys in the youtube film is asking for trouble

KillaByte

30th December 2006, 12:05

spooky stuff, law is not my field but posting the title-keys in the youtube film is asking for troubleHe didn't. What is seen in the film are only hashes - the title keys are well hidden behind a black bar ;)

neviens

30th December 2006, 13:38

My experience of programming versus ASM debugging is about 10000:1 in favor of programming.
...

It's easy to guess from your nickname too (;
Those with 1:10000 ratio usually select something like
0DEADBEEFh for nick (:

...
Still I think looking closely at the calls of DeviceIOControl would be the approach with the least effort.
...

You are complicating things. DeviceIoControl is for communication
with kernel mode drivers, and it's a bad practice to put computation
intensive code (ie. crypto functions) into driver.

Better pay attention to CLDShowX.dll library, it's the only file
with all necessary crypto functions (Rijndael aka AES, SHA1,
ECC) into.

Cyberace

30th December 2006, 13:43

since the files are mpeg-2 (are the first hddvd's still mpeg-2, or did they switch yet), we may only need to make a slight change if any to our favorite mpeg-2 decoder to actually make backup copies of our favorite moviesI read that all HD DVD movies released so far uses the 'newer' MPEG-4 AVC (H.264) codec, (it is Blu-Ray that still uses MPEG-2 for it's retail movies, but I guess they going to switch to H.264 soon enough as well). My favorite H.264 encoder is x264, and my favorite H.264 decoder is FFmpeg (FFmpeg's libavcodec/libavformat also contains a H.264 encoder based on x264), they are my favorites because the are open source (GPL/LGPL). Nero Digital by Nero/Ateme probebely has the best commercial H.264 encoder for home-usage, and CoreAVC by CoreCodec is probebly the best commercial H.264 decoder for home-usage, however those are closed source and cost money.

http://en.wikipedia.org/wiki/HD_DVD
http://en.wikipedia.org/wiki/Blu-Ray
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC

0xdeadbeef

30th December 2006, 14:02

It's easy to guess from your nickname too (;
Those with 1:10000 ratio usually select something like
0DEADBEEFh for nick (:

A good observation on this ;)
Then again, the C notation adds the "0x" pun, so this was a reason as well. On a second thought, I spent hundreds if not thousands of hours debugging on several processors, so the 1:10000 ratio was maybe a little exaggerated :)

You are complicating things. DeviceIoControl is for communication
with kernel mode drivers, and it's a bad practice to put computation
intensive code (ie. crypto functions) into driver.

When looking at the source code of DVD authentication functions, they use DeviceIOControl to send/retrieve keys from the DVD drive, which is not surprising as this is the only way to do it. Should be the same for HD-DVD and if you determine the handle by watching calls to CreateFile, you can break only on calls which are sent to the HD drive.
Then again this has nothing to do with the encryption and thus is neither compitation intensive nor bad practice.

Better pay attention to CLDShowX.dll library, it's the only file
with all necessary crypto functions (Rijndael aka AES, SHA1,
ECC) into.
That's a very interesting observation of course. If one could identify the function entries of the AES128 decryption in there and set a breakpoint to it, this would deliver the title key immediately. Then again, I neither have the hardware nor the software nor the wish to be the aim of some lawyers, so let's just see what other people make of this.

v_spec

30th December 2006, 14:21

The guy is famous! He's all over the news.

hartiberlin

30th December 2006, 14:48

The encryption scheme doesn't need to be changed since it was not compromised. If we have really bad luck, PowerDVD will be blacklisted by entering a newly released HD-DVD in the drive in the next 1-3 months. If then nobody is able to read the keys from another player, we're were we started at.
.

What a crap,
just keep the PowerDVD Version you have now
and uninstall a newer Version.
Or install Windows XP again and then install
the old PowerDVD Version again...

This way you always have access to the old
Version.

Also, if a movie is decrypted it can be recoded
into WMVHD or MPEG-4 H.264 or XVID-HD or DIVX-HD
or Nero-HD and stored onto a normal
DVD-R as a backup.

I guess this hack will boost HDDVD very much now in
the future !
I might myself buy now a XBOX HD-DVD rom drive
and rent some HD-DVD movies, if I can make backups.

Also if HD-movies would come out at the same
day as they are released in the movie theater and are
not sold much higher than a movie ticket, I also would
just buy them !

All this DRM crap is stupid.

It just doesn´t make sense...
I will not go to a movie theater to see a movie
and be annoyed by the big guy in front of me,
who has an Afro look hair and makes noise
with his popcorn bag...
I just want to have the movie at home myself...
I just collect movies and I don´t sell them...

If the movie studies would be smarter, they would just drop
the DRM and make the media available at prices, everone
can afford to buy and release it at the same day,
they are also released at the movie theaters
or make them available to download the same day for
the same fee what a movie ticket costs...

Then they would make much more money...

Now we have to rent the movies, copy them
and recode them to DVD-R, which is very time
and work consuming...

I would love to pay 5 to 10 Euros for a HD movie
to download online, if it would be much easier and
would be availabe on the first day, the new
movie is released into the movie theaters..

blutach

30th December 2006, 15:04

I guess this hack will boost HDDVD very much now in
the future !
I might myself buy now a XBOX HD-DVD rom drive
and rent some HD-DVD movies, if I can make backups.

Also if HD-movies would come out at the same
day as they are released in the movie theater and are
not sold much higher than a movie ticket, I also would
just buy them !

All this DRM crap is stupid.

It just doesn´t make sense...
I will not go to a movie theater to see a movie
and be annoyed by the big guy in front of me,
who has an Afro look hair and makes noise
with his popcorn bag...
I just want to have the movie at home myself...
I just collect movies and I don´t sell them...

Now we have to rent the movies, copy them
and recode them to DVD-R, which is very time
and work consuming...

I would love to pay 5 to 10 Euros for a HD movie
to download online, if it would be much easier and
would be availabe on the first day, the new
movie is released into the movie theaters..Such a blatant post about how you copy material you do not own is clearly against the spirit and intention of rule 6. I have warned users about this previously in this very sensitive thread.

Strike issued.

As well, I fail to see what a person's hair has to do with it. Please be more polite on this forum.

Regards

hartiberlin

30th December 2006, 15:16

Sorry,
no disrespect to someone´s hair style...
but if you go a movie theater, pay around 8 to 12 Euros
Entrance and get a seat, where somebody in front of you is
very tall and has a hair style, that affects your sighting of the
screen display and some people in your
neighboorhood crackle with their popcorn bags all
the time, so you don´t understand the audio at all...

then I would like to stay at home and better watch
the movie on my 32 inch TFT flatscreen and
can lay in my bed and have a drink with it
during watching it and pause, if I have to go to the
toilet or someone calls...

blutach

30th December 2006, 15:20

You are extremely close to a 3rd strike hartiberlin. Stay on topic.

Regards

hartiberlin

30th December 2006, 15:29

I have clearly stated,
that I would like to avoid copying discs
and just buy the movies online,
also with DRM , if it is userfriendly and the license
is valid at least for one year.

I really would like to have new HD movies in an easy
to download format and would like to pay for this
also.

But the current offers are no good
and are more expensive than a movie theater ticket.

And be realistic... how many times do you really
watch a movie twice ?
Very limited number of titles which are your favourite movies, but
many titles you would only collect and never watch twice..

Okay, sorry, for being offtopic again.

I guess we should wait for the new version on Jan. 2nd.
Then we can see, if he will deliver a workable solution...

hajj_3

30th December 2006, 15:36

think im gunna pencil in jan 2nd in my diary (maybe a should buy a diary first thinking about it!).

i have a suspicision that the author will prob never post in here again nor release a new version. its been about 4 days without a word from him!

trbarry

30th December 2006, 17:22

Each day that goes on without someone else actually providing a key or at least confirming spotting one makes me more skeptical this is real.

- Tom

0xdeadbeef

30th December 2006, 17:36

What a crap,
just keep the PowerDVD Version you have now
and uninstall a newer Version.
Or install Windows XP again and then install
the old PowerDVD Version again...

Let's see

[ ] You know how the revocation mechanism works
[ ] You understood any of my posts
[x] You don't have a bloody clue what you're talking about

1 out of 3 !

Zag

30th December 2006, 18:05

What a crap,
just keep the PowerDVD Version you have now
and uninstall a newer Version.
Or install Windows XP again and then install
the old PowerDVD Version again...

This way you always have access to the old
Version....

I am afraid you are not understanding...once this version of PowerDVD is blacklisted it won't work anymore with newer released titles. The newer released HD-DVDs will know that this version of powerDVD has been compromised and will refuse to work. You either update to a newer version of powerDVD or you are stuck with only be able to play the old (150 or so HD-DVD) titles that have come out up to now.

Atamido

30th December 2006, 18:26

However if this approach fails (and it sure will) the first time you run it, there are too many factors which could be the reason for this: Chill. Since no on is likely to be doing this, it's all academic anyway. I was providing a specific solution to a specific answer, not trying be the best.

calinb

30th December 2006, 18:55

Each day that goes on without someone else actually providing a key or at least confirming spotting one makes me more skeptical this is real.I agree. It's amusing that many news outlets are reporting that HD-DVD has been cracked or compromised, based on the YouTube video and the claims posted here. As we all know, it's far from compromised as long as the keys remain secure. The only upside to this attention is an elevation of public consciousness about the DRM issue. The U.S. National Public Radio spot that aired yesterday had a nice segment on consumer rights vs. DRM while reporting that HD-DVD had been compromised.

Gradius

30th December 2006, 19:19

So, has anyone with hardware (HD-DVD) and couple titles confirm this working? If you don't know, nobody said that yet. :logfile:

Soulhunter

30th December 2006, 21:32

Maybe its just a tricky campaign from the BluRay camp and muslix64 works for sony! ;D

A happy new year @ all ~ Bye

Zag

30th December 2006, 22:18

The problem is that he gave very little (nothing really) information regarding how to obtain the Title keys. All he said was"

"I won't explain it in detail. Read the AACS doc first. You will understand.
The title keys are located on the disk in encrypted form, but for a
content to be played, it has to be decrypted! So where is the
decrypted version of the title key? Think about it..."

A lot of people saw the hash and thought that those were the keys so now they can't understand why no one has confirmed this. There are relatively few people that have the hardware then on top of that even fewer people that have the knowledge that can pull the keys out of where ever they are regardless how obvious he says it is.

Pulp Catalyst

30th December 2006, 22:25

screw the proxies and firewalls, and what ever else, go to public places like cybercafes and upload there, hard to trace you if you keep moving places,

and whilst your at it, use drive crypt, which protects a partition with powerful encryption, using a very long pass phrase,

but if you upload files from public terminals, the risk of getting caught if near enough 0%, but don't forget to goto to different places, several would be good,

happy new year to every one, and lets hope blue ray gets hit soon, to keep our fair right's alive, as i don't see any company out there that protects our rights, just goverment agencies protecting corporates companies.

well done, and there was me thinking DVD jon may of had this, still if you succeed, you will be more famous then DVD jon, as cracking AACS is suppose to be like moving mount everest, hehehe

still being known is being caught, can't crack a multi billion dollar encryption aswell as lost from profits from the films them selves and exspect to not get caught, only way to get a way with it, and that is not to be know, but one doesn't get fame that way,

depends what your motives are really, do you want to be known and play that game, or not be known, and not get caught,

i hope it's the latter, not because of what you can and can't do, but if you do go to court, you will be on your own, been there myself, can be scary when your on your own,

look after your self, and be as stealth as you can,

live long and prosper.

DVDCake

30th December 2006, 23:11

I've got the 360 HDDVD drive in hand. In the youtube video it shows that he is using powerDVD 6.5 . I'm only finding 7.0 online. Should I try to find 6.5 or go with 7.0?

DC

glen8

31st December 2006, 00:05

forget that

lazyn00b

31st December 2006, 00:28

I've got the 360 HDDVD drive in hand. In the youtube video it shows that he is using powerDVD 6.5 . I'm only finding 7.0 online. Should I try to find 6.5 or go with 7.0?

DC

You will almost certainly need the PowerDVD 6.5 HD version - trust me, it's out there, just keep looking. The newer PowerDVD Ultra will play HD DVDs also, but it may not have the vulnerability.

Zutton

31st December 2006, 00:58

Something not to overlook is that even if AACS has really been cracked, there is not that much of an advantage in backing up HD-DVD movies due to the inconvenience factor of storing movies on a hard drive.

Let's say an external 300GB drive can be had for $75, and that the average HD-DVD is 30GB. So, 10 movies can be stored on the drive at a cost of $7.50 a movie. Are people going to go out and buy dozens of external drives, label which 10 HD-DVD back-ups are on each drive, and then plug in a drive whenever they want to watch a given flick? Maybe. But until blank HD-DVD media is readily available and cheap, I don't think that Joe Six Pack will be interesting in casual copying of HD-DVDs to a hard drive backup.

hajj_3

31st December 2006, 01:02

true zutton, but you could convert the discs into x264 codec, say about 15gb. or even a 720p x264 and fit it on 1 dvdr.

we wont be getting cheap hd writers or media for 18+ months so no point even thinking about that!

johner23

31st December 2006, 01:41

See above:

http://news.yahoo.com/s/nf/20061230/tc_nf/49022

http://club.cdfreaks.com/showthread.php?t=204039&highlight=BackupHDDVD

PS: does anybody will improve the program? Or create some GUI for it?

I hope more people put some updating work for BackupHDDVD in next versions, because (very soon) the industry will correct their security holes and make some updates in future high definition discs, just like they did before with WMA and WMV files ( DRM protection) or even new dvd discs releases.

Thanks.

gooki

31st December 2006, 01:53

PS: does anybody will improve the program? Or create some GUI for it?

No real need for a GUI at this stage (the command line structure is very simple), but for mass appeal, then yes one probably will be made.

I've got my HD-DVD drive on it's way, and 3 titles so just need to find out how to detect these missing "keys".

PS for people in countries that don't have the HD-DVD drive available for purchase, www.playasia.com have fair pricing on the device, and decent shipping rates.

Gradius

31st December 2006, 01:56

We'll know sooner or later, wait until day 2.

hartiberlin

31st December 2006, 02:26

..... You either update to a newer version of powerDVD or you are stuck with only be able to play the old (150 or so HD-DVD) titles that have come out up to now.

Yes, that is what I meant,
until today this version of PowerDVD will always be able to
play the current 150 titles.
I guess this is enough for a few tests...

johner23

31st December 2006, 02:37

See above:

--> http://en.wikipedia.org/wiki/BackupHDDVD

The decryption methodology is similar to DeCSS, exploiting and extracting the weak player keys.

http://www.betanews.com/article/Studios_Take_Claims_of_AACS_Crack_Seriously/1167427818[/

http://www.techtree.com/India/News/Took_Eight_Days_to_Crack_HD_DVD/551-78152-581.html

And if you look for more news, you'll find a great amount of sites that talks about the program and his creator. LOL.

PS: it will be necessary (for those people who has proper knowledge about the subject) to open and study the player ( physically, I mean) to understand the way the things work, how to get the valid keys, etc?

More: people who can get some player for that high definition discs could test and post their results / experiences here, to help the author ( or capable people willing to help him) in BackupHDDVD's development and improvement for next versions. ;)

Thanks for help.

devil (johner)

Deihmos

31st December 2006, 10:14

See above:

--> http://en.wikipedia.org/wiki/BackupHDDVD

http://www.betanews.com/article/Studios_Take_Claims_of_AACS_Crack_Seriously/1167427818[/

http://www.techtree.com/India/News/Took_Eight_Days_to_Crack_HD_DVD/551-78152-581.html

And if you look for more news, you'll find a great amount of sites that talks about the program and his creator. LOL.

PS: it will be necessary (for those people who has proper knowledge about the subject) to open and study the player ( physically, I mean) to understand the way the things work, how to get the valid keys, etc?

More: people who can get some player for that high definition discs could test and post their results / experiences here, to help the author ( or capable people willing to help him) in BackupHDDVD's development and improvement for next versions. ;)

Thanks for help.

devil (johner)

Am I the only one who thinks this was a hoax?

moonraker

31st December 2006, 11:35

I might have missed something here, and forgive me if it's a stupid question, but: how did the decryption keys get into the memory if the software didn't let you play the HD-DVD ?

dchard

31st December 2006, 12:00

For those who need pdvd 6.5 hddvd:

just use search: ::EDITED BY NIC - No Warez! (Rule 6!)::

Not forget: just use only for the end of the trial period, and then buy it if you like it. I hope I not violating any rules by posting this.

Dchard

crypto

31st December 2006, 12:52

Am I the only one who thinks this was a hoax?

No! But for some reason all those who know how AACS really works, don't comment on this.

Hotdog453

31st December 2006, 16:50

I'm using the tool right now on "Fugivitive", so I'll let you all know how it works here in a few. If I'm not too busy crying if it works.

trbarry

31st December 2006, 17:02

I'm using the tool right now on "Fugivitive", so I'll let you all know how it works here in a few. If I'm not too busy crying if it works.

Hotdog453 -

Did you actually acquire a non-zero key somehow?

- Tom

Hotdog453

31st December 2006, 17:05

Zag

31st December 2006, 17:17

I mean I'm trying the tool on the disk. Not trying to do anything more clever or deep or witty.

As for a non-zero key, I have no idea what you're referring to. It appears to be working, as in, the files are growing, and it hasn't given me an error of any sort.

You'll end up with a worthless copy on your hard drive because you are not decrypting it, you are just copying it to the hard drive in its encrypted form. You need the title key to decrypt it otherwise you are just wasting time and hard disk space. There is a file that came with the tool called TKBD.cfg. This is the file that contains the title keys, right now you will see this:

CE6339246F34087AB355681DEB656D23DCD5BD86=Full Metal Jacket | 1-00000000000000000000000000000000
486198E3855B57CD40F6DC0C60645BDE8E1E9AC5=Van Helsing |19-00000000000000000000000000000000
B5A8E784B83E793AB246D0C5F7C148A39D7F4856=Tomb Raider 1 | 6-00000000000000000000000000000000
4ACABE525F5CBF77DAA43EA2B83E04918D5FA6D4=Apollo 13 | 1-00000000000000000000000000000000
3D357B0653A66176583C5218FD0149EAF8832FB0=The Last Samurai | 1-00000000000000000000000000000000
610CF1EB362D40050123E92F063D51AC05676F37=The Fugitive | 1-00000000000000000000000000000000

See all those zeros on the right? Thats where the title key for your movie goes. The numbers on the left (hash) mean nothing without the title key. You are supposed to find this key and place it there. Don't bother asking how to find the title key because no one is talking. Look at the FAQ that came with the software, he mentions it but basically you are on your own.

Golgot13

31st December 2006, 18:03

Hi all,

Happy new year 2007.

I test the tool and it don't work (in my Computer ?).
I have 50 HDDVD from many countries (US, Japan and Europe).

I have 2 titles which can "decrypt" (there is a key line in TKBD.cfg). No way to have a *.evo not encrypted:

The process work and copy the file on hard disk I compare the files in the HD DVD disc and
the hard disk, there is lot of difference).
But I can play NOT it with PowerDVD 6.5 and when I demux its, the elementary file are encrypted
(VC1 viewer see bloc with different colour,... ).

I think it was a problem of my PowerDVD 6.5 because I can not see HD DVD disc on my PC with it
(I use it to test my HD DVD authoring not encrypted on HDD).
I use in my home a X360 HDDVD drive (maybe the tool work only with HDDVD from NEC or Toshiba).

Censored.....

And if the crack of AACS will be public (in tool like dvdecrypter)
all major (video studio mike Warner, StudioCanal,...) will do only
BluRay disc. Because there are two other protections:
Rom maker and BD+.

Today the HD DVD file from HD DVD encrypted disc can copy on HDD
directly without out decrypter software!!!! :mad:
This is not possible with BluRay encrypted (AACS + BD+) and DVD (CSS)...

Golgot13

cinemania

31st December 2006, 18:21

Hi all,

Today the HD DVD file from HD DVD encrypted disc can copy on HDD
directly without out decrypter software!!!! :mad:

Golgot13

Hööö?

Without Decrypter Software ?

Don´t think so man ... BackupHDDVD is already a Decrypter when you have the key ;)

Golgot13

31st December 2006, 18:38

Hööö?

Without Decrypter Software ?

YES !!!!!!

Don´t think so man ... BackupHDDVD is already a Decrypter when you have the key ;)

In my home, I have X360 HDDVD drive and I copy the file on my hdd DIRECTLY.
If you search in the web you can find encrypted *.evo file...

It is crazy but you can test it and you will see...

Golgot13

Gradius

31st December 2006, 18:49

I see, I see.

But you cannot playback FROM HD, right ?

Now I'm starting to think that video (on tube) might be... fake.

Happy 2007 !

Gradius

Golgot13

31st December 2006, 19:39

I am not sure because there is on the web some files
from encrypted HD DVD (*.aca and *.evo).

Censored...........

There is on the web since beginning of december decrypted source
files from HD DVD...

If you search, you can find valid demuxers (HDDVD demux don't work),
DeACA, and somes tools for HDi.
I wait a software to Dolby Digital Plus.

I think before two months we will see on the web recode of HD DVD
on DVDR (in H264 and DD+, sure).

I surprise to see good professional tools on the web...

Happy new year 2007 !!!
Bonne annee 2007 !!!
S novum godom 2007 !!!

Golgot13

Turtleggjp

31st December 2006, 20:30

I don't think this program is a hoax, but rather it is not the easy one-click solution to decrypting HD-DVDs that we have become used to with DVDs. It's sort of like being given a Ferrari, but without the keys. The car cannot be driven with the keys, unless of course it is hotwired (and in this case, "hotwiring" HD-DVDs with their AACS protection is not easy).

I tend to see this program on the same level as video game console emulators. Although their existance is somewhat controversial, and disliked by the console makers, they are not illegal as long as they were created using only publicly available information (as this program claims to be). The trick is, the emulators are pretty much usless without the game ROM images for them to work on, just like this program is pretty much worthless without the keys. Game ROMs can be considered to be warez, and thus will not be as easily acquired as the emulators. The same will be true with the keys needed to make this program work.

I think this program is an excellent example of a first generation ripper (if it does indeed work). I only hope that a similar program can be written for Blu-Ray discs as well, so that the paranoid movie studios will have nowhere to run.

Matt

Adub

31st December 2006, 20:37

@Golgot13
Of course it didn't work all the way man! Have you been reading the forum? You don't have the keys that enable you to unlock the encryption. What you just did was copy the disk to your harddrive, still in it's encrypted form. Until someone can find the keys, or rather, find how to find the keys, then we will not be able to decrypt HDDVDs.

BackupHDDVD v.99 only works when you have the title keys in your tkdb.cfg file already. The file that is contained in the download has the keys zeroed out, so that means no decryption, yet.

Golgot13

31st December 2006, 20:53

Censored..........

I have "Appolo13" and "Full Metal Jacket" (to test key).

Golgot13

tonyp12

31st December 2006, 23:15

Also, if a movie is decrypted it can be recoded
into WMVHD or MPEG-4 H.264 or XVID-HD or DIVX-HD
or Nero-HD and stored onto a normal
DVD-R as a backup.

A HDDVD is 30GB,
and I would guess the main title is 15-20GB.

You will loose some quality if you try to squeeze it down to a 8.5G Dual layer DVDR.
Maybe you could get a decent 720p version out of it.

bob0r

31st December 2006, 23:49

hajj_3

31st December 2006, 23:59

is the title key the same for every dvd of a certain film e.g apollo 13. so the key e.g sdfsdf234vdfgdsfg would be on every copy of apollo 13 sold?? if so that would be great for us, if someone found out the keys for every hd-dvd released it would help copying alot easier. then find the key of the hd-dvd itself.

im praying that this guy does come back, cos atm i think that he's a 1 poster and we wont hear of him again:(.

Zag

1st January 2007, 00:58

I would speculate that every copy of Apollo 13 that has been released up to THIS POINT has the same key. I am also willing to bet that future releases of Apollo 13 will have their key changed, it only makes sense.

Golgot13

1st January 2007, 01:17

A HDDVD is 30GB,
and I would guess the main title is 15-20GB.

You will loose some quality if you try to squeeze it down to a 8.5G Dual layer DVDR.
Maybe you could get a decent 720p version out of it.

With H264 codec, it's possible to encode HD video file 1920x1080
at 8Mbps (in France the ISP "Free" encode HD video at 6Mbps
in real time, and HD VoD file at 4.5Mbps in H264 from Ateme...)

Golgot13

blutach

1st January 2007, 03:58

Posting keys can be done so easily.

Like if you want to say: HELLO
Hi,

Everything is cool today.
London was very nice, and Lissa finally talked to me.
Oh man, its 2007 almost!

Spread the keys over 3 users, and nothing will hold ground in any court.

Or just give me the keys, ill post them anywhere, i live without laws :D

* awaits 2 jan ....You will please live within our forum rules irrespective of whether you obey the laws of your country.

Again, if any keys are posted, I will have no recourse but to issue strikes. All forum members need to be cognisant of rule 6 and the announcement at the top of this forum.

As well, bob0r, we are not interested in weather reports.

Regards

Adub

1st January 2007, 04:20

@hajj_3
Yeah, I believe that all the keys released so far are the same for that particular dvd.

The only problem is that "sdfsdf234vdfgdsfg" is not the key! Where the key would be located is where all of those 000000's are, right next to "sdfsdf234vdfgdsfg" in the tkdb.cfg file.

So, yes, if we knew the key, then it would probably be the same for all of the current Apollo 13 movies. Yet the fact is that we do not have nor know the key, so we are stuck at square 2. So to speak.

DVDCake

1st January 2007, 04:35

YES !!!!!!

In my home, I have X360 HDDVD drive and I copy the file on my hdd DIRECTLY.
If you search in the web you can find encrypted *.evo file...

It is crazy but you can test it and you will see...

Golgot13

What are you saying? You can copy HD DVD's to your XBOX hard drive?

Adub

1st January 2007, 04:52

No. He is using an external Xbox 360 HD DVD drive connected to his computer to copy the HD DVDs.

DVDCake

1st January 2007, 06:07

No. He is using an external Xbox 360 HD DVD drive connected to his computer to copy the HD DVDs.

Gotcha

I've got the same setup, waiting for more tools to find those keys.

BTW, did I mention how much I hate DHCP, no DHCP video card or compatable display and no workie. I guess thats why we are chatting in this thread to begin with. =]

~DC

Zag

1st January 2007, 06:15

Gotcha

I've got the same setup, waiting for more tools to find those keys.

BTW, did I mention how much I hate DHCP, no DHCP video card or compatable display and no workie. I guess thats why we are chatting in this thread to begin with. =]

~DC

I think you meant HDCP (High-Bandwidth Content Protection) and not DHCP (Dynamic Host Configuration Protocol). Gotta love all these acronyms. BTW, I agree with you...

DVDCake

1st January 2007, 06:19

I think you meant HDCP (High-Bandwidth Content Protection) and not DHCP (Dynamic Host Configuration Protocol). Gotta love all these acronyms. BTW, I agree with you...

DOH! Ya thats it =]

I got lucky though, ive got a nvidia 7600 card and a westinghouse 37" which is HDCP compliant.

zeroprobe

1st January 2007, 12:48

So anyone think there will be a follow up to this come tommorow??

Golgot13

1st January 2007, 13:23

HDCP is not a prrotection because there is lot of device which
can remove the HDCP protection...
This device is sell in grey market (without label, name,...),
and some professional use it to display video with old HD TV set.

Golgot13

hajj_3

1st January 2007, 13:49

edo1080

1st January 2007, 15:51

the only problems is how to find the kyes now, the tool is working( the youtube video shows it clrearly) ; I expect key lists will appear somewhere on the internet and will be shared. Anyway AACS will give a new set of keys for further releases of HD DVD movies and stand alone player by Toshiba will require a firmware update while software players like POWERDVD or WINDVD will require a new version update; I'm quiste sure that,even if now it could be possible to grab keys from memory with already released titles, with next gen software players this chance will ber forbidden. Anyway we will be able to backup at least all the titles released until now.

I hope tomorrw we will see some interesting news.

Fuse-One

1st January 2007, 17:19

I'll be getting a 360 HD drive soon. I am as excited as when decss was released back in the days.

video

1st January 2007, 17:42

PS for people in countries that don't have the HD-DVD drive available for purchase, www.playasia.com have fair pricing on the device, and decent shipping rates.

gooki. the site says that the drive "Compatible with Xbox360™
Japanese". I have an european version of xbox.360. will the drive work for me?
Thanks.

SBeaver

1st January 2007, 18:44

got a link for this device, im sure hdcp aint been cracked!

I know there was a small device, like a cable adapter, that hooked on to dvi or hdmi cables and just removed the HDCP and gave you a regular signal.
I think they were on sale for 30-40€ in germany, but everything got shut down eventually if I remember correctly.
This was a while ago and there wasnt much of a market back then.
Some similar device is probably what sits in all HDCP compatible displays so it's not very mystical at all that you could make a device like that with the right chip and components.
I don't know if they will ever be "allowed" for people with old displays that don't support HDCP, but I doubt they can be made illegal, just very very hard to get your hands on.

0xdeadbeef

1st January 2007, 19:30

There were devices called DVIMAGIC and DVIHDCP, which were distributed by Spatz Tech in Germany, but manufactured in Korea. They were much more expensive though, more like 350€.
The DVIMAGIC would convert DVI/HDCP to VGA, the DVIHDCP would convert DVI/HDCP to HDCP.
After Spatz Tec was threatened with legal actions, these device didappeared quickly, though they were said to be still produced by the Korean manufacturer for a while. There were also rumors that the chip/device id used or whatever was added to the HDCP revocation list. Dunno if this is true though.

tonyp12

1st January 2007, 20:38

With H264 codec, it's possible to encode HD video file 1920x1080
at 8Mbps

HDDVD uses VC-1 a very similar compression to H264.
There is no magic way to re-compress the video
from 20Gb down to 8GB and still look 99% as the original.

Now that AVC versions of mpeg4 are out you probably could get 70% quility.

DVDCake

1st January 2007, 21:24

gooki. the site says that the drive "Compatible with Xbox360™
Japanese". I have an european version of xbox.360. will the drive work for me?
Thanks.

The drive is just a toshiba USB drive, shouldn't matter where you get it from if you plan to connect it to a PC.

~DC

hajj_3

1st January 2007, 21:29

the drive might be region coded, think there are 3 regions for hd-dvd's, cant be sure tho!

DVDCake

1st January 2007, 21:30

the drive might be region coded, think there are 3 regions for hd-dvd's, cant be sure tho!

True but it shouldn't be long till someone creates a flash to remove region restrictions.

Golgot13

1st January 2007, 21:41

Today, there is not region code on HD DVD disc and on HD DVD drive
(all X360 HDDVD drive are same on the world).

Golgot13

DVDCake

1st January 2007, 21:43

I'm an old school encoding provider, mostly in the WM relm encoding live events via satellite and batch coversion of physical media stock. We are starting to work with VC-1 and the windows media 9 advanced codec. I have an application that runs kiosks and HD is the next step.

I've been working with some of the 1080p content on wmvhd.com to come up with a chart to show where the reduction of encoding rates will effect the viewing experience. This of course is subjective because content type and playback displays will produce different results.

So when we get some of these HDDVD's ripped and the media extraced I can produce some samples for reducing the bitrate.

~DC

gooki

1st January 2007, 21:59

gooki. the site says that the drive "Compatible with Xbox360™
Japanese". I have an european version of xbox.360. will the drive work for me?
Thanks.

Per above - should work fine as it's just a USB drive. The DVD region code may be different, but there is no HDDVD region code system at this point in time so for our purposes it shoudl work fine. I'll post up confirmation when my drive arrives (connected to australia/nz xbox360).

calinb

1st January 2007, 22:25

I'll be getting a 360 HD drive soon. I am as excited as when decss was released back in the days.There are several online reviews of the 360 HD drive under Windows. You might need new UDF filesystem drivers:

http://www.pcw.co.uk/personal-computer-world/features/2170703/xbox360-hd-dvd-pc

oddball

1st January 2007, 22:46

0xdeadbeef

1st January 2007, 23:23

Just jumping ahead to mention something if not already mentioned. Sharing of keys is a BAD idea because they will get blacklisted on future HD-DVD releases. Better to have a prog that decodes the keys for you (But does not tell you what those keys are) and then uses that key on the HD-DVD media to copy it. That way the media moguls won't have a list of compromised keys to blacklist players with on future HD-DVD releases. They would have to blacklist ALL keys which they could not really do without changing the way AACS drastically.

If disc/title keys were "shared", there would be no way of telling where they come from. Then again, looking at the video ony MyTube, it's quite obvious were the keys came from. So the player key will be blacklisted although it was never posted or maybe not even found and thus compromised.
So your suggestion somehow lacks any base and/or also shows a somewhat strange idea of the keys involved here. If it was possible to decode the disc/title keys without a specific player key, this would mean that AES128 was broken, which it isn't.

vsv

1st January 2007, 23:43

HDDVD uses VC-1 a very similar compression to H264.
There is no magic way to re-compress the video
from 20Gb down to 8GB and still look 99% as the original.

Now that AVC versions of mpeg4 are out you probably could get 70% quility.

Encoding for HD-DVD must have short GOP 0.606s max. and a lot another restrictions. You just can not use all power of AVC codec.
VC1 just polished for HD-DVD.For online distributed content no need restriction as for HD-DVD authoring.
In this case as said Golgot13 you can encode 1080p to avc at 6-8Mbps long GOP's and this be equal in quality to 12-16Mbps of VC1 on HD-DVD.

oddball

1st January 2007, 23:45

I'm thinking it's the revocation process which needs to be 'fixed' anyhow. All this talk of hacking/cracking the keys for decrypting is rather moot in that scenario.

Get around the revocation and the other stuff will probably seem simple.

I myself would not like to risk getting the key to decrypt an HD-DVD only to find I cannot play certain titles further down the line because they were revocated and my software/hardware 'silently' blacklisted them when the disc was inserted.

That is the insidious nature of this AACS system. I think people posting keys will only make this happen faster. Best to let the software pull the key from say PowerDVD 6.5 and not show it to the user. Let the key be used internally by the decryption software (No breaking of AES involved if the unencrypted key can be pulled from memory space). I assume that each disc must have it's own key? Otherwise if they blacklist a key on a title wouldn't it blacklist on everyone's player? I obviously must be missing something :)

hajj_3

2nd January 2007, 00:05

shall we take bets, its jan 2nd in 56mins, im betting that on jan the 2nd we will not got a new version of this program, nor will the guy post in here at all.

oddball

2nd January 2007, 00:08

LOL. FBI get!

0xdeadbeef

2nd January 2007, 00:09

I'm thinking it's the revocation process which needs to be 'fixed' anyhow. All this talk of hacking/cracking the keys for decrypting is rather moot in that scenario.

The revocation list of player keys is stored inside the HD-DVD drive. And it's the drive that decides to authenticate a player that was blacklisted. So I guess hacking the drive's firmware would be needed for this.

Get around the revocation and the other stuff will probably seem simple.

As I wrote before: if the revocation mechanism could be bypassed in certain drives, these drives together with a vulnerable player (or the player key and a separate implementation of the authentication process) would be able to deliver the disc/title keys until the end of time. This would practically circumvent AACS without having broken AES128. Still you would need a special drive with patched firmware to read out the keys.

I myself would not like to risk getting the key to decrypt an HD-DVD only to find I cannot play certain titles further down the line because they were revocated and my software/hardware 'silently' blacklisted them when the disc was inserted.

The revocation list is not about titles, but about players. So if PowerDVD is blacklisted, the player key is stored in the drive's non volatile memory and from this moment, the drive doesn't respond to this player key any more in the authentication process.

That is the insidious nature of this AACS system. I think people posting keys will only make this happen faster. Best to let the software pull the key from say PowerDVD 6.5 and not show it to the user. Let the key be used internally by the decryption software (No breaking of AES involved if the unencrypted key can be pulled from memory space). I assume that each disc must have it's own key? Otherwise if they blacklist a key on a title wouldn't it blacklist on everyone's player? I obviously must be missing something :)
As I said: it doesn't matter if the player key is used directly, indirectly or whatever. It will not prevent it from being blacklisted. And again: not the title is blacklisted but the player key.

video

2nd January 2007, 00:16

Today, there is not region code on HD DVD disc and on HD DVD drive
(all X360 HDDVD drive are same on the world).

Golgot13

okay but it is tagged as "Compatible with Xbox360™
Japanese", OK I know that's not a big deal, but I wouldn't like to end up with a drive paid for $200 and plays only japanese animes :D

Sagittaire

2nd January 2007, 01:12

Encoding for HD-DVD must have short GOP 0.606s max. and a lot another restrictions. You just can not use all power of AVC codec.
VC1 just polished for HD-DVD.For online distributed content no need restriction as for HD-DVD authoring.
In this case as said Golgot13 you can encode 1080p to avc at 6-8Mbps long GOP's and this be equal in quality to 12-16Mbps of VC1 on HD-DVD.

The majors restriction is just short GOP and only for low framerate source (short gop at 0.6006 sec is not a major restriction for 50/60 Hz sources). You can use CABAC, inloop, AQ, CQM, 2 adaptative bframes, wpred, Max Pref at 4, Max Bref at 3. There are vbv restriction but it's not a problem for 6-8 Mbps encoding (max at 29.4 Mbps with very large buffer at 30 Mbits). Short gop produce perhaps something like 10% or 15% efficiency loss for H264 if you compare with unlimited gop but not more.

dchard

2nd January 2007, 10:27

"I decide to track down the "Volume unique key" instead of title key.
I found it also! I'm preparing BackupHDDVD V1.00, that will support volume key and title keys."

This means, that the program will contain an empty variable - like with title keys - which is must be figured out somehow, but I think, we get a "Think about it" class answer for the question "How to get the volume uniqe key?" I know that he/she cannot provide us detailed informations about that in here, but many other ways should be.

Dchard

edo1080

2nd January 2007, 12:06

I know that he/she cannot provide us detailed informations about that in here, but many other ways should be.

Right! I hope that with the release of BackupDHDDVD 1.00 more tech hints will be revealed

KoD

2nd January 2007, 14:32

To people that don't have the technical baggage to understand it by themselves: all the required tech hints were already provided by the person that made the first post and some of those that replied in this thread.

And also, it is not the AACS protection system that was "cracked", but a software player failed to protect the decryption keys because of lazy programmers and haste to "release the player faster". This will change in future player versions, and although any software player can be reverse engineered to grab the keys again, you will not get a "press butan, get rip" commercial application out of this because it will be illegal in many if not all parts of the world. So no "AACS hacked" nonsense, please.

Hellreaper

2nd January 2007, 16:11

muslix64 will either...

...never post in here again.

...or tell you soon that there were some problems with the program and that you will have to wait until xx.xx.2007.

Face the truth, it took about two years until DVD keys were extracted.

If he/she had really done it, she/he had released the key extraction method. The program with the weakness would have been withdrawn or changed, no doubt, but it also would have been seriously verified that someone found a way to compromise the whole encryption/decryption process. (not AACS itself)

A real hacker/cracker is interested in releasing proof, not in releasing videos. You don't get scene credits for releasing videos.

dchard

2nd January 2007, 16:21

you will not get a "press butan, get rip" commercial application out of this because it will be illegal in many if not all parts of the world

DVD decrypting/copying is also illegal in most parts of the world, and see how many one-click decrypter in the market. Yes: not only a P2P distributed tiny software of a hacker, but commercial products.

A little off: could someone provide me some sort of info about HD-DVD-ROM directory/file structure? I found it for Blu-Ray (BD is more well documented than HD-DVD many other ways also), but I can't find it for HD-DVD. Searched the original documentations on dvdforum.org, but found nothing.

Thanks.

Dchard

edo1080

2nd January 2007, 17:42

A real hacker/cracker is interested in releasing proof, not in releasing videos

I don't think he's an hacker or a cracker, he simply is someone who needed to backup his discs and found a way to do it. So I don't need he wants to show us how "skilled" he is. I think we have to thank him for this program, he could also have kept it for himself, without running any risk.

Gradius

2nd January 2007, 18:02

Face the truth, it took about two years until DVD keys were extracted.

In 1997/1998 a Toshiba DVD-ROM 2x (max) + a mpeg-2 video decoding card for PC was USD$ 1000~1200.

DeCSS appeared in october 1999, thanks to 3 (three) people, not just Jon ! That all (2 years) was because the COSTS of DVD hardware (DVD-ROM), not the complexity !

Today isn't different, of course, the "complexity" is way better now. :search:

noclip

2nd January 2007, 18:28

The key revocation system and BD+ are an all-out assault on fair use. To revoke or change a key, studios would have to have found out that disk was compromised, and by that time the movie would already be up on the torrents. The only use that the draconian copy protection on HD formats prevents is fair use backup and transcoding by legitimate consumers.

hallway

2nd January 2007, 20:38

muslix64 will either...

...never post in here again. Do a Google search on 'muslix64' and literally every result is related to him/her and the HD-DVD crack... I know it's big news and all, but I've got a bad feeling about this one.
If he/she had really done it, she/he had released the key extraction method. The program with the weakness would have been withdrawn or changed, no doubt, but it also would have been seriously verified that someone found a way to compromise the whole encryption/decryption process. (not AACS itself)

A real hacker/cracker is interested in releasing proof, not in releasing videos. You don't get scene credits for releasing videos. The video at YouTube was certainly unnecessary and was quite well done. It sure wasn't webcam quality, in fact, it was pretty good quality and it was done by a 2nd person. As you say about a real hacker, they're more interesting in improving their program, fixing bugs, etc, etc and the time and effort spent making the video was wasteful.

DanITman

2nd January 2007, 20:52

Cyberlink Responds to Alleged AACS Crack

With the HD DVD AACS Crack/Hack that supposedly happened last week, I said that Cyberlink would most likely issue some additional information on the matter. I just got an e-mail from the people at Cyberlink with some great information. Above all, Cyberlink is sure PowerDVD's implementation of AACS fully protects HD DVD contents.

* First of all, PowerDVD complies to AACS compliance rules to ensure HD DVD contents are fully protected. Cyberlink is confident that PowerDVD fully protects HD DVD contents.
* Secondly, PowerDVD does not keep "Title Keys" in system memory. Cyberlink is not sure how the user got the Title Key and notes that the released tool nor the video on YouTube provides the information on obtaining the Titles Keys.
* Thirdly, there are no evidences that the user is using PowerDVD to hack/crack HD DVD video content. He or she was simply using PowerDVD to playback the video that was ripped with other software. PowerDVD supports evo video file format playback.

Overall, it doesn’t look like AACS or Cyberlink have found any faults in PowerDVD. So, at this point no updates will be issued for PowerDVD and the verdict is still out on whether or not additional playback software was used to obtain the Title Keys. No one has yet to prove that the keys can be obtained through a memory dump or any other methods.

Yet again, AACS wasn’t cracked/hacked and the one piece of the puzzle for obtaining the Title Keys doesn’t appear to add up.

Thanks goes out to Cyberlink for the information.

http://msmvps.com/blogs/chrisl/archive/2007/01/02/463980.aspx

JarrettH

2nd January 2007, 21:01

I guess we find out if this is omgbs today. :cool:

dchard

2nd January 2007, 21:15

"PowerDVD does not keep "Title Keys" in system memory"

OK, but where it is? It must be in somewhere it is shortly accessible many times, because the decoding of the encrypted is in real time, and this is a huge amount of data.

So the big question: where it is?

Dchard

2nd January 2007, 22:01

Maybe it's not PowerDVD's memory dump that Muslix is reading to obtain the key? He never said ir was cyberlink's software. Perhaps he is reading the mem dump of WinDVD. I dunno.. I just hope Muslix comes back to provide a little more direction.. It would be nice is others out there could verify that they had done a successful rip too!

~Sy

zeroprobe

2nd January 2007, 22:12

where did the 2nd of January come from anyway?

He not been active on here or youtube for a week, so he definately busy with something. If he was a hoax wouldnt he want to check how is joke is going. He got alot of peoples attention anyhow.

2nd January 2007, 22:15

Page 1 - Post 4
This is real, any good java programmer can confirm this program make sense, and all that is missing is the decryption keys.

Take a look at the FAQ file for details...

I already have a version that works with volume key instead of title keys. Even more powerfull!

Version 1.0, with volume key support should be out on january 2.

muslix64

2nd January 2007, 22:15

I spent the last few days reading a lot of articles on BackupHDDVD, reading a lot of people's post/comments on various websites.

This is the time to set the record straight about this new tool and what the impacts are.

First I need to clarify some points.

Revocation:

In the AACS system, there is 4 types of revocation:
Drive revocation
Host revocation
Device revocation (with MKB)
Content revocation

There is no such thing as "title key revocation" and "volume key revocation"

-------------

Now, here is a list of affirmations I have seen lately.

Affirmation 1: You did not break AACS, just the player

My comment: I did not break AACS, but I find a way to decrypt movies and I have bypassed all the revocation system.
Not that bad...

Affirmation 2: The BackupHDDVD circumvention tool won't last long

My comment: As long as insecure players will exist, it will last...
And insecure players will always exist, in fact you can extract keys from any player! Some players are just easier to extract the key from. Being lazy, I prefer to extract keys from an insecure player than a secure one.
And the AACS spec says "Device keys must be protected!" but they did not said that about volume key, fatal mistake!

Affirmation 3: The keys can easily be revoked.

My comment: What keys are you talking about?
As I stated before, there is no such thing as "title key revocation" and "volume key revocation". If someone publishes only volume keys, there is no way to know from which player these keys where extracted from, making the revocation system useless. They can do content revocation, but to revoke what? All movies before 2007? They can do player revocation, so I will just change the player I'm using, big deal...

So what is the AACS revocation system good at?
It is good for that scenario:
Someone post on the net, a tool that do the complete decryption automatically. Off course the program use stolen device keys from an official player. They (AACS and friends) will eventually get their hands on this program, look at the device keys and revoke them. Making that player unable to play new titles. But the author of this program can pre-extract a bunch of devices keys from different players and release them, one at the time, when the previous one have been blacklisted. The AACS spec says "Device keys must be protected!" so I suppose they put more effort in protecting these keys then the volume key in memory.

Affirmation 4: BackupHDDVD is nothing, only one person out of a million have the technical skills to extract keys.

My comment: BackupHDDVD is a proof of concept.

Picture this:
Few skilled persons can do massive volume key extraction, and send the keys to a central server on the internet. Then, they create an easy to use decryption program, with a nice GUI that do online key recovery. That way, my father and your father can backup movies.
Or they can send the keydb.cfg file on P2P networks (BitTorrent, E-Mule, etc..)
See the problem now?

Affirmation 5: You can extract keys from software player on personal computer but not on hardware player.

My comment: It's easier to extract keys from software player, but it also possible to extract keys from hardware player (the set-top box in your living room!)

Conclusion:

The attack I describe in "Affirmation 4", is not here yet, but it's coming. So I give MPAA and AACSLA a head start. Start to think what you can do about that.

To totally block this attack, they need to put different keys on every disk! Now, they only have different keys for different movies. I don't know about the manufacturing process of the disk. This solution may not be possible.

The best they can do, is doing shorter manufacturing run of a particular movie, so it would be difficult to get your hand on every "pressing" of a movie.

When they design AACS, they assume people will look for the device keys. I don't care about device keys. I do care about volume key. Having the device keys mean that you have to re-implements all the complex crypto and do the full AACS process.
I leave all this dirty job to the player and recover only the volume key.

There is 3 important things in cryptography:

1-Private key protection
2-Private key protection
3-Private key protection

Did I break AACS? I don't know. What do you think?

I'm not going to work on this anymore, I'm taking a vacation!

muslix64

2nd January 2007, 22:16

Ok, here it is, BackupHDDVD V1.00!

What's new in this version?

- Volume key support
- Partial resume of an interrupted decryption session
- New file format and file name for key database file.

The key database file is now KEYDB.cfg

You can download it here:

http://rapidshare.com/files/9942683/BackupHDDVDV100.zip.html
http://z13.zupload.com/download.php?file=getfile&filepath=59843

File name: BackupHDDVDV100.zip
File size: 22,429 bytes
SHA1 hash: 0d938a376133dfaf78ec47e6d41201d553a6bb81

This may be my last post here.

I'm going to have a rest for a while.

Take care everyone and wish me good luck!

2nd January 2007, 22:22

Nice! Thanks for your hard work... will be interesting to see where your efforts lead.;)

jp110099

2nd January 2007, 22:23

Thanks for the great program! I hope to get an xbox360 hd-dvd player soon.

zeroprobe

2nd January 2007, 22:28

any programs that helped you on your way?

Adub

2nd January 2007, 22:39

You rule Muslix64! Go and have a great vacation.

BUZZARD1

2nd January 2007, 22:40

Where do I go to get the drivers for my xbox360 hd-dvd drive? Also can some one confirm if power dvd 7.2 works with this or must I use 6.5.

zeroprobe

2nd January 2007, 22:41

again the keys are not posted, you gotta find them.

2nd January 2007, 22:47

Where do I go to get the drivers for my xbox360 hd-dvd drive? Also can some one confirm if power dvd 7.2 works with this or must I use 6.5.

You can always google "xbox 360 hd-dvd drive windows drivers"

We can confirm that PowerDVD can read EVO files but nobody has yet confirmed that that is the program that you need to use to extract the volume keys or title keys needed to decrypt the video.

noclip

2nd January 2007, 22:57

Great job muslix64!

As for the key, if it's not in memory it has to be in the CPU registers, right?

milh31

2nd January 2007, 23:10

muslix64 delivered what he promised

Dude thanks

zeroprobe

2nd January 2007, 23:46

it really is frustrating lol

its batman without robin
tea without sugar

Great work though, alot of effort gone in to it.

hechacker1

2nd January 2007, 23:47

I was reading the AACS spec sheets and found something interesting.

There is less than 1MB of space to store the revoked keys on any hd-dvd disc (at least in this revision of the spec). Which means in theory, if you succeed in getting enough keys, and the AACS adds them to the revoke list, eventually they will run out of space!

I think.. I am just trying to understand muslix64 comments by actually dwelling into the AACS spec.

I also think Powerdvd's reply is BS because they know they goofed up somewhere. We'll see if they suddenly push out an update. And as muslix64 said, the AACS spec doesn't require protection of the volume key, so it should always be obtainable, it's just a matter of the degree of difficulty.

DanITman

3rd January 2007, 00:06

Not even a hint to where the keys are :(

Oh well, thanks for all your work. If this thing blows up from here you will go down as the pioneer who started it all.

Thanks Man!

lazyn00b

3rd January 2007, 00:29

**** Sorry, but without even one working key this is nothing but speculation.

Sure, the BackupHDDVD program looks nice, but without verifiable proof that a volume key has been actually been extracted, this is nothing to get excited about.

Frankly, I now suspect that the youtube video is a hoax, and that muslix64 is just hoping against hope that some superhacker out there will figure out where PowerDVD HD hides the keys.

noclip

3rd January 2007, 00:40

The volume key has to be in the registers to calculate the CMAC value (and decrypt title keys). If you were to set a breakpoint on the routine that accesses the memory location of the CMAC, you would find the Volume key in the registers.

BUZZARD1

3rd January 2007, 00:57

If anything it got the community really thinking togeather on how to come up with a solution. So cheers to that.

MaXiMuS

3rd January 2007, 01:27

Jerky_san

3rd January 2007, 01:38

In the new FAQ it has changed a little bit..

-Where are title keys?

The title keys are encrypted on the disk.

-What is the volume key?

The volume key is the key used to decrypt the title keys. So the volume key is all you need to decrypt a movie.

-Where is the volume key?

The volume key is the result of several complex decryption process. Read AACS doc for more details.

The last being the most interesting to me.. I've been following all of your conversation.. I would buy an HD-DVD player and work all day on it but the fact of the matter is I'm broke and must work lol..

P.S. dang I really never posted since I registered lol?

edo1080

3rd January 2007, 01:58

GREAT MUSLIX64 !!! Thank you for your work, you've shown us the way, now we have to work on finding the keys. You have delivered what you promised, Thanks again.

The title keys are encrypted on the disk

Yes, but they are also in unencrypted form somewhere in the memory (according to the faq of the 1st vesrion released by Muslix64).

Jerky_san

3rd January 2007, 02:04

Yes but perhaps the other keys must be assembled with this "volume key". That or your going to be looking for a very long time.. At least he/she perhaps made it more simple for us since now we just must hunt down this "volume key" which maybe easier to find then hunting down a key that at one point is encrypted. But perhaps we are making it more difficult then it seems..

edo1080

3rd January 2007, 02:09

we are making it more difficult then it seems

Yes you could be right, anyway the only way I can figure right now is IDA PRO used with PowerDVD 6.5 and setting breakpoints when PowerDVD is loading the movie. IDA PRO lets you see the map of memory at the breakpoint and then you could start a search over all the 32 bits long words in memory and test them as title keys (if they are not too much) or test the words with length equal to the length of volume keys as volume keys. This is only an idea, but I haven't tested it yet and since this test will require a lot of time I don't know if I'll have the time before the end of CES

noclip

3rd January 2007, 02:20

Muslix64: You could say things like "I needed to use a debugger" or "I just looked at a memory dump" and you wouldn't be breaking any law.

Thanks and all, but it's a little bit suspicious of you to deliberately avoid saying anything at all. Are you or have you ever been a <strike>member of the Communist</strike> employee of the Sony Corporation?

woah!

3rd January 2007, 02:35

trbarry

3rd January 2007, 02:42

Well, I'm guessing that even in this day and age I'm personally allowed to speculate on how to decode the movies since I haven't read the AACS doc, don't really have a clue, and thus no information to divulge to anyone except general software principles.

But obviously given both a player and a disc the sum total of available info must be enough to play the movie. And, according to Muslix64's FAQ, both the ECC-160 and AES-128 algorithms are used for decryption purposes. If I had an army of abnormally dedicated programmers (I'm not asking for one here!) I'd disassemble a player (any player) and find the functions called to perform both decoding algorithms. Then I would set breakpoints at the beginning and end of them and see what data was being passed and returned.

But I do not own an HD DVD player, don't consider myself that sort of hacker, and have no intention of doing this. Nor am I sure Muslix64 did.

- Tom

blutach

3rd January 2007, 03:40

Thanks and all, but it's a little bit suspicious of you to deliberately avoid saying anything at all. Are you or have you ever been a <strike>member of the Communist</strike> employee of the Sony Corporation?Must I continue to remind members about rule 4?

Can we please discuss the technical and practical merits of this program without calling other forum members' reputations into question?

Regards

noclip

3rd January 2007, 03:55

Must I continue to remind members about rule 4?

Can we please discuss the technical and practical merits of this program without calling other forum members' reputations into question?

Regards

That was a joke. It's obvious that he doesn't want to say more to avoid being sued, not because he works for Sony.

blutach

3rd January 2007, 04:04

It didn't come across that way to me. I would appreciate it if members would not make such statements since they may be misinterpreted.

Regards

generalnewbie

3rd January 2007, 05:01

has anyone tested this to see the keys get extracted? i dont have a hd dvd addon or i would.

moshmothma

3rd January 2007, 05:11

Thanks muslix64 - this looks to be the start of something very cool! Have a good break.

Adub

3rd January 2007, 05:26

@GeneralNewbie
Read the thread! We have yet to find the keys first. BackupHDDVD does not provide the keys, we have to supply them. Well, we actually have to find them first.

ioakougroup

3rd January 2007, 07:54

********************

Its good news that some unreakable protections finally ...break...and melt like...ice cream in front of some smart hackers...persons like muslix64 are the meaning of this sharing community...That was the first step against that HDDVD AACS protection system...be sure that will be next... steps very soon...according to many reactions...!:lol:***********************

OverlordQ

3rd January 2007, 08:03

You know, reading over the AACS doc I dont think I ever saw a thing called a Volume key or anything similar.

generalnewbie

3rd January 2007, 08:15

@GeneralNewbie
Read the thread! We have yet to find the keys first. BackupHDDVD does not provide the keys, we have to supply them. Well, we actually have to find them first.

Sorry mate i had the assumption that the first release didn't tell you how to get the keys or the app, but i thought in his second release he would include in the app a method of obtaining the keys. I guess nothings changed and we are still left to figure out how to get the keys. So far i find this app useless until some more light is shed on getting the keys. I mean we are to understand that the data being read from memory is decrypted by the key. But how does one read Memory and what its doing?

calinb

3rd January 2007, 09:03

You know, reading over the AACS doc I dont think I ever saw a thing called a Volume key or anything similar.

Advanced Access Content System (AACS), Pre-recorded Video Book Section 3.3:

The Volume Unique Key and/or the Volume Variant Unique Keys are used to encrypt and decrypt the Title Keys stored on the pre-recorded media, in a manner that is described in the given Format-specific book of this specification.

aiataga

3rd January 2007, 09:19

You know, reading over the AACS doc I dont think I ever saw a thing called a Volume key or anything similar.

http://www.aacsla.com/specifications/specification_support/AACS_Spec_HD_DVD_and_DVD_Prerecorded_0_912_redline_to_0_911.pdf

3.4 Title Key File
An AACS Disc shall have at least one Title Key File (TKF) in which each Title Key data is
encrypted by AES-128E with Ku. Ku is the Volume Unique Key (Kvu).

... is the Volume Unique Key defined in the <i>AACS Pre-recorded Video Book</i>.

... The Player passes the ... to the AACS module which <b>has already generated</b> the Volume Unique Key.

zeroprobe

3rd January 2007, 10:23

would softice do the trick? Got all the tools just need the hddvd addon

vsv

3rd January 2007, 10:33

I searched more info about BackupHDDVD and have found interesting files.

[links deleted per forum rule 6]

OverlordQ

3rd January 2007, 11:24

Eh that's what I get for skimming lol, I saw Volume ID but I missed the Volume Key parts

karandras

3rd January 2007, 11:36

You don't have to make a search on volume key but on Volume Unique Key.
But i haven't found any interresting informations on how to get any keys.
I have all the hadware requirement to test. So if somebody have an idea...

hajj_3

3rd January 2007, 12:01

am i the only person who's completely confused??

hope you can bring out a new version soon muslix64, even if you only post here once a month like you did yesterday along with a new release.

hope 1.01 will have a windows interface, that would be cool!

i hope you can find the keys and release them on p2p!

p.s you should update the first post on this thread with the link to version 1.00 otherwise people who dont read all these pages wont know there is a new version out.

Hellreaper

3rd January 2007, 13:00

If this is real after all (I'm still not sure) then I'm getting it.

muslix64 has problems with his/her conscience.

muslix64 wants to show that he/she has found a weakness, but she/he does not want to be fully responsible for major piracy issues. (which would definately come up)

I don't believe muslix64 is afraight of getting caught.

evdberg

3rd January 2007, 14:24

Better pay attention to CLDShowX.dll library, it's the only file
with all necessary crypto functions (Rijndael aka AES, SHA1,
ECC) into.

On what grounds do you come to this conclusion?

Guest

3rd January 2007, 14:50

I searched more info about BackupHDDVD and have found interesting files.

Struck for posting warez. Don't do it again.

vsv

3rd January 2007, 15:15

neuron2
But how to know warez this or not?
In description of these files i can't see word "warez"...
Thank you.

Guest

3rd January 2007, 15:30

@vsv

Now you're posting off-topic. You can challenge strikes through proper channels.

zeroprobe

3rd January 2007, 17:21

we need somewhere to discuss and share everything on this.

generalnewbie

3rd January 2007, 18:55

From what ive gathered this info might be helpful to more info and ill share it here

Memory.dmp--you can generate the Memory.dmp file by holding CTRL on the right side of the spacebar while you press SCROLL LOCK two times. Not verified to work but someone said it may......

Windows XP Service Pack 2 Support Tools has a command called dumpchk that will verify the dump and display information about it. This command can be found in the Windows XP Support Tools. The easiest way to run it is to copy the dumpchk.exe into the same folder as the memory.dmp file.

IE c:\windows\memory.dmp

At a command prompt in this folder run the command “dumpchk memory.dmp”.

To really dig into the memory.dmp file you will need to use the Microsoft Debug Tools. You also need the correct symbols for the os that the memory dump came from. These can be downloaded here.
http://www.microsoft.com/whdc/devtools/deb...installx86.mspx
http://www.microsoft.com/whdc/DevTools/Deb.../symbolpkg.mspx

After all that is installed, open up the Debug program windbg. It can be found in the start menu. First set the symbol path, by clicking File, symbol path; and add the path that you installed the symbols to. Default is c:\windows\symbols.

To open up the memory.dmp file, select File, Open Crash dump. It will first show the same info that dumpchk displayed. To get more detailed info, enter this command: !analyze -v. This will display a much more detailed analysis of the problem. Some other useful things you can look at are the call stack (View, Call Stack) to see what system calls were being run when the crash occured, registers (view, registers) to see what registers were being used, and the actually memory (view, memory) to view the contents of the memory when the crash occured. You could also view the dissassembly to see what code was running.

CAFxX

3rd January 2007, 18:56

we need somewhere to discuss and share everything on this.

Then switch to some kind of darknet.
TOR hidden services or Freenet websites should do.

dukey

3rd January 2007, 19:26

Brute forcing the memory for keys should work. The title key or whatever is needed to actually decrypt the content of the disc will probably be stuck on the heap as aposed to the stack as it will probably need to outlive the scope of the decryption functions :p

Someone suggested the key will be in the registers .. well it will be eventually but i guess the key is probably bigger than the current x86 registers so probably easier to get it out of mem.

I can't really see how you can protect against this hack.

CAFxX

3rd January 2007, 19:44

I can't really see how you can protect against this hack.
TPM (sigh!)

Gradius

3rd January 2007, 19:45

You can just look @ C:\program files\CyberLink\PowerDVD (6.5 HD) and check what "some specific files" do.

I doubt is on registry, must be on memory (RAM).

I do not have a HD-DVD, nor HD-DVD movies, so I cannot try it by myself.

Gradius

3rd January 2007, 19:47

TPM (sigh!)

Keep the old good ones working, never buy ANY TPM/TPC compliant.

Lord_KiRon

3rd January 2007, 19:58

From what I had understood EACH AND EVERY HD-DVD TITLE has it's own volume key (or more).
Like "Superman" released in US has it's own volume key ,"Superman" released in Europe has it's own volume key , "Enter the dragon" released in US has it's own volume key, etc...
Morever even same title like "Superman" released in US can have SEVERAL volume keys like one for disks produced in October-November and one for disks produced in December-February, etc ...

This means for each HD-DVD disk someone will need to find a right volume key , not just once per player or even one per title.

This means this someone need to post it somewhere to be accessible by other users and therefor this someone can be sued.

Also since wast majority of users will not be able to extract Title key for every disk they put in their drive by themselves they will need someone to do it for them.

No Automatic key extraction software will be possible, let's say someone for example develop such software that uses speciffic version of PowerDVD (just for example it can be any other software player even on Vista 64 despite all the protections built-in) to extract volume key. Then very soon studios will block that player's key (so it will not play new titles at all) and PowerDVD will release new version with new player key.
So no reason to stick with old version and new version can't be "harvested" for keys automatically.

All the above means that probably same as with ISO "releases" one of two "industries" will develop :

1. "Indexing" sites that hold a lot of volume keys for different versions of the movies.

2. "Images" releases same as cracked games will spread on Torrent or other P2P networks with already decoded versions of HD-DVDs same way as now they "release" images of games with crack.
(This option I believe more feasible, after all what is 25 or even 50GB for Torrent ? And internet speeds continue to increase all the time).

In both cases it will be either professional programmers that will do the debugging (like now only few people in the world do software cracking) or people around industry steal volume keys (like now steal games before they even get released).

So that's my analysis on the future of HD-DVD (and probably BD too).
This means no "immediate" threat for studios, there will be no such programs as DVDDecriptor for DVDs that any kid can use at home to decrypt but in a long run - yes, AACS IS cracked.

I think for the studios it's again (like with CSS or/and region protected DVDs) the situation becoming worse then if no protection were used since legal user will have many limitations (streaming for example if forbidden etc) while pirates will have more "usable" versions.

noclip

3rd January 2007, 20:45

I have a theory for how to figure out where to find a key for any given player application after PowerDVD 6.5 HD gets revoked (you know it's coming).

Say you picked some HD-DVD available in stores today and figured out its keys via Muslix's PowerDVD exploit. You now have a copy of the decrypted key. You would then play back that same disk for which you already know the key in any other current or future HD-DVD playing application. You would then watch memory (knowing in advance the decrypted key) for the decrypted key to appear and remember the memory location where it was found.

Now you know where in memory decrypted keys are kept and you can play any other disk, go to the same memory location, and there's the decrypted key.

A program could easily be written to automate all of this.

Adub

3rd January 2007, 21:01

Good thought process. Except for that fact that we are not sure that Muslix64 even used PowerDVD to find the keys in the first place. Although it does look that way, we should totally assume anything.

maksa

3rd January 2007, 21:32

1. Task is to encript content and deliver it to the public without discovering the keys for decription.
2. At the same time they have to give you (user) the key in some form so you can watch the movie.
3. You own the player, soft or standalone and have acces to it.
4. If you have the acces to it, you could extract the keys or the algorithm in theory - everyhing should be there.
5. Main rule for authrized decription is not followed. Key is public on the media side, key is public on the player side.
Even encripted, they are accesible.
6. Only way to have message secure is to have user specific key that only he/she knows (public/private key scheme).
7. In this case "private" key is accesible (in some way) by "malevolent hacker'.
8. Logical conclusion is that there is now way to protect content available to all public in secure way. It is just matter of time spent to get there.
9. If we remember Enigma machine, only way English could decipher it was to get hands on code book and a machine. Germans changed the code, but too late, and the alghoritm wasn't changed for the compatibility reasons (sounds familiar for standalones). I am not saying that it couldnt be done brute force at the end, language is closed set and it has its own distribution and syntaxe, but it would take indefinite time.
10. AACS alghoritm was made public, keys are out there, so only logical conclusion is - it could be done!

I am not a programmer, have no clue how to do it, but please comment on above statements.
I figure, the only reason for content scrambling is to stop "average joe" to copy movies. Remember NagraVision 2, it was praised as unbrakable, Asian sat dealrs were offering 1M$ for a solution, I know (and you too) that money is collected.
The only way to secure something is to keep one part secret (totally, not encrypted in some form and accesible), either private key or algorithm, or content probability distribution. All else is just increasing workload. Having computers and smart hackers out there, even workload could be shortened.
just my 2c...
Regards...

Mtz

3rd January 2007, 21:33

And insecure players will always exist, in fact you can extract keys from any player! (by Muslix64)
Lanier's point was that AACS has the ability to revoke compromised keys. AACS can revoke a compromised key with future HD DVD releases.
The way keys are revoked is by putting the revocation information on future releases. For instance, if a title key is revoked, the revocation information is stamped onto all future HD DVD releases, every title. When the disc is inserted in a player for the first time, the player's memory is updated with the revocation information. At that point, the compromised title will no longer play. (Chris Lanier, a Microsoft MVP for Digital Media products)
Some of us can mod firmware of a standalone player, usually the Mediatek based. From this players the firmware can be extracted using a serial cable.
As Lanier said, if a player will be upgraded with some revocation, comparing the firmware after and before inserting new HDDVD disc will give us some informations. The wrong step from them is to release a disc which include revocation.
Another way is to read the memory dump from the player when inserting a HDDVD disc. I never made this type of dump, but some people already did it when hacking the Mediatek firmwares.

Edit: The title keys are used to decrypt media files. You can have up to 64 title keys on a disk. (by Muslix64) And all this 64 keys must to be in the player firmware, no? :D

enjoy,
Mtz

Lord_KiRon

3rd January 2007, 21:45

Mediatek does not have HD-DVD players (yet) , the current one is Toshiba which is basically PC which makes it easier to hack in.

The problem can be the OS they use, if it's something of their own if will be really hard to hack but if it's Windows or Linux based ... ;)

And all this 64 keys must to be in the player firmware, no?

Mtz , you not really fully understend what you talking about :)
Title keys is different from player keys , different from volume keys.

Mtz

3rd January 2007, 21:54

I knew that Mediatek not producing yet (or ever). But this Toshiba have a firmware.

enjoy,
Mtz

calinb

3rd January 2007, 22:02

Then switch to some kind of darknet.
TOR hidden services or Freenet websites should do.
Or perhaps I2P. The "Off Topic" area of the I2P forums would be one place to start a thread to discuss further communications options, while keeping the doom9 thread "on-topic." :) There may be other I2P sites that would be appropriate and I2P seems to be working better, of late, and could certainly use more users. But yes, it would be nice if someone could anonymously host a forum using Tor hidden services or I2P.

NghtShd

3rd January 2007, 22:08

I've been chomping at the bit to post (had to wait 5 days after registering).

I'm very surprised that muslix64 has been taken so seriously on the flimsiest of evidence. I actually had to laugh when I saw that Reuters had picked up the story. Granted, muslix64's story could be legit, but so could anyone else making the claim and offering no evidence. It's nice to see a few more doubters over the last few days.

Don't be fooled by some code that hashes the title key file and then twiddles bits. The code could be 100% legitimate and fully capable of decrypting the movie, but what does that prove other than that muslix64 was able to put together a java app using some standard decryption libraries.

I'm also bothered by the vague references to finding the key in memory. Why not be more specific? Why not say when X function is called the stack contains the key, etc? Why conveniently pop up, answer no question, conveniently pop up again, answer no question, then conveniently take a vacation? He says that the key was easy to find, so could this be the reason he didn't think he needed to offer any more help? If so, one would think someone else having the decrypt code all done for them could have verified the story.

Would anyone have taken this story very seriously if it were just a video on youtube? If not then you probably shouldn't be taking it seriously, because that's basically all it is. What muslix64 has added is some unverifiable code (without the key it does noting useful) and he has popped into this forum and said virtually nothing. So what do we have as evidence? I'd say nothing.

I've looked at some of the calls to crypto routines in the DLL mentioned earlier in the thread. All I see is some stuff doing secure key exchanges and key BLOBs (which you can search for on MSDN). I don't claim to know how this stuff works or how you could ever use a key without it being in the clear in memory at some point unless the decryption is done in hardware. What hardware would that be, though? What are the hardware requirements for HD and BD DVD? Does it require a video card with HDCP to play at all and if so is the decryption done in hardware on the card?

The PowerDVD people claim the key is not kept in memory. Could they be lying? Yes, but if so they'll eventually be caught in a lie. Since keeping the key in memory would be an obvious and huge security hole, their story seems more believable than muslix64's claim (which he offers no evidence for).

Another question I would have for muslix64 if he weren't "taking a vacation" is, why hash the entire key file in the first version of his app? Couldn't the encrypted title key in that file have been used as an ID avoiding the sha1 hash? Was it simply a design choice?

calinb

3rd January 2007, 22:32

Does it require a video card with HDCP to play at all and if so is the decryption done in hardware on the card?No. An HDCP capable card is not required. However, the VGA output res may be scaled down. Given that a specific card is not required, it's doubtful the card plays a role in decryption.

The PowerDVD people claim the key is not kept in memory. Could they be lying? Yes, but if so they'll eventually be caught in a lie. Since keeping the key in memory would be an obvious and huge security hole, their story seems more believable than muslix64's claim (which he offers no evidence for).Well--how many places have we identified as potential places to find the key (regardless of liklihood)?

1. Main DRAM memory. (The obvious place).
2. Files/Registry.
3. CPU Cache (unlikely to remain there--under Windows memory mgmt.) Disable cache.
4. CPU Registers (ultimately and fleetingly, a certainty)
5. FPU Registers (at 80 bits maximum, how likely?)
6. Swap files. Disable virtual memory.
7. On the HD-DVD drive. (Seems unlikely across the USB interface and do drives have any volatile/flash memory?)

Another question I would have for muslix64 if he weren't "taking a vacation" is, why hash the entire key file in the first version of his app? Couldn't the encrypted title key in that file have been used as an ID avoiding the sha1 hash? Was it simply a design choice?The answer should be in the AACS spec but the problem may be in deciding which title key to use to ID the disc. Title keys could be "mix and match," depending on manufacture and origin. Better to ID using all the keys to determine an ID match. (Not referring to the AACS "ID" here.)

noclip

3rd January 2007, 22:34

Simply put, for any decryption to be done a key must be kept somewhere in either memory or the CPU registers. Even if it's obfuscated in memory it must be in the clear in the CPU's registers at some point.

noclip

3rd January 2007, 22:44

My take on the possible locations:

1. Main DRAM memory. (The obvious place).
Cyberlink denies it but they have a pretty big vested interest. This is very likely.
2. Files/Registry.
At the lowest level, the key would still have to be loaded into memory and ultimately registers to use it, so this possibility can be ignored with 100% certainty.
3. CPU Cache (unlikely to remain there--under Windows memory mgmt.) Disable cache.
Unless Cyberlink developers are on crack, we can be sure it's not here.
4. CPU Registers (Ultimately and fleetingly, a certainty)
A breakpoint on the decryption routine would discover it here, this should be the top priority.
5. FPU Registers (at 80 bits maximum, how likely?)
Can be safely assumed not to be the case.
6. Swap files. (Disable virtual memory.
This should be pursued as a second priority after CPU registers.
7. On the HD-DVD drive. (Seems unlikely across the USB interface.)
Extremely unlikely. I almost want to say it can be safely ignored.

NghtShd

3rd January 2007, 22:57

The answer should be in the AACS spec but the problem may be in deciding which title key to use to ID the disc. Title keys could be "mix and match," depending on manufacture and origin. Better to ID using all the keys to determine an ID match. (Not referring to the AACS "ID" here.)

Yeah reading the doc is what caused me to ask the question. Upon revisiting it I see that there are/can be multiple keys (up to 64?), so I suppose just hashing the entire file might be easier.

calinb

3rd January 2007, 23:11

(WRT: files/registry)
At the lowest level, the key would still have to be loaded into memory and ultimately registers to use it, so this possibility can be ignored with 100% certainty.My point here isn't about any single location, but yes, there are places that can be ignored without precluding the finding of a solution. However, should they be ignored? Some places are easier to observe than others. Most commercial binary code isn't all that easy to observe and debug--even with SoftICE. Both observability and probability should be considered. :)

DanITman

3rd January 2007, 23:26

No. An HDCP capable card is not required. However, the VGA output res may be scaled down. Given that a specific card is not required, it's doubtful the card plays a role in decryption.

I just wanted to comment on this part. I attempted to play an HD-DVD using the same exact software as seen in the YouTube video. When I load the movie and push play the Universal logo starts to come up (the one with the globe and sun beams) a few seconds into this small clip the movie shuts down and gives me a message that says I cannot view the video due to certain restrictions. So it actually doesn't even downsize the resolution, it just won't let you view it. I assume this is when some sort of HDCP checks are taking place.

I am willing to do more research from here if people are willing to help me. I am running the same exact setup as the youtube video shows except I don't have copies of the movies that were used. I have a copy of Data Rescue Pro but I have no clue how to use it.

toytown

3rd January 2007, 23:38

7. On the HD-DVD drive. (Seems unlikely across the USB interface and do drives have any volatile/flash memory?)

As far as i know, the xbox 360 HD-DVD addon, does come with some flash memory, if you plug it into windows, its meant to show up 2 devices (1 the drive, and 1 memory)

EDIT - These are the 2 devices which show up when plugging into a mac/pc

XBOX 360 HD DVD Memory Unit
XBOX 360 HD DVD Player

NghtShd

3rd January 2007, 23:39

Well--how many places have we identified as potential places to find the key (regardless of liklihood)?

1. Main DRAM memory. (The obvious place).
2. Files/Registry.
3. CPU Cache (unlikely to remain there--under Windows memory mgmt.) Disable cache.
4. CPU Registers (ultimately and fleetingly, a certainty)
5. FPU Registers (at 80 bits maximum, how likely?)
6. Swap files. Disable virtual memory.
7. On the HD-DVD drive. (Seems unlikely across the USB interface and do drives have any volatile/flash memory?)

I think we can ignore all of those places other than RAM if we are to believe muslix64, because he said 1) it's in RAM and 2) it's easy to find (which implies that it probably isn't obfuscated).

If we aren't to believe him then we're at square one. We don't even know which player, if any, is a viable target. Personally, I think we are at square one.

I'm interested in the secure key exchange stuff. I've just started reading the AACS docs which so far haven't given me a clear picture of the sequence of event's which occur when a movie is played using a PC. Is it possible that the primary decryption is done inside the HD-DVD drive and the secure key exchange is for streaming encrypted compressed video to the player using the player's public key?

honai

3rd January 2007, 23:50

Guess it's time to help you guys out ...

So far we know that somewhere in the vast place that makes up the memory of our computers there must be a code piece that feeds keys into a decryption algorithm. These keys may or may not be "in the open", i.e. residing in unprotected data pages. One possible attack vector might be to inspect the kernel mode driver that Cyberlink PowerDVD 7.x installs.

However, the biggest challenge so far has been to identify the key data portion (volume/title/etc). It seems that some people in this and various other boards - most of them being of the non-technical nature - believe that Cyberlink conveniently stored them in memory as an easily detectable string, like "YO HAX0R DIS IZ DA KEY: 8F902A...". Not so. The key is a sequence of 8-bit values with no deterministic characteristic, i.e. it will look completely random (in the cryptographical sense).

But all hope is not lost. The biggest strength of AACS - relying on proven and secure cryptography - is also its weakness. What muslix64's code, unfortunately, obfuscated due to its reliance on a Java-internal cryptography library is the fact that AES-128 (or AES-Rijndael, as it is called) uses - apart from some discrete algebra - several sets of constants, namely:

the Rijndael round constants Rcon in the Rijndael key schedule: http://en.wikipedia.org/wiki/Rijndael_key_schedule
the Rijndael S-box http://en.wikipedia.org/wiki/Rijndael_S-box

These constant sequences must occur in every implementation of AES-Rijndael since AACS mandates the use of standard implementations of AES-Rijndael.

So start looking for occurences of 0x637c777b or 0x8d010204 (possibly with reverse byte-order), and trap/breakpoint the code that uses that data, then you'll have found the AES-128 decryption routines. The Rijndael key schedule is especially noteworthy since it's being fed the decryption key directly ...

calinb

3rd January 2007, 23:52

the movie shuts down and gives me a message that says I cannot view the video due to certain restrictions. Did you try disabling video acceleration in the player? I remember reading that hint somewhere.

aicjofs

3rd January 2007, 23:56

If we believe all this to be true, doesn't the author say in memory numerous times? I can't imagine he wouldn't say registers, if in registers, etc

i.e.

from post 244

The AACS spec says "Device keys must be protected!" so I suppose they put more effort in protecting these keys then the volume key in memory.

again in the saga.txt

December 13:

Now I focus only on title key. I was very surprise to realize that the title key is there, in memory! Can it be
that easy? I don't believe it. Around 7PM, I decrypt my first movie "pack". Around 11PM, I have now a totally decrypted
movie! But there is a problem. Frame skipping.

Then there is the problem with

* Secondly, PowerDVD does not keep "Title Keys" in system memory. Cyberlink is not sure how the user got the Title Key and notes that the released tool nor the video on YouTube provides the information on obtaining the Titles Keys.

So how many software players are compliant if it wasn't powerDVD, (can't be that many available yet)? Of course they mention nothing of volume unique key...

I suppose it would help if we knew the experience level of our poster.

It took me about a week to do. But I have wasted few days
trying to work on too complicated approach. In fact, it is very simple.

Simple for who? Someone with years of assembly language understanding? Someone who has studied encryption? etc

He seems to drop a hundred hints

-How do you extract title/volume keys?

I won't explain it in detail. Read the AACS doc first. You will understand.
The title keys are located on the disk in encrypted form, but for a
content to be played, it has to be decrypted! So where is the
decrypted version of the title/volume keys? Think about it...

or

There is 3 important things in cryptography:

1-Private key protection
2-Private key protection
3-Private key protection

but I have browsed through all the documents/specs, and volume unique keys descriptions are all over the place, in this document and in that one. It could be all a joke, but very elaborate none the less, he would have done alot of studying to not have made a mistake that one of us would have found by now.

Wookie Groomer

4th January 2007, 00:55

PowerDVD 6.5 must be used to do this, none later.

4th January 2007, 00:58

PowerDVD 6.5 must be used to do this, none later.

You speak from experience or you read that somewhere?

rmtaibo

4th January 2007, 00:58

It's a puzzle that Muslix64 invited us to join...
Every one could had a piece...
Who's the guilty????
All the community!!!

So, All the comummunity can't go to jail...

rmtaibo

4th January 2007, 00:59

He He He...

Someone can say:
BD you're the next in the list...

ridesideways

4th January 2007, 01:32

i can't believe there is so much speculation and hype about this HD-DVD decrypter that muslix64 has written.

all the guy did was write an implementation of an AACS decrypter in java, and he posted the source code. THIS IS NOT A DIFFICULT THING TO DO FOLKS-- YOU CAN DOWNLOAD THE DAMN SPEC FROM A PUBLIC WEBSITE FOR GODS SAKE. since i am a software engineer, i would write same damn program in a week too, and so could every other software engineer in the world worth his salt.

ah but there is more to the story. muxlix64 goes on to claim that he's extracted volume keys from his HD-DVD disks-- now that is one hell of a claim and actually takes some skill. BUT HE PROVIDES NOT ONE SHRED OF PROOF THAT HE'S ACTUALLY DONE THIS. anyone with a camcorder could make a you-tube movie with a blacked-out text screen where one claims to have secret volume keys.

until someone provides real evidence that they can reliably extract volume keys from an HD-DVD player, this whole damn thread is all one gigantic waste of time.

let's recap:
muslix64: i wrote an aacs decrypter.
me: *yawn*
muslix64: and i've extracted volume keys from my HD-DVD's
me: wow that's amazing, show me.
muslix64: no
me: *yawn*

MacAddict

4th January 2007, 02:02

lol...lots of new posters on the board now.

Gradius

4th January 2007, 02:35

Who's the guilty????
All the community!!!

So, All the comummunity can't go to jail...

WRONG, the Studios, Hollywood, DRM, MPA, Buena Vista, etc, they're the one to blame. Why they created such unfair system? Why not to sell those HD discs for $3 bucks or less?

They're selling less now the DVD can be copied? HELL NO! In fact, they never sold so much before!! :sly:

wakebrder

4th January 2007, 03:49

I just wanted to comment on this part. I attempted to play an HD-DVD using the same exact software as seen in the YouTube video. When I load the movie and push play the Universal logo starts to come up (the one with the globe and sun beams) a few seconds into this small clip the movie shuts down and gives me a message that says I cannot view the video due to certain restrictions. So it actually doesn't even downsize the resolution, it just won't let you view it. I assume this is when some sort of HDCP checks are taking place.

I got this same result using my Dell 700 Inspiron. On "The Thing" the Universal Logo plays for a few seconds then gives the message "this content is protected, playback cannot continue." This is with Power DVD 6.5. I wouldn't think HDCP would be relevant on a laptop?

DanITman

4th January 2007, 05:27

Did you try disabling video acceleration in the player? I remember reading that hint somewhere.

Negative, it didn't help. Still got the same error.

I'm interested to figure out why this error is occurring. Maybe I'll try to do a memory dump right when I get the error to see if I can find anything.

woah!

4th January 2007, 05:36

Negative, it didn't help. Still got the same error.

I'm interested to figure out why this error is occurring. Maybe I'll try to do a memory dump right when I get the error to see if I can find anything.

do you have the dvi connected to something aswell as the vga?

i had the same issue until you unplug one and have only one output out of the card.

i had the same issue over hdmi gcard which i had connected via vga to my monitor aswell.... another hassle this HDCP will now cause me as i have to pull the vga to watch over hdmi to my plasma tv.... i aint buying anymore hd-dvd's until this is sorted out either...

woah!

4th January 2007, 05:54

I got this same result using my Dell 700 Inspiron. On "The Thing" the Universal Logo plays for a few seconds then gives the message "this content is protected, playback cannot continue." This is with Power DVD 6.5. I wouldn't think HDCP would be relevant on a laptop?

why would you think HDCP isnt relevant on a laptop? that is the main reason they want it is so you cant move it around. you need a HDCP monitor or screen and a HDCP video card.

the consumer has to take another movie industry move right up the ass...

4th January 2007, 10:14

If you want to see why powerdvd may not be playing HD-DVDs try downloading the Cyberlink HD Advisor. It will check your system and let you know what components you need to upgrade to achieve playback:

http://www.cyberlink.com/multi/support/bdhd_support/diagnosis.jsp

I wanted to try and search for the keys but according to this program I can't playback HD because I need to upgrade my 2 (SLI'd) Nvidia Quadro 4500's (~$2000) to a $200 FX7600GT :rolleyes: because it supports HDCP.

I can't wait till someone cracks this DRM/HDCP/AACS crap.

OverlordQ

4th January 2007, 10:26

jarlen

4th January 2007, 10:26

I think we have some clues here:

If we believe all this to be true, doesn't the author say in memory numerous times? I can't imagine he wouldn't say registers, if in registers, etc

i.e.

from post 244
The AACS spec says "Device keys must be protected!" so I suppose they put more effort in protecting these keys then the volume key in memory.

again in the saga.txt

Quote:
December 13:

7. On the HD-DVD drive. (Seems unlikely across the USB interface and do drives have any volatile/flash memory?)

Now I focus only on title key. I was very surprise to realize that the title key is there, in memory! Can it be
that easy? I don't believe it. Around 7PM, I decrypt my first movie "pack". Around 11PM, I have now a totally decrypted
movie! But there is a problem. Frame skipping.

Then there is the problem with

Quote:
* Secondly, PowerDVD does not keep "Title Keys" in system memory. Cyberlink is not sure how the user got the Title Key and notes that the released tool nor the video on YouTube provides the information on obtaining the Titles Keys.

So how many software players are compliant if it wasn't powerDVD, (can't be that many available yet)? Of course they mention nothing of volume unique key...

I suppose it would help if we knew the experience level of our poster.

I put this togheter with these 2 posts:

27th December 2006, 20:00 muslix64

I have a XBOX 360 external USB drive on my PC.

Yesterday, 23:38 toytown

As far as i know, the xbox 360 HD-DVD addon, does come with some flash memory, if you plug it into windows, its meant to show up 2 devices (1 the drive, and 1 memory)

EDIT - These are the 2 devices which show up when plugging into a mac/pc

XBOX 360 HD DVD Memory Unit
XBOX 360 HD DVD Player

No one reckons that the key is actually kept in the HD-DVD disc-reader itself (in its memory)?

Like the key they try to hack out of XBOX360 games (where an "ok"-signal is sent from the player to the rest of hardware when key is decrypted), they have used a hacked firmware to always send the "ok"-signal. I know this is not the same cryptation and security system. But the idea of having the disc-reader itself approve the disc would be the same.

jarlen

4th January 2007, 10:38

In addition to the post above i also found this on a website:

From majornelson.com: If you have picked up the Xbox 360 HD DVD Player you have probably noticed that in addition to the unbelievable picture and sound quality, you now have 'HD DVD' as a new storage device section under Memory on your System Blade of your Xbox 360's Dashboard. I have gotten a few emails asking me what this is and more specifically if it can be used to store game content, arcade titles etc. The answer is you can't. You can only delete items from this memory area, not add them. In fact, games won't even 'see' this area...so for the most part you'll never come across it, but I wanted to explain exactly WHAT this area is. This memory area is part of the HD DVD spec and it only accessible by the Xbox 360 HD DVD player when using the advanced features of the HD DVD format. For example, if you lay down any bookmarks from the HD DVD's that you rent from from Netflix, then you'll use the Memory section of the System blade to delete that content, since it would stand to reason that you don't need the information again since you rented the disc. Unfortunately, none of the current HD DVD's properly tag their data..so for the short term all you'll see is 'Unknown Title.' Remember: Not every HD DVD has the same advanced features, so check the back of the HD DVD packaging (Example) to see what each title supports.

http://www.majornelson.com/archive/2006/11/16/xbox-360-hd-dvd-player-memory.aspx

This picture shows that the memory on the drive is about 200mb (enough for lots of titles)
http://www.flickr.com/photos/majornelson/298947903/

NghtShd

4th January 2007, 10:44

pacman2006

4th January 2007, 11:07

I think we have some clues here:

I put this togheter with these 2 posts:

No one reckons that the key is actually kept in the HD-DVD disc-reader itself (in its memory)?

Like the key they try to hack out of XBOX360 games (where an "ok"-signal is sent from the player to the rest of hardware when key is decrypted), they have used a hacked firmware to always send the "ok"-signal. I know this is not the same cryptation and security system. But the idea of having the disc-reader itself approve the disc would be the same.

I think you're on the right track here. Muslix64 said that it was very easy to get the key from memory. It makes perfect sense that the key is actually in the extra memory device that XP mounts, when the drive is attached.

But it probably also means that only Xbox360 HD drives will work, since internal drives will have this memory more hidden.

NghtShd

4th January 2007, 12:24

I think you're on the right track here. Muslix64 said that it was very easy to get the key from memory. It makes perfect sense that the key is actually in the extra memory device that XP mounts, when the drive is attached.

But it probably also means that only Xbox360 HD drives will work, since internal drives will have this memory more hidden.

I don't think that makes any sense at all. What good would the key do there. If the PC needs it for decrypting it needs to be in RAM or a register (something directly accessible by the CPU). If the drive does the decrypting it needs to be in the drive's memory or a hardware register.

Hellreaper

4th January 2007, 12:31

Best hoax of 2006 - and maybe 2007.

(Don't worry, this is my final post in here)

pacman2006

4th January 2007, 15:19

If the drive does the decrypting it needs to be in the drive's memory ....

If I read the previous posts correctly, then this IS the drive's memory. The drive was made for the XBox360 and maybe this was the easiest way to implement the memory storage needed as per the HDDVD specs.

DanITman

4th January 2007, 15:19

I think you're on the right track here. Muslix64 said that it was very easy to get the key from memory. It makes perfect sense that the key is actually in the extra memory device that XP mounts, when the drive is attached.

But it probably also means that only Xbox360 HD drives will work, since internal drives will have this memory more hidden.

This is highly unlikely. The extra memory is the memory in the HD-DVD drive that saves Bookmarks for films. You can bookmark a scene and it will save it for you so you can back to that scene when you put the disk in again. They would also be breaking critical AACS rules by doing this.

JK1974

4th January 2007, 15:37

You are all talking about the Xbox360 HDDVD drive´s memory. Do you actually have one attached to your PC? If I remember correctly, when I connected the drive for testing some weeks ago, only a driver for reading the file system was found and installed, not for the memory unit etc. - those drivers were not delivered with the hacked driver package and could not be installed if I recall correctly. Everytime booting up XP asked for drivers for this...
Furthermore I was told, that this driver packages that went around in the net just included the UDF 2.5 drivers which you might also get if you install the latest Nero InCD version.
Unfortunately, I don´t have this drive anymore and neither can continue testing nor say for sure that there was no driver installed for the memory unit.

jarlen

4th January 2007, 15:44

El_Servas

4th January 2007, 17:56

This is gonna be good.

Beastie Boy

4th January 2007, 18:02

This is gonna be good.

Great first post. :D

j10

4th January 2007, 18:42

Hi Guys

Here is a mirror for the Software
http://www.backuphddvd.net

DanITman

4th January 2007, 19:20

I maybe was out of line, but it makes perfect sense.
Microsoft maybe never intended that some PC would read that memory..

1.) Yes, I actually have an Xbox 360 HD-DVD Drive

2.) MS is well aware that people were going to hook these up to PC's. Lets see.....it uses a standard USB cable and it's actually just a normal IDE HD-DVD drive inside a plastic hull.

If they didn't want people to hook these up to PC's they would have made it much harder to do.

DanITman

4th January 2007, 19:22

tekno5

4th January 2007, 20:25

still think its not a HOAX then

try to play a hd dvd disc like muslix64 did by clicking on the file
'FEATURE_1.EVO'

all you get is a blank/black screen with no film footage and some
audio clicks/buzzes as not all of the keys are present.

to play a hd dvd disc you need to go to the 'ADV_OBJ' folder
then click on one of the 'VPLST000.XPL' files as this has the first key needed
to play the footage and is also the order in which the hd dvd disc plays.

Regards.

generalnewbie

4th January 2007, 20:49

i think the video is fake. I just watched it again to see how it was directed and its done in the manner to hide certain things. I would say if we could see more of the file sizes at point 43 seconds to verify the file sizes from the previous points in the movie then we would know he didn't alter the drives.. Its pretty easy to name CD rom drives from F to G and so forth. Whos to say he didnt name his HD DVD rom G and copy it to his hard drive which is M:\ and then to fool everyone changed his hd dvd rom name to M and the HD back to something else?

Mtz

4th January 2007, 21:09

My second post regarding Muslix64 nick. ;) musli > ilsum = "A function that counts the total number of true values in a vector declared LOGICAL. It returns zero if the number of elements, N, is less than one." Source. (http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0530&db=man&fname=/usr/share/catman/p_man/cat3/complib/ILSUM.z)
Even all this is a fake, this guy is smart.

enjoy,
Mtz

hechacker1

4th January 2007, 21:12

This is highly unlikely. The extra memory is the memory in the HD-DVD drive that saves Bookmarks for films. You can bookmark a scene and it will save it for you so you can back to that scene when you put the disk in again. They would also be breaking critical AACS rules by doing this.

I don't think the key is in the hd-dvd drive's memory either.

If the decryption was taking place in the hd-dvd drive, then the data sent from it would already be unencrypted. You could simply save that stream..?

lol, we need more hackers to actually try and debug the code (although I bet powerdvd's eula says something along the lines of not being allowed to reverse engineer their software)

noclip

4th January 2007, 21:23

...although I bet powerdvd's eula...

BAHAHAHAHAHAHAHAHA!

*breath*

AHAHAHAHAHAHAHAHAHA!

Seriously though, PowerDVD's EULA probably prohibits you from using it to watch movies. No doubt reading this thread, much less participating in it is a violation too.

4th January 2007, 21:24

Yes, I own one. It uses flash memory to keep track of bookmarks in movies. With the right drivers this flash memory can be read. I'm pretty sure if you take the time to hunt down drivers your going to find nothing in there. Toshiba would have never let this out of the door if they were trying to hide keys in there.

Actually Microsoft provides the drivers for the memory. If you are running windows XP go to windows update (http://windowsupdate.microsoft.com) and do a custon update. In the hardware section you will see: "xbox 360 hd dvd interface". From there you can install the drivers. I installed them on my laptop and it did not make the memory available as a hard drive or anything. In the system devices the ""xbox 360 hd dvd interface 0 & 1" is listed under the USB root hub section rather than showing up with the yellow exclamation point. I don't know where to go from here.... :confused:

Borg_Collective

4th January 2007, 22:18

Awwww No

Things just got a bit more difficult

Warner Bros., which helped popularize the DVD more than a decade ago, plans to announce next week a single videodisc that can play films and television programs in both Blu-ray and HD DVD, the rival DVD technologies.

http://news.com.com/New+disc+may+sway+DVD+wars/2100-1041_3-6147053.html

I must admit I've followed this thread since seeing info
posted on a news site.

Even on New Years eve I was on the phone with a colleague
about it.

Time for me to "Re-Generate" for a bit
I'd think the "KEY" to this is in the AACS Documentation
Read, Read and then Re-Read it.

Thats what I recomend, time to "RE-GENERATE"

Syris2k4

4th January 2007, 23:58

The process to update Title Key File is as follows:
1. Decrypt all the Title Key(s)
2. Modify Title Key File
3. Update Title Key File Generation and Title Key File Nonce
Update Title Key File Generation to increment the value by 1 and regenerate three Title Key File Nonces
4. Re-encrypt all the Title Key(s) and store TKF_X

Are you talking about that? or is the lack of sleep completely raping my ability to read your "hint"?

DanITman

5th January 2007, 00:21

tonyp12

5th January 2007, 02:17

I think what they are refering to (I may be wrong) is a dual sided disc. On one side you will have an HD-DVD image and on the other a Blu-Ray image.

I would say so too.
And I hate when you have no logo on disc, it's so hard to read that tiny hub what movie title it's and what side goes up.

That the problem with 16:9 and 4:3 dual sided DVD now.

Gradius

5th January 2007, 05:06

I read that on news:

"But still, the hack can be blocked by adding different keys on every disk. Currently, the mastering houses use different keys for each movie title (title-specific security code). The Blu-Ray Association could partially have an answer to this, at least by preventing the replication of the Blu-Ray content on blank BD media. They have included the so-called "ROM-Mark" as an extra security feature on blank Blu-Ray discs. The ROM-Mark was designed to prevent the casual copying from BD-ROM to recordable media. It is an analog level mechanism for bit-by-bit copy protection. The ROM-Mark requires special machinery in the disc mastering process in order to be inserted on disc and thus, it could prevent malicious replications.

Reading these thoughts, someone might claim that the Blu-Ray camp could have some benefits over the rival HD DVD. We await the official response to these claims from Toshiba and Sony with great interest."

About Sony/BD with that ROM-Mark begin analog is pure BS, everyone with good ASM knowledge can hack the firmware on drive to ignore that mark forever.

JVz

5th January 2007, 07:35

When is 1.0 coming out?

CoZZm0

5th January 2007, 07:44

It already is. But you still need to find out how to get the keys yourself.

christopherw

5th January 2007, 08:42

This place reserved for future words of wisdom

I do hope that this turns out to be verifiably functional though, I'm all for HDDVD over BD (for a variety of reasons, we all have them) and if it became possible to strip out the restrictions so I could watch them over DVI on my nice Bravia from my PC, I think I'd buy even more discs than I would otherwise!

...Yeah, I already own HD-DVDs of some of my favourite films, and I don't even own an HD-DVD player yet! Talk about nutter. X360 drive on the way a little later this year. :D

cyber1

5th January 2007, 10:05

I dont understand people who thinks this is a hoax just because he did not release any keys, if he released the software with keys he would break the law.

I have been in contact with another person who has found the key also...

Since I dont have any Xbox HD-DVD I cant confirm this.

AndreLi

5th January 2007, 11:21

Its finally happened - Who yaaaa - I read a article on CDRInfo about it.
Kick A#$

CoZZm0

5th January 2007, 12:55

Its finally happened - Who yaaaa - I read a article on CDRInfo about it.
Kick A#$

Nothing to see or its already been removed if posted in the forums. I guess what will happen now is as "proof" for this is posted, it will be cleansed from forums etc just as quickly to ensure that there are no legal ramafactions for the hosting sites.

tjf

5th January 2007, 13:16

Is this http://www.hardforum.com/showpost.php?p=1030429406&postcount=56 the only public confirmation?

feizex

5th January 2007, 13:56

Hi Guys,

Finally I can post! 5 days is a long time. ;)

I have been following this mostly out of curiosity.

Here's some speculation...

Enjoy!
FEIZEX.

Personally, reading the FAQ makes it sound convincing - what con artist would think up bugs for their fake solution like the following extract which says that a fast forward function doesn't work??? If it is fake then this is more clever than actually having found the keys - what a psycho!

"What are the side effects of the "Nav chain" bug fix? You cannot do fast forward, or backward using the round dial, but you can still use the progress bar to navigate through the film. So it’s not that bad. For some reason, the sub-titles don’t seems to work anymore. It may be a side effect of the nav chain bug. But may be not."

And just like every other engineer he can't help but add bells and whistles...
"I want to go further in the decryption, so I decide to track down the "Volume unique key" instead of title key. I found it also! I'm preparing BackupHDDVD V1.00, that will support volume key and title keys."

And then...
"What's new in this version?

- Volume key support
- Partial resume of an interrupted decryption session
- New file format and file name for key database file."

Seriously folks why the &*(%# would you bother adding a resume function if you knew that noone was going to use it???

Oh and all you who say he's done nothing. Well that's not true. He did what he claimed. He wrote a decrypter. It's useless you say - the AACS spec is public - anyone could write the program, the problem is we don't have the keys. EXACTLY. This is his way of saying - you're not pinning anything on me. His last word on this "BackupHDDVD is a proof of concept."

Seriously he can't be the only person in the world smart enough to figure it out. He's given enough clues.

He has however made one contradiction...
"I did not break AACS"
and then in the same post...
"Did I break AACS? I don't know."

What a glaring error - he must be a fake! :P

BTW, all you that think it is definitely PowerDVD 6.5 remember he did mention he owned another...
"But when I realized the 2 software players on windows don't allowed me to play the movie at all" - Muslix64

Once you find a way to get the keys, the next step would be to bypass the revocation mechanism. It could be as easy as swapping greater than for less than on the revocation list version number comparison mechanism (if you can find it) so that it keeps the first one it sees and no others...

Extract from spec AACS spec:
"The drive shall keep the highest-version-number Host Revocation List Record it has seen. (The version number is found in the previous Type and Version Record.) During authentication, the drive shall check that the Host ID in the Host Certificate is not in its host revocation list. These first two records combined together, i.e. the Type and Version Record followed by the Host Revocation List Record, are also referred to as a Partial Media Key Block or Partial MKB for the purpose of storing the HRL in the drive."

http://www.aacsla.com/specifications/specs091/AACS_Spec_Common_0.91.pdf
page 30

There have been questions over what the Flash on the disk does. Well here is one clue...
"4.8 Updating Host Revocation List in Non-volatile Memory of Drive ..........................................39"

There is still confusion surrounding the Volume Unique Key, Volume Variant Unique Key (Kvvu), the Volume Identifier and the Title Key.

So far as I can tell, the Volume Variant Unique Key (Kvvu) is different to the Volume Unique Key (Kvu).

We don't care about the variant key. Maybe someone else can confirm this?

Info comes from: Advanced Access Content System: HD DVD and DVD Pre-recorded Book
http://www.aacsla.com/specifications/AACS_Spec_HD_DVD_and_DVD_Prerecorded_0_912.pdf

Here's what can be done with the Volume Unique Key (Kvu)...

3.4 Title Key File
An AACS Disc shall have at least one Title Key File (TKF) in which each Title Key data is encrypted by AES-128E with Ku. Ku is the Volume Unique Key (Kvu). Title Key Files on an AACS Disc shall reside in the “AACS” directory.

This is also not to be confused with the Volume Identifier...
"2.3.3 Volume Identifier
Each side of an AACS-Protected HD DVD-Video ROM medium shall contain one and only one Volume Identifier (IDvolume) of 128 bits."

The docco adds confusion when it says...
"Each Title Key can be decrypted using the Volume ID" - true, but you need the media key as well...

If you have the media key Km and IDvolume you can calculate the Volume Unique Key Kvu which is what you really need to decrypt the title key.

"A Encrypted Title Key of 16 bytes which is encrypted as follows: Kte_i = AES-128E(Kvu,Kt_i), where AES-128E denotes encryption by the AES algorithm in the ECB mode defined in the AACS Introduction and Common Cryptographic Elements, Kt_i is a Title Key and Kvu is the Volume Unique Key defined in the AACS Pre-recorded Video Book."

And for those that still have doubts about the decrypted key being stored in memory, RTFM...

"A Player may also retain the decrypted Title Keys while playback continues. The decrypted Title
Keys shall be, however, discarded if one of the following conditions holds:
1. The Disc is ejected.
2. The Player loses power.
3. The Player goes into Stop State.
4. The boot sequence for an AACS Disc starts.
a) The boot sequence is described in 6.2.2.2.
A Permission for playback itself is in fact a TKF which resides on a Disc, in a Persistent Storage or
in the File Cache in a Player. Only a Title Key which is bound to a TN is for an Instant Permission because
the TN in the AACS module to which the Title Key is bound is discarded once the Binding MAC is resolved.
In this context, a Binding MAC for TN, where BIND_TYPE = 100b, shall be verified every time the
corresponding Title Key is used. Note that a Permission associated with a Title Key with other binding is
considered to be “Basic” or “Cacheable”."

zacoz

5th January 2007, 14:07

Is this http://www.hardforum.com/showpost.php?p=1030429406&postcount=56 the only public confirmation?
Edit: Ignore post - must be too tired - can't see for looking :lol:

This hardly seems confirmation to me. The "progress" screenshot posted shortly thereafter by w1retap shows BackupHDDVD running without the keys. Seems he's also clammed up on the issue of keys, and his further posts are talking about playback not working successfully from HD.

dialysis1

5th January 2007, 14:14

I believe he was referring to this article:
http://www.cdrinfo.com/Sections/News/Details.aspx?NewsId=19400

xyz987

5th January 2007, 14:26

This hardly seems confirmation to me. The "progress" screenshot posted shortly thereafter by w1retap shows BackupHDDVD running without the keys. Seems he's also clammed up on the issue of keys, and his further posts are talking about playback not working successfully from HD.

No, BackupHDDVD is supposedly running with a Title Key. See last line of command output.

zacoz

5th January 2007, 14:53

@dialysis1
I don't see how he was refering to that news article when his question clearly included a completely different link. But it doesn't really matter.

@xyz987
Ah yes, misread that bottom line. Must be too tired.

dialysis1

5th January 2007, 17:12

I was referring to the post that he read the article on Cdrinfo.
http://forum.doom9.org/showthread.php?p=926664#post926664

Doom9

5th January 2007, 18:44

At least, somebody actually went through the specs instead of just to speculate. I'm really puzzled how many people can have an opinion without so much as to bother to read the specs.
I've gone through parts of the AACS specs myself (cryptography.. ugh, nasty memories from boring and incomprehensible lectures at college re-awaken.. it's safe to say I wasn't an A student in that particular subject but I managed to pass the class regardless).. feizex is looking at the proper document.
But with regards to how to decrypt a movie, all that matters is section 3.5.
It involves 5 steps:
1) Decrypt the title keys:
Kt = AES-128D(Ku, Kte) where Kte is/are the encrypted title key(s) which can be read from the disc. Ku is a volume unique key.. BackupHDDVD can either start off with Kt or Ku, and AES-128D is publicly known.
2) Verify that content isn't revoked
Licensed players have to do that.. BackupHDDVD doesn't.
3) Verify the content signature
Once again, BackupHDDVD doesn't have to even do that.
4) Decrypt the content.
C = AES-128CBCD(Kt, Ce)
Where Ce is the encrypted content we can read off the disk, and we already have Kt from step 1. So bottom line, if you have Kt or Ku, all that remains to be done is implement the proper cryptographic functions and you can read the content. AES-128CBCD is a known function as well.

As far as player / drive revocation goes, that part appears to be in Chapters 3 & 4 of the common AACS specs but I haven't managed to properly digest that information yet.

If you find a flaw in the above reasoning (backed up with the appropriate references to the specs.. "I think" or "I believe" don't count.. this is simply mathematics we're talking about here and that's an exact science).

Also, while I'm at it I'd like to re-iterate that this isn't a crack and look at the CSS history again and see if any parallels can be drawn. BackupHDDVD simply implements the AACS decryption functions. You can't put in any disc and let it rip.. you need to know the decryption key. Consider a safe in a bank. You may be able to drag out the safe, you may even get the plans of how the safe is built, but that still doesn't allow you to get the money. In order to get the money, you either have to break the lock (that's the equivalent of hacking), or get the key. BackupHDDVD goes the latter way.
Now consider DeCSS. It didn't crack CSS either. But the Xing software DVD player left its keys unprotected.. DeCSS and Dodsrip used that player's key. 4 months later, the first DVDs started appearing that could no longer be decrypted using the known key.. so Xing and DeCSS were stuck whereas the rest of the world had no problem playing those discs. Then came VobDec, and only then was CSS cracked.. VobDec, rather than relying on an exposed key, cracked the rather weak CSS decryption - it decrypted content without knowing any of the player keys by breaking the encryption. So, while the mainstream press likes to write that DVD Jon broke CSS encryption, that's actually not correct (plus the decryption routines were written by somebody else)... DeCSS was a key to the safe, not a way to break into the safe without a key.
BackupHDDVD cannot even be compared to DeCSS.. it has no keys, and it most certainly has no means of breaking through the encryption without having a valid key.

Pomyk

5th January 2007, 20:31

maksa

5th January 2007, 20:37

good analogy. From a little I know about encryption, to hack (break open safe) is close to impossible. It'd take indefinite time. This analogy with safe is good to understand the options.
What we have is the safe and the samll locked box with the key to the safe inside. To open safe we need to open box (there are samller boxes inisde that one - tittle key, player key atc.), but weaknes of all this protection scheme is that thay givew you both, the safe and the small box(es). What are we going to attack, of course small boxes...
I gues that is the whole point of this thread.

Beastie Boy

5th January 2007, 20:53

To use the same ananogy, would it be a good idea to start someone working on the safe whilst the small boxes are being worked on. I know that this encryption method is extremely robust, but would some sort of distributed computing project be of any use to try the brute force route?
Suppose it would take 100 years to process every possible combination, doesn't that mean it could take anywhere between 1 minute and 100 years to find the key. It's statistically just as likely to be the first one that you try as it is to be the last one. But I'm not sure who would / could set up such a project even if it was feasible.

Disclaimer: I confess to knowing nothing about encryption or distributed computing, so please feel free to flame me.

Cheers, Beastie.

Doom9

5th January 2007, 21:01

I don't think the title/media/volume keys are anywhere in the memory.Please quote the part of the AACS specification that makes you think that.
The drive does the decrypting and it needs Device Keys to do itUmm.. let's actually look at the specs (AACS_Spec_Common_0.91.pdf). On page 27 we have a diagram of the whole decryption process. Note that the right part of the image, or the "host" part is the PC. And now look where the device keys are... the drive doesn't decrypt, for the simple reason that if it did, all you'd have to do to capture the decrypted content in digital form is dump the I/O bus.

On cracking 128bit AES: http://www.avolio.com/columns/pkiq+a.html. Sure, 56bit DES can be brute forced by considerable effort, but you don't actually have to try 2^56 key combinations.. several key bits can be inferred, which reduce the effective keysize to something manageable for the most expensive supercomputers or a huge network of interconnected PCs (unfortunately I don't recall exactly how many bits don't need to be brute-forced anymore.. I guess those cryptography notes on the attic would come in handy about now). Or to put it bluntly: forgettaboutit. AES is considered secure - unless a manufacturer makes a mistake in implementing the (publicly known and heavily scrutinized by the cryptography community around the world) specs, there's just no way.

Pomyk

5th January 2007, 22:00

I didn't read that part of the specs ;)
In that case moderately skilled cracker should be able to find those keys.

Shinigami-Sama

5th January 2007, 22:14

On cracking 128bit AES: http://www.avolio.com/columns/pkiq+a.html. Sure, 56bit DES can be brute forced by considerable effort, but you don't actually have to try 2^56 key combinations.. several key bits can be inferred, which reduce the effective keysize to something manageable for the most expensive supercomputers or a huge network of interconnected PCs (unfortunately I don't recall exactly how many bits don't need to be brute-forced anymore.. I guess those cryptography notes on the attic would come in handy about now)

modified 'folding at home' mayhaps?

Anyways

just a thought, isn't it possible to to set a trap to copy the memory that a given proccess is using?
though I dont think thats possible under Vista so probly useless

I would think if you could just grab the active memory from the started decrypt you could feed some random values into the AES and search for 'similar' values

though crypto isn't my forte

Doom9

5th January 2007, 22:47

modified 'folding at home' mayhaps?What exactly is it about a safe encryption that you don't understand? An algorithm is considered safe if it has no attack vectors that compromise the key integrity, and if it takes forever to brute-force it. Without going too much into detail, you can search google for how long it took to break DES and how many possible combinations DES really offers with all the known attack vectors, then multiply that time by 2^(128-effective key bits of DES)... you'll see you'll be crunching numbers for a very long time after you've died. Go to the next university and ask a cryptography professor if you can't believe me. You just won't crack the AACS safe.
isn't it possible to to set a trap to copy the memory that a given proccess is using?Yes.. didn't you follow the thread?
Please everyone.. with all the sensationalist stuff out there, and foundationaless speculations and the hacker allegations, let's show them we're not about that at all. The specs are out there.. feel free to read them and if you can prove or disprove any of muslix64 statements with verifiable facts, you are most welcome.
But your two cents really are just idle talk if you've neither read the specs nor know the first thing about debugging and we do have a "no idle talk" rule.

generalnewbie

6th January 2007, 01:01

Stupid journalist and there crappy stories!

Read this "On Wednesday, Muslix64 posted BackupHDDVD, a tool for decrypting AACS protected movies, on a Doom 9 forum thread along with the volume and title keys needed to decrypt HD-DVD movies such as Full Metal Jacket and Van Helsing."

Source:
http://www.pcmag.com/article2/0,1895,2078016,00.asp

This guy clearly is an idiot because no KEYS WERE RELEASED!!!!

NghtShd

6th January 2007, 01:01

At least, somebody actually went through the specs instead of just to speculate. I'm really puzzled how many people can have an opinion without so much as to bother to read the specs.

I read the specs (though not the whole thing and I didn't pore over it, I admit). I have an opinion. My opinion is that he's offered nothing that someone wanting to fraudulently make the same claim couldn't have done. Had he not provided the code or a video but simply popped up and and said, "Hey, I cracked the HD-DVD copy protection. Gotta go now. Bye" would you take him at his word?

I'm not calling it a fraud, mind you, I'm just saying there is nothing more than some anonymous person's word that he did this. What works against his credibility, in my opinion, is the claim that the key was in memory and easy to find. If it's so easy then I'm suspicious as to why it hasn't been verified. It also makes me a bit suspicious when someone goes to the trouble to make a video and write and distribute an app but is then unwilling to discuss anything and instead he takes an immediate "vacation".

It puzzles me (well, not really, but for rhetoric's sake lets pretend it does) that people accept this "hack" as a fact with no verification. It's and interesting claim, but until it can be verified (and I'll be happy if that happens) it that's all it is.

Shinigami-Sama

6th January 2007, 01:24

What exactly is it about a safe encryption that you don't understand? An algorithm is considered safe if it has no attack vectors that compromise the key integrity, and if it takes forever to brute-force it. Without going too much into detail, you can search google for how long it took to break DES and how many possible combinations DES really offers with all the known attack vectors, then multiply that time by 2^(128-effective key bits of DES)... you'll see you'll be crunching numbers for a very long time after you've died. Go to the next university and ask a cryptography professor if you can't believe me. You just won't crack the AACS safe.

I was referancing your earlier post...

On cracking 128bit AES: http://www.avolio.com/columns/pkiq+a.html. Sure, 56bit DES can be brute forced by considerable effort, but you don't actually have to try 2^56 key combinations.. several key bits can be inferred, which reduce the effective keysize to something manageable for the most expensive supercomputers or a huge network of interconnected PCs (unfortunately I don't recall exactly how many bits don't need to be brute-forced anymore.. I guess those cryptography notes on the attic would come in handy about now). Or to put it bluntly: forgettaboutit. AES is considered secure - unless a manufacturer makes a mistake in implementing the (publicly known and heavily scrutinized by the cryptography community around the world) specs, there's just no way.

Yes.. didn't you follow the thread?
Please everyone.. with all the sensationalist stuff out there, and foundationaless speculations and the hacker allegations, let's show them we're not about that at all. The specs are out there.. feel free to read them and if you can prove or disprove any of muslix64 statements with verifiable facts, you are most welcome.
But your two cents really are just idle talk if you've neither read the specs nor know the first thing about debugging and we do have a "no idle talk" rule.

I have followed the thread
from page one - I'm just trying to throw some ideas albeit they've been said before with an equal number of people saying its stupid and wont work to hunt memory, I used to think that write protect on floppies was stupid until I erased my resume by accident a few years ago

as for the idle talk comment I'm done anyways.

Turtleggjp

6th January 2007, 01:56

Building on Doom9's description of DVD rippers, I doubt very seriously that rippers for HD discs will ever get beyond the level that the original DeCSS was. In order to get a VobDec style ripper, AACS would have to be broken, which is probably never going to happen. Right now, we are 1 step behind DeCSS, since we have the means to use keys, but don't have any keys. Someday soon, we will probably have DeCSS style rippers for these discs, but they will probably not be hosted by this site, as they would probably be illegal. These rippers will also suffer the fate of the original DeCSS, because of the key revocation built into AACS. I'm sure that the process of ripping these discs will ultimately be confined to the darker corners of the Internet, so most of us will either be out of luck, or be forced to turn to the dark side. :scared: My hope is that discussion of the tools to work with this content once decrypted will still be allowed to continue on this forum...

Matt

noclip

6th January 2007, 02:09

I don't think the title/media/volume keys are anywhere in the memory. The drive does the decrypting and it needs Device Keys to do it. So in my opinion the only options are to hack a drive to get the device keys or to break AES.

The key will always have to be somewhere directly accessible to the CPU. It's just how computers work.

KornX

6th January 2007, 02:13

only for those of you thinking about brute force
think about Landauer's Principle...

Doom9 linked an article earlier in the thread about ALMOST the same...

for the curious ones:
http://en.wikipedia.org/wiki/Landauer%27s_Principle

KornX

Romario

6th January 2007, 02:28

Well, soon or later (probably until middle 2007), AACS protection will be cracked completely, not just partially.

tonyp12

6th January 2007, 03:12

The youtube video have been removed on the request of Warner Brother.
The video did show the first number for the keys.
the second title did start with 16 and the other titles did start with 1
the last two titles did start with one and second number looked like 10-19 something.

That would help a little if you are doing memory dump to find
the titles keys.

Though v1.0 now uses volume keys.

feizex

6th January 2007, 03:42

Here's one for the rumour mill the guy that claims to have found keys said that he copied the encrypted data onto his drive and PowerDVD played it - after he had played a portion of the HDDVD he removed it and could view the encrypted copy. If that's right then powerdvd doesn't clear the keys from memory like it is supposed to. It also means that Muslix64's video clip could have been faked the same way.

http://www.hardforum.com/showthread.php?t=1137390

#53 12-28-2006, 11:09 PM w1retap
Yes, it played back without the HD-DVD in the drive, but it was only because I didn't know and left PowerDVD open, which still had the key stored in it for the session. Upon further review, if I close PowerDVD and try to play it back off the hard drive, it is just a black screen and gets no audio or scratched/bliping audio.

Later he claims to have located the keys...
#56 12-31-2006, 07:14 PM w1retap
bwhahaha.. found encryption keys, volume keys, and the MCM managed copy V-ISAN ID. Now I'm just working on hashing the whole HD-DVD.. its taking a while.. lol. After that, I'll try the ripping program for playback off the hard drive. Then, if that works, its off to HDbits.

He then proceeded to show a screenshot of hddvdbackup running and decrypting the feature title of HULK hddvd
After this someone asks him about the keys and he clammed up.

#73 01-03-2007, 11:10 AM figgie
w1retap have you or have you not gotten the Title keys (at least the one needed for this workaround)?

#74 01-03-2007, 12:31 PM w1retap
1) I'm not going to speak of title keys on a public forum.

And again no response...
#75 Yesterday, 01:17 PM tharagleb
w1retap: So were you successful playing back after using backuphddvd?

#76 Yesterday, 01:38 PM w1retap
I'm not discussing anything further than I have already said yet. Especially to someone who has just joined the forum as of today. I won't answer your PM's.. nothing. The only thing I will answer is for how you guys to get your Xbox360 HD-DVD drives working with your PC if you need help. I'm not going to break any rules on [H] by discussing piracy.

Either he was faking it, or he really did find the keys and much like Muslix64 decided to keep it to himself. What you need is someone that is not afraid of releasing the keys - some young teenager in russia or someone equally untouchable.

Oddly enough he claims later that the very HDDVD that he screensnapped himself trying to decrypt (HULK) would not work with PowerDVD - the original disk would not work (nothing to do with backup).
#90 Today, 09:43 AM w1retap
Ya.. I am using PowerDVD 7. PowerDVD 6.5 doesn't support all movie titles, but nor does 7. I recently had to take back The Hulk because it didn't work on either program at all.

There is no more confirmation here than what muslix64 has already produced.

Turtleggjp

6th January 2007, 04:22

For those of you waiting so patiently for proof that this does work, don't hold your breath. The only way to prove this works is for someone to produce a key so that we can all try it. However, no public forum in its right mind (especially this one) will let such a key stay in the open for very long. Personally, I see no reason why this shouldn't work. The algorithm in question is very simple to compute if you have the key.

tjf

6th January 2007, 08:45

The youtube video have been removed on the request of Warner Brother.

The video is still available here:

http://www.cdr.cz/a/20159

OverlordQ

6th January 2007, 12:11

w1retap didn't solve anything. If you read his posts he thought he could break the protection by sniffing his network. The dude is a moron.

Doom9

6th January 2007, 12:15

I'm not calling it a fraud, mind you, I'm just saying there is nothing more than some anonymous person's word that he did this. What works against his credibility, in my opinion, is the claim that the key was in memory and easy to find. If it's so easy then I'm suspicious as to why it hasn't been verified. It also makes me a bit suspicious when someone goes to the trouble to make a video and write and distribute an app but is then unwilling to discuss anything and instead he takes an immediate "vacation".

It puzzles me (well, not really, but for rhetoric's sake lets pretend it does) that people accept this "hack" as a fact with no verification. It's and interesting claim, but until it can be verified (and I'll be happy if that happens) it that's all it is.
That's the root of the problem isn't it.. people believe or don't believe without actually being qualified to judge. Are you an experienced cracker, do you have ample experience with a debugger to verify if the keys can be found in memory or not? Do you know how a PC works and where information is stored when a program is running? If not, how can you make any claims as to the validity or not of muslix' claims? I personally am not qualified.. so I cannot in good conscience judge and that would make my opinion just idle gossip, which is why I do not comment on that part.

For the rest of it.. the specs are out, everybody can verify for themselves if the software properly implements the decryption mechanism outlined in the AACS specs. If you are not willing to at least have a cursory glance at the code and specs, whether or not you believe the software works is just idle gossip again.

All the unfounded speculation here and on the web almost makes me sick. I see the most ridiculous things these days, speculation about the release date and upcoming CES, speculation whether muslix is trying to sabotage HD DVD or Blu-ray (you see the argument going both ways), speculation about the origin of the author's nickname, all kinds of things you'd expect from people who have too much time at their hands and still don't quite know what they're talking about.

And looking at what they tried with DVD Jon (just to re-iterate, he didn't crack CSS), and the US exporting the DMCA all over the world, can you blame people from being more cautious? You don't see viodentia sticking out his head either, or the guy who write the DVD-A decryption software.

@feizex: that's idle gossip again. Posting a key is actually not much of a problem.. it's not so much different from providing a CSS decryption software.. you could post CSS keys (DVD Decrypter can show them) as well, but there's little use since every decrypter can automatically get those keys.

Well, soon or later (probably until middle 2007), AACS protection will be cracked completely, not just partially.You are not going to learn anything before we ban you, are you? AACS was not cracked.

The youtube video have been removed on the request of Warner Brother.Just another fair use violation on the part of the studios.. length and quality make the copyright infringement claim ridiculous.

feizex

6th January 2007, 13:13

guth

6th January 2007, 13:50

Thank you Doom9 for the best post in this thread!

If posting a key is "not much of a problem" then howcome noone has?
Maybe because noone has any keys...?

xous

6th January 2007, 13:58

All I was suggesting was that if someone posted a working key then we could verify it is possible. (stating the obvious I know!)

If posting a key is "not much of a problem" then howcome noone has?

As for gossip, yeah I'll cop that. But not much else has materialised has it?

Sorry.

No one has posted a key because it is forbidden on most forums, it is unlikely that someone has found one, and everyone that claims to have found a key is concerned with legal issues.

--

IMHO, I don't think muslix64 has done anything except produce a horrible ( the decryptEVOBFile method is easily a candidate for thedailywtf.com's CodeSOD) partial implementation of a published standard.

Isn't the tool alone a violation of IP law?

To quote the AACS docs:

The use of this specification and access to the intellectual property and cryptographic materials required to
implement it will be the subject of a license. A license authority referred to as AACS LA LLC (hereafter
referred to as AACS LA) is responsible for establishing and administering the content protection system based
in part on this specification.

qbyter

6th January 2007, 14:54

Lord_KiRon

6th January 2007, 17:16

I think the best way it can be if someone PMed (anonymously , like by creating new account and using Tor) Doom9 with at least one working key.
Then he could verify if it woks or not and tell us - we all trust him after all :)

br0kenpipe

6th January 2007, 17:34

Mabye this thread might be of interest?
http://www.avsforum.com/avs-vb/showthread.php?t=774256

hajj_3

6th January 2007, 17:53

apparently on the disk there is a plaintext file with the info below, this is what it says on the avsforums link anyway:

[deleted pending ruling from Doom9]

Luk@s

6th January 2007, 18:11

lol the key to decrypt the movie as a plain-text file on the disc.... that would be the gag of the year...

VistaVick

6th January 2007, 18:13

Too good to be true.

Remember, the key though is to REGENERATE.

tonyp12

6th January 2007, 19:13

Come on now, someone must own a 360HDDVD player
and have easy access to HULK hddvd.
$20 at walmart or in 2 days from netflix (make sure to change to HD DVD version)

The file was probably included on the disc by mistake by
the mastering company.

So can someone test it and get back to us?

calinb

6th January 2007, 19:47

The file was probably included on the disc by mistake by
the mastering company.No--I suspect the keys are the encrypted title keys expected to be in the VTKF000.AACS file. It's all in the spec! If the VTKF000.AACS file contained title keys in the clear, it probably wouldn't play, but I've not studied the spec sufficiently to know for sure how a player would behave given such a mishap.

Edit: Hmm--seems they're talking about a text file in the root directory of the disc. That wouldn't be the VTKF000.AACS file and that is strange!

zeroprobe

6th January 2007, 21:43

them keys are not 16 bytes long?

hartiberlin

6th January 2007, 22:23

Okay, 2 keys are in this thread:

http://www.avsforum.com/avs-vb/showthread.php?t=774256

Please can somebody try it ?

It seems, it is forbidden here by the rules to post the keys...
as the text was already deleted above in the posting...

feizex

6th January 2007, 22:42

Good eyes. One is 32 bytes (chars). But it looks to be HEX chars. IE. 16 HEX pairs = 16 bytes = 128 bits.

The other is a strange length and looks to be date time plus padding.

271020061204

27/10/2006 12:04 and 02 padding

VistaVick

6th January 2007, 22:44

These are not the keys....but interesting finding nonetheless.

If they were the keys, plenty of people would have tried them already, as that thread was posted a while ago at one of the most popular forums on the net.

aicjofs

6th January 2007, 22:55

Come on guys. Look at the the specs for the love of....

The shorter number would be a Volume ID if anything (not Volume Unique Key), the second number says DKF (logically a Directory Key File, inside that file is the Directory Key encrypted, which needs the Volume Unique Key to be decrypted. Is this possibly the hashed version of DKF?). I don't see these as either the Title Key nor the Volume Unique key.

Defiently worth a try though, doesn't take any time if you have the equipment. At least the 2nd number is the correct length to try for HDDVDbackup.

I do see the pattern year/week/month/whatever which would mean decrypted. I can't even remember if the VolumeID is encypted or not, and I have read through those damn tech docs 3 times, once was just last night...(hard stuff to digest). The guy said he only posted part of the file so the rest would be fun to look at.

Either way this is not the solution we are looking for, it would just be one mistake on one movie, and that's about it.

feizex

6th January 2007, 23:02

"Either way this is not the solution we are looking for, it would just be one mistake on one movie, and that's about it."

Looking for a known key in memory is a lot easier.

But I agree these are not the keys. Here's your key...
TKF.BIN_FILE=<RANDOM>

tjf

6th January 2007, 23:23

...The shorter number would be a Volume ID if anything (not Volume Unique Key), the second number says DKF (logically a Directory Key File, inside that file is the Directory Key encrypted, which needs the Volume Unique Key to be decrypted. Is this possibly the hashed version of DKF?).

I bet it is the Encrypted Directory Key which is the last part of the DKF.AACS file (see chapter 6.3 of the AACS_Spec_HD_DVD_and_DVD_Prerecorded_0_912.pdf). Anybody with Hulk can confirm?

Also the rest of the txt file is in the hardforum thread I was linking before. To me it looks like some forgotten configuration file for the AACS encryption process.

feizex

6th January 2007, 23:46

Oh that's gold! He now claims that muslix's program does not work because he couldn't get it to play back.

DUH, you didn't have the correct key! :P

He effectively fed it garbage.

OverlordQ is spot on. ;)

Adub

6th January 2007, 23:47

Here is an interesting opinion upon the "motives" of Muslix64.
Insightful, to say the least.

Edit: Here is the link, sorry.
http://www.hdnowonline.com/Comment_Who_Is_Muslix.html

tonyp12

7th January 2007, 00:42

I just bougt a X360 HD DVD drive for $159 at circuit city

$199- $40 coupon
http://www.zshare.net/download/cccoupon12_24_06-pdf.html

I bet MS will see a spike in sales this month.

Getting HULK from netflix on Tuesday.

blutach

7th January 2007, 00:48

@tonyp12

And the relevance to this thread is what? Please read rule 3. You've been around long enough to know better.

I know you are not alone, so let me ask all posters to keep on topic please - and that is the decrypting of HD-DVD via HDDVDBackup.

I have also asked posters not to publish keys. We are clarifying this situation, but until then, I would ask you all to please not do so.

Thanks.

Regards

aicjofs

7th January 2007, 00:58

Looking for a known key in memory is a lot easier.

Would it narrow it down if you did the following? (I know you posted this from a difference reference, but it had different wording so I thought I'd add this one too) Reference from page 130 of HDDVD prerecorded book of the boot sequence.

In the boot sequence, the AACS module in the Player may keep the Title Keys in a secure manner. In
that case, the AACS module in the Player shall be reset and the decrypted Title Keys shall be cleared from the
system when the following conditions hold in the boot sequence:
i) A Player starts an initial boot sequence.
ii) The associated Disc is ejected.
iii) The Player loses power.
iv) Another boot sequence starts.
• This may be caused by a call of the API, Playlist.load().

example would be to eject the disc and see what memory is freed?

EDIT: You know another thing I was thinking about your date time observation. What if the unique key(volume or title) was just like what you described and not some creation of a random number generator? The key is the date time hour at creation and some padding, that key would always be unique...haha...I would bet tons of money that's not how it's done but I have seen many passwords over the years like this, can't imagine they would do it but it would be funny if we spent all this time and they used such a weak key.

kmac61

7th January 2007, 01:29

The root of this forum is about fair use and all the various ways you can exercise that right. Making a backup copy of your optical media to proect your investment, while valid, is just a small slice of the concerns and needs of those using Doom9. In the case of HD and BD media it's a non starter, you can't do it. Even if you could,why bother, it'd be much cheaper and easier to buy a new disk.
The only fairuse value of this program and thread is limited the needs of the op and the small # of people in a similar position, having HD compatible equipment with a break in the hdcp chain.The only question(s) then is can you bypass hdcp and should you be allowed to. Considering 99.99% of the people purchase Hd and BD discs do so because they can play them back this is an issue no great importance. Whether it's fair or not the few people in the op's position can simply upgrade the deficent hardware or wait till they can before buying into Hd or BD. Considering the mislead notoriety of the subject and the drift of this thread towards defeating aacs I would hope the mods lock it

woah!

7th January 2007, 01:53

Even if you could,why bother, it'd be much cheaper and easier to buy a new disk.

so i should just throw more money at the film industry? dont tell them that, as they will then make discs that corrupt themselves after say 6 months and you have to go buy it again, as that is surely cheaper than being allowed to make a backup of your bought media...

why dont they then just LEASE the discs out instead of using the word BUY a dvd.

blutach

7th January 2007, 01:56

it'd be much cheaper and easier to buy a new disk.
Why should you have to?

The only fairuse value of this program and thread is limitedAnd does the same hold true for a regular DVDs? The argument is spurious as well as being off topic.

I would hope the mods lock itThere is no need to do that and I'd be grateful if you would leave such decisions to the mod team.

Regards

moshmothma

7th January 2007, 02:31

Ok, tried the Hulk - here are my observations

1. The Hulk does not play in Powerdvd or Windvd for me. A few screens flash by and then a black screen.

2. However, while the flashing takes place I did a memory dump.
Turns out the clear text file from the Hulk disc is loaded with both programs probably because they are both in the root. I grep on the title string from the file and it is loaded several times into memory.

3. However, the contents of the file is the only place I find those keys.

4. Maybe someone else with the Hulk disc who can actually play it can try the same.

Zag

7th January 2007, 02:34

quoll

7th January 2007, 04:35

so where is DVD Jon amongst all this ?

blutach

7th January 2007, 09:43

quoll - you have waited 5 days to post this off topic remark?

I have asked and asked about keeping this thread on topic.

Please observe rule 3 - strike issued.

Regards

blutach

7th January 2007, 12:59

Lord_KiRon

7th January 2007, 13:51

CiTay

7th January 2007, 15:45

"heise online" spoke with Cyberlink on the "CES Unveiled" event and reports that they deny any AACS-key-in-memory issue in PowerDVD.

http://www.heise.de/newsticker/meldung/83289 (german) and a badly translated version (http://translate.google.com/translate_p?hl=de&ie=UTF-8&oe=UTF-8&langpair=de%7Cen&u=http://www.heise.de/newsticker/meldung/83289&prev=/language_tools)

Abstract: PowerDVD doesn't store the keys in memory, therefore they can't be found there. Since there's no loophole, nothing needs to be fixed. If there was one, they would have to report it to AACS LA, and new HD DVDs would contain a new keyset that would make them unplayable with the compromised PowerDVD version. Furthermore, all 18 months, there is a mandatory change of keys.

noclip

7th January 2007, 16:56

After discussion with Doom9, it has been decided to allow publication of decryption keys and logs. This in no way implies a relaxation of rule 6 - certain information still may not be published, such as IFO files (or extracts therefrom).

Regards

I hope this helps the process, but I imagine everyone will be too scared of WIPO/MPAA lawsuits to post them anyway.

Doom9

7th January 2007, 18:47

Here is an interesting opinion upon the "motives" of Muslix64.
Insightful, to say the least.

Edit: Here is the link, sorry.
http://www.hdnowonline.com/Comment_Who_Is_Muslix.htmlA few pages ago, that's one of the articles I was thinking of when I wrote that I'm fed up with unfounded speculation. I realize we've been too lax in the past and have allowed this forum, or especially this subforum, with this thread and the fairuse4wm thread before it, to become a gossip column. It's time to correct that mistake so let me remind you to stay on topic or face the full brunt of the forum rules. If you ain't got nothing backed up by facts to say, then you must not post here - I'm sure there are places out there for speculation and gossip but this is not the place.

Sureshot324

7th January 2007, 21:00

Can anyone who's read the AACS spec tell me how the HD-DVD drive transfers the title key to the monitor? The title key is decrypted in the drive so it must be unencrypted when it is sent to the monitor. What stops this unencrypted key from being intercepted? Does it go directly through hardware without going into system memory?

Doom9

7th January 2007, 21:04

I think you're mixing up a couple things here. AACS is decrypted on your machine.. between your GFX card and the monitor we then have HCDP which is something else entirely (and afaik, but I could be wrong here, no disc uses ICT yet so the connection doesn't necessarily have to be encrypted).

Jerky_san

7th January 2007, 21:58

hvatum

7th January 2007, 21:59

Here is an interesting opinion upon the "motives" of Muslix64.
Insightful, to say the least.

Edit: Here is the link, sorry.
http://www.hdnowonline.com/Comment_Who_Is_Muslix.html

Insightful? More like a bunch of conspiracy mongering and unfounded gossip. Try using your critical thinking skills: He used Java, Sun uses Java, so he MUST be working for Sun! I mean, it's not like there is anyone else who uses Java except for Sun. Seriously, it's not like there's over 100,000 projects on sourceforge.net written in Java, and it's not like Java is a good langauge for cross-platform development, obviously this guy must be working for Sun!

Honestly, if Sun were actually behind this why would they have it written in a language which would obviously lead back to them. Doesn't make any sense, this is far too risky given the possible repurcussions for their entire corporation, which cannot afford any kind of financial loss right now. Secondly, they don't really stand to gain very much if Blu-Ray wins, Java is an open platform, that's why it was chosen, not because it's profitable for Sun.

Secondly, the "it's mueslix son," um, NO. Very few actual Germans are going to write Mueslix if they can't use an Umlaut, because it looks dumb. Also they tend to be lazy, in online chat with Germans I have NEVER not ONCE seen a German type a "ue" or "ae" in place of a "ü" or "ä." The only person who would do that is an AMERICAN writing for their GERMAN class. If anything this strongly suggests he is a European, and shows how ignorant that poster on hdnowonlinefanboys.com is.

"4) As a defence, he claims to only own an HD DVD player, which would indicate to most that he is an exclusive supporter of the HD DVD format. Yet he releases a so-called "tool" like this, and publicises it in a big way, knowing full well the damage that it could cause the format."

Come on, this site is not even pretending to be unbiased. It's equally possible that he happens to have an HD-DVD drive because it's the cheapest way of getting a next generation HD-Drive for your computer right now.

I'm not going to bother tearing down the other points on that HDnow site, suffice it to say that whole article is a farce. Please stop posting links to it, first of all it makes you look dumb, secondly it distracts from the issue at hand...

PS. CSS was broken by a 16 year old Norwegian kid.

hvatum

7th January 2007, 22:19

So.. if HD-DVD player companies claims its not in memory. If you take their comments with something more then a grain of salt what does it leave you?

1. Registers
2. Perhaps the heap? or swap memory on the hard drive
3. What about the video card memory? Couldn't it be possible to use the video card as a storage place? Mainly since it seems Vista is more toward using the video card then any windows platform.
4. Where else? I'm a programmer but I can't think of many other places..

We as a group need to start at one end of the rope and slowly climb up the hill knocking out each place where it could perhaps be. Where ever it is it has to be the for the entirety of the movie shouldn't it? Since you have to decrypt each key as it comes and I doubt they left 1 key to protect a whole feature. Thus it would perhaps call on the key before each section comes up for decryption and will have it ready.

I just called Cyberlink R&D about this. And I must say, there is absolutely no way Muslix could have gotten the keys from WinDVD.

This is for one very simple reason: The keys are stored Cyberlink's new patented "MAGIC MEMORY." Yes, instead of using any physical method of saving data (Memory, Magnetic Hard Drive, CPU Register) they have avoided any security issues by storing the keys in a new super-secret memory which only WinDVD can access. When the operating system or any other process tries to access this memory the data there magically dissapears, and then re-appears when WinDVD needs it. Pretty cool, eh?

The data is moved around by a bunch of DRM gremlins, who live inside of your computer. :P

VistaVick

7th January 2007, 22:29

Magic Memory? Sounds pretty lame, not cool.

blutach

7th January 2007, 22:38

Insightful? More like a bunch of conspiracy mongering and unfounded gossip. Try using your critical thinking skills: He used Java, Sun uses Java, so he MUST be working for Sun! I mean, it's not like there is anyone else who uses Java except for Sun. Seriously, it's not like there's over 100,000 projects on sourceforge.net written in Java, and it's not like Java is a good langauge for cross-platform development, obviously this guy must be working for Sun!

Honestly, if Sun were actually behind this why would they have it written in a language which would obviously lead back to them. Doesn't make any sense, this is far too risky given the possible repurcussions for their entire corporation, which cannot afford any kind of financial loss right now. Secondly, they don't really stand to gain very much if Blu-Ray wins, Java is an open platform, that's why it was chosen, not because it's profitable for Sun.

Secondly, the "it's mueslix son," um, NO. Very few actual Germans are going to write Mueslix if they can't use an Umlaut, because it looks dumb. Also they tend to be lazy, in online chat with Germans I have NEVER not ONCE seen a German type a "ue" or "ae" in place of a "ü" or "ä." The only person who would do that is an AMERICAN writing for their GERMAN class. If anything this strongly suggests he is a European, and shows how ignorant that poster on hdnowonlinefanboys.com is.

"4) As a defence, he claims to only own an HD DVD player, which would indicate to most that he is an exclusive supporter of the HD DVD format. Yet he releases a so-called "tool" like this, and publicises it in a big way, knowing full well the damage that it could cause the format."

Come on, this site is not even pretending to be unbiased. It's equally possible that he happens to have an HD-DVD drive because it's the cheapest way of getting a next generation HD-Drive for your computer right now.

I'm not going to bother tearing down the other points on that HDnow site, suffice it to say that whole article is a farce. Please stop posting links to it, first of all it makes you look dumb, secondly it distracts from the issue at hand...

PS. CSS was broken by a 16 year old Norwegian kid.

Magic Memory? Sounds pretty lame, not cool.Please refer to Doom9's post 424 (http://forum.doom9.org/showpost.php?p=928419&postcount=424).

These posts simply perpetuate the discussion which is way off topic, which I have warned about many times before. It is clear my warnings have not been heeded.

Please confine your posts to BackupHDDVD and not about Muslix. Doom9 is not a chatline.

Strikes issued. Off post remarks will be struck in future.

Regards

Jerky_san

7th January 2007, 22:40

hvatum

7th January 2007, 23:28

hmm if this "magic memory" is true then I wonder if it acts like a virus.. You know the ones when you attempt to delete them or go into the folder where you virus scan say they are they move to a different folder.. If this is true then its going to be a very hard climb up the mountain. Although I'm curious if anyone has been playing a movie and did a memory dump at the same time while still playing the movie? Does it keep playing? or Does it stop due to the key was just transfer to a different area. And how to does the program know where the transfer went? It would have to keep track of it somehow..

hehe, as far as I know there is not actually any such thing as "Magic Memory." I was just satrizing Cyberlink, if the values are stored somewhere, then they must also be able to be accessed. Cyberlink's argument that it "could not possibly" come from WinDVD is a red herring, because Muslix never stated he got the values from memory .

Jerky_san

7th January 2007, 23:33

hehe, as far as I know there is not actually any such thing as "Magic Memory." I was just satrizing Cyberlink, if the values are stored somewhere, then they must also be able to be accessed. Cyberlink's argument that it "could not possibly" come from WinDVD is a red herring, because Muslix never stated he got the values from memory .

Yeah thats the kinda stuff blutach is talking about..

anyway

Btw: If HDDVDbackup works as it should and according to the above, it should set KEY_VF to 00b after decryption, otherwise a player would still asume the EVOB needs decryption - does hddvdbackup do that?? I´m no Java guy...

Well running through all the src I don't see where anything is set to that but it might be in a some part of the decryption that inside of the java stuff....

Lange

7th January 2007, 23:40

He-Man

8th January 2007, 00:56

Finally i can post,

I'm not really into file hashes e.d. but i thought it is possible to get the original string back from a hash by the use of rainbow tables?

Same thing is done with MD5 hashed passwords on websites...

still offcourse Muslix64 has to have posted the original hashes from the keys

:readfaq: Read the FAQ.txt file in backupHDDVD.zip!
The hash is not from any keys but it is the SHA1 Hash of the VTKF000.AACS file on your HDDVD disk.

-What is the TKDB.cfg file?

This is the Title key Database file. It holds the decryption keys for the movies.

-What is the format of this file?

Field 1: SHA1 Hash of the VTKF000.AACS file on your HDDVD disk.

Borbus

8th January 2007, 01:13

CiTay

8th January 2007, 01:21

Cyberlink's argument that it "could not possibly" come from WinDVD is a red herring, because Muslix never stated he got the values from memory .

Please remind Cyberlink to stop impersonating InterVideo (the makers of WinDVD), and also remind them that they are the makers of PowerDVD instead :D

He also stated that he found a key in memory: "I was very surprise to realize that the title key is there, in memory!"

cyber1

8th January 2007, 01:21

Since title keys are now allowed, here is one that is supposed to be for "The Hulk" HD-DVD:

554E4956455253414C5F48442D445644

It isn't necessarily for the feature, it could be for some of the other things like the menu etc. I haven't got a HD-DVD drive so I can't try it.

Read the AACS spec first.
That's a Directory Key, DKF.DK.

The only keys that is interesting is Titlekeys or Mediakeys, only these types will work with backupHDDVD.

SvT

8th January 2007, 01:28

Since title keys are now allowed, here is one that is supposed to be for "The Hulk" HD-DVD:

554E4956455253414C5F48442D445644

It isn't necessarily for the feature, it could be for some of the other things like the menu etc. I haven't got a HD-DVD drive so I can't try it.

This value is the ASCII code for "UNIVERSAL_HD-DVD".

Doesn't look like a title key to me :sly:

Borbus

8th January 2007, 01:37

Yes, you're right it is a directory key. I haven't read the spec but I just thought I'd help. It came from a text file which Universal probably accidentally put on The Hulk HD-DVD. A bit more:

// Directory Settings
[COMMON]
IN.ROOT=G:\TheHulk\TheHulk
OUT.ROOT=G:\AACS_output\TheHulk

// Volume ID Setting
[VID]
VID.UNQ_NO=271020061204020202020202

// Title Key Setting
[TKF]
TKF.BIN_FILE=<RANDOM>

// Title Key Setting
[DKF]
DKF.DK=554E4956455253414C5F48442D445644

// Managed Copy Settings
[MCM]
MCM.V-ISAN=0000-0001-4F66-0000-F-0000-0001-R
MCM.SERVER_URI=http://smc.universalhomentertainment.com/

So, the title key was random, damn.

Isochroma

8th January 2007, 02:03

The biggest bottleneck in the player vulnerability discovery process is that we are searching for two unknowns. The first is the title key, and the second is the location in memory, registers, files, etc. where the software player might store it. The logical option would be to eliminate as many unknowns as possible.

There is a much easier method to determine whether PowerDVD or any other software 'leaks' title keys, and to also test BackupHDDVD's ability to properly decrypt HD-DVD content, given a correct title key, than to try playing commercial HD-DVDs with unknown title keys on a drive few have and which requires a hacked UDF 2.5 driver to work.

First, rather than have to acquire a commercial HD-DVD movie disc and HD-DVD drive to enable reading of its contents, it might be easier to just make some HD-DVD content. Sonic Scenarist can author HD-DVD content, and also provides the ability to protect the content using standard AACS encryption:

Sonic Scenarist (http://www.sonic.com/products/Professional/Scenarist/quicklook.aspx)
'AACS Content Protection Support - Secure your Blu-ray Disc titles with next-generation AACS Content Protection. (http://www.sonic.com/products/professional/scenarist/features.aspx)'

'HD DVD Support - Offer your clients both Standard and Advanced Content HD DVD title creation. With direct access to the HD DVD specification, the only limit is your creativity. (http://www.sonic.com/products/Professional/Scenarist/quicklook.aspx)'

Movie Factory 5 Plus - Removed - Does not (http://www.ulead.com/dmf/compare2.htm) have AACS functionality (sorry!)

The authoring software will make the required fileset, but may not provide ISO creation functionality. However, thanks to PowerDVD's ability to play an HD-DVD from files in a folder, that is not necessary to test this particular player software.

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.
Now we can make up a tiny 1920x1080 MPEG-2, H264 or VC-1 file, and using Scenarist create the HD-DVD fileset.

Most importantly, we now know the title key - in both its encrypted and unencrypted forms, since we authored the files.

Should our authoring package not provide the facility, the 'HD-DVD Authoring to DVD --+ Media (http://www.avsforum.com/avs-vb/showthread.php?t=667462)' thread on the AVS forum provides the required method to convert the HD-DVD fileset to an ISO image, which has been tested and found compatible with at least one hardware player; thus it should be compatible with software players also.

At this point, the player software can be tested on the files, either by direct playback (PowerDVD) or by emulation. With either the Microsoft or Sonic emulator installed, the ISO file can be mounted and read by software players which cannot play raw filesets.

It now becomes a trivial task to search memory and other places for the keys. It also becomes easy to find if and where in the player code vulnerabilities exist; since we know what the original keys are, we can simply search for them.

Jerky_san

8th January 2007, 02:14

..dang Isochroma that is a very good idea lol.. I'm doing that right now.. I'll report my results if any.. Also Ulead does have ISO ability but I'm not seeing the encryption ability anywhere..

Borbus

8th January 2007, 02:48

Yes, good idea, I'll try it too. Also we can see if BackupHD-DVD actually can decrypt our HD-DVD before searching for the location of the title or volume keys.

hvatum

8th January 2007, 02:50

Please remind Cyberlink to stop impersonating InterVideo (the makers of WinDVD), and also remind them that they are the makers of PowerDVD instead :D
Which version of vulnerable player software these companies produce doesn't really matter to me.

He also stated that he found a key in memory: "I was very surprise to realize that the title key is there, in memory!"

Yes, Muslix did state he found a key in Memory, but he did not state that the key was sourced from the DVD playing software made by cyberlink. If I recall correctly.

Secondly I take Cyberlink's statement with a very large grain of salt, obviously their software plays HD-DVDs, so the Title key must be stored somewhere in unecrypted form, at least for a short while. If it's stored somewhere, then it can be read from this location. Perhaps Cyberlink discovered some new programming method, which allowes them to access data which does not exist, but this would be the first I've heard of it.

Shinigami-Sama

8th January 2007, 02:53

hvatum

8th January 2007, 03:00

the only way I could think of that they could even say that the key wasn't in memory would to do something very simple with it

fragment it in memory

have the first 8 bits at location 4
second 8 bits at location 65535
next 8 bits at 217
so on and so forth

so it would be rather easy to reconstitute the key but more difficult to track it down

That's possible. However that still means the key does exist in memory - contradictory to Cyberlinks statement which seems to suggest they have discovered a form of CS black magic.

BTW: Is it possible to dump the values stored in CPU registers? Because at some point the key would need to be reconstituted so it can be used for decryption. Afterall, you can divide something up, but you still have to remember what all the parts together are at some point.

Isochroma

8th January 2007, 03:23

Even better, using the method in my previous post, multiple copies of the exact same content can be authored, with the only difference being the title key.

Then each can be played in turn, and dumps of the suspected key storage areas made (memory, registers, files, etc.). Comparing the dumps, the differences between them will point to the location(s) where key information is stored.

This process will significantly increase the ease, speed and reliability of software player vulnerability testing, while decreasing its costs and implementation complexity.

Furthermore, by running a player capable of non-emulated (direct file) playback within a debugger environment, the process may be automated.

First, a set of small test filesets authored from the same content is created, with the only difference being title key. Next, these sets are segregated each in its own folder at a known location on hard drive.

Next, the player application, provided it is capable of commandline specification of source fileset for playback, is fed the parameters on its virtual commandline within the debugger environment. After a preset time period determined by the tested initialization time, the debugger does a total or partial memory or register dump to a file, and terminates the running debug environment.

Next, the debugger either exits as specified or is terminated by scheduled task, using third party software if necessary. The next scheduled task restarts the debugger with different commandline parameters, which are passed into the player's commandline within the new debug environment. These parameters sequentially specify the various authored HD-DVD filesets and debug dump files.

When the sequence has run to completion, a binary compare utility can be launched interactively or via commandline or scheduled task with parameters specifying the debugger's memory dump files.

The binary compare utility will produce a difference file or files which highlight differences between the test runs, which can be examined by the user to rapidly narrow and finally discover key locations.

Finally, even if the authoring software does not provide the end user with either or both the encrypted or unencrypted title key, and even if the player software encrypts or scrambles the title key in memory, this method will at least pinpoint the location(s) used by the player software to store the key data.

If the authoring software provides either the encrypted or plaintext key, then it is also possible to, using different keys and repeated test runs, discover the relationship between encrypted key and scrambled encrypted/decrypted key in the player application's memory space, or alternately, find the code responsible for key storage allocation and/or scrambling.

Knowing the location(s) used and also knowing the player's scrambling algorithm (if any), it will be possible to, for a given player, write a software which runs concurrently and, provided the operating system does not enforce protected memory space, snoop the values for any real disc which the software player plays.

Finally, the scrambling can be undone to provide the plaintext title key, which can be provided to secondary decryption software, such as BackupHDDVD.

hvatum

8th January 2007, 03:25

Borbus

8th January 2007, 04:02

If anyone manages to make a HD-DVD ISO, put it on a filehost and link to it so we can all try to use it. I can't work out how to use Scenarist and I don't know what settings to use with x264 to get a compliant video.

Shinigami-Sama

8th January 2007, 04:09

That's possible. However that still means the key does exist in memory - contradictory to Cyberlinks statement which seems to suggest they have discovered a form of CS black magic.

BTW: Is it possible to dump the values stored in CPU registers? Because at some point the key would need to be reconstituted so it can be used for decryption. Afterall, you can divide something up, but you still have to remember what all the parts together are at some point.

it has to exist in memory for anything to be done with it anyways, its basic digital electronics

so they must have done some sort of obfuscation or something on the key so that they key itself is not in memory as a whole, but parts, cyphered etc... could exist and not be readable unless you know where and how it was done

Gradius

8th January 2007, 05:21

Magic Memory = pure BS, don't believe on them! :logfile:

calinb

8th January 2007, 05:45

Then each can be played in turn, and dumps of the suspected key storage areas made (memory, registers, files, etc.). Comparing the dumps, the differences between them will point to the location(s) where key information is stored.The title keys also change between titles of the same disc. I proposed the same idea earlier in this thread and it could still be useful, if combined with other techniques, but a lot of other stuff (besides the keys) changes too.

I suggest that sensitive or perhaps even speculatiive brainstorming, that might be considered off-topic here, be conducted offline in an anonymous forum.

Install I2P and join the discussion:

http://forum.i2p/viewtopic.php?p=9157#9157

(The link doesn't work unless you've installed I2P)

Dear mods: if you've not ever used I2P and visited the I2P forum, I must assure you that it's not a warez site. It is simply a public site where users may speak freely with a high degree of anonymity. It is available to anyone who installs I2P software.

New I2P users: Let's keep it that way! This is about exercising Fair Use rights and no more/less!

Isochroma

8th January 2007, 06:14

@calinb: There is no need for secrecy: what was done in secret by the making of the HD-DVD and Blu-Ray copy protection schemes, will be undone in public.

Like good encryption, good decryption will not die by being exposed for all the world to see. In this case, the hardware standard is already set in stone, with thousands of players and lots of discs already sold, so that's not going to change.

As far as player software, that will always change, but it will be reverse-engineered too, using the same or better methods. Fundamentally, there is no way to keep the system closed as long as PC playback is a possibility.

The possibilities mentioned in my last two posts have no doubt already been thought of or are soon to be seen by player developers. The ideas are general, and apply to a wide range of possible cases; more like a sample guide for security auditing.

Perhaps most importantly, there is nothing player developers can do but issue an ever-growing stream of updates and new versions with ever more convoluted protection schemes, that will all be reverse engineered.

The only real threat to this kind of attack is a protective operating system, like Vista. But like russian dolls, cracks will be found and made at all layers, so even that will not stand long.

As for personal risk, I won't post anything here that is illegal in my country, or against forum rules, so I have nothing to fear. I hope this is the case for all posters, because all that needs to be accomplished can be done right here without any problems from either local policies or enforcement agencies, if users think carefully before posting.

calinb

8th January 2007, 07:29

As for personal risk, I won't post anything here that is illegal in my country, or against forum rules, so I have nothing to fear. I hope this is the case for all posters, because all that needs to be accomplished can be done right here without any problems from either local policies or enforcement agencies, if users think carefully before posting.Well--in the U.S. we have the DMCA. Other coutries have vairous "exported" versions if it. The DMCA contradicts Fair Use. As far as I can tell, this has not been resolved through either legislative or judicial process. Not everyone wants to risk becoming case law.

Borbus

8th January 2007, 07:39

I have tried to make a HD-DVD image with Scenarist. I can't test it because it's obviously UDF2.5 and mounting with Daemon Tools doesn't work. I can't find UDF 2.5 drivers. It's only 4.5MB so if it's not right it doesn't waste much bandwidth.

http://www.filehost.gr/643076

If anyone can get it to work, the keys should be:

C29E56D1E80EA92B010733C46A73DECA
6ACF5ADFCFD8A3D404D0DB6155229D36

I think the second one is for the main video. Not sure what the other one is for.

It's the first time I've used Scenarist so it probably is wrong...

By the way id anyone's interested I just made a blank 1920x1080 video with AVISynth and encoded it with Mainconcept h264. x264 doesn't work for creating compliant elementary h264 streams.

edit: the first one is the volume key, the second one is the title key for the single title in the ISO.

Susana

8th January 2007, 08:00

Daemon 4.0 works, I've just do it.

Played with windvd 8. 7 seconds clip.

Edit: extracting files with isobuster 2, plays same way. No aacs proteccion in that iso. ?? Remains in memory ??

Isochroma

8th January 2007, 08:02

Returning to the topic at hand - which in this case is the BackupHDDVD application - I'd like to extend my congratulations to Muslix64, who not only chose a username corresponding with my favorite cereal, but also made good effort to build an application which may help the cause of fair use.

The most valuable thing Muslix64 has provided by establishing this thread is not an application called BackupHDDVD, but an idea called YouCanBackupYourHDDVD.

Just by building an application which may or may not decrypt HD-DVDs, and dropping hints and clues in his posts and release notes, his ideas are now making lots of people think about how to make applications which can do the same or better.

Perhaps the YouTube video itself was the best inspiration; even if it was an utter fraud it provided and still provides a glimmer of the light at the end of the tunnel for fair use in the twenty-first century.

The hardest step to take is always the first one, but as soon as someone does, many more are both informed and inspired to follow. Of course, often that first step is over a cliff or into a deep quicksand, but that doesn't really matter.

What matters is that such an event changes many people's thought patterns from "we are victims" to "we can change this". The holdup is almost always a lack of will and faith in capability, not in intelligence per se., manpower, technology or money.

Isochroma

8th January 2007, 08:08

@Borbus: excellent work! I've downloaded the file but don't yet have the player to test with. Also it is late at night right now; I will write more tomorrow.

I can confirm that the ISO mounts fine with Daemon Tools, but Windows cannot recognize the filesystem; I don't have the UDF 2.5 driver installed (yet). I'd hoped that Scenarist might come with the driver, since it should also include the emulator.

@Borbus: can you confirm if anywhere in the package, is located the emulator?

Also, it is likely that the Microsoft HD DVD Interactivity Jumpstart includes a UDF 2.5 driver, since it would be rather pointless for a development kit of this type to not have it, hopefully?

I will install a UDF 2.5 driver tomorrow and report on further findings.

Borbus

8th January 2007, 08:10

Edit: extracting files with isobuster 2, plays same way. No aacs proteccion in that iso. ?? Remains in memory ??
Really? But I set it up to use encryption, and the AACS files are there which aren't if you don't turn on encryption (edit: at least I think they are, they're in the output directory, are they in the ISO?). Any idea what I might have done wrong?

Here's a screenshot of me enabling AACS:

http://img403.imageshack.us/img403/7081/neoshooter22em8.th.png (http://img403.imageshack.us/my.php?image=neoshooter22em8.png)

condorito

8th January 2007, 08:16

http://www.macfergus.com/niels/dmca/cia.html

Finally, 5 days, that's really, really @$@^$% up. I found that link. It's good reading, old though.

Susana

8th January 2007, 08:26

http://img127.imageshack.us/img127/8535/snap1ql9.th.jpg (http://img127.imageshack.us/my.php?image=snap1ql9.jpg)

Thinking about it, aacs can be in the iso ?

Borbus

8th January 2007, 08:35

It doesn't seem to have worked at all. The AACS stuff isn't in the ISO at all. It's in the output directory, but even the EVO file in there plays in PowerDVD fine. I don't know what's wrong...

Pomyk

8th January 2007, 08:40

The stream doesn't look encrypted at all. After compression it's only 16kB.

Isochroma

8th January 2007, 08:41

@Borbus: Excellent work! I had only hoped that this step would be fairly feasible; you've proven this supposition correct. However, it would be good if you can generate one more sample ISO, this time with two items different:

1. It should have a few frames of visible content, so we can see that the player is actually working.

2. In your AACS Settings dialog, the last dropdown box is called ICT. You must select none, or disabled, rather than the current constrained. Reason why is because if the ICT is enabled, only those with a valid HDCP output chain (videocard, monitor) can test your sample. Remember, the purpose of this investigation is to help reverse-engineer an AACS implementation, not HDCP.
The reason why Susana had no problem playing the file is because the title key was generated from a portion of the available keyspace assigned to Scenarist's application license.

The disc key was undoubtedly also added but not displayed; it is only required when the player supports and requires disc authentication, which daemon tools and isobuster do not, of course.

Because of that, any player with a licensed unrevoked decryption key will be able to play the files in his ISO.

The important part of the AACS is not in the ISO volume structure; it is the files themselves that are encrypted, just like regular DVD VOBs. And it is their encryption which BackupHDDVD is purportedly capable of removing, provided the correct Title Key.

Now, getting those files off a real HD-DVD disc requires the player to authenticate the disc, or vice-versa. That step should be automatic, ie. people have been able to copy the EVOBs from HD-DVDs with only the UDF 2.5 driver and drive installed.

Borbus

8th January 2007, 08:48

I just read this in the documentation, so actually it probably isn't feasible:
Note: When outputting a project, AACS is only written to DLTs and PlantDirect images. AACS is not written when burning discs.

Unless there is some software that can burn or mount PlantDirect images...

edit 1: Daemon Tools does mount PlantDirect images somehow... now uploading the image...

Isochroma

8th January 2007, 08:57

The AACS they are referring to is probably the Disc Key system. What makes me think this is in the AACS Settings dialog, the Enable AACS checkbox and associated settings are in their own separate area.

Something to test: if you uncheck Enable AACS, do the Title Settings below go gray?

Borbus

8th January 2007, 08:59

Something to test: if you uncheck Enable AACS, do the Title Settings below go gray?

Yes, everything below goes grey.

Borbus

8th January 2007, 09:06

Susana

8th January 2007, 09:29

Same as before, windvd plays mounted .dat and extracted files.

http://img293.imageshack.us/img293/6865/snap1vd2.th.jpg (http://img293.imageshack.us/my.php?image=snap1vd2.jpg)

blutach

8th January 2007, 09:35

Magic Memory = pure BS, don't believe on them! :logfile:Another totally off topic post. Posters have been warned enough. Keep to the topic please! Strike issued.

Regards

Well--in the U.S. we have the DMCA. Other coutries have vairous "exported" versions if it. The DMCA contradicts Fair Use. As far as I can tell, this has not been resolved through either legislative or judicial process. Not everyone wants to risk becoming case law.If you read Doom9's very good synopsis of DMCA (http://www.doom9.org/index.html?/dmca_revealed.htm), you will see provision for Fair Use. It's the reason you can backup your DVD. Should you wish to discuss this further, a separate thread would be more appropriate.

Regards

Golgot13

8th January 2007, 11:12

Ok, here's the PlantDirect image. The AACS stuff makes it much bigger:

http://www.filehost.gr/276912

I'm still not sure if the video is encrypted though because it's exactly the same size but I don't have a registered version of ISOBuster to extract the files with. The keys are the same as before:
Volume: C29E56D1E80EA92B010733C46A73DECA
Title: 6ACF5ADFCFD8A3D404D0DB6155229D36

Your image is not crypted but it is ready to be crypted by HD DVD replicator manufactory
with a specific software from AACS (with yours keys, like CSS with Scenarist SD)....
The video file in movie stream is a H264 encoded by MainConcept 2.0.1889

HP@L4.1 (1920x1084 ?), there is no audio stream.

Golgot13

zeroprobe

8th January 2007, 11:17

Damn it was a nice idea. Back to square one.

Quote from sonopress.co.uk

"The Content owner provides the authored HD DVD data to a licensed replicator, the authoring project needs to be set up or “flagged” for subsequent processing. The AACS Licensing Authority provides the replicator with keys and a Content Certificate that allows the blocking of content to be copied from the playback device or even put settings to the output of a player that allows the downscaling of HD signals at the analogue output in order to prevent copying of the analogue signal.
The replicator then manufactures the HD DVDs, which carry the encrypted content and the AACS data, and they are shipped to the customers. AACS LA also supplies Device Keys and the Public Key to licensed player manufacturers, which will allow legally produced discs to play without problem"

Golgot13

8th January 2007, 11:33

But the information in AACS folder is good, the AACS key of HDDVD replicator is missing....

Golgot13

zeroprobe

8th January 2007, 11:46

without the replicator key would the whole decryption process take place with powerdvd??

would it still grab the title keys etc.

Golgot13

8th January 2007, 11:55

This schema is the AACS chain from HD DVD White Paper (pdf file from
public web site of DVD Forum).

http://img136.imageshack.us/my.php?image=aacschainkm6.jpg

Golgot13

feizex

8th January 2007, 12:19

If the "the information in AACS folder is good". (IE, you have encrypted title key and other info in there)

Are you saying that you have everything but the encrypted video?

Why not just encrypt it with your title key?

There may be other requirements though...
"A Player shall decide that a Disc to be played back is an AACS Disc if the AACS-Compliant drive for the
Player is able to read the PMSN or if the drive is able to read the Volume ID."

Page105 - content binding diagram shows requirements for Media Key Block (MKB), VolumeID and Encrypted Title key.

suxen_drol

8th January 2007, 14:18

question: why write your own crypto implementation, when there exist off-the-shelf libraries? random example: http://www.cryptopp.com/.

answer: obscurity.

cheers,
-- pete

Bystander

8th January 2007, 19:01

Alright, for those who are interested.

Nothing is loaded into memory when PowerDVD is running. It is only when you press the play button.

The code that first loads the AACS files into memory is from the HDDVDAdvNav.dll file. From here the following DLL's are used:

CBS.dll, and FileSystemMgr.dll

Here is the code that loads the AACS files:1009D460 /$ 56 PUSH ESI ; Loads Files into Memory
1009D461 |. 8BF1 MOV ESI,ECX
1009D463 |. E8 A8F7FFFF CALL HDDVDAdv.1009CC10
1009D468 |. 68 C8B71D10 PUSH HDDVDAdv.101DB7C8 ; /Arg3 = 101DB7C8
1009D46D |. 8D86 A0000000 LEA EAX,DWORD PTR DS:[ESI+A0] ; |AACS/MKBROM.AACS
1009D473 |. 50 PUSH EAX ; |Arg2
1009D474 |. 8D8E 9C000000 LEA ECX,DWORD PTR DS:[ESI+9C] ; |
1009D47A |. 51 PUSH ECX ; |Arg1
1009D47B |. 8BCE MOV ECX,ESI ; |
1009D47D |. E8 FEFBFFFF CALL HDDVDAdv.1009D080 ; \HDDVDAdv.1009D080
1009D482 |. 8D8E 24010000 LEA ECX,DWORD PTR DS:[ESI+124]
1009D488 |. FF15 18031A10 CALL DWORD PTR DS:[<&MSVCP71.?c_str@?$ba>; MSVCP71.?data@?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@QBEPB_WXZ
1009D48E |. 50 PUSH EAX ; /Arg3
1009D48F |. 8D96 A8000000 LEA EDX,DWORD PTR DS:[ESI+A8] ; |AACS/VTKF000.AACS
1009D495 |. 52 PUSH EDX ; |Arg2
1009D496 |. 8D86 A4000000 LEA EAX,DWORD PTR DS:[ESI+A4] ; |
1009D49C |. 50 PUSH EAX ; |Arg1
1009D49D |. 8BCE MOV ECX,ESI ; |
1009D49F |. E8 DCFBFFFF CALL HDDVDAdv.1009D080 ; \HDDVDAdv.1009D080
1009D4A4 |. 68 74B81D10 PUSH HDDVDAdv.101DB874 ; /Arg3 = 101DB874
1009D4A9 |. 8D8E C8000000 LEA ECX,DWORD PTR DS:[ESI+C8] ; |AACS/CONTENT_HASH_TABLE2..AACS
1009D4AF |. 51 PUSH ECX ; |Arg2
1009D4B0 |. 8D96 C4000000 LEA EDX,DWORD PTR DS:[ESI+C4] ; |
1009D4B6 |. 52 PUSH EDX ; |Arg1
1009D4B7 |. 8BCE MOV ECX,ESI ; |
1009D4B9 |. E8 C2FBFFFF CALL HDDVDAdv.1009D080 ; \HDDVDAdv.1009D080
1009D4BE |. 68 38B81D10 PUSH HDDVDAdv.101DB838 ; /Arg3 = 101DB838
1009D4C3 |. 8D86 D0000000 LEA EAX,DWORD PTR DS:[ESI+D0] ; |AACS/CONTENT_HASH_TABEL1.AACS
1009D4C9 |. 50 PUSH EAX ; |Arg2
1009D4CA |. 8D8E CC000000 LEA ECX,DWORD PTR DS:[ESI+CC] ; |
1009D4D0 |. 51 PUSH ECX ; |Arg1
1009D4D1 |. 8BCE MOV ECX,ESI ; |
1009D4D3 |. E8 A8FBFFFF CALL HDDVDAdv.1009D080 ; \HDDVDAdv.1009D080
1009D4D8 |. 68 08B81D10 PUSH HDDVDAdv.101DB808 ; /Arg3 = 101DB808
1009D4DD |. 8D96 D8000000 LEA EDX,DWORD PTR DS:[ESI+D8] ; |AACS/CONTENT_CERT.AACS
1009D4E3 |. 52 PUSH EDX ; |Arg2
1009D4E4 |. 8D86 D4000000 LEA EAX,DWORD PTR DS:[ESI+D4] ; |
1009D4EA |. 50 PUSH EAX ; |Arg1
1009D4EB |. 8BCE MOV ECX,ESI ; |
1009D4ED |. E8 8EFBFFFF CALL HDDVDAdv.1009D080 ; \HDDVDAdv.1009D080
1009D4F2 |. 68 B0B81D10 PUSH HDDVDAdv.101DB8B0 ; /Arg3 = 101DB8B0
1009D4F7 |. 8D8E E0000000 LEA ECX,DWORD PTR DS:[ESI+E0] ; |AACS/CONTENT_REVOCATION_LIST.AACS
1009D4FD |. 51 PUSH ECX ; |Arg2
1009D4FE |. 8D96 DC000000 LEA EDX,DWORD PTR DS:[ESI+DC] ; |
1009D504 |. 52 PUSH EDX ; |Arg1
1009D505 |. 8BCE MOV ECX,ESI ; |
1009D507 |. E8 74FBFFFF CALL HDDVDAdv.1009D080 ; \HDDVDAdv.1009D080
1009D50C |. 8D8E 40010000 LEA ECX,DWORD PTR DS:[ESI+140]
1009D512 |. FF15 18031A10 CALL DWORD PTR DS:[<&MSVCP71.?c_str@?$ba>; MSVCP71.?data@?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@QBEPB_WXZ
1009D518 |. 50 PUSH EAX ; /Arg3
1009D519 |. 8D86 C0000000 LEA EAX,DWORD PTR DS:[ESI+C0] ; |AACS/VTUF000.AACS
1009D51F |. 50 PUSH EAX ; |Arg2
1009D520 |. 8D8E BC000000 LEA ECX,DWORD PTR DS:[ESI+BC] ; |
1009D526 |. 51 PUSH ECX ; |Arg1
1009D527 |. 8BCE MOV ECX,ESI ; |
1009D529 |. E8 52FBFFFF CALL HDDVDAdv.1009D080 ; \HDDVDAdv.1009D080
1009D52E |. 5E POP ESI
1009D52F \. C3 RETN

Also the program uses HeapFree which is a Kernal32 command to overwrite the data it uses. A simple patch would allow the code to remain in memory if you know what you are looking for.

The magic call to remove the AACS stuff is here:028D4D4B /74 09 JE SHORT FileSyst.028D4D56 ; force this jump
028D4D4D . |50 PUSH EAX
028D4D4E |E8 87320000 CALL <JMP.&MSVCR71.??_V@YAXPAX@Z> ; clears heap ... file info is gone

In this section forcing the JE to JMP would bypass it without corrupting the stack.

This should get you started.... enjoy

P.S. After it's loaded might want to break into the RSAENH.dll (windows\system32 directory) and you'll notice it's doing the Cryptography (SHA1 too). And remember to stop the HeapFree command when you are tracing to stop it from hiding it's tracks.

Jerky_san

8th January 2007, 19:27

1009D48F |. 8D96 A8000000 LEA EDX,DWORD PTR DS:[ESI+A8] ; |AACS/VTKF000.AACS so it loads the all talked about file just after it loads

1009D46D |. 8D86 A0000000 LEA EAX,DWORD PTR DS:[ESI+A0] ; |AACS/MKBROM.AACS

Then it loads up 2 sets of hash tables along with the Revocation list along with a
1009D4DD |. 8D96 D8000000 LEA EDX,DWORD PTR DS:[ESI+D8] ; |AACS/CONTENT_CERT.AACS (wonder what this file has)

and then

1009D519 |. 8D86 C0000000 LEA EAX,DWORD PTR DS:[ESI+C0] ; |AACS/VTUF000.AACS

VTKF000.AACS and VTUF000.AACS The Change in the K and U are these the K and U that they are talking about in the specs? You add them together you get the key?

Also perhpas they are right they didn't use the RAM but instead kept it all in the registers of the CPU? .. I dunno though Me + Assembly = Bad grade last semester so I dunno if I reading it right..

Bystander

8th January 2007, 19:41

The code does exist in memory. Regardless if it's in the drive or the computer it must reside in the memory before it gets to the processor. Most protections will mask/overwrite the code once it does what it needs to do which literally removes it from memory.

Nothing magical about that.

tonyp12

8th January 2007, 20:51

Isochroma

8th January 2007, 21:05

Good morning all! I see there's been much activity since yesterday...

There is no need to bring the keyed but unencrypted files to a licensed HD-DVD replicator to get them encrypted... here is one example of software on the market :

Eclipse Data Releases High-Speed Blu-ray AACS Encryption Software (http://www.emedialive.com/Articles/ReadArticle.aspx?ArticleID=11623)

"We knew that we needed to minimize the impact of moving encryption into the premastering process"

Premastering is what you do with the Sonic package. This means you can get secondary software which will take the fileset made by Sonic and convert it to a fully AACS-encrypted fileset or ISO image.

Sonic only adds AACS information to DDP images, also known as PlantDirect:

"A powerful add-on option for Scenarist Studio (SEN-3101), PlantDirect Tapeless Premastering allows DDP file sets to be written to hard disk, rather than to DLT, enabling delivery of DVD masters for replication via the Internet saving time and money on physical shipments." (http://www.filmwareproducts.com/Sonic/SEN-3111.html)

DDP is the industry standard for disc imaging, and was established by a company known as DCA Inc. They established the standard, so it should surprise nobody that they also make a product called Blazer:

Blazer is an application designed to encrypt a DDP V3.0 HD ROM image with the Advanced Access Content System (AACS) encryption. Blazer automatically recalculates the HCRC in the AACS encrypted image. (http://www.dcainc.com/products/ddptools/blazer/index.html)

I contacted the company by phone this morning, and found out that the software, while it runs on XP (screenshot (http://www.dcainc.com/products/ddptools/blazer/blazerprogress.jpg)), only comes bundled with a workstation machine with RAID, etc. The cost is probably high, I didn't ask, but will do so later today and report my findings.

Other than this it seems the Sonic product "DVDit Pro HD (http://www.roxio.com/enu/products/dvdit/hd/overview.html)" can author AACS protected Blu-Ray DDP filesets, but it doesn't have HD-DVD functionality.

Finally, an email was sent to Eclipse requesting a price quote for their EclipseSuite + AACS addon software. It runs on any hardware (ie. software-only); the specifications page (http://www.eclipsedata.com/products/eclipsesuite/index.htm) states that it will run on Windows NT 4.0, 2000 and XP. It also seems to need an Adaptec SCSI controller, but those are cheap.

feizex

8th January 2007, 21:07

FYI...
http://www.youtube.com/profile?user=muslix64
muslix64
Age: 26
Country: Canada

ron spencer

8th January 2007, 21:09

FYI...
http://www.youtube.com/profile?user=muslix64
muslix64
Age: 26
Country: Canada

I doubt that is true....he (or she) is not that stupid.

8th January 2007, 21:11

Is Bystander = Muslix64.

Just joined and pretty much tells how to get the
keys but without telling all of it.
Sounds like Muslix, and using a second screen name will
lessen the chance of getting traced and sued.

I think Muslix is from Germany, where the cereal is from and a land where Commodore 64 was a hackers first toy.

This is just speculations, and Mods can delete this post if it's
out of bound/irrelevant.

I don't think it matters who Bystander is. He seems like a knowledgable person and it looks as if he would be an asset to this community. You shouldn't question the identities of people. If they want you to know who they are then they would tell you.

Yes it is speculation and you should use your own judgement and delete it yourself if you think it is out of line.

CiTay

8th January 2007, 21:18

Please, it shouldn't matter who one or the other is. What they post is important.

Borbus

8th January 2007, 21:40

There were actually other files with the PlantDirect image, they might be important if anyone manages to get hold of Blazer or an equivalent. Note how small it all is when RARed, I suppose it's the blank revocation files.

http://www.filehost.gr/883400

The IMAGE.DAT is the same as before.

I was going to make a short video with more than just a blank screen and maybe audio too, but, this sounds really stupid, I couldn't think of a way to encode just a few seconds of video with MainConcept... Any idea how to make a short animated clip with AVISynth?

communist

8th January 2007, 21:54

Simple solution: use Colorbars(width,height) and ShowFrameNumber().

neviens

8th January 2007, 22:18

Some observations for those with HDDVD drive and know, what OllyDbg is.
Seems, HDDVDAdvNav.dll is a module where stuff is located.
Here are all AES function calls:

;-----------------------------------------------------------
...
.text:100C350F push 1 ; crypto mode
.text:100C3511 lea ecx, [ebp+var_40]
.text:100C3514 call CryptoModeSelector ; 1 == CBC decrypt
.text:100C3519 mov [ebp+var_4], 0
.text:100C3520 lea eax, [ebp+var_40]
.text:100C3523 push 80h ; int
.text:100C3528 push [ebp+arg_0] ; KEY!
.text:100C352B push eax ; int
.text:100C352C call AES_KeyExpand
.text:100C3531 mov ebx, eax
.text:100C3533 test ebx, ebx
.text:100C3535 jl short loc_100C355F
.text:100C3537 push offset CBC_InitVector ; ==0BA0F8DD..
.text:100C353C lea eax, [ebp+var_40]
.text:100C353F push eax ; int
.text:100C3540 call _initCBC
.text:100C3545 mov ebx, eax
.text:100C3547 test ebx, ebx
.text:100C3549 jl short loc_100C355F
.text:100C354B push [ebp+arg_C] ; data len
.text:100C354E push [ebp+arg_8] ; output
.text:100C3551 push [ebp+arg_4] ; input
.text:100C3554 lea eax, [ebp+var_40]
.text:100C3557 push eax ; expanded switch
.text:100C3558 call AES_SwitchFunc2
.text:100C355D mov ebx, eax
.text:100C355F
.text:100C355F loc_100C355F: ; CODE XREF: CBC_decrypt+4Dj
.text:100C355F ; CBC_decrypt+61j
.text:100C355F mov [ebp+var_4], 0FFFFFFFFh
.text:100C3566 lea ecx, [ebp+var_40]
.text:100C3569 call ClearExpandedKey
...
It was CBC mode, most likely content decryption, Title key??

;-----------------------------------------------------------
.text:100C35E8 push 21h ; crypto mode
.text:100C35EA lea ecx, [ebp+var_54]
.text:100C35ED mov [ebp+var_14], edx
.text:100C35F0 call CryptoModeSelector ; 21== ECB decrypt
.text:100C35F5 mov edx, [ebp+var_14]
.text:100C35F8 mov [ebp+var_4], 0
.text:100C35FF mov ecx, [ebp+var_1C]
.text:100C3602 lea ebx, [ebp+var_54]
.text:100C3605 push 80h ; int
.text:100C360A mov [ebp+var_14], edx
.text:100C360D push ecx ; KEY!
.text:100C360E push ebx ; int
.text:100C360F call AES_KeyExpand
.text:100C3614 mov edx, [ebp+var_14]
.text:100C3617 mov ebx, eax
.text:100C3619 test ebx, ebx
.text:100C361B jl loc_100C36AE
.text:100C3621 mov ecx, [ebp+var_20]
.text:100C3624 lea ebx, [ebp+var_54]
.text:100C3627 push 10h ; data len
.text:100C3629 mov [ebp+var_14], edx
.text:100C362C push ecx ; output
.text:100C362D push edx ; input
.text:100C362E push ebx ; expanded key
.text:100C362F call AES_SwitchFunc2
...
This one was Triple AES Generator (AES-G3)

;-----------------------------------------------------------
.text:100C3C47 push 21h
.text:100C3C49 lea ecx, [ebp+var_40]
.text:100C3C4C call CryptoModeSelector ; 21== ECB decrypt
.text:100C3C51 mov [ebp+var_4], 0
.text:100C3C58 lea eax, [ebp+var_40]
.text:100C3C5B push 80h ; int
.text:100C3C60 push [ebp+arg_0] ; KEY!
.text:100C3C63 push eax ; int
.text:100C3C64 call AES_KeyExpand
.text:100C3C69 mov ebx, eax
.text:100C3C6B test ebx, ebx
.text:100C3C6D jl short loc_100C3C82
.text:100C3C6F lea eax, [ebp+var_40]
.text:100C3C72 push 10h ; data len
.text:100C3C74 push [ebp+arg_8] ; output
.text:100C3C77 push [ebp+arg_4] ; input
.text:100C3C7A push eax ; expanded key
.text:100C3C7B call AES_SwitchFunc2
.text:100C3C80 mov ebx, eax
.text:100C3C82
.text:100C3C82 loc_100C3C82: ; CODE XREF: sub_100C3C20+4Dj
.text:100C3C82 mov [ebp+var_4], 0FFFFFFFFh
.text:100C3C89 lea ecx, [ebp+var_40]
.text:100C3C8C call ClearExpandedKey
...
ECB stuff

;-----------------------------------------------------------
.text:100DBFE6 push 21h ; crypt mode
.text:100DBFE8 lea ecx, [ebp+var_54]
.text:100DBFEB call CryptoModeSelector ; 21== ECB decrypt
.text:100DBFF0 mov [ebp+var_4], 0
.text:100DBFF7 mov eax, [ebp+var_20]
.text:100DBFFA lea edx, [ebp+var_54]
.text:100DBFFD push 80h ; int
.text:100DC002 push eax ; KEY!
.text:100DC003 push edx ; int
.text:100DC004 call AES_KeyExpand
.text:100DC009 mov eax, [ebp+var_1C]
.text:100DC00C mov edx, [ebp+var_24]
.text:100DC00F lea ecx, [ebp+var_54]
.text:100DC012 push 10h ; data len
.text:100DC014 push eax ; output
.text:100DC015 push edx ; input
.text:100DC016 push ecx ; expanded key
.text:100DC017 call AES_SwitchFunc
.text:100DC01C mov eax, [ebp+var_1C]
.text:100DC01F movzx edx, byte ptr [eax]
.text:100DC022 test edx, 80h
.text:100DC028 jnz short loc_100DC084
...

This one looks interesting!
Chapter 3.2.4, Calculation of Processing Key?

;-----------------------------------------------------------
.text:100DC49C call CryptoModeSelector ; 1 == CBC decrypt
.text:100DC4A1 mov edx, [ebp+var_18]
.text:100DC4A4 mov [ebp+var_4], 1
.text:100DC4AB mov eax, [ebp+var_24]
.text:100DC4AE lea ecx, [ebp+var_C0]
.text:100DC4B4 push 80h ; int
.text:100DC4B9 mov [ebp+var_18], edx
.text:100DC4BC push eax ; KEY!
.text:100DC4BD push ecx ; int
.text:100DC4BE call AES_KeyExpand
.text:100DC4C3 mov edx, [ebp+var_18]
.text:100DC4C6 lea ebx, [ebp+var_C0]
.text:100DC4CC lea ecx, [ebp+var_78]
.text:100DC4CF lea eax, [ebp+var_68]
.text:100DC4D2 push 10h ; data len
.text:100DC4D4 mov [ebp+var_18], edx
.text:100DC4D7 push eax ; output
.text:100DC4D8 push ecx ; input
.text:100DC4D9 push ebx ; expanded key
.text:100DC4DA call AES_SwitchFunc
.text:100DC4DF mov edx, [ebp+var_18]
.text:100DC4E2 mov [ebp+var_4], 0FFFFFFFFh
.text:100DC4E9 lea ecx, [ebp+var_C0]
.text:100DC4EF mov [ebp+var_18], edx
.text:100DC4F2 call ClearExpandedKey

CBC decrypt again.

;-----------------------------------------------------------
.text:100DC79C call CryptoModeSelector ; 1 == CBC decrypt
.text:100DC7A1 mov eax, [ebp+var_14]
.text:100DC7A4 mov [ebp+var_4], 0
.text:100DC7AB mov edx, [ebp+var_24]
.text:100DC7AE lea ecx, [ebp+var_9C]
.text:100DC7B4 push 80h ; int
.text:100DC7B9 mov [ebp+var_14], eax
.text:100DC7BC push edx ; KEY!
.text:100DC7BD push ecx ; int
.text:100DC7BE call AES_KeyExpand
.text:100DC7C3 mov eax, [ebp+var_14]
.text:100DC7C6 lea ebx, [ebp+var_9C]
.text:100DC7CC lea ecx, [ebp+var_58]
.text:100DC7CF lea edx, [ebp+var_48]
.text:100DC7D2 push 10h ; data len
.text:100DC7D4 mov [ebp+var_14], eax
.text:100DC7D7 push edx ; output
.text:100DC7D8 push ecx ; input
.text:100DC7D9 push ebx ; expanded key
.text:100DC7DA call AES_SwitchFunc
.text:100DC7DF mov eax, [ebp+var_14]
.text:100DC7E2 mov [ebp+var_4], 0FFFFFFFFh
.text:100DC7E9 lea ecx, [ebp+var_9C]
.text:100DC7EF mov [ebp+var_14], eax
.text:100DC7F2 call ClearExpandedKey
...
CBC decrypt with xoring...

Borbus

8th January 2007, 22:50

Simple solution: use Colorbars(width,height) and ShowFrameNumber().

Colorbars() makes 1hr of video by default. How can I change that to something shorter?

edit: Nevermind, did it with Trim()

blutach

8th January 2007, 23:30

Is Bystander = Muslix64.

Just joined and pretty much tells how to get the
keys but without telling all of it.
Sounds like Muslix, and using a second screen name will
lessen the chance of getting traced and sued.

I think Muslix is from Germany, where the cereal is from and a land where Commodore 64 was a hackers first toy.

This is just speculations, and Mods can delete this post if it's
out of bound/irrelevant.

FYI...
http://www.youtube.com/profile?user=muslix64
muslix64
Age: 26
Country: Canada

Sigh.... Why won't some posters read what we type and read the rules? Strikes issued.

Regards

Borbus

8th January 2007, 23:34

Ok, here's another image with Colorbars and a Framecount instead of nothing. Analogue output is now allowed instead of constrained.

http://www.filehost.gr/73129

The volume and title keys are in the discinfo.dat file (volume key first, then title key).

Now there's probably not much else to play around with until someone can get hold of Blazer of figure out how to encrypt the video.

Polly

8th January 2007, 23:39

I'm designing a GUI for the HDDVD backup and attempting to make an easy way to enter the keys in as you get them.

Since I don't have an HDDVD player it makes it impossible for me to change any of the source that muslix provides and guarantee it works, and as such I will simply make a wrapping gui for the backup classes. If he continues to put up future releases it should be easy to plug in the new version into the gui.

http://img166.imageshack.us/img166/9430/screenshotnv2.jpg

This is a 30 second design in java, but it makes it easier to use. I'll be posting it soon for those who want an interface rather than command line.

Isochroma

8th January 2007, 23:48

@Borbus: Thank you!

I haven't yet receive a reply from Eclipse. It seems that for now, the best way to verify BackupHDDVD's functionality is to obtain an HD-DVD drive, AACS-protected HD-DVD disc, and player software.

The Title Key must be available in the clear during the entire playback process, as it is needed to decrypt each chunk of data as it is read.

Keeping the Title Key scrambled using the player software's algorithm or encrypted from disc would place a heavy burden on the CPU during playback, as it would have to be repeatedly decrypted to be used for chunk decryption, throughout playback.

Considering that most machines are only just able to decode 1080p content alone, it seems unlikely that software authors would cripple their product's performance using such a method.

hajj_3

9th January 2007, 00:06

if you guys want some hd-dvd's to test you can get 2 for £2.86 delivered from a mis-price on play-asia: http://www.hotukdeals.com/forums/showthread.php?t=42021

@ polly - great work, release the sourcecode when your done. also change the image of the dvd to this: http://www.hazi-mozi.hu/cfiles/527/HD-DVD_logo.jpg

calinb

9th January 2007, 00:48

Keeping the Title Key scrambled using the player software's algorithm or encrypted from disc would place a heavy burden on the CPU during playback, as it would have to be repeatedly decrypted to be used for chunk decryption, throughout playback.

Considering that most machines are only just able to decode 1080p content alone, it seems unlikely that software authors would cripple their product's performance using such a method.I believe they have, in fact, done so and the title keys may not remain in the clear for long. The player behavior I've seen is consistent with the code snippets Bystander posted. The player accesses the encrypted title keys in memory every few hundred milliseconds or so. I've also seen it clear heap memory.

The CPU load is enormous and regenerating keys whenever necessary, on the fly, could easily be accomplished, within the high load. Besides, compared to decrypting the content, decrypting the keys should not result in much additional load. I have a computer that plays high profile AVC HD with CoreAVC nicely. The computer can't even come close to decoding a VC-1 HD-DVD without dropping frames all over the place. The developers were probably more concerned with implementing DRM than realizing performance.

Bystander's suggestions are useful, based on the behavior I've captured.

Jerky_san

9th January 2007, 00:55

Isochroma

9th January 2007, 02:05

I just received an email reply from the folks at Eclipse, regarding the costs for an AACS license (required before Eclipse will sell you their product):

"It's pretty expense. You can find more information at: http://www.aacsla.com/home

I think the adopter agreement costs about $20,000 per year, and then AACS collects about $2,000 per title, and $0.04 per disc."

calinb

9th January 2007, 02:57

So basically we can either add the steps in that were suggested or create a breakpoint JUST before the heap clears and instead dump the memory. What are you all using to play this.. My version of WinDVD HD crashes when I load the file..Sounds like a reasonable approach to try. I suspect that most people are following Muslix64's suggestion to use PowerDVD 6.5 but he said other players may yield keys too. Try launching or enabling your debugger after a title is playing and remember that the AACS spec says stuff must be cleared when the player is stopped. I don't know about pausing play.

El Toro

9th January 2007, 05:08

It seems amazing, on how one posting has created a lot of conversation on the subject in question burning a HD-DVD and yet no one is able to burn one. Will sit in the background and see what this thread leads to.:D

Susana

9th January 2007, 05:46

You can burn a hd-dvd in a standard dvd. Indeed, you can already demux a hd-dvd (dvdlogic has a demuxer), compress video to avc lowering bitrate and reauthor. ;)

Bystander

9th January 2007, 05:56

Ábudos

9th January 2007, 06:02

Working to find a Title Key is all good and dandy, but shouldn't more effort be placed on getting ahold of a Volume Unique Key as the AACS specifications say that some videos could require the use of multiple Title Keys.

neviens

9th January 2007, 08:30

The file 001.fcl is loaded by Cyberlink and is used in the computation.

If you bp where neviens suggests you will get a chance to see where the 001.fcl code is used in the calculations. This leads me to believe this is the number that is unique to Cyberlink for future changes/updates.

It's very unique! Device keys are stored in this file.

...
My version of WinDVD HD crashes when I load the file..

WinDVD is attempting to use some antidebugging techniques.
You can estimate which player is less secure now :)

zeroprobe

9th January 2007, 10:29

still no method of us non hd-dvd owners can test this?

Borbus

9th January 2007, 11:26

You could try using the images I put up a few posts ago. The video isn't encrypted but PowerDVD might still load the volume/title key.

I can't get them to work without a UDF 2.5 filesystem driver though. The Toshiba one won't install, probably because I have no HD-DVD drive. Anyone know how to get UDF 2.5 to work with a Daemon Tools drive?

troubler

9th January 2007, 11:59

*cough* virtualisation *cough*

maybe take a little look at debugging a virtual machine, giving you access to the complete memory structure ( whether windows tries to protect or not ) at all times. you wont have native hdcp support, but should be able to view downscaled, and therefore grab the neccesary title keys.

*walks away quickly*

tjf

9th January 2007, 12:02

Borbus: It worked fine on my system without HD-DVD. Make sure you have the latest Daemon Tools and this http://rapidshare.com/files/3149367/XBOX360-1.HD-DVDRom.UDF.Reader.v2.5.WindowsXP-BluePrint.rar.html UDF driver.

JK1974

9th January 2007, 14:17

What about Neros InCD? I heard that this one also does the UDF 2.5 stuff.

kolak

9th January 2007, 15:54

All what you need is Deamon tools (I have old 3.47v.) and installed Nero InCD. Works perfectly.

Borbus

9th January 2007, 19:29

Daemon Tools + that Toshiba driver posted by tjf works. Thanks.

Janvitos

9th January 2007, 21:53

Hey people, i'm glad i can post now.

Just to let you guys know, i've been playing around with a debugger (OllyDbg), a plugin to hide the debugger (IsDebuggerPresent) and PowerDVD. I've been reading through this thread for the passed few days and have gone through many trials and errors to try and find the mystery keys.

Here is a link to the debugger: http://www.kongoo.com/odbg110.zip
Here is a link to the plugin: http://www.kongoo.com/SV_IsDebug14.zip

By the way, if the debugger crashes sometime after you pushed the "play" button, give it the Shift + F7 command, press "play" again, if the movie doesn't start playing, give it the Shift + F7 command and push "play" one last time. When ever the movie crashes, you can do this and it worked for me all the times.

Now that we know that we can't encrypt our own AACS content, i guess we'll have to debug the hard way.

In OllyDbg, i've been looking at patterns of the PowerDVD memory while HD-DVD content is being played. I'm not sure if it has anything to do with the keys, but anyone that has OllyDbg with PowerDVD will notice that some memory at particular addresses change every few seconds or so.

Here are the changing addresses:

02690000
02772000
0277E000

02C69000
02C88000

732F0000 mscat32
732F1000 mscat32 .text
732F2000 mscat43 .data
732F3000 mscat32 .rsrc
732F4000 mscat32 .reloc

Now, since i am no ASM guru, i am not able to do much with these.
There might be other changing addresses as well, some of them are hard to grasp.

If this might help anybody, maybe we can get more clues and get closer to these keys.

ilaps

9th January 2007, 22:16

• You perhaps could try a brutal and simple way : with a dump you can reduce tremendously the exhaustive search of the media key (verification values are described in the AACS specs). With 128 bits keys, 2^128=10^37 trials are necessary with AES: if we take one ms per test, you need 3 10^26 years! Forget it. But if you locate key somewhere in a 1 MB space in the RAM of the PC, and simply stored as a 16 bytes array, you only need 10^6 tests, or 17 minutes!
• Does SO know if the Hollywood content Providers have or will have some policy to accept HD on PC only if they can be trusted, ie not only with OS like VISTA but more over with the stuff defined in TCG (old name TCPA) based on a trusted module called TPM and a lot of other features? Does it require VISTA "ultimate" and not the "basic / premium/ business" versions?
More over are these new approaches really trustable? ie it is likely that executing a player under the control of a debug program will be impossible, but is it possible to prevent to force a crash and perform afterwards a dump of RAM memory, for example?

Janvitos

9th January 2007, 22:33

I laso noticed that some code is written / deleted at the following address:

02735000

The code is:

02735000 42 INC EDX
02735001 0100 ADD DWORD PTR DS:[EAX],EAX
02735003 00EE ADD DH,CH
02735005 04 EE ADD AL,0EE
02735007 0108 ADD DWORD PTR DS:[EAX],ECX
02735009 0075 02 ADD BYTE PTR SS:[EBP+2],DH
0273500C 8837 MOV BYTE PTR DS:[EDI],DH
0273500E 76 02 JBE SHORT 02735012

Btw, PowerDVD DOES check for a debugger on "play".

Janvitos

9th January 2007, 23:01

I also wanted to note that some constants of the AES-128 encryption / decryption can be found in a few places in memory such as:

- Rcon from the Rijndael key schedule
- Rijndael's S-box
- Inversed S-box
- Iv0 which is the initialisation vector for AES-128CBCE and AES-128CBCD

If you want to find these constants in the memory yourselves, simply load up your debugger with PowerDVD, push the "play" button and then do a search for these constants:

- Rcon: 63 7c 77 7b
- S-box: 01 00 00 00 02 00 00 00 04 00 00 00 08 00 00 00
- Inversed S-box: 52 09 6A D5
- Iv0: 0B A0 F8 DD

Like noted previously, these would have to be used at some point for encrypting / decrypting the keys.

honai

10th January 2007, 00:02

Yes, I pointed that out previously, but didn't think that anyone actually noticed.

Basically, you'll only need to hook into the key schedule function since that one is being fed the raw decryption key. The AES-128 decryption function itself uses that computed key schedule later on, so hooking into that would be too late already.

Pseudo-code for the key schedule looks something like this:

for i from 0 to Nk-1 {
w[i] = word (key[4*i], key[4*i+1], key[4*i+2], key[4*i+3])
}

for i from Nk to Nb(Nr+1) -1 {
if (i is multiple of Nk) then {
w[i] = SubstituteBytes( PermuteWord(w[i-1]) ) XOR RoundConstant[i/Nk]
} else if (Nk = 8 and i - 4 is multiple of Nk) then {
w[i] = SubstituteBytes( w[i-1] )
}
w[i] = w[i] XOR w[i-Nk]
}

MickeyNumberEight

10th January 2007, 00:05

Hi

My first post here, so I would like to tell what software I use to manipulate and dump memory, debug and so on. There is very good debugger IDA PRO http://www.datarescue.com/ and file/disk/memory editor http://www.x-ways.net/winhex/ which helped me a lot with weird protections. I don't have HD-DVD drive yet, but soon I will buy one, and I will join you.

Greetings for all.

Janvitos

10th January 2007, 00:23

If anyone is interested to live chat, we could all gather up on IRC on EFNet on the #doom9 channel. We can then share ideas live and maybe progress quicker.

Just a thought.

cyberpass

10th January 2007, 00:44

Sounds like a lot of fun...I would like to create a bulletin bored with your up to the minute updates on finding a key/crack at http://www.aacskeys.com . What do you guys think?

The_ByteMaster

10th January 2007, 05:17

After discussion with Doom9, it has been decided to allow publication of decryption keys

I've noticed in the FAQ.txt for 0.99 and 1.00, Muslix64 uses the following example TITLE key:

12-08A3DC61910280F2...

None of the example discs in the .cfg files use key # 12, but so far I haven't seen confirmed nor denied that this is part of an actual title key (instead of some random hex gibberish). Did Muslix leave this there on purpose -without mentioning which disc it is- so people can look for this string in memory/registers?

(I don't own a HDDVD drive so I can't help out).

Beastie Boy

10th January 2007, 09:01

Just a thought...
If BackupHDDVD is able to take an encrypted video and a key, and from that write an unencrypted video, can it be modded to take an unencrypted video with key and produce encrypted video?

There seem to be quite a few posts around claiming that BackupHDDVD is very simple Java code that pulls together standard encryption packages and writes the output. I'm assuming that if packages exist to decode AACS encryption, then they also exist to encode.

If this is the case, then it would be possible to produce encrypted content for which the key is known.

Cheers, Beastie.

Pomyk

10th January 2007, 10:05

For the video stream it would be possible, but not for the keys (they are encrypted differently).

He-Man

10th January 2007, 10:57

I've noticed in the FAQ.txt for 0.99 and 1.00, Muslix64 uses the following example TITLE key:

12-08A3DC61910280F2...

None of the example discs in the .cfg files use key # 12, but so far I haven't seen confirmed nor denied that this is part of an actual title key (instead of some random hex gibberish). Did Muslix leave this there on purpose -without mentioning which disc it is- so people can look for this string in memory/registers?

(I don't own a HDDVD drive so I can't help out).

If looking for the the FAQ.txt key snippet doesn't work, maybe the easiest would be playing the movie "Van Helsing" and only look for memory locations starting with 19 to find the title key.
Maybe try to first play Van Helsing and then play for example Tomb Raider 1 and then look for memory locations changing from 19 to 6 (is it 06 ??).

CE6339246F34087AB355681DEB656D23DCD5BD86=Full Metal Jacket | 1-00000000000000000000000000000000
486198E3855B57CD40F6DC0C60645BDE8E1E9AC5=Van Helsing |19-00000000000000000000000000000000
B5A8E784B83E793AB246D0C5F7C148A39D7F4856=Tomb Raider 1 | 6-00000000000000000000000000000000
4ACABE525F5CBF77DAA43EA2B83E04918D5FA6D4=Apollo 13 | 1-00000000000000000000000000000000
3D357B0653A66176583C5218FD0149EAF8832FB0=The Last Samurai | 1-00000000000000000000000000000000
610CF1EB362D40050123E92F063D51AC05676F37=The Fugitive | 1-00000000000000000000000000000000

Field 1 is the SHA1 Hash of the VTKF000.AACS file on your HDDVD disk, you can use this to make sure you got the same movie version as used above.

crashd

10th January 2007, 16:32

Perhaps a "side channel" attack could be implemented, similar to the one described in Adi Shamir's Cache Timing Attack (http://www.wisdom.weizmann.ac.il/~tromer/papers/cache.pdf)? Just throwing it out there :)

inurenegade

10th January 2007, 18:37

just curious what are the unencrypted keys supposed to be in
hex, decimal, octal, binary?

Gradius

10th January 2007, 19:21

Looks like to be decimals.

19-A8249382FD7237CA etc, would looks odd !

Anyway it should to be HEX ! (doh!)

Warren

10th January 2007, 19:56

Just so you know, the XX- is not a part of the key (it's the key #) and the textual representation of the keys that you see is not what would be in memory. You would have to convert that Hex string to actual hex values which would be half the length of the string, ie 16 bytes.

Janvitos

10th January 2007, 22:27

I wonder why he didn't put the king kong movie in there.
After all, it does come free with the Xbox 360 HD-DVD drive.

Frank Kao

10th January 2007, 23:56

To see Muslix64's java code, I noticed that Muslix64 did not do a very complex task. But now, so many people start dump PowerDVD's memory and trace PowerDVD's code, but we still cannot do the same thing as Muslix64. why ?

In the FAQ, Muslix64 said he has two players and he found the key in the memory. So I give up trace PowerDVD's code and try to dump WinDVD's memory. Wa, I can found the title key in the WinDVD's memory and use this key to rip the movie. You should be curious about why I know this is a title key. ^Q^ I just put the value into backupHDDVD.

Now, I realize the whole Muslix64's story. Why did Muslix64 play the video with PowerDVD? ^Q^ That is because WinDVD cannot play .evo file. We waste too much time is just we chosen a wrong player.

Warren

11th January 2007, 00:03

Care to enlighten us on how to find keys in WinDVD then Frank? Breakpoint addresses and instructions on how to find the key from there would be nice.

cyber1

11th January 2007, 00:10

Janvitos

11th January 2007, 01:33

Can anybody enlighten me as to what WinDVD version plays HD-DVDs ?
I got my hands on WinDVD 8 but it wont play any HD-DVD movies i feed it.

Frank Kao

11th January 2007, 01:56

Yes, but every software-player will have the key in memory at some time, however some may be easier to debug. And when they revoke WinDVDs player key, we still need to find another player, so its good to have several players memory "debugged".

Yes, you are right. After we finding a key in a player, then AACS will revoke the device key of the player. So we must do again and again the same thing. And of course the player will try to make it stronger than previous version. So we will very tired always.
This is also the purpose of AACS, it knows it is impossible to do a un-crackable device or software, so it designs a way to revoke the device key. Finally, we will give up to crack it. Because it is too tired and too bored.

Frank Kao

11th January 2007, 01:59

Care to enlighten us on how to find keys in WinDVD then Frank? Breakpoint addresses and instructions on how to find the key from there would be nice.

Sorry, I do not trace the WinDVD code by Ollydbg or Idapro. I just search the memory and call backupHDDVD. If the value can rip a short segment of video header, I think I find it. It mays take a long time but it works.

feizex

11th January 2007, 02:06

Hi Frank,

Sounds like you found the key.

Send it in a private message to blutach

Quick Links > Private Messages > Send New Message

If you can, send him the complete line out of the BACKUPHDDVD TKDB.cfg file.

Regards,
Feizex.

Warren

11th January 2007, 02:25

Frank, so have you successfully found a key yet using this technique or is this just what you're planning on doing?

Frank Kao

11th January 2007, 02:36

Frank, so have you successfully found a key yet using this technique or is this just what you're planning on doing?

Now, I can realize why Muslix64 do not talk any more. This topic is too sensitive. I just want to say "Muslix64 did not lie". You can do it by yourself, and then you will find everything you want.

DerKönig

11th January 2007, 03:07

@Frank:

The latest version of WinDVD i.e. ver 8 does not play HD-DVD or bluray discs yet (says so on Intervideo's website also). So Im wondering what version of WinDVD did you use to play while you dumped the memory...

DerKönig

11th January 2007, 03:16

Muslix64 had stated that the reason he got to write BackupHDDVD is because (from his Saga.txt):

"But when I realized the 2 software
players on windows don't allowed me to play the movie at all, because my video card is not HDCP compliant and because I
have a HD monitor plugged with DVI interface, I started to get mad..."

Notice that he said he had 2 software players. He also repeatedly stated that "as long as there are weak players, key extraction will be possible" He used PowerDVD in the video and Cyberlink stated many times that PowerDVD is secure.... leads me to think that the other player that Muslix64 had was the weak one from which key extraction from memory was possible. Perhaps the reason why he chose not to mention the name of the player or show it in the video is because once the player is known, the device key would be revoked....

Could people who know please post all the makes and versions of software players out there that are currently capable of HD-DVD playback....

tonyp12

11th January 2007, 03:18

Only Windvd-8 Japanese version can play HD-DVD

The $26 upgrade HD pack is very close to be released.

If you could get a free trail download of this pack to
go with the free trial of WinDVD 8 Platinum you could tinker around for awhile.

But no news when the HD pack is coming out.

DerKönig

11th January 2007, 03:23

@Frank:

so did you use the Japanese version 8 of WinDVD capable of HD-DVD playback?

VistaVick

11th January 2007, 03:24

I can confirm it has been done....only a matter of time before it spreads.

Isochroma

11th January 2007, 03:41

WinDVD has a plugin that allows it to play HD-DVD and Blu-Ray discs. The plugin is available but they state on their site (http://www.intervideo.com/WinDVD/) that:

HD DVD and Blu-ray Playback Support:
To be purchased separately. Available soon - check back often!

It is already available but they seem to be making it hard to get the plugin.

Regarding the player key, there are only three scenarios (only if the player key is leaked):

1. Players each have an individual key.
Revoking one player's key means no consequences for everyone else, but if many are cracked, the 1MB revocation table on HD-DVD discs will fill up rapidly.

Losers: AACS LA
Winners: Consumers, crackers (when table is full).

2. Each brand/version of a player has only a single key.
Revoking this key means a large number of people will be very angry, file lawsuits, etc.

Losers: large number of player-buying consumers, definitely software publisher.
Winners: AACS LA

3. Groups of 50-1000 players each have a unique key.
Revoking this key means significant groups of people will be very angry, file lawsuits, etc.

Losers: medium-sized blocks of player-buying consumers, possibly software publisher.
Winners: AACS LA

noclip

11th January 2007, 04:51

If looking for the the FAQ.txt key snippet doesn't work, maybe the easiest would be playing the movie "Van Helsing" and only look for memory locations starting with 19 to find the title key.
Maybe try to first play Van Helsing and then play for example Tomb Raider 1 and then look for memory locations changing from 19 to 6 (is it 06 ??).

CE6339246F34087AB355681DEB656D23DCD5BD86=Full Metal Jacket | 1-00000000000000000000000000000000
486198E3855B57CD40F6DC0C60645BDE8E1E9AC5=Van Helsing |19-00000000000000000000000000000000
B5A8E784B83E793AB246D0C5F7C148A39D7F4856=Tomb Raider 1 | 6-00000000000000000000000000000000
4ACABE525F5CBF77DAA43EA2B83E04918D5FA6D4=Apollo 13 | 1-00000000000000000000000000000000
3D357B0653A66176583C5218FD0149EAF8832FB0=The Last Samurai | 1-00000000000000000000000000000000
610CF1EB362D40050123E92F063D51AC05676F37=The Fugitive | 1-00000000000000000000000000000000

Field 1 is the SHA1 Hash of the VTKF000.AACS file on your HDDVD disk, you can use this to make sure you got the same movie version as used above.

That's just Muslix's bizarre way of formatting the title key index, which is worthless.

Janvitos

11th January 2007, 05:32

If anybody knows where i could buy / get a copy of WinDVD HD, that would be great.

Thanks.

Warren

11th January 2007, 05:37

Instructions on how to buy WinDVD 8 HD from intervideo.co.jp are here:
http://www.avsforum.com/avs-vb/showthread.php?p=8871286&&#post8871286

Janvitos

11th January 2007, 05:49

Thanks Warren,

I just bought WinDVD 8 HD (Jap) and am downloading right now.
I will update you with results (if any).

I will also put it up for download on torrentspy for those interested.
I will post the link when i have.

This might speed up things a bit :)

CowBell

11th January 2007, 07:12

1. Players each have an individual key.
Revoking one player's key means no consequences for everyone else, but if many are cracked, the 1MB revocation table on HD-DVD discs will fill up rapidly.

Losers: AACS LA
Winners: Consumers, crackers (when table is full).

2. Each brand/version of a player has only a single key.
Revoking this key means a large number of people will be very angry, file lawsuits, etc.

Losers: large number of player-buying consumers, definitely software publisher.
Winners: AACS LA

3. Groups of 50-1000 players each have a unique key.
Revoking this key means significant groups of people will be very angry, file lawsuits, etc.

Losers: medium-sized blocks of player-buying consumers, possibly software publisher.
Winners: AACS LA

Isn't it in the AACS specs that the AACS Specs will only take the most current version of the MKB (Media Key Block) File? As soon as HD-DVD burners come out doesn't this mean that we might be-able to create a MKB File that has a Max Version number of the MKB file and make the contents of that file Invalid but Valid. If that doesn't make sense what I mean is to create a MKB file that has a MAX Version number while containing only one players/host key or even an invalid file all together. This would thus create a hard coded file on the drive itself that wouldn't accept any other MKB file since it already has the highest version.

I can see it now really....any .ISO or some other version that is labeled "HDDVDUnlock.*"

I hope that someone is able to test this theory out in due time and minimal cost (Emulate and burn minimal time please! Save yourself the $$$$)

Janvitos

11th January 2007, 07:31

Unfortunately i can't post the link but you can easily find it on mininova.
Hint: Do a search for "windvd hd"

Make sure you install it in "HD" mode and that you run WinDVD HD when you want to watch an HD-DVD movie.
(You will have 2 folders, WinDVD and WinDVD HD)

Also, if the program freezes on startup, try starting it by loading any movie file on your computer and then switching to the HD-DVD movie source.

Let's hope this gets us to the long awaited keys.

Btw, WinDVD is much nicer / quicker than PowerDVD with HD-DVD playback.

calinb

11th January 2007, 10:32

I just bought WinDVD 8 HD (Jap) and am downloading right now.
I will update you with results (if any).How did you get past the "Your machine is not configured for Japanese. Please download the English (US) version of WinDVD" popup from the Japanese version installer?

Update: I found a guide. http://greggman.com/japan/xp-ime/xp-ime.htm

Not sure if it works yet.

cyber1

11th January 2007, 10:43

I can confirm it has been done....only a matter of time before it spreads.

Nice, wonder what the people who called Muslix64 "a moron" is thinking now...

As a programmer I never doubted Muslix64 claims, since the key always (at some point) will reside in memory, in every software player, otherwise it will not be able to play HD-DVD files at all.

Warren

11th January 2007, 10:54

calinb, the Japanese WinDVD HD 8 doesn't display that error - at least it didn't for me and I don't even have the Japanese language pack installed.

calinb

11th January 2007, 11:21

calinb, the Japanese WinDVD HD 8 doesn't display that error - at least it didn't for me and I don't even have the Japanese language pack installed.
Weird! I downloaded WinDVD8.exe from www.intervideo.co.jp. It's 120,270 KB. Following the guide up to the point where you set Japanese for "Language for non-Unicode programs" allowed me to install it, however.

I should have followed the avsforum guide. I can't read kanji.

mixanobios

11th January 2007, 11:40

I have been reading this thread since it begining, and i would like to post my thoughts.

1) As i understand it, actual content on a AACS protected disc is encoded with ONE(1) key, or at most a handful of keys, correct? i could refrase that by saying that there is a AES-128 key that can decrypt content on each AACS protected disk. lets call that "final decryption key". i think that these are the title keys refered in muslix's FAQ.

2) if we manage to hack a drive firmware (if it is needed) and create a program that can read HDDVD or BD sector by sector, bypassing the whole AACS authentication process, then, provided we have title keys, we can decode any disk we want to, regardless of any revocation stuff correct?

So, all we need to completely break AACS is a list with title keys for every disk, a program that can extract HDDVD and BD sector by sector, read their structure and decode them using the title keys, and possibly a drive with hacked firmware if such procedure is not allowed by current firmwares.

The good thing about this is that title keys need only be extracted ONCE per batch of disks, and posted to a site.

Is my line of thinking correct? please comment

Related : http://www.freedom-to-tinker.com/?p=1106

jlobee

11th January 2007, 11:41

no errors here during install, or playback

hajj_3

11th January 2007, 12:17

I can confirm it has been done....only a matter of time before it spreads.

tell us how to do it or release the keys for movies that you own:)!

i can get them spread as a scene release in an nfo if you want.

feizex

11th January 2007, 13:20

This has been covered before, but here it is. One more time for the dummies...

Yes there is one key - the volume unique key. Use this to decode the title keys. There's more than one title (video) to a disc. There is one title key for each video. Use the title key to decode the matching video.

BTW, the videos are stored as encrypted files on the disc. There's no need to linearly read the each sector of the disc. All you need is the encrypted video file and the title key.

The AACS authority can revoke drives, hosts and content. Drive as in the physical optical drive. Host as in the software player on the PC. Content as in the HDDVD itself.

They can't revoke volume or title keys. But they can revoke what allows you to get them in the first place IE. drive, software player or disc.

All revocation info is stored on the HDDVD. This info is stamped with a version number. Before anything is played back the revocation lists are checked and updated from the info on the disc (if it has a later version). Copies of the latest revocation lists are stored on the HDDVD drive (in flash ram) and on your PC.

This means that if you insert a disc with info on it that revokes your drive or your player, it will not play anymore certified content (HDDVDs).

There doesn't appear to be anything in the specs to say under what circumstances they would revoke anything. Reality suggests that they would revoke anything which has been compromised.

As has been suggested before the most likely to happen is revocation of the software player because it is too easy to obtain decryption keys from. It has also been suggested that under these circumstances the software provider would produce an update for their product which is more secure. This would need to be recertified by AACS (new Host Certificate and Host ID). Once updated it could play HDDVDs again, but you may not be able to get your decryption keys.

Check out Figure 4-6 Drive Authentication Algorithm for AACS

Here is some more info that explain some of the Revocation process...
"the drive and the PC host verify each counterpart is not revoked by checking the Host
Revocation List (HRL) and the Drive Revocation List (DRL), respectively. To do this, the drive shall store the
most recent HRL it has encountered and the PC host shall store the most recent DRL it has encountered."

It gets revocation info (DRL and HRL) from the Media Key Block (MKB) on the disc. First it checks the DRL that the drive is not revoked. Then it checks the HRL that the Software player is not revoked.

The latest version of HRL is what is stored on the HDDVD drive in it's NVRAM.
"the drive reads an MKB recorded on the media to check if its version is higher than the version of HRL that it has stored in its non-volatile memory. If not, the drive determines to use the HRL in its non-volatile memory for the subsequent drive authentication procedure"

Content revocation...
"Certified Content may be revoked. When this occurs, corresponding revocation information is added to a Content Revocation List". "Licensed replicators shall include the most recent CRL on each pre-recorded medium that they produce".
In the AACS directory there is a file called CONTENT_REVOCATION_LIST.AACS

cyber1

11th January 2007, 14:11

Please dont go public which software-player you used to extract keys!

You can publish the volume key and the title keys, but never talk in public which player you used, because then its easy for them to revoke that players key.

hajj_3

11th January 2007, 14:28

you might aswell post which player it is, we all presume the xbox 360 as its the most common one. if they update the keys in future revisions we can just find the key for that!

cyber1

11th January 2007, 14:31

you might aswell post which player it is, we all presume the xbox 360 as its the most common one. if they update the keys in future revisions we can just find the key for that! :D
I'm talking about software-players!, you cant extract volume or title keys from an Xbox HD-DVD player, the decoding take place in the computer when using Xbox HD-DVD player.

DerKönig

11th January 2007, 15:09

Continuing CowBell's line of thought with what I understood from feizex's post:

Wouldnt it be, in theory, possible to create an HD-DVD image like the one Borbus created, with an MKB file that has empty DRL and HRL but a very high version number. Burn that image and play it in the HD-DVD drive (probably the XBOX drive as this is most popular). This would force the authentication process to be skipped in future as the system now thinks it has the highest versions of the DRL and HRL (but they are empty)???

@IsoChroma:

Since you are the one who contacted Eclipse... would the above idea need a license from the AACS LA (to create a "valid" HD-DVD image I mean)??

DerKönig

11th January 2007, 15:11

cyber1

11th January 2007, 16:37

BackupHDDVD requires either the Volume Key or Title Keys... is having a player key of any use??? I mean, if I had a player key, where is the encrypted Volume Key on the Disc? so that it can be decrypted using the Player Key...

You can read the specs at www.aacsla.com.
At this point the player key is not interesting.
Its only AACS LA that can create signed MKBs.

ilaps

11th January 2007, 16:39

read chapter 3 of AACS_spec_common_0.91: they describe the algo Kd (you call it player key) , MKB (you read it on the dvd)-->Km: media key ; there is an example in java!

then you go to AACS-spec_prerecorded_0.91 and in §3.3 you see how to compute from media key the volume key and title key

Have you got Kd keys?

evdberg

11th January 2007, 17:16

Syris2k4

11th January 2007, 18:45

Rather off topic, but I thought a nice thing to... share.

"Many media content owners believe web surfers should pay to watch their material, just like other audiences, and protect their files with digital rights management (DRM) constraints that prevent people making copies. A recent Treasury report on intellectual property concluded that this kind of protection actually encourages innovation and creates the next big thing that consumers seek."

Source : http://tinyurl.com/yxyoxq

Please could I have some DRM, ohh please? :)

And good job so far on the hunt, I'm enjoying the reading so far, wish I could join in. I do like the idea of re-writing the stored cache of banned keys - perhaps check with "the dangerous brothers" if they could look at a firmware hack?

neviens

11th January 2007, 22:26

Hi Neviens,

I have made a program which can log the input and output of any function in PowerDVD. I now used it to monitor the function you disassembled and commented in post #490 (http://forum.doom9.org/showthread.php?p=929376#post929376). These are the results of the 4 input parameters:
33d1e40 300a520 30061dc 2190
33d1e40 30125e8 7e002e4 2190
33d1e40 301b008 2fd72cc 2190
33d1e40 2ff4148 2fefe04 2190
33d1e40 7eeb1e0 2fc77c4 2190
33d1e40 2ff1b38 2fed7f4 2190
33d1e40 2fc51e0 2fed7f4 2190

Obviously the 1st 3 parameters are pointers, so I might log the memory to which they point. Is this of any use to you? Do you want to see other results or logs of different function calls?

P.S.: I can not play HD-DVD on my system, so these are the calls to the point that PowerDVD displays the error message that my system is not sufficient to play HD-DVD.

1. Unfortunately, it's useless to hook AES functions in program
that actually don't play a content. You see, there isn't any call
with fourth argument = 10h, but most (all ?) AES operations on
keys are exactly with 10h bytes of data.
We need to cooperate with somebody who can play a HD-DVD.

2. What data output from your program is necessary.
a) the key. Pointer to AES key is a 2nd argument of AES_KeyExpand(),
and key length allways is 10h (16 decimal).
b) input buffer (for operations with keys only). Pointer to
input buffer is a 2nd arg of AES_SwitchFunc*()
c) output buffer (for operations with keys only). Pointer to
output buffer is a 3rd arg of AES_SwitchFunc*()
length of buffers = 10h

If we want to begin with title key, then it's necessary to hook
the CBC decrypt function @100C34E8, I think. One call to this
function decrypts device keys file 001.fcl with hexadecimal key
00010203000102030001020300010203
One of two remaining calls must be content decyphering!
We need only 2nd arg of AES_KeyExpand(), the title key.
Oh, it's so difficult to live without debugger ):

Janvitos

11th January 2007, 22:52

Just a little comparison i made between PowerDVD and WinDVD,
i noticed the contents of the VTKF000.AACS file is there a few times in PowerDVD's memory,
but it isn't at all in WinDVD's memory. I'm not sure if this means anything, just a thought.

evdberg

11th January 2007, 23:20

I prepared below log earlier this evening. It is the 32 bytes of each of the 3 argument pointers before (Input) and after (Output) the function call. You can clearly see the key you mentioned in the 1st argument.

I will see tomorrow if I can log what you asked for ...
What do you mean with your last sentence? Don't you have a debugger?

Input:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00 GenuineIntel

43 2c e9 fe 25 1c a3 0f bb 80 27 e9 8b 19 8c c4
a4 d4 f4 91 ad c3 43 a2 8b db 29 52 d5 79 3f 07

34 33 32 63 65 39 66 65 32 35 31 63 61 33 30 66 432ce9fe251ca30f
62 62 38 30 32 37 65 39 38 62 31 39 38 63 63 34 bb8027e98b198cc4

Output:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

a0 e0 12 00 dc 03 2f 03 01 00 00 00 ac e0 12 00
5c 0f 2f 03 00 00 00 00 00 00 00 00 90 2d 00 03

46 43 4c 46 49 45 4c 44 78 4c f5 c3 63 97 a4 39
04 06 a4 9f 78 00 c7 7d e9 0c b3 4c 00 1d f3 6b

Input:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

43 2c e9 fe 25 1c a3 0f bb 80 27 e9 8b 19 8c c4
a4 d4 f4 91 ad c3 43 a2 8b db 29 52 d5 79 3f 07

34 33 32 63 65 39 66 65 32 35 31 63 61 33 30 66
62 62 38 30 32 37 65 39 38 62 31 39 38 63 63 34

Output:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

ac df 12 00 dc 03 2f 03 01 00 00 00 b8 df 12 00
5c 0f 2f 03 00 00 00 00 00 00 00 00 88 ee 00 03

46 43 4c 46 49 45 4c 44 78 4c f5 c3 63 97 a4 39
04 06 a4 9f 78 00 c7 7d e9 0c b3 4c 00 1d f3 6b

Input:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

43 2c e9 fe 25 1c a3 0f bb 80 27 e9 8b 19 8c c4
a4 d4 f4 91 ad c3 43 a2 8b db 29 52 d5 79 3f 07

34 33 32 63 65 39 66 65 32 35 31 63 61 33 30 66
62 62 38 30 32 37 65 39 38 62 31 39 38 63 63 34

Output:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

60 db 12 00 dc 03 2f 03 01 00 00 00 6c db 12 00
5c 0f 2f 03 00 00 00 00 00 00 00 00 90 2d 00 03

46 43 4c 46 49 45 4c 44 78 4c f5 c3 63 97 a4 39
04 06 a4 9f 78 00 c7 7d e9 0c b3 4c 00 1d f3 6b

Input:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

43 2c e9 fe 25 1c a3 0f bb 80 27 e9 8b 19 8c c4
a4 d4 f4 91 ad c3 43 a2 8b db 29 52 d5 79 3f 07

34 33 32 63 65 39 66 65 32 35 31 63 61 33 30 66
62 62 38 30 32 37 65 39 38 62 31 39 38 63 63 34

Output:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

6c da 12 00 dc 03 2f 03 01 00 00 00 78 da 12 00
5c 0f 2f 03 00 00 00 00 00 00 00 00 70 d9 00 03

46 43 4c 46 49 45 4c 44 78 4c f5 c3 63 97 a4 39
04 06 a4 9f 78 00 c7 7d e9 0c b3 4c 00 1d f3 6b

Input:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

43 2c e9 fe 25 1c a3 0f bb 80 27 e9 8b 19 8c c4
a4 d4 f4 91 ad c3 43 a2 8b db 29 52 d5 79 3f 07

34 33 32 63 65 39 66 65 32 35 31 63 61 33 30 66
62 62 38 30 32 37 65 39 38 62 31 39 38 63 63 34

Output:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

a0 db 12 00 dc 03 2f 03 01 00 00 00 ac db 12 00
5c 0f 2f 03 00 00 00 00 00 00 00 00 90 2d 00 03

46 43 4c 46 49 45 4c 44 78 4c f5 c3 63 97 a4 39
04 06 a4 9f 78 00 c7 7d e9 0c b3 4c 00 1d f3 6b

Input:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

43 2c e9 fe 25 1c a3 0f bb 80 27 e9 8b 19 8c c4
a4 d4 f4 91 ad c3 43 a2 8b db 29 52 d5 79 3f 07

34 33 32 63 65 39 66 65 32 35 31 63 61 33 30 66
62 62 38 30 32 37 65 39 38 62 31 39 38 63 63 34

Output:
00 01 02 03 00 01 02 03 00 01 02 03 00 01 02 03
47 65 6e 75 69 6e 65 49 6e 74 65 6c 00 00 00 00

ac da 12 00 dc 03 2f 03 01 00 00 00 b8 da 12 00
5c 0f 2f 03 00 00 00 00 00 00 00 00 e8 2f 00 08

46 43 4c 46 49 45 4c 44 78 4c f5 c3 63 97 a4 39
04 06 a4 9f 78 00 c7 7d e9 0c b3 4c 00 1d f3 6b

muslix64

12th January 2007, 02:40

There is a problem with the playback of movies having the
"In movie experience" (IME) feature. This is not a BackupHDDVD problem but a PowerDVD problem

PowerDVD cannot play decrypted content having the extra streams required for the IME feature.
It simply Crash...

In order to play the content, you have to remove these extra streams. I have identify:

Audio substream 0xc8 and video substream 0xd3
I manage to get smooth audio playback, but not smooth video playback so far...

If you want to experiment with BackupHDDVD, make sure your movie don't have the IME feature.

or just use one of the movies I have listed I my first post.

I hope we will have an open source player to play decrypted evob file soon. (VideoLan!)

muslix64

12th January 2007, 02:45

muslix64

12th January 2007, 02:51

Anyone have the BD+ SPDC virtual machine specifications?
This one will be a real challenge...

Warren

12th January 2007, 03:13

Hrm which known plaintext attack are you referring to muslix? What information do we have that when encrypted could lead us to the key?

muslix64

12th January 2007, 03:25

Warren...

Do you know what is the structure of an encrypted PACK?
Take a look at that first and think about it.
If I have figure it out, anyone can...

DanITman

12th January 2007, 03:42

Welcome back muslix I hope you vacation went well :)

noclip

12th January 2007, 03:53

Do you know about "known-plaintext attack"?
It takes only few seconds to my keyfinder tool to locate the key in the memory dump file using the known-plaintext attack.

You don't have to mess with tracing/debugging the code. Just dump the memory...

All the AACS constants appear at least half a dozen times in memory.

On a different note, are the keys padded with 00 00 00?

Are you talking about taking a some data from an unencrypted EVOB that is constant for all EVOBs and bruteforcing memory for a key that yields a result which contains that data?

muslix64

12th January 2007, 04:23

Yes my vacation went well, thanks DanITMan.
Ok, let's call it "guessed-plaintext attack" if you want.
Get it?
Take a look at actual packs in the stream. Anything special?

noclip

12th January 2007, 04:41

Take a look at actual packs in the stream. Anything special?
The packs in the encrypted EVOBs on the HD-DVD? The packs of the unencrypted EVOB as it's decrypted for playback?

Is the known (guessed) data in the unencrypted portion of each pack?

Edit: Also, could you please come to the #doom9 channel on efnet?

Janvitos

12th January 2007, 05:33

Muslix64, without disrespect, i would like to know why you are giving us everything but precise information and how you believe this might help us out in the long run.

I am no assembly programmer myself, and have been following this thread since the beginning, but have found little if no help with the "clues" you have been providing. In my understanding, you are trying to make a riddle out of this, which is, in my opinion, throwing people on different tracks and not necessarily "helping" out.

If you are trying to help with good intentions though, then i am simply not "wise" enough to connect with your clues or sayings. Memory locations, constants and key locations are what everybody is seeking here. I think many have been working really hard on this, but it seems to be going round and round for most.

Furthermore, i do appreciate the work you have put in writing the code for BackupHDDVD and it will surely serve a purpose some day when we hopefully, and finally, get our hands on the keys.

feizex

12th January 2007, 06:34

Uh... Plausible deniability.

As for the known plaintext, perhaps some header info? "The HD DVD-Video format is licensed by the DVD Forum, which publishes the HD DVD-Video Specifications." I haven't found that yet. Anyone want to post a link?

Besides that, the same aproach could be used to find the volume key once you have the title key.

jackchen

12th January 2007, 06:57

well, in the view point of reverse engineering or cracking, the clue given by Muslix64 is quite enough even though he never point out which software and where exactly to find the keys. but this shall be enough for those who are experienced in the cracking field.
we have different software players, each player have multiple executeable files, DLLs, filters, and each of these files might be encrypted to prevent reverse engineering. so it will take some time to find out which file contents the code which uses the title key to decrypt the contents on disk, and then it will take more time to search the memory space for the key. it's only a matter of time.
for sure that if he could give us more clue than we can certainly shortern this trial and error iteration time. But that's his freedom. None of us has the right to push him showing off any unreveiled info.
I actually encountered similar situation when I was in the team announced the first success in cracking xbox360 DVD firmware to allow backup game disk being played. I can understand his situation.
If you are not familiar with software reverse engineering, here are some hints.
1. Try to understand your target with as many ways as possible.
Here our target is the HDDVD and AACS, so we shall gather and read the spec. of HDDVD and AACS.
2. Find feasible tools.
debugger which can trace the code in real time and access the memorys such as olly debugger, softIce, etc.
disassembler which can give you the asm source code of certain program. IDA Pro is the best choice.
Other tools such as PE tools which can dump the code and memory space of program/DLLs running in OS. this might help when the code was encrypted and the disassembler is not working.
Sometimes you have to program your own tool. Like Muslix's key finder, that can help him search the keys in the memory dump.

well, looks like easy, but it was never a easy thing. So if you are interested in this cracking thing, than you can start to joing the game. If you're not willing to learn these stuff, than you can sit tight and watch the show. Maybe soon there will be someone releasing a tool which can help you grab the keys in realtime which the players is running.

Just one more thing. Since we can copy the encrypted content from the HDDVD disks to HDD directly, than the only thing stopping us from using the software player to play it is the AACS restriction which was coded in the software player. If we can find this code and change it, then the software player can still play the encrypted content directly since it has all the keys necessary for the play back. In that case, we no longer need to decrypt the content, just use the cracked software player than we play anything we want. too bad I don't have HDDVD drive and disks here. I am more interested in this cracking way.

neviens

12th January 2007, 09:10

1. Try to understand...
2. Find feasible tools...

You forget 3rd. HD-DVD drive, and at least one disc is necessary.
It's (near) impossible to reverse nonworking code. Authopsy
(deadlisting) is not enough, vivisection (live debugging) is
the king of reverse engineering.
And it is not a mess! It's a matter of hours not days to find
a code and data (including AACS specs reading :) in this way.

evdberg

12th January 2007, 09:47

Do you know about "known-plaintext attack"?
Ofcourse ... as long as you know both the encrypted data and the decrypted data you can try out keys, in this case from a memory dump, quite fast. I guess you refer to the weakness of the way video data is encoded in the stream, which is also exploited by VobDec? The last pack is padded with a padding block, so you know how this has to look after decryption ... this way you can verify the title key ... and once you know a title key you can use the same method to verify the volume unique key ...

Personally I wanted to make a method that just grabs the volume unique key when a title key is being decrypted, which I find a more elegant way ... although slightly more work to figure out ... :)

generalnewbie

12th January 2007, 10:21

hmm when i was thinking all hope was lost and no progress would be given.. the man thats caused all this ruckus is back. For anyone curious as to what he ment by Know plaintext attack or referred to guessed attack the analogy best states it:Encrypted file archives such as ZIP are also very prone to this attack. For example, an attacker with an encrypted ZIP file needs only one unencrypted file from the archive which forms the "known-plaintext". Then using some publicly available software they can instantly calculate the key required to decrypt the entire archive

jackchen

12th January 2007, 10:27

You forget 3rd. HD-DVD drive, and at least one disc is necessary.
It's (near) impossible to reverse nonworking code. Authopsy
(deadlisting) is not enough, vivisection (live debugging) is
the king of reverse engineering.
And it is not a mess! It's a matter of hours not days to find
a code and data (including AACS specs reading :) in this way.

haa.. you're right, I missed the most important part.
if the drive and disks are popolar, then we might already have lots of keys floating around the P2P sites.

btw, anyone with the HDDVD drive and powerDVD can verify that whether the PowerDVD can play the EVO files directly from the HDDVD disk? I am now trying to go with different way, that is to crack the software players to play the encrypted contents from none-HDDVD medias. any comments or inputs?

Bystander

12th January 2007, 13:18

You're talking about a lot of trial and error to find keys by dumping memory. PowerDVD removes the code as it goes along.

There are no less than 1,911 calls to: CALL <JMP.&MSVCR71.??3@YAXPAX@Z> to remove code from memory to cover its steps.

This leads me to think HD DVD japan version was used. Unless there is another HD DVD player out there?

arturner

12th January 2007, 14:02

Hey Everyone,

I've been following this thread for about 3 weeks now and thought I'd some up my own thoughts on the matter.

First of all it seems 100% plausible to me that the keys are dumped from memory, seeing as the "host" (as defined in AACS LA specs) has to construct the Volume Unique Key (based on Volume ID cipher...) to decrypt the Title keys, which are in turn used to decrypt the content.

(BTW I'm neither a programmer, cracker, or anything, just someone that likes to read specs, solve puzzles and think)

Now, in muslix64's last posts he refers to the known plain text (or GUESSED plain text) method to get the keys form a memory dump.

Now let's think about this for a second:

If you do AES 128 encyption of some plain text, you have (forgive me for not using EXACT numbers) say X^Y (X and X are VERY large) possibilities for the key, which you could only crack by brute force (and will take forever).

Now what about known plaintext (I nicked this example off the internet btw):

Say I want to send some highly confidentiel info (in XLS format) to a colleague. I encypt it and send it, but someone intercepts (who knows me, i.e. coporate spy. He/She can then start a known-plaintext attack based on:

*XLS header (constant and known)
*Words like dollar, total, subtotal, revenue

Other things you either KNOW or GUESS. The more you really know the smaller you can make X^Y, say you reduce it to 2^20

Well thenj you're only looking at a million key possibilities. Run these through your memory dump (at the appropriate time, although this seems to be a snag where PowerDVD is concerned if it hides it's tracks) matching say, partial or whole pattern and if your key is in memory, you'll find exactly the key. Might take a little time but still relatively quiick :)

So, this brings us to what plaintext do we know (or guess??), well I haven't done any research on the actual video content on HD-DVD, but I presume it's either MPEG 2 HD or H.264 (MPEG 4 part 10) which both have pretty standard header descriptors :) On the either hand you have the padding that was talked about earlier, should be standard. Maybe by reading the specs you can find more info on 'guessed' plaintext content.

I'll do some research later and also see if I can find a publicly avilable tool for doing AES known-plaintext attacks (as I can't program Java for ***) LOL :)

Hope I was of some help, I'll get back to this thread later!

DerKönig

12th January 2007, 14:14

We know the ciphertext (encrypted EVO)... We can get the plaintext i.e. decrypted video stream (or can we?? Im not sure... but if we can) then a known-plaintext attack is possible...

Also, regarding evdberg's post:

Do we know or is it possible to know the padding for the last block???

evdberg

12th January 2007, 14:48

Do we know or is it possible to know the padding for the last block???

We just know. The 1st 128 bytes of each pack is never encrypted and the pack header is thus readable, so we know how much video data is in the block. A fully used video block is 0x7ec (the packheader is 14 bytes, the video header + size is 6, totally 20 bytes), so if it is less we know that after the video block there will be a padding block. We also know exactly the size and start offset in the pack. The padding will look like this:

00 00 01 BF XX XX FF FF FF ..

XX XX is the size of the padding block (which is 0x7ec - <size of video block> - 6). If we have a memory dump of PowerDVD or WinDVD while it is playing a disk, we can try every 16 continuous bytes at long word offsets as key. This is most likely the way muslix64 did it. He only forgot to include his key checking prog to the distribution ...

hoihoi

12th January 2007, 14:54

i really am surprised that nobody posted a device key yet, because
a) there aren't that many (software) players out yet -> they will probably release a new MKB for future DVDs
b) there is no secret "voodoo-magic-yadayada-stealth" way to hide those device keys, ever. all you can do about it is make them harder to find; which might take 20-30 mins longer, at most. thats just how computers work. the registers have to point to the memory location(s) of the key at some point or another.

so i guess there are just not that many people, who have the equipment, interested in finding a key, and even less who want to brag about it / post a key.

muslix has given so many hints on how to find the keys.
so if you don't know how to interactivly debug or trace the key in the memory, one could as well just brute force the MKB using a memory dump of a player as possible device key list. should not take that long either.

evdberg

12th January 2007, 15:14

Fixed my playback problem! PowerDVD does not want to play on my iMac (has problems with my video driver), but WinDVD works perfectly fine and without any complaint!

hajj_3

12th January 2007, 17:55

muslix64, is it possible to create a program to find the key if you know where it is located? are the keys located at the same place each time.

give us some more clues please!:)

evdberg

12th January 2007, 18:04

hajj_3, did you read my posts?? You should have enough clues by now ...

hajj_3

12th January 2007, 18:18

hajj_3, did you read my posts?? You should have enough clues by now ...

get re-writing muslix64's program to scan for the keys then and release it anonymously in the wild.

an automated way is the only way this will be successful as only a handful of people would be able to rip their hd-dvd's. a gui program that did everything for you would be used by millions of people.

cyber1

12th January 2007, 18:35

I may be oldschool, but I think that many of todays young people want everything "served on a plate".... :o

Personally I think muslix64 gave too many clues.:cool:

The_ByteMaster

12th January 2007, 18:38

get re-writing muslix64's program to scan for the keys then and release it anonymously in the wild.

Let's first just see one working title key or volume unique key in the wild...

Jerky_san

12th January 2007, 19:00

I may be oldschool, but I think that many of todays young people want everything "served on a plate".... :o

Well if you look at it though the reason you must serve it to them on a plate. Is then you get the herd to adopt it. Once it spreads to the herd theres no stopping the stampede that will come after. If you don't make it easy like Xerox in the 70's thought that having a GUI is something that no one that used computers would want. Well look what happened.. we all have a GUI and it trampled everything else.

Onto other things like the subject at hand.. This basically sounds like when your a little kid and if you made a "secret code" but if someone knew 1 or 2 words in the letter you wrote then they could inturn find out what the other numbers and letters mean because persay A was 4 and B was 1 then you could assume that C would be something in the range of 2 or 4 and D 3 or 6.. Is this sorta what you all are talking about? Know a few characteristics in each block you'll know what every block is?

calinb

12th January 2007, 19:42

In that case, we no longer need to decrypt the content, just use the cracked software player than we play anything we want. too bad I don't have HDDVD drive and disks here. I am more interested in this cracking way.Yes, but please remember one of Muslix64's main motivations: playing his HD-DVD in full res over an unprotected (no HDCP) DVI interface. Apparently, his player provides this capability only with unencrypted files and media.

With the approach you suggest, a second hack to the player would also be required to permit this capability, in addition to the hack to merely enable the playing of copied encrypted files. Then there's the desire to transcode the video to formats that are compatible with other devices and operating systems. All in all, finding the keys is the most compelling endeavor, motivated by Fair Use and similar to the Hymn project for iTunes.

cyberpass

12th January 2007, 20:02

bob0r

12th January 2007, 20:10

@muslix64

Since you are now allowed to post keys, just do so.
And proof the people here wrong: http://www.hdnowonline.com/Comment_Who_Is_Muslix.html

If you dont dare posting keys, i am sure you can find a way to do this anonymous.

I myself hate fakers, and hope you are the real deal.

maksa

12th January 2007, 20:30

@bob0r
And proof the people here wrong: http://www.hdnowonline.com/Comment_Who_Is_Muslix.html

If you dont dare posting keys, i am sure you can find a way to do this anonymous

If you have followed, we'vew seen this paranoid article form someone from HD Camp. Of course that it is possible to find the keys. Simple cryptology (w/o knowing programming) principles will tell you that full obfuscation of the code is not possible and could be reverse engineered. AACS knows that and the task is only to make it labour extensive. That is what they did. Unfortunately they are operating with public algorithm, known length of the crypto word and known material to be scrambled.
That is what could help us to reduce number of trials to find a key. This approach is known from WWII as "crib" approach. We assume that parts of the plain text is known and present in scrambled message. We try combination of the keys till we get that text right and easily exclude all the wrong keys. Hashing is complicating things a bit, but I am sure that muslix64 is a smart guy (as all of hackers out there) and will (or allready has) find the way to get all the requred keys.

diogen

12th January 2007, 20:43

Finding the device keys are useless and a bad idea. If you do get the device keys, there is still way too much coding needed to calculate the title keys. They will just revoke the player for future use.

Finding the title keys is a good idea, even better if small brother doesnt find out which player was used. Let the player calculate the title key and steal it.It might not be as simple as that, based on Felten's series (http://www.freedom-to-tinker.com/).
...And proof the people here wrong...It would be nice to have one confirmed case of his methodology working. But doing this only because of that website?
Based on the owner's posts on AVS and on the very page you linked to, it doesn't deserve even being paid attention to, IMHO.

Diogen.

Isochroma

12th January 2007, 20:45

It seems to me that the best course of action is to find a place in the player code where the key is plaintext, and insert some code to dump it to a file from there. That way, no memory dumps are necessary.

Then, ZIDRAV (http://sourceforge.net/projects/zidrav/) can be used to produce a difference file, which can be used to patch everyone's player to do the same. Then we can all start publishing keys...

cyberpass

12th January 2007, 21:22

this better not end up like direct tv... A lot of hype at first on being cracked then nothing shows up, even till today!

Doom9

12th January 2007, 22:01

Guys... back to topic please. I'm not gonna say it again.

stormlord

12th January 2007, 22:30

Why is everybody assuming that the required information is stored in just one location? That would be making it much easier to break then if the key information is located in different locations. I'm not just talking player, database or disc in physical terms - but also why should all of the "key" be in for example just one location in memory, or one register - it could be a combination too. I have no cryptography experience of any kind nor any experience with breaking security on PCs. I do have experience with forms of protection on good old commodore 64 - and I can tell you this: a good protection does not do the obvious, it tempts to misguide you or even relocates or rewrites itself/encrypts itself - i.o.w. much like viral activity of the worst kind. Some protection can be broken by finding one key element (in general the easy ones, like jump to a certain protection routine). In other numerous parts and various types of protection will be scattered through the software, making it much more difficult to find everything. Probably the hardest thing to break if they would do the protection/deprotection through a special circuit in hardware (with write once unique key in every player, no reading possibility). I recall one of the harder protections on C64 made use of the soundchip (!) to generate a random value.

As for HD DVD or Bluray media: there will always be a way to break any form of protection, since it has to be able to be played. The matter is: how difficult do they make it and how easy/obvious is it. The challenge will be greater if they make it more difficult, and many people who try will give up because they lack the patience or the knowledge. There will always be people who have the ability to break it though, if they want.

<< START RANT >>

My largest problem with all of this is that there will be a lot of people who bought discs legitimately and they won't be able to play them with the best quality on each and every hardware due to various forms of UNWANTED copyprotection (DRM, AACS, HDCP, whatever...). When will the MPAA/RIAA finally get it that people do not WANT any of this, nor do they want to pay extra for them (because they definately ARE paying for them). Region coding is bull in this day and age (many movies are released almost simultaneously around the globe), and the industry should be aware of that the plubic thinks about it that way. Do they seriously think the player manufacturers and even dealers WANT all these problems with things like HDCP, region coding (customers nagging about it) etc... I can understand perfectly that the studios want to protect their rights as a copyright holder and want to make a profit on their products so that they can correctly & rightfully pay everybody involved in the production/distribution etc.., but there is such a thing as overpricing and scaring away the customers from buying these new products (that is how good new ideas and new techs fail). When multiple formats are being released, ultimately - there always will be losers -& in general it's the early adopting endusers/consumers (the ones who pay back all the R&D!!!) who end up with hardware or media they cannot use as they would have wanted. They get a beta product that only works half the way it should, they pay far the most and often end up with unusable quickly devaluating material. The industry should REWARD these people for being their guineaupigs!!! Instead they ROB them of any decent userexperience, much like they claim to being robbed by piracy year after year (yet with ever increasing profits... don't they realise there is a ceiling to that??)

If they want piracy out of the world (which they will never be able to do entirely anyway), they 'd be better off taking other measures:
1) lower the price of the media (album CDs often cost more than a full DVD out here - which are much more labourintensive to master, anybody care to explain how that is logical?) Lower price means: more people buy the original. If backing up a disc costs almost as much as the original one - why bother copying? They could start lowering the cost by skipping all kinds of unwanted forms of copyprotection, because all these schemes definately cost money to develop + they cost extra in terms of hardware and hardwareresources.
2) allow people to make a legit copy of their rightfully purchased media or provide cheap replacement themselves if a disc goes bad within a normal lifespan. Here in many European countries people already pay some form of copy tax on blank media any way, why don't they just make that the same for everybody everywhere + return part of the money to the people who really earn it (the artists, NOT the large publishing companies behind them - who rake up all the hard cash in a great many cases!) !!!
3) Persue first and foremost mass piracy through illegit reprints, i.o.w. people who make loads of profit out of piracy. People will always copy for family and friends, you will never get that out. That's a battle lost before it's even started. Hell, even the musicians/artist copy themselves. The ones that claim they don't are usually a bunch of hypocrits or flat-out liars! IMHO, the better way would be to convince people to BUY the product if they think it is WORTH the money!

Nobody wants protected original media that does not play the way it should in EVERY player...

If the industry still doesn't realise people want players that play EVERYTHING: Blu Ray, HD DVD, DVD and CD alike -AND- do not have crap like region coding, HDCP etc.. that prevents them from playing back media they purchased legitimately.

When I buy discs at e.g. amazon.com in the USA and I live in Europe and I PAY for them and I PAY taxes for them - I want to be able to play them everywhere! Why buy them in the USA: there hardly are any titles in Europe available, let alone good ones!!!
(note that to my knowledgde NONE of the blu ray titles listed on Amazon indicates which region they belong to or if they have region coding enabled)
That's doesn't mean I want to fork out the schandalous amount of money for 2 players (let alone 4 if no one makes a hybrid Blu-ray/HD-DVD player) if I want to be able to play discs from the USA and Europe!
Hell, these players do not cost the chinese that much to produce at all (not nearly as much as they are being sold at anyway) - early adopters pay all the R&D + the volumes are just too low.
They should give early adopters a reduction voucher for next generation product as a reward for BETATESTING their early release crap!!!

As for the HD-DVD vs Blu Ray battle, it's all politics that in the end consumers are not served by.
HD DVD's wider acceptance in the USA may have to do with better title releases and better mastering of the specific titles.
Here in Europe neither HD-DVD, nor blu ray have broken through (I guess it hasn't anywhere, but even far less here than in the USA) - and I'd say HD DVD even less!(less players/drives for PC, less titles, less brand recognition!)
Personally, all I care about is that in the end we get good versatile & quality product that works properly and can be played without too much of a hassle or harressment by all kinds of lame protection systems ultimately none of the buyers want.

Haven't they learned their lessons yet from audio cd protection then??? The buying consumers didn't want it there either!

I stress: I'm talking about BUYING customers, not pirates...

And even then: just about everybody has a VCR, dont't they? ALSO the RIAA/MPAA execs? Right: they pirate too! TV shows and movies shown on TV are also copyrighted!
It's the same bunch of hypocrits all over: they release/sell MP3/DIVX players, they release/SELL VCRs, they release/SELL blank media for them, they release HDD recorders?

But hardly anybody can record or use them legitimately? Who are they kidding?

Aren't they making enough money yet by selling both the hardware and the software??? Oh, they would love us to pay for each time we play the media too I suppose?

<< END RANT >>

Mikey10

12th January 2007, 23:58

Well, known-plaintext attack worked really well for DeCSS ...

... but ...

wouldn't it be to abasing for the MPAA, if this same lousy method would break these creepy-billion-dollar-concept AACS also?

by the way - muslix ...
... why had the Teaser_1.evo in your really awful^^ YouTube video just a filesize of 4,02 GB?

Mine has 9,2 gig; the 14,4 gig Teaser_2.evo was missing completely ...

LordSloth

13th January 2007, 00:26

Finally I can post!

I wanted to post this over the weekend but had to wait :mad:

Anyway, I can also confirm that BackupHDDVD properly decrypts EVOs when given the correct Title Keys.

I followed this posting http://pastebin.com/853659 for finding one for a movie. And after the lengthy search, interpret, and hex conversion the key actually worked in BackupHDDVD.

~Cheers

He-Man

13th January 2007, 00:48

I followed this posting http://pastebin.com/853659 for finding one for a movie.
??? Are you sure you gave the right link?

This is the only text I get if I follow your link, it doesn't seem to have any relation HD-DVD encryption:
2/Reavers are bad mmmmkay...Google 4TW!

Mark Twain Intermediate School
Restaurant & Lounge
Cent
Celtic Designs Dover Pictorial
Science Online Special Feature
Link Building Strategies
Starlifter
Solar periodicity
Dawson's Creek Music Guide Decisions
Duncan's F
ways to market your small or solo business
WBFF
Olivia Quinn Food Stamp Leaver
Dalmations
CITI FM
Skippyslist

Janvitos

13th January 2007, 00:52

I think some people are messing around with us.
I followed that link too and get nothing relevant.

Please ban the ignorants.

LordSloth

13th January 2007, 01:05

??? Are you sure you gave the right link?

This is the only text I get if I follow your link, it doesn't seem to have any relation HD-DVD encryption:

Yes the link is correct. It's a scavenger hunt of some sort! And since I had to go through the trouble of following it myself, I'm not going to post the answer directly.

I mean what fun would that be? :)

Don't get me wrong, I don't take some sick pleasure in making others follow the same path I did. But it did seem the safest way to share the information. Which is probably why the original poster put it in this format.

blutach

13th January 2007, 01:21

@stormlord - you have just registered 5 days ago and had time to read the rules. This thread is not a place for your rants. Many times, Doom9 and I have asked posters to stay on topic. Strike issued.

@Mikey10 - same comments regarding rules. How does yourt post add to the topic? Strike issued.

Regarding LordSloth's link: I can not get it to load at all. I am loath to issue strikes until I can determine the content for myself. But you are way off topic in your previous post. Strike issued.

Regards

setarip_old

13th January 2007, 01:26

LordSloth

13th January 2007, 01:29

@LordSloth

As an outside observer, having absolutely no involvement in the activity being pursued in this thread (Although I'm certainly interested in its eventual outcome), I must say it's disconcerting to see you trying to make a "game" out of the loosely cooperative effort the other posters to this thread.

I'd suggest that if you have discovered a legitimate, meaningful "piece of the puzzle", you should simply present it here - so that others can advance their combined efforts...

I am just passing on the link that I found and indicated that I went through the trouble of following it, that others could too without much difficulty.

That and the result of following that link is a Title Key for the movie hinted at in the top. Posting the answer directly didn't seem wise.

setarip_old

13th January 2007, 01:32

@Janvitos

I'd speculate you'd have to convert those to hex...

Janvitos

13th January 2007, 01:38

For the ones interested:

239 -> EF
33 -> 21
50 -> 32
159 -> 9F
125 -> 7D
131 -> 83
141 -> 8D
154 -> 9A
112 -> 70
86 -> 56
136 -> 88
45 -> 2D
191 -> BF
102 -> 66
92 -> 5C
213 -> D5

What movie is this a key for ?

blutach

13th January 2007, 01:38

Gentlemen - enough of this!

LordSloth - either post your results or do not post at all. Last Warning.

Everybody - there will be no more warnings issued. Posts which can not stay on topic, or do not directly address the issue of decrypting HD-DVD will be struck. These include rants, taunts, accusations, publication of off topic links (including about muslix64's identity), irrelevant numbers which can not possibly be seen as keys and anything else that is not relevant or does not further this discussion.

Please read the above carefully.

Regards

LordSloth

13th January 2007, 01:42

For the ones interested:

...

What movie is this a key for ?

Serenity

It took me awhile to figure that out from the Reavers comment at the top...

Hope you have a copy.

It's the 2nd Title Key

cyber1

13th January 2007, 01:42

He-Man

13th January 2007, 01:43

@Janvitos

I'd speculate you'd have to convert those to hex...
Google each of the 16 lines in the text. The first Google hit you get for each text line contains a 2 or 3 digit number in the title.
These decimal numbers probably have to be converted to hex and you get a 64 bit number.

He-Man

13th January 2007, 01:49

deleted

He-Man

13th January 2007, 01:54

Regarding LordSloth's link: I can not get it to load at all. I am loath to issue strikes until I can determine the content for myself.
I couldn't get the link working the first time either, but hitting the refresh button a couple of times made the site load.
The only contents of the link is the text I quoted above, which are suppoed to be used in Google to find decimal numbers.

Janvitos

13th January 2007, 02:06

I just got my hands on the movie Serenity from a friends, i will update you with results (if any).

luders

13th January 2007, 02:09

I have Serenity... Trying to figure out how to try it. If anyone wants to help with the .cfg file setup I should be using, hit me.

Janvitos

13th January 2007, 02:18

I can confirm the following value "EF21329F7D838D9A7056882DBF665CD5" to be in WinDVD memory after playback of the movie "Serenity".

Will continue to research this and update you with results.

luders

13th January 2007, 02:24

So this so far.....

0000000000000000000000000000000000000000=Serenity |T|MM/DD/YY|2-EF21329F7D838D9A7056882DBF665CD5

Janvitos

13th January 2007, 02:27

Luders, replace the 0s with the SHA1 of the VTKF000.AACS file, which is "C8A57242AF4CB5C0D7848BDA10821F984DC656E0"

He-Man

13th January 2007, 02:32

I can confirm the following value "EF21329F7D838D9A7056882DBF665CD5" to be in WinDVD memory after playback of the movie "Serenity".

Will continue to research this and update you with results.
If the above is the complete title key #2, then you only need to calculate the SHA1 hash value to put into the field 1 of TKDB.cfg file

[QUOTE]Field 1: SHA1 Hash of the VTKF000.AACS file on your HDDVD disk.

Next fields are pipe "|" delimited.

-Movie Title
-A variable number of Title key, pipe delimited

You have a key number followed by the key value like:

12-08A3DC61910280F2...

Key values are 128 bits long, so 16 bytes, or 32 hexadecimal characters long..[QUOTE]

Janvitos

13th January 2007, 02:39

He-Man, how do you know this is key #2 ?

luders

13th January 2007, 02:42

Hmmm I get a java error because I am using JRE 6 in vista. Might have to boot into xp to try this.

He-Man

13th January 2007, 02:44

He-Man, how do you know this is key #2 ?
Because that's what LordSloth wrote in a previous post:
Serenity

It took me awhile to figure that out from the Reavers comment at the top...

Hope you have a copy.

Its the 2nd Title Key

LordSloth

13th January 2007, 02:46

Now after I followed that crypted scavenger hunt and got the 2nd TK, I searched for the key in WinDVD's memory...and guess what I found...

The entire Title Key table decrypted!!!!

That's right....the next 16 bytes after the 2nd key is the 3rd key and so on...

Enjoy!

He-Man

13th January 2007, 02:48

So this so far.....

0000000000000000000000000000000000000000=Serenity |T|MM/DD/YY|2-EF21329F7D838D9A7056882DBF665CD5
Why do you have the MM/DD/YY filed in there?

I don't see this in the original TKDB.cfg file, only 4 fields:
1: hash value
2: title
3: title key number
4: title key in hex (128 bit)

He-Man

13th January 2007, 02:51

Why do you have the MM/DD/YY filed in there?

I don't see this in the original TKDB.cfg file, only 4 fields:
1: hash value
2: title
3: title key number
4: title key in hex (128 bit)

That's the new structure in hdvdbackup 1.00 posted Jan 02

luders

13th January 2007, 02:52

You must be using the first version of BackupHDDVD. The new one has the date field though it is ignored by the program.

Janvitos

13th January 2007, 02:54

Alright, this is good news.
The key "EF21329F7D838D9A7056882DBF665CD5" is the 2nd key which decrypts the file UNILOGO.EVO from the movie Serenity. This is *CONFIRMED* and *WORKING*.

Here are all the keys for Serenity:

1-31325529846E19E90D88F414DA7D1661
2-EF21329F7D838D9A7056882DBF665CD5
3-46BE356597AD71BFFADEDA14FE335B64
4-8906E3E8B05EEC17E594E98D42C913FE
5-0F998F1C0C7FEB30381C01F135FBE8E9
6-97895F12C018845C9CDCE95DFF4101DF
7-6C005DA9DAA97E168129753319D748A1
8-0608D2628A9FE952398B0FB432BDB6B1
9-A24471CC766C6E7F7F56DB560CCD31E5
10-6EC977757A9E8AC378CC680770874E33
11-55962EA8084BF5135CB2ED5A5E795233

Here are the keys for KingKong:

1-7D743D3C92652CC16B66D9CB87F6D132
2-70B71C6E767E213AEB7456985BAAD8A4
3-4BC362995030035312A5B6030D76C817
4-A019B5101E904A700A44F056B7EB3579
5-896AB02D3D77554EABCE3CCE931DA39D
6-BEC07637E9C4EFA1F70FED6891DB277B
7-1DC0D276F2C5B9FCFDE1414C5002BAAB
8-BC7EB577D1936818AEB9241F024DE681

To find these keys, my best advice would be to search your memory for "VPLST000.XPL" and they will be near one of the instances of it.

Now we have to find the volume keys for a lot less trouble.

Jerky_san

13th January 2007, 02:56

Yes won't we need the first version of the decryption to use a title key? Since the newest is for volumes? And I must say very good work on finding the key.. If the table has been reveled surely the volume key is with it..

LordSloth

13th January 2007, 02:57

Volume Unique keys are located

+0x13C0 after the 2nd title key location

:D

Janvitos

13th January 2007, 02:59

LordSoth i dont have the same addresses, can you tell me exactly where the volume unique key is ?

LordSloth

13th January 2007, 03:00

So to recap...

Search for VPLST000.XPL in WinDVD's memory (4th occurrence) and from that offset.

+0x0181 is the Decrypted TK table
+0x1571 is the Volume Unique Key

Granted these may vary from system to system and disc to disc.

I believe the offsets vary from movie to movie and computer to computer.

Looks like Janvitos confirmed they do since they don't match what I posted. But just look somewhere around that region and you should be able to locate the TK table and the VUK.

Jerky_san

13th January 2007, 03:00

LOL! holy crap the keys are flying.. are the volume keys in the same place every time? Or do they vary?

Janvitos

13th January 2007, 03:05

Serenity Volume Unique Key: D075568AE6BB0B3F85446927B3794C28

KingKong Volume Unique Key: 802F78B1B20D1183638D84E1A96D6EDD

12 Monkeys Volume Unique Key: 2662C05B5238B0C50BD1BDF693223712

Janvitos

13th January 2007, 03:08

I believe the offsets vary from movie to movie and computer to computer.

He-Man

13th January 2007, 03:13

And the keys stays in memory after a HD-DVD disc has been stopped again?

What tool do you use to get a memory dump?

He-Man

13th January 2007, 03:16

You must be using the first version of BackupHDDVD. The new one has the date field though it is ignored by the program.
Yes, I opened up version 0.99 by mistake.

Yes won't we need the first version of the decryption to use a title key? Since the newest is for volumes?
No, version 1.00 can be used with either title or volume keys, it's your choice, you just have to define which type you use in Field 3 in the KEYDB.cfg file:
Field 1: SHA1 Hash of the VTKF000.AACS file on your HDDVD disk.

Next fields are pipe "|" delimited.

Field 2: Movie Title
Field 3: Key type (V or T for Volume or Title key)
Field 4: File creation date
This field is informational only. It's ignored by the program. It should be the creation date of the media file on the
disk.

Field 5:A variable number of Title key, pipe delimited or one volume key

In the case of a title keys, you have a key number followed by the key value like:

12-08A3DC61910280F2...

Key values are 128 bits long, so 16 bytes, or 32 hexadecimal characters long.

Janvitos

13th January 2007, 03:16

I use WinHEX to edit the memory directly.

zeroprobe

13th January 2007, 03:22

some screenshots would be nice. Wish I had the addon would love to play about with this for myself.

Janvitos

13th January 2007, 03:26

I think posting the Volume Unique Keys speaks for itself :)

zeroprobe

13th January 2007, 03:30

So if the players key in question gets revoked. Would any of the keys now found be any use in future players for tracking more? or would a new players key get totally different results on the exploited discs?

oddball

13th January 2007, 03:46

To beat the system I'm guessing you would need a hacked firmware that stops the revocation process from happening. Newer titles will likely contain lists of revocated keys etc?

Someone please explain in laymens terms how the new system works. I never understood the technical docs.

Shinigami-Sama

13th January 2007, 03:48

So if the players key in question gets revoked. Would any of the keys now found be any use in future players for tracking morei? or would a new players key get totally different results on the exploited discs?

doesn't matter if the player keys get revoked because the volume Unique and Title keys are on the disk - player keys are used to tell if the player is allowed to use the vku or tk

and its great to see that it was as simple to find the keys as I though it would be. It just makes sense that it'd have to be in memory and work like every other digital system out there

Adub

13th January 2007, 04:03

Yes!! Excellent job guys! I will order a Xbox 360 drive myself now. Excellent work!

woah!

13th January 2007, 04:12

great news :)

how do you config the key file exactly tho, as i cant seem to get it to go... me stupid... do i need to still find out the date etc from the king kong disc?

oddball

13th January 2007, 04:13

From what I understand when newer discs come out they will require you to play them with newer more secured software. You won't be able to use the software with the exploits to playback newer titles. It will be a game of cat and mouse as people try to find the newer methods of where they hide the keys.

Jerky_san

13th January 2007, 04:17

I don't think thats on HD DVD.. unless the software people do it.. Blue Ray on the other hand is a whole different story all together.. But what your going to have to worry about on HD DVD is the revocation of the player key which forces you to get those new software updates..

oddball

13th January 2007, 04:19

Effectively the same thing. Newer titles will require upgrading to play. Otherwise you are stuck with your old titles.

calinb

13th January 2007, 04:25

doesn't matter if the player keys get revoked because the volume Unique and Title keys are on the disk - player keys are used to tell if the player is allowed to use the vku or tkOkay, congrats to those who have won round one and yes--the keys are on the disk, but they are encrypted keys on the disk. We still need an (unrevoked) player to decrypt new keys for us or even play old encrypted disks. If your player is revoked, it's end of round one; you won't even be able to play old titles! Here's why: Take a look at Fig. 4-1 of AACS_Spec_Common_0.91.pdf. 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.

The_ByteMaster

13th January 2007, 04:32

Effectively the same thing. Newer titles will require upgrading to play. Otherwise you are stuck with your old titles.

Unless the content gets revoked, the newer player will always have to determine the Volume Unique Key to decrypt the Title Keys. So unless your Serenity, King Kong and whatever else is compromised gets revoked, you *know* that at some point your new player will have to use that key. This will help to a large extent in compomising the new player (which will, in turn, compromise even more content). This is an avalanche that is hard to stop.

13th January 2007, 04:38

Yes!! Excellent job guys! I will order a Xbox 360 myself now. Excellent work!

No no!!! Don't order the 360... Just the Drive :)

Adub

13th January 2007, 04:53

Oh, right. Okay I mean the drive. And then Hi-def hear I come!

muslix64

13th January 2007, 04:58

Congratulations!
So now you see BackupHDDVD is not a fake...
Now we have to make movies with the IME feature playable with PowerDVD.

Then, ... BD+!

Adub

13th January 2007, 05:04

Thanks alot for the program Muslix64!
And I share your want for IME and ... BD=!
Excellent job everyone!

oddball

13th January 2007, 05:11

Remember guys. You read it here first. Another notch in the history of the digital copyright wars. ;)

woah!

13th January 2007, 05:21

well i was missing the SHA1 hash number and now king king is working on a non-HDCP vcard in powerdvd... amazing stuff guyz...

dont know how long this will work but hats off to all of you that know your stuff. i like video encoding but the heady stuff i know little about.

Testing source
Found valid HD-DVD source.
Look for this movie in my database
Found movie: KING KONG
Start backup on Fri Jan 12 20:00:13 PST 2007
Scaning video directory
Processing BLACK.EVO key = 3
Processing DELOGO.EVO key = 5
Processing MAINMENU.EVO key = 1
Processing MENULOOP.EVO key = 1
Processing SCREENSAVER.EVO key = 6
Processing UCONTROL.EVO key = 7
Processing UNILOGO.EVO key = 2
Processing FEATURE_1.EVO key = 4

oddball

13th January 2007, 05:25

Dammit guys it's 4:25am here and I don't want to go to bed this is so damned exciting! :)

moshmothma

13th January 2007, 05:29

Using what has been posted I am ripping Serenity. Is Powerdvd the only plahyback mechanism. There seems to be some directshow filters but not able to make them work in graphedit.

Please keep the keys coming (especially since I can't get Windvd to work ;(

Adub

13th January 2007, 05:31

Ha! Drink some coffee, take some artificial adrenaline, whatever you can do stay with us!

Okay, so what is the next step? Coding a program to do this automatically for us non-debugger smart people?

rbmcgee

13th January 2007, 05:35

In the war of HD-DVD vs Blu-Ray ... it looks like I'm going with HD-DVD.

Well done.

I agree, we need a program so that us technically challenged individuals can play as well.

oddball

13th January 2007, 05:43

Does anyone know how to get around the chain nav lag?

setarip_old

13th January 2007, 05:47

Again, as an outside observer, I'd like to congratulate those of you who have actively participated (and are still participating) in this remarkable accomplishment - and also in such a remarkably short period of time!

What is most impressive to me is how foreshortened the effort became once the teamwork truly started amongst you.

If I wore a hat, it would be off to all of you - Great Work ;>}

(Looking forward to the GUI and underlying program)

woah!

13th January 2007, 06:06

moshmothma

13th January 2007, 06:09

Could someone help me with playback? I noted none of the map files were moved over with backuphdvd. Is this normal? I just copied them from the hddvd but that does not seem right. Playback with Cyberlink yields a blank screen. Thanks

VistaVick

13th January 2007, 06:23

yes it would seem lag is a major issue now on the backed up EVOB's. the menu evob seems to play fine but the feature is terrible with spikes in the bitrate upto 300+ mbps :(

still we cant run before we can walk :)

Plays ok for me, a few glitches here and there, though I have a very fast cpu and graphics card.

However, I imagine these will be commonly converted to different formats that play more smoothly.

woah!

13th January 2007, 06:27

Plays ok for me, a few glitches here and there, though I have a very fast cpu and graphics card.

However, I imagine these will be commonly converted to different formats that play more smoothly.

i suppose my quadcore isnt fast enough :(

i have a X1800XT vcard bolted to it. it might be the sound thats the problem then maybe?

luders

13th January 2007, 06:28

Applying the following solution to my Vista and Java 6 setup fixed the problem with running BackupHDDVD incase anyone has the same error.

http://forum.java.sun.com/thread.jspa?threadID=5120332

hajj_3

13th January 2007, 06:30

maybe a program can be written to find these keys out as the average person wont be able to do this.

OR (if not technically possible)

create a detailed pdf guide with screenshots showing how to do this.

ALSO: get posting more movie's in here with there keys, create a list.
ALSO: if anyone get a hd-dvd writer test it by trying to burn a backup of the hd-dvd you just unencypted. imagine seeing that on youtube of a guy burning a hd-dvd and then playing it, how cool would that be!!!
ALSO: whens the next version of backuphddvd coming out??? maybe you could get the program to auto search for keys or atleast make a GUI for the current version.

do playback work on non-hdcp capable monitors, i know you said it works with non hdcp capable graphics cards, but what about monitors?

there are very few gpu's that support hdcp only 8800 series, some of 7600gt's, x1650 pro saphire i think.

there are only 2 gpu's that have hdmi out too, 1 7600gt and 1 x1650 by saphire. i hope to see alot more hdmi outputs and hdcp capable cards soon.

i think we should create a table with hd-dvd's that work with this program and those which dont!

woah!

13th January 2007, 06:49

well ulead moviefactory 5 can author TO hd-dvd format but cant READ from a EVO file? so it can make one but cant read one...

Shinigami-Sama

13th January 2007, 07:05

Okay, congrats to those who have won round one and yes--the keys are on the disk, but they are encrypted keys on the disk. We still need an (unrevoked) player to decrypt new keys for us or even play old encrypted disks. If your player is revoked, it's end of round one; you won't even be able to play old titles! Here's why: Take a look at Fig. 4-1 of AACS_Spec_Common_0.91.pdf. 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 was under the impression from the quick glance I had the chance to grab that the volume unique keys would work with any player
once we've gotten them we have them and no longer need the player Key

as for the drive, I'm sure there will be a flash dump made so you just reflash it after every 'update' to the revoke list

tonyp12

13th January 2007, 07:15

Adub

13th January 2007, 07:27

Yeah, I would just stick with the latest stock update form java, nothing fancy.

luders

13th January 2007, 07:38

Isochroma

13th January 2007, 07:56

Try this: HashCalc (http://www.slavasoft.com/hashcalc/index.htm)

tonyp12

13th January 2007, 07:57

What I'm missing from this?

0e75082678aad5cd4410a28a662d6832d21eb325=KING KONG |V|MM/DD/YY|802F78B1B20D1183638D84E1A96D6EDD

Adub

13th January 2007, 08:04

nothing. The date is not necessary. Or are you recieving and error?

alanisrox69

13th January 2007, 08:06

What I'm missing from this?

0e75082678aad5cd4410a28a662d6832d21eb325=KING KONG |V|MM/DD/YY|802F78B1B20D1183638D84E1A96D6EDD

I believe the hash is case sensitive...so

0E7.....

you can also change the date to 00/00/00

jokin

13th January 2007, 08:08

Ok, now that this is proven to work, could someone post a semi in-depth tutorial on what to do and what to look for.

Thanks

tonyp12

13th January 2007, 08:09

nothing. The date is not necessary. Or are you recieving and error?

"can not find in in my database, please update your key file"

luders

13th January 2007, 08:10

Yes that is because it has to be all caps as was said.

luders

13th January 2007, 09:07

You guys having any trouble with the decrypted King Kong feature evo's?
They dont play back for me in PowerDVD 6.5 HD but the Serenity evo's do.
This is what I have so far.
C8A57242AF4CB5C0D7848BDA10821F984DC656E0=Serenity |V|MM/DD/YY| D075568AE6BB0B3F85446927B3794C28
0E75082678AAD5CD4410A28A662D6832D21EB325=King Kong |V|MM/DD/YY| 802F78B1B20D1183638D84E1A96D6EDD
0000000000000000000000000000000000000000=12 Monkeys |V|MM/DD/YY| 2662C05B5238B0C50BD1BDF693223712

oddball

13th January 2007, 09:10

Not full res but you get the drift. BTW they disabled screencap in PowerDVD. Probably the same will apply to all players.

http://filexoom.com/public/pview/7856/3.png

oddball

13th January 2007, 09:11

[QUOTE=luders;933624]You guys having any trouble with the decrypted King Kong feature evo's?
They dont play back for me in PowerDVD 6.5 HD but the Serenity evo's do.[/quaote]

Which is probably why Muslix did not include it in his list of movies. I think some titles have some other stuff in them that might need to be overcome. Some extra level of crap.

luders

13th January 2007, 09:16

Oh sure.. I forgot, that whole ucontrol deal. Thanks.

luders

13th January 2007, 09:18

Anybody got keys for Batman Begins and Van Helsing so I can see if those suffer the same fate?

tonyp12

13th January 2007, 09:26

PowerDVD7.2 (@Horse+donkey) plays decrypted king kong.

But skips and stutters so bad it's not watchable.

I only have a Opteron 146 at 2.3ghz and it just barely can handle playing the movie back from the 360-drive.

What about creating a Daemon Image file so powerdvd actually thinks is playing from a disc?

Feature title 26.9 GB, that is huge!
I can not see that being transcoded down to 8.5gb (DL DVDR)
without loosing major quility.

evdberg

13th January 2007, 09:55

generalnewbie

13th January 2007, 10:19

Congratulations!
So now you see BackupHDDVD is not a fake...
Now we have to make movies with the IME feature playable with PowerDVD.

Then, ... BD+!

I now am a believer. Glad you came back from vacation.

Secondly Was it PowerDVDs memory that you guys dumped to find the key? or was it WinDvD? Or can you find it in both? Just wondering if PowerDvds Media remark was true.

He-Man

13th January 2007, 11:21

For those interested in getting the SHA1 hash for the VTKF000.AACS files. I used this method.

Download this tool from Microsoft.
http://download.microsoft.com/download/c/f/4/cf454ae0-a4bb-4123-8333-a1b6737712f7/windows-kb841290-x86-enu.exe
After downloading, install to Windows\System32 directory.
Open command prompt and type:
fciv -sha1 i:\AACS (Where "i" is the HD-DVD drive letter)
Take the hash for the VTKF000.AACS file.
Note that the hash has to be all caps in the keydb.cfg file.Try this: HashCalc (http://www.slavasoft.com/hashcalc/index.htm)
WinHex (http://www.winhex.com/) can calculate the hash value for a file. You probably need WinHex for the memory dump anyway, so why not use if for the hash calculation too.
In WinHex use these two step to find the SHA-1 hash value:
1) Open VTKF000.AACS with File -> Open [Ctrl+O]
2) Calculate hash value with Tools -> Compute Hash [Ctrl+F2] and choose SHA-1 (160 bit) and hit OK.

If you don't want to use WinHex for this task, then there's also the nice little HashTab Windows Shell Extension (http://www.beeblebrox.org/hashtab/)
that can do the calculation for you.
After installation of HashTab just right-click on VTKF000.AACS in Windows Explorer, then choose Properties and click at the new File Hashes tab shown below:
http://www.beeblebrox.org/hashtab/hashtab.jpg

He-Man

13th January 2007, 11:44

Java is giving me problems.

An unexpected error has been detected by HotSpot Virtual Machine:
# Internal Error (4E41544956452C4F4F4B55500E43505000D5), pid=3704, tid=3304
# Java VM: Java HotSpot(TM) Server VM (1.5.0_10-b03 mixed mode)

I take it I ony need the JDK 6 from here:
http://java.sun.com/javase/downloads/index.jsp
(http://java.sun.com/javase/downloads/index.jsp)

Update: I uninstalled all versions that was on my computer, downloaded the 53mb java file
Copied the folder
C:\Program Files\Java\jdk1.6.0\jre\bin\server
to
C:\Program Files\Java\jre1.6.0\bin\server

it now works!

The FAQ.txt says Java Runtime 1.5 is required, maybe it should have said 1.6 instead of 1.5?

-What are the system requirements to use "Backup HDDVD"

1 - A Windows based system
2 - A HDDVD disk drive
3 - A HDDVD player software (like PowerDVD)
4 - A HDDVD movie(s)
5 - Java runtime 1.5
6 - The possibility to access the content of the disk with a drive letter under windows.
(you may need UDF 2.5 file system driver for this)
7 - A lot of free hard disk space to backup your movies!

calinb

13th January 2007, 12:33

For those interested in getting the SHA1 hash for the VTKF000.AACS files. I used this method.<snip>
Or simply modify Muslix64's code in the BackupHDDVD.java file to have it report the hash it reads from the disk and recompile with the Sun JDK:

<snip>
System.out.println("Found valid HD-DVD source.");

byte[] keyFileHash = Utils.hashFile(keyFile);
System.out.println("Look for this movie in my database");
Properties TitleKeyDatabase = new Properties();
try{
TitleKeyDatabase.load(new FileInputStream("TKDB.cfg"));
System.out.println("Hash read...");
System.out.println(Utils.toHexString(keyFileHash));
<snip>

hajj_3

13th January 2007, 12:38

calinb, please can you re-compile this to do the hashes, that would be amazing, the more automated this can become the better!

He-Man

13th January 2007, 12:47

calinb, please can you re-compile this to do the hashes, that would be amazing, the more automated this can become the better!
It could be build into the Backup HD-DVD GUI that "Polly" is already working on: http://forum.doom9.org/showthread.php?p=929912#post929912
But it should still be put into the correct field in the KEYDB.cfg file toghter with the key, title, etc.
And since you need WinHex or similar to find the key, it's just as easy to use this tool to find the hash too.

Only recompiling the BackupHDDVD code to report the hash will not make the process any more automated than using WinHex to show the hash.

calinb

13th January 2007, 12:51

I was under the impression from the quick glance I had the chance to grab that the volume unique keys would work with any player
once we've gotten them we have them and no longer need the player KeyThe opportunity to grab decrypted keys and the difficulty of doing so varies from player to player. Yes--once you've figured out how to exploit any given player and used it to calculate the volume unique key, you no longer need the player for any further decryption of that disc. You have BackupHDDVD for that!

But what about discs, new or old, for which you've not yet obtained a volume unique key in the clear (unencrypted)? You'll need the player again. If the player is listed in your drive memory (presumably flash memory) as revoked, the player will no longer work to generate volume unique keys or even play any HD-DVD discs--even if you reinstall a fresh copy of the software on your computer. This will require you to learn how to exploit another player, hack the drive, or hack the player.

zeroprobe

13th January 2007, 12:58

The opportunity to grab decrypted keys and the difficulty of doing so varies from player to player. Yes--once you've figured out how to exploit any given player and used it to calculate the volume unique key, you no longer need the player for any further decryption of that disc. You have BackupHDDVD for that!

But what about discs, new or old, for which you've not yet obtained a volume unique key in the clear (unencrypted)? You'll need the player again. If the player is listed in your drive memory (presumably flash memory) as revoked, the player will no longer work to generate volume unique keys or even play any HD-DVD discs--even if you reinstall a fresh copy of the software on your computer. This will require you to learn how to exploit another player, hack the drive, or hack the player.

The new updated players have to playback old material though, thus having the same title keys????????? and as we already know them it will be easy to locate on the new software players.

Title keys will stay the same so will reveal where the location is on new software players. Am I right???

hajj_3

13th January 2007, 13:00

It could be build into the Backup HD-DVD GUI that "Polly" is already working on: http://forum.doom9.org/showthread.php?p=929912#post929912
But it should still be put into the correct field in the KEYDB.cfg file toghter with the key, title, etc.
And since you need WinHex or similar to find the key, it's just as easy to use this tool to find the hash too.

Only recompiling the BackupHDDVD code to report the hash will not make the process any more automated than using WinHex to show the hash.

he may just be a 1hit poster, we need someone to release a gui version on here with sourcecode so that we can all improve it. pref a c++ version or something that dosent require java or .net to be installed.

calinb

13th January 2007, 13:09

<snip>
Only recompiling the BackupHDDVD code to report the hash will not make the process any more automated than using WinHex to show the hash.I agree. We could discuss whether or not the hash check in Muslix64's code is a good usability feature. It appears the only reason it's there is to support multiple entries in the KEYDB.cfg file. (It identifies discs by matching the hash to the user's entry in KEYDB.cfg.) Given that a user generally decrypts an HD-DVD only once, it might make sense to remove this feature from the code and support only a single entry in KEYDB.cfg. Or even better, simply add a command line option to permit placing the volume unique key on the command line and completely ignore KEYDB.cfg. That way we could have both functionalities, as desired for the situation. :)

I've been looking for a reason to learn a "modern" programming language -- having been more of an assembly and C guy in the past. I'm sure others will whiz right past me in developing new tools and features but I could add this command line volume unique key option, if there's interest. (I feel like I should contribute something--damn day job had me shut down during most of this action!)

hajj_3

13th January 2007, 13:15

yeah Calinb, create an updated version of this and release the sourcecode, even if it is commandline, someone can then create a gui version from it by knowing the sourcecode.

calinb

13th January 2007, 13:15

The new updated players have to playback old material though, thus having the same title keys????????? and as we already know them it will be easy to locate on the new software players.The updated players will play old media but, if they go to the trouble to revoke a player, the new one will certainly be more resistant.
Title keys will stay the same so will reveal where the location is on new software players. Am I right???Hmm--that would help considerably. Are you gonna make me go read that spec again? ;)

yeah Calinb, create an updated version of this and release the sourcecode, even if it is commandline, someone can then create a gui version from it by knowing the sourcecode.Okay...but I gotta get some sleep first. There are so many excellent programmers around here and this thread is moving so fast, someone will have probably beaten me to it by the time I awaken. ;)

zeroprobe

13th January 2007, 13:26

The updated players will play old media but, if they go to the trouble to revoke a player, the new one will certainly be more resistant.Hmm--that would help considerably. Are you gonna make me go read that spec again? ;)

Okay...but I gotta get some sleep first. There are so many excellent programmers around here and this thread is moving so fast, someone will have probably beaten me to it by the time I awaken. ;)

If decrypted title keys are the same on powerdvd and winddvd then it obviously has no effect what the players key is.

He-Man

13th January 2007, 13:33

I agree. I only compiled Muslix64's code to report the hash because my hash calculator was having trouble. We could discuss whether or not the hash check in Muslix64's code is a good usability feature. It appears the only reason it's there is to support multiple entries in the KEYDB.cfg file. (It identifies discs by matching the hash to the user's entry in KEYDB.cfg.) Given that a user generally decrypts an HD-DVD only once, it might make sense to remove this feature from the code and support only a single entry in KEYDB.cfg. Or even better, simply add a command line option to permit placing the volume unique key on the command line and completely ignore KEYDB.cfg. That way we could have both functionalities, as desired for the situation. :)
I think most users wish to store all the extracted keys somewhere anyway. You might only need to extract once, but it would be nice to keep they keys so you can always extract again if your hard rive crashes or something. Or maybe you want to share the keys with a friend. Or using the already extracted keys as reference for hacking a new player if the old player gets revoked.
So if you are going to store keys for all the extracted files anyway, you might as well just store them all in the same KEYDB.cfg file along with the title name and hash.

I think a better solution would be to automate writing/updating to the KEYDB.cfg file by entering the movie title, + volume/title key value in the the a GUI for BackupHDDVD and then have it automatically calculating and writing the hash to the KEYDB.cfg along with it.

hajj_3

13th January 2007, 13:38

yeah, a .txt plaintext file of previously found keys would be good, like anydvd does.

zeroprobe

13th January 2007, 13:44

can anyone confirm the end result decrypted title keys are the same regardless of which player is used.

If so is that not game over as we know what to look for on any updated software player?

He-Man

13th January 2007, 13:50

If decrypted title keys are the same on powerdvd and winddvd then it obviously has no effect what the players key is.
If a player key gets revoked by new HD-DVD movies, so this player wont be allowed to play anymore HD-DVD's, then you need to install a new player version. This new player version might be better at hiding title and volume keys in memory. If you can't find these keys in memory anymore in a new version of the player, then you can't extract anymore movies because you can't find keys anymore, not in the old player version because it has been revoked so it's not allowed to play anymore HD-DVD's, nor in the new player version if you can't find the keys in memory anymore in this new version.

I don't know if anyone is able to extract title/volume keys using PowerDVD. Has anyone tried to search for the keys in memory using PowerDVD?
If WinDVD gets updated to be more secure it might not be possible to extract keys with this anymore either. And then it doesn't help to have the old player version still installed because it can be revoked from new movie titles without even being connected to the internet.

Please correct me if I'm wrong, but that's how I understood the revocation process.

jackchen

13th January 2007, 13:55

can anyone confirm the end result decrypted title keys are the same regardless of which player is used.

If so is that not game over as we know what to look for on any updated software player?

yes, in the AACS spec. it's 100% true that every player including the software and hardware player will always decryt the title key table and then get the same result. But AACS can revoke these titles so that you won't be able to play these disks any more. But that will be a critical impact since there are already so many titles released in the filed.

For those people with both software players, could you give it a little trial to see whether we can find the keys in PowerDVD's memory or not?

JarrettH

13th January 2007, 14:00

this thread has revealed the true crackers of this community :D

Hellreaper

13th January 2007, 14:30

zeroprobe

13th January 2007, 14:39

someone already mentioned they found a title key in powerdvd. The only way they can have a good chance at stopping this is blacklisting every single hddvd released thus far.

As it stands even if they update the players, the title keys already out can be used to track down the new locations. When you know what to look for it would be easy. The only way they stop this is blacklisting the titles out now. Can you really see them doing this.

jackchen

13th January 2007, 14:46

Abstract: PowerDVD doesn't store the keys in memory, therefore they can't be found there. Since there's no loophole, nothing needs to be fixed. If there was one, they would have to report it to AACS LA, and new HD DVDs would contain a new keyset that would make them unplayable with the compromised PowerDVD version. Furthermore, all 18 months, there is a mandatory change of keys.

I believe that he was talking about the player key instead of the title key or the Volume unique key.

Eeknay

13th January 2007, 14:55

I'm having trouble with WinDVD... I installed the HD version, it opens, but then sits there and does nothing if I select "HD DVD source" or hit Play. Any ideas?

EDIT: never mind, fixed it. Needed to roll back my ATI drivers to 6.7.

He-Man

13th January 2007, 14:56

someone already mentioned they found a title key in powerdvd.
Who mentioned this and where?
So far in this topic I have only read people mentioning finding keys in memory using WinDVD.

zeroprobe

13th January 2007, 15:06

Who mentioned this and where?
So far in this topic I have only read people mentioning finding keys in memory using WinDVD.

wasn't on a forum. Someone mentioned they had found one so I presume he's right.

markrb

13th January 2007, 15:54

Once a movie is on your HD a few questions since I can be thick.
Do you need to use PowerDVD 6.5 or will any HD capable player play the movie?
Do you need to run anything other then the player or is the movie completely decrypted already?

I just get the impression that you still need to use the keys even after copying with the keys?

I have a HTPC and I copy my most watched movies that I own onto the HD so I can just click to watch and would like to continue this way with HD-DVD.

Thanks,
Mark

MrDVD

13th January 2007, 18:03

Anyone know it the X360 HD-DVD is recognized by linux so that its possible to run the java soft under it ?

noclip

13th January 2007, 18:57

In case you're having trouble finding the keys, search for the second occurrence of file:///required/ and scroll down until you see something in the sea of 00s, that's the TK block. Scroll down some more and the VK will be there.

moshmothma

13th January 2007, 19:43

Could someone please tell me how they are handling the .map files? They are not being copied during the backup process. Is everyone just copying files from the disc to the their backup folders? Thanks

LordSloth

13th January 2007, 20:02

Now that the key memory locations are easily determinable, we need to figure out how the Volume Unique Key derived from the Volume ID and whatever other parts that may go into it.

If we can figure out that algorithm we can start work on making a Linux HD-DVD (possibly even BluRay) player that can play all our discs!

I don't have much use for backing up my discs (I tend to take good care of them) and making an open source Linux HD-DVD/BD player is only reason I care about working on any of this.

Hope we can get some smart people to help out in this. I guess this should be a separate thread.

~Cheers!

Bystander

13th January 2007, 20:13

I just tried WinDVD HD. Seems I can't get Olly to get past an error... " Don't know how to bypass command at address 00FBCE2A. Try to change EIP or pass the exception to the program". I tried adding the exception in the debugging options and no go.

Which brings me to my next question. If you are not using a debugger when dumping memory with WinHex, at what point do you inspect the memory? do you pause or stop the movie?

Then for Winhex, you can select WinDVD but what exactly do you click on to search? I find only one instance of VPLST000.XPL and no keys are present.

The version of WinDVD I am using is: 7.5 B42.052 in the information tab

Eeknay

13th January 2007, 20:21

cyberpass

14th January 2007, 00:05

DanITman

14th January 2007, 00:43

Here is my worry...AACS refuse to license any software player...Is there anyway to dump the memory of a hardware player? I remember during the days of direct tv hacking, hardware memory dumps will flying everywhere....

Yes, there is a good possibility that people will figureout how to extract keys from actual hardware players. This how DeCSS original became what it is today.

In regards to no software players, this will never happen. The first company that people does this will lose the format war.

xyz987

14th January 2007, 01:15

emule or torrents probably only way, and it would be not
organized and some people would just include random numbers
for keys just to waste your time.

Key poisoning is not a big problem. Any key collector can sign the file that stores his/her keys collection. Of course, a key collector can get keys from files from other key collectors he/she trusts.

blutach

14th January 2007, 01:51

Good morning/evening all.

May I ask members who have questions that are off this topic to start their own threads please?

I will move various posts to new threads in the meantime.

Regards

Mistar Muffin

14th January 2007, 02:41

I successfully ripped the entirety of King Kong to my drive with the volume key supplied in this thread. I do not have an HD copy of WinDVD, as I do not want to buy the jap copy. I do have the HD ver of Power DVD 6.5, and I can play everything except the feature film in it just fine. On Vista Ultimate x86, I can play the universal logo and various menu files after they are ripped, but attempting to play the FEATURE_1/2.evos causes PDVD to crash. Same goes on an XP Pro box with entirely different hardware. What I found interesting is that the Vista box I am on now only has a 3.0ghz P4 and 1024mb PC3200 and a meager Geforce 5200, and plays back on a 1280x1024 monitor without hiccups. Pretty sweet, but I wish I could get the feature to play.

Also, anyone successfully gotten a key from PowerDVD?

noclip

14th January 2007, 03:40

Also, anyone successfully gotten a key from PowerDVD?

The title key for whatever title is playing is in memory in PowerDVD, but no volume key.

jokin

14th January 2007, 03:59

I usually find the keys just above CONTENT_REVOCATION_LIST.AACS for World Trade Center and Batman Begins.

Jerky_san

14th January 2007, 04:36

To people wondering about PowerDVD last night when the keys first started appearing Janvitos spoke about finding keys in powerDVD but I believe he mentioned it was a little bit harder at first but he then discovered the 13 monkey key in PowerDVD hopefully he will come back soon and tell about the experience but I'm fairly certain he said he was able to find keys in powerdvd..

Ábudos

14th January 2007, 04:57

To the people who origionaly found the Volume Unique Keys and title keys:

How did you find them for the first time? Was there some logic behind it, or did you just grab 16 bytes that looked conveniently placed and get lucky?

Jerky_san

14th January 2007, 05:03

<Janvitos> simply do a text search for VPLST000.XPL
<Janvitos> and after a couple of instances
<Janvitos> all the title keys are there
<Janvitos> and below
<Janvitos> after some few 0s
<Janvitos> will be the volume unique key
<Janvitos> easily recognisable

thats what Janvitos said yesterday when explaining how he found them..

Ábudos

14th January 2007, 05:09

OverlordQ

14th January 2007, 06:23

beaups

14th January 2007, 06:34

Okay, congrats to those who have won round one and yes--the keys are on the disk, but they are encrypted keys on the disk. We still need an (unrevoked) player to decrypt new keys for us or even play old encrypted disks. If your player is revoked, it's end of round one; you won't even be able to play old titles! Here's why: Take a look at Fig. 4-1 of AACS_Spec_Common_0.91.pdf. 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.
What would prevent somebody from modifying their "player key" so that it is unique and not in the "revocation list"?....

Warren

14th January 2007, 06:38

What would prevent somebody from modifying their "player key" so that it is unique and not in the "revocation list"?....

Nothing except for the fact that the player will no longer be able to decrypt anything to play it.

beaups

14th January 2007, 06:41

warren can you please explain why the software player would no longer work?

OverlordQ

14th January 2007, 06:50

http://www.thedarkcitadel.com/svn/BackupHDDVD/

Public checkouts, passworded commits.

woah!

14th January 2007, 06:52

http://rapidshare.com/files/11616301/BackupHDDVD.rar

2 'requested' features added:

1) Will report the calculated Disc Hash
2) If Hash not found in key file, will add it after prompting for the name of the movie.

Given I don't have neither HDDVD Drive nor any HD Movies, I'll need bug reports from somebody on if these work or not :)

Also, this was compiled against Java 5.0 so if it gives errors, try:

http://rapidshare.com/files/11615854/BackupHDDVD.rar which was compiled as 1.4 compat.

works great here to show the hash thx :)

Backup HD-DVD V1.00 (OQ Mod 0.1) Starting
Testing source
Found valid HD-DVD source.
Disc Hash: 0E75082678AAD5CD4410A28A662D6832D21EB325
Look for this movie in my database
Found movie: King Kong
Start backup on Sat Jan 13 21:50:06 PST 2007
Scaning video directory
Processing BLACK.EVO key = 3

also i have waterworld i havent done yet and yes it asked for the name and added it to the key list with the hash etc...

B5DE266362701D2E7C36A5F389855F2B7DB6A17F=waterworld |V|0/13/2007|00000000000000000000000000000000

but as i havent got the hang of getting the vlk from the memory myself i have no waterworld key yet.

melakai

14th January 2007, 07:02

warren can you please explain why the software player would no longer work?

If you change the device key arbitrarily, it won't be able to obtain the media key, which is needed to get the title keys. The value would have to be changed to a different Kd_i.

3.1 Device Keys
Each compliant device is given a set of secret Device Keys when manufactured. These Device Keys, referred to as Kd_i (i=0,1,…,n-1), are provided by AACS LA, and are used by the device to process the MKB to calculate Km (Media Key).

1.8 Terminology
Media Key
A key that is used to unlock the Title Keys stored on a media that contains Titles protected by AACS. The Media Key can be computed by successfully processing a MKB.

OverlordQ

14th January 2007, 08:57

works great here to show the hash thx :)

B5DE266362701D2E7C36A5F389855F2B7DB6A17F=waterworld |V|0/13/2007|00000000000000000000000000000000

but as i havent got the hang of getting the vlk from the memory myself i have no waterworld key yet.

Meh, looks like I flubbed up the Month.

popper

14th January 2007, 09:50

as a side note,i thought this was an interesting comment as regards HDDVD/BR
Flash will kill Blu-ray and HD DVD
http://uk.theinquirer.net/?article=36930

flash memory is all well and good but i find it iritating that the superslow USB became the standard for interfacing it. its about time we had a FAR faster interface so as to get far better read/write from any flash device ,it seems we need at the very least an updated far faster USB3 to be introduced and PDQ...

hajj_3

14th January 2007, 10:39

lets stick to uploading to sendspace.com, rapidshare is pants! wait times, things get deleted if they are reported etc.

keep up the good work adding features!

blutach

14th January 2007, 11:05

@popper

Apparently you do not read what Doom9 and I write. Strike issued.

Stick to the topic. "Interesting" things between BR/HDDVD do not belong in this thread.

Regards

2bigkings

14th January 2007, 11:15

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!
thank you very much.

regards

Amir

14th January 2007, 12:12

About player revocation for when new discs are out...

I was wondering, how is a player identified as being that exact one?. if the version string is somehow sent back to the player then cant we simply edit the .exes resources to send back the vesion of the newly released player?.

e.g. if you use powerdvd6.5 and then 7 is released with 6.5 being the "revoked" one. Would it not be feasible to alter 6.5 to report back as 7?

I'm unsure if there are any checksums returned as part of the return message but was just wondering..

zeroprobe

14th January 2007, 12:16

Amir

14th January 2007, 12:19

It's not the program revoked its the players key. So they will get a new key when they have fixed up there player.

BTW has windvd responded to anything yet lol?

Whoops sorry you are right, this thread is so long stuff at the beginning is getting forgotten :-o

JackSnap

14th January 2007, 13:08

I was wondering about that, is it not possible to create a revocation list, with say one player key in it that no one cares about, and set the version number to the highest possible allowed by the structure, then in theory no player will bother importing anymore files as it will always think it has the latest.

zeroprobe

14th January 2007, 13:27

my god, again software players have KEYS which are used to get the volume, title keys.

if this players key is on the revocation list on the hddvd its not going to work.

He-Man

14th January 2007, 13:47

markrb

14th January 2007, 13:53

I successfully ripped the entirety of King Kong to my drive with the volume key supplied in this thread. I do not have an HD copy of WinDVD, as I do not want to buy the jap copy. I do have the HD ver of Power DVD 6.5, and I can play everything except the feature film in it just fine. On Vista Ultimate x86, I can play the universal logo and various menu files after they are ripped, but attempting to play the FEATURE_1/2.evos causes PDVD to crash. Same goes on an XP Pro box with entirely different hardware. What I found interesting is that the Vista box I am on now only has a 3.0ghz P4 and 1024mb PC3200 and a meager Geforce 5200, and plays back on a 1280x1024 monitor without hiccups. Pretty sweet, but I wish I could get the feature to play.

Same thing for me on King Kong (XP only), but Serenity plays fine.
What could it be? Different Key?
Tried it twice, once with the new modified version.
Any thoughts as to what else to try?

Mark

hajj_3

14th January 2007, 15:07

can someone upload the rapidshare file to sendspace.com please. rapidshare.com isnt working very well for uk users at the moment.

thanks.

blanchg

14th January 2007, 15:09

Revocation facts from: http://www.aacsla.com/specifications/specs091/AACS_Spec_Common_0.91.pdf

MKB has three methods of revocation, two specifically for PC's with separate devices/playback software and is described in detail in Section 4 of above document.

Summary here:

1. Device Revocation List (DRL): Each device (i.e. XBOX360 HDDVD Drive) has an id attached to it in a record that has been signed by AACS_LA private key (Section 4.1) and is verified as having not been modified by the Host using the AACS_LA public key. This is versioned inside the MKB which is also signed by the AACS_LA private key (Section 3.2.5.8) and checked it is not modified before use. This pretty much discounts modifying the device id or setting the version of the DRL to it's maximum. (unless we have the AACS_LA private key which is nearly impossible to get/brute force)

2. Host Revocation List (HRL): This is the software running on the pc i.e. (PowerDVD, WinDVD) has it's own id again in a record that has been signed by the AACS_LA private key (Section 4.2) and prevents the same kind of attacks as per the DRL above.

3. Key revocation via Subset-Difference Tree or NNL-Tree: (Seciton 3) This is used both to calculate the Volume Key used by BackupHDDVD and to revoke DEVICE KEYS. Again this is part of the AACS_LA signed MKB and can't be altered. The interesting part of this is that each device calculates the same Volume Key for each disk with the same MKB (this will usually be the same for each "title" in a particular batch as has been proved).

Hope that dispels some of the incorrect information/questions being posted.

Hellreaper

14th January 2007, 15:14

There is a new article on "heise online".

http://www.heise.de/newsticker/meldung/83671 (german)

It tells about the "Serenity riddle", the weakness in the japanese version of WinDVD and the volume key thread.

The author says that the compromised WinDVD version will probably withdrawn. He also says that you probably won't be able to play future generations of HD-DVDs with it.

Ronin-7

14th January 2007, 17:22

Same thing for me on King Kong (XP only), but Serenity plays fine.
What could it be? Different Key?
Tried it twice, once with the new modified version.
Any thoughts as to what else to try?

Mark

Those having problems with King Kong are normal I believe as PowerDVD 7 Ultra had problems playing this when it was released from reading the thread on the AVS Forums & ironically bugs to do with the HDCP implementation as it wasn't working for some even with the right hardware :rolleyes:

hajj_3

14th January 2007, 17:25

we need to create a very in depth user guide as a .pdf with screenshots etc. also a table of keys and compatible hd-dvd titles needs to be created.

who fancies doing these?

He-Man

14th January 2007, 17:57

also a table of keys and compatible hd-dvd titles needs to be created.
This has already been done in a separate topic. Look at the sticky topic named Volume Unique Keys (http://forum.doom9.org/showthread.php?t=120611) in this forum. So far 30 titles and keys has been posted.

hajj_3

14th January 2007, 18:16

didnt know that. well we just need to create a very detailed pdf guide then i guess and add more titles to the list. im gunna be ordering a hd-dvd drive in a few days as a result of this thread:)!

Bystander

14th January 2007, 19:12

Power DVd 7.1 is not immune. Have a looksee

Van HelsingSHA1 Hash of VTKF000.AACS: 486198E3855B57CD40F6DC0C60645BDE8E1E9AC5

Title Keys:

43030103CB010B02304A8605F8AE7F06
70B07F062C4A860570B07F06689E7E06
FEC90F16A5075797B3C158BAA726B491
D09B373FFCD5950043AA83400A9E54A6
6688A295A241144512CC4C99C0C061A4
CCB6AB1337D4AAA6871553F676AA98B6
0F797221B5BB9FEC7B640E47B5A186CA
79A8626B10580955779CBA9328EE3459
BF6235C9C5F2E5448175DA4FBC3EFB2B
DD60CFF1D991A2579D0FD3E7AF269C96
B342601AF6660A83040D4D1AB728C778
C9DF108A6A7A19CBBF626F52D4B12456
33072BF6386FCE3A91A80DB8B4F6DD90
2AEC2F11B4A43884CE66B3DF005A3F26
2E52CFAFE2ED5C2AD735AE9791590C3C
98A0CD3CA24531365D660746D3EF31C3
2F290DF0416120F122128EB8AC82854B
92E04EB34DD8DD72D212677B253CEA57
FB940AA831093584CA4A674A442BA712
D4EE9FEEDB6F483053F98EA78F6024C3
444F3EF7F7867997FB5BB4D45274E7D1
4F2689FA1C1DCA4D1A78D33E3896657D
8A86BC850B99240DD2D951A21F835EE3
0FC3BC1F20BEAE53B1EAD64B103BDB50
A9C3459600D6F9353FA890DCCBA85959
AC0469A8BECDCDFB097CF76004CAEA65
21DE26210F177A5787E81EABEE20FED9
1869FAD6D6B59D5EAFC37546567D7A9A
848AE12CD408702476711B0A1887520F
DF455DAA553B6E93B06FE2A5D3A8F3C4
987DD26BBDAAEBAD015165B5133D7CAC

Volume Key: C3EE61AFEED85EB5285C60DBEE61545B

Phantom of the OperaSHA1 Hash of VTKF000.AACS: 0592DA47B8E0C8071C05A55C568F0F2531C28751

Title Keys:

4303010365010B02304A7605F8AE6F06
70B06F062C4A760570B06F06689E6E06
DA690991F3E0875AA553ACB93653F8A1
D1120C8D07D6FA0D3058E19FA3EC0D5C

Volume Key: 4B58600E51C5A8756D618AFA6F54499A

jokin

14th January 2007, 19:26

Power DVd 7.1 is not immune. Have a looksee

Any hints as to the general area to look? The same VPLST000.XPL as before?

Bystander

14th January 2007, 19:35

Why risk having both players changed and starting from scratch? Let's wait and see what happens to WinDVD first mkay?

jokin

14th January 2007, 19:42

Why risk having both players changed and starting from scratch? Let's wait and see what happens to WinDVD first mkay?

OK, but posting that you found the keys in PowerDVD 7.1 and posting the keys pretty much tells AACS LA that they need to revoke the PowerDVD key along with WinDVDs. It also makes a larger number of people try to figure out that method instead.

I assumed you were willing to help out with that method since you posted the keys. Ahh well, gives me something to do in the meantime. Thanks for confirming it though.

hajj_3

14th January 2007, 19:44

these hd-dvd's seem to have been ripped and are on torrent sites, 25gb, 25gb and 20gb:

The Chronicles Of Riddick, Batman Begins, Serenity

e.g: The Chronicles Of Riddick HD DVD 1080p VC-1 DDPlus 5.1

they are .evo files.

VistaVick

14th January 2007, 19:50

these hd-dvd's seem to have been ripped and are on torrent sites, 25gb, 25gb and 20gb:

The Chronicles Of Riddick, Batman Begins, Serenity

Aaaaaah, can't play these in windows media center, need to find a way to convert.

Doom9

14th January 2007, 20:00

I believe it's time that I remind some people here of our rules with regards to downloaded content. As we cater to an international audience, they are more strict than your local laws may be.
Bottom line: decrypting and converting discs you own: OK, downloading ripped discs via P2P and further processing them: Not OK.
So tread carefully please.

noclip

14th January 2007, 20:06

blanchg: Can't we just modify WinDVD so that it ignores the revocation lists completely?

zeroprobe

14th January 2007, 20:10

blanchg: Can't we just modify WinDVD so that it ignores the revocation lists completely?

no as its windvds KEY that is revoked........... ( how many times )

noclip

14th January 2007, 20:18

no as its windvds KEY that is revoked........... ( how many times )

WinDVD's key will simply be wrong for decrypting further disks? How would they manage that?

tonyp12

14th January 2007, 20:34

WinDVD's key will simply be wrong for decrypting further disks? How would they manage that?

As I understand it, the disc have space allotted for a list of revoked keys.

But say you do hack the software player to ignore this list somehow
and still being able to play the title.

Or does AACS just encrypt new movie titles (from a specific date on and forward)
with a new masterkey that simple can not work with windvd's key.

Zag

14th January 2007, 20:41

As I understand it, the disc have space allotted for a list of revoked keys.

But say you do hack the software player to ignore this list somehow
and still being able to play the title.

Or does AACS just encrypt new movie titles (from a specific date on and forward)
with a new masterkey that simple can not work with windvd's key.

The problem is not the player that needs to ignore the revocation list, it is the disc. Once the disc sees the players key is on it's revocation list, it will refuse to pass its keys to the player. If the keys are never given to the player than there is no way to extract them.

tonyp12

14th January 2007, 20:46

Once the disc sees the players key is on it's revocation list, it will refuse to pass its keys to the player.

The disc does not have a chip in it to make that kind of decisions,
Do you mean the DRIVE will check and will stop streaming data.

If so can't the firmware for the drive be hacked?

arnezami

14th January 2007, 21:20

The disc does not have a chip in it to make that kind of decisions,
Do you mean the DRIVE will check and will stop streaming data.

If so can't the firmware for the drive be hacked?

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

1) Each device (read: software player here) has a set of device keys.
2) Each disc has a Media Key Block (MKB) which is pretty large btw.
3) Each disc is essentially encrypted with a volume/media key. This key is also on the disc but it is itself encrypted.
4) Using a combination of the device keys and the MKB you can decrypt the Media/Volume key. But only if they (that is: device keys and MKB) are "compatible".
5) If you have the media/volume key you can decrypt the title keys which in turn can be used to decrypt the content.

For a new HD DVD (which still to be pressed/released) they can make the MKB so that all devices except certain compromised (software) players can decrypt the media/volume key. So even if you have an old player (with its old player keys) you can't decrypt the media key because the information simply isn't in the MKB anymore. This also explains why you can still decrypt all old HD DVDs released so far but not those in the future.

Right now WinDVD can decrypt all media/volume keys for all HD DVDs so far. For each HD DVD we can look into the memory dump what the decrypted volume key is. But if new HD DVDs come out with updated MKBs then this version of WinDVD can't decrypt anything and we won't be able to use its memory dump. We'll have to hack the new version of WinDVD (or PowerDVD).

Hope I'm making myself clear here.

Regards,

arnezami

Shinigami-Sama

14th January 2007, 21:31

if they have a place on the physical disk
can't you just do that black sharpie trick like with the - I believe sony protected disks?
havn't had a chance to read that part of the specs yet...

Lord_KiRon

14th January 2007, 21:42

Just an idea (I haven't bothered to read the AACS specs :o ) :

If we have a Tilte and Volume Keys and a disk can't we perform reverse process and calculate player key ?

In this case I believe generic decryption utility can be created that can decrypt any disk that does not blacklist that player key ...

Or am I missed something ?

Bystander

14th January 2007, 21:49

Right now WinDVD can decrypt all media/volume keys for all HD DVDs so far. For each HD DVD we can look into the memory dump what the decrypted volume key is. But if new HD DVDs come out with updated MKBs then this version of WinDVD can't decrypt anything and we won't be able to use its memory dump. We'll have to hack the new version of WinDVD (or PowerDVD).

You may be able to inject aka cut/paste PowerDVD's key into WinDVD to convert them again. Food for thought.

CiTay

14th January 2007, 22:06

We'll have to hack the new version of WinDVD (or PowerDVD).

First, Cyberlink and/or InterVideo have to admit that they have a security hole (Cyberlink denied it already). When they report that to AACS LA, they can do a player revocation.

But so far it remains more or less a theoretical threat for the movie industry. Who knows, if enough people hear that they can handle their HD-DVD movies more freely, it might boost popularity of HD-DVDs and make it the media of choice. The protection of DVDs is circumvented and they still sell, what's the deal with that?

And they can't carry player revocation and other restrictions too far anyway. I doubt that customers would constantly want to update their player when yet another version is compromised and all they see is an error message when they try to play that new movie. They might start to think that the paying customer is the idiot here and turn to other means of getting that movie...

Syris2k4

14th January 2007, 22:23

Imho - I dont think they will bother.

Backing up HD-DVD's requires disk space, time and some know-how that 99% of consumers dont really have. So bothering to discomfort that many people would be kinda silly, specially considering how many of these players they licence. Think almost every mid range+ gfx card/Mobo.

And atm - this is making the format look muuuch better than BR to people that care about DRM etc.

As long as copies dont flood the market within the next 2/3 months - I dont see it changing, they know we will adapt anyway.

appleguru

15th January 2007, 00:08

Here's to hoping this will let me play the movie in OS X with DVD Player... Decrypting Batman Begins atm to find out; I'll report back :)

markrb

15th January 2007, 00:13

I am so glad there are smart people on this board.
I have tried time and time again and I cannot locate the keys in memory using winhex. I have tried searching for all the text strings listed in this thread and even looked for known keys on King Kong with no luck.

Is the key findable with a search in memory if you know the key or does it have to be translated somehow?

I can find the hash no problem so I know I have the same version that is listed in the volume key thread.

I am planning on buying some movies not listed so I might contribute, but if I can't find a known key how will I know what to look for in an unknown disc?

I guess I am just discouraged. Any help anyone can give I would appreciate it.

Thanks,
Mark

Shinigami-Sama

15th January 2007, 00:15

rubycon

15th January 2007, 00:42

Such a blatant post about how you copy material you do not own is clearly against the spirit and intention of rule 6. I have warned users about this previously in this very sensitive thread.

Strike issued.

As well, I fail to see what a person's hair has to do with it. Please be more polite on this forum.

Regards

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.

arfster

15th January 2007, 01:45

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

It's their forum - they can ban or warn you for whatever they like.

Given how aggressive the legal people can be wrt copyright, you can hardly blame them.

Shinigami-Sama

15th January 2007, 01:55

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.

This forum is currently hosted in the USA; therefore it must abide by the rules and regulations of the USA. So in order to operate the users of this forum must also abide by these rules or the forum may be subject to legal battles that would force Doom9 to close down. Please try to be more aware of the rules in the future or else you may not be here long.

toytown

15th January 2007, 03:05

This forum is currently hosted in the USA

Its hosted in france, i believe.

bass4040

15th January 2007, 03:13

Once an hd-dvd movie is on the hard drive and the correct key is used, do you still need an hdcp video card for play back?

Shinigami-Sama

15th January 2007, 03:16

Its hosted in france, i believe.

I remember doom9 saying ateme - I thought that was in the USA
hmm
just doing a lookup the IP resolves to an ampserdam company so I'm not sure anymore.

anyways this is kinda getting offtopic...

Shinigami-Sama

15th January 2007, 03:19

Once an hd-dvd movie is on the hard drive and the correct key is used, do you still need an hdcp video card for play back?

not if you remux the stream into a container/format that doesn't use that restriction

Bystander

15th January 2007, 03:26

You would have to locate the Content Restriction Token/Flag and disable it or force it to always be "off".

This can be done by patching the player or removing it from the decoded .evo file itself.

Gradius

15th January 2007, 03:27

Imho - I dont think they will bother.

Backing up HD-DVD's requires disk space, time and some know-how that 99% of consumers dont really have.

So true. :cool:

Bystander

15th January 2007, 03:42

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.

OverlordQ

15th January 2007, 04:38

Just wondering, isn't the movie title stored somewhere at the HD-DVD disc (maybe the disc title itself, a folder name or in some unencrypted text file) so you can automatically extract the movie title along with the hash value and date?

Not a clue, I dont have a HDDVD Drive, if somebody could tell me where that info is stored, I'd be greatly appreciated so I could add it.

woah!

15th January 2007, 04:41

not if you remux the stream into a container/format that doesn't use that restriction

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.

Janvitos

15th January 2007, 04:41

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.

Doormat!

15th January 2007, 06:12

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

15th January 2007, 06:29

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

15th January 2007, 07:17

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

15th January 2007, 07:18

Anyone confirm?

True.

tonyp12

15th January 2007, 07:28

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!

15th January 2007, 08:56

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

15th January 2007, 09:09

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

15th January 2007, 09:10

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

blutach

15th January 2007, 09:36

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

15th January 2007, 10:04

...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

15th January 2007, 10:14

arturner

15th January 2007, 10:16

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

15th January 2007, 10:21

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

15th January 2007, 10:32

JackSnap

15th January 2007, 11:00

@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

15th January 2007, 11:09

JackSnap

15th January 2007, 11:15

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

15th January 2007, 11:16

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

15th January 2007, 11:20

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

15th January 2007, 11:21

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

15th January 2007, 11:59

Dreassica

15th January 2007, 12:34

Nutrition24

15th January 2007, 12:43

@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

15th January 2007, 13:00

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

Strike issued.

Regards

crashd

15th January 2007, 13:09

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

15th January 2007, 13:33

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

15th January 2007, 13:43

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

15th January 2007, 16:04

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

15th January 2007, 16:14

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

15th January 2007, 16:17

[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

15th January 2007, 16:32

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

15th January 2007, 16:32

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

15th January 2007, 16:55

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

15th January 2007, 17:15

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

15th January 2007, 17:25

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

15th January 2007, 17:41

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

15th January 2007, 18:36

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

moshmothma

15th January 2007, 19:15

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

15th January 2007, 19:33

cwm9

15th January 2007, 19:53

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

15th January 2007, 21:36

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

15th January 2007, 21:50

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

15th January 2007, 21:58

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

15th January 2007, 22:01

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

15th January 2007, 22:03

He-Man

15th January 2007, 22:10

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

15th January 2007, 22:16

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

15th January 2007, 22:28

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

15th January 2007, 22:30

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

15th January 2007, 23:01

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

blutach

15th January 2007, 23:35

Mister Muffin - I know your posts pertain to both threads, but please be careful about cross posting. You can assume people interested in web access to keys will read that thread.

Wookie Groomer - you've been around long enough to know all about rule 12. Please observe it. Multiple post deleted.

Regards

Nutrition24

15th January 2007, 23:58

The more I'm reading the AACS spec, the more I'm confused...

The backuphddvd tool treats packs as NV_PCK and others. For others, the PES flag is checked (Header[20] & 0x30 == 01) to see if the content is encrypted.
If the data is encrypted, it's decrypted with the Title key which is a simple decryption with the Volume Key.

The spec (0.912) however talks about the content key Kc:
Each Encrypted Pack is encrypted by a 128-bit Content Key (Kc). The Content Key (Kc) is calculated
by a 128-bit Title Key (Kt), a 32-bit Title Key Data (Dtk) and the least significant 96 bits of the CPI field in
the GCI_PKT as follows
Kc = AES-G (Kt, Dtk || CPIlsb_96)

from the decryption process:
If the PES_scrambling_control of the current Pack is 01b or if the current Pack is an HL_PCK, the Player calculates a 128-bit Content Key (Kc) using Title Key (Kt)

It's also not clear why they stress the importance for HL_PCK (hightlight) while first they say to use it for all encrypted packs. Could it be that it's only done for HL_PCK with the Kc and otherwise with the plain Title key ? If it's always with the Kc, then how can backuphddvd decrypt any content successfully with the wrong key ?

Also any idea where to find more information about the HD DVD-Video Specifications ? It's not really clear what must be cleared here:
HeaderPart[0x3c]=0; // Clear CPI field
HeaderPart[0x48]=0;

VistaVick

16th January 2007, 03:11

Can anyone tell me what happened to the thread devoted to demuxing/reconcoding hd dvd images to different formats?

He-Man

16th January 2007, 03:16

Can anyone tell me what happened to the thread devoted to demuxing/reconcoding hd dvd images to different formats?
EVOB De/Multiplexers: http://forum.doom9.org/showthread.php?t=120652

VistaVick

16th January 2007, 03:28

EVOB De/Multiplexers: http://forum.doom9.org/showthread.php?t=120652

Thanks

cwm9

16th January 2007, 03:47

The more I'm reading the AACS spec, the more I'm confused...

I feel your pain....

At first the more I read the more confused I became, but at least some of it is becoming clearer.

Part of my problem was that I had initially read the HDDVD patent w/o reading the AACS spec, so there were a few details I had confused.

AACS seems to slice up the standard packs at certain points and insert extra information, most notably the key and the 0x20 PES decryption indicator.

According to the decryption part of the spec, you're supposed to decrypt the pack if EITHER the PES bit is set OR it's an HL_PCK. The ADV_PCK stuff I found earlier is something that's forbidden to be encrypted, but it would still be embedded in an "encryption pack" marked either don't encrypt (pes bit not set) or maybe in an HL_PCK, I don't know.

The point is, I'm now trying to figure out how to determine when a pack is an HL_PCK which is kinda hard since I could only find two references to it anywhere and I now think that the ADV_PCK is not (directly) related to the problem.

jimfcarroll

16th January 2007, 04:53

HD Hell

16th January 2007, 05:05

Congratulations!
So now you see BackupHDDVD is not a fake...
Now we have to make movies with the IME feature playable with PowerDVD.

Then, ... BD+!

Hi muslix64 - I'm one of those who thinks that you are doing this as a partisan attack on HD DVD. I suspect that you are going to stall on the Blu-Ray version of this.

Are you going to prove me wrong, or just continue to stall? I suspect you could have the Blu-Ray version working in only a couple of days given the work you have already done here.

It's not fair that you attack only one format - if you are true to what you say you are, you would have already released a Blu-Ray version of this program by now...

Color me skeptical of your true motives at the moment.

Mug Funky

16th January 2007, 05:41

@ HD Hell:

dude, most of us can't afford an xbox 360 drive, let alone one of them AND a blu-ray drive.

chill out. the guy gave the community something for free, started the hunt to break AACS.

blu-ray will be broken soon enough. but don't get shirty that an anonymous person isn't giving you what you want. he didn't have to post anything at all, then you'd have nothing to complain about except a pile of HD-DVDs that you can't decrypt.

not a good first first post there...

diogen

16th January 2007, 05:59

Hi muslix64 - I'm one of those who thinks that you are doing this as a partisan attack on HD DVD...Geeez...
Talk about not having a clue.

Diogen.

GIR

16th January 2007, 06:13

blu-ray will be broken soon enough. :)

http://www.hdtvblogger.com/?p=39

I have received numerous (more than 3) independent reports that an exploit has been found on the PS3 that will reveal the title/volume keys for Blu-ray disks using a PS3. The procedure involves some minor modding of the boot process and Linux.

I have not been told of the exact process but the information makes it seem that the process is not that difficult once you know what you are doing and the lengthy steps are duplicated.

I do not own a PS3 so there is no way for me to deny/verify any of this information.

Ábudos

16th January 2007, 06:15

Hi muslix64 - I'm one of those who thinks that you are doing this as a partisan attack on HD DVD. I suspect that you are going to stall on the Blu-Ray version of this.

Are you going to prove me wrong, or just continue to stall? I suspect you could have the Blu-Ray version working in only a couple of days given the work you have already done here.

It's not fair that you attack only one format - if you are true to what you say you are, you would have already released a Blu-Ray version of this program by now...

Color me skeptical of your true motives at the moment.
Are you kidding me? You are flamming him for not cracking blueray because of his involvement with HDDVD?

As he said, he has no Blueray drive. If you want to send him $500 so that he can buy one, I bet he would really love that.

Seriously, seeing as how you haven't done anything yourself, you have no room to criticize.

blutach

16th January 2007, 08:57

Hi muslix64 - I'm one of those who thinks that you are doing this as a partisan attack on HD DVD. I suspect that you are going to stall on the Blu-Ray version of this.

Are you going to prove me wrong, or just continue to stall? I suspect you could have the Blu-Ray version working in only a couple of days given the work you have already done here.

It's not fair that you attack only one format - if you are true to what you say you are, you would have already released a Blu-Ray version of this program by now...

Color me skeptical of your true motives at the moment.What more can I say? Strike issued (R4).

Everybody else - please get back on topic.

Regards

blizc

16th January 2007, 09:55

Warren

16th January 2007, 10:06

Is it cuz of the added stream for In-Movie Experience(IME)?

Yes BackupHDDVD doesn't properly handle movies with IME yet.

cyberpass

16th January 2007, 10:13

Is there anyway we can find the spec for the IME?

Warren

16th January 2007, 10:22

Not without signing a bunch of NDAs and paying $5000 to the DVD Consortium.

blutach

16th January 2007, 10:40

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

Regards

Warren

16th January 2007, 10:47

There are ways to get the raw frames out of IME movies for which graphedit filter graphs are posted in the sister threads to this one but they are not optimal for watching HD DVDs.

Nutrition24

16th January 2007, 12:08

Take a look at "Pre-recorded Video Book" - which is a different spec. Specifically chapter 3.

http://www.aacsla.com/specifications/specs091/AACS_Spec_Prerecorded_0.91.pdf

Yes, you're right, there indeed, the Title Key is used as is to decrypt the Content (C) as follows:
C = AES-128CBCD(Kt, Ce) so no talking about content key Kc.

I was referring to the HDDVD AACS prerecorded spec
http://www.aacsla.com/specifications/AACS_Spec_HD_DVD_and_DVD_Prerecorded_0_912.pdf
section 4.3.2 where the pack encryption is described. and where the content is encrypted/decrypted with a variant of the Title key.

But maybe it's only HL_PCK packs that are encrypted with a Kt variant (Kc) and so if such packs are encountered, they won't be decrypted correctly by backuphddvd.

HD Hell

16th January 2007, 13:44

With full respect, apologies to anyone who took that as a personal attack.

Now, doesn't anyone here have a Blu-Ray drive of any sort? Using it with the Power DVD software should allow the keys to be seen in the same way. It seems right that one should be able to back up one's Blu-Ray discs as well.

Let's get a head start until someone releases a mod'ed version of "backup".

He-Man

16th January 2007, 13:58

Now, doesn't anyone here have a Blu-Ray drive of any sort? Using it with the Power DVD software should allow the keys to be seen in the same way. It seems right that one should be able to back up one's Blu-Ray discs as well.

Let's get a head start until someone releases a mod'ed version of "backup".
Please keep posts about Blu-Ray in the "BackupBluRay" topic instead: http://forum.doom9.org/showthread.php?t=120672

romgohan

16th January 2007, 13:58

Maybe create somewhere a repository of different encountered packs, to widen our knowledge and help find troublesome ones?

jimfcarroll

16th January 2007, 16:42

Yes, you're right, there indeed, the Title Key is used as is to decrypt the Content (C) as follows:
C = AES-128CBCD(Kt, Ce) so no talking about content key Kc.

I was referring to the HDDVD AACS prerecorded spec
http://www.aacsla.com/specifications/AACS_Spec_HD_DVD_and_DVD_Prerecorded_0_912.pdf
section 4.3.2 where the pack encryption is described. and where the content is encrypted/decrypted with a variant of the Title key.

But maybe it's only HL_PCK packs that are encrypted with a Kt variant (Kc) and so if such packs are encountered, they won't be decrypted correctly by backuphddvd.

The relationship between "HD DVD and DVD Pre-recorded Book" spec and "Pre-recorded Video Book" spec is somewhat cloudy in my mind (though they reference each other). The later is much easier to read and seems to be written at a much higher level. Take a look at Chapter 4 which appears to be a technical sales pitch to various media conglomerates on how well protected their content will be (and, IMO, in the long run, they are right).

Unfortunately I don't have any of the requisite hardware, software, or content to experiment or I'd be digging in; all I can do is watch from the sidelines and read the publicly available specs and code.

jkenzie

16th January 2007, 17:03

I found the keys for Swordfish and Training Day and was able to decrypt them using BackupHDDVD but when played it's just a black screen with no sound. King Kong is fine and by fine I mean a jittery mess but at least that's what everyone is getting anyways. So what's up with these 2 Warner Brothers movies. Is it cuz of the added stream for In-Movie Experience(IME)?

No, It's because you didn't find the volume key. Or you found a Title key. Backuphddvd will backup the movie with any group of numbers inputed into the Keybd.cfg, but it will be garbage.

The_ByteMaster

16th January 2007, 19:30

No, It's because you didn't find the volume key. Or you found a Title key. Backuphddvd will backup the movie with any group of numbers inputed into the Keybd.cfg, but it will be garbage.

Would it be hard to modify BackupHDDVD so it will (optionally) check the Verify Media Record (see 3.2.5.4 AACS_Spec_Common_0.91)?

i.e. Bytes 4-19 of the MKB (MKBROM.AACS) = Dv and
[AES_128D(Km, Dv)]msb_64 == 0x0123456789ABCDEF

jimfcarroll

16th January 2007, 20:19

Would it be hard to modify BackupHDDVD so it will (optionally) check the Verify Media Record (see 3.2.5.4 AACS_Spec_Common_0.91)?

i.e. Bytes 4-19 of the MKB (MKBROM.AACS) = Dv and
[AES_128D(Km, Dv)]msb_64 == 0x0123456789ABCDEF

If that formula is correct, and my recollection of the spec is correct (I don't have it in front of me here), then it would be difficult since Km (I think) is the "media key" - which BackupHDDVD doesn't have and cannot get from what it does have (the Title Key and/or the Volume Unique key ). In fact, it's the reverse that happens in a normal player (the media key yields the Kvu and Kt).

Nutrition24

16th January 2007, 23:52

Would it be hard to modify BackupHDDVD so it will (optionally) check the Verify Media Record (see 3.2.5.4 AACS_Spec_Common_0.91)?

i.e. Bytes 4-19 of the MKB (MKBROM.AACS) = Dv and
[AES_128D(Km, Dv)]msb_64 == 0x0123456789ABCDEF

For this to work, we'll need to have the Km (Media key) itself, which we don't have. Using the Km, it's simply decrypting the Dv (Verification data from the MKB) and checking if the left part of the decrypted result is 0123456789ABCDEF.

The Volume ID and the Km (media key) are used to create the Kvu (Volume Unique key), but this step is not reversable (AESG)

But if the idea is to check the correctness of the Kvu, another possibility exists using the TKF (Title Key File). The last entry of this file is the TKF MAC:

This field stores the CMAC value of the data ranging from the 0th to
the 2463rd byte of the Title Key File. The key for the CMAC calculation is the Volume Unique Key
(Kvu).

tdent1138

17th January 2007, 03:41

Hi muslix64 - I'm one of those who thinks that you are doing this as a partisan attack on HD DVD. I suspect that you are going to stall on the Blu-Ray version of this.

Are you going to prove me wrong, or just continue to stall? I suspect you could have the Blu-Ray version working in only a couple of days given the work you have already done here.

It's not fair that you attack only one format - if you are true to what you say you are, you would have already released a Blu-Ray version of this program by now...

Color me skeptical of your true motives at the moment.

I'd be more likely to guess he works for the HD-DVD group in an effort to spur sales.

Thanks Muslix64.

It may be that we have to wait for a stand alone BR drive that can be accessed by an operating system before that get's worked around like HD DVD now is.

EDIT: If this is considered off-topic, I am sorry. I'll delete if requested.

trueimage

17th January 2007, 05:00

anyone put together a howto yet? i have training day, but I didn't see the key posted here, so I'll try to find it myself...

jokin

17th January 2007, 05:12

Search the memory for "00 20 00 00 00 3F 00 00 00 80 00 00 00" in the memory dump of WinDVD the key should be right after that.

Also the key is already in this forum @ http://forum.doom9.org/showthread.php?t=120611

The_ByteMaster

17th January 2007, 05:50

The Volume ID and the Km (media key) are used to create the Kvu (Volume Unique key), but this step is not reversable (AESG)

But if the idea is to check the correctness of the Kvu, another possibility exists using the TKF (Title Key File). The last entry of this file is the TKF MAC:

This field stores the CMAC value of the data ranging from the 0th to
the 2463rd byte of the Title Key File. The key for the CMAC calculation is the Volume Unique Key
(Kvu).

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/

firewan

17th January 2007, 08:17

Backuphddvd can't handle another HDDVD authoring format-----for Standard Content Authoring.

"Standard Content Authoring DISC" have a VTKF.AACS file in AACS folder(Not a VTKF000.AACS).Backuphddvd can't handle this.

BTW,the DISC without a VPLST000.XPL file, What's a key word by search in the memory dump of WinDVD?

Nomadic

17th January 2007, 09:41

Please test this (http://rapidshare.com/files/12071837/BackupHDDVD-GUI.zip) version BackupHDDVD with simple GUI :)

hajj_3

17th January 2007, 10:31

nomadic, please put up some other mirrors of it like sendspace.com etc etc.

rapidshare is pants and it will prob get deleted.

Nomadic

17th January 2007, 10:43

Mirror (http://www.sendspace.com/file/0722ye)

mustang3

17th January 2007, 10:48

dude im testing it out right now, gui is working nicely. :D
Thnx!

could there be a status bar, on how much % it has done? but so far its going good.

kenwatanabe

17th January 2007, 11:09

just tried this and it appeared to work.

1. copy the content of the hddvd to a folder on the harddisk
2. use the subst command to map this folder to a drive letter
3. run backuphddvd on this mapped drive letter as the source

The idea is perhaps to have copies of various hddvds "waiting" on the harddrive until keys are available. Also a batch file can decrypt multiple (mapped) drives in one shot.

jokin

17th January 2007, 13:06

I converted this to an EXE and made an Icon for it. Seems to work great.
Mirror for EXE Version (http://www.sendspace.com/file/ze65dy)

He-Man

17th January 2007, 13:27

Please test this (http://rapidshare.com/files/12071837/BackupHDDVD-GUI.zip) version BackupHDDVD with simple GUI :)
Nice work.
When browsing for KEYDB.cfg, I think it should be set up to only look for "*.cfg" as default in "Files of Type" instead of "All Files".

rogerpe

17th January 2007, 13:46

One more mirror (http://www.wikiupload.com/download_page.php?id=54697) for the .exe

Mistar Muffin

17th January 2007, 15:26

Nutrition24

17th January 2007, 15:45

Nomadic, do you think you could post the source? I was about 75% done with a basic GUI myself for the version with online key retrieval. Yours looks great and would save time. Please share! Thanks and great work.

If you unzip the BackupHDDVD-GUI.jar file, you'll find the .class files and the .java files as well. (Or use jar xvf BackupHDDVD-GUI.jar if you have the jdk installed instead of the jre)

hajj_3

17th January 2007, 19:19

the GUI .exe version of BackupHDDVD runs nicely. im using vista x64 ultimate with java 1.6 x64. dont have a hd-dvd drive yet to test it properly tho.

please provide the source code for it so we can keep improving it collectively. cant believe we finally have an exe with a GUI of this great program, fantastic work!!! any improvements such as fixing IME should be made to this new .exe GUI version (assuming creator provides us with sourcecode) this way we wont have GUI and command line versions. once we've added all the necessary features and fixed bugs we can work on a c++ version so that users dont have to install java to run it.

Nomadic

17th January 2007, 19:44

as said Nutrition24 - source zip'ed in jar
but soon new version out ;)

Mistar Muffin

17th January 2007, 20:25

******, I knew I should have looked closer. I'll wait for the new version to make any mods on the HDKeys.com build.

melakai

17th January 2007, 21:17

given the rapid development of this tool, maybe it's time to stick this in source control (i.e. sourceforge)

2bigkings

17th January 2007, 21:54

i was able to rip mission impossible 2 [eu] but there's only english language. i can't choose other languages.
How can i rip a other language (like german)?
anyone also have this problem? but the volume key seems to be correct.

regards

NghtShd

17th January 2007, 22:20

I'm in the process of porting BackupHDDVD to C# (and if that works out then maybe C++), but not having an HD-DVD drive I don't have any encrypted files to test. I'm not sure if it would be OK to ask for a VTKF000.AACS file so I looked at the specs and made my own based on the posted Serenity keys.

What I would like is if someone could tell me whether the following keys are the encrypted Serenity title keys and if not could you post them? If you open VTKF000.AACS with a hex editor the 16 bytes starting at offset 132 (0x84) should be the first key. The second key should be 36 bytes from the start of the first and so on. Even getting just the first encrypted key would be great.

Edit:
Just wanted to add that when the app is ready for release source code will be releases as well.

Assuming my crypto translation is correct, I believe the following are the keys, but its quite possible I've not done the encryption correctly.

Encrypted Title Keys

01 = 80316BF135FFA74C08182D30D874BC6A
02 = DD2704D0783CECDFE14265B3B923AD33
03 = BF82FE9CB8BE988ABB6C3FBD0790C20A
04 = 02982C6AF396EA2F59B5A00BC80188A6
05 = 70992BB480F33349318AAEE5F091ABC6
06 = C793FAF1CE708DF61BE6D7D4B38B4D20
07 = D57516650AFDA7A17C24DD17BAE50DDB
08 = 6CA32B401277EE7E651DECBF72867A53
09 = EC1EAF02DE3E72C618462328853184BD
10 = 3EBAAB244BC47B43281BF27A04D88528
11 = 0BDB4CF03F89075EFCCC119583B1893A

Decrypted Title Keys

01 = 31325529846E19E90D88F414DA7D1661
02 = EF21329F7D838D9A7056882DBF665CD5
03 = 46BE356597AD71BFFADEDA14FE335B64
04 = 8906E3E8B05EEC17E594E98D42C913FE
05 = 0F998F1C0C7FEB30381C01F135FBE8E9
06 = 97895F12C018845C9CDCE95DFF4101DF
07 = 6C005DA9DAA97E168129753319D748A1
08 = 0608D2628A9FE952398B0FB432BDB6B1
09 = A24471CC766C6E7F7F56DB560CCD31E5
10 = 6EC977757A9E8AC378CC680770874E33
11 = 55962EA8084BF5135CB2ED5A5E795233

generalnewbie

17th January 2007, 22:43

App seems to run perfectly find i tested both the .jar and the EXE

If anyone is wondering how to run .jar extension files its really not hard. You just need to download the java binaries if your running windows. I downloaded Java Run Time for Windows Multilanguage (http://download.java.net/download/jdk6/6u1/promoted/b02/binaries/jdk-6u1-ea-bin-b02-windows-i586-p-12_jan_2007.exe)
Then you need to open the jar file in a Command Prompt and run using javaw -jar name_of_jar_file
Example
javaw -jar BackupHDDVD-GUI.jar

noclip

17th January 2007, 22:44

There is still a long list of modifications that need to be made to the BackupHDDVD before multi-core support is anywhere near a top priority.

Proper handling of PCKs and ability to deal with IME are the major ones.

He-Man

17th January 2007, 23:06

If anyone is wondering how to run .jar extension files its really not hard. You just need to download the java binaries if your running windows. I downloaded Java Run Time for Windows Multilanguage (http://download.java.net/download/jdk6/6u1/promoted/b02/binaries/jdk-6u1-ea-bin-b02-windows-i586-p-12_jan_2007.exe)
Then you need to open the jar file in a Command Prompt and run using javaw -jar name_of_jar_file
Example
javaw -jar BackupHDDVD-GUI.jar
I just double-clicked on BackupHDDVD-GUI.jar and it opened like it was an .exe file. Doesn't this method work just as well as opening it from a command promt?

zeroprobe

17th January 2007, 23:19

someone help nightshd out with the encryped keys.

noclip

17th January 2007, 23:51

Meh, here's a logo:

http://img405.imageshack.us/img405/9972/bhdvdjs6.png

Small logo (for icon, etc.):
http://img444.imageshack.us/img444/3640/bhsmallbp5.png

hajj_3

18th January 2007, 00:12

nice logo:) hope its in the next version:)!

Mistar Muffin

18th January 2007, 00:15

Meh, here's a logo:

http://img405.imageshack.us/img405/9972/bhdvdjs6.png

Great logo, but a couple of things:

1) Trying to keep things legal, I don't think basing off the existing HD DVD logo is in fact legal. I do beileve there is some copyright on that since it is not parody etc.

2) It looks great, what font did you use to match the DVD font? I looked at one point for a font but could not find one.

Not trying to be a buzzkill, just thought I would mention that!

Bye.

Nutrition24

18th January 2007, 01:24

someone help nightshd out with the encryped keys.

I adapted BackupHDDVD-GUI to check the correctness of the Volume Unique Key using CMAC algorithm, but since I don't have a title key file myself, I'd also like to receive some sort of valid title key file to test the changes against.

(If anyone else want to try out ahead: it's at http://www.sendspace.com/file/slqvdw)

tonyp12

18th January 2007, 01:31

I but since I don't have a title key file myself, I'd also like to receive some sort of valid title key file to test the changes against.

a few in earlier post

http://forum.doom9.org/showpost.php?p=933495&postcount=638

noclip

18th January 2007, 01:45

I set up a project at Sourceforge for BackupHDDVD. I should know if it's approved by Friday.

Ábudos

18th January 2007, 04:55

Assuming my crypto translation is correct, I believe the following are the keys, but its quite possible I've not done the encryption correctly.

Encrypted Title Keys

01 = 80316BF135FFA74C08182D30D874BC6A
02 = DD2704D0783CECDFE14265B3B923AD33
03 = BF82FE9CB8BE988ABB6C3FBD0790C20A
04 = 02982C6AF396EA2F59B5A00BC80188A6
05 = 70992BB480F33349318AAEE5F091ABC6
06 = C793FAF1CE708DF61BE6D7D4B38B4D20
07 = D57516650AFDA7A17C24DD17BAE50DDB
08 = 6CA32B401277EE7E651DECBF72867A53
09 = EC1EAF02DE3E72C618462328853184BD
10 = 3EBAAB244BC47B43281BF27A04D88528
11 = 0BDB4CF03F89075EFCCC119583B1893A

Here's what I found:

01 = D32238519C4DA3BD395348B3E50B274E
02 = 92946B88A06967661B8491B18E488BF7
03 = 9810826ECB07414312CBA26245823942
04 = DD96EF42FF22B228EE9284DCB6180C43
05 = 2D81BC9FBB80FB5D25ED53616C9A0E79
06 = 9F269E568097C7CCD83BAD3511D82BA7
07 = 5E465FF6144864A0D23AE3CB776A15BC
08 = 8902AC657C91297DB03C21285FDD5B5D
09 = 7418D2A78417D093665321BED1790EF1
10 = 8DA3FBCC6E585DF13C28418EB2D10283
11 = FC087EBBC632EFBE4F48158009CF4E7D

@ 1-core it took a little bit over 2 hours to backup king kong from 1 hdd to another hdd.. anyone out there willing to do a multi-threaded backuphddvd? badly needed..

Multi-threading this app wouldn't do a whole lot to help. What's slowing it down is 1: the maximum bitrate of the USB connection / drive read speed, and 2: The fact that this is a Java program using its crappy crypto functions.

2bigkings

18th January 2007, 06:19

Here's what I found:

01 = D32238519C4DA3BD395348B3E50B274E
02 = 92946B88A06967661B8491B18E488BF7
03 = 9810826ECB07414312CBA26245823942
04 = DD96EF42FF22B228EE9284DCB6180C43
05 = 2D81BC9FBB80FB5D25ED53616C9A0E79
06 = 9F269E568097C7CCD83BAD3511D82BA7
07 = 5E465FF6144864A0D23AE3CB776A15BC
08 = 8902AC657C91297DB03C21285FDD5B5D
09 = 7418D2A78417D093665321BED1790EF1
10 = 8DA3FBCC6E585DF13C28418EB2D10283
11 = FC087EBBC632EFBE4F48158009CF4E7D

Multi-threading this app wouldn't do a whole lot to help. What's slowing it down is 1: the maximum bitrate of the USB connection / drive read speed, and 2: The fact that this a Java program using its crappy crypto functions.

You should decrypt the movie directly from the HDD, my quality of the movie is better now and it's faster!

jokin

18th January 2007, 06:29

I seem to have no trouble with speed. Mine takes ~1hr with a P4 3.4 2GB of RAM. I dont think thats too bad for 20+ GB

Janvitos

18th January 2007, 06:33

Just to let you people know, i've started working on Blueray keys and have created a new thread for those interested.
Yep, i bought a 800$ Blueray burner for the sake of the community :D

hajj_3

18th January 2007, 06:51

bloody hell Janvitos!!!

$800 is a hell of alot of money, which burner did you buy? you should have waited for the new combo writer from lg, it reads hd-dvd's and burns/reads blue-ray @ 4x i think.

let us know the progress with decrypting blu-ray.

woah!

18th January 2007, 08:26

You should decrypt the movie directly from the HDD, my quality of the movie is better now and it's faster!

that makes no sense what so ever.. how can the image be worse just because the ripping to HD from the disc is slower??? its data it doesnt change unless its told to like in transcoding eg: dvdshrink where it re-adjusts bitrate.

so your saying its quicker to copy the encrpyted files to the HDD which will take a while anyways for 18-20gig and then run it again from there to another HDD through backuphddvd and this will be quicker and give you better Q??

Nomadic

18th January 2007, 08:36

Who can share small hddvd iso working with BackupHDDVD for debug development??

firewan

18th January 2007, 09:06

Who can share small hddvd iso working with BackupHDDVD for debug development??

A small HDDVD iso with AACS? BackupHDDVD need a VTKF000.AACS file to work

blutach

18th January 2007, 09:28

Be careful please about sharing EVO files (or other copyrighted video files) or mentioning the sharing of them here.

We allowed publication of title keys on the basis that the people who could use them actually had the disks anyway. We do not make a presumption that someone has rented a disk and is using a published key.

Asking for the video content itself (or a part thereof) is entirely another matter - it needs little thought to figure out you don't have the DVD.

Sharing files are best done via PM and certainly not in open forum and we at Doom9 do not condone the sharing of files. Please refer to rule 6.

Regards

madshi

18th January 2007, 10:16

Touffi

18th January 2007, 10:36

Hi everybody,

The following is based on what I read in the docs founds at : http://www.aacsla.com/specifications/

And specially this one :
http://www.aacsla.com/specifications/specs091/AACS_Spec_Prerecorded_0.91.pdf

I have a few questions about Sequences Keys, or Volume Unique Keys Variants (chapter 4). Well, first my english is not good enough for me to understand what exactly they are used for and how they work (first question) although I undestand that it's a revocation-scheme protection mecanism similar to the MKB.

Second question, BackupHDDVD seems to work with Volume Unique Keys only, so what are the Variants used for ? Section 3.5 states that Title Key is computed with this formula : Kt = AES-128D(Ku, Kte). Kte being the encrypted Title Key and Ku "one of the volume unique keys defined in Section 3.3". Section 3.3 explains how to compute Volume Unique Keys (Kvu) and Volume Unique Keys Variants (Kvvu). So that would mean that we can feed BackupHDDVD either with a Kvu or au Kvvu and that you only need one of them to decrypt Title Keys ?

Well, I'm confused :)

Nomadic

18th January 2007, 11:56

New version BackupHDDVD-GUI (http://rapidshare.com/files/12229227/BackupHDDVD-GUI.zip)
changes:
- Decrypting file in separate thread (as yet one!)
- Progress bar while decrypting
- Minor fixes

hajj_3

18th January 2007, 12:04

nomadic, what does this mean??

" Decrypting file in separate thread (as yet one!)"

thanks.

Nomadic

18th January 2007, 12:07

that not to freeze an interface in the process of decoding

jokin

18th January 2007, 12:11

Sendspace Mirror for updated GUI (http://www.sendspace.com/file/045l4k)

Also,

1. Maybe you can have it list files and allow one to select certain files to decrypt. (File mode and a disc mode)

2. Make a button to stop or pause decryption?

Thanks for the great work.

Obveron

18th January 2007, 13:55

I don't have a HDCP compatible graphics card, so I'm thinking about using BackupHDDVD to be able to play my HD DVD discs. Now my question is:

Can I find out the keys of my own HD DVD discs by checking WinDVD memory without having a HDCP compatible graphics card? Or won't WinDVD have the keys in memory if I don't have a HDCP compatible graphics card?

Thanks!I would also like to know the answer to this question.
From the following post from Muslix64, it seems that he was able to retrieve keys without a HDCP capable video card... But I can't be sure. But when I realized the 2 software players on windows don't allowed me to play the movie at all, because my video card is not HDCP compliant and because I have a HD monitor plugged with DVI interface, I started to get mad... This is not what we can call "fair use"! So I decide to decrypt that movie.

He-Man

18th January 2007, 14:05

Second question, BackupHDDVD seems to work with Volume Unique Keys only, so what are the Variants used for ? Section 3.5 states that Title Key is computed with this formula : Kt = AES-128D(Ku, Kte). Kte being the encrypted Title Key and Ku "one of the volume unique keys defined in Section 3.3". Section 3.3 explains how to compute Volume Unique Keys (Kvu) and Volume Unique Keys Variants (Kvvu). So that would mean that we can feed BackupHDDVD either with a Kvu or au Kvvu and that you only need one of them to decrypt Title Keys ?

Well, I'm confused :)
Here's an article discussing Volume Variant Unique Keys, maybe this will be to some help?
AACS: Sequence Keys and Tracing: http://www.freedom-to-tinker.com/?p=1110

Touffi

18th January 2007, 14:30

Here's an article discussing Volume Variant Unique Keys, maybe this will be to some help?
AACS: Sequence Keys and Tracing: http://www.freedom-to-tinker.com/?p=1110
Great reading :thanks:

I went to this site yesterday while googling but this post hadn't been published yet ;)

The_ByteMaster

18th January 2007, 16:54

Here's an article discussing Volume Variant Unique Keys, maybe this will be to some help?
AACS: Sequence Keys and Tracing: http://www.freedom-to-tinker.com/?p=1110

From the article:
"The effect of this is that the movie will look slightly different, depending on which player was used to decrypt it."

So depending on your player, Han will shoot first, or not?

I'm only kidding of course, it stands to reason the differences wouldn't be noticable to the human eye. This will just result in a cat-and-mouse game between Fair Use people who compromise players (nab required decryption keys from memory) and the content providers. It doesn't really matter if you only get updates say a couple of times per year, as long as those updates work with all currently available discs.

Once a future version of BackupHDDVD encounters a P-EVOB which needs SKB processing it perhaps will just consult the file SKBDB.cfg to get the required keys.

For now the BackupHDDVD modders can just check for the presence of AACS/SKB.AACS and AACS/SKF.AACS: "no SKBF and no SKF shall be present on a HD DVD-Video ROM medium which contains no P-EVOB with Sequence Key Sections."

jokin

18th January 2007, 16:55

With the newest version of the GUI I get this error on 4 discs.
Could not find keyFile "O:\aacs\VTKF.AACS". Aborting...

NghtShd

18th January 2007, 17:18

Here's what I found:

01 = D32238519C4DA3BD395348B3E50B274E
02 = 92946B88A06967661B8491B18E488BF7
03 = 9810826ECB07414312CBA26245823942
04 = DD96EF42FF22B228EE9284DCB6180C43
05 = 2D81BC9FBB80FB5D25ED53616C9A0E79
06 = 9F269E568097C7CCD83BAD3511D82BA7
07 = 5E465FF6144864A0D23AE3CB776A15BC
08 = 8902AC657C91297DB03C21285FDD5B5D
09 = 7418D2A78417D093665321BED1790EF1
10 = 8DA3FBCC6E585DF13C28418EB2D10283
11 = FC087EBBC632EFBE4F48158009CF4E7D

Thanks very much, Ábudos. Setting up the decryption in C# is a bit different than in Java.

Update:
Somehow I had put the wrong volume key in my test CFG file. Everything looks good now that I fixed that. Thanks again for your help.

muslix64

18th January 2007, 18:41

By now, some people may wonder "Why did he put a date field in the keydb.cfg?"
Even if this field seems useless for now, it will be very usefull in the future. When revocation and, may be other countermesures will kick in, it will be usefull.
Movies manufatured in a certain time frame may have special features, we never know...

So I strongly suggest you to use the date field now to prepare for the future...

evdberg

18th January 2007, 18:44

Hi Musli-X64 ... I wonder more why you write 0x7F to the MSB of VOBU_EndAddress? This value is correct in the original files, so why change it? I know you did some experimenting and it *seemed* to fix the 'nav chain problem', as you call it, but it also may cause new problems (see reported problems on this forum).

muslix64

18th January 2007, 18:50

You are right. Try to play a evo file with PowerDVD without that fix. It do a lot of frame skipping. This is a PowerDVD problem, so this fix is just a workaround a player problem.

Coderjoe

18th January 2007, 18:53

By now, some people may wonder "Why did he put a date field in the keydb.cfg?"
Even if this field seems useless for now, it will be very usefull in the future. When revocation and, may be other countermesures will kick in, it will be usefull.

I don't really think revocation matters. Kvu and Kt are both after the revocation steps (from the version of the specs I have read, anyway). The only place the revocation currently matters is in WinDVD or PowerDVD, where everyone is currently snatching the keys from.

muslix64

18th January 2007, 18:57

But, may be other countermesures we don't even think of, will kick in sooner or later. It's always usefull to know the manufaturing date of a movie.

evdberg

18th January 2007, 19:17

This is a PowerDVD problem, so this fix is just a workaround a player problem.
I assume you mean it is a specific problem of PowerDVD 6.5? Did you also try V7.2? Or do you have the same problem as I do that V7.2 is bitching that your system is not qualified to play HD-DVD?

hajj_3

18th January 2007, 19:22

muslix64, what do you think about the GUI version of 1.00. any ideas how the IME can be fixed?? you havent posted in a few days, there has been alot of development since then.

muslix64

18th January 2007, 20:40

@evdberg
Yes it's a bug with 6.5. I don't have V7.2. may be it work well with 7.2

@hajj_3
I did not try the GUI version yet. I'm not working on IME bug. I think you have to remove some sub streams in the stream, but I leave that to demuxing experts. I'm more into crypto than media format stuff.

This is a player bug, not a BackupHDDVD bug. The decryption works fine.

Did someone was able to play a movie with IME so far?

noclip

18th January 2007, 20:42

Muslix: Do you have a SourceForge account? PM me your username and I will add you as a developer.

muslix64

18th January 2007, 20:47

Thanks noclip. But I leave that to serious coders. I'm good at proof of concept software, not production grade software.

Coderjoe

18th January 2007, 21:37

noclip: developer on what project?

btw, I am getting more and more tempted to get a drive and a movie or two and start poking around...

He-Man

18th January 2007, 21:47

noclip: developer on what project?
BackupHDDVD on SourceForge http://forum.doom9.org/showthread.php?t=120896

DanITman

19th January 2007, 04:05

I have an HD-DVD that I cannot find the VK for. I'm starting to think it doesn't even have one or the disc might not be encrypted.

Here is the disc: Musicares person of the year tribute honoring James Taylor

http://www.buy.com/retail/product.asp?sku=203172501&loc=107&sp=1&queryType=video_vhs&

I'm more interested in hunting down keys then I am actually backing this thing up. I'm just practicing finding keys and this is the only one that has stumped me. Could it be possible that it doesn't have a VK? Would anyone be willing to take a look at the dumped memory and give me a hint to it's location?

Thanks

jokin

19th January 2007, 04:44

NghtShd

19th January 2007, 07:27

Please read the following before downloading.

HDDVDBackupG is C# port of HDDVDBackup with a GUI interface.

I'm pretty sure title key decription works properly. It may not work on EVO files however. Since I don't have encrytped EVO files and a corresponding VTKF000.AACS to test with I couldn't do much more than guess at the crypto setup. If you feel it would be a waste of your time if the app fails to decrypt your files then don't bother.

The C# source code will be released, but I'd like to get some feedback regarding EVO decription while I do some code clean up and maybe add a bit more error control. I'll also look at more informative output a progress bar and multithreading if I have time.

http://users.adelphia.net/~m.crane/bin/HDDVDBackup.rar

Below is the main decryption setup. If any crytpo people see any obvious errors please let me know.

class AESFunc
{
static byte[] AESCBCConstantIV = { 0x0B, 0xA0, 0xF8, 0xDD, 0xFE, 0xA6, 0x1F, 0xB3, 0xD8, 0xDF, 0x9F, 0x56, 0x6A, 0x05, 0x0F, 0x78 };

public static byte[] AESG(byte[] x1, byte[] x2)
{

RijndaelManaged AES = new RijndaelManaged();
AES.Mode = CipherMode.ECB;
AES.Padding = PaddingMode.None;
AES.KeySize = 128;
//AES.BlockSize = 128;
ICryptoTransform decryptor = AES.CreateDecryptor(x1, x1);
MemoryStream memoryStream = new MemoryStream(x2);
CryptoStream cryptoStream = new CryptoStream(memoryStream, decryptor, CryptoStreamMode.Read);

byte[] plainTextBytes = new byte[x2.Length];

// Start decrypting.
int decryptedByteCount = cryptoStream.Read(plainTextBytes, 0, plainTextBytes.Length);

return Utils.xor(plainTextBytes, x2);
}

public static byte[] decryptPack(byte[] pack, byte[] contentKey)
{
RijndaelManaged AES = new RijndaelManaged();
AES.Mode = CipherMode.CBC;
AES.Padding = PaddingMode.None;
AES.KeySize = 128;
//AES.BlockSize = 128;
ICryptoTransform decryptor = AES.CreateDecryptor(contentKey, AESCBCConstantIV);
MemoryStream memoryStream = new MemoryStream(pack);
CryptoStream cryptoStream = new CryptoStream(memoryStream, decryptor, CryptoStreamMode.Read);

byte[] plainTextBytes = new byte[pack.Length];

// Start decrypting.
int decryptedByteCount = cryptoStream.Read(pack, 0, plainTextBytes.Length);

return pack;
}
}

arnezami

19th January 2007, 11:18

I adapted BackupHDDVD-GUI to check the correctness of the Volume Unique Key using CMAC algorithm, but since I don't have a title key file myself, I'd also like to receive some sort of valid title key file to test the changes against.

(If anyone else want to try out ahead: it's at http://www.sendspace.com/file/slqvdw)

This is a great feature. Has this been tested yet by anyone? Maybe change a key slightly and see if it is detected?

New version BackupHDDVD-GUI (http://rapidshare.com/files/12229227/BackupHDDVD-GUI.zip)
changes:
- Decrypting file in separate thread (as yet one!)
- Progress bar while decrypting
- Minor fixes

Looking at your source Nutrition24's cmac check still has to be added to your program. Am I right? Or is it already in the exe?

hajj_3

19th January 2007, 13:52

its prob best to use the c#.net version when thats fully working instead of just a .exe, this way you can have access to the keys.cfg file. we could create an installer for it to install it to $:\Programs Files\BackupHDDVDgui.

melakai

19th January 2007, 15:43

The C# source code will be released, but I'd like to get some feedback regarding EVO decription while I do some code clean up and maybe add a bit more error control. I'll also look at more informative output a progress bar and multithreading if I have time.

Don't worry about trying to stuff all these features in right away. It might be better to get the source out so others can help rapidly develop that don't do Java.

I don't have my HDDVD drive hooked up at home to test, but I'll give it a shot tonight if no one beats me to the punch.

kad77

19th January 2007, 15:49

I want to clear a few things up about BackupHDDVD performance for the non-technical:

1. Software can be structured to be multi-threaded (not 'multi-core'), which would utilize multiple processors and/or cores.

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

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

4. Most importantly: as others have stated, the encrypted AACS data streams still need to be handled properly! Guesswork hacks remain in muslix64's code that don't follow AACS spec... When these unknowns are addressed, then you'll see worthwhile optimized versions. In the meantime, you are likely archiving 'corrupt' backups that will need to be redumped in the future.

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

Remember, this entire process is still in the testing/development stage. BackupHDDVD is not a production utility ready for prime time quite yet. GUI development is a nice coat of paint, but the core algorithm needs to be fixed first!

Thanks for firing the first shot muslix!

noclip

19th January 2007, 15:53

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

Example format:
<?xml?>
<keyset>
<description>Movie name</description>
<cmac>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</cmac>
<key type="volume">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</key>
<key type="title">
<title id="3">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</title>
<title id="10">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</title>
</key>
</keyset>
<keyset>
<description>A different movie name</description>
<cmac>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</cmac>
<key type="volume">XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</key>
</keyset>

Nomadic

19th January 2007, 15:55

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

19th January 2007, 16:05

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

19th January 2007, 16:24

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

19th January 2007, 16:48

He-Man

19th January 2007, 16:57

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

19th January 2007, 17:05

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

19th January 2007, 18:04

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

19th January 2007, 18:14

heman

19th January 2007, 18:19

NghtShd

19th January 2007, 18:50

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

19th January 2007, 18:58

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

19th January 2007, 19:01

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

19th January 2007, 19:17

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

19th January 2007, 22:59

kad77

19th January 2007, 23:27

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

19th January 2007, 23:59

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

20th January 2007, 00:01

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

20th January 2007, 00:31

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

20th January 2007, 00:32

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

20th January 2007, 00:37

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

20th January 2007, 00:43

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

20th January 2007, 00:43

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

20th January 2007, 01:50

He-Man

20th January 2007, 02:16

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

20th January 2007, 02:20

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

20th January 2007, 02:42

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

Regards

sensite

20th January 2007, 03:09

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

20th January 2007, 05:36

kad77

20th January 2007, 05:58

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

20th January 2007, 06:04

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

20th January 2007, 06:29

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

20th January 2007, 09:21

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

20th January 2007, 10:00

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

20th January 2007, 12:51

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

20th January 2007, 13:19

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

20th January 2007, 13:28

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

20th January 2007, 16:18

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

20th January 2007, 16:26

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

20th January 2007, 17:44

@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

20th January 2007, 18:13

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

2bigkings

20th January 2007, 18:20

eeknay is right, bd+ is not out yet.

muslix64

20th January 2007, 18:28

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

The_ByteMaster

20th January 2007, 18:31

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

20th January 2007, 18:32

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

cwm9

20th January 2007, 18:40

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.