Got VolumeID without AACS authentication :)

[Geremia]

First much thanks to arnezami for contributing with a xor and sum calculation app and sharing headache :)

E:\HD-DVD\PLSCSI>plscsi.exe -v -x "AD 00 00 00 00 00 00 80 00 24 00 00" -i x24
x 00000000 AD 00 00:00:00:00 00 80:00:24:00 00 .. .. .. .. "-@@@@@@@@$@@"
x 00000000 00:22:00:00 40:00:09:18 20:06:08:41 00:20:20:20 "@"@@@@IX FHA@ "
x 00000010 20:20:00:00

I don't think that getting volumeID without AACS authentication is something very usefull to the most, but i had fun in playing with the drive firmware.

I still have to clear something prior to eventually share, at the moment it's only a quick patch

[arnezami]

Congratulations Geremia!! :D :D :D :D :D

This is really cool :).

Btw: this is all about a Xbox 360 HD DVD drive patch (link (http://www.xboxhacker.net/index.php?topic=6866.20)).

Its been quite a ride the last couple of days (or should I say weeks ;)) but its been worth my time. Glad to be of service Geremia!

(and the timing couldn't be better fo course: just before they will start revoking the Host Private Key...)

Regards,

arnezami

PS. As Geremia just told there still has to done quite a lot of work to make this work for everybody. So don't start asking for a patch (yet) ;). Anyway whats really great is that the AACS-Authentication system has effectively been broken this time. :D

[Geremia]

thanks again :)

well, i would say 2 months since i buy the drive (and never watched a movie, lol), but last 2 weeks have been the most "unsleeped"

I must take a look for any vendor specific CDB to read firmware, because flashing without a backup is not so elegant, even if the modified firmware is 90% secure.

[lightshadow]

Does that mean, that if they find a way to revoke the Private Host Key, they can not revoke this hack?

Is it likely at all that the Private Host Key can be revoked???

[bourke]

Does that mean, that if they find a way to revoke the Private Host Key, they can not revoke this hack?

Is it likely at all that the Private Host Key can be revoked???

It means that we can continue to build our collective VUK database without the need of certain Private Host Keys ;-)

I.e. new releases of HD-DVD and Blu-Ray from now on can now only have their keys found by using Volume ID + Processing Key etc.

Well at least for the time being ;-)

[arnezami]

Does that mean, that if they find a way to revoke the Private Host Key, they can not revoke this hack?

Is it likely at all that the Private Host Key can be revoked???

Indeed. They cannot revoke this hack. No matter how many Private Host Keys they revoke we will still be able to get Volume IDs using patched xbox 360 HD DVD drives. :)

Of course some measures must be taken to make sure a patched drive will not be identified as such and revoked (in theory they could make new versions of WinDVD and PowerDVD "examine" your patched drive and if confirmed to be hacked they could (in theory) "call back home" and tell the AACS LA who can revoke your drive). But by simply reflashing the drive (with the original firmware) after getting all your Volume IDs (or making this feature stealthy) this will not be an issue at all.

This is all assuming this patch can be made practical for everybody: Geremia desoldered his flash-chip to read his flash. Only after desoldering, reading and then soldering it back could he flash his drive (using software only). So we still have to find a way to read the entire flash using software only ;).

[edit] Besides the obvious advantage of not needing a Host Private Key anymore there is something else that is good about this. This hack/technique enables us to figure out how the Volume ID is stored on the disc (this is officially "confidential" ;)). Its very possible we would figure out (or at least get an idea) of how the KCD is stored on the disc. Knowing that and being able to teach a PC drive how to read a KCD will open the door for what I called 3rd generation decryption (http://forum.doom9.org/showthread.php?p=959780#post959780) (and here (http://forum.doom9.org/showthread.php?p=959884#post959884)).

Regards,

arnezami

PS. Keep in mind a Host is a software Player. A Drive is a drive. There is such a thing as Host revocation and there is such a thing as Drive revocation. But they can only revoke something they identified.

-- Of course there is also such a thing as Device "revocation" using the MKB etc. But that concerns getting a Media Key while here we are talking about a Volume ID (btw a Volume ID combined with Media Key results in a Volume Unique Key) --

[bob0r]

As long as we can not "backup" our "encrypted .iso backups", AACS is not fully cracked at all :p

[lightshadow]

Indeed. They cannot revoke this hack. No matter how many Private Host Keys they revoke we will still be able to get Volume IDs using patched xbox 360 HD DVD drives. :)

That's so cool =)

This is all assuming this patch can be made practical for everybody: Geremia desoldered his flash-chip to read his flash. Only after desoldering, reading and then soldering it back could he flash his drive (using software only). So we still have to find a way to read the entire flash using software only ;).

is there a thread on this firmware hack? I'd love to read it =)

[edit] Besides the obvious advantage of not needing a Host Private Key anymore there is something else that is good about this. This hack/technique enables us to figure out how the Volume ID is stored on the disc (this is officially "confidential" ;)). Its very possible we would figure out (or at least get an idea) of how the KCD is stored on the disc. Knowing that and being able to teach a PC drive how to read a KCD will open the door for what I called 3rd generation decryption (http://forum.doom9.org/showthread.php?p=959780#post959780) (and here (http://forum.doom9.org/showthread.php?p=959884#post959884)).
Is a complete reverse engineered firmware for that needed?

[arnezami]

That's so cool =)


is there a thread on this firmware hack? I'd love to read it =)


Is a complete reverse engineered firmware for that needed?

http://www.xboxhacker.net/index.php?topic=6866.20

Although I guess much of the detailed knowledge (about this hack) has only been discussed through pms :). I'm sure all info on this will be released soon.

[Geremia]

This is all assuming this patch can be made practical for everybody: Geremia desoldered his flash-chip to read his flash. Only after desoldering, reading and then soldering it back could he flash his drive (using software only). So we still have to find a way to read the entire flash using software only ;).



well, the patched firmware it's already for everybody drive, because only main firmware and bootloader will be flashed, and it's the same for all drives.
I got a flash dump from another drive, and i saw that unique data is at flash regions that are filled with FF in the buffalo SD-H802A fw upgrade.
I blanked with FF my unique data area, like the buffalo fw upgrade, flashed, and all went ok, i can still play hd-dvd.
Also looking at fw flashing code inside the drive bootloader makes me think that unique data area are skipped during flash, but since i didn't already readed back my flash after all tests i made, i can not be sure 100% that unique data is still the same.

[arnezami]

well, the patched firmware it's already for everybody drive, because only main firmware and bootloader will be flashed, and it's the same for all drives.
I got a flash dump from another drive, and i saw that unique data is at flash regions that are filled with FF in the buffalo SD-H802A fw upgrade.
I blanked with FF my unique data area, like the buffalo fw upgrade, flashed, and all went ok, i can still play hd-dvd.
Also looking at fw flashing code inside the drive bootloader makes me think that unique data area are skipped during flash, but since i didn't already readed back my flash after all tests i made, i can not be sure 100% that unique data is still the same.

Interesting. But since we don't know yet how exactly the checksum really works (and if it somehow includes some unique drive specific info) its risky to flash a drive with the firmware of another. Unless of course the 16 bytes at the beginning and end of fw parts (used for checksum stuff) are exactly the same for two different drives. If its not then they either have a different firmware version OR the checksum data is based on something unique. Flashing a drive with the firmware of a different drive might then not work at all because the checksum (during flash) is not validating this data (because the 16 bytes stuff isn't correct). If you could check this that might clear this up.

Anyway. Reading the entire firmware would solve this problem (if it exists) and its of course good practice to have a backup of your original fw before flashing it with a new one.

arnezami

[Geremia]

i already checked, the difference of my dump and the other dump is only in unique data not checksumed at 4000-7FFF

the code analize the uploaded firmare in 7 passes, which denotes 7 firmware zones:

