xboxscene.org forums

Pages: [1] 2

Author Topic: Research on 'Timing Attack' to Downgrade Kernel without CPU Key  (Read 177 times)

Xbox-Scene

  • Archived User
  • Hero Member
  • *
  • Posts: 4299
Research on 'Timing Attack' to Downgrade Kernel without CPU Key
« on: July 27, 2007, 07:43:00 PM »
Research on 'Timing Attack' to Downgrade Kernel without CPU Key
Posted by XanTium | July 27 21:43 EST | News Category: Xbox360
 
The hackers over at the XBH forum are researching a new way to downgrade the kernel (to a kernel with vulnerable hypervisor) without knowing the unique per-xbox CPU Key. Note that this 'hack' has NOT been confirmed or performed yet, right now it's just an idea/project and they are researching if and how this can work. Also note that if it works, it's no 'Hero attack' (hacked once, working for all 360s) and thus will have to be performed again on each Xbox360 (which might not be a solution for normal end-users if expensive HW is required for the timing ... but they are also looking into possible solutions for this). It's pretty technical, but the introduction is below.

From arnezami on xboxhacker.net:
Quote

The problem:
We currently do not have a way to downgrade without a cpu key (especialy when fuses are blown). From what I understand there are two main problems:
    * The CB is signed/authenticated with the cpu key using an HMAC algo. Unless you have a dump of the CB before upgrading you won't be able to create this "signature" without the cpu key.
    * In the decrypted CF there is a "version lockdown counter". This part of the CF is also signed/authenticated by the cpu key. Without it you cannot change the blown fuses counter.

I believe there may be a way to (depending on several conditions) to downgrade without a cpu key. ;)

The idea:
It would be foolish to try to break SHA1-HMAC. However the output of a hash usually has to be checked against something that is stored. Thats usually the point of it. This takes (a tiny bit of) time. The thing is many memcmp functions use a byte-wise compare: "as long as no difference in the current byte is detected go to the next byte, but if this byte is different stop". In other words: it might take (a fraction of a second) longer if the output is similar at the beginning (to the stored value) as opposed to completely different 16-byte values. If it is possible to measure this time difference you could change the first stored byte (up to 256 times) until it takes this fraction longer for the xbox to detect the (16 byte) values are not entirely the same. And you can go on with this until all bytes have been figured out this way.

It this technique would work you could do the following:
    * Encrypt and flash the NAND with an exploitable kernel (CB/CD/CF etc) using the 1BL key. The 16 byte auth-values (in both the CB and CF) will of course not be correct.
    * Add hardware that can measure time/clocks from a certain point in the boot sequence until a detectable moment after the (failed) verification of the CB auth value.
    * Make sure you change the first stored byte of this CB auth value and reboot. Go on until it takes a tiny bit more time for the xbox to detect the CB auth value is incorrect. This means you've found the first byte.
    * Go on until all 16 bytes are found.
    * After this do essentially the same with the auth-value in the CF (using a different trigger point of course).
    * You should now be able to boot into a vurnable kernel and extract your fuses.

The conditions:
Needless to say there are a lot of things have to be just right for this to work at all. Here are the conditions for this to (remotely) possible:
    * In both cases (CB auth and CF auth) the value stored has to be directly compared with another value (eg the HMAC output). There should not be some kind of (crypto) operation on these value before comparision.
    * The comparison should be byte wise.
    * The difference between the amount of the identical starting bytes should be measurable. Possibly using a triggger point from where to count/time it.

Just to be clear: I simply don't know if the conditions can be met. The coding stuff can best be checked by those who have easy access to RE'd code. The (hardware) timing will be much more difficult. So I guess it should first be checked how the checking/comparison algos are implemented before thinking about the possible hardware challenges.

More Details/Tech Discussion: xboxhacker.net (tech replies ONLY please, thx)

Logged

tomgreen99200

  • Archived User
  • Hero Member
  • *
  • Posts: 826
Research on 'Timing Attack' to Downgrade Kernel without CPU Key
« Reply #1 on: July 27, 2007, 07:26:00 PM »
Hooray Timing Attack !! Hooray XBMC360 !!
Logged

Jstraw

  • Archived User
  • Newbie
  • *
  • Posts: 32
