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?

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

[Geremia]

hahhahaah, xt5 from xboxhacker found a CDB that solves all your worries.

This does not need a patched firmware at all :) :)

http://www.ingenieria-inversa.cl/files/vid.rar

[tonyp12]

xt5 from xboxhacker found a CDB

Got any link to that post?

[arnezami]

hahhahaah, xt5 from xboxhacker found a CDB that solves all your worries.

This does not need a patched firmware at all :) :)

http://www.ingenieria-inversa.cl/files/vid.rar

You gotta be kidding! :D

Link doesn't work atm.

[generalnewbie]

I just wanted to thank you for clarifying this thread. I just posted an article on my blog i hope i got everything correct. Care to read it? find it here (http://dltv.wordpress.com/2007/04/09/xbox-360-hd-dvd-drive-exposes-volume-id/)






Sure.


Yes.


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


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.


Have I succeeded?

Regards,

arnezami

[Geremia]

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

[FoxDisc]

I think people would prefer to have their back ups decrypted and free from DRM, so there are no strings attached.
I won't dispute that most people would prefer to eliminate the DRM entirely. The problem is that the AACS LA is very likely to begin using the SKB system. Without delving too deeply, the SKB system is going to require more keys than current decryptions require. Disclosing those additional keys means disclosing something about who provided those keys and where they came from. That's their purpose. If you disclose the source of the keys, you make it easier to cut off that source.

In contrast, spoofing the Volume ID on the BCA by modifying the firmware would make fair use backups possible without requiring any keys. If you have the keys and can remove the DRM, then great, but this would provide an alternative when you don't have the keys.

Sometimes half a loaf is better than nothing.

[arnezami]

hahhahaah, xt5 from xboxhacker found a CDB that solves all your worries.

This does not need a patched firmware at all :) :)

http://www.ingenieria-inversa.cl/files/vid.rar

OMG. Its working !!! On my unpatched drive!!!

This is FUN!! :D

How on earth is this done? Some kind of exploit? Or some left over debug CDB command? That would be fun!

I've said it before but this time its really true: the Volume ID is a joke :).

arnezami

[lightshadow]

OMG. Its working !!! On my unpatched drive!!!

This is FUN!! :D

How on earth is this done? Some kind of exploit? Or some left over debug CDB command? That would be fun!

I've said it before but this time its really true: the Volume ID is a joke :).
What? What? What??? What does it do??? =) Please tell us =)

[generalnewbie]

I think the new program the VID.rar file contains the program and source code to get the volume ID without needing to patch the firmware of the HD DVD drive. It is able to get retrieve the Volume ID of the xbox 360 hd dvd drive by another method.

[Geremia]

well, near the DF 00 E2 00 00 ba ba ba ea ea ea command to dump mem, xt5 found a nice
DF 00 E3 00 sa sa sa ea ea ea bb bb tu poke ram :), where sasasa is start address, eaeaea is end address, and bbbb is the 16bit value to write

Now it's posible to write to ram to let the (not patched) volumeID function to pass without being authenticated, just 2 bytes have to be written, because just 2 bytes are checked


ROM:002218DE loc_2218DE: ; CODE XREF: ATAPI_AD_AACS_READ_VOLUMEID+20j
ROM:002218DE ldi:20 #0x164, r0
ROM:002218E2 mul r0, r9 ; r9 = AGID, from 0 to 3
ROM:002218E4 mov mdl, r0
ROM:002218E6 ldi:32 #0x60C1C8, r8 ; probably AGID related ram address
ROM:002218EC add r0, r8
ROM:002218EE ldi:8 #4, r13
ROM:002218F0 ld @(r13, r8), r0
ROM:002218F2 cmp #0, r0
ROM:002218F4 bne loc_221902 ; branch if 60C1CC is not 00000000
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
ROM:00221902 loc_221902: ; CODE XREF: ATAPI_AD_AACS_READ_VOLUMEID+42j
ROM:00221902 ld @r8, r0
ROM:00221904 cmp #5, r0
ROM:00221906 beq:D loc_22191C ; branch if 60C1C8 is 00000005
ROM:00221908 mov r9, r4


this app coded by xt5 does:
enable the DF command
writes 0001 to 60C1CE and 0005 to 60C1CA
reads the volumeId
disable the DF command

[arnezami]

What? What? What??? What does it do??? =) Please tell us =)

It gives the volume ID without patching the drive and without doing AACS auth. Meaning this drive has a HUGE security hole in it :).

[lightshadow]

this app coded by xt5 does:
enable the DF command
writes 0001 to 60C1CE and 0005 to 60C1CA
reads the volumeId
disable the DF command
What a beautiful hack! No traces afterwards.

Keep up the good work =)

[arnezami]

well, near the DF 00 E2 00 00 ba ba ba ea ea ea command to dump mem, xt5 found a nice
DF 00 E3 00 sa sa sa ea ea ea bb bb tu poke ram :), where sasasa is start address, eaeaea is end address, and bbbb is the 16bit value to write

Now it's posible to write to ram to let the (not patched) volumeID function to pass without being authenticated, just 2 bytes have to be written, because just 2 bytes are checked


ROM:002218DE loc_2218DE: ; CODE XREF: ATAPI_AD_AACS_READ_VOLUMEID+20j
ROM:002218DE ldi:20 #0x164, r0
ROM:002218E2 mul r0, r9 ; r9 = AGID, from 0 to 3
ROM:002218E4 mov mdl, r0
ROM:002218E6 ldi:32 #0x60C1C8, r8 ; probably AGID related ram address
ROM:002218EC add r0, r8
ROM:002218EE ldi:8 #4, r13
ROM:002218F0 ld @(r13, r8), r0
ROM:002218F2 cmp #0, r0
ROM:002218F4 bne loc_221902 ; branch if 60C1CC is not 00000000
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
ROM:00221902 loc_221902: ; CODE XREF: ATAPI_AD_AACS_READ_VOLUMEID+42j
ROM:00221902 ld @r8, r0
ROM:00221904 cmp #5, r0
ROM:00221906 beq:D loc_22191C ; branch if 60C1C8 is 00000005
ROM:00221908 mov r9, r4


this app coded by xt5 does:
enable the DF command
writes 0001 to 60C1CE and 0005 to 60C1CA
reads the volumeId
disable the DF command

Deep respect for xt5 and Geremia here. Fabulous work :)

[woah!]

works here aswell :) amazing work too all of you. i checked the key it gave me against the one aacskeys gives me and its the same.

but the drive gives me 8 bits more info at the beginning of the key:

from the drive: 00220000400026061109202157474844564D0000

from aacskeys: 400026061109202157474844564D0000


so what dumper can use a VID not VUK as its key ??

DumpHD looks for a VUK i believe.

[arnezami]

Btw: are there any Toshiba/Samsumg BD drives? ;)

[Mug Funky]

good point on BD drives.

the availability and interoperability of HD-DVD hardware might just be giving Sony a competitive advantage it most certainly should not have... already there's been delays in HD-DVD titles but no corresponding delays in BD titles.

if i had the moolah i'd be buying up hardware and donating it to deserving hacksters :) sadly it seems the cleverest people have sided with HD-DVD, possibly to it's detriment.

here we see DRM turning usual market principles upside down... make a product more competitive and useful and suddenly it's at a disadvantage.

[lightshadow]

I won't dispute that most people would prefer to eliminate the DRM entirely. The problem is that the AACS LA is very likely to begin using the SKB system. Without delving too deeply, the SKB system is going to require more keys than current decryptions require. Disclosing those additional keys means disclosing something about who provided those keys and where they came from. That's their purpose. If you disclose the source of the keys, you make it easier to cut off that source.
Will SKB be an compatible "extension" to the AACS that we know today, or will it break the current hacks and how AACS works?

[LoloMc]

I need to buy one of those readers :D

Thanks guys to share

[FoxDisc]

Will SKB be an compatible "extension" to the AACS that we know today, or will it break the current hacks and how AACS works?

A bit of both. Try reading this:
http://forum.doom9.org/showthread.php?p=986881#post986881

[TiCaL]

Btw: are there any Toshiba/Samsumg BD drives? ;)

Toshiba are the one of the main supporters of HD DVD so it is very unlikely they will come out with a Blu-ray player let alone a drive.

Samsung on the other hand do have a BD Writer, although I cannot seem to find it on their website anymore (it may be outdated). It is listed here though:

SAMSUNG SH-B022
http://www.blu-ray.com/drives/

Maybe someone has this model or can get their hands on one of them.

[Geremia]

About bluray, it will be interesting to see the fw of this drive

Plextor BD-R PX-B900A

The Panasonic MN103 is well known

http://www.cdrinfo.com/Sections/Reviews/Print.aspx?ArticleId=19104

[SuperGoof]

Samsung BD writers for PC do not seem to be popular even if they exist:

http://www.videohelp.com/dvdwriters.php?bdrom=1

But what about Samsung standalone players: BD-P1000 and BD-P1200? They are probably second best selling BD players after PS3. It would be interesting to know what drive they use.

I found pictures of the insides of BD-P1000 here:

http://www.engadgethd.com/2006/06/13/samsung-bd-p1000-hands-on-cracked-open-pored-over/

and that page has a link to a more detailed article here:

http://www.avsforum.com/avs-vb/showthread.php?t=683987&page=2&pp=30

[mrazzido]

i have LiteOn LH-2B1S Bluray writer

from cdrinfo this chip is inside


http://www.cdrinfo.com/Sections/Articles/Sources/L/LiteOn%20LH-2B1S/images/Chipset1.jpg

[Momotte]

works here aswell :) amazing work too all of you. i checked the key it gave me against the one aacskeys gives me and its the same.

but the drive gives me 8 bits more info at the beginning of the key:

from the drive: 00220000400026061109202157474844564D0000

from aacskeys: 400026061109202157474844564D0000


so what dumper can use a VID not VUK as its key ??

DumpHD looks for a VUK i believe.

Yes, I have the same problem, how do we get from the VID to the VUK to get the tools working (since they require VUK)? I know its been discussed, but my math is not that great...

[arnezami]

Yes, I have the same problem, how do we get from the VID to the VUK to get the tools working (since they require VUK)? I know its been discussed, but my math is not that great...