1st pass: base 0 len 4000 (0-3FFF) main firmware (checksumed)
2ns pass: base 10000 len D0000 (10000-DFFFF) main firmware (checksumed)
3rd pass: base 6000 len 2000 (6000-7FFF) unique data, S/N and few other bytes, maybe region (not checksumed)
4th pass: base 8000 len 4000 (8000-BFFF) don't know what's inside, does not seems code (checksumed)
5th pass: base F0000 len 10000 (F0000-FFFFF) bootloader (checksumed)
6th pass: base E0000 len 10000 (E0000-EFFFF) just a few bytes then 00, same data in other MC08 dump, empty in TS06 fw upgrade (checksumed, but 00 on 8th byte)
7th pass: base 4000 len 2000 (4000-5FFF) unique data, probably AACS related (not checksumed)

difference is only in part 3 and 7 (not checksumed), which are filled with FF in the buffalo TS06 fw upgrade. Filling FF on my dump and flashing back to drive, the drive still works, so, as the code analisys seems to confirm, that zones are skipped, and it sounds logical, even in many other drives you can't reflash the area that stores region code and serial number.

what i'm not sure is part 6: it's the same for both flash dumps, but it's filled with FF on buffalo TS06 upgrade, so it seems not firmare code but data common to all SD-S802A. Filled with FF on my dump and flashed back, the drive works again.
Anyway the code explain himself, it skips from checking part 3, 6 and 7, but what i'm not sure, is if a skipped area will be flashed or not, i suppose not, but i must be sure of this.


ROM:002FE364 ldi:8 #6, r0
ROM:002FE366 mul r0, r9 ; r9 = pass number, from 0 to 6
ROM:002FE368 ldi:32 #0x2FDC18, r13
ROM:002FE36E mov mdl, r10
ROM:002FE370 lduh @(r13, r10), r6 ;can be F010, F011, 0080, A090, 70A0, 00D0, 00D1

.........
.........
ROM:002FE3A2 loc_2FE3A2: ; CODE XREF: bootmode_unknown_3B_not04_writebuffer+DCj
ROM:002FE3A2 ldi:20 #0x2000, r0
ROM:002FE3A6 and r0, r6 ; r6 was F010, F011, 0080, A090, 70A0, 00D0, 00D1
ROM:002FE3A6 ; so 2000, 2000, 0000, 2000, 2000, 0000, 0000
ROM:002FE3A8 beq loc_2FE46E ; branch for part 3, 6, 7 (not firmare code)
.........
.........
ROM:002FE46E loc_2FE46E: ; CODE XREF: bootmode_unknown_3B_not04_writebuffer+ECj
ROM:002FE46E ; bootmode_unknown_3B_not04_writebuffer+194j
ROM:002FE46E ; bootmode_unknown_3B_not04_writebuffer+1A4j
ROM:002FE46E ldi:32 #0x2FDC18, r13
ROM:002FE474 lduh @(r13, r10), r4 ; F010, F011, 0080, A090, 70A0, 00D0, 00D1
ROM:002FE476 ldi:20 #0x4000, r0
ROM:002FE47A and r4, r0 ; 4000, 4000, 0000, 0000, 4000, 0000, 0000
ROM:002FE47C beq next_pass_or_goon_if_was_last ; don't branch for pass 1, 2, 5 mainfw and bootloader

[arnezami]

i already checked, the difference of my dump and the other dump is only in unique data not checksumed at 4000-7FFF

the code analize the uploaded firmare in 7 passes, which denotes 7 firmware zones:

1st pass: base 0 len 4000 (0-3FFF) main firmware (checksumed)
2ns pass: base 10000 len D0000 (10000-DFFFF) main firmware (checksumed)
3rd pass: base 6000 len 2000 (6000-7FFF) unique data, S/N and few other bytes, maybe region (not checksumed)
4th pass: base 8000 len 4000 (8000-BFFF) don't know what's inside, does not seems code (checksumed)
5th pass: base F0000 len 10000 (F0000-FFFFF) bootloader (checksumed)
6th pass: base E0000 len 10000 (E0000-EFFFF) just a few bytes then 00, same data in other MC08 dump, empty in TS06 fw upgrade (checksumed, but 00 on 8th byte)
7th pass: base 4000 len 2000 (4000-5FFF) unique data, probably AACS related (not checksumed)

difference is only in part 3 and 7 (not checksumed), which are filled with FF in the buffalo TS06 fw upgrade. Filling FF on my dump and flashing back to drive, the drive still works, so, as the code analisys seems to confirm, that zones are skipped, and it sounds logical, even in many other drives you can't reflash the area that stores region code and serial number.

what i'm not sure is part 6: it's the same for both flash dumps, but it's filled with FF on buffalo TS06 upgrade, so it seems not firmare code but data common to all SD-S802A. Filled with FF on my dump and flashed back, the drive works again.
Anyway the code explain himself, it skips from checking part 3, 6 and 7, but what i'm not sure, is if a skipped area will be flashed or not, i suppose not, but i must be sure of this.

Ok. So as I understand it: if you fill all unique parts of both firmwares (from the two different drives) with FF's you end up with exactly the same firmware and it can be flashed without error. If so then those people with the exact same drive type (btw are there different xbox 360 hd drive types on the market?) could already flash their drives with this patch.

Its also possible there is another flash command to flash the unique parts. Or maybe it can't be read/write these areas when the chip is on the drive's board and some addresses maybe be hardware blocked/secured? I guess when we find a command to read the flash will we see how much it can read.

Anyway. This all looks quite promising :).

For those of you who would like to know how this hack relates to the entire AACS scheme here is a picture:

http://img135.imageshack.us/img135/3430/host2xr1.png

In effect we removed the need for a Host Private Key and "only" need to get Device/Processing keys in the future to decrypt all HD DVD discs. :)

Regards,

arnezami

PS. This "elimination" of a piece of AACS is only possible because this part involves explicit revocation: they tell the drive to revoke the host but the drive can simply disobey. When it comes to MKB revocation (which involves what I call implicit revocation: the needed key simply isn't there) we cannot eliminate this part of AACS for good. So this part will be a ongoing endeavor ;).

[Geremia]

Ok. So as I understand it: if you fill all unique parts of both firmwares (from the two different drives) with FF's you end up with exactly the same firmware and it can be flashed without error. If so then those people with the exact same drive type (btw are there different xbox 360 hd drive types on the market?) could already flash their drives with this patch.


exactly, at least for the only 2 flash dump i've, and it should be for all xbox360 drive with MC08 fw revision


Its also possible there is another flash command to flash the unique parts. Or maybe it can't be read/write these areas when the chip is on the drive's board and some addresses maybe be hardware blocked/secured? I guess when we find a command to read the flash will we see how much it can read.


Yes, probably there are cdb commands to write unique data areas and cdb command to dump memory space (ram and flash), but there could be also a bad situation where such cdb does not exist. This case there should be 99% probably a cdb command to upload and execute custom code (trojan horse style).
I neesdsome time to take a look.

[Pelican9]

How can we help your work?

[Galileo2000]

How can we help your work?


Yeah, and we wanna guide to the hack too :D

[awhitehead]

Yeah, and we wanna guide to the hack too :D

Essentially here is what happened the way I understand it. Geremia will correct me, I am sure

Geremia is a highly respected firmware engineer on xboxhacker.net forums. He was one of the folks who collaborated on breaking the protection of the normal Xbox 360 DVD drive.

One day he bought an HD-DVD drive, and asked on xboxhacker.net forums if anyone else got got one, and is interested in reverse engineering it's firmware. At the same time he "dumped" the drive - opened the HD-DVD case apart, removed the drive, then desoldered the flash chip (containing drive's operating system) and read it using standard "flasher" - device designed to read and write to flash memory chips.

Then he had a copy of the firmware in the flash memory of his drive.

At that time noone knew what is the core of the drive based on - in plain words, what processor architecture is used by Toshiba in SD-S802A HD-DVD drives. Without knowing this, it was not possible to make sense of the actual data that Geremia recovered from the drive. Geremia took high resolution photos of the drive's logic board, and looked at the similar Toshiba drives, that might use similar architecture and similar firmware.

