35C3 - wallet.fail

35C3 preroll music

Herald angel: Welcome everybody to our
next Talk. It's the talk “Wallet.fail”.

As you all know, when you have something
valuable you put it somewhere safe. But as

we as hackers also know there is no place
that is really safe and our three speakers

Thomas, Dmitry and Josh are now going to
demonstrate in the next hour the art of

completely breaking something apart. So
please give a big round of applause for

Thomas, Dmitry and Josh and have a lot of
fun.

Applause

Dmitry: So just just to start, I'm
curious how many people here actually own

cryptocurrency. Raise your hand. And how
many of you store it on a hardware wallet?

So we're very sorry to everyone who has
their hand up. OK. So it's not just me.

It's me, Josh and Thomas. So we're all
hardware people. We do low level hardware

stuff in varying degrees and we got into
cryptocurrency and so I can recommend to

everyone sitting in this room if you're a
security person. There's not a lot of

people doing security and cryptocurrency
as much as that's painful to hear. So yeah

I mean a lot of this is based on reverse
engineering. We love cryptocurrency.

I mean for us crypto also stands for
cryptography not just crypto currency, but

no offense to anyone with this talk. It's
just something that it's a category that

we looked at. And so the results kind of
speak for themselves. And again this

wouldn't be possible alone. So we have a
lot of people to thank. I'm not going to

go through all of them individually. Just
be knowing that we're thankful to everyone

on this, on the slide. So yes, so we
started this about six months ago. So we

wanted to take a look at cryptocurrency
because we own some cryptocurrency

ourselves and we saw that everyone's using
cryptocurrency wallets. It's more and more

the thing that you do. So we started a
group chat as you do nowadays. And we have

50000 messages now and 1100 images. And I
had my first, I had my son in the meantime

as well. So it's a really long time that
we been looking at this, etc.

Applause

OK, so what do we want to achieve
though? Because people don't give

the kinds of attacks so you can
actually perform against

cryptocurrency wallets enough credit.
So first attack is supply chain attacks

where you are able to manipulate the
devices before they get

to the end customer.
Firmware vulnerabilities, where you find a

vulnerability in the firmware and can
somehow either infect or do something else

with the device. Side-channel attacks of
course. I think that's one of the more

obvious ones that people are familiar
with. And also chip-level vulnerabilities.

So we were able to find one of each of
these. And so that's the talk that we're

going to talk about each one of these
individually. But first, what's a wallet?

Just in case you are not 100 percent
familiar with them. So a wallet, and in

general cryptocurrency how do you do this,
it's just asymmetric cryptography. So you

have a private key and a public key. The
public key, basically, it gives you the

address. You can derive the address from
this. The address is nothing other than

the public key of the wallet and you have
the private key and you need this to send

transactions, so to actually operate with
the cryptocurrency. So this, the private

key, is what needs to be kept secret. The
public key is something that everyone can

know so that they can send cryptocurrency
to you. But it kind of sucks to have a

separate for each cryptocurrency-pair or
for each wallet maybe even multiple

wallets. It sucks to generate a new
cryptographic pair for each one of them.

So the people, the wonderful people,
behind bitcoin have thought of something

for this and it's called BIP32/BIP44. And,
so, what it is is you have a cryptographic

seed and you can actually derive the
accounts from a single seed. So you

basically store one seed and you're able
to implement and do unlimited amount of

wallets. Okay. So basically you do key
derivation, you add some data, do key

derivation and you can have an unlimited
amount of wallets while storing a single

seed. And this is what you're using when
you're using a hardware wallet. So and of

course for each key derivation there will
be a new private key and a public key, but

it will be generated in a predictable
manner and you only need a store one

secret seed. So you only have to store the
seed. You can write it down, and that's

the advantage. But it's difficult to write
down because it's binary data. So come

BIP39, which is what you're most used to,
which is a format in which you can take

that cryptographic seed, that binary data,
and actually convert it to a set of

dictionary words that you can then easily
write down on a piece of paper and store

it at your mother's house, or store half
of it at your mother's house and half of

it at your grandmother's house. And that
way somebody would have to go into both

houses simultaneously to get your words.
So yeah. So what's a hardware wallet?

So we just talked about what's a wallet.
So why do you even need a hardware wallet?

Well, the problem is, of course, computers
can get backdoored, have malware running

on them and this is what you want to pre-
vent against. How do you do this? You have

a secure device, you store your seeds
externally. Usually, this is a USB-

connected device that you store your
crypto on and so you can trust this even

if you can't trust your computer. This is
the idea. So what happens is the computer

sends the transaction to the device. The
device gets the transaction, it can

actually confirm or deny the transaction.
It also displays the transaction. So

before you do any cryptographic signing,
you can see is that actually what I was

doing or was my computer owned and is it
initiating the transaction for me? So you

sign the transaction and also, yeah, the
seed never leaves the transaction, but the

hardware signs a transaction for you. You
send it back to the computer and the

computer can actually take that and send
it to the Internet. OK? So that's a quick

rundown of how crypto or, sorry, how
hardware wallets work. So the first thing

that we looked at was supply chain attacks
which is where Josh gonna pick up. You

have a mic. Oh sorry.
Josh: Ok, so the three big things I want

to leave you with as we go through the
supply chain attacks are, stickers for

laptops, they are not for security. So
we're going to be talking about stickers

today. They're there for laptop
decorations, they are not for security.

Supply chain attacks are easy to perform,
but they're quite hard to perform at

scale. And the last takeaway that I will
leave you with is that, the vendor's

threat model may not actually be your
threat model. So security stickers, some

of the wallet vendors are using them. I
have seen them on other products, they

seem to be quite popular. I have a friend
and colleague named Joe Fitzpatrick, he

also likes stickers. So the stickers that
he makes are the same as we find on his

security product. They have holograms.
They have unique serial numbers. And they

leave you with that nice warm fuzzy
security feeling. Joe makes some funny

