Got VolumeID without AACS authentication :)

[mb2696]

great work!!!!

i was able to confirm that this works.

[arnezami]

Originally Posted by Geremia

The volumeID patch is not something usefull, it's just a proof of concept, anyway if anyone interested, here it is (rechecksumed with great arnezami app)

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

Dump your own firmware, store a copy in safe place, apply the ppf on a copy of your firmware, flash it back with WinVUP.

If your drive fw is different from the fw the patch was build for (MC08), the patched firmware will have the sum and xors incorrect and will not be flashed, so it's quite safe.

to take a look at VolumeID:

plscsi.exe -v -x "AD 00 00 00 00 00 00 80 00 24 00 00" -i x24

For everybody who wants to apply this patch:

****** WARNING ******

Do NOT connect the patched drive to a xbox 360 that has been connected to the internet (from now on).

Do NOT use the patched drive in conjunction with a future version of WinDVD or PowerDVD.

****** WARNING ******

Why? Because this patch isn't stealthy (yet). This means its very easy for M$ or a different commercial software developer to detect that your drive is patched and can thus "call home".

Ignoring these warnings can cause your drive to be revoked.

You can patch your drive and do all kinds of fun stuff with it. But always re-flash it with your original firmware so no patched fw can be detected.

Regards,

arnezami

[awhitehead]

Originally Posted by arnezami

This means its very easy for M$ or a different commercial software developer to detect that your drive is patched and can thus "call home".

Ignoring these warnings can cause your drive to be revoked.

Question to arnezami and Geremia:


I realize that in case of Xbox 360, most likely result is that your Xbox will be revoked from Xbox Live, and you will never be able to play on line with that Xbox Live account and system.

But from the point of view of the people that have their drives hooked up to their Home Theater PCs, what is the likely result of having a modded firmware ?

In other words, are we expecting that specific drives will be revoked, or are we expecting ALL SD-S802As revoked?

What would a revocation mean? In other words, if someone was to create a different version of the firmware, that causes the device to reply to inqueries as "NEC 1100a Rev S" instead of XwhatverJ that SD-S802As replies now, and flashes that the modified firmware in, would all of a sudden they be on the white list again? Or would they also need to modify/zero out some cryptograhic seeds inside the drive (I see the s-box tables, etc, and references to AES, but what are those used for? Do we care if they are correct if drive just gives out volume ID?)

I guess my question is: If the drive gets revoked, is it a paperweight brick at this point, or is it just an inconvinience?

We know that the difference in firmware between your specific SD-S802A and mine is in the area 4000-7FFF, that is not checksummed area of the firmware image. (I assume that we all run MC08 version of firmware for Toshiba SD-S802A)

Would a utility that "sanitizes" that part of the firmware dump, and sets the serial number of the drive to a random value be useful?

[arnezami]

Originally Posted by awhitehead

Question to arnezami and Geremia:


I realize that in case of Xbox 360, most likely result is that your Xbox will be revoked from Xbox Live, and you will never be able to play on line with that Xbox Live account and system.

But from the point of view of the people that have their drives hooked up to their Home Theater PCs, what is the likely result of having a modded firmware ?

In other words, are we expecting that specific drives will be revoked, or are we expecting ALL SD-S802As revoked?

What would a revocation mean? In other words, if someone was to create a different version of the firmware, that causes the device to reply to inqueries as "NEC 1100a Rev S" instead of XwhatverJ that SD-S802As replies now, and flashes that the modified firmware in, would all of a sudden they be on the white list again? Or would they also need to modify/zero out some cryptograhic seeds inside the drive (I see the s-box tables, etc, and references to AES, but what are those used for? Do we care if they are correct if drive just gives out volume ID?)

I guess my question is: If the drive gets revoked, is it a paperweight brick at this point, or is it just an inconvinience?

We know that the difference in firmware between your specific SD-S802A and mine is in the area 4000-7FFF, that is not checksummed area of the firmware image. (I assume that we all run MC08 version of firmware for Toshiba SD-S802A)

