Got VolumeID without AACS authentication :)

[lightshadow]

firmware dump by software included unique area, without patching anything.

Very impressive! =)

Is there anyone that can make a something like a script to issue 512 plscsi commands to dump 512 0x800bytes chunk and reassemble all them into 1 file?
Would a Linux Script be okay? If not, give me the exact command you want to be issued, and how it output is produced; E.g. default filename scheme or desided by plscsi parameter, and I make a Linux script that produces a Dos script.

In Linux a for-loop is done like this:
for i in $(seq -w 512); do
echo "plscsi $i"
done


This will print 512 lines of "plscsi 000" ... "plscsi 512". When you feel confident remove the "echo" and it will execute each line.

When you have the 512 files, you can join them by
cat * > ../complete_fw.bin
which will join all the files in the current directory and place the joined file in the perent directory.

This was just to get you started, if you have Linux, otherwise I would be happy to help out =)

[arnezami]

Then i send this specific command (hard work to trace it, but with some coffeine an nicotine i've found)
Haha! It helps huh. :)

Congratulations (again)!! This is really cool. :D :D

[Geremia]

heeheh, thanks :)

set PLSCSI=\\.\E: where E: is my toshiba drive letter

plscsi.exe -v -p -x "1D 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00" -f DFenable.bin -o x8

where DFenable.bin contain these hex bytes: 88 00 00 04 02 6F 01 00

plscsi.exe -v -p -x "DF 00 E2 00 00 20 00 00 20 07 FF" -i x800 -t 0.bin
plscsi.exe -v -p -x "DF 00 E2 00 00 20 08 00 20 0F FF" -i x800 -t 800.bin
plscsi.exe -v -p -x "DF 00 E2 00 00 20 10 00 20 17 FF" -i x800 -t 1000.bin
.....
....
512times :(

don't know if this is easy to script, anyway for fw dump will be ok, but for exploration of all memory space of the CPU a dedicated app will be appreciated.
This DF command is most interesting for exploration than simply fw dumping :)

[arnezami]

YES! YES!

I figured it out too! :D :D

Coool. More info later. Still working out some details. But I've recreated one 16 byte value from another. This means I can create a 16 byte value from xor columns too. :)

:D :D

This is a good day!

arnezami

[awhitehead]

E:\HD-DVD\PLSCSI>plscsi.exe -v -p -x "DF 00 E2 00 00 20 00 00 20 00 FF" -i x101



So in essence you want

plscsi.exe -v -p -x "DF 00 E2 00 00 20 00 00 20 00 FF" -i x101
plscsi.exe -v -p -x "DF 00 E2 00 00 20 01 00 20 01 FF" -i x101
plscsi.exe -v -p -x "DF 00 E2 00 00 20 02 00 20 02 FF" -i x101
[etc]

right?

How far ahead do you want it? Do you want an argument to plscsi to dump each chunk to file? Anything else?

Based on my cursory farting around with printf and seq, all you need are three commands:

hostname$ for ii in `seq -f %1.f 0 15 | xargs printf %x'\n'` ; do echo "plscsi.exe -v -p -x "DF 00 E2 00 00 20 0$ii 00 20 0$ii FF" -i x101" ; done
plscsi.exe -v -p -x DF 00 E2 00 00 20 00 00 20 00 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 01 00 20 01 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 02 00 20 02 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 03 00 20 03 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 04 00 20 04 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 05 00 20 05 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 06 00 20 06 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 07 00 20 07 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 08 00 20 08 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 09 00 20 09 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 0a 00 20 0a FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 0b 00 20 0b FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 0c 00 20 0c FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 0d 00 20 0d FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 0e 00 20 0e FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 0f 00 20 0f FF -i x101



hostname$ for ii in `seq -f %1.f 16 255 | xargs printf %x'\n'` ; do echo "plscsi.exe -v -p -x "DF 00 E2 00 00 20 $ii 00 20 $ii FF" -i x101" ; done
plscsi.exe -v -p -x DF 00 E2 00 00 20 10 00 20 10 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 11 00 20 11 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 12 00 20 12 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 13 00 20 13 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 14 00 20 14 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 15 00 20 15 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 16 00 20 16 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 17 00 20 17 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 18 00 20 18 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 19 00 20 19 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 1a 00 20 1a FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 1b 00 20 1b FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 1c 00 20 1c FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 1d 00 20 1d FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 20 1e 00 20 1e FF -i x101
[...]




