Xbox 360 Timing Attack

From ivc wiki
Revision as of 00:34, 28 August 2007 by Ivc (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Possible MS Updates

arnezami:

MS cannot fix this problem by simply changing the memcmp function in a future kernel version. Thats not
gonna help them. The weakness is that the byte-wise memcmp function is in the 1888 kernel/bootloader
(and they cannot change that one anymore of course). [1]

tmbinc:

sure, microsoft can change the 2BL, and burn a fuse (of the fuseline 2) so that an old 2BL doesn't work anymore... [2]

arnezami:

Ah. Right. If they can indeed burn these fuses at row 2 than you wouldn't be able to run any of the lower 
kernel versions anymore. [3]
Been thinking about this. I'm now pretty sure when row 2 of the fuses is burned your xbox won't be able to 
downgrade or run homebrew anymore (it appears the fuse count number is indeed RSA signed). [4]

surrido:

you could if it makes you happy wire a switch to the R6T3 and keep it on while being in live and turn it 
of when you receive an update. [5]

tmbinc:

No, a switch at R6T3 doesn't help. It's not the resistor which presence can be detected, but the result to the fuse (burned or not).

So his question is completely valid: If you remove the resistor, you could end up with an unbootable box 
after the next update. But at least you could restore a previous flash. (If you want, you could *then* 
re-attach the resistor, and update again, of course loosing the possibility to downgrade). [6]