Just use mkb.exe (http://forum.doom9.org/showthread.php?p=953496#post953496) for the moment.

[Momotte]

Just use mkb.exe (http://forum.doom9.org/showthread.php?p=953496#post953496) for the moment.

OK, thanks...

[arnezami]

Yes, I have the same problem, how do we get from the VID to the VUK to get the tools working (since they require VUK)? I know its been discussed, but my math is not that great...

But what I'm wondering is why you are not using aacskeys because that will give you the VUK...

Clearly you have a xbox 306 HD DVD drive and an original disc. So aacskeys should work fine.

Or did you just wanted to know how to use a Volume ID instead of a VUK?

[lightshadow]

Or did you just wanted to know how to use a Volume ID instead of a VUK?
Just curious... How can mkb.exe get the VUK just by having the VID?

[arnezami]

Just curious... How can mkb.exe get the VUK just by having the VID?

The Processing Key is in it ;). So it takes the MKBROM.AACS and the Volume ID and voila it gives a VUK.

evdberg wrote this proggy just after the Processing Key was found...

[jsl]

Samsung BD writers for PC do not seem to be popular even if they exist
AFAIK Samsung never released its SH-B022A/SE-B026A BD writers for whatever reason. So far there are the following "original designed" half height BD writers released (all others are rebadged drives based on these):
LG GBW-H10N
Lite-On LH-2B1S (rebadged drives include BenQ BW1000 and Philips SPD7000)
Panasonic SW-5582 (rebadged drives include Plextor PX-B900A and Sony BWU-100A)
Pioneer BDR-101A

About bluray, it will be interesting to see the fw of this drive

Plextor BD-R PX-B900A

The Panasonic MN103 is well known

Sony BWU-100A is the same drive as the Plextor (both are OEM Panasonic drives) and Sony has released a firmware update for this model here (http://sony.storagesupport.com/blu-ray/downloads/bwu100a/10c2Firmware/BWU100A_10c2.zip).

[FoxDisc]

The HD DVD and DVD Pre-recorded Book says that the KCD is stored in the Copyright Data Section of the lead in area.
It's right after the lsb_64 of the Volume ID. Since you are reading the Volume ID, I wonder if you have found anything in the fw that reads the KCD? It would be interesting to know if the current AACS discs have a KCD on them.

Along the same lines, I notice that there's room in the flash for storing the host revocation list. Have any CDBs for storing the HDL actually been identified?

[dito]

I think it would be highly useful if the BluRay in the PS3 could be patched so it works under Linux... Will be good for people just wanting to use the PS3 as a HTPC...

BTW does the Xbox360 HD-DVD work under linux (are there any drivers?)?

Great work guys!

[Geremia]

The HD DVD and DVD Pre-recorded Book says that the KCD is stored in the Copyright Data Section of the lead in area.
It's right after the lsb_64 of the Volume ID. Since you are reading the Volume ID, I wonder if you have found anything in the fw that reads the KCD? It would be interesting to know if the current AACS discs have a KCD on them.


hum, interesting, i missed this part of aacs stuff :)

[haibane]

The HD DVD and DVD Pre-recorded Book says that the KCD is stored in the Copyright Data Section of the lead in area.
It's right after the lsb_64 of the Volume ID. Since you are reading the Volume ID, I wonder if you have found anything in the fw that reads the KCD? It would be interesting to know if the current AACS discs have a KCD on them.


So suppose the KCD is on disk and the current XBOX360 drive can read it. And the KCD is not encrypted or scrambled in some secret way(The AACS spec seems to say it's store in a way defined in the confidential part of the spec). Then does this mean the KCD mechanism is broken, at least for people who own the current version of XBOX360 HD-DVD players?

[Galileo2000]

So my guess is we need to find PC Blu Ray drive with the same free memory options like Xbox HD DVD drive.

And then we are done.

And AACS is done.

[markrb]

This is great for me. I watch my HD-DVD's strictly from the HD on my HTPC since the 360 drive is too loud for my taste.

Thanks to all of you for your hard work.
I wish these people would wake up and understand that if I couldn't watch my own store bought movies this way I wouldn't be buying them in the first place.

Mark

[FoxDisc]

So suppose the KCD is on disk and the current XBOX360 drive can read it. And the KCD is not encrypted or scrambled in some secret way(The AACS spec seems to say it's store in a way defined in the confidential part of the spec). Then does this mean the KCD mechanism is broken, at least for people who own the current version of XBOX360 HD-DVD players?
From my reading, it appears that the KCD will only be used by integrated standalone devices, not PC host software using drives like the XBOX360 HD-DVD drive. Standalone devices will calculate a media key precursor Kmp with their device keys, not the media key Km that is used by all the software here. The Kmp can be used with the KCD to calculate the Km via AES-G. The purpose of the KCD is to prevent device keys stolen from one type of device (standalone) from being used with another type (PC and software like WinDVD) That's why it's interesting to see if the XBOX 360 drive can read the KCD. If it can read the KCD, then that part of the system has a crack in it.

[FoxDisc]

So my guess is we need to find PC Blu Ray drive with the same free memory options like Xbox HD DVD drive.

And then we are done.

And AACS is done.

AACS has lots of fight left in it. The new software versions of WinDVD and PowerDVD will be hardened making it harder to pull keys out and breaking older methods. The old processing key and the one known device key ( I think one is all that's been found) will be revoked in the next MKB. They'll probably revoke the old software in a new Host Revocation List. They'll bring out the SKB system for traitor tracing. No, I don't think anyone is quite ready to declare victory yet.

[Galileo2000]

AACS has lots of fight left in it. The new software versions of WinDVD and PowerDVD will be hardened making it harder to pull keys out and breaking older methods. The old processing key and the one known device key ( I think one is all that's been found) will be revoked in the next MKB. They'll probably revoke the old software in a new Host Revocation List. They'll bring out the SKB system for traitor tracing. No, I don't think anyone is quite ready to declare victory yet.


Oh well.My bad.

But frankly, I am not sure I understand.

If we can get VUK from HD DVD Xbox without any software player involved, why do we care about the software players at all?

You know a hell more about the whole thing than I do.

Please explain, thank you.

[Sulimo]

AACS has lots of fight left in it. The new software versions of WinDVD and PowerDVD will be hardened making it harder to pull keys out and breaking older methods. The old processing key and the one known device key ( I think one is all that's been found) will be revoked in the next MKB. They'll probably revoke the old software in a new Host Revocation List. They'll bring out the SKB system for traitor tracing. No, I don't think anyone is quite ready to declare victory yet.

And can't they just revoke the HD-DVD addon hardware?

[gulikoza]

If we can get VUK from HD DVD Xbox without any software player involved

You can't get it directly, you still need the processing key (which is the same for all discs...AT THE MOMENT, but it will be changed sooner rather then later).

[lightshadow]

The Processing Key is in it ;). So it takes the MKBROM.AACS and the Volume ID and voila it gives a VUK.

evdberg wrote this proggy just after the Processing Key was found...
I see =) Thanks.

It is not quite related, but what is KCD that people are talking about?

[lightshadow]

Just thinking. Would it be a good idea if the leading hackers exchanged contact information in case Doom9 and/or xboxhacker should be taken down, so you are separated if the forums should be taken down?

If you don't want to give out your real email, then use Sneakemail (http://www.sneakemail.com), which makes an email alias to your real email. I have used it for years, and it just works!

[FoxDisc]

And can't they just revoke the HD-DVD addon hardware?
Yes, using the Drive Revocation List they can revoke drives. I don't know whether individual drives can be revoked (your XBOX 360 HD-DVD drive, but not mine) or if it's just whole classes of drives (all XBOX 360 HD-DVD drives).

[MrDVD]

I think it would be highly useful if the BluRay in the PS3 could be patched so it works under Linux... Will be good for people just wanting to use the PS3 as a HTPC...

BTW does the Xbox360 HD-DVD work under linux (are there any drivers?)?

Great work guys!

Me dont have an PS3 but i think it works already under linux. There is a UDF patch for the kernel to support UDF 2.5. Check ps3news.com

[Galileo2000]

Yes, using the Drive Revocation List they can revoke drives. I don't know whether individual drives can be revoked (your XBOX 360 HD-DVD drive, but not mine) or if it's just whole classes of drives (all XBOX 360 HD-DVD drives).

But why is it important? I will not be able to play HD DVD movie from the drive, but I still will be able to use it for decryption, no?

[bourke]

It gives the volume ID without patching the drive and without doing AACS auth. Meaning this drive has a HUGE security hole in it :).

Heads off to buy stockpile of these drives - they're only about US$110 here at the moment (Australia).

They could be worth a mint when they eventually patch the drive firmware LOL!

[bourke]

But why is it important? I will not be able to play HD DVD movie from the drive, but I still will be able to use it for decryption, no?

Sure you can read the Volume IDs (and the encrypted disc contents) using this drive - however you still need keys (e.g. a processing key) in order to decrypt those files.

They will be revoking all such publicly known decryption keys as sure as day follows night.

What we need to do is find another processing key... and not release it until about one month from now ;-)

I wonder if this time they will use completely different keys for Blu-Ray and HD-DVD?!

[FoxDisc]

I don't know whether individual drives can be revoked (your XBOX 360 HD-DVD drive, but not mine) or if it's just whole classes of drives (all XBOX 360 HD-DVD drives).But why is it important? I will not be able to play HD DVD movie from the drive, but I still will be able to use it for decryption, no?

That's two questions. Why is it important? Mainly we want to understand what can and can't be done. I suspect that they would not turn off all legitimate XBOX 360 drives with a DRL revocation just to get at some hackers who could probably get around the revocation. I also have my doubts that there is enough space on an AACS disc to individually revoke specific drives, which leads me to guess that DRL is not a big issue. I suppose they might have some way of forcing people to flash upgrade the drives, then they could revoke the old unflashed versions, but even that seems unlikely. Finally, I'm not sure we know where the DRL revocation would be stored (If I saw this in the specs, I've forgotten - arnezami, do you recall?). Is it in the drive, the software? Right now it looks like there would be ways to get around a stored DRL list, but only time will tell for certain.

As to whether you could still use a DRL revoked drive to decrypt - that mostly would depend on what they've changed in the encryption. I agree, the drive could probably still be used to read everything on the encrypted AACS disc with the control that's been gained over the firmware, but will you have all the required decryption DK and SK keys to work through the MKB and the SKB? Again, only time will tell for certain.

[Galileo2000]

Sure you can read the Volume IDs (and the encrypted disc contents) using this drive - however you still need keys (e.g. a processing key) in order to decrypt those files.

They will be revoking all such publicly known decryption keys as sure as day follows night.

What we need to do is find another processing key... and not release it until about one month from now ;-)

I wonder if this time they will use completely different keys for Blu-Ray and HD-DVD?!


This is understandable.

Processing keys will change, like you said.

New keys will have to be found.

But hardware revocation is irrelevant.

[FoxDisc]

What we need to do is find another processing key... and not release it until about one month from now ;-)

Yes, another processing key will almost certainly be needed. Right now, one processing key (plus the Volume ID), is all that's needed to decrypt all of the movie on all discs. Note the two "all"s in that sentence. What may not be apparent, is that 1) if they begin using the SKB system, the new processing key will only decrypt portions of the movie (most, but not all). At up to 32 points in the movie you will need other keys (derived from the six SKBs on the disc and secret Sequence Keys stored in the player). 2) The second limitation, is that they are not required to use the same processing key for all discs (or for HD/BR as you noted).

It should be interesting to see what's on the next AACS discs that are released.

[FoxDisc]

hardware revocation is irrelevant.

I'm inclined to agree - but there is an opportunity for the AACS LA to make a huge PR blunder by turning off legitimate drives. People who buy discs may understand that DRM prevents them from copying the discs, but people who buy hardware usually don't understand that the AACS DRM can permanently turn off their hardware so it can't play new discs and it won't even play the same discs it would play last week.

[Galileo2000]

I'm inclined to agree - but there is an opportunity for the AACS LA to make a huge PR blunder by turning off legitimate drives. People who buy discs may understand that DRM prevents them from copying the discs, but people who buy hardware usually don't understand that the AACS DRM can permanently turn off their hardware so it can't play new discs and it won't even play the same discs it would play last week.

We are dangerously close to the legal waters now, but let me say that such action would be a kiss of death to any organization or company which does such things.

I put YOUR DISC into MY DRIVE and YOUR DISC killed MY DRIVE and you are telling me just that?

[bourke]

Yes, another processing key will almost certainly be needed. Right now, one processing key (plus the Volume ID), is all that's needed to decrypt all of the movie on all discs. Note the two "all"s in that sentence. What may not be apparent, is that 1) if they begin using the SKB system, the new processing key will only decrypt portions of the movie (most, but not all). At up to 32 points in the movie you will need other keys (derived from the six SKBs on the disc and secret Sequence Keys stored in the player). 2) The second limitation, is that they are not required to use the same processing key for all discs (or for HD/BR as you noted).


Yes, arnezami explained this early on in his 'Understand AACS (Subset-Difference)' thread ;-)

I hope they do use different keys for Blu-Ray and HD-DVD - and that we crack the Blu-Ray one(s) first (and much earlier) - that way some studios may shift camps!

Just think - hackers may actually be able to influence the outcome of the format war :-)

After all - I only want to be able to convert region-coded Blu-Ray movies into non-region-coded HD-DVDs - something entirely legal here in Australia :-)


It should be interesting to see what's on the next AACS discs that are released.

We're all looking forward to the fun and games ahead :-)

[FoxDisc]

I see =) what is KCD that people are talking about?

Key Conversion Data. It's not used by software players and is optional for hardware players. Its part of the confidential spec, but it's stored on an AACS disc in a known location, so it's interesting to see 1) if it's currently in use (since it's optional) and 2) if the drives used by software players can even see it (since software players aren't supposed to be able to get it.)

[SuperGoof]

I'm not sure we know where the DRL revocation would be stored. Is it in the drive, the software?