ones. You can get a Fitz 140-2 approved
stickers. You don't have to pay the money

for the FIPS one, just get the Fitz one.
So the first device I looked at was the

Trezor One. The Trezor One actually has
two levels of protection on the packaging.

There's the hologram sticker than the
actual box is enclosed with an adhesive.

So it's supposed to be that you actually
have to rip open the box to get into it.

But if you use a hot air gun or a
hairdryer it's actually quite easy to

remove. And so if you see on the left
there that's the original package and on

the right this is a box that I opened and
put everything back into. And if you look

closely there is a little bit of gap
there. The sticker has a little bit of

break but this was the first try. And it's
pretty close. So trust me taking a sticker

off is not very hard. Now if you remember
this picture of the sticker cause we're

going to come back to it. So but for the
vendor this is actually a real problem so

Trezor did put a blog post out that one of
the challenges they face is that they're

facing counterfeiting of their devices. So
this is from their blog post. They say hey

you know we've noticed that there's
counterfeit devices. You have to look at

the stickers to see that they are legit.
So I said remember look at that sticker.

So I bought that case about a year and a
half ago for my previous DevCon talk and

it's the same sticker that they're saying
is fake here. So then on their wiki it's

very confusing because there's three sets
of stickers so basically, yeah, stickers

are very confusing. They cause problems
for end users. And I was not even sure if

I bought a real Trezor or a cloned one. So
this morning I got out a new case. And

just to make sure I took off the sticker
using very sophisticated equipment

including a very expensive Dyson hairdryer
that was included in the AirBnB and I was

able to remove the sticker.
So it comes off

with zero residue. So yes stickers do
not provide any security. On the Trezor T

they switched it from the box and now the
box can be opened easily. But now there's

a sticker on the USB-C port. Again as you
would expect use hot air and you can

easily remove it. Pro tip: don't set the
hot air rework that high I had it set for

lead free reworking and I actually melted
the enclosure. So if you're going to do

this kind of supply chain attack, maybe,
no, set the heat a little lower but if you

just google how to remove stickers the
same attack methods work. So this causes

a bit of confusion because the ledger
device has a very, I will say, in your

face a piece of paper when you open the
box it says there are no stickers in this

box. However I combed through about 250
1-star Amazon reviews and a lot of them

have to do with confusion about the
stickers. So some of them are actually

quite funny. So this this one started out
"Note to wallet hackers", so I was really

into this. So I was like, OK, pro tip
what's this guy have to say? And basically

he was complaining that there's
fingerprints on the device. That's how he

knew it was hacked. Another one complained
that the fingerprints were on the wallet

and there was a hair underneath. So if
you're doing supply chain attacks be sure

to remove any evidence of your
fingerprints or hair. So anyway stickers

don't work. That's all I want to say about
that. Once you get through this enclosure

though you then have to have the challenge
of actually opening the enclosure. These

are three different wallet devices: Ledger
Nano on the left, the Trezor One and the

Trezor T on the bottom all of which
actually open pretty easily. So the Trezor

One, even, so, I'm still not sure if
that's the counterfeit or the real one,

but I get on the on the real one today. I
was able to pop open enclosure. So it is

ultra sonically welded but you can pry it
in there and open it. The Ledger Nano

opens very easily, like, without any
equipment. But once you do this, you know

what do you do once it's opened? So the
attack basically is you take the

microcontroller and you rework it. So you
remove the microcontroller from the

printed circuit board and you put on a new
one that you bought from a distributor.

Once you've done that on the Trezor
devices you can put your compromised

bootloader on there. So this is, I did not
go as far to make the compromised

bootloader, but I did confirm that once I
switched the microcontroller, I could

connect with a debugger over SWD and I
have free access to the chip. So some of

the parts got blown off when I was
reworking but the SDM works fine. So yeah.

So you just rework, reflash and then you
put everything back together. So next I

want to talk about hardware implants. So
you may remember the story that came out

there was this big hack by Bloomberg about
hardware implants. I wanted to make a

hardware implant. I also wanted to have a
little bit of fun with this. So, we, in

honor of the Bloomberg story which has
some, you may have some issues with it.

We're about to talk about the BloomBurglar
which is a super micro fun implant. So the

goals for this implant is I wanted this
implant to happen after receipt. So it is

both a supply chain attack and a physical
one like a red team can perform this. A

malicious insider could also perform this
attack. Zero firmware, because more fun.

It has to fit inside of a hardware wallet,
so it has to be small it has to also

bypass the core security function,
otherwise it's not an implant. Very few

components. I have a thousand of them with
me. So I wanted to be able to offer Makers

and DIYers to participate in the hardware
implant fun. So what kind of implant did I

end up with. Well, I decided to do a
basically, an RF-triggered switch and so

the idea is on these devices there's a
button and the button is the last line of

defense. So all the vendors assume that
the host is going to be compromised. They

just assume that's going to be easy
because that's software. And so once you

have a compromised host you have to send
it to the device and then the human -- so

humans are still needed -- humans have to
look at it and say "Is this the right

transaction or not?" They have to say yes
or no. So now with this implant I can,

through RF, I can trigger the yes button.
So a human is not required to send

transactions, I can remotely trigger it.
Basically the RF comes in through the

antenna it goes through a single
transistor which is the main component and

it pulls the button low. And I'm sorry to
say that the bill of materials is quite

expensive at three dollars and 16 cents.
Two dollars and 61 cents of that is this

potentiometer I had to use. So it is a
little bit expensive. I'm sorry. Also, why

is this so big. I mean this is an American
Dime I can fit two on them. What's the

deal. Why is it so big. Well I optimized
it for hand assembly. So it would be, you

know, more fun to use, but basically you
put the antenna in and then there's an out

button and, like I said, I have a thousand
with me. So just for scale. This is how it

fits on the Ledger Nano. This is how it
fits on the Trezor. It is also because

