Got VolumeID without AACS authentication :) - Doom9's Forum

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.


Go Back Doom9's Forum > General > Decrypting
Reload this Page Got VolumeID without AACS authentication :)

(追記) (追記ここまで)
Closed Thread
Page 1 of 15 1 2 3 11 Last »
Thread Tools Search this Thread Display Modes
Old 4th April 2007, 01:06 #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
Geremia is offline
Old 4th April 2007, 04:00 #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 ) 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.
Last edited by arnezami; 12th April 2007 at 18:55.
arnezami is offline
Old 4th April 2007, 13:01 #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.
Geremia is offline
Old 4th April 2007, 15:08 #4 | Link
Registered User

Join Date: Feb 2007
Posts: 123
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???
lightshadow is offline
Old 4th April 2007, 16:13 #5 | Link
Registered User

Join Date: Feb 2007
Posts: 85
Quote:
Originally Posted by lightshadow View Post
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 ;-)
bourke is offline
Old 4th April 2007, 17:21 #6 | Link
Registered User

Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by lightshadow View Post
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 (and here).

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.
arnezami is offline
Old 4th April 2007, 17:49 #7 | Link
Pain and suffering

Join Date: Jul 2002
Posts: 1,337
As long as we can not "backup" our "encrypted .iso backups", AACS is not fully cracked at all
bob0r is offline
Old 4th April 2007, 18:05 #8 | Link
Registered User

Join Date: Feb 2007
Posts: 123
Quote:
Originally Posted by arnezami View Post
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 =)

Quote:
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 =)

Quote:
[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 (and here).
Is a complete reverse engineered firmware for that needed?
lightshadow is offline
Old 4th April 2007, 18:08 #9 | Link
Registered User

Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by lightshadow View Post
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.
Last edited by arnezami; 4th April 2007 at 19:36.
arnezami is offline
Old 4th April 2007, 19:18 #10 | Link
Registered User

Join Date: Feb 2007
Posts: 71
Quote:
Originally Posted by arnezami View Post
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.
Geremia is offline
Old 4th April 2007, 19:46 #11 | Link
Registered User

Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by Geremia View Post
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
Last edited by arnezami; 4th April 2007 at 19:50.
arnezami is offline
Old 5th April 2007, 01:56 #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
Geremia is offline
Old 5th April 2007, 06:57 #13 | Link
Registered User

Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by Geremia View Post
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:



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.
arnezami is offline
Old 5th April 2007, 12:26 #14 | Link
Registered User

Join Date: Feb 2007
Posts: 71
Quote:
Originally Posted by arnezami
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

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.
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.
Geremia is offline
Old 5th April 2007, 14:11 #15 | Link
Coder

Join Date: Jan 2007
Location: Around the World
Posts: 697
How can we help your work?
Pelican9 is offline
Old 5th April 2007, 14:18 #16 | Link
Registered User

Join Date: Jan 2007
Posts: 224
Quote:
Originally Posted by Pelican9 View Post
How can we help your work?

Yeah, and we wanna guide to the hack too
Galileo2000 is offline
Old 5th April 2007, 19:18 #17 | Link
Registered User

Join Date: Jan 2007
Location: Tel-Aviv, Israel
Posts: 185
Quote:
Originally Posted by Galileo2000 View Post
Yeah, and we wanna guide to the hack too
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.
awhitehead is offline
Old 5th April 2007, 20:21 #18 | Link
Registered User

Join Date: Sep 2006
Posts: 390
Quote:
Originally Posted by awhitehead View Post
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. 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:

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

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
Into this:

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
And thats just sweet . 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!

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
The patched code:

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
Code:
000218D0 A8 04 E3 05
to
Code:
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:

Code:
17 A0 00 00
And these are the bit changes from 1 to 0.

Code:
20 04 03 00
This means we have to compensate in an FF area the following way:

Code:
E8 5F FF FF
And in a 00 area the following way (this is simple):

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

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
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.
Last edited by arnezami; 6th April 2007 at 08:13.
arnezami is offline
Old 6th April 2007, 00:29 #19 | Link
Registered User

Join Date: Feb 2007
Posts: 71
Quote:
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

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
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.
Geremia is offline
Old 6th April 2007, 03:43 #20 | Link
Registered User

Join Date: Jan 2007
Posts: 224
Quote:
Originally Posted by Geremia View Post
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

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
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.
Galileo2000 is offline
Closed Thread
Page 1 of 15 1 2 3 11 Last »

Thread Tools Search this Thread
Show Printable Version Show Printable Version
Email this Page Email this Page
Search this Thread:

Advanced Search
Display Modes
Linear Mode Linear Mode

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 17:06.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2025, vBulletin Solutions Inc.

(追記) (追記ここまで)

AltStyle によって変換されたページ (->オリジナル) /