To my understanding, according to the specs drives take care of HRLs, while hosts take care of DRLs. In this case, it is up to PowerDVD/WinDVD where they decide to store DRLs. Based on my experience with blu-ray regions, I think they will probably store DRLs in Windows Registry. :)

[FoxDisc]

To my understanding, according to the specs drives take care of HRLs, while hosts take care of DRLs. In this case, it is up to PowerDVD/WinDVD where they decide to store DRLs. Based on my experience with blu-ray regions, I think they will probably store DRLs in Windows Registry. :)

That makes sense, but it's easier to get around such a revocation (reinstall Windows, then player) than it would be to get around a DRL that's also stored on the drive itself. I really doubt we'll see DRLs on the next discs anyway.

[Boing99]

A few comments and answers:

Current AACS disks (at least those I have looked at) do have a KCD, and (at least some) standalone players have device key sets that require a KCD. That also means that the drives in those players have a modified firmware which allows reading the KCD, using undocumented CDBs. Incidentally, on at least some of the standalone players the drive firmware is modified even more heavily, e.g. to allow the player to read the volume ID and KCD without exchanging host/drive keys first :). The AACS specs already hinted at that, and it has been confirmed in real life.

FoxDisc: I agree with the fight not being over yet, but behind the scenes player software, drives and standalones have been penetrated by several people a LOT deeper than has been announced so far. No use in tipping AACS-LA off about the targets and methods quite yet, as long as disk backups can already be made with what has been published so far. Don't be surprised though if the stream of VUKs continues after the first AACS key revocation almost like before. We might even see the new processing key (assuming they still only use a single one for all disks) quite quickly.

The problem for AACS-LA and movie studios is that some hardware and software manufacturers have been sloppy in their protection systems while rushing products to market, so we are seeing drives and standalones that can be updated without public key code signing (X-Box add-on and others), software players that do not handle CRLs, software players with insufficient code armor, software players that keep keys lying around in memory etc. etc. Some of these mistakes are probably irrecoverable except possibly to some degree by using BD+ and SKB. Reverse-engineering is alive and well...

About SKB: I doubt we will see this before the end of the year, and even after that it will probably only be used in certain high-profile titles, because it would be a PITA for movie companies to use. Mastering movies without SKB is relatively simple, as most the burden of MKB, revocation etc. lies with replicators, but with SKB the movie companies probably will have to do a lot more of the work. The question is: will movie companies continue to invest a lot more money, time, training etc. into a system which so far AACS-LA has not been able to demonstrate to be more effective in preventing copying than CSS, despite of the huge effort put into it.

Also, if software players will continue to be penetrated as easily as they have been in the past then there is no point in SKB (except for the one-time effort required by authors of ripping tools to support it in their software), because all sold copies of the same version of a player share the same keys. The use of SKB would just shift the race to a slightly different playing field: can hackers extract device keys and sequence keys out of players more quickly than AACS-LA can revoke and renew them ? My guess (assuming the HD formats continue to penetrate the market) most likely, yes. That would make the SKB system completely useless for AACS-LA, since all it would tell them shortly after each round of revocation is "Win/PowerDVD has been penetrated again." Doh :)

About drive revocation: I believe individual units can be revoked. It all depends on whether drive ids are assigned per unit or per model. The usual way to test is: if the drive id looks small and simple (like the host id in PowerDVD or WinDVD) then it was probably assigned per model. If it looks complex and irregular, like a serial number, then it is probably unique per drive. Mine looks like a serial number. You can find it in the drive certificate returned by the drive during an AACS key exchange. Just look at a packet trace. Of course, regardless, drive revocation does not affect ripping tools at all, only commercial players. And (at least some) standalones do not use drive keys at all, so their drives can never be revoked.

The PS3 drive does work under Linux (using either a UDF kernel patch or using ripping software that has UDF support built-in). However only file reading works, not the AACS key exchange, because that appears to be blocked by the Hypervisor. This means you will have to get the Volume ID with different hardware.

[Galileo2000]

Wow Boing99 such an excellent post overall.

A few comments and answers:

Current AACS disks (at least those I have looked at) do have a KCD, and (at least some) standalone players have device key sets that require a KCD. That also means that the drives in those players have a modified firmware which allows reading the KCD, using undocumented CDBs. Incidentally, on at least some of the standalone players the drive firmware is modified even more heavily, e.g. to allow the player to read the volume ID and KCD without exchanging host/drive keys first :). The AACS specs already hinted at that, and it has been confirmed in real life.

FoxDisc: I agree with the fight not being over yet, but behind the scenes player software, drives and standalones have been penetrated by several people a LOT deeper than has been announced so far. No use in tipping AACS-LA off about the targets and methods quite yet, as long as disk backups can already be made with what has been published so far. Don't be surprised though if the stream of VUKs continues after the first AACS key revocation almost like before. We might even see the new processing key (assuming they still only use a single one for all disks) quite quickly.

And we have seen it by now :D

The problem for AACS-LA and movie studios is that some hardware and software manufacturers have been sloppy in their protection systems while rushing products to market, so we are seeing drives and standalones that can be updated without public key code signing (X-Box add-on and others), software players that do not handle CRLs, software players with insufficient code armor, software players that keep keys lying around in memory etc. etc. Some of these mistakes are probably irrecoverable except possibly to some degree by using BD+ and SKB. Reverse-engineering is alive and well...

Good.

About SKB: I doubt we will see this before the end of the year, and even after that it will probably only be used in certain high-profile titles, because it would be a PITA for movie companies to use. Mastering movies without SKB is relatively simple, as most the burden of MKB, revocation etc. lies with replicators, but with SKB the movie companies probably will have to do a lot more of the work. The question is: will movie companies continue to invest a lot more money, time, training etc. into a system which so far AACS-LA has not been able to demonstrate to be more effective in preventing copying than CSS, despite of the huge effort put into it.

I bet they will. They still believe they are invincible. They are also slow and if they stop now, quite a few heads will be rolling. And those heads don't want to be rolling. Until someone who is smart and practical will step in, analyze the situation, losses in manufacturing, losses in sales and tell them STFU.

Also, if software players will continue to be penetrated as easily as they have been in the past then there is no point in SKB (except for the one-time effort required by authors of ripping tools to support it in their software), because all sold copies of the same version of a player share the same keys. The use of SKB would just shift the race to a slightly different playing field: can hackers extract device keys and sequence keys out of players more quickly than AACS-LA can revoke and renew them ? My guess (assuming the HD formats continue to penetrate the market) most likely, yes. That would make the SKB system completely useless for AACS-LA, since all it would tell them shortly after each round of revocation is "Win/PowerDVD has been penetrated again." Doh :)

About drive revocation: I believe individual units can be revoked. It all depends on whether drive ids are assigned per unit or per model. The usual way to test is: if the drive id looks small and simple (like the host id in PowerDVD or WinDVD) then it was probably assigned per model. If it looks complex and irregular, like a serial number, then it is probably unique per drive. Mine looks like a serial number. You can find it in the drive certificate returned by the drive during an AACS key exchange. Just look at a packet trace. Of course, regardless, drive revocation does not affect ripping tools at all, only commercial players. And (at least some) standalones do not use drive keys at all, so their drives can never be revoked.

The PS3 drive does work under Linux (using either a UDF kernel patch or using ripping software that has UDF support built-in). However only file reading works, not the AACS key exchange, because that appears to be blocked by the Hypervisor. This means you will have to get the Volume ID with different hardware.

[FoxDisc]

A few comments and answers:
All very interesting, and lots of good points. Thanks!

with SKB the movie companies probably will have to do a lot more of the work.

If the movie company needs to come up with eight variations of the movie at each of 32 points, this would be a lot more effort, but I was guessing that this was really just an automated process - the movie company provides the movie and an automated tool picks 32 segments and forms 8 watermarked variants for each.

if software players will continue to be penetrated as easily as they have been in the past then there is no point in SKB (except for the one-time effort required by authors of ripping tools to support it in their software),

The LA might consider it to be worthwhile to force hackers through the one-time effort. It makes it harder because there are lots more keys involved. Plus, they may just want to keep an eye on whether the keys are all coming from the software players and not the hardware. Finally, they may need to confirm which software players are being broken so they can point the finger at a specific software company without them all saying "It wasn't me - it was the other guy who wrote sloppy code!"

Nonetheless, I won't be surprised if they don't add SKBs immediately. They may just want to see how well hardening the software works before giving clues on how the SKB system functions. They might even be concerned that poorly written hardware and software players could malfunction as they try to play new discs with a new complex SKB system.

[stewwy]

revoke the 260 hd-dvd I bought it legitimatly with a copy of KK, They would be in court so fast for criminal damage their feet wouldn't touch the floor. I suspect they know this so hardware revocation is more a threat to the manufacturers than anything else

[Momotte]

But what I'm wondering is why you are not using aacskeys because that will give you the VUK...

Clearly you have a xbox 306 HD DVD drive and an original disc. So aacskeys should work fine.

Or did you just wanted to know how to use a Volume ID instead of a VUK?

yes, that was just a curiosity question... I have a xbox drive+pc and aacskeys works fine, but you never know, two methods are better than only one ;)

[Gradius]

Isn't hard at all to build a little circuit to turn this drive 100% stealth proof. Just desolder the original flash, then build the circuit, put two sockets with two flash memories there, and a switcher. 1 flash IC will contain the hacked one, and the other the original one. You can even put a LED with ON (hacked) / OFF (original) on it. :devil:

Gradius

[Pelican9]

Isn't hard at all to build a little circuit to turn this drive 100% stealth proof. Just desolder the original flash, then build the circuit, put two sockets with two flash memories there, and a switcher. 1 flash IC will contain the hacked one, and the other the original one. You can even put a LED with ON (hacked) / OFF (original) on it. :devil:

Gradius

It's easier with a double capacity flash with first half containing the original fw and the second half containing the patched fw and you can switch the most upper address pin.

[greath]

Nonetheless, I won't be surprised if they don't add SKBs immediately. They may just want to see how well hardening the software works before giving clues on how the SKB system functions. They might even be concerned that poorly written hardware and software players could malfunction as they try to play new discs with a new complex SKB system.

I agree. For all we know the certification process may be sloppy and some drives may not even support SKB. Who knows what sort of approval process each drive is subjected to. It could be better for AACS to use SKB now and find out that some drives don't work with it when only a few thousand have been sold rather than wait for a few million to be out in the field and to infuriate several million people.

[mlansell]

revoke the 260 hd-dvd I bought it legitimatly with a copy of KK, They would be in court so fast for criminal damage their feet wouldn't touch the floor. I suspect they know this so hardware revocation is more a threat to the manufacturers than anything else

They don't need to do anything to your drive to revoke it, so no damage will have taken place. Your drive will continue to play old disks.

Your only legal recourse would be a claim against the drive manufacturer on the grounds that it's not fit for purpose (i.e it won't play any new disks).

I guess this is OT, so if you want to discus further, this should move to a new thread.

Mal

[Boing99]

They don't need to do anything to your drive to revoke it, so no damage will have taken place. Your drive will continue to play old disks.


Actually that is not true.

There are two different kinds of revocation in AACS that people tend to confuse: one is the "forced" revocation of device keys. There is no workaround for that in software, but it only affects new disks. The other one is the completely separate "cooperative" revocation of players and drives based on their host/drive certificates, implemented by Certificate Revocation Lists. Drive revocation requires the cooperation of the player, and player revocation requires the cooperation of the drive. This type of revocation is supposed to be persistent (stored in NV-RAM or an encrypted file required by the player) and affects ALL disks, not just new disks.

On a related topic, I am still a little puzzled why Corel states that updates have to be downloaded from the drive manufacturer's web site (instead of updating only WinDVD from their website). That comment suggests drive firmware updates are required, too. I can only come up with two explanations for that:

One is that they may be planning a mass revocation of drive keys for at least some drive models. Not sure why, but the only obvious explanation I have for that is that some drives might not support player revocation correctly in their current firmware, and that AACS-LA may want to force new firmware onto those drives to ensure revocation of the compromised host private keys.

