The Challenge Response Protocol

[TheSpecialist]

It has been observed that they are in general NOT interchangeable on the xbox1. There's no reason to believe that the story is different on the x360.

Back on topic: the challenge/response session DOES succeed correctly on the xbox1 when you use a different security sector. But the game will NOT work. Speculation: it seems that the default.xbe / game is linked to the security sector somehow. Could be because of a signature or something ..

I'd like to elaborate on this. Some time ago, I stated that the security sector on xbox 1 was NOT linked to a specific game. I succesfully booted Amped with Rally sport's security sector. However, others that have succesfully replicated the xbox 1 hack, found that in most cases, this will NOT work and in some specific cases (like Amped+rallysport) it DOES work. Comparison of the security sectors shows some interesting similarities between these 2 games where they differentiate between other games. So it's speculated that some bytes in the sector are linked to the xbe (so in these cases you'd have to write (relocate) the security sector to disk, in order to boot the backup, since the majority of the security sector is signed, as is the xbe of course)

[nokaktsawa]

I'd like to elaborate on this. Some time ago, I stated that the security sector on xbox 1 was NOT linked to a specific game. I succesfully booted Amped with Rally sport's security sector. However, others that have succesfully replicated the xbox 1 hack, found that in most cases, this will NOT work and in some specific cases (like Amped+rallysport) it DOES work. Comparison of the security sectors shows some interesting similarities between these 2 games where they differentiate between other games. So it's speculated that some bytes in the sector are linked to the xbe.

Yeah, I remember that. That's exactly the reason why I asked about interchangeability. So, I guess that the safer solution is to store SS and CPR_MAI field infos taken from the original game disc on a burnable sector of its own backup disc, and then let the firmware retrieve these infos from there.

[TheSpecialist]

Yeah, I remember that. That's exactly the reason why I asked about interchangeability. So, I guess that the safer solution is to store SS and CPR_MAI field infos taken from the original game disc on a burnable sector of its own backup disc, and then let the firmware retrieve these infos from there.

Yes. The interesting question remains: why are these bytes (that cause the linking) the same for some games ? These byte might represent 'manufacturing plant info' for example. Still it's a bit weird but anyway, like said before, safe info to disc and you're ok

[MacDennis]

Yes. The interesting question remains: why are these bytes (that cause the linking) the same for some games ? These byte might represent 'manufacturing plant info' for example. Still it's a bit weird but anyway, like said before, safe info to disc and you're ok

Yes, some security sectors from different games are interchangeable, that's why I said 'in general'. Some bytes of these sectors are similar, simply compare Halo1 with Rallisport1 and you will spot them. But Spec, I'm not convinced yet that they are the 'key' to the linking. This has not been proven yet. The similarity is odd though.

I very, very doubt that x360 security sectors are interchangeable at all ..

[TheSpecialist]

Yes. The interesting question remains: why are these bytes (that cause the linking) the same for some games ? These byte might represent 'manufacturing plant info' for example. Still it's a bit weird but anyway, like said before, safe info to disc and you're ok

Yes, some security sectors from different games are interchangeable, that's why I said 'in general'. Some bytes of these sectors are similar, simply compare Halo1 with Rallisport1 and you will spot them. But Spec, I'm not convinced yet that they are the 'key' to the linking. This has not been proven yet. The similarity is odd though.

I very, very doubt that x360 security sectors are interchangeable at all ..

You're right, it's not been proven yet, sorry if i was not clear about that. Since the security sector is signed (and that HAS been proven) it's not easy to find out the cause. I think the best way to research it is to reverse the xbox 1 kernel's xbe loader and see if it does some checks other than the signature. However personally I don't feel it's THAT important, as I agree with you that I'm quite sure too that x360 SS's won't be interchangeable at all and it's always a better solution to save the SS to disc instead of firmware.

[headache]

The xbox1 kernel XBE loader does not do such additional "checks" ... as soon as the disc is authenticated the XBE gets loaded to RAM, some (section) hashes are checked and that's it.. no link between the security sector and the XBE... at least that's what my reliable bird was telling me