breadboard-friendly is a thing. So we made
it breadboard-friendly. So you can also

play along very easily at home. So then
the last challenge with an RF implant is

how do you design antenna to fit in there.
And so the big thing there with an

SMA connector is the first prototype
I did. Experimented with a few antenna

designs but that remember it, it all has
to fit inside the Ledger. So that's

actually quite easy because a Ledger Nano
has a plenty of room to insert extra

circuitry and so it quite fits easily in
the Ledger Nano. And then I did the

implant and then I started to go through
the wallet process. I got to a

check that said is might, you know, is the
Ledger device genuine. And here I actually

got a little bit nervous because it wasn't
working, and so it wasn't working. I was

like, maybe they were checking this, you
know how did they detect it. Don't worry,

it's only Linux. So it just doesn't work
on Linux. So that was no problem. I did it

on windows and no problems. The device was
genuine, I was able to move on. So the

thing is, this is a very crude receiver,
but the attacker can always use more

power. So here I have this is my antenna
setup in the basement, and with a 50W

transmitter I can remotely trigger the
button at 11 meters, and at this point I'm

just limited by my basement size. I'm
pretty very confident that I'd be able to

remotely trigger this thing further. Yeah.
So here we're going to see a demo of what

it looks like and for the other problem
you have with hardware implants is how do

you know you have the implanted device. So
you have to label it some way. Ledger has

this kind of Latin phrase that scrolls " I
wanted my own Latin phrase" And so this is

how I know this is my implanted device. So
what we're going to see is that the

transaction screens is gonna show up. This
is, and I'm basically going to trigger

this remotely, so I'm going to show that
radio come in and then it's going to

approve the transaction without any hands.
So this is the transaction. There is the

screen going. This is the way it supposed
to verify. There's the radio coming in at

433 MHz and then it's going to proceed to
the next screen without me touching the

button. There you go. So this is remotely
triggered, and that would have sent

transactions. So if you think about the
context that you have a malicious software

implant that sent it to a wrong address,
the attacker now can remotely accept that

and bypass the security module.
Applause

So, yeah, on the recaps, stickers are for
laptops, not for security. Supply chain

attacks are very easy to do at a hardware
level, but they're quite hard to do at

scale. And when the vendor says the device
is genuine, that may mean different

things.
Thomas: to segue to the next part, so six

months ago, Josh Datko said something that
I found kind of funny and it's almost

correct: "If you put funny constants in
your code, they will end up on DEFCON

slides, and they won't be laughing with
you." Small mistake, they won't end up at

DEF CON, they will be at CCC. and so
introducing the fOOdbabe vulnerability,

it's a bootloader vulnerability in a
Ledger Nano S. We did not come up with

this constant. It's literally in the code
as we'll see later. So the name was not

ours, but we like it. So we also bought
the domain foodba.be.

Laughter
Ledger Nano S is a very simple wallet. It

simply has a small display, it has a USB
port and two buttons. That's really all

there is. And you should take it apart.
You see it's just some pieces of plastic,

the display and the PCB. And looking at
the PCB, it kind of has an interesting

architecture where you have a STM32, which
is just a general purpose microcontroller,

and a ST31, which is a secret element that
is for example used in pay-TV and so on.

And is regarded as a very high security
chip, basically. And if you turn the PCB

around, you'll see that they were nice
enough to leave the programming port for

the STM32 open to us, ENABLED.
Laughter

And this has been suspected by other
people that we verified it. But you know,

you have to go through it. And obviously
Ledger is aware of this. And so let's look

at the security model that the Ledger Nano
S has. The basic idea is that if we look

at this device, we kind of have this
schematic of the STM32 being on the left

and the ST31 on the right. And as you can
see, all peripherals are connected to the

STM32. That is because the ST31 does not
have enough pins to connect peripherals.

It literally only has a one pin interface,
which is for the smartcard protocols

basically. And so all the heavy lifting is
done by the STM32. And Ledger splits it up

into the unsecure part and the secure
part. And the idea is that the STM32 acts

as a proxy. So it's basically the hardware
driver for the button, for the display,

for the USB, similar to a northbridge in
your standard computer. And when you take

a computer and want to make a transaction,
you create your transaction on the

computer, it goes through USB to the
STM32, and the STM32 then forwards it to

the ST31. THe ST31 then says, Oh, a new
transaction, I want trust the user to

confirm it. So it sends a display command
to the STM32 which in turn displays that

on the screen. And then you press the
"yes" button again it goes the same route

to the ST31, which then internally signs
the transaction. So the seed never leaves

the device and our assigned transaction
goes back through the STM, through USB to

the computer. To us, this means if this
chip is compromised, we can send malicious

transactions to the ST31 and confirm them
ourselves. Or we can even go and show a

different transaction on the screen than
we are actually sending to the ST31. And

Ledger is aware of this and we'll talk
about how they try to mitigate this later.

But first we have to find an exploit,
because while we do have debugging access

to the chip, hardware access is sometimes
kind of buggy. No offence. So we wanted to

have a software bug. And so we started
reverse engineering the firmware upgrade

process. And when you look at the
bootloader, the bootloader for the Ledger

used to be open-source, and back then they
didn't have any verification of the

firmware. So you could basically boot the
device into bootloader mode, flash

whatever from where you want, and then it
would run it. After someone, Saleem in

this case, wrote about this, they changed
it, and they changed it to do some

cryptographic measure. And we were too
lazy to reverse engineer the cryptographic

measure because it's very time consuming,
very hard. So we looked more at the parts

surrounding it and how we can maybe find a
bug in the bootloader to break it. And it

turns out that when you try to upgrade
your Ledger, you accept four different

commands. One is select segment, which
allows you to select the address base at

which you're firmware will be flashed. One
is the load command, which allows you to

write data to flash. Then you have the
flush command, which is basically like

f-sync on Linux and writes your changes to
the non-volatile memory. And you have the

