Serious Ideas on exploiting 4532 without KK

[tmbinc]

Sorry for not answering before.

First of, a BIG thanks to SeventhSon for figuring out the "JTAG test disable registers". I'll second your opinion that the 0xe002000x-writes are to blame. Like you, I couldn't find a way to prevent settings those bits. Also a big thanks to your discovery that CPU will stay alive if we are fast enough.

basically, this will dump the flash via the GPU jtag. You could also write to the flash, if you really want.

Are you sure about this? I couldn't get NAND writes via GPU JTAG to work. What's more I was unable to generate memory mapped or config space write cycles to any device except the host bridge and GPU. Read cycles work fine to all devices, write cycles have no effect. I was unable to work out why.

Sorry, I was drawing conclusions too quickly. You are right, writing to the external bus doesn't work with the code I've posted.

External PCIe-writes use the 4 upper bits of the 0xE0-register as a writemask, as I just found out. So just set them to 0xF, and writes to the external bus start working.

To test this, the code sequence

Code:

void write32(unsigned long addr, unsigned long data)
{
  jtag36(0xe0, 3 | addr | (0xFULL << 32), 0);
  jtag32(0xe1, data);
  jtagn(0xe4, 1, 1);
}

  while (!(read32(0xea001084) & 4));
  write32(0xea001084, 0x4);
  write32(0xea001080, 0xff0199);
  write32(0xea001084, 0);

will set all the frontpanel leds to orange.

[SeventhSon]

Sweeeet. And not just because we can now have orange lights

Nice work as always. Thanks for posting.

[SeventhSon]

Works nicely