[Dzgx216]

Hmm,

    Not sure if anyone can answer these ?'s or not, but I don't think that they're TOO detailed that it could be incrimintaing in any way....

1. I'm gathering that the info stored in the first 0x661 bytes of the SS are different for each game, can this be confirmed? (also wondering if this is encrypted when dumped)
2. I'm guessing that the remaining 0x19f is different per game as well. (This If I remember correctly has to be manipulated against the CPR_MAI bytes (0xCF) to be decrypted then compared with 0xD0)
3. I'm wondering if based on the information that's contained in the first 0x661 bytes a different set of CPR_MAI bytes are sent based off the information in the first 0x661 bytes? (thus the need to "observe" the C/R sequence and capture the unique CPR_MAI bytes in the header?)
4.  We've discussed the option of embedding the SS info in an ISO and letting the FW retrieve them from that location, if we alter the FW to read the SS data from another location, which if I'm correct (probably not) wouldn't even be TOO difficult for someone of my (VERY LOW) level of experience.... If we do that, the console no longer points to the original SS location. Or can we set it up to look BOTH places?
5.When patching to an unused sector within an ISO, is one to dump the RAW contents of the SS 0x661 bytes, then Xor 0xcf, against the CPR_MAI then compare to 0xd0 and patch in the resulting values?
6. What is the meaning of life? (worth a shot)

  I had MUCH better notes on this at one point, however my fiancee decided to "Clean" my desk for me and thought that I had merely scribbled all over many pieces of paper and forgotten to do away with them.   After a mad dash to the dumpster I was horrified to find out the trash had already been removed and I was refused entrance to the local landfill (kidding).

Danzig

[robinsod]

1) I'm gathering that the info stored in the first 0x661 bytes of the SS are different for each game, can this be confirmed? (also wondering if this is encrypted when dumped)

The diffs would be useful

2. I'm guessing that the remaining 0x19f is different per game as well. (This If I remember correctly has to be manipulated against the CPR_MAI bytes (0xCF) to be decrypted then compared with 0xD0)

The descrambling of these bytes requires the corect CPR_MAI bytes from the sector header and MUST match the SS. Trouble is we dont know how the xbe and SS tie up exactly

3. I'm wondering if based on the information that's contained in the first 0x661 bytes a different set of CPR_MAI bytes are sent based off the information in the first 0x661 bytes? (thus the need to "observe" the C/R sequence and capture the unique CPR_MAI bytes in the header?)

We cant crack the CR table yet in those 0x661 bytes, if we could we wouldn't need to dump The CR exchange

4.  We've discussed the option of embedding the SS info in an ISO and letting the FW retrieve them from that location, if we alter the FW to read the SS data from another location, which if I'm correct (probably not) wouldn't even be TOO difficult for someone of my (VERY LOW) level of experience.... If we do that, the console no longer points to the original SS location. Or can we set it up to look BOTH places?

You can set it up to do the 'right thing' if an original or backup is inserted

5.When patching to an unused sector within an ISO, is one to dump the RAW contents of the SS 0x661 bytes, then Xor 0xcf, against the CPR_MAI then compare to 0xd0 and patch in the resulting values?

At your own discretion, it would appear best to replicate the SS and place the CPR_MAI bytes in another sector. Patch t the rght time & everything 'just happens'

6. What is the meaning of life? (worth a shot)

42, but you know that

[bourke]

Are we 100% sure the (DVD) region code of the console is not part of the DVD-ROM firmware or an EEPROM like last time?

If you are talking about movies. I have not seen proof yet if it's either part of the console or the DVD-ROM firmware or both. It's easy to find out though, just log the ATAPI communication. Yes it was in the EEprom last time. There's no reason to believe it's not a part of the console anymore. Speculation: it's most probably stored in the (encrypted) flash this time amongst other settings.