boot command, which verifies the flash
code and starts booting it. So to us the

boot command is the most interesting,
because it provides all verification and

it attempts to ensure that no malicious
image is booted. And it turns out that if

you issue the boot command, it compares
the whole image to whatever

cryptographically function they use, and
if it's successfully verified, they write

a constant to the address 0x0800 3000, and
that constant is OxF00DBABE. And so, to

not have to verify the entire flash on
each boot, they just do this once, so only

after firmware upgrade. So basically if
you boot up the ledger, it boots, it waits

500 milliseconds. It checks if you have a
button pressed. If yes, it goes to

bootloader. Otherwise it loads the
constant at 0x08003000. And if it's

0xF00DBABE, it boots the firmware. So our
goal is to write a 0xF00DBABE to that

address. First attempt, we just issue a
select segment command to exactly that

address. We just write 0xF00DBABE to it,
flush and reset the device. Didn't work

unfortunately. so we had to do more
reverse engineering. It turns out that

they use an interesting approach to ensure
that you don't accidentally flash over the

bootloader. So they basically blacklist a
whole memory region. So if you try to

flash from 0x0800_0000 up to 0x0800_3000.
It returns an error. If you try to

directly write to F00DBABE, They thought
about it, and they have a very specific

code path to prevent that. So they memset
it to zero and you're screwed again. And

then finally it writes assuming you didn't
error out. But it turns out that the STM32

has kind of an interesting memory map and
on a lot of chips, you cannot only map

your flash to one address, but you can
also have it mapped to another address.

And in this case the flash is indeed also
mapped to the address 0. And so the

bootloader uses a blacklisting approach,
so it only excludes certain memory areas.

But it doesn't use whitelisting where you
could only explicitly write to this memory

region. So they do not block writing to
0x0000_0000. Profit! Second attempt. We

just select the segment at 0x0000_3000,
which maps to 0x0800_3000, we write

0xF00DBABE to it, we flush, reset, and we
can flash custom firmware! Awesome!

Applause
So what do you do when you have a device

that, where the display is not big enough
to run DOM with a custom firmware. So in

this case it's an original letter, press
the button, put it into bootloader mode,

which is part of the normal operation, and
Laughtes and Applause

If you want to play a bit of snake, come
by later. How are they protecting against

this? I've mentioned before Ledger is
aware that you can reflash this STM32. And

they are, they put in some measures to
prevent you from doing malicious stuff.

And basically what they do and this is
very simplified, and we did not bother to

fully reverse engineer because we didn't
need to, basically. When the chip boots,

it sends its entire firmware to the ST31,
which then performs some kind of hashing

also, verifies that the firmware as
authentic. And it also measures the time

it takes to send the firmware. This is to
prevent you from just running a

compression algorithm on the STM32 and
send it very slowly. How do we bypass

this? So our idea was, because we not only
have flash, we also have RAM. So what if

we create a compromised and compressed
firmware that copies itself to RAM? We

jump to it and then it writes its entire
compressed firmware to flash,

uncompressed in that case, and then we
just call the original code on the secure

element. It would verify the firmware, it
would run with a real timing and boots up

regularly. And so we attempted this. It
took quite a while to achieve.

Because basically, you can't do ZIP, you
can't do LZMA, because even if you

compress the image you don't have enough
space for complex compressor. So our

attempt was to find duplicate bytes,
squeeze them together and make space for a

custom payload. And basically we just have
a table that says, okay, now you will have

six zeros or something. And our each table
entry only takes a single byte. So, and

it's only like 10 instructions in
assembler to run this decompressor, so you

don't have the large code base. It's very
easy to use. And it turns out that even

with a very simple detector, like in this
case we rerun the script to find the

longest duplicate data, and you can see on
the first try, we get like 260 bytes of

space for our payload, which is enough for
a lot of things, let's say. And we have a

working PoC of concept of this and we
would go into a lot of details, but if we

only got an hour. And so we will release
after this talk and on non-offensive

example of this that you can look at how
does it work, what can you do even if

you're firmware is attempting to be
verified. And we also and this is very

exciting we are working with the YouTube
LiveOverflow and he created a 20 minute

video on walking through this entire
F00DBABE vulnerability, how did the

verification works and how to bypass it to
a certain degree. We don't want to

weaponize it. So we did not, we will not
release the first the full thing, but

yeah, very excited for this. Stay tuned on
our Twitter and we'll link it for sure. As

part of this, we also have a lot of
software that we will release. So public

release, we'll release the snake firmware.
So hopefully this evening you'll be able

to play snake on your Ledger. If you
bought some bitcoin at twenty thousand now

you're bankrupt, you can at least play
snake. We will opensource the compressor

and the extractor. We built a logic
analyzer plugin for this markup protocol

and we built software that analyzes the
communication between the STM32 and the

ST31 on the Ledger specific data, and you
can just dump it. So if you guys are

interested in for example trying to break
into the ST31, please have a go. And

Ledger has a second device, which is
called the Ledger Blue. We assume the

reason it's called the Ledger Blue is
because it contains Bluetooth. But they

never enable Bluetooth. So it's basically
just a regular Ledger with a color display

and a big battery in it. And we call this
part "Fantastic Signals and how to find

them".
Laughter

Because when we opened up this device and
we were chatting, we have this nice

telegram chat room where we're chatting
24/7 while doing this. And we opened up

the device and the first thing,like
literally five minutes after opening it, I

saw that you have the secure element on
the left and the STM32 on the right. You

have some other stuff like the Bluetooth
module and so on. The trace between the

secure element and the microcontroller is
pretty long and contains a pretty fast

signal. So what is a long conductor with a
fast changing current? Anyone got a clue?

Interjection
Correct. It's an antenna.

So I pulled out my HackRF
software defined radio, this

is just a very, a more sophisticated RTL-
SDR, so you can just sniff arbitrary

