why linux all the time? why not a 360 dash with unsigned code running?

[anita999]

why linux all the time? why not a 360 dash with unsigned code running?

well, maybe it sounds silly, but for me, there are matured programming tools for the 360 kernel made by MS such as XNA. one can certainly ultize the high level access to all 360 resources which will certainly speed up the homebrew code development.

based on this assumption, I am wondering that whether it's possible to boot a modified 360 dash which can run unsigned code and then we're back to old xbox1 times.

The way should be not so hard.
1. to have a binary image of the newest 360 kernel and dash code.
2. to allocate the code which verified the signature and modify it to allow unsigned code to run.
3. boot 360 to linux kernel, load the modified dash board binary to ram, then pass control to the code we load.

well, I know that the linux will certainly be clean and legal, and more pro users like it.
but for a end user like me, or a not-so-pro programmers, a platform like XNA might be much easier to develop a homebrew code.

I am really eager to see a XBMC on 360. and MAMEX, and other fun homebrew applications.

btw, a modified dash might certainly block any possible attack from MS via internet update since we now have full control of the dash and kernel.

well, any comments?

[Surrido]

well, because modifying the dashboard makes it illegal again... it would be nice to have a legal dashboard...

[anita999]

Sure I know the legal issue, but that's what we're used to in xbox1 case.
Being a end user, I don't care about that. All I want is a simple way to have some powerful homebrew code.
Though linux could be powerful, too. But it will certainly take a longer time for the scene to develop a mature platform for 360 specific programming.

[gigabite]

quote from you "Being a end user, I don't care about that."

quote from someone such as robinsod, or tmbinc or TS...or any other hacker "Being the creator, we face legal action" etc etc...u get my point...plus it's not as simple as you think, hypervisour, kernal verisons, CPU keys, eFUSES, 1BL

gigabite

[robinsod]

Shutup Giggles, you have no idea what you are talking about (as usual). Anita worked with us on the original firmware hack and is well aware of the issues and dificulties.

The problem we face is how to launch a patched HV/Kernel, the actual patched firmware could be created by the end user armed with a .ppf (or anonymously uploaded to xbins).

The principle reason for not releasing something (like a DVD firmware hack) is if it purely enables piracy rather than research/homebrew.

[anita999]

Hey, Robinsod, thanks a lot for your info sharing.

quote from your msg:
"The problem we face is how to launch a patched HV/Kernel"

So what's blocking us from launching a patched HV/Kernel?
I am really not familiar with PPC structure, but couldn't we simply load the binary to the RAM in the addressing space where it should be then branch to to it just like what we can do in PC?

[robinsod]

We have 2 problems:

1) How to execute unsigned code? We could use the KK sploit but it's inconvenient. Unfortunately its the only exploit found to date

2) How to modify/launch the HV/Kernel? If we do use the KK sploit we have to get the system into a state where this will run. I haven't looked in detail to see what is required.

I suspect if we can interrupt the boot process at the point where it is about to load and execute the stock HV/Kernel anyway we will have a much easier time. In fact if we can hack the box to ignore the signatures on CB-CG we could probably patch and repack the HV/Kernel (the base version is in CE and patched using data in CG) and let the existing system firmware do all the work for us.

[arnezami]

Hi guys,

Since this is now being discussed...

For the last 4-5 weeks I have been working very hard to reboot the xbox into an unsigned kernel/hv. And I've been making quite some progress.

I am now capable (using the KK exploit as starting point) to reboot from the moment the CB section starts the CD section up to POST 0x6C (!) in the boot process. Meaning that all three cores are running in an unsigned kernel/hv at that point.

What I'm doing is loading the CD section back into memory (where it would normally be during boot) and restart it. This CD section is changed to contain a kernel/hv patcher (which I now use to debug the kernel startup). So in fact I can already change the kernel/hv at will .

The difficulty has been (and still is) to restore the xbox into a state it was during boot. Most of the cpu/mmu related stuff have been restored now and thats why it already goes that deeply into the boot process. But some problems still remain (possibly interrupt/southbridge related). I'm still working on those. I'm also thinking of modifying what I've created into a more replicatable and managable form so others can take a look at some of these issues too (to speed up the progress).

