Timing attack - stupid questions thread.

[Geremia]

too kind, but sincerely i did nothing this time. 
i was just there with the tool that you and robinsod were missing.

congrats again 

[spanky34]

You guys are utterly amazing here at XBH.  I think the amount of smart people that work in these forums can open anything up given enough time.  So this is what, 20 months since launch and just about a complete hack.  Hard work pays off in the end, Congrats!

[Surrido]

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).

There is some other stuff they could do, but I'm pretty sure making a backup of your flash now (link) will allow people to downgrade at any time in the future no matter what they throw at us.

Of course a new kernel version should still be checked for "the other things" they could do to prevent downgrading for those that do not have a backup of their fw yet...

i agree (my post of that was deleted in the tech thread, sorry for that :-p )

we have to educate 10.6 million 360 owners to remove R6T3 and dump their NAND and keep it in a safe place :-)

my question is. might there be another place in that nice kernel game were we can play the timing card?

[arnezami]

my question is. might there be another place in that nice kernel game were we can play the timing card?

I've been thinking about that. But came up empty (so far).

Things I believe are not time-attackable (well at least not memcmp attackable):

- Any one of the RSA signatures (during boot and also xex'es) because we have no byte-wise control over what goes into the memcmp.
- Keyvault because of the "tight" way its encrypted and verified. If we change one byte in the signature (which also doubles up as input for key generation) the decryption key will be wrong and you get a garbage kv.
- DVD drive communication/authentication to find DVD key. From what I understand an encrypted nonce is exchanged (?) and its used as session key. Not sure about the details, maybe somebody can point to (the address of) the code involved. But if this is the case we probably can't use a timing attack.

So far the CB-auth and CF-auth seem to be the only ones. And CF-auth is done at much higher speeds which means its practically very difficult. We got lucky we only need CB-auth .

arnezami

[tser]

Excelent Job...people of the world

we have to educate 10.6 million 360 owners to remove R6T3 and dump their NAND and keep it in a safe place :-)

if 0.01% of the owners is an active coder, we now have an additional 1.000  coders! Helllo there!

[arnezami]

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

The fuses (one char is one nibble) have the following form:

ABCCCCCCCCCCCCCC
DDDDDDDDDDDDDDDD
EEEEEEEEEEEEEEEE
FFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFF
GGGGGGGGGGGGGGGG
HHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHH
HHHHHHHHHHHHHHHH

E is encoded similiar to the G/H fields (see below), and also has to match a minimum value in 'CB'. Maybe this is some (yet unused?) revocation algorithm? It's however unrelated to the upgrade. It's set with bit=2

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.

So thats probably what they are going to do next kernel update.

Meaning: if you want to keep running homebrew/linux you probably won't be able to go live anymore in the future (not even when a dual fw). But anyway all xbox owners can downgrade now. So everyone has to make this (hard) choice for himself: homebrew or live.

Unless of course you remove the resistor and the new kernel will still run without the fuses in row 2 burned.

We'll have to wait and see.

Regards,

arnezami

[edit] I'm not sure yet whether the "fuse count" used here is RSA signed or not...

[arnezami]

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

But that means that we have 10 mio. potentially  exploitable boxes out there *at the moment*. No more excuses for people to not being able to get an exploitable box. It's different than last time. If you update now, it's your fault, not anyone else's. You have been warned.

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).

But...



you don't have to do the real upgrade but instead "fake" being upgraded: since you are in complete control of your xbox (after the KK exploit) and have all the keys of your keyvault you could (in principle) run the new (but patched) kernel. There would be some stealthening involved but it would very likely work.

Tons of work to "re-boot" your xbox into an (unsigned) upgraded xbox (and be stealthy about it) but I don't see a fundamental problem here.

Most importantly you have to make sure your row 2 of your fuses never get burned. In other words: remove that r6t3 resistor!

Just my 2 cents...

arnezami

[ForSwitch]

I've been thinking about that. But came up empty (so far).

Things I believe are not time-attackable (well at least not memcmp attackable):