signals with it. I got a random shitty
telescope antenna on Amazon and they have

my Ledger blue. So on this screen, you can
see the blue thing is the radio spectrum

around 169 MHz and if we start entering
our pin we can see that there's a weak

signal.
Laughter

You guys see where this is going. On the
radio. Unfortunately that signal is pretty

weak. Luckily they included an antenna.
They call it a USB cable, but I'm not so

sure about it. So this time with USB
connected, and we do the same thing again.

You can see like crazy radio spikes and
this is right next to each other. But even

if you go a couple of meters. I was
limited as Josh by my living room space.

You get a couple of meters of decent
reception. So our goal was to find out

what is this signal and if we just look at
the recorded amplitude of the signal, we

get this. And if you do a lot of probing
and so on, you immediately see, ok, there

are spikes and there are 11 of them and
then there's a pause and then are small

spikes. So this is probably some kind of
protocol that first sends 11 bytes of data

then pauses, and then sends more data. So
we looked at the back of the device,

started probing every single connection
and tried to figure out is this the secure

element? Is this whatever? And it turned
out to be the display bus. So we can sniff

information on what is sent to the display
remotely. And if you, if we look at the

signal that gets sent in blue, it's the
signal that gets sent when you press the

letter zero on the pin pad and an orange
when you press the letter seven. So we can

see a very clear difference at certain
points on the signal which confirmed our

suspicion. But building software for this
is kind of boring, like digital signal

processing is not really my thing. So what
do we do? And we wanted to increase the

buzzword load in our talk a bit. And so we
are hacking blockchain IoT devices, using

artificial intelligence, in the cloud.
Applause and Laughter

So our ideal was we record training
signals, we use some kind of prefiltering,

we train AI on it. Profit! Literally.
Problem is, getting training data really

sucks, because you don't want to sit there
for 10 hours pressing the same key on a

pin pad. It really doesn't sound like fun.
And so this needs automation. So,

Laughter
So we took in Arduino, we took a roll of

masking tape, a piece of acrylic glass, a
PCB vice and this is a HUAWEI-pen for the

extra amount of Chinese backdoor. And we
let this run for a couple of hours. And

you can actually see that every time it
presses down, you can see that the digit

that you pressed is highlighted and the
difference in the signal we saw earlier is

probably the x and y coordinate, of where
it highlights the button. And that's the

difference. We can see in the trace. And
so we had a lot of recorded data. Now we

created a training set. We created a test
set, preprocessing Tensorflow ai model.

It's really easy surprisingly. And we
tried our test set did a prediction. And

so the big question how accurate is it.
And it turns out. So this is the the

result of a cut of the test set. And if we
zoom in on this this basically tells you

we have the signal of this great thing
it's just a picture representation of the

signal and it tells you how sure it is,
what digit it is. In this case it's 7 with

98 percent likelihood. So pretty good. In
our test set we only have one wrong result

and overall we get it wrong 90 percent
accuracy and to move this in the cloud we

are hosting this on the Google cloud. As
the LedgerAI for you guys to play with and

we'll publish it online with a limited
dataset that is trained on a very close

space. You cannot do something super
malicious with it but it's nice to play

around and see how this was done. And this
brings us to the next part, glitch me if

you can. Thank you.
Applause

Josh: So now we're going to talk about the
silicon level vulnerability with glitching

attacks fault injectio so to review.
So to review I will be talking about the

trezor one. And so I just want to go over
very quickly what the architecture is of

the trezor one and some previous work that
is done. So the Trezor One is quite a

simple embedded device. It consists of
only a few components. It has an OLED

display it has some buttons and has a USB
connector that are all externally facing.

Internally it has its main brain if you
will the STM32F205 microcontroller which

controls all the other operations on the
Trezor, that display, the USB, and the two

buttons. So last year we gave a talk at
DEFCON "Breaking Bitcoin Hardware Wallets"

here we use the chip whisper to mainly do
the glitching attacks, the conclusions

from last year is that the F2O5 was
vulnerable to fault injection but it was

inconclusive if we could do a exploit via
the fault. So this year we have a

different result but the output of that
work was this board was

called the breaking bitcoin board.

Basically it was a Trezor clone that just
made it easy to attach wires and probes

and so we made this board. The design
schematics are all online. It's open

source hardware. This is the chip
whisperer set up that we were using so we

made the board specifically to fit on the
chip whisperer target board. And this is

just what it looks like when you use the
chip whisper GUI to perform a glitch. And

here we were doing application level code
so it's very different but I gave that

talk and then I met Dmitry and Thomas.
Dmitry: Fortunately we had Josh to do the

talk last year and to kind of exhaust a
lot of the firmware vulnerabilities that

were actually hardware vulnerabilities in
the firmware that might have been there.

So we immediately knew that we could
exclude this. And so you can start looking

at the underlying microcontrollers. So in
this case it's STM32 microcontroller that

they use inside of it and it controls
everything. So compromising the STM32

microcontroller means that you can
compromise, you can compromise the device.

So I mean so there's a couple of papers
that have covered some of the

vulnerabilities in the STM32 specifically
there's one which describes a UV attack

which lets you downgrade the security on
the STM32. So we determined that paper

unfortunately does not apply to our result
because the Trezor or is smart enough when

it boot's to check the value stored in
Flash. And if it has been altered in any

way to set it correctly. So they actually
even protect against this kind of attack.

But nevertheless you can see that there is
some vulnerabilities. So there is another

paper which unfortunately has not been
published yet and we couldn't get in touch

with the authors yet. That should be
coming out in January hopefully which

describes glitches against the STM32 F1
and STM32 F3. So now we have the F0, the

F1, and the F3 and so basically here's the
product matrix. So three of them are

already vulnerable. So what we're looking
at SDM 32 F2 and potentially STM32 F4 if

we're talking about the Trezor model T so
those we do not have vulnerabilities for