hostname$ for ii in `seq -f %1.f 256 512 | xargs printf %x'\n'` ; do echo "plscsi.exe -v -p -x "DF 00 E2 00 00 2$ii 00 2$ii FF" -i x101" ; done
plscsi.exe -v -p -x DF 00 E2 00 00 2100 00 2100 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 2101 00 2101 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 2102 00 2102 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 2103 00 2103 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 2104 00 2104 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 2105 00 2105 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 2106 00 2106 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 2107 00 2107 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 2108 00 2108 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 2109 00 2109 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 210a 00 210a FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 210b 00 210b FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 210c 00 210c FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 210d 00 210d FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 210e 00 210e FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 210f 00 210f FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 2110 00 2110 FF -i x101
plscsi.exe -v -p -x DF 00 E2 00 00 2111 00 2111 FF -i x101
[...]

[Geremia]

I was sure you had capacity to figure out all that crypto stuff, good job :)

0x100 chunks or 0x800 chunks makes not difference, maybe 100 is easy for scripting.
-i x100 (not 101, my mistake, the last byte seems to be a checksum)

and -t chunknumber.bin

plscsi.exe -v -p -x "DF 00 E2 00 00 20 00 00 20 00 FF" -i x100 -t 0.bin
plscsi.exe -v -p -x "DF 00 E2 00 00 20 01 00 20 01 FF" -i x100 -t 100.bin
plscsi.exe -v -p -x "DF 00 E2 00 00 20 02 00 20 02 FF" -i x100 -t 200.bin

then a total reassembly

well, is needet till 2F FF FF

damn, i'm so ignorant about this stuff :)

[awhitehead]

How picky is plscsi about the spaces between bytes in commands? Will something like this work?

(Sorry, I am in a middle of a studying session for quantum physics, so I am far away from an HD-DVD drive!)


plscsi.exe -v -p -x "DF00E20000 200000 2007ff" -i x800 -t 200000.bin
plscsi.exe -v -p -x "DF00E20000 200800 201fff" -i x800 -t 200800.bin
[etc]

[Geremia]

FFF is too high for end address, must be <=FFE, that's why i choosed 800

anyway plscsi doesn't care of spaces in CDB, it's ok with or without or with some spaces

EDIT: ah that's ok

what about reassembling?

[lightshadow]

plscsi.exe -v -p -x "DF 00 E2 00 00 20 00 00 20 07 FF" -i x800 -t 0.bin
plscsi.exe -v -p -x "DF 00 E2 00 00 20 08 00 20 0F FF" -i x800 -t 800.bin
plscsi.exe -v -p -x "DF 00 E2 00 00 20 10 00 20 17 FF" -i x800 -t 1000.bin
.....
....
512times :(

One question=)

Do there have to be white spaces between the hex values? I.e. "DF00E200002000002007FF" is just a good as "DF 00 E2 00 00 20 00 00 20 07 FF"? That would simplify the problem a lot! =)

[awhitehead]

FFF is too high for end address, must be <=FFE, that's why i choosed 800

anyway plscsi doesn't care of spaces in CDB, it's ok with or without or with some spaces

EDIT: ah that's ok

what about reassembling?



#include <stdio.h>


int main()
{


int foo = 0, bar = 0;

fprintf(stdout,"set PLSCSI=\\\\.\\E:\n");
fprintf(stdout,"plscsi.exe -v -p -x \"1D 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00\" -f DFenable.bin -o x8\n");


for (foo = 2097152; foo < 3145728; foo = foo + 2048)
{
fprintf(stdout,"plscsi.exe -v -p -x \"DF00E20000 %x %x\" -i x800 -t %x.bin\n",foo, (foo+2048-1), foo);
}

return 0;
}





Output (which sould be redirected to a file) looks like this:

set PLSCSI=\\.\E:
plscsi.exe -v -p -x "1D 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00" -f DFenable.bin -o x8
plscsi.exe -v -p -x "DF00E20000 200000 2007ff" -i x800 -t 200000.bin
plscsi.exe -v -p -x "DF00E20000 200800 200fff" -i x800 -t 200800.bin
plscsi.exe -v -p -x "DF00E20000 201000 2017ff" -i x800 -t 201000.bin
plscsi.exe -v -p -x "DF00E20000 201800 201fff" -i x800 -t 201800.bin
plscsi.exe -v -p -x "DF00E20000 202000 2027ff" -i x800 -t 202000.bin
plscsi.exe -v -p -x "DF00E20000 202800 202fff" -i x800 -t 202800.bin
plscsi.exe -v -p -x "DF00E20000 203000 2037ff" -i x800 -t 203000.bin
plscsi.exe -v -p -x "DF00E20000 203800 203fff" -i x800 -t 203800.bin
plscsi.exe -v -p -x "DF00E20000 204000 2047ff" -i x800 -t 204000.bin
plscsi.exe -v -p -x "DF00E20000 204800 204fff" -i x800 -t 204800.bin
plscsi.exe -v -p -x "DF00E20000 205000 2057ff" -i x800 -t 205000.bin
plscsi.exe -v -p -x "DF00E20000 205800 205fff" -i x800 -t 205800.bin
plscsi.exe -v -p -x "DF00E20000 206000 2067ff" -i x800 -t 206000.bin
plscsi.exe -v -p -x "DF00E20000 206800 206fff" -i x800 -t 206800.bin
[...]