Research on 'Timing Attack' to Downgrade Kernel without CPU Key
« Reply #2 on: July 27, 2007, 07:34:00 PM »
smile.gif So your saying that it may be possible to boot the new kernel partially then strategically load the old kernel with a timing device once the newer kernel unlocks the system.  Isn't that called injection coding?  Makes sense though.  So 360 starts to boot, in order to do that, a security check looks at the kernel and gives an ok to start loading of the kernel system, we then inject the old kernel on top of the new (being that they are both signed) and viola!  Exploited kernel ready to run.  HOMEBREW?!!  I hope I'm on the right track.  Wouldn't that require a modchip that would store the old kernel and port/read the new one.  Seems inexpensive and worth looking into.  Although I might be psychotis and read this article totally wrong.  Feel free to redirect my active thinking if i'm off track. pop.gif
Logged

mrdan

  • Archived User
  • Newbie
  • *
  • Posts: 39
Research on 'Timing Attack' to Downgrade Kernel without CPU Key
« Reply #3 on: July 27, 2007, 08:16:00 PM »
QUOTE(Jstraw @ Jul 27 2007, 09:10 PM) *

So your saying that it may be possible to boot the new kernel partially then strategically load the old kernel with a timing device once the newer kernel unlocks the system.


It doesn't work like that.

This method basically allows us to discover the correct CB and CF auth-values.

Read more here: http://www.xbox-scene.com/xbox1data/sep/EE...lkAWyvjrKRY.php

This post has been edited by mrdan: Jul 28 2007, 03:19 AM
Logged

Lush

  • Archived User
  • Sr. Member
  • *
  • Posts: 261
Research on 'Timing Attack' to Downgrade Kernel without CPU Key
« Reply #4 on: July 27, 2007, 08:21:00 PM »
good luck to all those involved!
Logged

Home Less

  • Archived User
  • Newbie
  • *
  • Posts: 49
Research on 'Timing Attack' to Downgrade Kernel without CPU Key
« Reply #5 on: July 27, 2007, 09:14:00 PM »
When M$ reads this, won't they just change the way it detects so that it doesn't instantly fail if one of the earlier bytes are wrong? couldn't they just have it check the entire string of 16 bytes even if the first byte doesn't match?

or does M$ not have the ability to change this checking process?
Logged

Rustmonkey

  • Archived User
  • Sr. Member
  • *
  • Posts: 475
Research on 'Timing Attack' to Downgrade Kernel without CPU Key
« Reply #6 on: July 27, 2007, 09:22:00 PM »
QUOTE(Home Less @ Jul 27 2007, 09:50 PM) View Post

When M$ reads this, won't they just change the way it detects so that it doesn't instantly fail if one of the earlier bytes are wrong? couldn't they just have it check the entire string of 16 bytes even if the first byte doesn't match?

or does M$ not have the ability to change this checking process?


Well, no one knows for sure if they have access to these... however, it really wouldn't matter if you picked up a BANNED box and used it for homebrew purposes - if you're adamant about playing games on it, then you could use an infectus (which you would probabley need in the first place) to downgrade your kernal again after forced updates - but if homebrew is up and kickin, I'm sure we would be able to spoof newer games anyways (but this is obviously along ways off)...
Logged

flashfreak

  • Archived User
  • Hero Member
  • *
  • Posts: 683
Research on 'Timing Attack' to Downgrade Kernel without CPU Key
« Reply #7 on: July 27, 2007, 09:53:00 PM »
They've certainly done an excellent job on the security with the 360. Look what its coming to, how complicated its getting! So close yet still so far...
Logged

Software2

  • Archived User
  • Sr. Member
  • *
  • Posts: 385
Research on 'Timing Attack' to Downgrade Kernel without CPU Key
« Reply #8 on: July 27, 2007, 10:37:00 PM »
I'm getting very temped to open my system up and rip off that resistor to stop any further damage from being done.
Logged

telo{+}

  • Archived User
  • Sr. Member
  • *
  • Posts: 316
Research on 'Timing Attack' to Downgrade Kernel without CPU Key
« Reply #9 on: July 28, 2007, 12:39:00 AM »
Home Less: Depending on what hardware this check is done on then yes. But, yea these guys are banking on MS having coded it check a byte and only proceed on success, which creates a bunch of potential times for correct and wrong answers. If ms changed to code to check a byte and then still check the next one all the while just keeping a flag of valid or not that get compared at the end then this attempt would be defeated. Thats generally poor programing however... Funny, good programming techniques could end up creating a hole to attack

From my understanding of what is proposed it looks like its very much just an idea.
Logged

ConteZero76

  • Archived User
  • Full Member
  • *
  • Posts: 244
