any chance unsigned code will be playable on stock modded/hacked 360?

I think that would be pretty neat. How about a quad-boot, like the Sega CD MultiBIOS Arakon did, with a NAND flash for each of the PAL, NTSC-U and NTSC-J regions, as well as from a debug NAND (if the idea above is feasible). All encrypted with the retails per-box CPU key of course. Then one could run retail discs from all regions as well as dev discs simply by flicking a switch?

As long as you have a 360 with a vulnerable kernel to begin with, you can get your CPU key, right?

CF

 

.
The answer to the question is No. dev and retail use different nand chips 256 retail compared to 512 for dev.

 

Since the NAND chip is bigger in the dev (I thought is was 128Mbit in a retail btw? 16MByte...?) it would be a little harder.

But can't you just replace the onboard NAND with a bigger one, or piggy-back a bigger chip on the onboard NAND (like with a dual-boot solution tmbinc was taking about).

CF

 

Sorry your right on retail my bad 128 it is the hynix chip hy27uso8281a. debug is 512 (k9f1208u0b Samsung chip). If you are good at soldering you can replace it but you still have the first 1bl loading out of the cpu and it hold values on where to load the 2bl from.

 

Are you saying that the 1BL (in the ROM inside the CPU) in a dev unit is different from the 1BL in a retail?

Does the 1BL in dev units load the 2BL from a offset different from 0x8000 (in NAND)? Or did MS use a different private key for signing the 2BL/CB for dev units?

 

From what I have read they use encrytion in the cpu so it is not just a straight change

 

I am not sure I understand what you mean... The 1BL in the CPU ROM loads the 2BL in the NAND flash, checks it's signature and executes it, right? So, if the 2BL is signed by the same key and at the same location in the NAND, then what is the problem?

I would like to stress that I am not saying that this is how it works, it is only my personal understanding so far... I might be wrong.

 

You are close all my information is from reading from a number of places.

If I am correct The way I understand it is the 1BL loads the 2BL but the signiture in the 1bl must match that in 2bl. If you can modify the 2BL to have the signiture from 1bl or modify signiture in 1bl to match that in 2bl than it should work. Reading fram various boards it would seem that is getting close so teh biggest hurdle would be unsoldering and soldering in a nand chip. If you have any ideas I would like to hear them. My soldering skills are lacking.

 

Well, what I meant in my first post in this thread was the following steps. Thanks for the info about the bigger NAND in the devs

As you know, 2BL is stored in the CB section of the NAND flash... Here goes..


STEP A

1. Get a 360 retail unit with a vulnerable hypervisor.
2. Exploit the vulnerablitiy to run code.
3. Dump the fuseset.
4. Read the retail's "per box" CPU key from the fuseset dump.

Result: The CPU key for a retail Xbox 360.


Step B

1. Get a 360 dev unit (or debugger) with a vulnerable hypervisor.
2. Exploit the vulnerablitiy to run code.
3. Dump the fuseset, 1BL and NAND memory areas.
4. Read the fixed 1BL key from the 1BL dump.
5. Read the dev's "per box" CPU key from the fuseset dump.
6. Use the 1BL key to decrypt CB, CD, CE, CF and CG sections of the NAND dump. These are encrypted using RC4 and some of the keys are generated with HMAC SHA-1. The CE section is also compressed with the Microsoft LZX algorithm. Everything is documented pretty well.
7. Use the dev's "per box" CPU key to decrypt the keyvault.

Result: A dump of the dev's NAND, with the CB, CD, CE, CF, CG and keyvault sections decrypted.


STEP C

1. Patch the pairing data in the dev's CB section with pairing data matching the retail's CPU key
2. Patch the pairing data in the dev's CF section with pairing data matching the retail's CPU key
3. Patch the hash of the dev's KV section with a hash matching the retail's CPU key
4. Re-encrypt the keyvault with the retail's CPU key.
5. Re-encrypt CB, CD, CE, CF and CG using the fixed 1BL key and the HMAC SHA-1 generated keys (compress CE).

Result: The NAND dump is now encrypted properly to match the retails CPU key. The CB and CF sections are signed with RSA (actually it is a hash of the section that is signed). Patching CB and CF will not break their RSA signature as the part of the sections that are signed starts right after the pairing data.

STEP D

1. Flash the hacked dev NAND dump onto a 512Mbit compatible chip.
2. Replace the 128Mbit NAND in the retail with the new chip with the hacked dev NAND data.


POWER ON

1. Control is passed to 1BL.
2. 1BL decrypts CB (2BL) using the fixed 1BL key (same in every system).
3. 1BL verifies CB's RSA signature (the signed hash in CB).
4. Since Microsoft signed the dev's CB section with the same RSA private key, the check pass.
5. 1BL pass control to 2BL.
6. 2BL checks if the pairing data match the retail's CPU key. It does.
7. And so on...

There might be checks I have forgotten..... And if you don't have the right to backup the NAND in the dev, you know what that means....

Again I would like to stress that I am not saying that this is how it works, it is only my personal understanding so far...

CF

 

It's been more than a year since this thread has seen any movement. Have you experimented anymore along this line CF?

-hl718

 

oh, and except that SB will check fuses to differ between dev and retail at the beginning
plan result: EPIC FAIL

 

Bummer, since the real damage comes from piracy, not homebrew (which brought us cool stuff like XBMC)