yet. So let's take a look at how how it
works really quickly. So the way that STM

implements security on the STM32 is that
they store an option byte and the option

byte the thing to remember is on on a
cortex M3 or M4 microcontroller that you

don't have anything other than flash. So
even though they call it option buy or

refer you to this is fusing or being
permanent and hardware. It's still stored

and flash just like the user application
is stored in flash. So it's the same exact

same non-volatile memory that's otherwise
used. So basically when you get a new SDM

32 it's shipped in a state where you have
full access. So that's how Josh was able

to rework abord and flash it with new
firmware. And there is the ultimate

security is what's called RDP2. So there
you have no access but you can see that

basically if you have a value other than
aa or cc which correspond to RDP0 and RDP2

respectively then you have what's called
RDP1 and this is interesting because it

doesn't give you access to the flash which
is actually where the cryptographic seed

is stored on the Trezor but it gives you
access to RAM, it gives you access to the

registers but it doesn't give you flash
access like I said and it doesn't give you

single stepping as well so connecting a
debugger and this mode will actually cause

the hardware to hard fault which we'll see
in the second. So basically what we want

to try to do is to downgrade RDP2 which is
what the trezor is set to. And we want

to be able to access the device at RDP1
which is somewhat vulnerable state. This

so I should say that this is this is the
correct way to approach this and it's

great for doing an educational talk. But
in all honesty there's three of us. And so

we did this completely in the dark over a
over 3 months trying different

parameters on our on our glitch setups
which also later and were able to find

this. But I'm here to explain it to all of
you so that it's easy to reproduce. So if

you actually watch the SDM 30F2 boot
you'll see that it's relatively slow and

it's only this slow after you power cycle
the board. So it takes approximately

1.8 milliseconds to boot which is
a microcontroller terms pretty slow so you

can see there's the power supply there's
the IO pin and that's approximately how

long it takes to boot the firmware so you
can see that's where the IO actually

toggles so 120 milliseconds later. So we
just wrote some firmware to basically

toggle one of the pins measured within an
oscilloscope. Now we have the timing of

how long that takes. So that's not super
interesting because that's not really a

trigger. And each one of these
microcontrollers internally it has a boot

rom so it has some some rom read only
memory. It's not non-volatile memory it's

not the flash. It's literally a rom which
is inside the chip itself. It's it's hard

coded. It cannot be fixed or patched that
gets executed first. So we wanted to

actually attack that because anything else
is the user application and that's what

Josh did last year. So you can kind of
start to fiddle this down. So you see that

1.4 milliseconds of the reboot
nothing actually happens because this is

now the reset line. And so the reset line
goes high after 1.4 millisecond

so you can ignore the first
1.4 milliseconds after you

cycle the power. So now the next step that
you can actually do is you can connect

what's called a shunt resistor. So
oscilloscopes are there to measure

voltage and so you want to actually
measure current to be able to know how

much power is being consumed
by the device. So you do what's called

a shunt measurement and that's
what I have on this slide right here.

So you have the blue signal is now
actually the power consumption. And so now

you can actually look and see what's
happening. So the first thing that happens

is we have the execution of the BootROM.
You can see in the power consumption curve

you can clearly see this moment in time.
Then you have basically where the flash

and option bytes actually get read
somewhat at least within the BootROM. And

finally the third distinctive moment in
time is where the application actually

begins to execute. So now we've taken this
1.8 milliseconds which is a

relatively long time and reduced it to 200
microseconds. We're actually interested

in. And not only that we know that we're
actually interested in having slightly

higher power consumption than the normal
execution of the bootloader or the BootROM

rather and this is somewhere between
let's say 170 microseconds and 200

microseconds. So this is the time at which
we actually need to glitch and this is

also reasonable parameters. If you're
trying to reproduce this at home. So what

do you need to reproduce this thing. So I.
The greatest thing that came out in the

last couple of years is the these cheap
Chinese power supplies where you take a

cheap you know old wall wart from one of
your old Linksys routers you plug it in

and then you actually have a controllable
power supply with with voltage and current

and you can adjust this and control this.
And so that's what we're using here. The

second thing that I have to actually

control the timing is an FPGA. I mean I
use FPGA's for everything and this is

something that was easiest to put together
with an FPGA because FPGAs have constant

timing. So finally we have a multiplexer
there as well and the multiplexers are

actually switching between two voltages
between ground so completely cutting the

voltage off and the normal operating
voltage of the microcontroller. And

finally we have a debugger, the J-link
which is highly advised if you want to

ever do Jtag stuff. So it's just a Jtag
debugger and basically what happens is

you let this run for a while and it looks
like this. It's not really super eventful

so you can see that the voltage the yellow
signal is actually the voltage and you can

see we're just dipping the voltage at
different points in time and

simultaneously we have a python script
checking if we have Jtag access or not.

Protip to all the new dads if you do this
at home you can turn your oscilloscope

towards the door, so that when you get up
at night because the baby's crying, you

can see if it's still running or not. So
it's very, it's highly advised. So now

Thomas is going to tell us how to get the
seed into into RAM.

Thomas: So we had this thing running for
3 months roughly across 3

continents because Josh is in America,
Dmitry is in Russia and I'm in Germany and

so it took us 3 months to get a
successful glitch and even then we didn't

believe it at first because we exhausted
everything basically. And the only reason

we finally got it working is that we did a
mistake where we misstook 70 ms with

170 ms and had it run for a long time. And
that's how we found out that the BootROM

is actually super slow to boot on this
device. And once we had this downgrade

from RDP2 to RDP1, we were able to read
the RAM, but we cannot read the flash

which actually contains the seed. And so
how do we find this? And our idea was we

start reviewing the upgrade procedure
because on the Trezor, the way the

bootloader works is, it doesn't require a
PIN or anything to upgrade the firmware,

which makes sense, because let's say you
have a bug in the pin function you want to

