Timing attack - stupid questions thread.

[arnezami]

alright, got my 1BL, fuseset and the nand flash dump (thanks arnezami!)
trying region change now! laters

Keep in mind you need the edc bytes in order to do any on-the-fly patching or re-flashing your nand.

[Protonus]

Yay for a stupid questions thread! now I can ask a few :-D  I realize these are noob questions, but I've been unable to clearly determine their answers in reading as much as i can here...

1.  With a downgraded kernel,  you are effectivly removing the patches applied by xbox live when it updates correct?  As such with a downgraded kernel, live play would no longer work correct?

2.  There are ways to run multiple kernels now though, correct? In a nutshell what is required to do that, and how to you switch between them? If you had a new kernel and an exploitable kernel, could you play on live then with the new kernel and switch to the old kernel when you want to run 3rd party apps?in   Would this be similar in end result to switching a mod chip on/off to play on Live, with an xbox1?

3.  Those of us who have been playing on live have up to date 360's, and as I understand it, later updates blow e-fuses that prevent downgrading?  If that is the case, this downgrade plan would only work if you're running a certain version of the kernel or earlier?  Or would this work for anyone?

4.  With a downgraded kernel, via exploits unsigned code can be run now correct?  What currently prevents us from porting an app like XBMC to run with a downgraded kernel? 

[jas0nuk]

Yay for a stupid questions thread! now I can ask a few :-D  I realize these are noob questions, but I've been unable to clearly determine their answers in reading as much as i can here...

1.  With a downgraded kernel,  you are effectivly removing the patches applied by xbox live when it updates correct?  As such with a downgraded kernel, live play would no longer work correct?

2.  There are ways to run multiple kernels now though, correct? In a nutshell what is required to do that, and how to you switch between them? If you had a new kernel and an exploitable kernel, could you play on live then with the new kernel and switch to the old kernel when you want to run 3rd party apps?in   Would this be similar in end result to switching a mod chip on/off to play on Live, with an xbox1?

3.  Those of us who have been playing on live have up to date 360's, and as I understand it, later updates blow e-fuses that prevent downgrading?  If that is the case, this downgrade plan would only work if you're running a certain version of the kernel or earlier?  Or would this work for anyone?

4.  With a downgraded kernel, via exploits unsigned code can be run now correct?  What currently prevents us from porting an app like XBMC to run with a downgraded kernel? 

1) The Xbox is unable to connect to Xbox Live if you are not running the latest kernel (which is 5761 or something as of the latest update)
2) Yes, you could use an xD card mod to switch between kernels
3) If you have the CPU key you can downgrade a NAND image without worrying about the fuses. You must extract the CPU key on kernel 4532/4548
4) At the moment, yes, Linux is working via the old kernel, and AFAIK XBMC is being ported to Linux for this exploit.

[arnezami]

I will give it a shot .

1.  With a downgraded kernel,  you are effectivly removing the patches applied by xbox live when it updates correct?  As such with a downgraded kernel, live play would no longer work correct?

Correct. Your xbox simply doesn't know about any newer versions when its downgraded. It will act as if it was shipped with the older version (and therefore live won't work). 

2.  There are ways to run multiple kernels now though, correct? In a nutshell what is required to do that, and how to you switch between them? If you had a new kernel and an exploitable kernel, could you play on live then with the new kernel and switch to the old kernel when you want to run 3rd party apps?in   Would this be similar in end result to switching a mod chip on/off to play on Live, with an xbox1?

Right now there is a way to use an xD memory card and use it as a second/third etc firmware. In the technical section there is a thread about this. Anyway I suspect that when demand gets higher relatively easy to install mods will appear on the market to do this. Switching between a "live fw" and a "linux fw" should be possible (or in fact it already is).

3.  Those of us who have been playing on live have up to date 360's, and as I understand it, later updates blow e-fuses that prevent downgrading?  If that is the case, this downgrade plan would only work if you're running a certain version of the kernel or earlier?  Or would this work for anyone?

This is a really good question. I will try to explain the idea behind the fuses first.

When a fuse is burned due to an upgrade an old fw dump won't work anymore. This in fact seems to be the idea behind the fuses: to make it impossible to simply backup your old nand contents (eg just before upgrading) and then -after the upgrade- simply flash the nand with the backup. That won't work: the old fw contains a fuses count which is signed by the cpu key and if more fuses are burned than this signed count (because of an upgrade) then the backup won't work anymore. And you cannot change this count in the backup without the cpu key (well.. we can now of course).