Just compile this, run once, redirect to file, and you are golden.

[Geremia]

thnx a lot :)

i'll compile on cygwin and i'll test

[awhitehead]

Ok, just a small modification
Try compiling and running this, giving it an argument of a filename:


#include <stdio.h>


int main(int argc, char **argv)
{


int foo = 0, bar = 0;
FILE *outfid;


if (argc > 1)
{
if ((outfid=fopen(argv[1],"wb"))==NULL)
{
fprintf(stderr,"Error: cannot write to '%s'\n",argv[1]);
return(1);
}
}

if (argc > 1)
{
fprintf(outfid,"set PLSCSI=\\\\.\\E:\n");
fprintf(outfid,"plscsi.exe -v -p -x \"1D 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00\" -f DFenable.bin -o x8\n");
} else
{
fprintf(stdout,"set PLSCSI=\\\\.\\E:\n");
fprintf(stdout,"plscsi.exe -v -p -x \"1D 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00\" -f DFenable.bin -o x8\n");
}

for (foo = 2097152; foo < 3145728; foo = foo + 2048)
{
if (argc > 1)
{
fprintf(outfid,"plscsi.exe -v -p -x \"DF00E20000 %x %x\" -i x800 -t %x.bin\n",foo, (foo+2048-1), foo);
} else
{
fprintf(stdout,"plscsi.exe -v -p -x \"DF00E20000 %x %x\" -i x800 -t %x.bin\n",foo, (foo+2048-1), foo);
}
}


if (argc > 1)
{
fclose(outfid);
}

return 0;
}




hostname$ gcc -o plscsi_foo plscsi_foo.c
hostname$ ./plscsi_foo runme.bat
hostname$ head runme.bat
set PLSCSI=\\.\E:
plscsi.exe -v -p -x "1D 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00" -f DFenable.bin -o x8
plscsi.exe -v -p -x "DF00E20000 200000 2007ff" -i x800 -t 200000.bin
plscsi.exe -v -p -x "DF00E20000 200800 200fff" -i x800 -t 200800.bin
plscsi.exe -v -p -x "DF00E20000 201000 2017ff" -i x800 -t 201000.bin
plscsi.exe -v -p -x "DF00E20000 201800 201fff" -i x800 -t 201800.bin
plscsi.exe -v -p -x "DF00E20000 202000 2027ff" -i x800 -t 202000.bin
plscsi.exe -v -p -x "DF00E20000 202800 202fff" -i x800 -t 202800.bin
plscsi.exe -v -p -x "DF00E20000 203000 2037ff" -i x800 -t 203000.bin
plscsi.exe -v -p -x "DF00E20000 203800 203fff" -i x800 -t 203800.bin
hostname$

[awhitehead]

As for putting each 2K firmware chunk togeher, either cat *bin > fulldump (under unixish environment), or copy /b under DOS should probably work.

[Geremia]

thnx, just tried the first souce, now i'll reassemble under cygwin, hoping that it will take them in filename order

[Geremia]

WORKS ! :)
thanks awhitehead

the software dumped fw is exactly the same as my flash reading with external programmer.

[awhitehead]

So is byte swapping necessary afterwards?

[arnezami]

WORKS ! :)
thanks awhitehead

the software dumped fw is exactly the same as my flash reading with external programmer.

WOW :)

[arnezami]

@Geremia: I know you're busy doing something else. But maybe you can answer this when you have time for it:

This is regarding checksum bytes and where they are stored in the fw:

I can find the 16 checksum bytes for 0000-3FFF (starting at 00003FF0)
I can find the 16 checksum bytes for 10000-DFFFF (starting at 000DFFF0)
I can find the 16 checksum bytes for the bootloader (starting at 000FDBF0).

I guess these are the most important areas.

But when looking at the region 8000-BFFF there appear to be no valid 16 checksum bytes at the end. And when checking myself (with proggy) they don't validate (while the above three do). Also with E0000-EFFFF.

Any idea if these areas really are XOR checksummed (aswell as SUM)? And if so where these 16 bytes should be?

