Timing attack - stupid questions thread.

[tumba]

So ive been following on the timing attack thread and it would be nice for us wannabes to be able to ask a few questions.

And whenever you have time it would be nice with answers.


From what I have understood its now confiirmed that its working and now you are only trying to reduce the time it takes to "bruteforce" the cpu key?

[tumba]

yes you are right I mistook tmbinc post

"Works fine. I patched the CB from a 1888/2241 image and removed the 2241 CF section. The xexp files from the 2241 patch were still present in the FS but that doesn't seem to be a problem - 1888 was booted. The 4532 update also blew a lockdown version eFuse"

But this seems really really really nice. And I love reading about these guys progress

[sentinel0]

I would like to know more about the purpose of the nand emulator and how it plays into the attack

[vax11780]

I would like to know more about the purpose of the nand emulator and how it plays into the attack

Here is the proposed sequence (correct me if I get this wrong):

1) Dump the flash from a post 4552 box
2) Modify the fuse count in the flash image to allow the original firmware to boot (1888)
3) Corrupt the 4552 update in the flash image
3) Find the hash value (16 bytes) for the modified flash
    a) program the flash with 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 for the key (and correct ECC bytes)
    b) boot 360 and measure time to failure code
    c) program the flash with 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    d) boot 360 and measure time to failure code
    .
    .
    .
    e) if time to failure is 2.2uS longer, remember the first key byte and start interating on the second key byte

You can see it will take (on average) 16 * 128 program/boot cycles to find all the key bytes. If you are manually programming it will take months! The NAND flash emulator will step through the key bytes, reboot the 360 and measure the time automatically. This will reduce the time to a few days at most.

VAX

[lasonnette]

And with this code we can measure the difference between the two values

Code:

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.std_logic_unsigned.all;

entity timedifference is
port (
    Din : in std_logic_vector(7 downto 0);
    SYS_CLK : in std_logic;
    FIFO_wclk : out std_logic;
    FIFO_wdata: out std_logic_vector(31 downto 0)
);
end timedifference;

architecture behavioral of timedifference is

type statetype is (IDLE, triggerstart, triggerstop, writetofifo);
signal state,nextstate : statetype;

signal counter : std_logic_vector(31 downto 0);

begin
process(SYS_CLK)
begin
if rising_edge(SYS_CLK) then
case Din is
when X"21" =>
nextstate <= triggerstart;
when X"A4" =>
nextstate <= triggerstop;
when others =>
nextstate <= state;
end case;
elsif falling_edge(SYS_CLK) then
case state is
when IDLE =>
-- FIFO_wdata <= (others => 'Z');
state <= nextstate;
when triggerstart =>
counter <= counter + '1';
state <= nextstate;
when triggerstop =>
state <= writetofifo;
when writetofifo =>
FIFO_wdata(31 downto 0) <= counter(31 downto 0);
state <= IDLE;
end case;
end if;
end process;

FIFO_wclk <= SYS_CLK when (state = writetofifo) else '1';

end behavioral;

[arnezami]

From what I have understood its now confiirmed that its working and now you are only trying to reduce the time it takes to "bruteforce" the cpu key?

Just to clear up. The timing attack does not try to "bruteforce" the cpu key itself. It tries to find/bruteforce a hash value which is a result of the usage of the cpu key (so even if you have that hash you still cannot backwards compute the cpu key). But finding this hash value (I usually refer to it as the CB-auth value) will enable the xbox to boot the original kernel (v 1888). This then allows you to upgrade to a vulrnable kernel (eg 4532) and THEN you can extract the cpu key using the kk exploit.

So its quite a bit of "hoops" you have to jump through . But its fun and should be quite doable I think.