But it looks like xbox-es can run old kernels even if many fuses are burned (or even all of them). Robinsod tested this by downgrading a box with 4 fuses burned. The trick is to sign it with the cpu key (or more precise: create a signature). But since you can't extract your cpu key running a new kernel version you get a chicken and egg problem. So in this sense they (=MS) probably thought they had everything covered...

However because of the timing attack (which allows us to create a new fuses-count-signature) every xbox on this planet can now downgrade. What you need is a complete firmware dump (of either your own box or of another) and make it work by creating a signature for it. However you also need some parts from your own (upgraded) fw. Don't want to give MS too many good ideas, but instead of needing a cpu key (+ dumped fw) to be able to downgrade I believe the essential requirement now to downgrade is only a firmware dump of your xbox flash (and any of the current fw versions will do).

In other words: if you want to be able to downgrade at some point in time I believe you will be able to do that if you dump your fw now. And when you have that dump it seems that MS can't prevent you from downgrading anymore (even if you upgrade many times before ever downgrading). That is: unless they built something into the old kernels we haven't seen yet (like not being able to cope with a crazy amount of burned fuses or something) that prevents the old fw's from running at all.

This is all based on my understanding of how the xbox is protected of course and on the assumption that the timing attack is going to be practical and fairly easy/cheap to perform.

4.  With a downgraded kernel, via exploits unsigned code can be run now correct?  What currently prevents us from porting an app like XBMC to run with a downgraded kernel? 