The other possible explanation is that they may be rolling out and enforcing Bus Encryption to plug the various volume id retrieval holes. That would be an interesting new challenge :)

[bourke]

I agree. For all we know the certification process may be sloppy and some drives may not even support SKB.

I thought SKB compatibility is dependent soley on the player - not the drive?!

[Fahzuu]

On a related topic, I am still a little puzzled why Corel states that updates have to be downloaded from the drive manufacturer's web site (instead of updating only WinDVD from their website). That comment suggests drive firmware updates are required, too. I can only come up with two explanations for that:


First about the drive revocation: each XBOX360 drives seems to have a different Drive ID (at least the two, I've had a look at). So revocation of the complete "class" of XBOX360 drives seems to be completely out of the question.

Second: I think I can add a third explanation to your two, but that one is a lot less startling.
The exact phrase was:

"[...]security update from your PC or Drive manufacturer's websites[...]".

The point is that WinDVD8/HD is usually only available as an OEM version that comes with certain notebooks (apart from that infamous japanese standalone version).
So I suppose the above terminology simply refers to the fact, that the notebook manufacturers will be providing the update for download, being the OEM vendors.
Not sure though, what "or Drive" means exactly, but I'm quite certain, WinDVD/HD was bundled with a number of drives as well, so this would be the same then...

Simple and maybe disappointing :) explanation.

[greath]

I thought SKB compatibility is dependent soley on the player - not the drive?!

Sorry, I meant player as in the complete system.

[FoxDisc]

There are two different kinds of revocation in AACS that people tend to confuse: one is the "forced" revocation of device keys.
I tend to think of this type of revocation as "implicit" revocation. The revoked device searches for the keys it can decrypt in the MKB, but never finds them.

The other one is the completely separate "cooperative" revocation of players and drives based on their host/drive certificates, implemented by CRLs.
I think of this as "explicit" revocation because there are explicit "Revocation Lists" on the disc. There are three such lists and I don't think you should call them CRLs. "CRL" is defined in the specs as one of the three - the "Content Revocation List," while you are talking about the other two - the Drive Revocation List and the Host Revocation List.

[Boing99]

First about the drive revocation: each XBOX360 drives seems to have a different Drive ID (at least the two, I've had a look at). So revocation of the complete "class" of XBOX360 drives seems to be completely out of the question.

Not necessarily. The CRLs use ID ranges, and up to 65536 consecutive IDs can be revoked in a single entry, taking up only 8 bytes of space.

The point is that WinDVD8/HD is usually only available as an OEM version that comes with certain notebooks (apart from that infamous japanese standalone version).
So I suppose the above terminology simply refers to the fact, that the notebook manufacturers will be providing the update for download, being the OEM vendors.
Not sure though, what "or Drive" means exactly, but I'm quite certain, WinDVD/HD was bundled with a number of drives as well, so this would be the same then...

Simple and maybe disappointing :) explanation.

But somewhat comforting :). Makes sense, thanks.

[Boing99]

I think of this as "explicit" revocation because there are explicit "Revocation Lists" on the disc. There are three such lists and I don't think you should call them CRLs. "CRL" is defined in the specs as one of the three - the "Content Revocation List," while you are talking about the other two - the Drive Revocation List and the Host Revocation List.

Mmmh, ok... In the wider security community "CRL" usually means "Certificate Revocation List", which is what the Host and Drive revocation lists are and what I meant, but you are right, it looks like AACS-LA redefined that acronym to mean "Content Revocation List". Too bad, redefining acronyms only creates confusion...

[lightshadow]

Too bad, redefining acronyms only creates confusion...
It is part of the AACS DRM specs. =)

[legoman666]

http://it.slashdot.org/it/07/04/12/164228.shtml

heh.

[arnezami]

A few comments and answers:

Current AACS disks (at least those I have looked at) do have a KCD, and (at least some) standalone players have device key sets that require a KCD. That also means that the drives in those players have a modified firmware which allows reading the KCD, using undocumented CDBs. Incidentally, on at least some of the standalone players the drive firmware is modified even more heavily, e.g. to allow the player to read the volume ID and KCD without exchanging host/drive keys first :). The AACS specs already hinted at that, and it has been confirmed in real life.

FoxDisc: I agree with the fight not being over yet, but behind the scenes player software, drives and standalones have been penetrated by several people a LOT deeper than has been announced so far. No use in tipping AACS-LA off about the targets and methods quite yet, as long as disk backups can already be made with what has been published so far. Don't be surprised though if the stream of VUKs continues after the first AACS key revocation almost like before. We might even see the new processing key (assuming they still only use a single one for all disks) quite quickly.

The problem for AACS-LA and movie studios is that some hardware and software manufacturers have been sloppy in their protection systems while rushing products to market, so we are seeing drives and standalones that can be updated without public key code signing (X-Box add-on and others), software players that do not handle CRLs, software players with insufficient code armor, software players that keep keys lying around in memory etc. etc. Some of these mistakes are probably irrecoverable except possibly to some degree by using BD+ and SKB. Reverse-engineering is alive and well...

About SKB: I doubt we will see this before the end of the year, and even after that it will probably only be used in certain high-profile titles, because it would be a PITA for movie companies to use. Mastering movies without SKB is relatively simple, as most the burden of MKB, revocation etc. lies with replicators, but with SKB the movie companies probably will have to do a lot more of the work. The question is: will movie companies continue to invest a lot more money, time, training etc. into a system which so far AACS-LA has not been able to demonstrate to be more effective in preventing copying than CSS, despite of the huge effort put into it.

Also, if software players will continue to be penetrated as easily as they have been in the past then there is no point in SKB (except for the one-time effort required by authors of ripping tools to support it in their software), because all sold copies of the same version of a player share the same keys. The use of SKB would just shift the race to a slightly different playing field: can hackers extract device keys and sequence keys out of players more quickly than AACS-LA can revoke and renew them ? My guess (assuming the HD formats continue to penetrate the market) most likely, yes. That would make the SKB system completely useless for AACS-LA, since all it would tell them shortly after each round of revocation is "Win/PowerDVD has been penetrated again." Doh :)

About drive revocation: I believe individual units can be revoked. It all depends on whether drive ids are assigned per unit or per model. The usual way to test is: if the drive id looks small and simple (like the host id in PowerDVD or WinDVD) then it was probably assigned per model. If it looks complex and irregular, like a serial number, then it is probably unique per drive. Mine looks like a serial number. You can find it in the drive certificate returned by the drive during an AACS key exchange. Just look at a packet trace. Of course, regardless, drive revocation does not affect ripping tools at all, only commercial players. And (at least some) standalones do not use drive keys at all, so their drives can never be revoked.

The PS3 drive does work under Linux (using either a UDF kernel patch or using ripping software that has UDF support built-in). However only file reading works, not the AACS key exchange, because that appears to be blocked by the Hypervisor. This means you will have to get the Volume ID with different hardware.

Very interesting and encouraging. :)

Btw: you are incredibly well informed when it comes to the workings of AACS. I love your precision and deep understanding of how things work. And your thoroughness makes you very trustworthy...

When the time is ready I would like to hear more about the efforts being made :).

Regards,

arnezami

PS. Personally I'm most "worried" about the time consumption it would take to figure out both BD+ and Sequence Keys. I'm not impressed by BD+ itself (I think breaking it amounts to figuring out the "100 lines of code" for the VM and the BD+ keys hidden in a software player) but it will take time to iron things out (the first time they introduce it). I wonder btw if they would introduce both BD+ and Sequence Keys since they both have an effect of small parts of the content and therefore are highly sensitive to implementation problems. It would be more advantageous to us if they would introduce them one by one. And it would (have) be(en) a joke if they just changed the MKB and HRL.

[FoxDisc]

When the time is ready I would like to hear more about the efforts being made :).

You are not the only one who would like to hear more when the time is right, but there is no hurry.

It comes as no surprise to hear that there is lots going on behind the scenes. One would have expected reverse engineering tools (Olly, Ida, Softice and friends) to have been heavily used against the software players, yet very little has leaked out about attacks from this direction that must be going on. It's all been USB sniffing, memory dumps and crypto known-text attacks.

[xt5]

hi, sorry for being late in this party, but doom9 posting politics seems a little crap, because you can post the first 5 days you got your account.

I'm very proudly on the work of people on this forum, intended to defeat DRM stuff, specially for the lastest advances of arnezami and Geremia :)

if you have a MATSHITA UJ-820B, UJ-822B, UJ-825, SW-9583, SW-9573, time, and your an "advanced user" PM.

does anybody know what is the chipset of the PS3 ODD??

[arnezami]

hi, sorry for being late in this party, but doom9 posting politics seems a little crap, because you can post the first 5 days you got your account.

I'm very proudly on the work of people on this forum, intended to defeat DRM stuff, specially for the lastest advances of arnezami and Geremia :)

if you have a MATSHITA UJ-820B, UJ-822B, UJ-825, SW-9583, SW-9573, time, and your an "advanced user" PM.

does anybody know what is the chipset of the PS3 ODD??

Welcome xt5 :).

And thanks again for your help.

If you have any issues/questions regarding AACS encryption stuff I'm your man ;).

Concerning the PS3 drive: I would be very interested to see if we can find a way to retrieve the fw for a PS3 drive. In my eyes there is a lot to be gained from that. The BD drive inside the PS3 is by far the most sold BD drive and running linux the Volume ID is currently not even accessible (blocked by the hypervisor). So there is a lot of "mystery" in this area.

I also understand from avs forums (http://www.avsforum.com/avs-vb/showthread.php?p=10290836&&#post10290836) (also here (http://www.avsforum.com/avs-vb/showthread.php?p=10291069&&#post10291069)) that MS may start talking to Toshiba whether its possible to do a patch on the HD DVD drive using the xbox 360. If they were to do this it would be nice if we could prevent it from doing this: by looking at how it would normally detect the fw version and then change the fw to make it look like it has already been patched (it may be more complicated than that of course but its probably good to take a look at).

Just so you know: in my opinion the ultimate goal when it comes to analyzing fw's is I believe figuring out the way the KCD is stored on the disc (which may be very similar to the way the Volume ID is stored on the disc). If we were to figure this out we could teach our PC drives to act like a standalone KCD enabled system. This would enable us to use the Device Keys from standalones to decrypt discs on our PCs. Btw: the KCD is simply a (16 byte) value to be retrieved from the disc but only (certain) standalones can do this. But this is not a short term goal because its probably very time consuming project.

Anyway keep up the good work :).

Regards,

arnezami

[blutach]

hi, sorry for being late in this party, but doom9 posting politics seems a little crap, because you can post the first 5 days you got your account.
Welcome to the forum. Sorry you feel that way, but those are our rules and they apply to everybody. I trust the world didn't stop turning while you waited and got to know us a bit better by lurking.

Again, welcome.

Regards

[Geremia]

Just so you know: in my opinion the ultimate goal when it comes to analyzing fw's is I believe figuring out the way the KCD is stored on the disc (which may be very similar to the way the Volume ID is stored on the disc). If we were to figure this out we could teach our PC drives to act like a standalone KCD enabled system. This would enable us to use the Device Keys from standalones to decrypt discs on our PCs. Btw: the KCD is simply a (16 byte) value to be retrieved from the disc but only (certain) standalones can do this. But this is not a short term goal because its probably very time consuming project.

arnezami

I'm just working on this, but have more trouble than expected, and i've still a lot of code to trace, but at first look, i'm thinking that they secured the system lead-in (not the data lead-in, i can read it) someway, maybe with wrong ECC, maybe different track pitch...something similar.

[arnezami]

I'm just working on this, but have more trouble than expected, and i've still a lot of code to trace, but at first look, i'm thinking that they secured the system lead-in (not the data lead-in, i can read it) someway, maybe with wrong ECC, maybe different track pitch...something similar.

This post/thread might also be interesting for your purpose.

http://forum.doom9.org/showthread.php?p=956065#post956065

[Geremia]