Anyway. If we are successful in re-booting into a (patched) kernel it should also be possible to re-boot into any kernel (including the new ones). If we can do that we can (for example) avoid the whole fuse-burning dilemma (essentially by faking it). For that we would probably also need a second NAND (or some other storage device like a memory card) to store the new kernel/dash/kv/settings etc but thats something to discuss later on.

Back to work...

Regards,

arnezami

[anita999]

thanks a lot for your description.
of course it will be much easier to boot into a moded dash/kernel directly. but before that, the K.K. exploit will be a must have..
as for the HV/kernel patch during boot up process, I thought the hackers here already make it clear... seems I made a mistake..
I tried to collect the detail flows of the boot up process, but the data seems to be scattered around. any good way to have a integrated
document/info to understand it in further detail?

[arnezami]

thanks a lot for your description.
of course it will be much easier to boot into a moded dash/kernel directly. but before that, the K.K. exploit will be a must have..
as for the HV/kernel patch during boot up process, I thought the hackers here already make it clear... seems I made a mistake..
I tried to collect the detail flows of the boot up process, but the data seems to be scattered around. any good way to have a integrated
document/info to understand it in further detail?

Just a summary (out of the top of my head so might not be entirely accurate):

The cpu begins running the 1BL. All cores go from real mode into translated mode (instruction only). All cores but one are catched into a loop. The other one does the whole boot process. The encrypted CB section is decrypted and read into mem/cache. Its (RSA!) signature is checked and its HMAC pairing data aswell. If all is ok it jumps to the CB section.

At the beginning of the CB section the second part of the CB section is loaded into a different part of memory. Also the code the other cores will later on jump to (containing a jump into the hv) is loaded into mem. Then it jumps to the second part of CB. After doing some setup it decrypts and loads the CD section into memory. It checks the SHA1 hash (contained in the RSA signed part of CB) and if correct jumps to CD (mtlr/blr jump, not rfid).

In the CD section translation for data access is turned on (no real mode addressing data anymore). It then decrypts and reads the CE section into memory and checks another SHA1 hash. If correct it decompresses the CE into the memory location the hv starts. Keep in mind this is done in data-translated mode (so starting at effective address 00000000). Basicly kernel/hv 1888 is now loaded into memory. It then loads and decrypts one of the CF sections. Checks the RSA signture and paring data (HMAC) and if all is ok runs the CF section.

The CF section checks if its corresponding CG section (which contains patch data) is correct by another SHA hash. If correct CF decompresses the CG patches into the kernel/hv. It then returns to CD. In the CD section there is a rfid-jump to the entry point of the hv (also changing into real  addressing mode again).

In the hv (hypervisor real mode) lots of mmu stuff is being set and after that there is a jump to the kernel (again translated mode, lots of 800xxxxx adresses in there). In the kernel systems calls are used to get in and out of the hypervisor. One of the first things it does is re-awake the other cores who will also jump into the hv first. And of course the whole xbox is configured during the rest of the kernel bootup.

Thats pretty much how the xbox booting process looks like.

Hope that clarifies your picture a bit.

Regards,

arnezami

[atiman]

Wow... Thanks for your nice work arnezami, you have our support!

[arnezami]

Small correction: CB pairing data check (HMAC) is done at the beginning of CB not in 1BL.

[anita999]

woh, that's impressing, arnezami. great job.
really appreciate for your great work and also the info sharing. I have a much cleark overall picture, now...
I am really wondering that is there any other place we can implement the timing attack to break the trust chain?
If we can find another break point, then we can break the chain and then it shall be much easier since we can boot into our kernel directly.
In the mean time, you're doing the right thing by using a known exploit to experiment the possible kernel modification and to understand the detail boot process. this is really a tough job. I admire your hard work.

ps. you're the one developed the backBDAV in doom9, right?
     seems we are interested in the same things(maybe the most hackers). are you in asia?(because I am in asia, and the BDAV is most popular in one asia country, you know).

[anita999]