And since this is a one-time-only event for somebody (once you have the cpu key and decrypted keyvault you're done with this attack) the hardware needed to do this can be used by someone else. So people can share it and lower the individual costs.

Regards,

arnezami

[tumba]

Ok yeah, the hash value, so the "nand emulator" will be on a chip, with wires to the places where the time is outputted? or something

[arnezami]

Ok yeah, the hash value, so the "nand emulator" will be on a chip, with wires to the places where the time is outputted? or something

Yes. Pretty much .

A bit more info to explain:

The real NAND flash memory contains several sections. Sections are referred to as CB, CD, CE, CF etc (also SMC and KV). The CB section contains (among many other things) the 16 bytes CB-auth value. But because we want to change the CB-auth value each time we boot we somehow have to make sure that when the CPU reads the 16 bytes in the CB section from the NAND we (sneakly) take over with a nand emulator. This is some electronics that behaves like a NAND but is not. The reason we do is because its easier/faster/better to change bytes in the nand emulator than to change bytes in the nand flash itself (which may also break if you flash it too many times).

So the nand emulator makes sure 1 byte (of the 16 bytes) changes each time the xbox boots. And since we already got the electronics/chip -to emulate the nand- we also use this (programmable) electronics/chip to automatically reset and measure time. This makes an easier design.

From a hardware perspective this means that the programmable electronics/chip has soldering connections to the real nand flash (since it has to be able to "take over"), to the reset "button" to reboot (recently found and tested) and to the connections on the cpu that signify an error or a boot state. That way it can measure between two points in the boot sequence: 1) just before the error is detected 2) just after the error is detected. This means our guessed CB-auth 16 bytes are compared byte-by-byte with the real one (only known by the cpu) and a difference is found at one of the 16 bytes. And if it takes 2,2 micro seconds longer between these points in the boot sequence we know we have found another valid CB-auth byte.

Regards,

arnezami

[tumba]

And what would the hardware cost be for this product? I guess one will be able to build it himself if I dont have my thumb straight in the hand.


And another thing thanks for answer questions it's really interesting and one might really learn something.

[tumba]

and for every 00 there are 16 combinations, or 17 if 00 is counted as a value?

I mean


01 02 03 upto 16

[arnezami]

and for every 00 there are 16 combinations, or 17 if 00 is counted as a value?

I mean


01 02 03 upto 16

For every 00 there are 256 "combinations". Here is how you count hexadecimally:

Code:

00, 01, 02, 03, 04, 05, 06, 07,
08, 09, 0A, 0B, 0C, 0D, 0E, 0F,
10, 11, 12, 13, 14, 15, 16, 17,
18, 19, 1A, 1B, 1C, 1D, 1E, 1F,
20, 21 ...
...
...
                    ... EE, EF,
F0, F1, F2, F3, F4, F5, F6, F7,
F8, F9, FA, FB, FC, FD, FE, FF

However. Since -on average- you will find the correct value at roughly half of the possible byte values you only need to try (approx) 128 values for each of the 16 bytes. Thats why vax is talking about 16 * 128 total number if byte changes...

There is a theoretical minimum to the reboot time of about 1 second. So in theory you could find the 16 bytes in 34 minutes. Thats probably not gonna happen. And installing the hardware will probably take even more time so its not a really big issue. But this is basicly where the time speculations are based on.

arnezami

[arnezami]

And what would the hardware cost be for this product? I guess one will be able to build it himself if I dont have my thumb straight in the hand.

Well thats still an unanswered question. First it has to be tested, probably with some hardware already available to one of the hardware specalists right now. Then we have to see if everything works as expected. Then we can see if costs can be reduced or if there is maybe a trade-off between cost and time spend. Its too early to tell yet. But I have good hopes seeing that the frequencies we're dealing with are quite low which means its probably not going to be very expensive...

Just wait and see .

arnezami

PS. Keep in mind the timing attack is still in its infancy. It will take lots of time to develop.

[vax11780]

And what would the hardware cost be for this product? I guess one will be able to build it himself if I dont have my thumb straight in the hand.

Cost of an Infectus + $20 for a CPLD to do the emulation.

VAX

[sentinel0]

Would i cpld like this one work?  http://cgi.ebay.com/ByteBlaster-MV-CPLD-FPGA-JTAG-Programmer-Cable-Altera_W0QQitemZ290145937168QQcmdZViewItem
Also found this one
http://cgi.ebay.com/JTAG-FPGA-CPLD-Cable-Xilinx-Parallel-III-Compatible_W0QQitemZ160144766126QQcmdZViewItem
I think i might get this kit
http://cgi.ebay.com/Xilinx-JTAG-CPLD-XC9500-Development-Kit-XC9536-XC9572_W0QQitemZ290146486648QQihZ019QQcategoryZ4661QQssPageNameZWDVWQQrdZ1QQcmdZViewItem