Would a utility that "sanitizes" that part of the firmware dump, and sets the serial number of the drive to a random value be useful?

You have some good questions and I will try to answer them.

First: the AACS LA can revoke a drive once it has been identified. Identification is simple: in order for a software player to retrieve the Volume ID it communicates with the drive first and checks the drive id. If the drive id is not revoked it continues and retrieves the Volume ID (and plays the content). If its on the DRL (Drive Revocation List as opposed to HRL) then it simply won't retrieve the Volume ID (although it could) and doesn't play the content. Since the drive is patched we can still retrieve the Volume ID. But we can't play the content with the AACS-controlled commercial Software Player. If we build our own player (or if the Software Player plays unencryped files from HDD) then we can still play the content. So its basicly an inconvenience.

A drive cannot fake its drive id (towards the Software Player) but (in theory) it might be possible to overwrite the unique parts of your revoked drive with one from an non-revoked drive: basicly creating a clone drive. This would un-revoke the drive (but this has never been done before there may be some hardware involved here too).

As for detecting whether a drive is patched: this is really easy (atm) for a Software Player/Xbox 360 to detect: simply read the fw parts concerning the Volume ID command and see if its not changed. If it is "call home" and tell the AACS LA which drive id has been compromised. Whether its legal for them to revoke your drive based on just this information is a different matter.

In short: revocation only has an effect on the "willingness" of a Software Player/Xbox 360 machine to retrieve the Volume ID (and thus playback). And its on a per-drive basis (not all drives of this type).

So its not the end of the world but its not fun either.

Regards,

arnezami

PS. I'm not talking an Xbox Live revocation. Thats a completely different matter (of which I don't know much about).
PPS. Theoretically they could flash a corrupt fw to your drive when they detect its patched (and that way crippling it), but I highly doubt that would be legal for them to do.

[Geremia]

I think that they can revoke any published device/host private key, i don't think a global thoshiba drive revoke will be plausible, and i personally do'nt think that powerdvd or windvd or xbox360, after payed the AACS consortium for a host certificate and after got money from the customers, is also obliged to investigate on customer drives to report AACS about a not secure drive, which is toshiba responsibility. A not secure drive is something between aacs and toshiba.

Anyway i also think that the drive must be used with the original firmware all the time.

P.S.
xboxlive lets play visible backuped games on live, since 1 year ago.

[awhitehead]

Originally Posted by arnezami

As for detecting whether a drive is patched: this is really easy (atm) for a Software Player/Xbox 360 to detect: simply read the fw parts concerning the Volume ID command and see if its not changed. If it is "call home" and tell the AACS LA which drive id has been compromised. Whether its legal for them to revoke your drive based on just this information is a different matter.

Come to think about it, I'd be more concerned about Windows Update downloading new drivers for the device. This is somewhat more plausible, since both Windows Update and Xbox 360 HD-DVD drive are Microsoft products, so in essence this keeps the problem internal to Microsoft. Dealing with Cyberlink, Intervideo and Nero to enable detection of patched firmware is less likely unless AACS LA gets involved - Not speaking for quality of Nero products, but we all know how good programmers at Intervideo and Cyberlink are, and how high are the chances of them mucking up the implementation of something Microsoft asks them to implement is.

So to summarize your answer regarding the drive plugged into a PC:

Currently if you use the drive to decrypt the contents of the HD-DVD disks onto the hard drive, and not with a HD-DVD playback application, you probably are OK to use patched firmware. However, since PowerDVD accesses the drive regardless of anything being present in it, it's probably a good idea to unplug the drive once you are done with decrypting content.

Either Windows Update (my theory), or updates to the playback application have potential of disabling the drive (An example that is close to home is that Toshiba flashes the firmware of NEC HD-DVD drive in HD-A1 standalone unit with each firmware update. So upcoming Dashboard/HD-DVD update for Xbox is capable of doing the same thing).

