Timing attack - stupid questions thread.

[Geremia]

hehehe, this project sounds interesting, great job 

i can get all the required (or arranged) in some days, if you like

[robinsod]

Ok, I got some info from infectus and solved that problem. The integration is "sort of" working (the code is still very rough & hacked together) but I can now test a number of "guesses" with no human intervention. These are the numbers I see when average over 10 samples, I started at 190 and went on until the system failed Each "Try" is the average of 10 measurement cycles

Try 190 Result 15062
Try 191 Result 15062
Try 192 Result 15073
Try 193 Result 15060
Try 194 Result 15059
Try 195 Result 15059
Try 196 Result 15061
Try 197 Result 15060
Try 198 Result 15060
Try 199 Result 15060
Try 200 Result 15061

Can you guess the first byte of my hash? The numbers are in multiples of 50nS, the timing period is taken from the second rising edge of CE until POST != 0x21. The timing don't make a lot of sense (I haven't really analyzed them & dont really care - I am looking for an easy to measure timing delta)

http://www.national.com/mpf/LM/LM339.html

I think the LM339 is quite a slow comparator and some faster devices might be a possibility

[robinsod]

hehe, I've guessed the second hash byte (the average number of samples has been reduced to 5 - It reduces the period between crashes )

Try 94 Result 15072
Try 95 Result 15073
Try 96 Result 15075
Try 97 Result 15086
Try 98 Result 15071
Try 99 Result 15073
Try 100 Result 15073
Try 101 Result 15069

So far 0xC0, 0x61

The system is a bit unstable, typically the infectus bombs after 10 erase/write cycles but that's normal for integration work (I want to add infectus have been really helpful and delivered an excellent product - YOU GUYS ROCK)

[lasonnette]

If someone knows a faster way to make that 1V into at least 2.2V, the delta-time feature can be easily added onto infectus.

[robinsod]

Third (last one tonight - Im bored ) elusive hash byte

Try 240 Result 15086
Try 241 Result 15083
Try 242 Result 15083
Try 243 Result 15081
Try 244 Result 15093
Try 245 Result 15082
Try 246 Result 15080

To date 0xC0, 0x61, 0xF4

Edit:

I lied, 4th byte

Try 119 Result 15092
Try 120 Result 15106
Try 121 Result 15094
Try 122 Result 15092
Try 123 Result 15090
Try 124 Result 15094
Try 125 Result 15091
Try 126 Result 15097

To date 0xC0, 0x61, 0xF4, 0x78

Edit: I sampled the timing 300 times for each of the 4 Hash bytes I know plus the next one which I don't (so 5 curves in all). The average, minimum and maximum values were logged as well:

    Hash[0]   Hash[1]   Hash[2]   Hash[3]   Hash[4]
Ave   15060   15072   15083   15094   15105
Min   15051   15061   15074   15085   15096
Max   15070   15081   15094   15104   15117

This Excel file contains data and a graph of the distribution of timing measurements for each Hash byte. Its pretty clear the timing attack works. As before, time is in units of 50 nS from the rising edge of CE to the end of Hashing (0x21->0xA4)
 
http://rapidshare.com/files/50439408/Hash_Timing.xls.html

More soon

[tmbinc]

I just thought a bit about flash wear.

If we investigate the block replacement process (i think it's as easy as a brute force search trough the replacement area), we could switch to another page, possibly after some tries. That would prevent the same page from being erased over and over again...

Pretty impressive, btw, your results.

[arnezami]

Just bought some popcorn . This is turning out to be a great show!

     

Man that looks so cool


Feels like a historical moment is coming up...

[robinsod]

I just thought a bit about flash wear.

If we investigate the block replacement process (i think it's as easy as a brute force search trough the replacement area), we could switch to another page, possibly after some tries. That would prevent the same page from being erased over and over again...

Fortunately Arakon has a box with the 10th block marked as bad, should reduce the guesswork...

Pretty impressive, btw, your results.

Thanks

[lasonnette]

I just thought a bit about flash wear.

If we investigate the block replacement process (i think it's as easy as a brute force search trough the replacement area), we could switch to another page, possibly after some tries. That would prevent the same page from being erased over and over again...

Pretty impressive, btw, your results.

How about a temporary FIFO with some logic around it? He's got infectus, it'll be done maybe still today

[robinsod]

Done it! My bricked box - one blown eFuse but no CPU key and no valid flash dump that would boot (I did have a valid 2241 dump though that would no longer boot because of the eFuse) - is now alive and well and booting 2.0.1888 with a patched CB (LD count = 1) and a "guessed" hash. Even doing it "manually" only took 3 evenings Now, sleep

[sentinel0]

Awsome work, by any chance does anyone know where to get a an infectus in the states?

[stonersmurf]

Done it! My bricked box - one blown eFuse but no CPU key and no valid flash dump that would boot (I did have a valid 2241 dump though that would no longer boot because of the eFuse) - is now alive and well and booting 2.0.1888 with a patched CB (LD count = 1) and a "guessed" hash. Even doing it "manually" only took 3 evenings Now, sleep

Great news. Keep up the good work! 

[uberfry]

great work Karl
www.hardstore.com for all your infectus needs

[arnezami]

Done it!

Awesome! BIG congratulations.

Its another one of those good days

Now, sleep

Sweet dreams.

[Dense]

Congratulations on this effort.

I have a few questions that i'd like to know the answer to that follow on from where this hack leads us. Doors are opening for some very interesting developments.

1) Is this timing attack done on the kernel before or after its downgraded. I am probably wording this incorrectly but do you put the NAND dump on then do the timing attack? Or use the current working kernel?

2) Following on from the previous question, will future software upgrades from Microsoft lock out this process? Is it advisable to prevent future firmware upgrades before the CPU key is extracted? (Obviously once we have the CPU key it doesn't matter what Microsoft does).

3) Once we have the CPU key using this exploit this allows changes to be made to the key vault? I know this means we can change DVD serial number (allow the use of any 360 DVD drive), region coding and hopefully machine account (is machine account stored in the KV?).

4) If Machine Account is stored in KV, changing this should allow a banned 360 to work on Live again? If a damaged motherboard had the NAND extracted (using hardware tools) this information could be updated on the exploited system to make it look like a different system and thus allow it to regain Live access. Is this correct?

[Surrido]

VICTORY  Great work!

[Ellex80]

CONGRATULATIONS

good job karl

[parasven]

this is so great looking forward to try this on my xbox

good job to all involved

[atiman]

/applause

[jacksback]

  A BIG WELL DONE to all involved