oh yes, but my problem is about reading PSN prior than about PSN 026B00 (i've not checked exactly, but +-100 this is the last PSN i can read backward), then errors about mechanism laser pointing.
Actually i'm looking at read CD command to see if i can raw read something, but maybe 01Fxxx psn has not the same track/sector structure of PSN > 026B00.....maybe i must go back tracing the AD format 15 cdb (read CDS) ans see if i can extend the area with simply poking ram

http://img95.imageshack.us/img95/8577/leadinij3.png

BTW, data lead-in contains some data, some "MKB" text

[arnezami]

oh yes, but my problem is about reading PSN prior than about PSN 026B00 (i've not checked exactly, but +-100 this is the last PSN i can read backward), then errors about mechanism laser pointing.
Actually i'm looking at read CD command to see if i can raw read something, but maybe 01Fxxx psn has not the same track/sector structure of PSN > 026B00.....maybe i must go back tracing the AD format 15 cdb (read CDS) ans see if i can extend the area with simply poking ram

http://img95.imageshack.us/img95/8577/leadinij3.png

BTW, data lead-in contains some data, some "MKB" text


This may be of interest and might explain this behaviour :):

On the other hand, HD-DVD offers a single capacity (15 GB) with a fixed pit length. This is actually not truly the case, because the pit length changes on a given HD-DVD disc: indeed, if the data area uses minimum pit length of 204 µm, the so called System Lead In and System Lead Out areas use a minimum pit length of 408 um. The purpose of these half-density regions is all the more puzzling that these pits are there even larger the ones on a DVD-ROM, which is pretty strange for a blue laser disc. Toshiba hinted that this large pit size had been chosen to guarantee that this region will be readable even when pits are badly defined on the disc.

taken from here:

http://www.cdfreaks.com/reviews/Blu-ray-vs_-HD-DVD/Differences.html

arnezami

[Geremia]

wow :)
ehehehe
this clears all my suspicions, much thanks arnezami :)

So, now i've only to see where this info is stored in ram, and mainly what is the value for double the pitch,...maybe simply double that value.

but damn, i've to go to work in half an hour :(

[arnezami]

wow :)
ehehehe
this clears all my suspicions, much thanks arnezami :)

So, now i've only to see where this info is stored in ram, and mainly what is the value for double the pitch,...maybe simply double that value.

but damn, i've to go to work in half an hour :(

If I'm not mistaken the Volume ID is (somehow) stored in the system lead-in area. So tracing the Volume ID retrieval command should lead to something that can read this area. I guess... :)

[Geremia]