Around the same time, Geremia discovered the post by arnezami on doom9 forum on snooping USB connection between the drive and the operating system. Since he already had means of restoring his drive to original condition (he made a backup of drive's flash before), he could play around with the flash "dump". By watching the interations between the flashing utilities and other Toshiba drives, he discovered some of the vendor specific CDBs - commands sent over the USB bus (or actually over any sort of encapsulated SCSI connection - ATAPI over USB, over IDE or over SCSI itself) needed to flash the drive with new firmware.

He attempted to duplicate the same commands but with his own drive and his own firmware, and after some attempts succeeded. So by this point he knew how to flash the firmware onto the drive, but not how to modify firmware.

By this point someone else on xboxhacker.net forums got an HD-DVD drive, and desoldered his flash chip (Usually people desolder the flash, and solder a socket in it's place, allowing easy removal and reprogramming of the chip), and read the contents. That person sent Geremia his own copy of the flash dump, and Geremia was able to see what the differences are between the two copies of the same firmware. That's the data that is not checksummed by the firmware, btw.

Around the same time, after some misdirections by people without a clue (read: after awhitehead told Geremia a bunch of bullshit), Geremia figured out that the architecture used by Toshiba in SD-S802A drives is based on Fujitsu FR 32 architecture. More over, disassemblers for this exist, both commercial and free, so it's possible to see to which assembly instruction each opcode matches.

At this point Geremia spent a long time tracking down how the drive is supposed to react to certain CDB commands.

Your copy of PowerDVD sends a bunch of authentication data using CDBs (Well, encapsulated in CDBs) to the drive, and then asks for specific data (Volume ID) from the drive again using a CDB command (plscsi.exe -v -x "AD 00 00 00 00 00 00 80 00 24 00 00" -i x24 command means "Send CDB containing AD 00 00 00 00 00 00 80 00 24 00 00 to the drive, and expect back 24 bytes of reply"), he was able to modify the firmware so that the drive executes the actual disk read without the need to the cryptographic exchange between the drive and the player software beforehand.

Now there are two things that remain to be solved:
1) Geremia and others (I can't say 'we", since I am not qualified) is searching for a way to be able to dump the firmware from the drive using CDBs. This way no complicated desoldering is required, and no flasher hardware is necessary. This is needed so that you could make a backup of your own firmware before hand.

2) Testing needs to be done, to make sure that the firmware modification is not noticed by the software, etc.


All of the above is probably wrong. :-)
Hope this helps.

[arnezami]

At this point Geremia spent a long time tracking down how the drive is supposed to react to certain CDB commands.

I think I can fill in some gaps here :).

At some point Geremia discovered the essential part of the checksum function (http://www.xboxhacker.net/index.php?topic=6866.msg44210#msg44210). At that time it was still unknown what the exact extend was of the whole checksum related issues but this function did seem very promising. He needed an XOR calculator and thats where I could help him.

I also decided to take a shot at the assembly code and after a lot of pm discussion we (well Geremia did most of the tracing ;)) figured out that the checksum (especially before flashing) was far more complicated than was first assumed. It wasn't just 4 XORs (4 x 32-bit columns) and 1 SUM (of all 32-bit values) and nothing more. There was lots more calculation after that. It was getting a little frustrating because we seemed to find more and more functions all extending these calculations.

So at some point we decided to try to see if it was possible to keep the total SUM and XORs exactly the same while changing just one bit. Basicly avoiding all the difficult checksum calculation issues we encountered. Here is a snippet of what we figured out:

Anyway. As far as I understand there are two things done first: SUM and XOR. And only with the endresults of those values is something being calculated.

So if we can make sure the SUM and XORs stay exactly the same then this should work.

Ok how could this be done?

Lets say we want to change 1 bit in 1 column. In order to do that we would have to change two bits in total.

Case 1:

Ok lets say we want to change one bit from 0 to 1. In this case this causes the SUM to go one up. In order to counteract this we would have to change a (very likely) unused part of the fw (in the same column) and find something like FFFFFFFF. We can change the same bit nr (vertically) and change it from 1 to 0. This will have two effects: the XOR of that column is restored AND the SUM is restored!

Case 2:

Ok lets say we want to change one bit from 1 to 0. In this case this causes the SUM to go one down. In order to counteract this we would have to change a (very likely) unused part of the fw (in the same column) and find something like 00000000. We can change the same bit nr (vertically) and change it from 0 to 1. This will have two effects: the XOR of that column is restored AND the SUM is restored!


Geremia tried this and changed one bit. And it flashed! This meant we could change the fw and still flash it (keep in mind all attempts so far had not succeeded in doing this and resulted in flash errors).

Now we realized we could use this same technique to change not just one bit but multiple. There was just one problem: in order for this to work we needed unused space in the flash memory filled with 00s (not just FFs). This was a problem because well there wasn't any: all unused space was filled with FFs.

We both (independently I might add) thought about this but his solution was both brilliant and beautyful :). He would change a bunch of FFs (of which we had plenty):

000DFFB0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000DFFC0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000DFFD0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000DFFE0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

Into this:

000DFFB0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000DFFC0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000DFFD0 FF FF FF FE FF FF FF FE FF FF FF FE FF FF FF FE
000DFFE0 FF FF FF FE FF FF FF FE FF FF FF FE FF FF FF FE
And thats just sweet :D. You may not see this directly but this does three things: (1) each 32-bit column's XOR stays the same (2) the total sum of all 32-bit values stays the same and (3) it creates a bunch of desperately sought for 00s!

Eureka! :D

From there things did go really quickly. Geremia had already figured out what changes he wanted to try to retrieve the volume ID. He sent me the changes in hex form and the following is what was actually calculated the first time we did multiple bit changes to the fw.

The original code:


002218C6 ldi:32 #checks_on_40254, r12
ROM:002218CC call:D @r12 ; some check on 40254, result r4=0 or =1
ROM:002218CE ldi:8 #1, r4
ROM:002218D0 cmp #0, r4
ROM:002218D2 bne loc_2218DE
ROM:002218D4 ldi:32 #loc_2238E2, r12
ROM:002218DA call @r12 ; seems to go to cdb error


The patched code:


ROM:002218C6 ldi:32 #checks_on_40254, r12
ROM:002218CC call:D @r12 ; some check on 40254, result r4=0 or =1
ROM:002218CE ldi:8 #1, r4
ROM:002218D0 nop ; patched here
ROM:002218D2 bra loc_2218DE ; patched here


Changes in hex:

from
000218D0 A8 04 E3 05

to
000218D0 9F A0 E0 05

The calculation:

Taking A8 04 E3 05 and 9F A0 E0 05 here are the bit changes from 0 to 1:

17 A0 00 00

And these are the bit changes from 1 to 0.

20 04 03 00

This means we have to compensate in an FF area the following way:

E8 5F FF FF

And in a 00 area the following way (this is simple):

20 04 03 00

This meant we knew exactly what to change in the original fw. If it flashed correctly it would be a confirmation that this technique actually worked. If it also would give the volume ID it would confirm the change was enough as a working VID hack.

And it flashed. :) While the change in code did not change the Volume ID behaviour it did mean we were on the right track. Geremia did some more changes (mostly concerning the skipping of AGID stuff I believe) and finally made the drive give the Volume ID :D.

This is the last info (I have) on the actual patch needed for Volume ID retrieval:


ROM:002218B2 .type ATAPI_AD_AACS_READ_VOLUMEID, @function
ROM:002218B2 ATAPI_AD_AACS_READ_VOLUMEID:
ROM:002218B2 stm1 (r8, r9, r10, r11)
ROM:002218B4 st rp, @-r15
ROM:002218B6 enter #0x14
ROM:002218B8 mov r4, r9 ; AGID, from 0 to 3
ROM:002218BA ldi:32 #off_2F0010, r10
ROM:002218C0 ldi:32 #0x405BB, r11
ROM:002218C6 ldi:32 #checks_on_40254, r12
ROM:002218CC call:D @r12 ; some check on 40254, result r4=0 or =1
ROM:002218CE ldi:8 #1, r4
ROM:002218D0 cmp #0, r4 ; patch here does not work
ROM:002218D2 bne loc_2218DE
ROM:002218D4 ldi:32 #loc_2238E2, r12
ROM:002218DA call @r12 ; seems to go to cdb error
ROM:002218DC bra loc_2219A8
ROM:002218DE ; ---------------------------------------------------------------------------
ROM:002218DE
ROM:002218DE loc_2218DE: ; CODE XREF: ATAPI_AD_AACS_READ_VOLUMEID+20j
ROM:002218DE ldi:20 #0x164, r0
ROM:002218E2 mul r0, r9 ; AGID, from 0 to 3
ROM:002218E4 mov mdl, r0
ROM:002218E6 ldi:32 #0x60C1C8, r8 ; seems AGID related data stored in internal ram
ROM:002218EC add r0, r8
ROM:002218EE ldi:8 #4, r13
ROM:002218F0 ld @(r13, r8), r0
ROM:002218F2 cmp #0, r4 ; patched here, substituted r0 with r4, which is always 4
ROM:002218F4 bne loc_22191C ; patched here, branch a little more forward, skipping checks on AGID
ROM:002218F6 ldi:32 #CDB_field_error, r12
ROM:002218FC call:D @r12
ROM:002218FE ldi:8 #0xA, r4
ROM:00221900 bra loc_2219A8
ROM:00221902 ; ---------------------------------------------------------------------------
ROM:00221902 ld @r8, r0
ROM:00221904 cmp #5, r0
ROM:00221906 beq:D loc_22191C
ROM:00221908 mov r9, r4
ROM:0022190A ldi:32 #sub_224208, r12
ROM:00221910 call @r12
ROM:00221912 ldi:32 #loc_22383C, r12
ROM:00221918 call @r12
ROM:0022191A bra loc_2219A8
ROM:0022191C ; ---------------------------------------------------------------------------
ROM:0022191C
ROM:0022191C loc_22191C: ; CODE XREF: ATAPI_AD_AACS_READ_VOLUMEID+42j
ROM:0022191C ; ATAPI_AD_AACS_READ_VOLUMEID+54j
ROM:0022191C ldi:32 #sub_224208, r12 ; seems to clear AGID validity, so next time need auth again
ROM:00221922 call @r12
ROM:00221924 ldi:32 #0x6010F0, r4
ROM:0022192A st r4, @(r14, 0xF8)
ROM:0022192C ldi:32 #0x60ABB8, r5


I would like to thank Geremia for letting me participate (and hopefully encourage and/or inspire him) in his effort (or should I say: quest ;)) of opening a so called "closed system". He has done the bulk of the work and I enjoyed helping him where I could and where I felt it was needed. :)

Its another victory for those who enjoy their fair use rights...

Regards,

arnezami


PS. I would also like to add that for all this to happen sacrifices were made. Both by me and by Geremia (and probably others too). Lets just say we (at the very least) lost quite a lot of sleep lately. I hope when asking about information or improvements or whatever you will always keep this in mind.

[Geremia]

Geremia is a highly respected firmware engineer on xboxhacker.net forums. He was one of the folks who collaborated on breaking the protection of the normal Xbox 360 DVD drive.


hehehe, that's too much!:) about first xbox360 hack, i did nothing special, i was not able to dissassemble anything. After that, i started learning and had my first satisfaction: a firmware patch for dvd media detection for hitachi drive.
Engeneer is too much, i prefer "hobbist who likes to learn on the way".

This time is the second satisfaction, from roaming in the dark till
a volumeID. And arnezami helped a lot with the xor stuff, and when he told me that a bit compensation can be the workaround for both xors and sum, he lighted me and i saw this picture :)


000DFFB0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000DFFC0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000DFFD0 FF FF FF FE FF FF FF FE FF FF FF FE FF FF FF FE
000DFFE0 FF FF FF FE FF FF FF FE FF FF FF FE FF FF FF FE

but this trick is quite frustrating for huge code changes, patch must be done with the less bit changes possible, so maybe i'll try to modify the bootloader (with this compensation trick) to skip the sum check but leave the xor check, this way the fw integrity will be guaranteed aswell and the xor calculation could be adjusted with easy.

I'll have some time on weekend to desolder the flash and read again, if nothing weird happened, i think the patch can be shared, but i don't assume any risks if people flash it without an original backup.

[Galileo2000]

hehehe, that's too much!:) about first xbox360 hack, i did nothing special, i was not able to dissassemble anything. After that, i started learning and had my first satisfaction: a firmware patch for dvd media detection for hitachi drive.
Engeneer is too much, i prefer "hobbist who likes to learn on the way".

This time is the second satisfaction, from roaming in the dark till
a volumeID. And arnezami helped a lot with the xor stuff, and when he told me that a bit compensation can be the workaround for both xors and sum, he lighted me and i saw this picture :)


000DFFB0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000DFFC0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000DFFD0 FF FF FF FE FF FF FF FE FF FF FF FE FF FF FF FE
000DFFE0 FF FF FF FE FF FF FF FE FF FF FF FE FF FF FF FE

but this trick is quite frustrating for huge code changes, patch must be done with the less bit changes possible, so maybe i'll try to modify the bootloader (with this compensation trick) to skip the sum check but leave the xor check, this way the fw integrity will be guaranteed aswell and the xor calculation could be adjusted with easy.

I'll have some time on weekend to desolder the flash and read again, if nothing weird happened, i think the patch can be shared, but i don't assume any risks if people flash it without an original backup.

OK guys, I am the test engineer by trade, I have Xbox HD DVD drive and willing to take the risks, except soldering.

Let me know what I have to do in order to help you and I will do it.

Cannot help with the code, sorry, my brain is half-broken already.

I know you are doing some really advanced stuff which will help us all in the near future.

[Geremia]

This will help in concluding if the patched firmware is safe:

- desolder the falsh
- read it with external programmer, compare with original MC08 firmware
- solder it back
- flash by software the patched firmware i can provide
- desolder the flash
-read it again and compare with the original dump to see if any other region changes except the few bytes patched.

Consider that i can do it myself as soon as i've time, probably tomorrow.

From the assembler side, an help could be in finding a vendor specific CDB that can dump firmware by software.
On xboxhacker thread there are info about the CDB table with relative function address.

btw, here is the original SD-S802A MC08 firmware with part 3, 6 and 7 blanked, like the buffalo SD-H802A fw upgrade.
http://www.sendspace.com/file/sleyls
don't flash this (atm), but use only for dissassembling or comparing with your own flash dump.

[arnezami]

Just a little update: I'm currently analyzing the checksum functions etc and I'm making progress. :)

Things I've figured out:

The function starting at 002F0CA6 first cancels the XOR effects of the first 32 bits value in the fw part (so this is literally at 00000000 for the first fw part) and the 16 bytes at the end of the fw part. Its as if it did a 4-column XOR with these (total of 20 bytes) values zeroed out. This is to then recalculate the 16 bytes checksum values at the end of the fw.
The function 002F0A44 re-calculates the actual 16 byte checksum values and has the 4 column XORs as input. The output of this function should be the 16 bytes value stored in the uploaded fw. So the only thing we need is this function which generates the right checksum data. It uses the data ToshibaSamsungST + random 16 bytes (from its current fw) and appears to do a hash (at 002F01B2) with 10 rounds on it (possibly RIPEMD-160). The fact that it gets these value from its current fw is probably because it won't (accidentally) overwrite a different type of firmware on its flash (which is good for us). This function also combines the 4 column XORs (byte-wise) including some bit shifting etc.
The 32 bit value at the beginning of a checksummed fw part is the "SUM-correction-value": it makes sure the SUM will be 0. This should be added at the last moment if we would do our own checksum calculations. Essentially this correction value is not part of the XOR checksum.

This whole checksum algo starts to make more and more sense to me now. I'm not there yet but its promising. ;)

arnezami

[Geremia]

hehhe, i got lost there with all that clearing of column xors.


