Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
![]() |
#1 | Link |
Registered User
Join Date: Feb 2007
Posts: 71
|
Got VolumeID without AACS authentication :)
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 |
![]() |
![]() |
#2 | Link |
Registered User
Join Date: Sep 2006
Posts: 390
|
Congratulations Geremia!!
![]() ![]() ![]() ![]() ![]() This is really cool ![]() Btw: this is all about a Xbox 360 HD DVD drive patch (link). Its been quite a ride the last couple of days (or should I say weeks ![]() (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) ![]() ![]() Last edited by arnezami; 12th April 2007 at 18:55. |
![]() |
![]() |
#3 | Link |
Registered User
Join Date: Feb 2007
Posts: 71
|
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. |
![]() |
![]() |
#5 | Link | |
Registered User
Join Date: Feb 2007
Posts: 85
|
Quote:
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 ;-) |
|
![]() |
![]() |
#6 | Link | |
Registered User
Join Date: Sep 2006
Posts: 390
|
Quote:
![]() 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" ![]() 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) -- Last edited by arnezami; 4th April 2007 at 17:48. |
|
![]() |
![]() |
#8 | Link | |||
Registered User
Join Date: Feb 2007
Posts: 123
|
Quote:
Quote:
Quote:
|
|||
![]() |
![]() |
#9 | Link | |
Registered User
Join Date: Sep 2006
Posts: 390
|
Quote:
Although I guess much of the detailed knowledge (about this hack) has only been discussed through pms ![]() Last edited by arnezami; 4th April 2007 at 19:36. |
|
![]() |
![]() |
#10 | Link | |
Registered User
Join Date: Feb 2007
Posts: 71
|
Quote:
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. |
|
![]() |
![]() |
#11 | Link | |
Registered User
Join Date: Sep 2006
Posts: 390
|
Quote:
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 Last edited by arnezami; 4th April 2007 at 19:50. |
|
![]() |
![]() |
#12 | Link |
Registered User
Join Date: Feb 2007
Posts: 71
|
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. Code:
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 |
![]() |
![]() |
#13 | Link | |
Registered User
Join Date: Sep 2006
Posts: 390
|
Quote:
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: ![]() 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 ![]() Last edited by arnezami; 5th April 2007 at 07:11. |
|
![]() |
![]() |
#14 | Link | ||
Registered User
Join Date: Feb 2007
Posts: 71
|
Quote:
Quote:
I neesdsome time to take a look. |
||
![]() |
![]() |
#17 | Link |
Registered User
Join Date: Jan 2007
Location: Tel-Aviv, Israel
Posts: 185
|
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. |
![]() |
![]() |
#18 | Link | ||
Registered User
Join Date: Sep 2006
Posts: 390
|
Quote:
![]() At some point Geremia discovered the essential part of the checksum function. 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 ![]() 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: Quote:
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 ![]() Code:
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 Code:
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 ![]() Eureka! ![]() 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: 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 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 from Code:
000218D0 A8 04 E3 05 Code:
000218D0 9F A0 E0 05 Taking A8 04 E3 05 and 9F A0 E0 05 here are the bit changes from 0 to 1: Code:
17 A0 00 00 Code:
20 04 03 00 Code:
E8 5F FF FF Code:
20 04 03 00 And it flashed. ![]() ![]() This is the last info (I have) on the actual patch needed for Volume ID retrieval: Code:
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 ![]() ![]() 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. Last edited by arnezami; 6th April 2007 at 08:13. |
||
![]() |
![]() |
#19 | Link | |
Registered User
Join Date: Feb 2007
Posts: 71
|
Quote:
![]() 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 ![]() Code:
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 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. |
|
![]() |
![]() |
#20 | Link | |
Registered User
Join Date: Jan 2007
Posts: 224
|
Quote:
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. |
|
![]() |
![]() |
Thread Tools | Search this Thread |
Display Modes | |
|
|