If you are talking about games. The console region was in the EEprom last time. Speculation: it's most probably now also stored in the (encrypted) flash. There's no reason to believe that this setting is stored in the DVD-ROM, that makes no sense.

So, to circumvent both you would need to be able to alter your flash memory. And that would mean a complete compromise of the security of the console.

You are right, in that last time it needed to be a separate EEPROM so that it could be updated separately to the firmware - however this time the firmware is updateable so it may well be in with the rest.

The advantage of keeping it external to the firmware is that you could bypass the region-coding (of both movies and games) without the need to compromise security.
That way M$ could allow region-circumvention whilst at the same time retain authority to crack-down on security-circumvention devices (i.e. weed out the legitimate import users from the software pirates).

So if they have gone down the EEPROM path I will be very happy as you could effectively attach several different region EEPROMS with a switch... and setup a very profitable Aussie import business :-)

[360videoguy]

Here's a video of someone playing a burnt copy of Project Gotham 3 http://www.youtube.com/watch?v=XyZQ4k7Bi-8 don't know if this is thr right thread.

[BlueCop]

Here's a video of someone playing a burnt copy of Project Gotham 3 http://www.youtube.com/watch?v=XyZQ4k7Bi-8 don't know if this is thr right thread.

HAHAHAHAHAHAHAHA. you are telling many of the people in the thread who developed the hack about the hack video. The orginal video link was actually posted in another section of this forum. This is all quite humrous to me.

[pOOBAH]

Here's a video of someone playing a burnt copy of Project Gotham 3 http://www.youtube.com/watch?v=XyZQ4k7Bi-8 don't know if this is thr right thread.

I think this

http://www.xboxhacker.net/index.php?option=com_smf&Itemid=33&topic=481.0

might be the right thread.

[MaV3RiCk]

The xbox1 kernel XBE loader does not do such additional "checks" ... as soon as the disc is authenticated the XBE gets loaded to RAM, some (section) hashes are checked and that's it.. no link between the security sector and the XBE... at least that's what my reliable bird was telling me

your bird is not so reliable...


SS offset
...
4ABh      ED10393E      Time/date stored in the xbe time/date certificate field too.
...
4CFh      20 bytes      SHA1 of the bytes from offset 4 to 4CFh (4CBh bytes).

these unique (per game) info are used in the game code to validate the media:

:0001650D    push ebp
:0001650E    lea ebp, dword ptr [esp-74]
:00016512    sub esp, 00000088
:00016518    mov eax, dword ptr [00010118]
:0001651D    push ebx
:0001651E    mov ebx, dword ptr [ebp+7C]      ebx = pointer dvd SS data
:00016521    mov ecx, dword ptr [ebx+000004AB]   ecx = Time/data
:00016527    cmp ecx, dword ptr [eax+04]      compare with one in the xbe certificate
:0001652A    je 00016536         same, dvd correct jump.
:0001652C    mov eax, C0000156         not the same set error code and return
:00016531    jmp 000165BC
:00016536    push esi
:00016537    push edi
:00016538    lea eax, dword ptr [ebp-14]      sha1 buffer
:0001653B    push eax
:0001653C    mov [ebp+7C], 000004CB      Init sha1 for 4CBh bytes
:00016543    call 0001B1E2         XcSHAInit
:00016548    push 00000004
:0001654A    lea eax, dword ptr [ebp+7C]
:0001654D    push eax
:0001654E    lea eax, dword ptr [ebp-14]      sha1 buffer
:00016551    push eax            update with 4 bytes size
:00016552    call 0001B1DC         XcSHAUpdate
:00016557    push [ebp+7C]
:0001655A    lea eax, dword ptr [ebx+04]      SS data + 4
:0001655D    push eax
:0001655E    lea eax, dword ptr [ebp-14]      sha1 buffer
:00016561    push eax
:00016562    call 0001B1DC         XcSHAUpdate
:00016567    lea eax, dword ptr [ebp+60]      final sha1 buffer
:0001656A    push eax
:0001656B    lea eax, dword ptr [ebp-14]      sha1 buffer
:0001656E    push eax
:0001656F     call 0001B1D6         XcSHAFinal
:00016574    push 00000014
:00016576    pop ecx
:00016577    lea edi, dword ptr [ebx+000004CF]   20 bytes sah1 stored in the SS
:0001657D    lea esi, dword ptr [ebp+60]      20 bytes sah1 calculated
:00016580    xor eax, eax
:00016582    repz
:00016583    cmpsb            compare 2 sha1
:00016584    pop edi
:00016585    pop esi
:00016586    je 0001658D         equal, so jmp to verify
:00016588    sbb eax, eax
:0001658A    sbb eax, FFFFFFFF
:0001658D    test eax, eax
:0001658F     je 00016598
:00016591    mov eax, C0000190
:00016596    jmp 000165BC
:00016598    lea eax, dword ptr [ebp+60]
:0001659B    push eax            20 bytes sha1 calculated
:0001659C    push dword ptr [003E529C]      XePublicKeyData
:000165A2    add ebx, 000004E3
:000165A8    push ebx
:000165A9    call 0001B1E8         XcVerifyPKCS1Signature
:000165AE    neg al            al = 1 signature passed
:000165B0    sbb eax, eax
:000165B2    and eax, 3FFFFE70
:000165B7    add eax, C0000190         eax = 0 media check passed.
:000165BC    pop ebx
:000165BD    add ebp, 00000074
:000165C0    leave
:000165C1    ret 0004