ROM:002F0AC4 ldi:8 #0xCF, r9
ROM:002F0AC6 extsb r9
ROM:002F0AC8 add r14, r9 ; r9 = (r14, 0xCF)
ROM:002F0ACA ldi:8 #0, r4
ROM:002F0ACC mov r9, r5
ROM:002F0ACE ldi:32 #CP_r4_to_@r5_till_r5plus_r6minus1, r12
ROM:002F0AD4 call:D @r12 ; clears from (r14, 0xCF) to (r14, 0xDE)
ROM:002F0AD4 ; column1 xors are at DC, is partially cleared, remain last byte
......
.......
ROM:002F01C8 ldi:8 #0xD4, r0
ROM:002F01CA extsb r0
ROM:002F01CC add r14, r0 ; r0 = (r14, 0xD4)
ROM:002F01CE st r0, @(r14, 0xFC)
ROM:002F01D0 mov r9, r4
ROM:002F01D2 ld @(r14, 0xFC), r5
ROM:002F01D4 call:D CP_@r4_to_@r5_r6len ; copy the cleared area (r14, 0xCF) to (r14, 0xD4), 0x10len
ROM:002F01D4 ; column xors area was from DC to EB, now cleared till E3 ?!?!



then bite rotation and other stuff, i got enought and thinked that a workaround was maybe easyer than recheck my dissassembling.

I'm sure that arnezami will figure it out clearly :)

[FoxDisc]

I'm currently analyzing the checksum functions etc....The function starting at 002F0CA6 ...

Are you using Ida Pro? If so, what processor do you tell Ida to use for decompiling?

[arnezami]

but this trick is quite frustrating for huge code changes, patch must be done with the less bit changes possible, so maybe i'll try to modify the bootloader (with this compensation trick) to skip the sum check but leave the xor check, this way the fw integrity will be guaranteed aswell and the xor calculation could be adjusted with easy.
As far as I understand the checksum functions this is a pretty good idea. Only 16 bytes of unused space would be needed to make sure the 4 columns will keep the same XOR. I don't think changing the last 16 bytes of a fw part themselves would be wise.

Maybe the best and easiest way to do this is change this:

002F0DB0 MOV R7,R4

into this:

002F0DB0 LDI:8 #$00,R4

If i'm correct (and you would really have to check this, I haven't given this much thought ;)) this would make sure the SUM will always be 0 (also at intermediate points (within the fw part) but that doesn't matter I believe) while keeping the XOR calculations intact.

This function is used both at booting and before flashing (correct?) so there will be no discrepancies (like being able to flash but not being able to boot anymore).

Does this make sense?

Regards,

arnezami


PS. I'm sure that arnezami will figure it out clearly :)
I'm not sure of that myself yet. Also some time contraints here... (don't count on it soon)

[Pelican9]