yes, but actually i'm near the solution for reading all sectors, just need to spot the right ram address to patch for playing with track/pit density, but i can't do it prior to late night :(

[arnezami]

yes, but actually i'm near the solution for reading all sectors, just need to spot the right ram address to patch for playing with track/pit density, but i can't do it prior to late night :(

ah. ok.

[Jeremy Duncan]

Link (http://news.digitaltrends.com/news_printerfriendly12663.html)

A lot of people have bought Xbox 360 HD DVD drives for their HTPC.
And now because you have cracked it, they are going to break the compatibility the drive has with new movies.

They want you to post that you have done this crack successfully then they will break the drives compatibility.

How do you think they will make money if people stop buying their equipment to buy their movies.
People will stop buying Xbox drives to play movies on their htpc, so will they buy external drives that have bloated prices ?
No they won't.
So you've just cut out a major portion of the enthusiast market with the genius crack you've made.

[Pelican9]

Link (http://news.digitaltrends.com/news_printerfriendly12663.html)

A lot of people have bought Xbox 360 HD DVD drives for their HTPC.
And now because you have cracked it, they are going to break the compatibility the drive has with new movies.

They want you to post that you have done this crack successfully then they will break the drives compatibility.

How do you think they will make money if people stop buying their equipment to buy their movies.
People will stop buying Xbox drives to play movies on their htpc, so will they buy external drives that have bloated prices ?
No they won't.
So you've just cut out a major portion of the enthusiast market with the genius crack you've made.
You are wrong. Read more about this thing.
Anyway, lot of people bought the XBOX HD DVD drive because it can play their legally bought movies without any restriction, thanks to this people here who working on breaking AACS LA.

[Jeremy Duncan]

You are wrong. Read more about this thing.
Anyway, lot of people bought the XBOX HD DVD drive because it can play their legally bought movies without any restriction, thanks to this people here who working on breaking AACS LA.

I'm not fully understanding your point ?
They will make the HD DVD Drive for the Xbox360 unable to play new movies on a HTPC.
You understand that point ?
Where is the freedom in that ?

[Galileo2000]

I'm not fully understanding your point ?
They will make the HD DVD Drive for the Xbox360 unable to play new movies on a HTPC.
You understand that point ?
Where is the freedom in that ?

You don't understand the point.

As long as the drive can be used to decrypt the HD DVD, old or new, their revocations are irrelevant and only will aggravate people.

If they start playing this game, first they will revoke 360 drive.

Then they will have to revoke Toshiba A1.

Then they will have to revoke Toshiba A2.

Then they will become irrelevant.

I really hope AACS is smarter than that. Stupid article suggesting future actions does not mean anything, but even if they go this path, like I said it is irrelevant.

It is not about 360 drive whatsoever. 360 drive just happened to be a handy tool. Any hardware player can be taken apart and reverse-engineered in terms of firmware / software.

[HyperHacker]

And we'll crack that too. :) We know all about the ability to revoke a drive. There are two ways to do it; hacked firmware makes one useless, and retrieving keys from other players makes the other useless.

Hey, good timing Galileo2000. :P

[awhitehead]

A lot of people have bought Xbox 360 HD DVD drives for their HTPC.
And now because you have cracked it, they are going to break the compatibility the drive has with new movies.


It seems like there might be a misinterpretation.
Optical disk drive is a mechanism that reads the contents of the optical disk, and provides the bits recroded on the disk to the software to deal with - decrypt, decode, display, etc.

There exists a host revocation list on the drive, designed to tell the drive not to read the disk, and not to provide disk's contents to the host, if the host runs software that is not approvied or revoked.

With discovery of undocumented debug commands in Toshiba ODD firmware, we discovered that no matter what the software is used to read the contents of the optical disk, regardless if it's revoked or not, we can always convince the drive to read back to the host the contents of the optical disk.

So the drive you bought will always read the disks you bought, regardless of what anyone might decide to change that.

This is a consumer win, not a consumer loss.


They want you to post that you have done this crack successfully then they will break the drives compatibility.


The only way to "break compatibility" of a drive, is to update the software on the host system, so that it would refuse to read the disk contents if the disk is inserted into the drive. Note that the drive will happily read the disk, but the software on the host will refuse to talk to the drive.

Don't you think that this is a problem with the software manufatureres - intervideos, cyberlinks and neros of the world, and not with the drive? Drive works, they refuse to use it. Complain to them, please.


How do you think they will make money if people stop buying their equipment to buy their movies.
People will stop buying Xbox drives to play movies on their htpc, so will they buy external drives that have bloated prices ?


I realize you concern. You likely invested hundreds of dollars into your HD-DVD collection. I, too, bit the "Red Pill" and spent over a thousand dollars on the Xbox drive, a stand-alone Toshiba player, close to 20 HD disks, etc.

But there really is no cause for concern. How can you tell right now that HD-DVD will win, and Blu-Ray will not? Or that something will not supplant both HD-DVD and Blu-Ray in the future?

Recall, that video making is a business. The film makers film and studios sell us a dream. We, as consumers, choose to pay for it or not.

So if the studios and equipment makers make it too hard or too expensive for us to watch movies, we will obtain entertainment elsehow - by going to a concert, game, restorant or wenching, instead of giving them money.

Thus ultimatley if the studios want our money, they will provide us with means and inscentive to give the money to them.

So taking some control from manufactureres of HD-DVD disks, and being able to read every byte on the disk you legitimately bought (recall that there are still no consumer HD-DVD-R drives) will not scare the studios away. They want our money. If we do not use their product, they do not make money. This is Capitalism 101.


No they won't.
So you've just cut out a major portion of the enthusiast market with the genius crack you've made.

As an enthusiast, and an early adopter, you yourself expected, and you are expected by the manufacturers to overpay, as opposed to the late adopter. If I wanted to buy a DVD player back when DVDs were just starting out, I'd expect to spend a thousand dollars. Now I can get a DVD player with tons of features for as low as 25$ (9.99 UK pounds). Being an early adopter does not guarantee that you will be able to play the format of your choice for ever (actually you can right now, until your player gets revoked), nor does it guarantee that there will be new content generated in your format of choice (think when was the last time you saw a video out on Beta).

As for the enthusiast market.... I've lurked on AVSforum for 3 months. I am honestly convinced that most of "enthusiast market" is a bunch of people who just want their movies to look good, and have very low technical knowledge. Thus "enthusiasts" easily give in into fear uncertanity and doubting, and repeat marketing spin of people with the clue without understanding what is going on. That's why AmirM is spending hours on AVSforum telling people that Xbox is good, that no, there will be no problems with Xbox HD-DVD drive, and no, there is no cause for concern. That's why there are paidgeeks and TalkStr8ts that tell you that no, HD-DVD is bad, "breach" of HD-DVD drive is the nail in the coffin of HD-DVD, and you should have bought Blu-Ray any way. Problem is that marketing spin by people with a clue is paid for. They have an agenda. So always follow the money when you read things like this.

An example of the FUD spreading working is you: You came here making wild allegations about the end of the world for HD-DVD in general and Xbox 360 HD-DVD drive in particular.

But you have no idea how the revocation works ("low technical knowledge amongst the enthusiasts"). You don't understand the political and economical realities of the situation. There really is no cause for alarm.

Specifically, to address your concern: if there will be a new firmware update by Microsoft for Xbox connected HD-DVD drives (as part of the May 7th update?), it would be a simple matter of flashing it into PC connected HD-DVD drives, and that the life will go on as a result. You would be able to chose to flash the "stock" firmware, or the "modified" firmware that gives you, as consumer, more rights.

Yes, it might be inconvenient for you as a end user. But nobody told the early adopters that the ride will not be rocky (and if someone did, they wanted your money and they lied).

So please don't spread even more fear uncertainity and doubt. Don't do what the paid people want you to do. Otherwise we'll think that you are part of Project Hydra, and a Blu-Ray schill.

P.S. Personally, I think that was Geremia, xt5 and arnezami managed to do with Xbox HD-DVD drive is amazing. What Muslix64 started is incredible. Our hats should be off for them, since what they do favors and empowers the consumer. Attacking them is both shameless and ungrateful and in the end undermines your own consumer rights.

[arnezami]

Just some clarifications: the Volume ID retrieval protection system has been broken from the start. As early as February (http://forum.doom9.org/showthread.php?t=121866) I already made clear that it was rediculously easy to retrieve a Volume ID. Basicly its a joke. Since then several other ways have been discovered to retrieve it.

The hack discussed in this thread only concerns a slightly easier way for owners of a 360 add-on drive to retrieve the Volume ID. Thats it.

The fact that the press is making a huge fuss about it doesn't mean its really that important (from an AACS perspective): people should actually read the first post of this thread and read what Geremia thought of the importance of this hack...

Sure. It was (from a technical perspective) quite a feat. And it opens some other doors. But it should not be blown out of proportions just becuase of some media journalists. If they do they usually have an agenda or are simply ignorant. Believe me there have seen soo many incorrect reports about this (and earlier) hacks that I gave up hope on (most of) them.

arnezami

@awhitehead: you have said things very well. :)

Regarding muslix64: what he did was indeed incredible: he joined knowledge from audio/video formats (as in "patterns" in the audio/video format) with knowledge about encryption schemes (title keys and vuks). I would like to meet another person who can bridge the gap which usually exists between those who know all about containers/demuxing etc and those that know the intricate details about encryption schemes. But this is exactly what muslix64 did by using patterns in decrypted audio/video output as crib for possible title encryption keys :). Deep respect here... in fact he inspired me ;).

[blutach]

@awhitehead - you need not have mentioned "hookers" to get your point across. Please consider rule 4.

Regards

[Galileo2000]

@awhitehead - you need not have mentioned "hookers" to get your point across. Please consider rule 4.

Regards

Hmm, too bad I missed this part.

[lightshadow]

@awhitehead - you need not have mentioned "hookers" to get your point across. Please consider rule 4.

I don't get it. If anyone should be corrected, it should be Jeremy Duncan. He violated rule 1, 1a, 2, 3, 4 and lack of respect for others peoples work.

In regards to the word hokker, it is just one word taken out of a reply of 50 lines or so. In its context I find it appropriate and not offending. In fact anyone that gives a so good 50 line reply to a offeending post like Jeremy Duncan's deserves the best.

awhitehead have contributed to make this DRM hack and variants possible. Anyone who enjoys Free Rights, use these hacks to defeat DRM for now and in the future should either contribute to the project or help in other ways. E.g. by keeping the tone to these people positive and motivational.

I think it is wrong to point fingers at awhitehead and not Jeremy Duncan.

I will not reply to any posts regarding this topic in this thread, as I think we should concentrate on hacking in this thread. But I thought it was important to stand up for what I think is right. PM me, and I will answer.

[Geremia]

I've bought a piece of hardware and some hd-dvd titles like you all.
You like watching higdef movie (at lame 24fps with prehistorical 2:3 pulldown), i like to use what i own in a different manner.
You like to be passive to technology, i like to be active, that's all.


Got enought of finding the density in ram, I've quick patched the CDB AD format15 to point to different PSN, this way i've read the ControlDS and the CopyrightDS. Well, the CopyryghtDS is all 00 in both places (01E600 and 01FA00), it would be interesting to see the headers too of these sectors.

The ControlDS are equal inthe first 3 sectors (PFI, DMI and CPI), while the second ControlDS have unreadable sectors in the "reserved" sectors (sectors 4 to 31)

[blutach]

@lightshadow - I'd be grateful if you left modding to the mod team please.

Regards

[Jeremy Duncan]

Destroying DRM is not my bag of tea.
It's offensive to a person to a point that is akin to personal space.
I'm not saying which person is too close to whom and who is offending whom, I'll let you figure that out.

Thank you all for your time.
I don't want to disturb your Nirvana Zen.

[Geremia]

BTW, regarding the LBA boundaries

0x40220 is the last LBA of disc, 00DBA9BF for kingkong
changing to FFFFFFFF makes boundary checks pass. negative LBA begins at FFFFFFFF and backward

first enable DF command, then

plscsi.exe -v -p -x "DF 00 E3 00 04 02 20 04 02 23 FF FF"

you can use iisobuster to read negative LBA sectors, but this not allow to read the system lead-in area, but it's good for any other purpose

[Galileo2000]

Destroying DRM is not my bag of tea.
It's offensive to a person to a point that is akin to personal space.
I'm not saying which person is too close to whom and who is offending whom, I'll let you figure that out.

Thank you all for your time.
I don't want to disturb your Nirvana Zen.

I suggest you return to your regular activities and won't post on this thread, or even better, on this forum.

[blutach]

Please let it rest guys. Galileo2000, please observe rule 4.

Now, back on topic please.

Regards

[mrazzido]

Hello! does any1 checked TS-L802A notebook hd dvd drive .

is there the same firmware bug availble?

i upload two firmwares (-bin) file CLICK DL (http://www.sendspace.com/file/wux13c)

[awhitehead]

Geremia, you were talking about laser power and pit sizes earlier, so maybe you know....

(If anyone else knows, feel free to jump in)

Here is my situation: I have an HD-DVD disk, that is readable in one HD-DVD drive (Toshiba SD-S802A), and not readable in another HD-DVD drive (NEC HR-1100A). Other HD-DVD disks are read by both.

When I say "not readable", I don't mean "not playable by software", etc, I mean that one ODD can read the bytes on disk and the other one can't

I verified sending the following CDBs to the drive using plscsi:

plscsi -v -x "25 00 00:00:00:00 00 00:00 00" -i 8 (READ CAPACITY)

plscsi -v -x "28 00 00:00:00:10 00 00:01 00" -i x800 (READ(10) 2048 bytes of the disk starting at address 16 (should be first block on disk))

Toshiba returns valid data, NEC returns AE's.

Is this a problem due to laser power? Bad mastering? Something else?

The title in question is French release of "Stalingrad" ("Enemy at the Gates") by Fox Pathe/Studio Canal. It doesn't have AACS encryption on the disk, and BCA is full of 00s.

[arnezami]

I guess this is the best place to put this.

New version of: fetchvid v0.2 (http://www.sendspace.com/file/opr4w7)

Some big changes:

- Generally more sublte and cleaner so its probably more reliable
- Time in ms (which is better)
- Works for BluRay too! (well it should, please test)
- You can examine the behaviour of your player+drive first and adjust your time setting to that.
- Removed the lower/higher advise because it seemed to disrupt proper working (possibly due to interference with new player version).

Basicly this is the BluRay equivalent of a Volume ID "hack". You need a working Software Player for this to work.

http://img71.imageshack.us/img71/5937/fetchvid02fw0.png

It should work on any drive and any software player :D.

Please test this for BD ;)...

arnezami

[PepsiLee2001]

I try to test fetchvid v0.2 for Blu-ray & HD-DVD.

for HD-DVD (work fine)

G:\fetchvid 0.2>fetchvid.exe L
fetchvid v0.2.
Note: this experimental program currently only works for drives that support just one AGID.

Looks like a HD DVD disc
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 1
Start your software player now and press play if needed.
Player is accessing drive: 1
vid: 400025061303183157474844564D0000


for blu-ray

G:\fetchvid 0.2>fetchvid.exe m
fetchvid v0.2.
Note: this experimental program currently only works for drives that support just one AGID.

Looks like a Bluray disc
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 1
Start your software player now and press play if needed.
Player is accessing drive: 1

Could not retrieve volumeid at the time specified. You should try a different time setting.




for blu-ray

G:\fetchvid 0.2>fetchvid.exe m 1000 5
fetchvid v0.2.
Note: this experimental program currently only works for drives that support just one AGID.

Looks like a Bluray disc
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 5
Start your software player now and press play if needed.
Player is accessing drive: 1
Player has stopped using drive: 15078 ms
Player is accessing drive: 2
Player has stopped using drive: 56562 ms
Player is accessing drive: 3
Player has stopped using drive: 13328 ms
Player is accessing drive: 4
Player has stopped using drive: 14078 ms
Player is accessing drive: 5


PowerDVD 7.3 play & stop 5 time, but still can't get vid.

[arnezami]

I try to test fetchvid v0.2 for Blu-ray & HD-DVD.

for HD-DVD (work fine)

G:\fetchvid 0.2>fetchvid.exe L
fetchvid v0.2.
Note: this experimental program currently only works for drives that support just one AGID.

Looks like a HD DVD disc
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 1
Start your software player now and press play if needed.
Player is accessing drive: 1
vid: 400025061303183157474844564D0000


for blu-ray

G:\fetchvid 0.2>fetchvid.exe m
fetchvid v0.2.
Note: this experimental program currently only works for drives that support just one AGID.

Looks like a Bluray disc
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 1
Start your software player now and press play if needed.
Player is accessing drive: 1

Could not retrieve volumeid at the time specified. You should try a different time setting.




for blu-ray

G:\fetchvid 0.2>fetchvid.exe m 1000 5
fetchvid v0.2.
Note: this experimental program currently only works for drives that support just one AGID.

Looks like a Bluray disc
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 5
Start your software player now and press play if needed.
Player is accessing drive: 1
Player has stopped using drive: 15078 ms
Player is accessing drive: 2
Player has stopped using drive: 56562 ms
Player is accessing drive: 3
Player has stopped using drive: 13328 ms
Player is accessing drive: 4
Player has stopped using drive: 14078 ms
Player is accessing drive: 5


PowerDVD 7.3 play & stop 5 time, but still can't get vid.

Hmm. Looks like it accesses the drive for like 13-15 (or 60) seconds. How long does it take for your movie to Bluray to startup? Or does fetchvid interfere/prevent it from playing? Or is it already playing the movie when you see these numbers come along? And how long did it take for it to give the "Could not retrieve" error message the first time?

Have you tried raising/lowering the time value?

Its possible that your BD drive is capable of multiple AGIDs at the same time which might explain this behaviour. But its kinda weird. Make sure you really shut down your player before starting fetchvid.

What brand/model drive do you have?

Also try this version (v0.2.1):

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

It should give AGID (debugging) messages if more than one AGID is used.

arnezami

[PepsiLee2001]

Hmm. Looks like it accesses the drive for like 13-15 (or 60) seconds. How long does it take for your movie to Bluray to startup? Or does fetchvid interfere/prevent it from playing? Or is it already playing the movie when you see these numbers come along? And how long did it take for it to give the "Could not retrieve" error message the first time?

Have you tried raising/lowering the time value?

Its possible that your BD drive is capable of multiple AGIDs at the same time which might explain this behaviour. But its kinda weird. Make sure you really shut down your player before starting fetchvid.

What brand/model drive do you have?



fetchvid 0.21 testing result.

OS : WinXP SP2
BD Drive : LiteOn LH-2B1S
blu-ray disc : 2007 DTS-HD Master Audio Presentation Disc

default argument

G:\fetchvid_0.21>fetchvid.exe m
fetchvid v0.2.1
Note: this experimental program currently only works for drives that support just one AGID.

Looks like a Bluray disc
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 1
Start your software player now and press play if needed.
AGID other than 0!: 3
Player is accessing drive: 1




G:\fetchvid_0.21>fetchvid.exe m 20000 1
fetchvid v0.2.1
Note: this experimental program currently only works for drives that support just one AGID.

Looks like a Bluray disc
Watching the drive's AGID usage...
Current time setting: 20000 ms
Wait until access moment: 1
Start your software player now and press play if needed.
AGID other than 0!: 3
Player is accessing drive: 1

Could not retrieve volumeid at the time specified. You should try a different time setting.



PowerDVD 7.3 is playing normally.

G:\fetchvid_0.21>fetchvid.exe m 15000 3
fetchvid v0.2.1
Note: this experimental program currently only works for drives that support just one AGID.

Looks like a Bluray disc
Watching the drive's AGID usage...
Current time setting: 15000 ms
Wait until access moment: 3
Start your software player now and press play if needed.
AGID other than 0!: 2
AGID other than 0!: 3
Player is accessing drive: 1
AGID other than 0!: 1
Player has stopped using drive: 9797 ms
AGID other than 0!: 3
Player is accessing drive: 2
AGID other than 0!: 1
Player has stopped using drive: 18563 ms
AGID other than 0!: 3
Player is accessing drive: 3

Could not retrieve volumeid at the time specified. You should try a different time setting.



aacskeys 0.24 work fine
G:\aacskeys_v0.2.4>aacskeys m n
aacskeys v0.2.4

First C-value: 459DE09775A9E7442416637D03D00552
First u mask nr: 17
First uv: 00000001
Volume Unique Key: 61B6A65446D6F1AF353F5F7AF7E546D6
Unit Key File Hash (DiscID): 2CCC522CE0C26F04F4015FFF9D3EE9D4E80DA43D

[arnezami]

fetchvid 0.21 testing result.

OS : WinXP SP2
BD Drive : LiteOn LH-2B1S
blu-ray disc : 2007 DTS-HD Master Audio Presentation Disc

default argument

G:\fetchvid_0.21>fetchvid.exe m
fetchvid v0.2.1
Note: this experimental program currently only works for drives that support just one AGID.

Looks like a Bluray disc
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 1
Start your software player now and press play if needed.
AGID other than 0!: 3
Player is accessing drive: 1




G:\fetchvid_0.21>fetchvid.exe m 20000 1
fetchvid v0.2.1
Note: this experimental program currently only works for drives that support just one AGID.

Looks like a Bluray disc
Watching the drive's AGID usage...
Current time setting: 20000 ms
Wait until access moment: 1
Start your software player now and press play if needed.
AGID other than 0!: 3
Player is accessing drive: 1

Could not retrieve volumeid at the time specified. You should try a different time setting.



PowerDVD 7.3 is playing normally.

G:\fetchvid_0.21>fetchvid.exe m 15000 3
fetchvid v0.2.1
Note: this experimental program currently only works for drives that support just one AGID.

Looks like a Bluray disc
Watching the drive's AGID usage...
Current time setting: 15000 ms
Wait until access moment: 3
Start your software player now and press play if needed.
AGID other than 0!: 2
AGID other than 0!: 3
Player is accessing drive: 1
AGID other than 0!: 1
Player has stopped using drive: 9797 ms
AGID other than 0!: 3
Player is accessing drive: 2
AGID other than 0!: 1
Player has stopped using drive: 18563 ms
AGID other than 0!: 3
Player is accessing drive: 3

Could not retrieve volumeid at the time specified. You should try a different time setting.



aacskeys 0.24 work fine
G:\aacskeys_v0.2.4>aacskeys m n
aacskeys v0.2.4

First C-value: 459DE09775A9E7442416637D03D00552
First u mask nr: 17
First uv: 00000001
Volume Unique Key: 61B6A65446D6F1AF353F5F7AF7E546D6
Unit Key File Hash (DiscID): 2CCC522CE0C26F04F4015FFF9D3EE9D4E80DA43D

Ok. This clarifies it a lot. :) Clearly your drive is capable of using mutiple AGIDs (which is not supported atm). I will try to see if I can make this work for these kinds of drives too.

arnezami

[arnezami]

@PepsiLee2001 (or anybody else with a BD drive):

Try this new version.

fetchvid v0.2.2 (http://www.sendspace.com/file/raxm6n)

Hopefully this works for drives capabale of multiple AGIDs. Basicly it shuts down the other 3 AGIDs before it begins.

arnezami

[mrazzido]

good morning :-D from here..


it test it on BD in 1-2hours new disc then arrived :-D

[PepsiLee2001]

@PepsiLee2001 (or anybody else with a BD drive):

Try this new version.

fetchvid v0.2.2 (http://www.sendspace.com/file/raxm6n)

Hopefully this works for drives capabale of multiple AGIDs. Basicly it shuts down the other 3 AGIDs before it begins.

arnezami

fetchvid 0.2.2 still not work fine.

G:\fetchvid_0.22>fetchvid.exe m 12000 2
fetchvid v0.2.2

Looks like a Bluray disc
Watching the drive's AGID usage...
Current time setting: 12000 ms
Wait until access moment: 2
Start your software player now and press play if needed.
Player is accessing drive: 1
AGID other than 0!: 1
Player has stopped using drive: 11844 ms
AGID other than 0!: 3
Player is accessing drive: 2

[arnezami]

fetchvid 0.2.2 still not work fine.

G:\fetchvid_0.22>fetchvid.exe m 12000 2
fetchvid v0.2.2

Looks like a Bluray disc
Watching the drive's AGID usage...
Current time setting: 12000 ms
Wait until access moment: 2
Start your software player now and press play if needed.
Player is accessing drive: 1
AGID other than 0!: 1
Player has stopped using drive: 11844 ms
AGID other than 0!: 3
Player is accessing drive: 2

Argh. It seems PowerDVD is screwing with (eh invalidating) unused AGIDs. That kinda sucks. This is a lot harder than hoped since I now have to dynamicly account for agids.

Try this new version:

fetchvid v0.2.3 (http://www.sendspace.com/file/td3e1n)

arnezami

PS. I almost have to go now :).

[arnezami]

Whoops. I think I made a mistake there. Here is the hopefully working one:

fetchvid v0.2.4 (http://www.sendspace.com/file/cm623t)

This one will probably not work for HD DVD drive though.

arnezami

PS. Really have to go now ;).

[PepsiLee2001]

Whoops. I think I made a mistake there. Here is the hopefully working one:

fetchvid v0.2.4 (http://www.sendspace.com/file/cm623t)

This one will probably not work for HD DVD drive though.


0.2.4 have other problem...


E:\fetchvid_0.24>fetchvid.exe f 12000 2
fetchvid v0.2.4

Error determining drive type: assuming HD DVD
Watching the drive's AGID usage...
Current time setting: 12000 ms
Wait until access moment: 2
Start your software player now and press play if needed.
Player is accessing drive: 1

[mrazzido]

sometimes the tools writes HD-DVD like pepsilee2001

and sometimes BD DISC.

i use both software (powerdvd/windvd) on my LIteon BD SATA Burner.


doenst work.

to get an ID

[arnezami]

Ok. This is going to be hard and a lot of going back and forth. I need lots of feed back. So please always post a screenshot or copy paste the results. And also tell if it "hangs" and when (and when/if the player is playing etc). This might not seem like important information to you but it is to me. I'm trying to do someting with a drive it wasn't designed to do and I do not even have this drive! Thats very hard. But I believe its possible and worth the effort.

Here is a slightly better version:

fetchvid v0.2.5 (http://www.sendspace.com/file/os2orw) (don't try this with xbox drive, won't work)

I don't quite understand why it sometimes doesn't see the MKB_RO.inf file (which is how it checks if its a bluray disc). Are there BD discs you tried that don't have that file? Anyway I've changed it so if it doesn't find this file now it will default to Bluray (instead of HD DVD). Which should solve this problem for the moment.

I've also changed the vid retrieval (earlier I only tried AGID 0 which would only work 25% of the time so this way it might look like it didn't work at all). Please try different parameters.

Awaiting your test results :).

arnezami

PS. Also: does the "Player is accessing drive: 1" come before or after the player starts (playing)?

[arnezami]

@mrazzido: thanks for the feedback. I can now see your drive supports 3 AGIDs (not 4 like I assumed earlier). Later on it will have to detect this automatically. But for now I've hardwired it to try only 3.

fetcvid v0.2.6 (http://www.sendspace.com/file/y8u25g)

Please test this version and report back your results.

arnezami

[mrazzido]

fetchvid i 1000
0
fetchvid v0.2.6

Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 0
Start your software player now and press play if needed.
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1


fetchvid i 1000
2
fetchvid v0.2.6

Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 2
Start your software player now and press play if needed.
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1







i think its an error

[arnezami]

fetchvid i 1000
0
fetchvid v0.2.6

Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 0
Start your software player now and press play if needed.
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1


fetchvid i 1000
2
fetchvid v0.2.6

Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 2
Start your software player now and press play if needed.
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1
AGID other than 0!: 1

i think its an error
Its a debug message. What happens if you start the player?

Well. At least it seems to be acting sensible now.

Anyway: here is a new version without this debug message and better volume id retrieval.

fetchvid v0.2.7 (http://www.sendspace.com/file/gbem6s)

Please try this.

arnezami

PS. When testing its better to set "Wait until access moment" at atleast 1.

[mrazzido]

i am testing... ~5min


------




Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 15000 ms
Wait until access moment: 3
Start your software player now and press play if needed.
Player is accessing drive: 1
Player has stopped using drive: 37016 ms
Player is accessing drive: 2
Player has stopped using drive: 29484 ms
Player is accessing drive: 3

Could not retrieve volumeid at the time specified. You should try a different ti
me setting.

-- Tip: run fetchvid setting a high wait "until access moment"
This will show you the amount of times the drive is accessed
and for how long. Keep in mind when doing this you have
to use Ctrl-C to stop fetchvid... sorry ;). --

So close the software player and start fetchvid with a new wait value.





does this only work with power dvd , the prog only regonize push play on powerdvd , / windvd 8 nothing happend...

[arnezami]

This one will spit out more debug info for me to figure out what is going on here.

fetchvid v0.2.8 (http://www.sendspace.com/file/7p3xbv)

Also try the default setting: so simply "fetchvid i"

Btw: what AGID does aacskeys give with this drive and disc?

arnezami

[mrazzido]

aacskeys says AGID : 01

i test yet new version..

[mrazzido]

whahh got an driver error in my system , powerdvd/windvd doesnt regonize BD drive anymore , its a Catalyst problem . i installed some minutes ago omega drivers. which is the best driver for Powerdvd.

i read some times other ppls had the same problem with newer driver of Catalyst

[PepsiLee2001]

aacskeys says AGID : 01

i test yet new version..


E:\fetchvid>fetchvid.exe f
fetchvid v0.2.8

Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 1
Start your software player now and press play if needed.
AGIDs usage now: 1 2 3 -1
Player is accessing drive: 1
AGIDs usage: 2 3 -1 -1

Could not retrieve volumeid at the time specified. You should try a different time setting.



E:\fetchvid>fetchvid.exe f 12000 1
fetchvid v0.2.8

Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 12000 ms
Wait until access moment: 1
Start your software player now and press play if needed.
AGIDs usage now: 1 2 3 -1
Player is accessing drive: 1
AGIDs usage: 2 3 -1 -1

Could not retrieve volumeid at the time specified. You should try a different time setting.



E:\fetchvid>fetchvid.exe f 12000 0
fetchvid v0.2.8

Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 12000 ms
Wait until access moment: 0
Start your software player now and press play if needed.
AGIDs usage now: 1 2 3 -1
Player is accessing drive: 1
AGIDs usage: 2 3 -1 -1

Could not retrieve volumeid at the time specified. You should try a different time setting.

[arnezami]

Ok. It looks like your drive is always using AGID 1 for AACS-Auth.

So I changed fetchvid to only try this AGID for volume id retrieval.

It also seems to be detecting the software players' access to the drive. So its possible its working now and it may just have to be tweaked.

Commands to try:

fetchvid f 300

up to

fetchvid f 3000

(eg 300, 500, 700, 1000, 1200, 1400, 1600, 1800 etc)

and

fetchvid f 1000 20 (maybe do this one first)

(to see if it detects the software player stopping to use the drive).

If possible try different software players.

New version:

fetchvid v0.2.9 (http://www.sendspace.com/file/yq9tod)

arnezami

[arnezami]

Ok. New version that hopefully works better with this command

fetchvid f 1000 20

(which should reveal the AGID usage by the player and times like 1000 - 3000ms)

It now releases the AGIDs not used by the player. Still hardcoded to AGID 1.

fetchvid v0.2.10 (http://www.sendspace.com/file/f6k0d7)

arnezami

@mrazzido: did you use a different drive here (http://forum.doom9.org/showthread.php?p=969016#post969016) since (the old) aacskeys showed AGID 00 there.

[mrazzido]

fetchvid i 1000
20
fetchvid v0.2.10

Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 20
Start your software player now and press play if needed.
AGIDs usage now: 1 2 3 -1
Player is accessing drive: 1
AGIDs usage: 2 3 -1 -1
AGIDs usage now: 2 2 3 1
Player has stopped using drive: 42078 ms
Player is accessing drive: 2
AGIDs usage: 2 3 -1 -1
AGIDs usage now: 2 3 3 -1
Player has stopped using drive: 43390 ms
Player is accessing drive: 3
AGIDs usage: 2 3 -1 -1
AGIDs usage now: 2 2 3 1
Player has stopped using drive: 31844 ms
Player is accessing drive: 4
AGIDs usage: 2 3 -1 -1
AGIDs usage now: 2 2 3 1
Player has stopped using drive: 29328 ms
Player is accessing drive: 5
AGIDs usage: 2 3 -1 -1

[arnezami]

Hmmm. These drives are doing weird stuff. Possibly a timing issue.

Please test the 300-3000 ms anyway.

[arnezami]

This version uses a different technique. Maybe this will work better:

fetchvid v0.2.11 (http://www.sendspace.com/file/m4yg6n)

arnezami

[mrazzido]

Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 300 ms
Wait until access moment: 1
Start your software player now and press play if needed.
AGIDs usage now: 1 2 3 -1
AGID other than 1!: 2
AGID other than 1!: 2
AGID other than 1!: 2
AGID other than 1!: 2
AGID other than 1!: 2

the debug message comes 5 times when i push play on powerdvd6 .

[PepsiLee2001]

This version uses a different technique. Maybe this will work better:
fetchvid v0.2.11 (http://www.sendspace.com/file/m4yg6n)

fetchvid with PowerDVD 7.3

fetchvid v0.2.11

Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 3
Start your software player now and press play if needed.
AGIDs usage now: 1 2 3 -1
AGID other than 1!: 2
AGID other than 1!: 2
AGID other than 1!: 2
AGID other than 1!: 2
AGID other than 1!: 2
AGID other than 1!: 2
.
.
.
loop
.
.
.


and powerdvd can't play movie, error message,

The Player cannot suppor this content [Error code = 0020]. Possible reasons are:
1) Your optical driver is revoked. please contact your drive manufacturer
2) Cannot support duplicate of copyrighted disc
3) Cannot support protected content from hard disc (HDD)



fetchvid with WinDVD 8

fetchvid v0.2.11

Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 3
Start your software player now and press play if needed.
AGIDs usage now: 1 2 3 -1


fetchvid have no any response, when play windvd, fetchvid show a message "AGID other than 1!: 2" and still waiting. Windvd can't play any thing, It still in idle mode. Play again, fetchvid will show next "AGID other than 1!: 2" message.

[KoD]

Is this the "updated" PowerDVD you are using ?

[PepsiLee2001]

Is this the "updated" PowerDVD you are using ?

No, It has not install any patch.

[arnezami]

Ok. I've now done something quite simple now and it just might work.

Lets see what happens :).

fetchvid v0.2.12 (http://www.sendspace.com/file/sj2lbn)

arnezami

[mrazzido]

fetchvid i

fetchvid v0.2.12

Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 1
Start your software player now and press play if needed.
AGIDs usage now: 1 2 3 -1
Player is accessing drive: 1
AGIDs usage: 2 2 3 -1

Could not retrieve volumeid at the time specified. You should try a different ti
me setting.

-- Tip: run fetchvid setting a high wait "until access moment"
This will show you the amount of times the drive is accessed
and for how long. Keep in mind when doing this you have
to use Ctrl-C to stop fetchvid... sorry ;). --

So close the software player and start fetchvid with a new wait value.




i used power dvd 6.6 is it better to use a newer version??!

[arnezami]

fetchvid i

fetchvid v0.2.12

Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 1
Start your software player now and press play if needed.
AGIDs usage now: 1 2 3 -1
Player is accessing drive: 1
AGIDs usage: 2 2 3 -1

Could not retrieve volumeid at the time specified. You should try a different ti
me setting.

-- Tip: run fetchvid setting a high wait "until access moment"
This will show you the amount of times the drive is accessed
and for how long. Keep in mind when doing this you have
to use Ctrl-C to stop fetchvid... sorry ;). --

So close the software player and start fetchvid with a new wait value.




i used power dvd 6.6 is it better to use a newer version??!

I'm not sure. But for now just keep using it.

Since it now seems to detect agid player usage could you run it with a higher waiting number? I would like to know if it recogines the stopping of usage of the agid. And what times (in ms) come out of it.

And besides that changing to 300-3000 ms (with wait value set to 1).

arnezami

PS. For those who are interested: the "2 2 3 -1" is really weird because it means that when asking the drive 4 times for a new agid it gives the agid "2" twice. It shouldn't do that: it should give only unique agid nrs and then (when all agids are given away) start giving errors (-1). But that doesn't happen. Which frankly I don't understand (maybe timing issue but it seems to be too consistent, or some bug in the drive software, or we need to reconnect to the drive between asking for new agids?). Just to clarify: it doesn't give the agid "1" at all because (assumingly) the software player has got that one in use.

[PepsiLee2001]

C:\fetchvid v0.2.12>fetchvid.exe n
fetchvid v0.2.12

Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 1
Start your software player now and press play if needed.
AGIDs usage now: 1 2 3 -1
Player is accessing drive: 1
AGIDs usage: 2 2 3 -1

Could not retrieve volumeid at the time specified. You should try a different time setting.




C:\fetchvid v0.2.12>fetchvid.exe n 1000 2
fetchvid v0.2.12

Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 1000 ms
Wait until access moment: 2
Start your software player now and press play if needed.
AGIDs usage now: 1 2 3 -1
Player is accessing drive: 1
AGIDs usage: 2 2 3 -1
AGIDs usage now: 1 2 3 -1
Player has stopped using drive: 17281 ms
Player is accessing drive: 2
AGIDs usage: 2 2 3 -1

Could not retrieve volumeid at the time specified. You should try a different time setting.




C:\fetchvid v0.2.12>fetchvid.exe n 20000 2
fetchvid v0.2.12

Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 20000 ms
Wait until access moment: 2
Start your software player now and press play if needed.
AGIDs usage now: 1 2 3 -1
Player is accessing drive: 1
AGIDs usage: 2 2 3 -1
AGIDs usage now: 1 2 3 -1
Player has stopped using drive: 13734 ms
Player is accessing drive: 2
AGIDs usage: 2 2 3 -1

Could not retrieve volumeid at the time specified. You should try a different time setting.




C:\fetchvid v0.2.12>fetchvid.exe n 13000 2
fetchvid v0.2.12

Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 13000 ms
Wait until access moment: 2
Start your software player now and press play if needed.
AGIDs usage now: 1 2 3 -1
Player is accessing drive: 1
AGIDs usage: 2 2 3 -1
AGIDs usage now: 1 2 3 -1
Player has stopped using drive: 12922 ms
Player is accessing drive: 2
AGIDs usage: 2 2 3 -1

Could not retrieve volumeid at the time specified. You should try a different time setting.




C:\fetchvid v0.2.12>fetchvid.exe n 13000
fetchvid v0.2.12

Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 13000 ms
Wait until access moment: 1
Start your software player now and press play if needed.
AGIDs usage now: 1 2 3 -1
Player is accessing drive: 1
AGIDs usage: 2 2 3 -1

Could not retrieve volumeid at the time specified. You should try a different time setting.




C:\fetchvid v0.2.12>fetchvid.exe n 3000
fetchvid v0.2.12

Looks like a Bluray disc
AGIDs available: 1 2 3 -1
Watching the drive's AGID usage...
Current time setting: 3000 ms
Wait until access moment: 1
Start your software player now and press play if needed.
AGIDs usage now: 1 2 3 -1
Player is accessing drive: 1
AGIDs usage: 2 2 3 -1

Could not retrieve volumeid at the time specified. You should try a different time setting.

[arnezami]

OK. I need time to think this through. But things don't seem to add up here :(.

Anyway. Lets go for brute force shall we :D.

Here is KenD00's dumpvid program adapted for bluray:

dumpvid 0.3 (adapted) (http://www.sendspace.com/file/wyqw47)

Screenshot:

http://img259.imageshack.us/img259/6277/dumpvidhq2.png

Works like a charm for PowerDVD 7.3 (for me when using the HD DVD version) even including the upgrade.

See KenD00's post (http://forum.doom9.org/showthread.php?p=956255#post956255) for more info. Just hit ENTER en then play with PowerDVD.

arnezami

[PepsiLee2001]

OK. I need time to think this through. But things don't seem to add up here :(.

Anyway. Lets go for brute force shall we :D.

Here is KenD00's dumpvid program adapted for bluray:

dumpvid 0.3 (adapted) (http://www.sendspace.com/file/wyqw47)


dumpvid 0.30 + aacskey 0.25

dumpvid 0.30

C:\dumpvid0.30>dumpvid.exe n
DumpVID 0.3 by KenD00 (adapted for bluray testing)

Drive type is recognised as CDROM/DVD.

Sending SPC1 Test Unit CDB6 command..done.
Returned good status.

Press ENTER to start hammering

Hammering drive...
vid: 43F962AFDF015A7A2F01BFB8B29C4C92
Hammering finished.


aacskeys 0.25

C:\aacskeys_v0.2.5>aacskeys.exe n s 43F962AFDF015A7A2F01BFB8B29C4C92
aacskeys v0.2.5

Current path: C:\aacskeys_v0.2.5

First C-value: 459DE09775A9E7442416637D03D00552
First u mask nr: 17
First uv: 00000001
Device key: AA856A1BA814AB99FFDEBA6AEFBE1C04
Processing key: 09F911029D74E35BD84156C5635688C0
Encrypted C-value: 459DE09775A9E7442416637D03D00552
Corresponding uv: 00000001

Decrypted C-value: 0028A88F4F50647D49962E02CFBFA9D7
Media key: 0028A88F4F50647D49962E02CFBFA9D6

Encrypted verification data: EB29317BB8DECA19A8879C6DFDB02D24
Decr verif data should be: 0123456789ABCDEF
Decrypted verification data: 0123456789ABCDEF373026BCC71B62E0

Volume ID: 43F962AFDF015A7A2F01BFB8B29C4C92
Volume Unique Key: 61B6A65446D6F1AF353F5F7AF7E546D6
Unit Key File Hash (DiscID): 2CCC522CE0C26F04F4015FFF9D3EE9D4E80DA43D
Encrypted Unit Key 1: C2FD8516BE84A8CEF789C913A38A0996

Decrypted Unit Key 1: 5F620690A99921E9B7CF4A756E69B8B8

[mrazzido]

i test the tool from kenD00

i got the right volume id...


DumpVID 0.3 by KenD00 (adapted for bluray testing)

Drive type is recognised as CDROM/DVD.

Sending SPC1 Test Unit CDB6 command..done.
Returned good status.

Press ENTER to start hammering

Hammering drive...
vid: 51FAA0C75C515D91429D23C2FF8C4173
Hammering finished.

[arnezami]

Great! :D :D :D

This is good news.

For some reason using the AGID as time marker interferes with both players (using a BD/multi-agid drive). Maybe there is an in between solution. But now we atleast got a way of retrieving Volume IDs from the current version of Power DVD.

For now I will probably concentrate on other stuff and maybe come back to this later when there is more time or need for it.

Much thanks to mrazzido and PepsiLee2001 for all their impressive efforts. :thanks:

Btw: this means we now have a way of retrieving the VID for both HD DVD and Bluray. Meaning we effectively do not need the upcoming HPK anymore. :)

Regards,

arnezami

[Geremia]

good work arnezami

there is always something more exciting than watching movie, right? :)

About the SD-S802A, i've found a (disabled) cdb command that reads any sector in any disc area (system lead-in included) with full 0x10 byte header too :) (header is first 0x10 bytes of the output)

plscsi.exe -v -p -x "08 00 00 ps ps ps" -i x810

where pspsps is the PSN

i've dumped all the "raw" copyright data segment of kingkong (where VolumeID LSB and KCD should be) but it doesn't seems to contain anything. Also the RSV 6byte field in the header is empty.

Reading AACS specs, they say that VID LSB and KCD "shall" be recorded here, but i also read that an AACS compliant standalone player may not use the KCD ...so, maybe we should look for a CopyrightDS of a movie that has full VolumeID (not the one with 00 20 20 20 20 20 ending)?
I've not such a movie, can anyone see how PSN 01E600 and > looks like?

ex:

plscsi.exe -v -p -x "08 00 00 01E600" -i x810

P.S.: the 08 CDB command is disabled by default, you have to enable disabled commands first (like done before for DF command)

[lightshadow]

P.S.: the 08 CDB command is disabled by default, you have to enable disabled commands first (like done before for DF command)
It may seam like a stupid question, but could you provide the entire command ofr unlocking 08? I can't find it for DF.

[awhitehead]

It may seam like a stupid question, but could you provide the entire command ofr unlocking 08? I can't find it for DF.


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


DFenable.bin is a binary file that contains the following 8 bytes:
88 00 00 04 02 6F 01 00

If you would like to disable DF, you need to create DFdisable.bin:
88 00 00 04 02 6F 00 00
and re-run the above plscsi command with an additional data in DFdisable.bin

HTH.

[Pelican9]

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


DFenable.bin is a binary file that contains the following 8 bytes:
88 00 00 04 02 6F 01 00

If you would like to disable DF, you need to create DFdisable.bin:
88 00 00 04 02 6F 00 00
and re-run the above plscsi command with an additional data in DFdisable.bin

HTH.


I think lightshadow wants to know how he can enable the 08 command.

[lightshadow]

I think lightshadow wants to know how he can enable the 08 command.
Yes, and also the DF command, so thanks awhitehead for that =)

[awhitehead]

I think lightshadow wants to know how he can enable the 08 command.

I apologize. After reading

P.S.: the 08 CDB command is disabled by default, you have to enable disabled commands first (like done before for DF command)

I was under impression that the technique above enables disabled commands, including both DF and 08.

Once again, I apologize.