[maximilian0017]

I think i might get this kit
http://cgi.ebay.com/Xilinx-JTAG-CPLD-XC9500-Development-Kit-XC9536-XC9572_W0QQitemZ290146486648QQihZ019QQcategoryZ4661QQssPageNameZWDVWQQrdZ1QQcmdZViewItem

Looks nice, but unless you have the skills to design the software (firmware) yourself i would hang on and wait on the other thread, big chance that they would pick another processor and you would 

The other two kits are only programmers, so you would also need a chip.
And most programmers are easy to build with only a few parts(depending on the processor)

Patience is a virtue

p.s. great idea Arnezami, keep up the good work!!!, will probably try to build the final product when the reseach is done

[lasonnette]

guys, I still have some APA075s, if you want, I can produce the full solution for it and for very cheap...

[arnezami]

guys, I still have some APA075s, if you want, I can produce the full solution for it and for very cheap...

Sounds nice .

Probably best to build it step-by-step.

- First you'll need several "corrupted" CB sections (with proper EDC bytes) like Geremia has.
- Then add the capability to measuring time (or clocks) between last NAND activity (R/B) and POST code 0x84. And test if differences can be detected between error0 and error1.
- Then add the capability to automatically reset.
- Then add the capability to (on-the-fly) "take over" a page from the CB section.
- Then make it all work together and do the loops/logic etc.

Are you up to that?

(I guess this is best done in the technical area?)

arnezami

PS. I believe the voltage on the POST is <= 1V. Is that going to be a problem?

[lasonnette]

guys, I still have some APA075s, if you want, I can produce the full solution for it and for very cheap...

Sounds nice .

Probably best to build it step-by-step.

- First you'll need several "corrupted" CB sections (with proper EDC bytes) like Geremia has.

not part of the hardware design

- Then add the capability to measuring time (or clocks) between last NAND activity (R/B) and POST code 0x84. And test if differences can be detected between error0 and error1.

why? wasn't it between 0x21 and 0xA4 or something?
btw...

And with this code we can measure the difference between the two values

Code:

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.std_logic_unsigned.all;

entity timedifference is
port (
    Din : in std_logic_vector(7 downto 0);
    SYS_CLK : in std_logic;
    FIFO_wclk : out std_logic;
    FIFO_wdata: out std_logic_vector(31 downto 0)
);
end timedifference;

architecture behavioral of timedifference is

type statetype is (IDLE, triggerstart, triggerstop, writetofifo);
signal state,nextstate : statetype;

signal counter : std_logic_vector(31 downto 0);

begin
process(SYS_CLK)
begin
if rising_edge(SYS_CLK) then
case Din is
when X"21" =>
nextstate <= triggerstart;
when X"A4" =>
nextstate <= triggerstop;
when others =>
nextstate <= state;
end case;
elsif falling_edge(SYS_CLK) then
case state is
when IDLE =>
-- FIFO_wdata <= (others => 'Z');
state <= nextstate;
when triggerstart =>
counter <= counter + '1';
state <= nextstate;
when triggerstop =>
state <= writetofifo;
when writetofifo =>
FIFO_wdata(31 downto 0) <= counter(31 downto 0);
state <= IDLE;
end case;
end if;
end process;

FIFO_wclk <= SYS_CLK when (state = writetofifo) else '1';

end behavioral;

- Then add the capability to automatically reset.

no problem at all!

- Then add the capability to (on-the-fly) "take over" a page from the CB section.

How often did I already say that it's possible just using a fifo? It's basically the USB core + a 528 Byte FIFO.

Btw. Uberfry kinda posted that code already:
http://www.xboxhacker.net/index.php?topic=8210.msg51542#msg51542

- Then make it all work together and do the loops/logic etc.

No problem, a state machine as a top entity...

Are you up to that?

You bet.

(I guess this is best done in the technical area?)

Don't know, people don't listen to my ideas there and flame me in private.

PS. I believe the voltage on the POST is <= 1V. Is that going to be a problem?

erm no, level translators exist...

[arnezami]

Ok. Lets do this .

- First you'll need several "corrupted" CB sections (with proper EDC bytes) like Geremia has.

not part of the hardware design