Are you using Ida Pro? If so, what processor do you tell Ida to use for decompiling?
Arnezami said Fujitsu FR 32-bit family (but it isn't work for me).

[awhitehead]

Arnezami said Fujitsu FR 32-bit family (but it isn't work for me).

Read the thread on the xboxhacker! It is Fujitsu FR 32 family.

You don't need to byteswap this particular firmware file before you disassemble it.

In the thread on xboxhacker, I give link to source code of FR disassembler (http://www.xboxhacker.net/index.php?topic=6866.msg43216#msg43216). It's not as nice as IDA Pro (primarily no automatic commenting and function tracing), however it works and it is free.


hostname:~/src/firmware/SD-S802A/tmp$ ./disfr
Binary file to disassemble : SD-S802A-MC08_nokey.bin
Offset : 0x00200000
TBR register value [FFC00]:
Swap bytes order (y/N) ? N
Done.
hostname:~/src/firmware/SD-S802A/tmp$ less SD-S802A-MC08_nokey.bin.txt




[...]
002F0AC2 A444 ADD #$04,R4
002F0AC4 CCF9 LDI:8 #$CF,R9
002F0AC6 9789 EXTSB R9
002F0AC8 A6E9 ADD R14,R9
002F0ACA C004 LDI:8 #$00,R4
002F0ACC 8B95 MOV R9,R5
002F0ACE 9F8C 002F 0198 LDI:32 #$002F0198,R12
002F0AD4 9F1C CALL:D @R12
002F0AD6 C106 LDI:8 #$10,R6
002F0AD8 CBFA LDI:8 #$BF,R10
002F0ADA 978A EXTSB R10
[...]


The results are consistent to what Geremia posted from IDA Pro:


ROM:002F0AC4 ldi:8 #0xCF, r9
ROM:002F0AC6 extsb r9
ROM:002F0AC8 add r14, r9 ; r9 = (r14, 0xCF)
ROM:002F0ACA ldi:8 #0, r4
ROM:002F0ACC mov r9, r5
ROM:002F0ACE ldi:32 #CP_r4_to_@r5_till_r5plus_r6minus1, r12
ROM:002F0AD4 call:D @r12 ; clears from (r14, 0xCF) to (r14, 0xDE)
ROM:002F0AD4 ; column1 xors are at DC, is partially cleared, remain last byte
......
.......
ROM:002F01C8 ldi:8 #0xD4, r0
ROM:002F01CA extsb r0
ROM:002F01CC add r14, r0 ; r0 = (r14, 0xD4)
ROM:002F01CE st r0, @(r14, 0xFC)
ROM:002F01D0 mov r9, r4
ROM:002F01D2 ld @(r14, 0xFC), r5
ROM:002F01D4 call:D CP_@r4_to_@r5_r6len ; copy the cleared area (r14, 0xCF) to (r14, 0xD4), 0x10len
ROM:002F01D4 ; column xors area was from DC to EB, now cleared till E3 ?!?!



Hope this helps.

[Pelican9]

Read the thread on the xboxhacker! It is Fujitsu FR 32 family.

You don't need to byteswap this particular firmware file before you disassemble it.

In the thread on xboxhacker, I give link to source code of FR disassembler (http://www.xboxhacker.net/index.php?topic=6866.msg43216#msg43216). It's not as nice as IDA Pro (primarily no automatic commenting and function tracing), however it works and it is free.


I've read the all thread.
disfr isn't work on my xp. ("The system cannot execute the specified program.")
IDA pro work, but the file (SD-H802A.bin) has wrong byte order.

[awhitehead]

but the file (SD-H802A.bin) has wrong byte order.

I slapped together a quick byteswapper for that purpose earlier in that thread. Link to source code (http://www.xboxhacker.net/index.php?topic=6866.msg42906#msg42906)

Someone else built distfr for Windows in this post (http://www.xboxhacker.net/index.php?topic=6866.msg43283#msg43283). Maybe that will work for you.

It's probably obvious by now that I don't have a readily available Windows system to build on (And probably won't have until I figure out how to install Parallels on AppleTV, but that's a subject of a different post in a different forum). If it helps at all, I believe that any of the things that I write in C are compilable under Windows using either cygwin or mingw, if not using the more mainstream development tools.

[Pelican9]

I slapped together a quick byteswapper for that purpose earlier in that thread. Link to source code (http://www.xboxhacker.net/index.php?topic=6866.msg42906#msg42906)

Someone else built distfr for Windows in this post (http://www.xboxhacker.net/index.php?topic=6866.msg43283#msg43283). Maybe that will work for you.

It's probably obvious by now that I don't have a readily available Windows system to build on (And probably won't have until I figure out how to install Parallels on AppleTV, but that's a subject of a different post in a different forum). If it helps at all, I believe that any of the things that I write in C are compilable under Windows using either cygwin or mingw, if not using the more mainstream development tools.

Thanks!
I've just written a swapper too. :-)
That windows build was which didn't work.

[Geremia]

.

Maybe the best and easiest way to do this is change this:

002F0DB0 MOV R7,R4

into this:

002F0DB0 LDI:8 #$00,R4

If i'm correct (and you would really have to check this, I haven't given this much thought ;)) this would make sure the SUM will always be 0 (also at intermediate points (within the fw part) but that doesn't matter I believe) while keeping the XOR calculations intact.

This function is used both at booting and before flashing (correct?) so there will be no discrepancies (like being able to flash but not being able to boot anymore).

Does this make sense?



Yes, it's called both from the 3B 05 writebuffer and the bootloader booting sequence, a patch like you suggest whould work, i'll test this night.
At booting, only fwpart 1,2 and 4 will pass trought this function, while at flashing only part 1, 2, 4 and 5.

About dissassembling, the fw is byteswapped only in the flashrom if you read with external programmer.
If you got fw from my link or from the buffato SD-H802A, it does not need byteswapping, it's ok like this, and it's how the CPU sees it.

The CPU works in bigendian scheme, and the flash is mapped at address 0x200000.
I'm using IDApro set to FR 32bit family, CPU FR65E but it should be the same if you set FR50 or FR30. Just make sure to load the bin in ROM at address 0x200000

[arnezami]

Yes, it's called both from the 3B 05 writebuffer and the bootloader booting sequence, a patch like you suggest whould work, i'll test this night.
At booting, only fwpart 1,2 and 4 will pass trought this function, while at flashing only part 1, 2, 4 and 5.
You probably already know this but this means you (and everybody else who wants to do this) first have to do the patch disabling the SUM checking (using bit compensation). And only after that can you do another flash without being concerned about the SUM. So at least two flashes for a VID hack.

Right?

arnezami

[Geremia]

Yes, i was too curious and i've tried already (my girlfriend can wait :))

modified the bootloader on an original fw, xors and sums compensated, flashed without errors.

then made a fw with this patched bootloader and a patched mainFW where only xors were correct, sum was wrong. Flashed, got error.

Ths was weird, so i made an original fw with a modified bootloader which had sum and xor not correct, to see if it give error.
Surprise, no flashing errors, this means that the bootloader is not checked and not flashed !?!?!
This is why my first bootloader patch of some days ago didn't work...the patch was probably correct, the problem is that the bootloader is not flashed :(
i've to take a look at the 3B 05 writebuffer comand, maybe the bootloader has another way to be flashed.

[bcrabl]

By being able to modify the firmware, is it now possible to do backups from a genuine HD-DVD to a HD-DVD-Recordable without the need to find any of the private/proseccing keys from the software application?

I mean a hack like the original xbox360 hack. Read all the "unreadable" portions of the disc and write them at specific section of the recorable disk. Then direct the drive to read those specific bytes and make "software player" think that everything is like a normal situation.

[arnezami]

By being able to modify the firmware, is it now possible to do backups from a genuine HD-DVD to a HD-DVD-Recordable without the need to find any of the private/proseccing keys from the software application?

I mean a hack like the original xbox360 hack. Read all the "unreadable" portions of the disc and write them at specific section of the recorable disk. Then direct the drive to read those specific bytes and make "software player" think that everything is like a normal situation.

Yes. This is (in principle) possible. Although its an awful lot of work.

What would be needed is to let the drive detect that is has a recordable inside. If so the Volume ID retrieval command should get its Volume ID from a different place (a place on the recordable we assigned ourselves to let the Volume ID be stored). In addition we would have to make sure the software player sees the recordable as a prerecorded disc (there may be checks to see this).

But looking at Geremia's last post we can't overwrite the bootloader itself so there is still quite a lot of work to do in order to do these kinds of complex changes to the drive. Not being able to overwrite the bootloader also limits our ability to "stealthen" the patched fw.

But if it all works it would mean that an (encrypted) recordable movie would work on all software players and would even play on the xbox 360 itself. I'm not sure if its possible now (or if it will stay possible in the future) to play unecrypted movies on the xbox 360. But if not this would be the solution to that too. All without knowing any of the AACS Keys (Device/Processing/Media/Vuk/Host Private keys etc.) :D. Thats pretty spectacular...

In essence this is a kind of "bit-by-bit copy" attack (with only a slightly difference to the orginal disc)

This would be a cool project :). If some people stick their heads together (possibly at xboxhacker since xbox 360 owners would greatly benefit from this and they have already done this with the dvd player) this could be done in reasonable time I think.

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?

Regards,

arnezami

Btw: I think I now know enough to recalculate the 16 byte checksum values :D. More on that later...
[edit] Hmmmm. Maybe not :(. Looks like I really need to go into the Hash function (or identify it). Damn it.

[lightshadow]

But looking at Geremia's last post we can't overwrite the bootloader itself so there is still quite a lot of work to do in order to do these kinds of complex changes to the drive. Not being able to overwrite the bootloader also limits our ability to "stealthen" the patched fw.

Wouldn't it be very likely that the fw/boot loader could flashed?

I mean; M$ could benefit from such feature when your fw patch is released =)

When you connect a hacked XBox to XBoxLive, it gets revoked. Isn't that done in the firmware?

[arnezami]

Ah. Stupid me. Its not a "normal" Hash function: its AES! :p

Or AES-G or AES-H or something...

Well it pretty much gotta be...

AES has 10 rounds too. :) Duh.

Still not sure of course but this makes a lot more sense.

[arnezami]

This seems to be way the 16 byte checksum is calculated for each fw part (if I didn't make any mistakes ;)):

http://img242.imageshack.us/img242/2342/checksumxr9.png

The "Rand 16 bytes" are the ones right after the ToshSams string (in the current fw).

The "XOR columns" is the endresult of XOR-ing the columns of an fw part without the SUM correction value (the first 4 bytes of the fw part) and without the (proposed) checksum values themselves (the last 16 bytes of the fw part).

The output should be the same as the 16 bytes at the end of the fw part. If not the flashing will fail.

Still trying to figure out what hash/one-way function is used and how it is used.

Regards,

arnezami

[Geremia]

with a criptographic specialist like you, we are all in good hope :)

BTW, i'm tracing a vendor specific CDB, it smells of "memory space dump", hope to be on the right track.

keep up the good work!

[awhitehead]

I'm not sure if its possible now (or if it will stay possible in the future) to play unecrypted movies on the xbox 360.

I might be misinterpreting what you mean by "unencrypted", however this post (http://www.avsforum.com/avs-vb/showthread.php?p=10058863&&#post10058863) on AVSforum by President of R&B Films (http://www.rbfilms.com/) indicates that none of their HD-DVDs use AACS due to costs. In practical means that means "Chronos".

In addition I can think of a couple other commercially pressed HD-DVD disks that were reported to not utilize AACS: "Running Scared" in Germany, and "Nature's Colors".

To the best of my knowledge, these titles are currently playable by Xbox 360 with an HD-DVD add-on.

[Geremia]

I'm on the right track, i got a dump of firmware but without the unique areas. I've to trace something more.
BTW, the CDB opcode is DF and it's disabled by default, or at least it works only if the drive is in a certain state, which i really don't know. I patched the firmware to enable this CDB.

[Geremia]

E:\HD-DVD\PLSCSI>plscsi.exe -v -p -x "DF 00 E2 00 00 20 00 00 20 07 FF" -i x801
x 00000000 DF:00:E2:00 00:20:00:00 20:07:FF .. .. .. .. .. "_@b@@ @@ G?"
x 00000000 56:31:59:4C 28:22:2D:23 02:01:02:00 00:00:00:00 "V1YL("-#BAB@@@@@"
x 00000010 40:40:00:79 1E:02:4A:14 00:00:00:00 00:00:00:00 "@@@y^BJT@@@@@@@@"
x 00000020 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
x 00000030 4D:43:30:38 31:30:2F:30 33:2F:30:36 00:21:7C:E4 "MC0810/03/06@!|d"
x 00000040 00:20:00:60 00:21:3B:E2 00:21:58:06 00:20:07:A8 "@ @`@!;b@!XF@ G("
x 00000050 00:21:3C:28 00:21:16:52 00:21:26:48 00:20:00:70 "@!<(@!VR@!&H@ @p"
x 00000060 17:81:9F:8C 00:21:8C:9A 9F:1C:C0:04 07:81:97:20 "WA_L@!LZ_\@DGAW "
x 00000070 17:81:9F:80 00:40:00:00 9B:0D:03:0C 02:04:CC:E0 "WA_@@@@@[MCLBDL`"
x 00000080 82:40:E3:08 9F:80:00:40 00:00:C3:11 9B:0D:03:0C "B@cH_@@@@@CQ[MCL"
x 00000090 F0:45:12:01 C0:20:82:40 E2:02:D0:45 E0:3F:C0:40 "pERA@ B@bBPE`?@@"
x 000000A0 82:40:E2:02 D0:A4:E0:3A C0:80:82:40 E2:31:9F:8C "B@bBP$`:@@B@b1_L"
x 000000B0 00:04:01:24 06:C0:A8:00 E3:18:9F:8C 00:04:01:21 "@DA$F@(@cX_L@DA!"
x 000000C0 06:C0:A8:00 E3:12:9F:80 00:40:00:00 9B:0D:03:06 "F@(@cR_@@@@@[MCF"
x 000000D0 02:00:C1:01 82:10:AA:10 E3:08:9F:80 00:40:00:00 "B@AABP*PcH_@@@@@"
x 000000E0 C0:81:9B:0D 03:0C:F0:1A 12:01:9F:80 00:40:00:00 "@A[MCLpZRA_@@@@@"
x 000000F0 9B:0D:03:07 02:04:A8:84 E3:09:9F:80 00:40:00:00 "[MCGBD(DcI_@@@@@"
x 00000100 C0:81:9B:0D 03:0C:D8:73 12:01:E0:08 D0:FF:E0:06 "@A[MCLXsRA`HP?`F"
x 00000110 C4:00:82:04 E2:02:D1:53 E0:01:D2:62 CF:E1:C4:00 "D@BDbBQS`ARbOaD@"
x 00000120 16:01:07:81 97:20:17:08 17:81:9F:88 00:04:05:D6 "VAGAW WHWA_H@DEV"
....
.....
x 000007F0 A6:06:05:A4 9B:00:F0:00 82:40:E3:1C 9B:00:40:01 "&FE$[@p@B@c\[@@A"
x 00000800 AE .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. "."
// 1 = plscsi.main exit int


here is the CDB to dump areas, it also dumps external ram and internal ram, hardware registers, flash area (unique data included).....i've not explored so much, but it looks very interesting :)

DF 00 E2 00 00 ba ba ba ea ea ea where bababa is baseaddress and eaeaea is end address
(endaddress-baseaddress)<=FFE
after all dumped data, it adds 1 byte (sort of checksum)

There seems to be other interesting CDB
during tests, it seemed that DF 00 E2 05 searches for data from disc inserted....i've to look deeply

Can anyone code a little app to dump memory space with easy?
For example it should be helpfull to have an app that takes as imput a base address and a lenght (>FFF) and sends multiple CDB to collect all data required.

Somethign more about enabling this CDB:


ROM:0023AFD0 CDB_table_D0_DF:.long 0xD0000000 ; DATA XREF: Process_incoming_CDB:loc_2236FEo
ROM:0023AFD4 .long ATAPI_D0_unknown
ROM:0023AFD8 .long 0x80000000
ROM:0023AFDC .long 0xD1000000
ROM:0023AFE0 .long ATAPI_D1_unknown
ROM:0023AFE4 .long 0x80000000
ROM:0023AFE8 .long 0xD2000000
ROM:0023AFEC .long ATAPI_D2_unknown
ROM:0023AFF0 .long 0x80000000
ROM:0023AFF4 .long 0xD3000000
ROM:0023AFF8 .long ATAPI_D3_unknown
ROM:0023AFFC .long 0x80000000
ROM:0023B000 .long 0xD4000000
ROM:0023B004 .long ATAPI_D4_unknown
ROM:0023B008 .long 0x80000000
ROM:0023B00C .long 0xD5000000
ROM:0023B010 .long ATAPI_D5_unknown
ROM:0023B014 .long 0x80000000
ROM:0023B018 .long 0xDF000000
ROM:0023B01C .long ATAPI_DF_unknown
ROM:0023B020 .long 0x88000000 ; patched to 80000000 to enable it
ROM:0023B024 .long 0xF9000000
ROM:0023B028 .long ATAPI_command_not_supported



ROM:00223726 mov r4, r0
ROM:00223728 add #8, r0
ROM:0022372A btstl #8, @r0
ROM:0022372C beq loc_223744 ; branch if bit4 is 0
ROM:0022372C ; go on if is set
ROM:0022372C ; disabled CDB has 88
ROM:0022372E ldi:32 #0x404B4, r12 ; don't know, maybe an hardware pin
ROM:0022372E ; maybe can be changed with another CDB
ROM:00223734 ld @r12, r0
ROM:00223736 cmp #0, r0
ROM:00223738 bne loc_223744
ROM:0022373A ldi:32 #ATAPI_command_not_supported, r12
ROM:00223740 call @r12


processing of DF 00 CDB is divided in different functions


ROM:0022588E ldub @(r13, r8), r0 ; 3rd cdb byte
ROM:00225890 ldi:8 #0xD7, r1
ROM:00225892 sub r1, r0
ROM:00225894 ldi:8 #0x19, r12
ROM:00225896 cmp r12, r0
ROM:00225898 bc loc_2258A2 ; branch if CDB was from DF 00 D7 to DF 00 EF
ROM:0022589A ldi:32 #ATAPI_DF_00_error, r12 ; seems to go to cdb error
ROM:002258A0 jmp:D @r12
ROM:002258A2
ROM:002258A2 loc_2258A2: ; CODE XREF: ATAPI_DF_unknown+30j
ROM:002258A2 mov r0, r13 ; from 0 to 18
ROM:002258A4 ; ---------------------------------------------------------------------------
ROM:002258A4 ldi:32 #DF_00_table, r12
ROM:002258AA lsl #2, r13 ; multiply by 4
ROM:002258AC ld @(r13, r12), r12
ROM:002258AE jmp @r12 ; jumps to
ROM:002258AE ; 002258B0 for DF 00 D7
ROM:002258AE ; 00225D08 error
ROM:002258AE ; 002258F6 for DF 00 D9
ROM:002258AE ; 00225CD0 for DF 00 DA
ROM:002258AE ; 00225D08 error
ROM:002258AE ; 00225D08 error
ROM:002258AE ; 00225D08 error
ROM:002258AE ; 00225D08 error
ROM:002258AE ; 00225D08 error
ROM:002258AE ; 0022597C for DF 00 E0
ROM:002258AE ; 00225D08 error
ROM:002258AE ; 00225BBC for DF 00 E2 dumps area
ROM:002258AE ; 00225B2C for DF 00 E3
ROM:002258AE ; 00225D08 error
ROM:002258AE ; 00225D08 error
ROM:002258AE ; 00225D08 error
ROM:002258AE ; 00225D08 error
ROM:002258AE ; 00225D08 error
ROM:002258AE ; 00225D08 error
ROM:002258AE ; 00225D08 error
ROM:002258AE ; 00225D08 error
ROM:002258AE ; 00225D08 error
ROM:002258AE ; 00225D08 error
ROM:002258AE ; 00225D08 error
ROM:002258AE ; 00225CD8 for DF 00 EF
ROM:002258B0 ; ---------------------------------------------------------------------------


To enalbe this CDB, i've patched the fw and flashed back, so this command works only with a patched fw.

As soon as i can verify my flash content, i can share a patched (and not dangerous) fw for VolumeID+DFenable

[arnezami]

I might be misinterpreting what you mean by "unencrypted", however this post (http://www.avsforum.com/avs-vb/showthread.php?p=10058863&&#post10058863) on AVSforum by President of R&B Films (http://www.rbfilms.com/) indicates that none of their HD-DVDs use AACS due to costs. In practical means that means "Chronos".

In addition I can think of a couple other commercially pressed HD-DVD disks that were reported to not utilize AACS: "Running Scared" in Germany, and "Nature's Colors".

To the best of my knowledge, these titles are currently playable by Xbox 360 with an HD-DVD add-on.

I'm sorry. I meant unencrypted recorded discs (inlcuding all menu features etc). I haven't had time to follow the reauthoring/remuxing threads for a long time. Can this be done? (assuming anybody has a HD DVD recorder...)

[arnezami]

with a criptographic specialist like you, we are all in good hope :)

BTW, i'm tracing a vendor specific CDB, it smells of "memory space dump", hope to be on the right track.

keep up the good work!

Seems you're making progress with the reading of the flash stuff. :)

Btw. Just to keep everybody updated. I found something regarding the checksum function. This is the part of memory that is used in the one-way function:

7C637B776BF2C56F01302B67D7FE76AB
82CA7DC959FAF047D4ADAFA2A49CC072
FDB726933F36CCF7A534F1E5D8711531
C704C32396189A051207E28027EB75B2
83091A2C6E1BA05A3B52B3D6E329842F
D153ED00FC205BB1CB6A39BE4C4ACF58
EFD0FBAA4D438533F9457F023C50A89F
A3518F409D92F538B6BC21DAFF10D2F3
0CCDEC13975F1744A7C43D7E5D647319
8160DC4F2A228890EE4614B85EDEDB0B
32E00A3A06495C24D3C262AC959179E4
C8E76D37D58DA94E566CEAF47A6508AE
78BA2E25A61CC6B4DDE81F74BD4B8A8B
3E7066B503480EF63561B957C1869E1D
F8E11198D969948E1E9BE98755CEDF28
A18C0D89E6BF684299410F2D54B016BB

And guess what. This is the S-box used in AES (http://en.wikipedia.org/wiki/Rijndael_S-box) (mind the byte swap):

http://img157.imageshack.us/img157/9650/aessboxtb9.png

So this is confirmation AES is indeed involved. :D

Although right now it doesn't seem to be AES-G. Possibly simpler.

For those who want to know a little bit more about AES here is a really nice visual presentation (http://www.conxx.net/rijndael_anim_conxx.swf).

Regards,

arnezami

[Geremia]

seems you are on the right track too :)

the CDB to dump any memory space is DF 00 E2 00 00 ba ba ba ea ea ea where bababa is baseaddress and eaeaea is end address, max lenght is FFE, but it's disabled by default.
Instead of patching the fw to enable it, i'm actually looking for an already enabled CDB that can poke a byte into ram, this way i could enable the DF command on an original firmware and dump it prior to any flashing.

[arnezami]

seems you are on the right track too :)

the CDB to dump any memory space is DF 00 E2 00 00 ba ba ba ea ea ea where bababa is baseaddress and eaeaea is end address, max lenght is FFE, but it's disabled by default.
Instead of patching the fw to enable it, i'm actually looking for an already enabled CDB that can poke a byte into ram, this way i could enable the DF command on an original firmware and dump it prior to any flashing.

That sounds like a good plan. Is it also possible there is a command to enable this dumping command somehow? You were talking about a possible hardware jumper or something?

Anyway. Great work! :)

I think I've figured out the "one-way" function. Its not AES-G (used by AACS):

http://img92.imageshack.us/img92/1558/aesgyh1.png

But something very similar:

http://img101.imageshack.us/img101/3443/aesjqf9.png

Which I will call AES-J from now on ;). Interestingly in this configuration its not one-way...

This is now the complete picture again:

http://img389.imageshack.us/img389/1362/checksum2sp2.png

If all this is correct and if I can replicate the "scrambling" stuff I should be able to re-create the 16 byte checksum values :).

arnezami

[edit] Mind the E (as opposed to D) in the schematic of AES-J...

[Geremia]

when @(0x404B4) is not 00000000 the DF command will be accepted.

there is ony a place where this is set to 1, but it's hard to trace back and see how to invoke it, atm i'm suspecting something related to 1D/1C command, these commands are vendor specific and are used by the WinVUP flasher, to retrieve some parts of the fw (btw FDC18, FDC04...) and to make the code jump to bootloader.

[Geremia]

GOT IT!!

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

Don't know if all firmware is dumped correctly, because must run plscsi 512times to dump all fw area, but at randomly dump, it seems correct.
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?

[awhitehead]

GOT IT!!

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

Don't know if all firmware is dumped correctly, because must run plscsi 512times to dump all fw area, but at randomly dump, it seems correct.
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?

If you post the sequence information for the chunks, and the exact command you want repeated (basically what plscsi arguments you want), I can probably whip together a quick script (or heck, write a C wrapper to plscsi) in a few minutes.

[Geremia]

Try to dump first 0x100 bytes of firmware with original firmware

E:\HD-DVD\PLSCSI>plscsi.exe -v -p -x "DF 00 E2 00 00 20 00 00 20 00 FF" -i x101
x 00000000 DF:00:E2:00 00:20:00:00 20:00:FF .. .. .. .. .. "_@b@@ @@ @?"
x 00000000 AE:AE:AE:AE AE:AE:AE:AE AE:AE:AE:AE AE:AE:AE:AE "................"
...
x 000000F0 AE:AE:AE:AE AE:AE:AE:AE AE:AE:AE:AE AE:AE:AE:AE "................"
x 00000100 AE .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. "."
x 00000000 70:00:05:00 00:00:00:0A 00:00:00:00 20:00 .. .. "p@E@@@@J@@@@ @"
// x 5 20 sense // x101 (257) residue
// -x0102 = -258 = plscsi.main exit int


Does not work, the sense data tell the CDB is not supported

Then i send this specific command (hard work to trace it, but with some coffeine an nicotine i've found)


E:\HD-DVD\PLSCSI>DFenable.bat

E:\HD-DVD\PLSCSI>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
x 00000000 1D:00:00:00 08:00:00:00 00:00:00:00 00:00:00:00 "]@@@H@@@@@@@@@@@"
x 00000000 88:00:00:04 02:6F:01:00 .. .. .. .. .. .. .. .. "H@@DBoA@"
// 0 = plscsi.main exit int


1D command sends addictional data that contain a subcommand. Subcommand 02 6F with parameter 01 sets (0x404B4) to 1, while 02 6F with parameter 00 clears it.
With plscsi i send 1D command and the addictional data is taked from DFenable.bin, which contains bytes 88 00 00 04 02 6F 01 00

Now that (0x404B4 is set to 1, all disabled commands will be enabled, let's take a look at the DF command to dump areas, let's try again:


E:\HD-DVD\PLSCSI>plscsi.exe -v -p -x "DF 00 E2 00 00 20 00 00 20 00 FF" -i x101
x 00000000 DF:00:E2:00 00:20:00:00 20:00:FF .. .. .. .. .. "_@b@@ @@ @?"
x 00000000 56:31:59:4C 28:22:2D:23 02:01:02:00 00:00:00:00 "V1YL("-#BAB@@@@@"
x 00000010 40:40:00:79 1E:02:4A:14 00:00:00:00 00:00:00:00 "@@@y^BJT@@@@@@@@"
x 00000020 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
x 00000030 4D:43:30:38 31:30:2F:30 33:2F:30:36 00:21:7C:E4 "MC0810/03/06@!|d"
x 00000040 00:20:00:60 00:21:3B:E2 00:21:58:06 00:20:07:A8 "@ @`@!;b@!XF@ G("
x 00000050 00:21:3C:28 00:21:16:52 00:21:26:48 00:20:00:70 "@!<(@!VR@!&H@ @p"
x 00000060 17:81:9F:8C 00:21:8C:9A 9F:1C:C0:04 07:81:97:20 "WA_L@!LZ_\@DGAW "
x 00000070 17:81:9F:80 00:40:00:00 9B:0D:03:0C 02:04:CC:E0 "WA_@@@@@[MCLBDL`"
x 00000080 82:40:E3:08 9F:80:00:40 00:00:C3:11 9B:0D:03:0C "B@cH_@@@@@CQ[MCL"
x 00000090 F0:45:12:01 C0:20:82:40 E2:02:D0:45 E0:3F:C0:40 "pERA@ B@bBPE`?@@"
x 000000A0 82:40:E2:02 D0:A4:E0:3A C0:80:82:40 E2:31:9F:8C "B@bBP$`:@@B@b1_L"
x 000000B0 00:04:01:24 06:C0:A8:00 E3:18:9F:8C 00:04:01:21 "@DA$F@(@cX_L@DA!"
x 000000C0 06:C0:A8:00 E3:12:9F:80 00:40:00:00 9B:0D:03:06 "F@(@cR_@@@@@[MCF"
x 000000D0 02:00:C1:01 82:10:AA:10 E3:08:9F:80 00:40:00:00 "B@AABP*PcH_@@@@@"
x 000000E0 C0:81:9B:0D 03:0C:F0:1A 12:01:9F:80 00:40:00:00 "@A[MCLpZRA_@@@@@"
x 000000F0 9B:0D:03:07 02:04:A8:84 E3:09:9F:80 00:40:00:00 "[MCGBD(DcI_@@@@@"
x 00000100 AE .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. "."
// 1 = plscsi.main exit int


IT WORKS :) :) :)

Now an automatic process for all this is needed, anyone can do it?