Research on 'Timing Attack' to Downgrade Kernel without CPU Key
« Reply #10 on: July 28, 2007, 01:05:00 AM »
It's possible (no, it's likely) that the entire signature block is loaded to cache before the actual check.
If you aren't able to detect a 2 clock cycles (at 3,2 GHz) it's really difficoult to "capture" differences.
Anyway if Microsoft was dumb enough (this kind of trick is quite old, most signatuer checks do confront ALL the value no matter what) they'll close the hole in a firmware upgrade.

This hack was first used 20+ years ago to steal root passwords on some paged architecture system.
The malicious code put the known password part plus the guessed char at a page boundary, a pass check call plus a page fault detection made the work:
If a page fault occours then the guessed char was right, so add the char to the known password part, and retry.
If page fault doesn't occour then the guessed char is wrong, retry with another char.

This post has been edited by ConteZero76: Jul 28 2007, 08:12 AM
Logged

torne

  • Archived User
  • Sr. Member
  • *
  • Posts: 383
Research on 'Timing Attack' to Downgrade Kernel without CPU Key
« Reply #11 on: July 28, 2007, 02:50:00 AM »
QUOTE(ConteZero76 @ Jul 28 2007, 08:41 AM) View Post

It's possible (no, it's likely) that the entire signature block is loaded to cache before the actual check.

Doesn't matter, the timing difference is from the comparisons being executed.

QUOTE

If you aren't able to detect a 2 clock cycles (at 3,2 GHz) it's really difficoult to "capture" differences.

It looks like the CPU probably isn't running at full speed at this stage in boot, plus there is a nice debug port that outputs values to tell you when certain stages have been passed in startup. smile.gif

QUOTE

Anyway if Microsoft was dumb enough (this kind of trick is quite old, most signatuer checks do confront ALL the value no matter what) they'll close the hole in a firmware upgrade.

They are dumb enough - the code has been reverse engineered and the comparison is byte-by-byte, and bails as soon as a byte is wrong. The only part that's up for debate is whether the timing difference is detectable, and with sufficiently expensive equipment it will be. The tricky bit is getting it detectable using *cheap* hardware, since this has to be done per-box.

Sure, they can fix it in a firmware upgrade, but it still widens the window of which kernels can be exploited. If they fix it in a future update then people can just not upgrade until they've had a chance to recover their key this way wink.gif Also, since you'll require an Infectus or other programmer to take advantage of this, you can just back up your current NAND, remove r6t3, then downgrade later.
Logged

ConteZero76

  • Archived User
  • Full Member
  • *
  • Posts: 244
Research on 'Timing Attack' to Downgrade Kernel without CPU Key
« Reply #12 on: July 28, 2007, 03:14:00 AM »
If Flash is readed directly byte-wise something is possible.
Anyway I (as a moddable bios X360 owner) am still waiting for something useful to do with that.
Sure, I can try to run linux but nothing good will come until someone develop a modified firmware with no checks and a dashboard with "extended" features.
None of both is near to be seen, so you can downgrade just to run Linux and hope...

...and you're unable to go live or play games from C'n'C on...

This post has been edited by ConteZero76: Jul 28 2007, 10:15 AM
Logged

bucko

  • Recovered User
  • Hero Member
  • *
  • Posts: 4255
Research on 'Timing Attack' to Downgrade Kernel without CPU Key
« Reply #13 on: July 28, 2007, 03:50:00 AM »
XD, if this allows Linux on every 360 out there, it will be awesome.
Logged

torne

  • Archived User
  • Sr. Member
  • *
  • Posts: 383
Research on 'Timing Attack' to Downgrade Kernel without CPU Key
« Reply #14 on: July 28, 2007, 06:59:00 AM »
QUOTE(ConteZero76 @ Jul 28 2007, 10:50 AM) View Post

If Flash is readed directly byte-wise something is possible.

No, it's a NAND flash, which is block-based. It's possible to make a small device out of an FPGA that listens for block requests and returns arbitrary data, but it's more complicated than for byte-addressed NOR.

QUOTE

Anyway I (as a moddable bios X360 owner) am still waiting for something useful to do with that.
Sure, I can try to run linux but nothing good will come until someone develop a modified firmware with no checks and a dashboard with "extended" features.
None of both is near to be seen, so you can downgrade just to run Linux and hope...

...and you're unable to go live or play games from C'n'C on...

Boot Linux, write down your CPU key, back up the NAND with a reader, and upgrade smile.gif It'll probably be quite a while before there's xbox1-style modding available; replacing the running 360 code with Linux is whole orders of magnitude easier than 'fixing' the 360 code to do more things without actually replacing it entirely.
Logged
Pages: [1] 2
« previous next »