Biggest problem that AACS LA can cause onto people, is either outlawing HD-DVD playback software on PCs outright (since it can be used to discover device keys or processing keys, which in turn allow one to obtain the title keys) or to mandate that all the AACS licensed players must check for presence of tampered firmware for playback from the drive, combined with forcing vendors to remove the "playback from folder on the hard drive" feature from software that does have it (PowerDVD and Nero?).


So with the modification to the firmware we still need:

• Free playback application, that is capable of playing back unencrypted EVO files from the hard drive.
• Program that is capable of obtaining VUKs from the Volume ID and device key.
• Means of continuing to get device keys.

Based on my understanding, the biggest problem ffmpeg people have right now with HD-DVD support, is decoding of Dolby Digital Plus audio, which is proprietary and not documented. EVO demuxing and subtitle decoding is implemented in the current CVS version. Once support for the current audio codecs is reverse engineered, there will be a free playback application (Pretty much every player that uses ffmpeg will have support the moment they refresh their ffmpeg source and rebuild).

AACSkeys.exe is capable of obtaining VUKs, however the keys it uses are hardcoded in the source code, so every time keys change it will require a rebuild. Potentially it can benefit from using a companion .ini file, that would contain the necessary keys.

Lastly we need new device keys, especially in view of the new wave of the HD-DVDs coming out (I've ordered a bunch of new HD-DVDs from Amazon.fr - Fox Pathe and Studio Canal second wave titles, so expect an update as to what the new changes are (new MKB version?) in a short time).

Some suggestions for devices to attack:

• Xbox 360 HD-DVD playback software. Some reports showed that the HD-DVD drive will not function with Xbox until the companion software is run, however once it is run, that particular HD-DVD drive will work on any Xbox. This suggests that the 10 meg file on the companion CD contains the playback application, that gets flashes into the flash inside the actual drive case (inside the HD-DVD drive case there is a controller board that has a USB hub, USB to IDE adapter, and what looks like 2gigabit (256 megabytes) of persistent storage).
• Stand-alone players, potentially Sony or Samsung based onces (some run VxWorks based operating system, and ARM based. I believe that debuggers that are OS (and not only architecture) specfic exist for those.
• First generation Toshiba HD-DVD stand-alone players. Those run Linux, and although some of the internal files are encrypted, some kernel modules are left unencrypted on easily accessible flash. There is a thread in hardware players section of doom9, that badly needs new input from people with Linux kernel programming clue.

We made great strides in making AACS irrelevant. It's not yet over, but thanks to all the people that contributed so far, we will prevail.

[arnezami]

Originally Posted by awhitehead

AACSkeys.exe is capable of obtaining VUKs, however the keys it uses are hardcoded in the source code, so every time keys change it will require a rebuild. Potentially it can benefit from using a companion .ini file, that would contain the necessary keys.

Yes. Extending aacskeys is on the top of my to-do list now .

Things like an ini file, device key support and BDAV support are what I plan to implement. Also outputting several more keys and proper error handling etc.

I wanted to do that earlier but this whole firmware project just got in between everything and I just couldn't leave it alone.

arnezami

[mrazzido]

great work guys! if i can help on BD msg me =)

[arnezami]

Concerning stealth:

I've been thinking about ways to make a volume id patch stealthy. There are basicly two things:

1. The dumping of mem/fw should not reveal the patched areas in the fw (it should look like the original)
2. The retrieval of the Volume ID should somehow be disguised

When it comes to the second part this may be a good idea:



First we make sure the drive knows some kind of password (we can choose ourselves). Using this password the drive encrypts the Volume ID and replaces Dn with this encrypted value. Since this Dn is supposed to be random the Software Player has no idea this is in fact an encrypted VID (and we would also be using 32 bit from the original Dn for "salting" which makes sure its different each time). The drive uses the AES algo (already available ) to do the encryption so we don't have to worry about that.

A program (like aacskeys) can be given the password which it will use to decrypt this Dn and retrieve the VID this way.

I think this is pretty solid.

[edit] Of course the first part is the hardest. I was thinking of "mirroring" the changed parts: a table of two addresses per row: the first address containing the places where changes have been made and the other address pointing to the orginal code (in unused space). The dump command(s) would reintegrate all this into the original firmware as output. This technique can also be used for other kinds of patches of course.

I'm not saying any of this is easy. Its just an idea.

Regards,

arnezami

[Geremia]

hehhe, it sounds cool, but personally i'm not afraid of such contermeasures.
I mean, why a software player could be afraid of a patched drive? it's not his business, it's a toshiba problem.
AACS spec are about crypto stuff, how to store keys, how to use them, how to press a disc, does not include drive firmware authenticity and patched drive reporting.
AACS, in my point of view, does not have the ability to get reports back, it's a one way process
If a drive it not secure, aacs can only revoke the toshiba certificates, but how many toshiba drivers are out here? 80%? Take in consideration that SD-H802A is 99% the same drive as xbox360 addon, so patchable in 5 minutes too.

Windvd8 have been forced to update, probably with a new certificate...the same update have to be done drive-side this time, and how?
New (sniffable/hackable) fw upgrade?
All toshiba drives to trashcan?

[arnezami]

Originally Posted by Geremia

hehhe, it sounds cool, but personally i'm not afraid of such contermeasures.
I mean, why a software player could be afraid of a patched drive? it's not his business, it's a toshiba problem.
AACS spec are about crypto stuff, how to store keys, how to use them, how to press a disc, does not include drive firmware authenticity and patched drive reporting.
AACS, in my point of view, does not have the ability to get reports back, it's a one way process
If a drive it not secure, aacs can only revoke the toshiba certificates, but how many toshiba drivers are out here? 80%? Take in consideration that SD-H802A is 99% the same drive as xbox360 addon, so patchable in 5 minutes too.

Windvd8 have been forced to update, probably with a new certificate...the same update have to be done drive-side this time, and how?
New (sniffable/hackable) fw upgrade?
All toshiba drives to trashcan?

You're probably right .

[arnezami]

Originally Posted by Geremia

member xt5 from xboxhacker provided a tool to automatically enable DF and dump any area space , much appreciated

http://www.xboxhacker.net/index.php?...44556#msg44556

to dump fw:

dump.exe driveletter firmware.bin 0x200000 0x100000

I can confirm this dump program is working! Great work xt5 .

It creates the exact same dump I already had of my original dump.

For those who want to use it: follow the instruction Geremia just gave here to dump the fw only.

[Geremia]

just a note to be exact:

the firmware is contained in the first half of the flash memory, the second half if blank (all FF), i'll be not surprised if it will be used to store host revocation list.

So, for only firmware dump:

dump.exe driveletter firmware.bin 0x200000 0x100000


but for a complete flash memory dump:

dump.exe driveletter allflashmem.bin 0x200000 0x200000

[generalnewbie]

Hey guys i've been reading this thread and well to me it's been a bit confusing. Maybe Geremia and arnezami can help clarify some of my questions.

First off The drive that you are messing with is the Toshiba SD-S802A or better known as the Xbox360 HD DVD Drive?

If i understand correctly you are patching the VolumeID of the HD DVD firmware? But what does patching the drive do exactly?

How would flashing my 360 HD DVD drive benefit me?

I know these might sound rather stupid but im just wanting some lamans terms.

[arnezami]

Originally Posted by generalnewbie

Hey guys i've been reading this thread and well to me it's been a bit confusing. Maybe Geremia and arnezami can help clarify some of my questions.

Sure.

Originally Posted by generalnewbie

First off The drive that you are messing with is the Toshiba SD-S802A or better known as the Xbox360 HD DVD Drive?

Yes.

Originally Posted by generalnewbie

If i understand correctly you are patching the VolumeID of the HD DVD firmware? But what does patching the drive do exactly?

We are patching the drive so when a disc is inserted it will give the Volume ID of that disc. Without the need of a special key (called a Host Private Key).

Originally Posted by generalnewbie

How would flashing my 360 HD DVD drive benefit me?

If in several weeks new discs are released this may be one of the few ways to get the Volume ID which is needed (among another Key called the Processing Key) to decrypt/backup your discs. But you don't need it now.

Originally Posted by generalnewbie

I know these might sound rather stupid but im just wanting some lamans terms.

Have I succeeded?

Regards,

arnezami

[FoxDisc]

Originally Posted by arnezami

We are patching the drive so when a disc is inserted it will give the Volume ID of that disc. Without the need of a special key (called a Host Private Key).

Some might wonder why this is useful and/or why the AACS system did it this way. Suppose you could make an "exact" bit-for-bit copy of a disc. You'd have a backup. Even though it would still be encrypted, and you had not broken the encryption, it would still play perfectly. The AACS LA does not want you to be able to make such backups, so, on a part of the disc that can't be written to by a normal burner, they put a secret (called the Volume ID) that the drive can read, but can't be burned. This prevents bit-for-bit identical copies from being made.

Of course, the drive has to be able to read the secret Volume ID from the original disc, and if the drive reads it and tells any software that asks, it's not a secret anymore. A bit-for-bit copy could still be made and the Volume ID added later (with some custom software), so the drive is designed to refuse to hand over the Volume ID unless the secret Host Private Key is used in a secret handshake (WinDVD and PowerDVD have one of these secret HPKs).

As arnezami says, changing the firmware changes the program in the drive so that it hands over the Volume ID without needing a HPK and going through the secret handshake process. The Volume ID is a necessary part of the decryption process. It could theoretically be used as described above (with a still encrypted bit-for-bit copy), but it's even more useful if you have additional keys that allow you to produce a fully decrypted copy.

@arnezami - Do you see any reason why you couldn't change the firmware so that if the Volume ID was missing from the Burst Cutting Area (meaning the disc was a burned backup copy) the firmware would read it from some other sector of the disc and pass that back to the player as though it had been read from the BCA?

[Pelican9]

Congrats for all!
I was reading the thread, but I couldn't post earlier.
All tools worked well for me.

[lightshadow]

Originally Posted by FoxDisc

@arnezami - Do you see any reason why you couldn't change the firmware so that if the Volume ID was missing from the Burst Cutting Area (meaning the disc was a burned backup copy) the firmware would read it from some other sector of the disc and pass that back to the player as though it had been read from the BCA?

The following is my own opinion, but I think many share it?

I think people would prefer to have their back ups decrypted and free from DRM, so there are no strings attached.

With a none working backup (because it misses the VUK) partial DRM most likely doesn't seam appealing to many. The problem is; Can the owner be 100% sure if this back up will work in the future? And how would it be played?

I think the "right way" (read: subject for discussion =) ) to back up is to remove DRM, and file copy to a blank disc, so any player can play it when ffmpeg supports EVO files.

