Timing Attack

[ivc]

ill be working on board layouts and also improving the circuit!
stay tuned.
great work robinsod

The DB9 female connector pin 2 and 3 has to be switched (pin 2 to 14, pin 3 to 13). Geremia and myself had to swap the pins to get a working connection to the RS232 level shifter using a regular straight-through DTE-DCE cable (not a null-modem/cross cable).

http://www.camiresearch.com/Data_Com_Basics/RS232_standard.html#anchor1155222

ivc

[robinsod]

Ah, did I not mention the null modem cable? Oops, sorry

I dont think it should be too dificult to build the PIC interface, any experienced electronic hobbyist should be able to build one in a day. That was one of the aims of the design. But the Infectus add on will completely replace the PIC interface anyway. So if all this raw technology frightens you, just wait a while, a much friendlier version is being worked on. Real men with hairy chests should read on however....

Will it encourage homebrew? Well, there will be a lot more potential users out there so maybe it will be worth the development effort, who knows.

Today, the "Degraded" tool, this is what you need to build the 2.0.1888 image that you will eventually boot.

http://rapidshare.com/files/56725771/Degraded.exe.html 

You will also need the original file system contents. Unfortunately they are copyright MS so I can't post them here. I'm confident they will appear in the "usual places" shortly

If you get warnings about bad blocks in the range 0-1C or 3DE-3DF the image generated wont work, but I'd like to hear from you 

PLEASE READ THE DOC AT THE TOP OF THIS POST, IT SHOULD GIVE YOU ALL THE ANSWERS (except the bit about the serial cable, my bad)

[CoolkcaH]

It's a good suggestion but a bit OTT I think. The trouble is the resistor is a tiny little SMT device. Most people wont have 5 blown fuses, at least I dont think they will Also, you only need to go through this once.

You only need once if you only want to do homebrew, but if you only have one 360 other people in the house may want to play live and then you need to upgrade/downgrade often, blowing the fuses.
About being small, maybe replace it with a bigger equivalent.

[robinsod]

No, you only need to do it once. When you have your CPU key you can up & down grade at will without blowing another fuse

[RAID]

Great job Robinsod

please you can share the DGTool.exe in rapidshare?

Thanks Again

[jacksback]

Awesome progress Robinsod

I'm assuming that if we have a 1888.bin Infectus dump from another console we will need the CPU and XEX keys to decrypt it in Flashtool before using that File System in the degrade tool?

Thanks

 

[robinsod]

The files required to rebuild a 2.0.1888 image can be extracted from any dump of an early image. You don't need any keys to extract files using old versions of my tool (the newer releases decrypt the files and you don't want that.

I'm told that a set of files are now available in the “usual places” so if in any doubt get them from there.

Assuming nothing goes wrong today, DGTool will be available tomorrow. How many of you now have working hardware?

[rufusb]

i have working hardware
WINK WINK

[RAID]

Assuming nothing goes wrong today, DGTool will be available tomorrow. How many of you now have working hardware?

Ok. I already have the hardware mounted to the delay of the DGTool



Thanks again

[robinsod]

New toys....

http://rapidshare.com/files/57176203/DownTools.zip.html

360 Flash Tool 0.85

Added:
Patch CB LDV if CPU keys are known
Additional recognition string for new flash images

Bodged:
Disabled extraction of Kernel images when CD version is 1920 (extracting
files will cause a crash)


DGTool
First release.
To do:

Improve timing filters, still need to find the cause of the jitter. Byte 6 can of the hash seems problematic occasionally.
Improve logging

Degraded

Fixed:

Handling of bad blocks in Cx area Now you will see the bad blocks (and the replacements) listed as "notes". if you are very unlucky the block at 0x8400 (where the CB header is located) will be bad. In this case the tools will fail and the image is unusable today.

Handling of bad blocks in FS area (not 100% yet). Currently I test for bad blocks as I insert files into the flash image. If a bad block is detected it is simply skipped over. I had a look at a dump that contains bad blocks in the File System area and it appears the file system is unaware that some of the blocks it is using are marked as bad. I guess the flash driver silently does the remapping of bad blocks for the file system. I will fix this soon since it crashes the flash tool

Handling of replacement blocks at end of flash image

Now you will see the bad blocks (and the replacements) listed as "notes". if you are very unlucky the block at 0x8400 (where the CB header is located) will be bad. In this case the tools will fail and the image is unusable today - sorry.

To be done:
Handling of bad block at 0x8400, start of CB
Using one of the spare blocks at the end of flash when guessing the hash

Please use the latest Degraded tool and create a new image (especially if you are French and have Bad Blocks) before downgrading

When you have downgraded to 1888 I would suggest you do the following:

If you have a LDV < 6 (Degraded will tell you this) or you dont care about being stealthy then just apply the 4532 update. Another fuse will be blown but now you will have your CPU key and you can increment the LDV in the CF sections of your original image.

If you have a LDV = 6 then you might want to consider:

1) Disabling the eFuses before applying the 4532 update then put the resistor back. No need to patch your original image

2) Sit out the next update

3) Accept that you will have an unusual number of blown fuses and see above

Now you have the possibility to

-Boot a vulnerable Kernel and run Linux
-Boot the latest Kernel and play on Live
-Change the region of your console for any Kernel (be careful on Live with hacked region codes, not recommended)

Its very likely that this hack will be fixed in future versions of CB (although we have found that CB version 1920 is still vulnerable). MS can also use eFuses to lockdown the CB version in a way we can't defeat even if we know the CPU key. I have no idea if MS will update the CB section in existing boxes or if it will be limited to new boxes.

MS may even take our new toy away completely making it impossible to boot vulnerable Kernels.

If the homebrew scene is of interest to you, then start saving for a new box, get its CPU keys and use one for homebrew and one for the latest games.

There's no reason not to go for a native XBMC360 now

EDIT: Damn, looks like I posted the wrong version of the Flashtool Wont stop you downgrading and I will post a link to the new version on Monday

[anita999]

well, I don't know whether to post this in hardware or kernel hacking forums. Since this topic is still hot, I would rather try my stupid question here.

So now with this hardware timing attack, we can reencrypt the 2BL even we don't know the correct hash.
Then is it possible to create our own 2BL code? I mean a customized 2BL code which will give us the freedom to load a modified dash/linux/user code in either direct or indirect ways.

If we can alter the 2BL, then we break the trust chain already. What's stopping us from doing so?

ps. I have to say sorry, because I was out of the scene for quite a long time and I am really out of the situation.

[robinsod]

Hey, good to hear from you again!

The hash we are guessing is used to verify that data that is unique to each box and that is written to the header of CB is valid (ie the pairing data, CB LDV, the hash also includes the SMC checksum). The CB section also contains an RSA signature and it's that signature that prevents us from modifying the CB code.

[zouzzz]

Sorry but the 360 Flash Tool in your .rar is the 360 Flash Tool 0.5 not a  0.85. No?

[anita999]

The CB section also contains an RSA signature and it's that signature that prevents us from modifying the CB code.

good to see you, too.
well, I tried to search more about the RSA signature checking in 1BL but ends up no further info. Is there any further details regarding the flow of how the RSA checking was applied?

Here is what I know: MS encrypted a part of the 2BL with their private key, and the 1BL holds the public key. and then how exactly does the 1BL code use the public key to verify the integrity of 2BL? Can someone show me a way to get further info?

[XFear]

Any news about the new dashboard update and the timing attack? Wondering if its still possible after the new dasboard update

[Iriez]

tmbinc had commented about it, trying to gather more details. Here's what he said...

<tmbinc> so, i've checked the new update, and it doesn't seem to contain any 'CD' timing-attack related fixes
<tmbinc> however, it fixes a memcmp() in the HV to an unattackable version  (by ORing up the XOR differences) (CB/CD)
<tmbinc> i think this update cann still be downgraded
<tmbinc> it would fix a possible timing attack inside the HV (but not at the bootloader)

[RAID]

Oh, btw, a few notes for the ones that are going to build the downgrader.

You could encounter problems in flashing the bootloader into the pic.

I have a JDM programmer selfpowered from erial cable, didn't work, probably with external 5v supply it works, but ICprog probably is not good for this pic.
It worked with willem with a ICSP adapter (it's just a socket and few wires) with software WinPic800
http://www.winpic800.com//descargas/WinPic800.zip
Willem + willem software or ICprog didn't work, i had pic fuses not writed correctly.

Edit: already this all well, sorry the haste

I have a Willem but not a ISCP adapter.

You can confirm the pin of the ISCP - > PIC16F876A

Adapter ISCP http://www.willem.org/ZIP/AD-87X.zip

Vpp -> pin 1
Vdd -> pin 20
Gnd -> pin 8,19,24
Rb6 -> pin 28
Rb7 -> pin 27

The Winpc800 does not recognize the device. (unknown) The test hardware Willen is ok.
is necessary to form something in settings on Winpc800?



Thanks

[Geremia]

Adapter ISCP http://www.willem.org/ZIP/AD-87X.zip

Vpp -> pin 1
Vdd -> pin 20
Gnd -> pin 8,19,24
Rb6 -> pin 28
Rb7 -> pin 27

You inverted RB6-RB7

Vpp -> pin 1
Vdd -> pin 20
Gnd -> pin 8,19,24
Rb6 -> pin 27
Rb7 -> pin 28

The settings you are showng are the PIC fuse settings, which are set automatically by the hex code you'll load.
Just be sure that willem is selected in the hardware settings.

[robinsod]

CB version 1920 is still vulnerable, It's been tested on a couple of machines

[Bang360]

CB version 1920 is still vulnerable, It's been tested on a couple of machines

What Kernel version does that equate to??

5766 or the new new 5787 ?

Thanks to all who helped make this possible...BRAVO