To make it work during our window of opportunity at boot (so we don't take out the CPU) requires us to do some very minor config of the PCI-PCI bridge and the target device before we can write the target regs. We have to do all this after power on but before POST 0x2E (which gives us ages ) I used POST 0x1B as the trigger again, for no particular reason.

Code:

//detect start of POST sequence to avoid false triggers by noise
while(inb(PP_DATA) != 0x10);
while(inb(PP_DATA) != 0x11);
while(inb(PP_DATA) != 0x12);

// wait for trigger
while(inb(PP_DATA) != 0x1B);

jtag_reset(); // Test-Logic-Reset

// use JTAG to map/enable required PCIe devices
/***************************************************************/
// PCI - PCI bridge
printf("\n");
printf("writing PCI-PCI bridge busses: ");
if(pcie_write32(0x00010100, 0xD0000018)) // set up bus numbers
printf("err\n");
if(pcie_read32(&data32, 0xD0000018))
printf("err\n");
printf("0x%08X\n", data32);


// Dev 0x0A
printf("\n");
printf("writing Dev 0x0A BAR_10: ");
if(pcie_write32(0xEA001000, 0xD0150010)) // map target dev
printf("err\n");
if(pcie_read32(&data32, 0xD0150010))
printf("err\n");
printf("0x%08X\n", data32);

printf("writing Dev 0x0A cmd/stat: ");
if(pcie_write32(0x00000002, 0xD0150004)) // enable target dev
printf("err\n");
if(pcie_read32(&data32, 0xD0150004))
printf("err\n");
printf("0x%08X\n", data32);


/***************************************************************/


// orange!
do {
pcie_read32(&data32, 0xEA001084);
}
while(!data32 & 4);
pcie_write32(0x00000004, 0xEA001084);
pcie_write32(0x00FF0199, 0xEA001080);
pcie_write32(0x00000000, 0xEA001084);

jtag_reset(); // Test-Logic-Reset (this releases the PCIe bus and allows 360 to boot)

all functions the same as before except that pcie_write32() now has the write mask discovered by tmbinc.

360 boots fine but with a nice orange front panel. Next target = DMA regs. Weeee.

[Shaun]

interesting stuff out of interest. how are you applying that code ? via a pic or similar or pc app ?  I also assume your monitoring post as thats something im trying to sort at present.

[SeventhSon]

interesting stuff out of interest. how are you applying that code ? via a pic or similar or pc app ?  I also assume your monitoring post as thats something im trying to sort at present.

I use a linux app. Yep, monitoring POST

It would be best in a uC or FPGA, but definitely easier to work with PC software.

[tmbinc]

read32 also requires the read mask, otherwise the most interesting peripheral doesn't work.

On the SMC side, I propose cmd 04 to do the trigger the dma read command. That's just before the flash controller init which would otherwise trash the dma address. We also need to defeat the "bitshifting checksum" unless we want to recalc the pairing data (which would require cpu key).

[SeventhSon]

read32 also requires the read mask, otherwise the most interesting peripheral doesn't work.

On the SMC side, I propose cmd 04 to do the trigger the dma read command. That's just before the flash controller init which would otherwise trash the dma address

Thanks again

We also need to defeat the "bitshifting checksum" unless we want to recalc the pairing data (which would require cpu key).

It's enough to just switch between 2 NANDs for now though, right? Or maybe I'll just recalc my pairing data for the time being. But I agree, we need to defeat that ideally.

[jz_5_3]

very interesting.

may I know what specific jtag cable is used here? can I use a xilinx parallel jtag cable?

by the way, what  jtag open source jtag code/library is used to compiled the code?

[SeventhSon]

may I know what specific jtag cable is used here? can I use a xilinx parallel jtag cable?

by the way, what  jtag open source jtag code/library is used to compiled the code?

I don't know about tmbinc, but my cable and JTAG lib code are both custom. Fortunately the JTAG spec is pretty simple to implement.

[XeNoN.7]

Nice on the LED color changing. I'm gonna need to give that a spin..

[mushy408]

In your dreams...

Do you even understand what this involves?

[XeNoN.7]

In your dreams...

No.

Do you even understand what this involves?

Yes. I'm not a dumbass. And also nowhere did I state I want to do this with a retail. I said I need to give the LED color changing a spin.. As in I'm going to look into changing it on one of my development consoles..

If I remember correctly you could mess with the RF module using HalSendSMCMessage. Though I didn't want to say I'm going to do it on a development console because it derails the topic which isn't about doing this on development consoles..

[braza]

Hello for all !

I have this JTAG debug:

http://www.diygadget.com/store/jtag-test-tool/wiggler-buffered-all-in-one-jtag-programmer-version-2/prod_33.html

The question is how to inject the CODES on motheboard ?

[.ISO]

First of all, you are not being specfic. For example, what kind of code are you trying to inject, to where, through which port/bus, and most importantly, what are exactly are you trying to accomplish?
Second, I can guarentee that the JTAG programmer you have will NOT work.
Third, it's not really possible to inject code hardware-wise to the Xbox 360 yet

[Redline99]

Any further off topic chatter will be removed.  If you want to continue then start a q. and a. thread in a "general" section.

[tmbinc]

So, some quick news:

We kept on working on this idea, and it worked out. pretty well. We use JTAG to program the DMA target addr, and then SMC to trigger the DMA read. The exploit itself is based on the old 4532 exploit.

The magic is how we launch 4532 - there is a "backdoor" for manufacturing since CB 1920. We have been able to restore the newer CD versions for all hardware types.

This means:
 - We can boot own code in HV context ~5s after boot, before any video output, right after the kernel runs.
 - we need to reflash the flash, and add 3 resistors for the JTAG (no modchip required! but you might want a dual-nand modchip),
 - 8498 kills this by updating the bootloader - it blacklists 4532/4548. it also does hw init stuff which might interefere with the jtag hack, we don't know yet.
 - we have a proof of concept hack, we will release it SOON (a matter of hours/days, not more - promised.).
 - DON'T UPDATE to summer 09. Did i already say this?
 - you don't need to know your cpu key. You can update to all BUT summer '09. you don't need a dvdrom.
 - It works on all xenon, zephyr, falcon, opus, jasper. Unless you have updated to 849x. Then you're screwed.

[jelle2503]

great news man. good work. especially since everyone thought 360 scene was dead, now the bomb drops even bigger. i thought it never happened, and while reading the news i nearly fainted of happyness

. sad about the new update though, i'm so lucky i did not connect to live yet

hope to see more from your great work =) great man!

[Redline99]

This is a warning, keep all non tech questions comments out of this thread. This is great news but lets keep this thread short and sweet and not grow to 50 pages.  If you don't have anything to contribute then use a different thread.

Thank you.

I'll start a new thread just to head this off.
General Discussion here
http://www.xboxhacker.net/index.php?topic=12178.0

Tech Information can continue in this thread

[tmbinc]

So, some more details:

CB1920 and up allow to boot into any kernel version, including 4532, but only in "mfgbootlauncher" mode, which is used in manufacturing. This mode (also called "zero pairing", because you need to zero out the CB pairing data) has been known before, however, previous to CD1920, it was useless, because you could only boot into 1888, not into 4532. It was *also* useless because you couldn't run a game.

Now, we developed a way that uses JTAG+SMC to write into physical memory at any time. I think the idea came even from this thread. Basically a flash sector will be prepared to contain the exploit buffer and the code we want to run. JTAG will be used to program the DMA target address (the only thing you can't do from SMC), and SMC will be used to kick off the read (remember, SMC code can access the nand controller as well - just not the dma addr.).

SMC will be patched so that it kick off the DMA read right when the kernel is loaded. We are using the "read rtc" command for that, which happens pretty early in the kernel, way before GPU init, for example. It also happens before nand controller init, which is important, as that would overwrite the dma addr again.

Basically everything required to assemble this hack was present in this thread already since some months .

[XeNoN.7]

If an exploit were to kick off.. Would you be able to boot into a newer kernel if hacked up a bit? Because if you were on an older one, and a new game came out, it'd say you need to update your dash.