the point is that this code (which use NtDeviceIOControlFile with IOCTL_SCSI_PASS_THROUGH_DIRECT , DVD_STRUCTURE cmd) appeared in a MS xdk lib after some time.
So we can say that we had a "first generation games" without this link between the xbe and dvd. for example Halo1 and rallisport1.
Then they came these "second generation games" using this link to check the original dvd from inside the xbe code.
it's enough checking the certificate size field in the xbe header to spot the difference between first and second generation games.

if the size of this certificate is =< 0x1D8 the xbe game code doesn't care to verify the link with the dvd. Halo1/rallisport1 xbe code don't verify any link with the dvd. try to use TOCA xbe with the halo1 SS even passing through the dvd challenge response you need the toca original SS or the xbe will crashed itself after the link checking.

[TheSpecialist]

Very good and interesting post, MaV3RiCk ! I really wondered what caused the linking. Thanks for clearing that up, in such detailed way !

[MacDennis]

First of all, thanks for the detailed explanation MaV3RiCk.

the point is that this code (which use NtDeviceIOControlFile with IOCTL_SCSI_PASS_THROUGH_DIRECT , DVD_STRUCTURE cmd) appeared in a MS xdk lib after some time.
So we can say that we had a "first generation games" without this link between the xbe and dvd. for example Halo1 and rallisport1.

Well, it still doesn't explain why Halo1 can't be booted with a security sector from a game besides rallisport1.

My guess is that the (newer?) kernels do this check whatsoever. The second generation game now also have the option to perform this check as it seems. This allows the game designer to check this security sector at particular intervals. Same thing happened on the PS2 were suddenly authentication was also checked while the game was running.

But good info nonetheless, this gives some insight in the mysterious linking was has been proven now.

[Arakon]

Offtopic stuff deleted, the people it was pointed at read it, so there is no need to keep it here cluttering up the thread.

[badsheepy]

Sorry to bump this topic a bit, but to comment on MaV3RiCk's disassembly, the checksum is
at 0x4cb in the SS, and consists of the 4 bytes 0xcb, 0x04, 0x00, 0x00, and the initial 0x4cb bytes, ie:
  byte[] hashheader = { 0xcb, 0x04, 0x00, 0x00 }; // size of hash, least significant byte first
  sha.TransformBlock(hashheader, 0, 4);
  sha.TransformFinalBlock(RawSS, 0, 0x4cb);
and the sha hash should equal the 20 bytes at 0x4cb.