This is how software players today expect to play back ups of DVD's, so I think that will apply for BD and HDDVD aswell.

[Pelican9]

Originally Posted by lightshadow

I think the "right way" (read: subject for discussion =) ) to back up is to remove DRM, and file copy to a blank disc, so any player can play it when ffmpeg supports EVO files.

I agree.

[HyperHacker]

Arnezami has basically the same idea I had to make the patch stealth. Make the VID retrieval require a password so that the software players can't use it and see if it works, and make the firmware read commands return the original bytes instead of the patched data. For the first, I was thinking the user chooses some key/password when installing the hack. You add a new CDB that will retrieve the VID only when given that password as a parameter, otherwise fails in whatever way an invalid CDB normally would. Since the user chooses the password the software player cannot know it.

Originally Posted by Geremia

the firmware is contained in the first half of the flash memory, the second half if blank (all FF), i'll be not surprised if it will be used to store host revocation list.

This is a big plus as it means we can store the entire original firmware in this region, and modify the read commands to read from it instead of from the first half, so that any program that checks for hacks will read the original firmware. We could compress it too, so that we have room for the modified routines in there as well. If it's only used for the HRL then that's even better, as we won't be using that, we can simply disable HRL-related routines to make this area truly unused.

Great work everybody. AACS is falling like the Berlin Wall.