- Any one of the RSA signatures (during boot and also xex'es) because we have no byte-wise control over what goes into the memcmp.
- Keyvault because of the "tight" way its encrypted and verified. If we change one byte in the signature (which also doubles up as input for key generation) the decryption key will be wrong and you get a garbage kv.
- DVD drive communication/authentication to find DVD key. From what I understand an encrypted nonce is exchanged (?) and its used as session key. Not sure about the details, maybe somebody can point to (the address of) the code involved. But if this is the case we probably can't use a timing attack.

[/quote]

The one thing that I've been drooling over is the hard drive.  Assuming the memcmp implementation in "Xlibc" (xam.xex?) is the same as the one in the bootloader (and there's a chance it isn't), I believe we could write a software bruter for more hashes for larger drives.  This comes with very little research, but whatever.

[Protonus]

Most importantly you have to make sure your row 2 of your fuses never get burned. In other words: remove that r6t3 resistor!

I searched this site and came up dry for instructions on removing that resistor.  I'm banned from XBS... can someone point me to a picture showing the location of the resistor? Thanks..

[arnezami]

Most importantly you have to make sure your row 2 of your fuses never get burned. In other words: remove that r6t3 resistor!

I searched this site and came up dry for instructions on removing that resistor.  I'm banned from XBS... can someone point me to a picture showing the location of the resistor? Thanks..

Here is a link: http://www.free60.org/wiki/R6T3

Be very careful though. This is not your "average sized" resistor. If you don't feel up to it or don't have the right tools just don't do it and wait until the next fw version comes out and decide then what to do after the update has been analyzed.

arnezami

[sentinel0]

I cheated to get my resistor off i made it a 2 man job.  That simplified things quite abit.

[xordef]

The problem wasn't the implementation, the problem was a consciously taken design decision. A bad one, as it seems.

I think we can agree to disagree if that need be When securing (embedded) systems you not only have to create a good design - you also have to make sure that you keep the control you've just designed all the way down to the lowest possible level. After all, you've just spent quite a lot of money on the top level stuff (beginning with the per-CPU key) so why waste it on basic things like chosing a non-functioning hash algorithm (Xbox 1 example) or information leaking compares (this 360 attack vector)?

Now, to be fair. After I wrote my previous post I realised that their ability to block this with new kernels and fuse-blowing could be seen as a design decision that makes it reasonable to not have to secure all the code. Looking at it that way, I would say you are correct in your description.

(This might be a meta discussion, but at least I find it interesting in itself)

[mrblack1134]

Now, to be fair. After I wrote my previous post I realised that their ability to block this with new kernels and fuse-blowing could be seen as a design decision that makes it reasonable to not have to secure all the code. Looking at it that way, I would say you are correct in your description.

(This might be a meta discussion, but at least I find it interesting in itself)

Granted, I think their ability to update kernels will inevitably dampen, one way or another, homebrew on the 360. What I mean by that is people were (and some still are) buying new xbox1 boxes to convert them off the shelf in ultimate emulation / media center machines; we can be pretty sure that new 360's will always ship with the latest kernel (given a couple of week/months buffer, of course), and thus probably be non-hackable (unless new exploits are chased all the time). Putting the new kernel on shipped boxes is a lot easier than changing PCB design to thwart modders (though xbox 1.5 to 1.6 was quite a failed attempt, but anyways).

Fast-forward a couple of months from now in a perfect world; Infectus come out with a uber-cool all-in-one hash finding chip, we can all downgrade & start poking around with linux & everything, XBMC is ported to 360/linux in its HD glory & all and we have a kick-ass system again (let me dream for a moment...). The problem is that the average Jo can't go to the store, get a new box, solder a few wires and be all set, since his new box will probably have the exploit plugged.

All I'm saying is that while the security system certainly has flaws the design makes it so they're easily pluggable. We either have to keep chasing holes in new kernels, or find a 'hero' security exploit that will require hardware changes on MS's side.

That is, if we really want to let the uninformed average Jo able to enjoy homebrew...

Just my 2.2c *adjusted for inflation

[lasonnette]

or maybe a flaw in 1888...that way we would have the kiosk disc booting again...

edit: wasn't someone talking about a shader in the dashboard some time ago?

[roofus]

The one thing that I've been drooling over is the hard drive.  Assuming the memcmp implementation in "Xlibc" (xam.xex?) is the same as the one in the bootloader (and there's a chance it isn't), I believe we could write a software bruter for more hashes for larger drives.  This comes with very little research, but whatever.

SATA disk authentication is handled in the kernel, not in xam.xex.  The hard disk is authenticated by decrypting an RSA signed PKCS1 SHA1 hash and comparing it with the SHA1 hash of the target data.  Bruteforcing the data necessary for a collision in SHA1 (160 bits) is not currently possible, and timing information is not helpful - it does not reveal anything about an RSA private key.

[jas0nuk]

Excellent work everyone, it was great following this idea from the first post by arnezami to this good news a few days ago!

[jkhax0r]

This is probably a stupid question, but what keeps microsoft from detecting that the e-fuse resistor has been removed?  I understand how it keeps you safe for always downgrading, but couldn't a new kernel detect that it can't successfully blow a fuse (b/c the resistor is gone) and then ban you from XBL for having "modded" your box? 

[Surrido]

i think its been said about a thousand times. if you mess around with your xbox, dont count on xbox live anymore. this is the simpest rule of the game.

noone here can guarantee you anything about their detection. we can asume things and find some things. in theory MS could dump all the stuff , kernel, keys, errorlogs... everytime you go to xb-live.

it allways depends on the scale things reach...

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.

the question is allways for you how badly do you want to have homebrew on your 360 and for MS how many modders do they want to kick out of xbox live...

[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).

Still, it's a no-win option: Games and homebrew doesn't play nicely together at the moment. Sorry.

[robinsod]

A little update. I can now "guess" 3-400 times onaverage before failure strikes! Thats a big improvement on a week ago when every "guess" needed a plug/unplug cycle I "guess" at the rate of 1 every 2 seconds. Lets say 2.5 hours worst case (including a few retries for dubious results)

Images:

http://rapidshare.com/files/51711822/DGImages.rar.html

1) The ghetto hardware, use what ya got
2) Easier POST points
3) "Wired for gas". Top right hand hand side is optional (power/CPU UART)

Better Stats for timing at all 16 hash positions:

http://rapidshare.com/files/51712219/DIST_0_300.csv.html