Here are my findings on the 360's Challenge Response Mechanism.
To fully utilise this information you will need to be able to dump the security sector (SS) and the CPR_MAI bytes (CB) for PSN fd021e. You will also find a mechanism to record the CR exchange is useful. Such tools are beyond the scope of this post.
As you no doubt already know the first 0x661 bytes of the SS are retreived by the console using the ReadDVDStructure Command. This is then decrypted and the console has a set of Challenges and Responses. Challenges are issued to the drive (in the form of a Challenge ID (CID) and 4 bytes of Challenge Data (CD)) and the response compared with the decrypted table. If all checks pass the drive unlocks and the game boots.
So how does the drive get the Response data? TheSpecialist first posted on the subject of the drive's response table. The remaining 0x19f bytes of the SS are divided into a scrambled message (0xcf bytes) and a lookup table (0xd0 bytes). The drives response table can then be found by xoring bytes from the message with the CB and then looking up the result in the table. You will find the exact algorithm in my sector decryptor code and elsewhere on this board.
Lets look at the drives response table from PGR3 PAL
03 23 00 03 46 D0 03 56 CF 0346D0 0356CF FFF
01 16 00 20 F8 F0 21 08 EF 20F8F0 2108EF FFF
03 24 00 DF 07 10 DF 17 0F DF0710 DF170F FFF
01 79 00 FC B9 30 FC C9 2F FCB930 FCC92F FFF
07 17 00 03 46 D0 03 54 4F 0346D0 03544F D7F
05 F5 00 20 F8 F0 21 06 6F 20F8F0 21066F D7F
07 4A 00 DF 07 10 DF 14 8F DF0710 DF148F D7F
05 5D 00 FC B9 30 FC C6 AF FCB930 FCC6AF D7F
00 90 00 3C 2E 19 3E 15 BE
E0 F6 00 02 90 BE E4 74 3F
Byte 0: Response Type
Byte 1: CID
Byte 2: Currently always 0, can be 0-3 appears to modify response
Byte 3-8: Data the drive will require to create the response
There appear to be some padding entries (response type 0xF0-0xFE) which I have removedType 0 Responses:
Same as XB1, we simply discard the 1st and 4th byte of the response data. There appears to be only 1 type 0 response.
CID CD Response 90 2709C26C 2E1915BE
The CD is also the CB, which BTW is dumb, since if you observe the CR exchange it makes it easy to guess the CB!!! Type 1 Responses
These differ from the XB1 in that they require data to be read from a sector other than the SS. Notice that the response data for type 1 & 3 responses is a range of PSNs? They happen to 0xFFF sectors long and that is 8MB (which as a wise man told me is the size of the place holder data in the MS patent). This sector range holds both good and bad setors. The data we are looking for happens to be located in a good sector at PSN range start + 0x1E0 or in the case of CID 0x16 20F8F0 + 1E0 = 20FAD0. You will find the CD followed by the response in the first 8 bytes of the sector.
There is also a type 2 response which I haven't seen in the wild. I found it was using the same handler as the type 1 in the TS but not in the LG. Maybe someone screwed up and type 2 is now unusable because of differences between the drives?Type 3 Responses
Very similar to type 1 but you will find the CD and response at PSN range start + 600, 620, 640, 660, 680, 6A0, 6C0, 6E0 and there does appear to be some selection of the offset into the range but I have not fully analysed that code. Testing suggests that whatever its doing it doesn't change its behaviour for a particular game ie the response is always the same.Type 5 & 7 Responses
These are more interesting and appear to measure th time taken to read/seek across a range of PSNs. Since the PSN range contains bad sectors that we cannot burn my guess is that these challenges will return very different numbers for DVDR compared with pressed disks. The general form of the the response data is
AA is the LSB of a 16 bit timer
BB is the MSB of a 16 bit timer
CC is the second byte from PSN start + D7F
DD is the first byte from PSN start + D7F
Note: The actual timer value is different for different sector ranges but the actual value seems pretty constant across multiple boots. The value seems to vary very slightly but the 360 wil certainly accept values +/-2 from the mean. I expect that range to be far larger because of variations in drive vendor, manufacturing variations, temperature, wear & the dollar exchange rate. I haven't tested the actual acceptable limits because I'm idle and dont care that much
If you find timing weighing heavy on your hands......
TS kindly provided an ATAPI debug function that takes two PSNs as parameters and appears to perform the same timing measurement, returning the required response data.Type E0 Responses
This appears to be some form of CID check. The CD is the CIDs of the last four CR exchanges in reverse order. The drive also stores the CIDs and returns them ( also in reverse order). If they match........
Here's a typical set of CIDs and CD observed during a CR exchange to illustrate the point:
CID CD Response Resp Type
17 16CD4E94 7
24 ACA2D11E 3
16 CBD9E4E1 1
F5 FA0560D1 5
90 2709C26C 0
F6 90F51624 90F51624 E0
Notice the sequence 90,F5,16,24
Thats about all there is to know about the CR mechanism in the 360 to date, of course this could change soon. In the disks I have examined I have found the following totals for each response type:
Total Response Type
0 2 Never seen one, I suspect it may be broken
There are 6 CRs exchanged during authentication out of a total of 9. It seems that its enough to simply observe the CR exchanges and respond with the observed data when challenged.
I have been deliberately vague about response types 5 & 7, I also haven't provided a full set of CR data. I suspect that data is copyright and therefore I cant post it. Also it would simply suck all the fun out of it for you
I am deeply indebted to the team I have been working who are without a doubt some of the most talented (and anonymous) engineers I have come across. In particular I'd like to thank TheSpecialist and 'Bob' (you know who you are) and all the others who contributed Again, please dont ask me for CR data, I wont give it to you and I dont have it.