somehow be able to get rid of it, right?
And the other thing is if you flash a

fully valid firmware it retains the data,
it retains your seed. if you flash and not

genuine one. It actually will erase your
seed and so on. And the big, and they do a

really good job on the firmware
verification. We reviewed it for days and

days and days and didn't find anything.
But so how does this upgrade procedure

work? how is this seat retained? And so
when you reviewed the relevant code you

see that there is a call to backup
metadata which sounds like it's going to

retain somehow your data. And indeed you
can see that it's literally a mem-copy

from the data on flash we're interested
into RAM. And so our basic procedure

was, we go into bootloader we start the
firmware upgrade and we stop it before the

RAM gets cleared. Because if you finish
the upgrade procedure, the Trezor actually

clears its memory again, which is a very
decent way to do it. But we've found a way

to retain it in RAM. So it turns out that
when you start the firmware upgrade

process, it eventually asks you to verify
to check some of what you just flashed and

it turns out that at this point in time,
the seed is still in RAM and we can read

it out via RDP2. And this is relatively
simple to do once you actually manage to

glitch the device. You basically just run
openocd dump_image, you get an image of

the SRAM and you have the whole RAM
contents and so.

Dmitry: What are we going to do,Thomas?
What high tech hacking tool will be using

today to extract the seed?
Thomas:So we actually before we were

successful, we had hours of talks on the
how do we, how is this seed stored and so

on. But we've found this super
sophisticated seed extraction tool that

only runs on POSIX and POSIX-like systems,
it's called strings.

Laughter
And so basically it turns out that when

you have a firmware dump as we have RAM
dump as we do now, and we go to we just

run strings on the dump. We get a couple
of really nice words and I don't know if

you remember the intro, but this is your
seeds.

Applause
And you might be wondering what this

little number is. This is your pin to the
device.

Laughters
That was a great day. And so Josh, or one

of Josh's employees took all this mess we
created on all desks and made it into this

nice device which is basically a socket
where you put in your chip and then we can

read out the seed and so on.
Dmitry: And all of this stuff including

the board design, FPGA codes, and the
Verilog code that we use, I mean if

somebody wants to, they can apply it and
do the same thing with one of the ICEPICKs

or one of the more open source friendly
FPGA boards. This just happens to be the

one that we all had lying around and could
reproduce the work with. You can go ahead

and do it. I mean we suspect, I think
Thomas said, we suspect you might be able

to do with Arduino as well, because the
actual glitch pulse is only approximately

60 μs or sorry, 6 μs in time. So it's a
relatively slow signal as well, so it

should be relatively repeatable even with
something cheaper than this. But this is a

way to automate this even better and to
not have dangling wires or any of the

small soldering that was required to do it
in situ in the device which we had on the

previous slide. So all of that we're going
to have it on GIthub. And so I think the

final, the final thing.
Thomas: one more thing before we are,

sorry. One more thing. So this breaks a
lot of the Trezor security, but there is

a way to protect your seed against this,
So if you use a passphrase on your device,

the way we understood it, it basically
doesn't allows somebody with hardware

access to steal all your funds. So if you
add a passphrase to your Trezor, a good

passphrase and your machine is not already
owned you can somehow somewhat protect

against this. But a lot of people don't.
So we are really sorry we didn't mean any

harm.
Dmitry: So yeah, that's the conclusion I

would say. So yeah I mean, so all the
stuff we're going to put online, I guess I

said, so you can follow us for the links
on the online. wallet.fail, it's a domain

name, believe it or not, fail is a TLD. So
you can go to github.com/walletfail,

twitter.com/walletfail. You can follow me,
Thomas, and Josh on Twitter as well and

like I said, we'll be releasing all this
stuff so it will go up slowly. Just

because I think when we set out six months
ago we did not expect us to have 100

percent success in everything that we were
planning to do. so that's a first for me

at the very least.
Thomas: The saddest part is that we have

more vulnerabilities to other wallets,
but, only one hour. And so we also have

some stuff to give out so we have the
hardware implant PCBs, we have thousands

of them if you want to get some.
Dmitry: Off to Josh.

Thomas: We even have components for them
for like 100 devices so hit us up and we

can do something. Thank you.

Applause

Herald: Thank you guys, it's an amazing
talk. I feel really inspired to break

things apart in a very creative way. We
have some time left for questions. So if

you have questions, please line up at the
microphones. But first we're going to

start with a question from the Internet.

Signal Angel: Thank you,
I've got two related

questions from the internet. First one,
how hard did you guys laugh when bitify

announced that their Android-based wallet
was unhackable? And second question, have

you had a try to attack larger processors
like ARM-based processors?

Thomas: So maybe let's start with Bitfi.
So we only talk about somewhat secure

wallets, we didn't want to use a Chinese
phone in this talk. So we laughed pretty

hard and we ordered some, but yeah.
Dmitry: And I mean this was covered

extensively. So another guy who you should
follow on Twitter @cybergibbons gave a

talk at hardwear.io on the topic of the
Bitfi. He was summarizing research that

he did in conjunction with a bunch of
other people as well. So if you're

interested in the Bitfi you should go look
at them.

So the second question was about ARM-based

controllers. I mean all of these were
ARM-based. Every single chip as far as I

know that we looked at was was ARM-based
in one way or another.

Thomas: Yeah and there's,

so if you're interested in this, look at
glitching the Nintendo Switch where they

glitch the Tegra used in the Nintendo
Switch, which is very interesting and will

give a lot of inspiration in that
regard, basically.

Herald: Thank you. A question for
microphone 4 please.

Mic 4: Hi, Trezor CPO here, first thank
you for the talk, we worked with you to

fix the issues as soon as are recommend to
prod and if anyone interested in hacking

hardware wallets, we are really interested
in working with the hardware hackers

community and we have a
responsible disclosure program.

you mentioned problems with supply chain
attacks, but gave no solutions, so let me

