The Challenge Response Protocol

[robinsod]

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 removed

Type 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

AABBCCDD  where

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
1       0
2       1
0       2        Never seen one, I suspect it may be broken
2       3
2       5
2       7
1       E0

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.

[SuperMario]

Is this as far as you guys are at - good work, but there is a hell of a lot more to go! 

You'll find that Mode's 0x05 and 0x07 are the problem, specifically, the physical offset timing vs. LBA deltas and the subsequent challenge chains therein...

SuperMario.

[robinsod]

Could you explain that in a little more detail?

[SuperMario]

The main problem appears to be with Mode's 0x05 and 0x07 - specifically with the offset timing and physical location of specific sectors, against their logical location on the disc...

Is that specific enough? 

SuperMario.

[SuperMario]

Additional:

I might as well mention (for the others out there who are working on this alone) that the Vendor command 0xee is interesting to play with...

SuperMario.

[robinsod]

Bluntly, no. Let me explain

Experience shows that the type 5 & 7 response handlers can be patched to return hard coded values the 360 will still boot an original disk if the response data matches ie it has been captured during previous boots with the same original disk. This has been found to be true every boot. If there is something more sophisticated we need to understand it.

Perhaps you have a newer kernel than me?

So, I think some more detail would be useful

[jasper]

The main problem appears to be with Mode's 0x05 and 0x07 - specifically with the offset timing and physical location of specific sectors, against their logical location on the disc...

Is that specific enough? 

SuperMario.

Offset timing?  Meaning that if you read too soon (based on robinsod's info of a timing check), you get a different result?  Is that just a cheap way to try to foil those looking to put answers in (fast) firmware vs (slow) pressed media or am I just being paranoid?

[SuperMario]

Robinsod:  I am talking the difference between a non-authentic disc and a legitimate one.  Try your test with a copy of the same said disc and... ?

Jasper:  No, more like the difference between a pressed disc vs. a recordable one, I would think.

SuperMario.

[robinsod]

Beats me, reading the answers from disk, flash or RAM doesnt make any difference. if the numbers match the original game disk boots. Simple

[SuperMario]

  So what you're telling us all is that you can boot an original game?  Doesn't the console do this, like, when you power it on out of the box? 

I am refering to how the system can identify the difference between an original and a copy - why the figures are different and how the determination is done.

SuperMario.

[TheSpecialist]

Is this as far as you guys are at - good work, but there is a hell of a lot more to go! 

Are you sure ? Of course I wouldn't know, I don't know anything about 360 security I guess that rumour about some guys that succeeded in booting a backup was probably false then after all .. Stuff like that happens all the time

  So what you're telling us all is that you can boot an original game?  Doesn't the console do this, like, when you power it on out of the box? 

I think he's saying that if an original boots with hardcoded responses ... then why wouldn't a backup of that game boot ?

[SuperMario]

No, I wouldn't know what you know, for the simple fact that even if you did know something, you'd probably just clam up and use being scared of MS as a reason to not provide proof of it.

I have no desire to boot backups, I wish to determine exactly how the difference is determined between a legitimate disc and a copy, so as to be able to produce an exact replica.

SuperMario.

[TheSpecialist]

No, I wouldn't know what you know, for the simple fact that even if you did know something, you'd probably just clam up and use being scared of MS as a reason to not provide proof of it.

I think I did my contribution to the scene ... And I'm not sure what you're so frustrated about. Finally there's a thread with a lot of new very detailed security info and you're still not happy... Some people are REALLY hard to satsify ...

[SuperMario]

Oh, well, if you say so, it must be true... 

Not everyone is a pirate, some people are more interested in specifically how things work in order to do a job properly.

When you can produce a 1:1 copy that boots on a normal, unaltered X360, where the system can not differentiate between the original and the replica - then you'll have achieved something.

SuperMario.

[SuperMario]

Oh, I have got to post an update here, otherwise my replies are out of context for anyone else reading:

TheSpecialist:  Why have you altered your original post?  The one where you said "booting backups" that I originally replied to?

How many other of your posts have you gone back and edited?  Why bother to do anything when you can just change history, eh?

[TheSpecialist]

Let's keep this thread technical. Mods: please delete the chit chat (also mine). Supermario, I really don't know you and don't know what your problem is, but I think it's best to keep the messages on this board technical and if you have to say something to me personal, send me a message.

[SuperMario]

Agreed, this should be culled.

As it will be wiped soon, I'll answer your question in context here, TheSpecialist:

My main problem with you is simply that you have previously made claims, yet have provided no proof at all.

Next, you have been caught altering your previous messages in an attempt to disguise what you said, and to make someone else (me) look like the bad guy with my replies now being out of context.

That said, it is nothing personal.  I'd rather a discourse with the potential to produce results, than a slanging match, anyday.

SuperMario.

[TheSpecialist]

Ok, since the posts will be deleted anyway, hehe:
About me making claims and not showing proof: only time I did that was with the xbox 1 FW hack. I still regret today I made that post. I guess you live and learn. I learned that if you make an important breakthrough at 4:00 AM in the morning and you're so excited that all you want to do is tell the world about it => go to bed and decide the next day what you're going to do with it

About the 360 I haven't made any claims at all. All I said some guys were really far at  getting a backup booting. I think this thread is enough proof of that.

And about me editing posts to make you look bad: I edit 99% of my posts And that's not because I want to make anybody look like a fool Mostly typo's and bad chosen words and/or better ways of saying something, I'm not natively English and make mistakes all the time If I wanted to make you look like a fool, I wouldn't have called you a very talented hacker in that other thread or would at least have edited THAT post So I hope that's sorted out now...

[MacDennis]

When you can produce a 1:1 copy that boots on a normal, unaltered X360, where the system can not differentiate between the original and the replica - then you'll have achieved something.

a. This requires us to be able to 'burn' some bad sectors as specific locations. How are we going to do that?
b. It requires writing data in the middle zone and in the lead-in/out.

b. Might be possible with a modified burner firmware but I'm not sure about a.  ...

[grouik]

I might be talking of my ass here and I hope I wont offence anyone.

How can the console detects that the disc is a copy if u return exactly the same response to the challenges as the original?

Well I guess for challenges 5 & 7 the console compute the time it takes the drive to answer the challenge and compare it to the time the drive reports in a challenge response.
If the time it take the drive to answer the challenge is smaller than time in the the Challenge response, the console can conclude that the response is doctored.