Essentially lots of research and hard work. But maybe more importantly: you need to start a game (KK) now to let your xbox run in "free" mode. Thats quite inconvenient. What is needed is another exploit but one that works during boot. However these kinds of exploits are very hard to find (if at all). But this downgrading attack would enable you to downgrade to to kernel version in which that exploit is found (otherwise that exploit wouldn't be much worth now since so little people would be able to benefit from it).

arnezami

PS. You need hardware for dumping your flash (like infectus chip) if you have an upgraded kernel (> 4548).

[Protonus]

<3 both of you guys that was a great explanation.  :-D Well I guess I'll be getting a chip shortly then to dump my current firmware before they figure out a way to prevent me from doing so! 

Sounds like we have a basis for a generation 1 modchip setup then for the 360, a device\software that allows for "plug and play" installation of the timing attack (assuming it becomes feasible), recover your key, backup your current kernel, downgrade your kernel, and then allow you to switch kernels off of a storage card, for booting mod kernel/stock kernel essentially for use on live.  I can see the future!   I can imagine this in a retail package from Xecuter!

I really really really really want XBMC on the 360 because of one huge limitation caused by the hardware of the Xbox1 - you cannot play HDTV / HD DVD rips/files AT HD resolutions with an xbox 1 due to a lack of processing power. So all my HDTV shows I have stored, I have to watch at 480p for the framerate to be high enough to consider "viewable".  With the 360s massive balls compared to the xbox1, I have to figure XBMC will be able to handle HD rips at HD res's, which will be so very awesome!

That and a good N64 emulator would be sweet.  I wonder if the 360 could handle a gamecube emulator too.

[lasonnette]

Team Xecuter? Dream on...
This is open source...

ANYHOW
It's working...but alas comes the bad news - it's unstable!
Right now I'm using the rising edge of WE to write into the Address latch, but tomorrow I'll try stabilizing it with the system clock...
After it's stable, I'd appreciate if someone could help me code the program itself (I can write the on-the-fly patch myself, but I don't know how to build that page...)

Night

[robinsod]

I have now finished building and testing a "proof of concept" downgrader hardware.

I'm using the Infectus chip (with a dll interface provided by them) to rewrite one NAND block with sequential hash guesses. The process takes approx 1 second. The Hynix data sheet quotes a 100,000 read write cycles, our worst case is 4096 or 4%. Since this is a one time operation I think 4% wear is acceptable

Some PIC processors have CCP modules that allow an internal 16 bit counter to be sampled when a +ve or -ve edge is detected, the counter is claimed to have a 50nS resolution although I'm not convinced Simple software in the PIC allows me to detect the end of CE and the POST port changing from 0x21 => 0xA4 (the end of hashing). The PIC also drives the JTAG reset line. A couple of cheap interface ICs and some passives complete the design - you will definitely be able to build your own hardware from easy to obtain parts, on stripboard, for around 20 Euros.     

Controlling all this is some PC software that can generate the required CB section patch, control the infectus and the PIC. It would seem that the "cycle" time should be less than 3 seconds. To test this I am using the 360 I "bricked" at christmas, I don't know the CPU key for this box so I cant "cheat" and test each correctly "guessed" hash byte (I dont want to do any more mods to my vulnerable box ). The good news is that I have "guessed" the first byte of the CB hash, the bad news is that there is a known bug in the infectus that prevents the 360 booting with USB cable connected, hopefully they will have a fix soon. So I have been  plugging/unplugging a USB cable all evening and the first byte was 0xC0 so you can imagine I'm quite looking forward to that fix    

Once I get the fix and finish testing I will post more info followed by a complete, open source package of hardware and software so you can build your own in a few hours. Now might be a good time to get that infectus chip

One final point, a lot of the people who want to downgrade will probably have recent versions of the applications (dash, media player etc etc). Some of the latest dashes definitely completely replaced the dash.xex (and possibly others) rather than write new xexp files. These newer versions of the applications definitely require newer system libs and I doubt they will boot on a 2.0.1888 machine. We will need to obtain an image of a clean 2.0.1888 file system. Are there any regional variations of files? It would certainly be useful if xbins where to start hosting FS image pack(s)....

[lasonnette]

robinsod you can connect the GND of x360 to GND of infectus and then you cut trace between the SB and NAND Flash and with your pic you can then control which one is accessing flash...

[Martin_sw]

But you will still need your own encrypted keyvault from the xbox right?

[arnezami]

I have now finished building and testing a "proof of concept" downgrader hardware.

Controlling all this is some PC software that can generate the required CB section patch, control the infectus and the PIC. It would seem that the "cycle" time should be less than 3 seconds. To test this I am using the 360 I "bricked" at christmas, I don't know the CPU key for this box so I cant "cheat" and test each correctly "guessed" hash byte (I dont want to do any more mods to my vulnerable box ). The good news is that I have "guessed" the first byte of the CB hash, ...

Believe me when I say: you really are the best.

I knew you were working on this too...

So I have been  plugging/unplugging a USB cable all evening and the first byte was 0xC0 so you can imagine I'm quite looking forward to that fix  

That is indeed funny 

Good job.

Regards,

arnezami

[Protonus]

the bad news is that there is a known bug in the infectus that prevents the 360 booting with USB cable connected, hopefully they will have a fix soon. So I have been  plugging/unplugging a USB cable all evening and the first byte was 0xC0 so you can imagine I'm quite looking forward to that fix  

incredible progress!! Is infectus trying to solve this problem? 

Is there anything any of us noobs can do to help?

[lasonnette]

team infectus is currently on holidays till september

[oranginasprite]

not yet...I have yet to confirm if my idea of on-the-fly patching works...
and I don't know how besides changing something in the keyvault (like region) to prove it works...

my problem now is that I can't access my usb stick or ipod...no root = no mount
anyone know the root password for the newest gentoo live cd?

There is no root password per se on a gentoo Live CD. You have to set it by typing sudo su - which will log you in root, so you will not even be forced to set a root password in fact.

[lasonnette]

yup, thanks for the late help, but I already figured that out got my cpu key and also already got the on-the-fly patch working...
now I need to know how to calculate the CB pairing data...

[Iriez]

These newer versions of the applications definitely require newer system libs and I doubt they will boot on a 2.0.1888 machine. We will need to obtain an image of a clean 2.0.1888 file system. Are there any regional variations of files? It would certainly be useful if xbins where to start hosting FS image pack(s)....

Anyone is free to PM me at any time with the requested images and I will be happy to host them on xbins.

I am very eager to get a hardware list to build this mod after it is refined.

I do however have a 'stupid question' for this 'stupid question' thread

arnezami quoted that this attack will only be essential in downgrading your kernel. However, isnt the entire point of this attack to gain the single thing that we have never gained before....the cpu key? And with this inital key (to my understanding, it is the first key in a line of encryption(s) ), can we not resign the essential parts of the HV, or anything else, with a modified bootloader? Perhaps modified serial stub? Or is it the fact that we are just guessing the HASH and not the key that stops this? I would figure once we guess the correct hash that we could brute force the hash to eventually get the un-encrypted key. (or is it some ridiculous 2048bit RSA key?)

I dont know why, but i always presumed that *this* was the open door into our fully-hackable 360.

[arnezami]

I do however have a 'stupid question' for this 'stupid question' thread

arnezami quoted that this attack will only be essential in downgrading your kernel. However, isnt the entire point of this attack to gain the single thing that we have never gained before....the cpu key? And with this inital key (to my understanding, it is the first key in a line of encryption(s) ), can we not resign the essential parts of the HV, or anything else, with a modified bootloader? Perhaps modified serial stub? Or is it the fact that we are just guessing the HASH and not the key that stops this? I would figure once we guess the correct hash that we could brute force the hash to eventually get the un-encrypted key. (or is it some ridiculous 2048bit RSA key?)

I dont know why, but i always presumed that *this* was the open door into our fully-hackable 360.

All executable code on the xbox is (one way or another) signed by a RSA key. MS has the private RSA key and thats why we will never be able to sign our own executable code. This is what prevents us from running anything different than what MS has build (like the kernel and bootloaders). This has nothing to do with the cpu key. The only thing we can do with the cpu key is choose which version of the kernel/bootloader we want to run. But we cannot make changes to any of these versions themselves.

Then why downgrade?

Because two kernel versions MS build (4532,4548) have a tiny flaw. And when we have our cpu key we can choose to run these (old) kernels and exploit them by running a patched KK game. After running the exploit we have complete control over the xbox (but not before that). This means to be able to run homebrew or linux we now have to start the game, press ok, insert a disc etc.

What we really want is to find a way to execute either the current (shader) exploit or a new exploit without the hassle of starting a KK game, pressing ok etc. Essentially an exploit (to get out of the "grips" of the hypervisor) during boot. If that is possible then we can more easely run our own software. And if such a new exploit is found we can use the downgrading attack to get our cpu key and the choose to run the kernel/bootloader version in which this exploit is found.

Just to clear up: the type of cryptography used for the signing of executable code (public/private RSA key pair) is completely different from the type used for signing the choice of the kernel/bootloader version with the cpu key (SHA1-HMAC). The timing attack "trick" can only be used on the the latter type. So we cannot adapt the technique to create our own signature for executabe code and (for example) run homebrew from boot. We would really need a real exploit for that.

In short: the execution of code is protected by a RSA private key. This was defeated by an exploit found in two old kernels. The choice of running an old kernel is protected by the fuses and cpu key. This is defeated by the timing attack. You need both.

Regards,

arnezami

PS. There is also encryption involved in the protection system of the xbox but that is now a far less significant problem since essentially a common key (1BL key) is used to encrypt "everything". Of course the encryption made it realy hard to find the first exploit. Thats also the reason for its use. But since the 1BL key is found it has little use now. Keep in mind encryption is something comletely different than signing.

[robinsod]

Just to be clear, the timing attack will allow you to downgrade to 2.0.1888. You can then upgrade to 4532 & run the KK sploit and obtain your CPU keys. You should be able to replace the original CB after the upgrade (this needs to be confirmed) and then the only "clue" to what happened is that you may have 1 or 2 more burned eFuses for the HV/Kernel version you are running

A short beta period might be a good idea (I make loads of mistakes ) so I'm looking for 2 or 3 people to join in the fun early (PM me). Ideally you will

1) Have good electronic engineering skills, you must be able to build and debug a simple stripboard project
1) Have an installed infectus and valid flash dumps
2) Have a PIC programmer that can program the PIC 16F876A
3) Be willing & able to buy a small number of parts (1*PIC16F876A, 2 * LM339 and 1 * SIPEX3232 plus a few passives)

