BackupHDDVD, a tool to decrypt AACS protected movies

[Lord_KiRon]

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]

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

enjoy,
Mtz

[calinb]

Originally Posted by CAFxX

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

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]

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]

Originally Posted by NghtShd

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.

Originally Posted by NghtShd

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?)

Originally Posted by NghtShd

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]

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]

My take on the possible locations:

Originally Posted by calinb

1. Main DRAM memory. (The obvious place).

Cyberlink denies it but they have a pretty big vested interest. This is very likely.

Originally Posted by calinb

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.

Originally Posted by calinb

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.

Originally Posted by calinb

4. CPU Registers (Ultimately and fleetingly, a certainty)

A breakpoint on the decryption routine would discover it here, this should be the top priority.

Originally Posted by calinb

5. FPU Registers (at 80 bits maximum, how likely?)

Can be safely assumed not to be the case.

Originally Posted by calinb

6. Swap files. (Disable virtual memory.

This should be pursued as a second priority after CPU registers.

Originally Posted by calinb

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]

Originally Posted by calinb

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]

(WRT: files/registry)

Originally Posted by noclip

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]

Originally Posted by calinb

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]

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]

Originally Posted by calinb

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?

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]

Originally Posted by DanITman

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]

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]

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

[Sy]

Originally Posted by Wookie Groomer

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

You speak from experience or you read that somewhere?

[rmtaibo]

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]

He He He...

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

[ridesideways]

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*