Hi, arnezami, few more questions since I am trying to put these thing together with the timing attack(again, you're the one raised up the idea, great job).

1. in the timing attack for downgrade, what's the actual thing we're changing besides the signature we're brute forcing? and which section does it belong? in the timing attack thread I saw "counter in both CB and CF sections are modified", is that true? if it's true, then how come one can modify the CB and skip the RSA part?

2. I tried to read RSA expressions from wiki, regarding to the signing part. But it's kind of chaso. let's take CB as a example.

my understanding is that MS hashed the CB to come out a hash value, then use the private key to encrypt the hash value.
and the code itself (I am not sure it's in 1BL or CB) calculates the hash, compares with the encrypted hash came from MS.
is my understanding correst?

3. How is the HMAC (paring) check applied on CB?

[arnezami]

woh, that's impressing, arnezami. great job.
really appreciate for your great work and also the info sharing. I have a much cleark overall picture, now...
I am really wondering that is there any other place we can implement the timing attack to break the trust chain?

I've looked at it but from a cryptographical point of view its rock solid. MS have done their job very well. Only possible way is a code implementation exploit or something like a hardware glitcher.

If we can find another break point, then we can break the chain and then it shall be much easier since we can boot into our kernel directly.
In the mean time, you're doing the right thing by using a known exploit to experiment the possible kernel modification and to understand the detail boot process. this is really a tough job. I admire your hard work.

Sure finding a breakpoint during boot is very desired. But I've been looking at the bootcode and my guesstimate is that if there is one it will take 1-2 years for anyone to find it and work out the details to make it reliable. And even if found it would probably require a hardware mod. Hope to be wrong though.

I think we have to prepare ourselves we're not going to find a better exploit any time soon. The KK exploit is a bit clumsy but its not too bad. If we would be able to re-boot into a unsigned kernel we could maybe create a "sleep mode" (possibly also changing the SMC code to prevent a hardware reset?) so the next time we "turn it on" it comes back directly into a unsigned kernel.

Regards,

arnezami

[arnezami]

Hi, arnezami, few more questions since I am trying to put these thing together with the timing attack(again, you're the one raised up the idea, great job).

1. in the timing attack for downgrade, what's the actual thing we're changing besides the signature we're brute forcing? and which section does it belong? in the timing attack thread I saw "counter in both CB and CF sections are modified", is that true? if it's true, then how come one can modify the CB and skip the RSA part?

2. I tried to read RSA expressions from wiki, regarding to the signing part. But it's kind of chaso. let's take CB as a example.

my understanding is that MS hashed the CB to come out a hash value, then use the private key to encrypt the hash value.
and the code itself (I am not sure it's in 1BL or CB) calculates the hash, compares with the encrypted hash came from MS.
is my understanding correst?

3. How is the HMAC (paring) check applied on CB?

I guess we are mixing up terminology

There are 3 kinds of verification used during boot:

- RSA signatures. CB and CF are RSA signed. No way to break this (MS has private key) basicly because it uses assymetric crypto. This prevents us from changing the boot code itself.
- SHA1 hash: CD, CE, CG. These hashes are contained in the RSA signed part of the previous sections and we can therefore not break it (also not time attackable). These can essentially be seen as extentions of the RSA signatures in CB and CF. Again preventing us from modyfing the boot code itself.
- SHA1-HMAC authentication. This is done in CB and CF too (but your CPU has the key). This prevents you to choose between released versions of the boot sections/dash etc. However this was time attackable.

Apart from that everything is encrypted (but this is trivial since we have the 1BL key). The kv is encrypted using the cpu key and this plays another vital role in the whole crypto system being secure. Eg. people who have lost their DVD key are screwed.

And then there are the fuses. They can make sure a CB/CF auth (HMAC) value is only valid if certain fuses are blown (or better: not blown) requiring the cpu key to downgrade. And they can even make sure old CB sections (and consequently the old exploitable CF sections) will never work anymore on a system when certain fuses are blown. This is the nasty one. Probably to be introduced in the fall update in its full glory. But we could get out of this "slavery" if we can reboot into an(y) unsigned kernel faking the fuse blowing.

Keep in mind that RSA sign uses a hash too (also SHA1 btw) and "expands" it (using some RC4) to the size of the signature. But the main idea behind RSA signatures is that you cannot recreate them because MS has the private key. And the public key is hardcoded into ROM. Thats why hard-resets are useless and we need to soft-reboot.

Regards,

arnezami

[edit] If you want to know exactly how the decryption/decompression works look at tmbinc's code here (romextract). Keep in mind he uses 1BL, 2BL, 4BL etc instead of 1BL, CB, CD etc.

[anita999]

well, what can I say. you're the one.
And finally being a rookie like me can have a much better understanding.
millions of thanks.

[tmbinc]

Oh, and additionally,  there is the Build #1920 bootloader system:

It uses the "2BL revocation mechanism" (fuse[2] lockdown). It predates the timing attack, so it doesn't work around that, but gives a nice overview about what's coming:

Essentially, the 4BL key, which is currently derived by a hmac of the (decrypted) 2BL key and the 4BL key data (see romextract for details) will be derived from the cpu key as an additional element - an element which we don't know on those boxes. That means that we can currently not decrypt the 4BL (and up) on these systems. Because it's "2bl lockdown value" is set to "4" (instead of, erm "2"?, as it was before), those systems won't run an older 2BL. It has neither been proven possible nor proven impossible to timing attack those systems to boot into 1888 (or 4532), and we don't know the exact mechanism in 4BL. If it hasn't changed, it would be possible (as the 2BL hash is attackable, which has been proven), but we don't know.

So far, the 1920 is only applied to new systems, and that's "good" (for MS), because otherwise we could decrypt it (by applying it on a box with known cpu key, for example).

Given that MS has already implemented a timing-attack-fixed memcmp() in the HV, i guess the bootloader will be next.

Did anyone yet checked one of the assumed "falcon" boards yet?

[arnezami]

Oh, and additionally,  there is the Build #1920 bootloader system:

It uses the "2BL revocation mechanism" (fuse[2] lockdown). It predates the timing attack, so it doesn't work around that, but gives a nice overview about what's coming:

Essentially, the 4BL key, which is currently derived by a hmac of the (decrypted) 2BL key and the 4BL key data (see romextract for details) will be derived from the cpu key as an additional element - an element which we don't know on those boxes. That means that we can currently not decrypt the 4BL (and up) on these systems. Because it's "2bl lockdown value" is set to "4" (instead of, erm "2"?, as it was before), those systems won't run an older 2BL. It has neither been proven possible nor proven impossible to timing attack those systems to boot into 1888 (or 4532), and we don't know the exact mechanism in 4BL. If it hasn't changed, it would be possible (as the 2BL hash is attackable, which has been proven), but we don't know.

So far, the 1920 is only applied to new systems, and that's "good" (for MS), because otherwise we could decrypt it (by applying it on a box with known cpu key, for example).

Given that MS has already implemented a timing-attack-fixed memcmp() in the HV, i guess the bootloader will be next.

Did anyone yet checked one of the assumed "falcon" boards yet?

This is interesting. I thought that 1920 was also put in repaired boxes. But if they can only be seen in new machines that would be really interesting because it could mean they can't blow fuses row 2 in all currently sold xbox-es. (and that would be great news ). In other words: maybe row 2 can only be blown once when the xbox is first initialized.

Can we somehow find out if certain rows can or can't be blown? Eg. can the cpu key fuses be blown? Can we detect a difference when trying to blow some of the fuses ourselves (with R6T3 removed for example).

If they can't blow fuses row 2 then that could also explain why they only patched the hv memcmp and not the one in CB and CF (since a CB "fix" without fuse row 2 blown wouldn't make a dent: 1888 is still installable). As in "why waste time trying to superficially fix something since we won't fool XBH with that anyway".

Regards,

arnezami

[tmbinc]

I'm pretty sure they won't waste time with things that don't help in the end At least not yet. They still have very powerful weapons, so they don't need to play for time.

I'm not sure about 1920 in *repaired* vs. *new* machines. I thought that they swap the mainboard completely (and probably refurbish the old one seperately). I'm not sure.

I can't see a reason why they can't blow any other fuses. The HV code in question seems to be used to blow all kinds of fuses, and doesn't make difference.

They haven't yet done a 2BL update at all. I believe the only reason why they haven't updated it yet is that they need to test that code *very* carefully.