True. But to test stuff properly you need might need it. Anyway. For now you can do without.

- Then add the capability to measuring time (or clocks) between last NAND activity (R/B) and POST code 0x84. And test if differences can be detected between error0 and error1.

why? wasn't it between 0x21 and 0xA4 or something?
btw...

And with this code we can measure the difference between the two values

Code:

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.std_logic_unsigned.all;

entity timedifference is
port (
    Din : in std_logic_vector(7 downto 0);
    SYS_CLK : in std_logic;
    FIFO_wclk : out std_logic;
    FIFO_wdata: out std_logic_vector(31 downto 0)
);
end timedifference;

architecture behavioral of timedifference is

type statetype is (IDLE, triggerstart, triggerstop, writetofifo);
signal state,nextstate : statetype;

signal counter : std_logic_vector(31 downto 0);

begin
process(SYS_CLK)
begin
if rising_edge(SYS_CLK) then
case Din is
when X"21" =>
nextstate <= triggerstart;
when X"A4" =>
nextstate <= triggerstop;
when others =>
nextstate <= state;
end case;
elsif falling_edge(SYS_CLK) then
case state is
when IDLE =>
-- FIFO_wdata <= (others => 'Z');
state <= nextstate;
when triggerstart =>
counter <= counter + '1';
state <= nextstate;
when triggerstop =>
state <= writetofifo;
when writetofifo =>
FIFO_wdata(31 downto 0) <= counter(31 downto 0);
state <= IDLE;
end case;
end if;
end process;

FIFO_wclk <= SYS_CLK when (state = writetofifo) else '1';

end behavioral;

The time difference between 0x21 and 0xA4 was too imprecise (or better: inconsistent). Using R/B proved to be (near) perfect. Right now that means (because you don't have a "corrupt" CB-auth) you should measure between last R/B and 0x22 (to simplify even more you can of course use your code and use 0x21 and 0x22 but keep in mind the time measurements won't be very reliable, that will have to change later on).

- Then add the capability to automatically reset.

no problem at all!

Thought so .

- Then add the capability to (on-the-fly) "take over" a page from the CB section.

How often did I already say that it's possible just using a fifo? It's basically the USB core + a 528 Byte FIFO.

Btw. Uberfry kinda posted that code already:
http://www.xboxhacker.net/index.php?topic=8210.msg51542#msg51542

Ok. You will have to add the ability to calculate EDC bytes though. Or maybe store 256 of them (with precalculated EDC bytes) each time you "attack" one of the 16 bytes.

- Then make it all work together and do the loops/logic etc.

No problem, a state machine as a top entity...

Are you up to that?

You bet.

You seem eager .

(I guess this is best done in the technical area?)

Don't know, people don't listen to my ideas there and flame me in private.

I have no problem with you at all (wouldn't know why) so I think the best way to react is simply to prove them wrong about you .

PS. I believe the voltage on the POST is <= 1V. Is that going to be a problem?

erm no, level translators exist...

Ok. Sounds good.

What box do you have? How many burned fuses? What kernel version? Do you have your cpu key? I assume you can flash and dump you nand.

Regards,

arnezami

[arnezami]

Just a related thought (its a bit speculative so I'll post it here).

It may be possible to execute this attack without ever flashing the nand. In other words: there might not be a need for an external flasher.

There are a few conditions:

- The programmable chip we are talking about here is capable of reading/sniffing a few pages during normal boot (eg first page of CB and CF) and remember/store them.
- it can do all the above stuff (CB-auth changing, EDC calc, resetting, measuring time, keeping track of it all etc)
- it can on-the-fly corrupt CF (so just 1888 kernel is run)
- the xbox will boot into 1888 if CB auth is correct even if the firmware contains 4552+ firmware stuff (so libraries are not a problem...)
- when the CB-auth is found -and is therefore emulated by the programmable chip- the xbox can be upgraded to 4532 even if the real nand doesn't contain a valid CB auth (for 1888-only booting)
- the encryption keys the C* sections are encrypted with are in no way dependend on the (changed) content at the beginning parts/page of CB.

If possible that would make it a really cheap and nice solution.

Thoughts?

Regards,

arnezami

PS. Is anybody else already working on implementing the timing attack? That would be good to know .