I guess this is low priority ;).

arnezami

[Geremia]

Thanks awhitehead for the bat creator

i've added the cat stuff

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

fwdump.bat driveletter

it dumps all the firmware, included unique areas

P.S.: byteswapping is only needed if you read the flash by external programmer

@ arnezami
fwpart4 is unknown for me, but i'll take a look after dinner (10minutes lol)

[Geremia]

about fwpart4, it's weird.
during flashing is xor and sum calculated, but skips the AES part.

in boot sequence, it's not checked

i think it's not so important at the moment

[arnezami]

about fwpart4, it's weird.
during flashing is xor and sum calculated, but skips the AES part.

in boot sequence, it's not checked

i think it's not so important at the moment

Ok. Its not so important.

Here is fwchecksum.exe (http://www.sendspace.com/file/smi4t2). :)

It will calculate the (new) 16 bytes checksum and the (new) sum correction value. It ignores the current 16 byte checksum and sum correction values (the old ones still present in the file). It does this for three different areas:

http://img142.imageshack.us/img142/6599/fwchecksumio5.png

In other words: when you change something in any of these areas and run this proggy you can replace the 16 bytes + sum correction value and it should flash without error :).

I'm a bit sleepy at the moment so I hope I didn't make any mistakes ;). Fingers crossed...

Regards,

arnezami

PS. Currently I'm not actually doing the scrambling stuff which limits this proggy to this revision atm.

[edit] Almost forgot: the flash dumper (+script) works!!! :D :D

[Geremia]

:) :)

your fwchecksum works!!!!! :)

just flashed a patched and rechecksumed fw

great job man! :)

BTW, there is another DF command to dump the flash without unique area, i'll check it, it can be usefull to compare with a modified fw to see if it's safe to flash, or if is another fw revision etc...

[arnezami]

:) :)

your fwchecksum works!!!!! :)

just flashed a patched and rechecksumed fw

great job man! :)

BTW, there is another DF command to dump the flash without unique area, i'll check it, it can be usefull to compare with a modified fw to see if it's safe to flash, or if is another fw revision etc...

This really is a good day :).

Seems we have beaten the Xbox 360 HD DVD hands down.

We should be proud. :D

arnezami

[bcrabl]

But this does not allow you to do anything with the video/audio on the disc (like demux/recompress whatever). Its just for backup and playback.

Does that answer your question?


Thanx arnezami for the reply. What I imagined is a last resort if all the other part becomes unhackable (dont think so:) ) . But maybe after this hack the AACS LA would give up upgrading the MKB every time a proseccing or even worse for them a device key (from a software player) is found. They could just admit they lost and game over.

Also when the HD-DVD recorders become accessible and the media price is lowered, it would be preferable to just record it than to reencode it to x264.:p

EDIT: Great news!!!

[lightshadow]

We should be proud. :D

It's well deserved =)

That would you say is left to be done?

Is the goal still a Private Host Key less firmware or perhaps a bootloader that accepts all firmwares?

[osix]

AACS must be hacked !

It's an important demonstration who has got the MIGHT !

Can some intelligent guys win the fight against the consortium of five or six gobal companies with billions of money ?

It's in a certain sense like a "war". Can the companies build the "walls" that high, that nobody can go over it ?

And it's the "second war", after the "first war" the industry lost because of DeCSS....But this time, with AACS, the "weapons" on both sides are even stronger than before...

I BELIEVE IN YOU ALL, nothing is more exciting to read the news on doom9...

[awhitehead]

Geremia, arnezami - wow, you're the giants here, guys.

Thanks awhitehead for the bat creator


Yay! Glad that it worked.
(In case someone asks, my source code above is public domain. Go right ahead and use it or modify it if you want to - I'll just be happy)

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

*removed, not needed anymore*

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

[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?topic=6866.msg44556#msg44556

to dump fw:

dump.exe driveletter firmware.bin 0x200000 0x100000

[mb2696]

how do you apply the ppf to the bin?

edit: nm used ppf-o-matic

[mb2696]

great work!!!!

i was able to confirm that this works.

[arnezami]

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]

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]

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]

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 (http://forum.doom9.org/showthread.php?t=122685), 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]

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:

The dumping of mem/fw should not reveal the patched areas in the fw (it should look like the original)
The retrieval of the Volume ID should somehow be disguised
When it comes to the second part this may be a good idea:

http://img442.imageshack.us/img442/7001/dnkh4.png

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]

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]

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

http://www.xboxhacker.net/index.php?topic=6866.msg44556#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]

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.

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

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

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.

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

Regards,

arnezami

[FoxDisc]

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]

@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]

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.
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. :)