[vax11780]

1.  With a downgraded kernel,  you are effectivly removing the patches applied by xbox live when it updates correct?  As such with a downgraded kernel, live play would no longer work correct?

2.  There are ways to run multiple kernels now though, correct? In a nutshell what is required to do that, and how to you switch between them? If you had a new kernel and an exploitable kernel, could you play on live then with the new kernel and switch to the old kernel when you want to run 3rd party apps?in   Would this be similar in end result to switching a mod chip on/off to play on Live, with an xbox1?

3.  Those of us who have been playing on live have up to date 360's, and as I understand it, later updates blow e-fuses that prevent downgrading?  If that is the case, this downgrade plan would only work if you're running a certain version of the kernel or earlier?  Or would this work for anyone?

4.  With a downgraded kernel, via exploits unsigned code can be run now correct?  What currently prevents us from porting an app like XBMC to run with a downgraded kernel? 

This should be obvious to all...

MS can and almost certainly is tracking what version your box was at when you connect to live.

If you manually downgrade your kernel (using ANY mechanism), then rely on Live to upgrade, MS will know you have modified your box and could ban you at any time.

Be sure to always restore the last kernel you downloaded from live (using your Infectus or equivalent) before connecting to live.

VAX

[Shaun]

yes it possible but i doubt its probable for a simple reason.
the whole point of having a 'backup' kernel is for a 'serious' fault in the data of the newer flash area and having an old backup.  altho booting a kernel / dash which is blocked via blown fuse update may ask further questions

[SeventhSon]

F*#king nice work Robinsod.

I'd offer to beta it for you but no infectus and a negative bank balance (damn las vegas )