give you one. Trezor is open source
hardware so you can build your own

from locally sourced components

and if you are paranoid and don't want to
deal with these kind of attacks.

but my question is, is there any
other solution except for building

your own wallet or inspecting
the code to run and

interrogate about basically?

Thomas: First Thank you. One thing we
should mention is that when we looked at

the Trezor code, the reason we had to end
up glitching this chip for three months is

that we couldn't break the firmware
otherwise. So they do a great job. And

it's really awesome.
Applause

Dmitry: Yes. The firmware on the Trezor is
something to look at. I mean I recommend

that, I mean we all do consulting work as
well. And so it's something that I

recommend that people who are interested
in looking at how to prevent certain doom

mitigations and hardware. It's an
excellent project to look at. And so

Trezor should be commended on that. But at
the end of the day it doesn't mean that

the chip that the Trezor uses is secure
against these kinds of attacks. And that's

where we had a fallback to looking for
silicon vulnerabilities against a chip

or, sorry, a wallet like the Trezor.

Josh: I would say on this hygeine side,

this is a very difficult problem,
governments especially have this issue.

You can do cryptographic attestation, but
as we saw with the Ledger nano,

that cryptographic attestation didn't help
verify that the requests were legitimate

against a hardware attack, so there's been
talk about X-raying the board and all this

stuff, but this is still very much an
open problem in hardware security.

Herald: Another question from microphone
3.

Mic: Actually I have a suggestion.
Herald: Make it short, though. Because

usually we just take questions. One
sentence.

Mic: A few MCUs actually have Jtag
connected via hardware fuses.

So this might be useful

at least slow down glitching attacks.
Dmitry: Thanks. I agree. But these are

not Cortex-M microcontrollers I can tell
you that with 100% certainty. It has to do

a lot with the fact that the
microcontrollers that are being used in

these devices, they're built to spec to
the spec that ARM specified that ARM

thinks would be a good set of features for
this class of device or rather for the for

the CPUs for the class of device that they
ended up getting put in. So anything

Cortex-M is gonna to have vulnerabilities
that are more or less like the silicon

vulnerabilities that we have. It's just I
mean if you ask me I think it's a matter

of time just to sit there. I mean
fortunately we had something like 3 months

of just glitching to be able to find find
these bugs. But if you can apply that much

to find it silicon attack you might be
able to find this kind of vulnerability as

well in other Cortex-M products. Only
three minutes.

Herald: All good. Another question from
microphone 4 please.

Mic 4: So obviously as part of your work
you analyzed the firmware of these

devices. Did you find that the firmware
is in any way obfuscated or encrypted?

Thomas: So basically yep, on these chips
you cannot really encrypt the firmware. On

the ST31 you can encrypt it. But we didn't
have to look at it because the ST31 is not

something you have to break but so no
there was no real obfuscation that we

could see. But we also don't have the code
in the case of letters so I just stared at

IDA pro for hours and yeah.
Herald: The next person on microphone 4.

Mic 4: Hello, did you have a look at the
entropy chip that generates the master

seeds on both of these hardware devices,
and what's your take on that?

Dmitry: I mean, so we already hovered how
the Trezor works. There is only one chip

and it's the STM32 so I know that there
was a known issue with Trezor back in the

day where they weren't seeding the
basically the RNG correctly. But this was

fixed. But for our attacks this wasn't
this wasn't an issue. I mean if you were

concerned about how strong these are, how
strong the random number generators are

for creating a seed you could actually
create a BIP39 wallet outside of any

one of these and then just use them for
their hardware features and get the seed

from outside.
Herald: And if you have a question, do

move to the microphone if you're able to.
But first we have another question from

the Internet.
SA: Thank you. Did you guys see the

dinosaur hiphop zero wallet?
Thomas: No but if you send it to us

we are happy to look at it.
Thomas: Oh you did.

Dmitry: Yeah, we had the it
Josh: The dinosaur hiphop wallet -

Thank you for the kind of trick questions
- So the design of the dinosaur hiphop

wallet was a trezor clone
that we looked at last year.

Thomas: Ah
Josh: Called breaking bitcoin board

so that if we didn't, otherwise
functionally it's a trezor clone

but we stole a lot of the instructions
from dinosaur hiphop

make the breaking bitcoin board
and then prepare the operating system.

Dmitry: I mean, and maybe on that note
I would say that in terms of looking at

what wallets are actually be used you'll
find that, so the Ledger is a very popular

wallet, the Trezor is a very popular

wallet. But since the Trezor is opensource
there is a lot of clones and forks of the

Trezor. And when I say that not all of
them run the latest security patches that

have been applied to the Trezor code base.
So that's also something that you can do

is basically diff the projects and see
which one of them which ones are staying

up to date and which aren't.

Herald: Your question has to be the very
last one today.

Please speak directly into the microphone.
Even closer to the mic.

Mic: Seeing as this is the first CCC for
many of us and some of us might not have

that much experience in hardware hacking.
Do you have any tips for beginners?

Thomas: Yeah lots of them. Buy an Arduino
learn what mistakes you do with it and

learn how hardware works, basically. Watch
a lot of online videos and I think you

gave presentations, you gave
presentations. I gave some presentations.

So just watch talks, watch LiveOverflow.
LiveOverflow, great YouTube channel on

exactly this stuff. And also don't
hesitate to reach out to us. If you have a

question. Always contact us
[e-mail], on Twitter, wherever. we

are happy to talk to you. It might take a
while.

Josh: On non-security electronics, if you
go to Sparkfun or Adafruit, they have lots

of free material of how electronics work,
how to get started. It's not security

related, but it's a very good
electronics program

Dmitry: But I'll say I started
with Arduino too.

Herald: All right thank you guys so much
for the very nice questions and you guys

for the amazing and inspiring talk.
Thank you so much.

Applause

Subtitles created by c3subtitles.de
in the years 2018-2020. Join, and help us!