Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/847 Thanks!
All right, now, it's my very
great pleasure to introduce Dominique and
Kate, who are going to talk about open
and closed systems with college kids, and
they brought a bunch of interesting
looking electronics with them.
And I'm very curious to hear
how they are going to help us liberate
all our devices.
So please give a warm welcome to
Dominique and Kate.
Thank you.
There we go.
All right, I'm Dominic.
This is Kate.
These are our faces
and Twitter handles.
If you want to
live, tweet about how terrible this is.
Right.
I work for Guarisco gadgets and mostly I
work on software and firmware
for embedded devices, things like Hacker
Great Fat over to
explain who you are.
Hopefully the microphone is working
perfect. So I'm not
really in the infosec scene.
I'm more of a reverse engineer.
So I maintain projects especially
that lets you get more information about
systems and see inside them.
I especially love things that help people
to learn about different
systems and kind of get a foot in the
door in various things.
Face cancer, for example, is something
I maintain the newer version of and that
lets people get their fingers into USB
great. We both maintain
and that's a multi tool that lets people
get their fingers into all different
kinds of things.
So we're coming up this
talk from the perspective
of people who really are
neither of us really are infosec people.
I think you say you write software for a
living. Yeah, exactly.
I do reverse engineering, which is kind
of on the periphery of the core, like
hacking culture kind
of thing.
And really what we're here to talk about
today is a tool that we built that helps
people do things like reverse engineering
and learning about systems more
effectively.
So most of what we build is is
interesting tools to to open up things.
And then we we rely on the idea that
other people will pick up those tools and
do really interesting security things
with them. So
naturally, if we want other people to
pick up our tools, it seems to make sense
that we make most of them open source and
available to people.
And in that spirit, that we'd like
a couple of people up front,
Mike or Elizabeth Scott Scanline.
She does some fantastic reverse
engineering work and is very
good at explaining things.
If you haven't seen her streams and
YouTube videos and things, you should
absolutely check them out.
And there's some stuff in this
presentation that that was directly
inspired by her work.
Colin O'Flynn has done an awful lot of
really interesting glitching work and
taught people about that over the past
couple of years.
And also we should think great school
gadgets, because they do
enable us to come and attend events like
this and spend all time working on these
things. Right. And so in this talk, we're
not really the you know, the brilliant
people doing anything that's absolutely
earthshattering. We're not coming up with
new, you know, techniques
that enable you to, like, sit on the
cutting edge of science.
But instead, we're tool builders.
We build things that let you do cool
things.
And so we kind of have like the
foundational people who have, you know,
kind of started blazing some of these
past forward. And we're building on a lot
of their work.
So, yeah.
And I mean, the reason that the first
to enlist is people who are smarter than
us is I try to I actually try
to pick up Cohn's work and it's
fantastic.
His ship was really cool.
The software is kind of great.
And I knew nothing about glitching.
And I think we got into a conversation
about, like, this stuff's really
cool. But like, wouldn't it be great
if someone who's not a genius,
like someone like me can pick it up and
like Glimcher system.
And so that's that's kind of where this
project came from. It's just trying to
make those things just a little bit more
accessible, a little bit easier for
everyone to use so much
right now. A lot of this came out of
conversations with those first two
people. So, yeah, it's really awesome.
I really appreciate the foundation
they built. So kind of give you
background for why we're doing this kind
of thing. This is a
circuit board for an HDMI switch.
Nothing super special about it other than
the fact that I was using it a few months
ago. And it was incredibly
it had an incredibly irritating flaw in
that. Sometimes when you're doing
something like playing a video game or
watching TV, it would sometimes flicker
on and off.
And so naturally, I did what anyone
does when their electronics stop working
and they took it.
You know, I took it apart, figured out
what the problem was.
In this case. It was all the little
signals, the plug to plug detect
signals that tell you whether they're
HDMI cables,
what the cables are present and plugged
in. The signals
that indicated presence actually had a
little bit of noise on them and the
system wasn't properly compensating for
that noise. So every once in a while, a
cable that didn't put it, that didn't
have a cable plugged in, would suddenly
see a cable for just a split second
and it would try to automatically switch
over to that input.
And this device happens
to be driven by an intel 1851
are equivalent microcontroller, a
derivative microcontroller.
And if I had the firmware for that
microcontroller, it would have been
probably ten minutes of work to,
you know, put a little bit of bouncing,
put a little bit of noise filtering into
that system and be able
to have fixed this and have this work.
But without the firmware and without this
kind of thing, it's the kind of thing we
have to start off by rewriting
the firmware from scratch or
coming up. With some other hacks, some
analog filtering under to make this thing
work, or as I did by a slightly
better HDMI switch, yes,
sometimes the solution is to build a
glitching framework, and sometimes the
solution is to spend 50 bucks and
really play with each other both.
Here's another device that
I was messing around with a little while
ago. This device is the inside of a
thermal camera, so it's the third
on 65. It's a relatively inexpensive
something like 200 or 300 USD
thermal camera.
And it's actually a really cool piece of
electronics. It's got an
SD card and my credit card that
it captures pictures onto, it's got a USB
port that it uses only to upload these
pictures to computers.
And then it's got a pretty powerful,
pretty large microcontroller on there.
And it would be really lovely to use a
board like this for all kinds of, you
know, experiments where you could take
in thermal data and pass it to a PC.
But the designers of this didn't
really think about that use case, didn't
identify that as a use case they were
interested in.
And so despite the fact that you have
this giant microcontroller with 512
kilobytes of flash, of which it was only
using something about 100 kilobytes,
there's without the firmware that
is on this device, you can't really do
that much.
And so luckily, this particular device
has its firmware in a
accessible format because it takes
firmware updates over USB.
And if you look at the file that they
upload onto the onto
this device, it has what looks
very clearly like an arm cortex and
vector table at the beginning.
But that's not the only thing that's in
this file. There's also some metadata in
the beginning and scattered throughout
this file. And unless you want
to sit there guessing at what the
metadata means, you know, like what kind
of checksum is this? What kind of CRC
could this be?
Is this, you know, a length here that
describes how much firmware there is
before there's another blob?
Unless you want to guess at those kind of
things, you're kind of not even able to
upload new firmware to the bootloader.
Right. The bootloader itself that on
there, that's not contained in those
firmware update images.
It knows what is used to
actually talk to it and to upload
things onto there.
And so if you have this bootloader, if
you're able to get the order out somehow,
then you can easily go reverse engineer
the code and figure out what the actual
structure that metadata is.
And though I didn't actually
get the letter out by glitching,
eventually I figured out the format was
able to find another vulnerability
and then get the bullet out via
some simpler exploits.
This device was able to be hacked and
there's tools for it.
And it would've been a lot easier to do
that if we had the ability to get the
bullet out almost immediately.
I'm going to you slightly here now.
Oh, wow, I get to play with this very
responsibility.
Excellent. All right, click, click,
click.
So not all, but
many, many security
issues that we have come from us making
assumptions and those assumptions not
being valid, such as,
oh, let Dominic wrote the code.
He knows how to code that assumption.
Things like string copy, like
string copy is like generally known to be
a pretty bad idea.
If you're not giving it a Lynnfield,
if you if you use that like
you have no way to know how long your
input was and it's going to just be
copied all over your stack.
And I hear from some hackers that that's
bad.
On the right hand side here, there's a
paper by Serguei
and Jilian about Pulsers.
And we have this concept
that if we design a file format, that
those the two people build a parser
for that very well defined file format,
that those policies will treat things the
same way. And it turns out people are
very bad at coming up with unambiguous
file formats. And so and I pulsers
about now,
it turns out you do exactly the same
thing in hardware.
One of the things you do is you have to
make an assumption that if in
the data sheet you say power
this chip with a voltage of between
this and this, you kind of have to make
the assumption that that
power supply is stable and that power
supply is constant and the same goes for
the clock. You make this assumption that
as long as the clock speed is within
your valid range, everything should
should work properly.
And you kind of have to make this assumption
that the the clock is not going to,
you know, go away or change dramatically
or the power is going to increase or
lower dramatically.
And this is where glitching comes
in, because what we do is we support
those assumptions and are able to use
them to
to to change the behavior of a part.
Right. And so we're able to secure
systems usually by identifying
the assumptions we make and constraining
those assumptions so we can do things
like, say, I'm not going to assume that
the user is handing me a nice, null,
terminated string that fits nicely in my
buffer.
It's a lot harder to build a chip that
behaves correctly when you start pulling
its power away for a period of time, it
really drives up the cost of your chip.
Same thing with the clock.
You start having these kind of fundamental
assumptions. It's really not worth coming
up. Solutions are
not worth constraining your device to
necessarily have to work without power or
without a stable clock.
And so when you start subverting these
assumptions, just like when you separate
the assumptions of someone designing
software, you get all kinds of
interesting and potentially exploitable
behaviors.
Yeah, and I think at that point you
touched on, which is that there are
methods for for avoiding this.
They absolutely exist, but they're
expensive. They they
add complexity to the to the part
you're using. They add it cost.
And what you end up with is much more
expensive microcontrollers, which
then means you're not going to get your,
you know, dirt cheap AI,
Internet connected camera or whatever
other like cheap Iot
rubbish that you buy is going to go
up in price. And the manufacturers
want to use the lowest cost thing.
So like the vast majority
of of parts that we see out there, like
don't have any of those kind of
protections on them, or can you just like
like a kind of logo.
So it's kind of quick show of
hands who has like knows how glitching
works, has glitched something before.
I can't really see because they're a
huge stage lights, but I don't think
that's a huge percentage of the audience.
So I was in everyone else's shoes
up until very recently.
And so I'm going to try and give you an
explanation. And then when I do it badly,
Kate is going to fill in the gaps.
But essentially there are there are two
key types that we're going to be talking
about. And the the a lot of people use,
one is glitching and the other is is
power or voltage switching
with with clock watching.
What you do is you take this nice
as one of these a laser.
Well, that is almost invisible to me,
so good luck to you, OK?
What you have is you have these nice
clock pulses that you can you can see on
the slides. And they
the the I think the way
a lot of people visualize what happens
inside a processor when
the clock signal comes on, it's like
everything happens as soon as that clock
pulse happens.
But realistically, what happens is
those things happen in stages.
So first of all, maybe we increment the
program counter and then we go and decode
the instruction that we're pointing to
and then we work out what that's
going to do and maybe implement like, you
know, if an ad is not necessarily in
stages. But in parallel, we have all the
intermediary pieces of those computations
coming together.
Right. So here we get to see
if we were to take a look inside the
circuit. We see all these different
pieces working kind of together,
coming up with different pieces of the
computation. And then finally, right
before the next clock edge or some period
of time before the next clock, everything
resolves to a stable state.
Right.
Thank you.
But but
what happens if we if we shorten that
clock posts and we we
bring the clock line back down
midway through that, can we can we make
it so that maybe the sum of that
conversation happens, but other parts
don't happen? And spoilers, the answer is
yes.
And so we can do things like have the
the instruction, the instruction
point to increments and
then the next the result of whatever
the next piece of computation is, doesn't
go anywhere. It just doesn't happen.
And then on the next pulse,
the program counter is exactly where
where it was. But the previous
instruction didn't happen.
So if that previous instruction is a
jump, we've now just moved over it
in the code
happy and move on.
Excellent.
This is the one that I don't know as
well.
Right. Volta's grouching.
So inside the chip are a lot of
transistors.
Yeah. This is Mike.
You know, I know a little bit
more.
I don't do hardware,
so there's lot of transistors.
And they when they're when they're
stable, when they're not switching, they
have they they draw very little power.
Right. OK, I'm
sorry that I have to keep checking it.
I just don't want to get it wrong.
But when they are switching, they draw,
they draw a lot more power. And so the
idea being that that they're fairly
stable, if you can make it so that when
they're switching, you rapidly
change very briefly change
the voltage that you're supplying to the
chip, you will very
great. You have a much better chance of
influencing them in a way that
does unintended.
So if we suddenly drop the power
on a chip as it's calculating,
say, the final stage
of a checksum or something like that.
Yeah, but then it's
much more likely that those values will
come out incorrectly.
Right. And so the take away here is that
if you have a portion of the chip that is
making some kind of computational
change, then that's changing state.
And you were to suddenly deprive the chip
of the energy it needs.
Those pieces are much more likely to be
affected by the
rapid brownout, the rapid dropping of
voltage then pieces that
are in steady state.
Right. If the chips are not doing
anything and you move its power supply
around, it's not actually going to have
that much effect. It's only the things
that are changing right now.
So the register, the value that it's
currently writing or or something like
that is much more likely or the value
that's currently calculating is much more
likely to change at the point that you
you move that that power to.
We got through that, okay?
Does anyone genuinely feel more informed
than they did two slides ago,
how it would be much more flattering if
it wasn't my employer.
So here's some pseudocode.
This is this is just something.
Let's say we've got a buffer.
We want to send that buffer somewhere.
We have a function called send bytes.
And we it's right over that buffer zone
nearby. I've written code like that on
the left, I imagine many people here
have. And this might be what it looks
like when it's compiled.
So let's say that
what we really want to do is send out
that buffer, but we want to
subvert the system to
to send out everything that comes after
that buffer zone to send out the rest of
ramp.
Now, there are a couple of things here, a
couple of steps in this in this program
which might be of interest to
us. And before we did this disclaimer,
this is all pseudocode.
So this is assembly that I wrote to be
representative on a plan.
I think it's a weird mix that I come up
with between like a risk processor
in 1851, because that's how it was
natural to express this particular
thought.
But I think this is something that people
who are familiar with the assembly could
understand.
Excellent. All right.
So this is written in Temkin Micro
Architecture.
So first up, what we do is we we
multiply, we multiply.
This works better on a black background.
We do this multiply to to work out the
size of a list.
If we could modify that in some way, we
could get a field that's way, way bigger
than than the Lynnfield that we're
supposed to. And and so therefore
so when when we compare in this, we're
going to get much more alternately
every time we go around the loop, we we
decrement the length.
If we can make this
decrement fail
or happen in a in a strange
way, we might be able to
get a much bigger number loaded into
the Lynnfield.
And therefore, again, we get a lot right
now. And the final one is this.
This jump, if we can make that jump
get skipped, then
the length will already be in decrements.
Next time around the loop, the length
will become negative one.
And we'll just keep documenting the loop
until we run out of until we
we loop through that entire integer
again. And so we have these opportunities
that we can if we are capable of
corrupting values or we're capable of
skipping instructions, we have these kind
of windows that we can use to
see things that are past that buffer in
memory. And depending on the individual
device and what you're sending out, that
could be transmission from
something and read only memory and you
could get what's next after that
read-only memory, which might be
firmware, might be secrets if
it's in RAM, potentially
with other values that the device
may not want to disclose.
And we'll see in more complex
cases that we can actually take advantage
of this to get more than just the data
that's immediately following in RAM.
But the key is that that timing is
absolutely critical.
In order to be able to do this, we need
to be able to we don't necessarily know
at what point exactly the device is going
to be vulnerable. We can kind of guess
here that it's in those instructions in
red that we're likely to have the effects
we want. But we don't know when during
those clock cycles, we might want
a glitch. We don't necessarily know
what kind of glitches they're going to be
effective or if any, are going to be
effective on a given system.
So in order to do that, we need to be
able to experiment and in order to be
able to experiment and have those
experimental results mean anything, we
really need a very precise
way of identifying time
as is relative to the thing
that is executing the program itself.
Yeah, so this diagram just kind of shows
that like this red line here, these are
all the options. We have to have a
successful switching attack.
And it's you know, it's fairly spread
out, but there are a lot of them.
So this is the multiply.
We've got one chance of that.
Then then this kind of decrement happens
every time around the loop.
And we always we have lots of chances to
to hit that one each time.
And then finally, we have
this this jump when
when we finish the loop.
And we only have one chance of
really skipping that step as
well, because there's only one time that
that jump is meaningful and that's when
we hit zero.
Right. And so this may seem pretty
synthetic. No, go ahead.
So this may seem pretty synthetic.
That may seem like the kind of code that
you'd hopefully not see in a lot of
programs, depending on the use case and
depending on the constraints.
But this is exactly the way in hardware,
a DMA control that works, right?
It is constantly subtracting from
its length register by one or more.
It is constantly incrementing the address
that it is reading from the address
of sending down the bus in order to
gather data. So even if that's software,
for example, looked a bit synthetic, it
is absolutely applicable to embedded
hardware.
Yeah, and there's absolutely no error
checking because what I mean, you've
got a damage control on it, on a
microcontroller.
What's it going to do when errors like
it pop up a dialog that says, hey,
something's gone wrong or you're not
writing to the right bit of memory, it's
just doing what it's told.
So we've we've done a lot that this
isn't.
This isn't like a super
clever attack against something.
This is a little Python script
that hacked up, which talks
to the DMA controller on a great Seibold.
This connects to the system and just
allows us all it does is take the
parameters. We give it in programing
programs into the DMA controller.
And I'm not specifically obviously
43, 43, 30.
Yeah, this is not something that you're
going to see in every damn controller,
but on a lot of the embedded DMA
controllers error checking is a premium
feature and has left out a lot of the
individual peripherals that use DMA.
So the CPU itself may execute on the
boss, execute transactions and get
notified if it requests memory that
doesn't exist.
A lot of times a DMA controller will have
absolutely no error checking just
because there's no way to handle errors
when hardware is executing them.
So it won't stop transactions, it won't
generate a fault, it won't generated
interrupt is just happy to do things like
read all zeros.
Right. And so this is the thing I just
read a section of memory that
I know is Ram and I write 128
bytes out of it and it and it gave it to
me. But if I were to do the same thing
again and read what address you
want to read.
Like the three zero zero
zero zero zero zero zero, but
you do that, but
there are sections of memory that don't
mean anything. That memory that's I oh
they were just like reserve sections that
don't exist. And it doesn't erase all
the damage control. Like we're just
representing on screen exactly what the
damage control is giving us back.
And when it has when it gets nothing
back over the bus, it so says to memory,
hey, I'd like to read this this value and
the various peripherals.
No one no one responds under my control.
So I guess it zeros them and it just
keeps going. And so if we can convince a
controller to to
read a section of RAM and just keep
going, it will just read us zeros
until it runs out, until its
counter overflows.
And then I'll just start again at the
bottom of RAM sometimes.
And so and so we can just keep reading.
As long as we can get the DMA control to
do the thing we want, we can get
it to keep reading us out.
And this is really cool because if you
actually go and ask it for an address
that is all the way at the end of RAM,
this particular microcontroller has a 32
bit address space.
And if I say I want the absolute last
bite that's in outer space and one
hundred and twenty seven bytes following
it, it will happily read that last bite
and then the 127 Bytes
it gets when in increments that last
address and rolls back around to
zero. Yeah, this gives us an almost
unlimited opportunity if we're willing to
read absurd amounts of data to explore
the address space and if we happen
to for example, corrupt the length field
that's supposed to have a value of ten
and is thirty two feet long and we get
something that's really, really, really
long, there's chances that we're going
to get things that are after
that in memory wrapping back around and
starting again.
Yeah, exactly. So if we do manage to take
the 32 bit landfilled and.
Glitch, it's become negative on jump that
jump that comparison to zero,
and it's been a negative one, it will
continue reading all the way all around
until that integer loops, which
happens to be about the point that memory
loops on this thing. So like we get
all of them
describe that the chip was so one
of the foundational pieces of technology
we are using.
We're facing a lot of our work on is the
chip whisperer.
So pictured is the chip whisperer light,
which is the inexperienced, inexpensive
variant of Colleano friends
glitching tool kit.
And this is a tool kit that lets you do
some power side channel analysis and
some basic glitching attacks.
It has modules for clock glitching and
for power glitching so we can implement
both of those two kinds of attacks.
And it provides software
and firmware on a microcontroller and
FPGA that are designed to let you
precisely timed glitches relative
to some known synchronization point.
But that synchronization point has to be
specified for the chip whisperer.
So the chip whisper light has only the
capability to synchronize to a single
rising edge or a single level
triggered event.
So it can't go and say,
I want to time this to, for example, a
USB communication or to a in
communication. It can only say
tell me when something happens
in the house by building your own piece
of hardware and having that hardware
indicate to me that something's
happening. Yes.
So what we want to do is we want to be
able to tie that that, you know, Demay
something that's using the DMA controller
and determining
that that length value or whatever to
to the chip whisperer, where we want to
just be able to say, yeah, go for it,
glitch now. And so we we want to tie
those two things together.
And we did.
So if you look at a typical
microcontroller datasheet, what you see
is something on this these lines,
the all the little boxes
around that side of peripherals that
implement various protocols and things
like that. We've got you arts.
We've got a USB somewhere on
here. We've got ATCs
and DAX. This thing up here
is a high stakes right thing.
The challenge protocols that you might
want to speak. So the challenges and
attackers, if I take a device that
has a lot of these busses populated, I
take a board that is using you, Saaz,
and you are using USB
and it's using the port and it's
connected to an EMC card.
If I want to start breaking into that
device, I have to build purpose-built
triggering hardware right now that is
capable of identifying exactly when
those individual peripherals are being
used and for what.
So in order to synchronize up with this,
I have to go and build purpose-built
pieces of hardware to test on an attack
that I'm not even sure is necessarily
going to work. And it would be a lot
nicer to be able to, instead of having
to build that purpose built hardware,
have some kind of tool kit that provides
a lot of those missing pieces that you
can actually go and say, hmm, I wonder
if attacking USB is going to work.
Let me try USB today.
OK, this premade tool kit is showing
me that USB seems to be a good option.
You know, 12 hours later when you run
for a while, I seem to have some
interesting behavior. Let me go more
into more depth with USB.
Yeah.
So this is where Glenturret comes in.
This is something that that we've been
working on over the past couple of
months, and it ties
together a lot of these features that we
that we want to use.
It ties together
various different like it ties together
synchronization, features of.
Do you wanna go into this now?
Yeah.
So this is just an overall diagram of
what we're going to go into it in detail
in a second. Yes, that is that this is
our open source software tool kit with
that is designed to work with some
existing open source hardware, but
kind of bridges that gap and lets you go
from kind of having interest in exploring
a system to attacking that system as
quickly as you can.
You don't have to make some hardware
modifications to your target device,
but that's, you know, adding transistors
and rerouting wires instead of building
purpose built hardware in order to be
able to try testing those individuals,
putting those individual busses and often
the modifications that you make, our
modifications that are
actually useful across all of
those different busses, for example,
modifying the power supply, you can
switch its power to be useful no matter
which one of those busses you're trying
to attack with with
voltage pitching.
The goal is that you you know, we're not
trying to bring the amount of hardware
hacking you have to do down to zero
because that's virtually impossible in
this and with this technology.
But we're trying to take it from I've got
to spend two weeks like designing a
custom board, sending after a piece of
fab, getting it back, building this thing
with a compass to like a couple of hours.
OK, well, I've pulled off all the
decoupling capacitors and now I've hooked
up my hardware to it.
Now let's go and see if we can.
So just trying to produce that turnaround
time and make it easier, especially if
you want to have to design hardware.
So what we really need is something that
takes the influence, a bunch of these
different
these different peripherals and things
like that. So it seems like if we're
going to try and implement those, we
should just find out what part this
datasheet is from and and boil down to a
board, which turns out we already
did because we did this the other way
around.
And this is great.
That's one of my hand.
That's about this big for me for
scale.
It is.
It is a microcontroller board
that Mike Ossman designed.
Some guy here,
it's open source hardware.
It's it's like a breakout board to
build interesting modules to sit on top
of it, does various USB stuff
that we've spoken about before.
And it's you
can go build one yourself.
Right now, the designs are on GitHub.
And so this is this is my
controller here.
Kind of the way this board wound up
existing is that this was used
previously. And Kharif so really neat.
Yeah, we use this chip in Hacker F, and I
think Mike was written
at some point.
It's like this part's really cool.
I'd love to use some of the other
peripherals and I'd love to make it
easier for other people to use some of
these peripherals and and see how
and have easy access.
I want I want to to plug something into
my USB port and then I want to able to
speak or spy
or something directly.
And I want to be able to do all those
things on a single board. And that's kind
of what great and so great that provides
this place platform on which which you
can build on top of to add other
features. That is, add
on boards that are similar to shields
called neighbors that theoretically had
other you.
You had the name a little bit.
Thank Trevaskis Speed for that, but I
have no problem calling them neighbors.
I have a problem with the fact that I
spell neighbor differently to the rest of
my company.
So so let's step through let's step
through it one more thing.
Oh, I'm sorry. So when we talk about
Greifeld, we are talking about both that
board and other boards that are
compatible with it.
So if you have a radio badge
because you want to scan a few
years ago, 20, 15.
Yep, 15, then you already have a great
fit because the great software runs
currently on that.
And it's not the preferred form because
you can't stack those additional headers
on there. But it'll work just fine for
doing glitching, if you will.
Yeah. You remember a couple of GPO,
right, so that you when you bought
tickets now
anyway, so. Right.
Let's step through three KHK.
There are three main kind of sections of
this, this code.
First up, we've got an event router and
the event, Rita lets us
take various things that are happening in
our target hardware and combine
them in interesting ways.
So, you know, we've got a
you know, we're looking really quizzical
at me about this. I'm sorry.
So so maybe we want to,
you know, only bring out the power supply
when this other thing happens.
And we want to fiddle with
the clock in some way when this power
line goes goes high and we were able to
kind of connect those events and
make more complicated structures
of of the hardware
states to come and kind of task.
When you're using these devices, you're
trying to glitch devices, is to
get things synchronized
across a variety of tasks.
So you might, let's say, be attacking
a USB device where you need to apply
power and then wait for the system to
boot, wait for it to show you that the
controller on board has started up.
And then at that point, you're ready to
apply some stimulus in order to
generate an attack or you might have a
device that you need to power up and then
immediately provide a clock, which is
going to drive that device but don't want
to ride that clock before power is on.
Otherwise, you're driving it into a chip
that has no VXI, that's not supply rail.
So this event routing system is
kind of the heart of glitch kit and
it lets you take all these
different pieces of information, all
these pieces of stimulus and use them
to drive things like, all right, when
VXI turns on for the target board,
I also want to start a clock and then I
want to wait for the system to
appear to boot by moderating one of its
GPO and seeing one that goes high.
And then finally, when that happens, I
want to throw some stimulus at it.
And then finally, when that
stimulus has taken, I want to trigger
a glitch.
So that event routing system is what
connects all those individual pieces.
Now, we also have a clock management
section, which is the
bar which handles things like
making sure that all the individual
pieces of your system share a common
clock when you can.
This is a lot easier to get everything
synchronized up if they are executing on
the same time base.
So the clock management will take in an
external clock and allow the glitch get
hardware the Fed itself to
be.
They execute on the same clock as your
other your target or as the chip
whisperer, and so you can get all of the
chip whisper and the great fat pieces of
that stack synchronized up.
Yeah. And it'll also provide clocks to
things that are better off being
given an external clock so it
can then go and apply clocks and
theoretically in the future, modify the
clocks for clock clenching as if you're
using this particular path.
So it gives you the ability to buffer
clocks and spread them out throughout a
system without having to
necessarily build purpose built hardware
in order to ensure that the clock is
stable as it's being distributed.
I guess the question, if you if you're
going to do things that require
incredibly tight timing, it's useful to
be running from the same time so
we can have the chip whisperer board and
the great fat and whatever our target
device that we're trying to glitch or
running from the same clocks, that kind
of running in lockstep with each other so
that we know if we're trying to like if
we've got a time offset between, you
know, the star and when we do
that, that voltage, which we know that's
consistent across the board.
So the other thing you might want to do,
a lot of switching to
try and get the bootloader or something
might happen like, well, or doing
something weird to the bootloader might
happen super early on.
You might like turn on the chip and then
immediately try and do something after
a short couple of instruction delay or
something. But sometimes you
want to probe the hardware
and somehow you want it to boot up
normally and then you want to modify in
some method, some some
some style.
And so we can act as a USB host
and a USB device and
sometime in the future a
fast ship or any C E.M.S.
device. And so the idea being, you
know, maybe maybe the thing that I think
is actually going to be the the the
request to the device that I want to
glitch is like some some
USB command that has to happen
after we've enumerated the device.
So we've got like five or six USB
commands that need to go between the host
and the device before I can start sending
out this this command and then
trying to glitch it during that command.
And so what we're able to do is we're
able to bring up the device, a numerary
to get into the right state, send
it that command, and then immediately
tell the chip whisperer, hey, now's the
time to start watching.
Right. This gives you the ability to do
really precisely timed stimulation
of that device. So if you think that's a
vulnerable piece of code or a vulnerable
hardware function is only ever exercised
once you've received a certain command,
let's say, you know, I'm a USB device, I
have a capability self-described.
I'm only going to do that when you ask
for a descriptor.
You need to be able to go and start
poking that device and prodding it in
order to get it into a state where it's
doing the task that you think are
vulnerable.
And while you're doing that, you often
want to know what stimulus
are being applied and where they are in
time, because sometimes
the stimulus for triggering is I've just
asked it to respond to a given command.
So all these stimulus
modules both exist and
to move the device through, you know, a
given device into a given state
and exists that they can provide
inputs to the event routing system.
So you can do things like, say, turn on
USB bus and then send a command
and use those as inputs for
both for glitching and triggering
glitching and for generating
other events like turning on clocks.
Yeah, so, so by extending
the the the by
allowing us to kind of interact with the
device for longer and do more to change
the state of the device before we try and
attack it, we massively increase the
attack surface because we can now
we're not just going for for
a small subset of the
of the code that's running on the device
we're going for. We can, you know, start
to play around with all sorts of weird,
arbitrary USB functionality
of this thing because you don't
know which part of it is going to be the
most susceptible.
And there's a fair chance that the
descriptive stuff might be really
solidly written.
It might even be implemented like in
hardware on the peripheral, but like
those USB vendor request that someone's
like thrown together to, you know,
the day before, they have to ship this
piece of hardware. They might be written
in that slightly more sketchy style of,
yeah, let's just let's just decrement
an integer. And so there might be more
than one thing going on in the hardware
as a descriptor inside out.
And that makes it very difficult to
glitch, because if you start watching the
script to request, you might also knock
out something that is responsible
for the core functionality of the device.
And the device is memory, but it may go
down. Right. So being able to explore
a lot of that is really important.
Also worth noting, I think this is
probably the first pitch you've heard
today where we tell you that a project
massively increases the tax service.
So that's a plus major
benefit of
increasing your tax taxes.
OK, so so Triggerfish, this is this is
kind of where this, I guess, or came from
originally, is that one of the things we
wanted to do was be able to have these
kind of more complex methods for
deciding, OK, well.
So, for example, the simple event trigger
here, what it does is it allows us to
hook into a bunch of lines on the
on the target device and say, well, when
this thing happens five times and
these two lines are high and like this,
this line pulses, that's when you
trigger. And so this is kind of funk's
you can just hook up to like a spy chief
and you can say, well, I know this
thing's going to read like four
times when it starts up.
And then what I want to do is try and
like, klich it right after it does the
fourth read. And so all you do is you
hook up to like the enable line and
you say, well, when that happens
four times, that's when you trigger or
like get a more complex example.
A simple event triggers lets you take a
variety of just general boolean
conditions for input pins and
build complex conditionals out of them.
So common example, and I think the
the more complex thing that I was talking
before is I might have a
microcontroller that reads some
information of an external flash and
I might want to know where it is in that
read.
And I could go and build a whole S.P.I
peripheral and, you know, kind of fake
S.P.I flash chip and know that by
emulating the flash chip, I get this
insight. Or I could say, OK, I know that
this thing behaves the same way every
time the 4th read,
for thing it reads, it's always that
piece of information that I'm interested
in using as my time base.
So let me just say, OK, the
24th clock edge, here are the
30 second clock edge here.
While the chip by the chip enabled pin
is low, happens to be the thing that I'm
interested in triggering on.
And this doesn't necessarily have to be
the thing that generates that final digit
trigger. This can be the thing that
prompts you to, let's say, turn on the
system's clock, turn on the clock to the
right to hit another target device.
Or you can use that as a
time base to start executing some
stimulus. So when it gets to this point,
that's when I want to start sending it
USB packets.
Yeah. To science. And you might do that
because you won't want to apply power to
the device and then wait for it to come
up before you start trying to talk to it
over USB and and things like that.
And so you might just wait for, for
example, like those lines don't have to
be like complex chip chip interfaces.
You can just hook into one of the LEDs
and say, well, when this light comes on,
I know it's booted something
like that.
You are I don't really want to talk
about you up because I influenced it and
it currently doesn't compile.
But you are I mean, that's not
surprising.
You are it is is
like a pretty common kind of debug
interface that you're going to find.
Like if you just tear open one of those,
like, standard routers that you get from
your ISP, like that thing's got a
going to have a serial connection on it.
And so you might want to use that to work
out when it's bootloader has started up
or something like that because it will
dump some information
and then these things can be used.
The final thing is to then talk to the
chip whisperer and trigger some output
from it. So this is
a cool things. You can you can take that
trigger signal and you can trigger the
chip whisperer to start doing its
switching process.
Or if you want to, you can use that to
drive the trigger input to your
oscilloscope or logic analyzer.
So you can use this as a source of
debugging information outside of
glitching, even though it's not our main
purpose. So this
is a general purpose stimulus and
triggering engine that we happen to be
using for leeching.
So one of the kind of
pieces of work that happened a couple of
years ago before a couple of years ago,
before we are now, that was
kind of really inspiring for this was
done by my friend Maika, who
wanted to be able to take a USB tablet
that she had and
use it as
kind of a general code execution engine
to prove out an idea that she had,
which was that these things are
an awful lot like RFID
readers. And she kind of had the idea
that she wanted to be able to take this,
run her own firmware on it and
be able to
read an RFID token that was held really
close to the actual switching matrix of
this Blackcomb tablet.
This is the kind of thing that you
normally use with an inductive drawing
pen, the kind of thing where the pen has
no battery.
But by holding it close to the tablet,
it's able to receive power, modulate
the its load on that
switching matrix, and thus kind of
communicate a little bit of information
like, yes, I have a pen, I'm being
pressed this hard and that
kind of functionally looks a lot like an
RFID chip, which also does kind
of a load modulation.
So whereas the pen was receiving
power and then loading the power lines
more or less in order to communicate
where it was on a grid and communicate
how hard the nib was being pressed
and RFID takes power and then
just transmits back to that mode
modulation, a simple fixed ID.
And so she had kind of the idea that
those things could be as basically
the same pieces of hardware.
Just that pen in this case was a little
bit more complex.
And so she wanted to
be able to get some firmware execution on
this device.
But looking at it, she found that it had
a custom controller called an LC eighty
seven, which was a completely custom
architecture by or on semi.
And it.
How to debug interface exposed and on
that was completely undocumented, so she
wasn't able to extract the firmware in an
easy way. So what
you did, because she's like a thank
you.
What she did, because she she's super
devoted and really loves getting into
these kind of things, and she decided to
try to extract that from where by
taking advantage of the way
USB packets are sent and trying
some voltage switching techniques.
If you look at the way a USB.
Control request is set, it happens in
a few stages, first you send
it, a command
stage is called the set up stage, which
can contain the standard USB commands
that.
Forced compliant devices to describe
themselves so like a get descriptor
request will make a USB device
respond with some descriptor describing
its own functionality.
So when you plug in a USB device and it
says, you know, hello, yes, I'm a
I'm tablet, your operating
system knows that because it has the
the device first for its device
descriptor, which contains a vendor I.D.
and a product ID and a
couple of string descriptors that contain
that string. Yes, I'm awake.
I'm tablet, I'm a CD 450 and
in.
In order to be a compliant device, every
device has to be able to do some amount
of self-description and the way that's
usually executed is by taking
small pieces of data that are usually
either in RAM or in read-only memory
and just dumping them right out of the
device. So here we have
a get descriptor request that's
executing.
It has a single packet that is
transmitted back in response.
And then we have an acknowledgment that
package was indeed
received. So we have the host sending
get data. Please give me that descriptor.
We have the descriptor being transmitted
in response and the host says, yes, I got
this. Theoretically, he doesn't have to
be one packet in the center.
If the device decides to respond
with a very, very long packet, that
could also theoretically be valid.
So there might be multiple packets that
make up a longer transaction.
So let's say you want to send 512
bytes on a bus that has a maximum packet
length of 64 that could be packetized
and broken up into a lot of sequential
packets.
If you look at the way a USB
device works, it's often very similar to
a host controller in that it has
a linked list that contains
basically that amount of bytes to
transfer and then pointers
in memory to the pages that contain
the data that you want to send so
that you have a length and an address
here.
And if we look at the way I get the
script, a request might work for a long
descriptor.
You could have the device essentially
populating a little DMA descriptor that
says, I want to send 256 bytes
and they start at address text one
thousand and
the device is going to start doing that.
Could send out a single packet of 64.
X is the most you can fit on this
particular bus.
The most I could fit in a single packet
on this particular bus. Rather, it's
going to decrement the length and
increment the address.
This looks a lot like the example we
provided in the beginning.
It's going to keep doing that until it
gets to the point where the Lynnfield
reaches zero and USPI is almost
the null, terminated kind of protocol in
that when it finishes a transfer,
it indicates that by sending a packet
that is shorter than the maximum length.
So in this case, it set all maximum
length packets until it was done.
So it has to send a zero length packet in
order to indicate that it is
indeed complete.
Now, if we're able to start applying
voltage glitching or clock pledging, if
for able to glitch something in the
system and corrupt that length, then
what we'll get instead of those nice
orderly transaction where we send for
individual packets to just to, let's
say, send up that configuration
descriptor is we'll get a length
that is potentially much larger,
which continues to transmit and transmit
and transmit well beyond what the device
should have stopped.
And if you have a device for the DMA
controller that works like most of them
do on my controllers, it will continue
not just out of that descriptors
location in RAM or RAM, but continue
throughout the entire memory map until
that field is brought
down to zero.
And so in order to be able
to do those that kind of glitch into the
system, you really need a way to be able
to synchronize with the system and
provide the stimulus.
So Michael built a custom piece of
hardware called the Face Whisper Name,
because it's use of the chip whisperer
technology and its descent from Chippewas
technology and its inspiration
in the Face Dancer project.
And this particular board
contains a microcontroller, which happens
to be the same one that is on a chip
whisper and a USB host chip, which
happens to be the same one that is on a
face dancer and then some clock buffering
hardware.
And all that it does is.
With very precise timing synchronize
itself up to a particular
point in the tablets execution
that would make controllers program
execution and then send
it some USB packets and
simultaneously trigger the chip whisperer
to start executing glitches.
So in doing that,
she was able to actually steal the from
her from this microcontroller.
And using that, she was able to find
vulnerabilities in the firmware and
eventually prove out that indeed you
could read RFID tokens
using a USB tablet as long as they were
pressed exactly. Against the tablet.
And so this is very cool, both because
it showed a novel way of getting
firmware out of the device and because
it was a really ingenious solution to
get at something that was a whole
bunch of steps away from what she
initially wanted.
So she's the kind of person who has that
kind of like hyper focus and dedication
to say, oh, I'd like to see what the
firmware is in this.
Let me build an entire piece of
purpose-built, hardware, firmware and
everything you need in order to be able
to, you know, get the firm out of a
tablet so they can then go and look for
vulnerabilities.
Yeah. So I feel having having said
all that, I do feel slightly bad about
the next slide, which is we've
essentially taken her idea and tried to
make it easier.
And so like, bear in mind,
glitch and all this stuff that didn't
exist when she did this and she went and
designed a board, built a board attached
to it, glitch the thing, got the firmware
out, whatever abilities.
So now we can implement that.
And I think that's one of the
conversations that Mike and I had
afterwards was just to both of us really
love making technology accessible to
people. Right.
One of the purposes of this and one of
the things I kind of promised Michael
when I started doing this is that we
would take this had this
whole technique, which required
a custom piece of hardware and, you know,
required a whole lot of different
levels of understanding and a whole lot
of development in order to test an idea
and make it into something that you could
apply kind of relatively
easily. So here's the
back end code for
applying the same things with Kit.
This is written in Python.
We were going to go through this, but I
think we're running low on time and I
want to get the demo done.
So so we're happy to
explain this at some point, but possibly
not now. Just we only got five.
Important part is that you don't actually
even have to write this code because the
final form of glitch kit has fancy
glitches that sit there.
Right. And Chipwich. So if you want to
apply the USB attack that Micah did,
you can start configuring that right from
the gooey of Chip Whisper.
So what time first,
OK? First time I just show off the ship
was prickley and then we'll talk about
our work well.
So this is the chick whisperer.
We now have added these
various glitch
methods. So they'll talk to a great.
I mean, there's a there's a big mess of
wires and connectors and things
on the table here.
And but essentially, we have a great
fat and a chip whisperer hooked up to our
target, great fat.
And the process of configuring this for
the you go and you select instead
of you're the type of target
that you want to select directly, you
say, OK, I would like to talk to
the great fat that's running a USB stack
also like USB and then from
the UI you can immediately
configure. Yes, I'd like to read a device
descriptor. I'd like to have that
device descriptor.
I'll be ready immediately when certain
pins go high and so you can start
building everything you need to allow
you to walk the interface. You EUROSUR, I
think it's kind of difficult to see on
the board. But if you look over here,
here's all the configuration settings you
would use to.
These are preconditions that determine
what an individual USB event
is generated up here on the side.
So you can go into this interface now and
you say when this when this GPO pin goes
high then and this one goes
low and this one happens on the fourth
time, whatever, and those complex
conditions that we're talking about, you
can just have that at that point.
The software will then set the trigger,
the the chip whisperer
to do its thing.
Right. So naturally,
you know, we're not content with just
reproducing other people's work.
We wanted to try doing some cool things
of our own, so.
At some point, we had to turn against our
own creation, right?
And so here is a great
fit that has been kind of actually
sloppily modified so that I promised
the board had all the flux on it before
we made modifications.
But I've yanked every one of the
decoupling capital capacitors rather
roughly off this device,
try to make it easier to start depriving
the device of power.
I've added a couple of
pretty nasty Varg wires here,
one that connects
the Vicryl to a couple of semiconductors
that you can do things like
inject voltage, inject
glitching signals and pull the voltage
down to zero.
And because we still want some
decoupling, I have a decoupling network
here that is replacing all the decoupling
capacitors on the board and that
is connected via a small impedance that
we can pull the device fairly readily to
zero, but it can recharge
the bass from these capacitors
via that small in this case
approximately 10:00 a.m..
And so sorry
to my COSSMAN because we totally
destroyed this thing that he's created or
I totally destroyed this PCB that he
created.
But more importantly, I'm sorry to
everyone else because look at this thing.
I actually tweeted
this picture and you've got, you know, a
significant number of likes and
retweeted. And I got a couple of people
being like, clean your BCB,
please.
It's not about how clean it is.
It's about it's about the glitching.
And like this this actual modification
was done like after a couple of drinks,
like on the night of Christmas, which is
like the perfect time to start switching
Nutanix.
So so, yeah, the
the great thing about this is we're now
able to glitch this board and we might
even be able to get the fumer off it.
But there's some problems with that.
One is that it's open source.
So we already have the firmware because
we wrote it. But also it turns out the
manufacturer of this board is incredibly
litigious and he sends out cease and
desist letters when people try and
reverse engineer his devices.
I mean, he sometimes writes them in
Sharpie, but you never you never know,
he might say, because we just.
Yeah, because when we already have a
source code to this and it's on GitHub,
and that doesn't make it a particularly
interesting reverse engineering target.
And two, because we're terribly afraid
of litigation, we decided instead
of attacking the Gresford
software that we're running on the application
processor that we would attack the
bootloader that is sitting in RAM on
the LPC forty three thousand
forty four hundred serious microcontrollers.
Yeah, the LPC. Forty three forty three
hundred zeros have a have a USB
Dafu bootloader
and also small USB functionality, which
is set in Rome. And there's only one Rome
section here
which I can't point to.
But so you probably do
write so that.
This device has a USB
bootloader that does all the same things
as the tablet because it's compliant to
the USB standard so it can do things like
you to respond to a get device
descriptor request.
And so we started applying the same kind
of glitching attacks to the ROM.
And you might be kind of saying, well,
why is it interesting to attack
this from one? Is that on a bunch of
these devices, it runs from the shadow
area that is at the start of RAM because
the cortex and microcontroller, once it's
vector table to be located at zero.
So it's very low in RAM.
Everything that's interesting follows it,
including on device parts with flash,
the contents of flash over here.
And also because if
you look at the secure mode parts,
one of the things that they do
inside this bootloader is read encrypted
images from things like flash
chips, decrypt them and stick
them in RAM immediately
following the.
Shadow area from which is running, so
we're capable of doing glitches,
so if we can read out from the shadow
area, we can continue reading, doing that
that diametric to
continue reading into RAM and pull out
that now decrypted firmware from secure
parts.
We only have five minutes left.
So I think we should go ahead.
I do not know how to say this guey as
well as you do. So I'm going to let you
do this.
This is the hard part.
All right. All right.
See see, that's what happens
when you run on my machine.
This is tragic.
If in doubt, turn off and have to wait
for it to connect and start blinking,
but here I am impatient, wanting to just
like, click the button immediately.
This is actually the hard part.
So.
They have a table from previous runs.
Essentially, this is issuing
USPI request to the device and capturing
the response, because we have limited
time, I haven't told it what's a good
response and what's a bad response?
So it's telling me every one of these
responses has failed.
But realistically, if you expand that
dialog that we can see what's happening
there.
Throw all the way down to the initial
ones.
It's worth mentioning that this is
actually a simulacrum of the device
running the way it normally would
normally when you're glitching, you would
actually step through lots of intervals
in order to find the few glitches that
work. So because we don't have several
hours to do this glitching attack.
This is actually because it has been
slightly modified to instead
of always reading the correct descriptor,
it jumps to different points in the
glitching stack that we've found having
to work for this particular device.
So what you'll see here is, is we get a
lot of a lot of responses that are the
standard response that what we expect to
come out of it.
They are it's reading.
It's trying to read 18 bytes.
That's hex 12 of of
the USB descriptor.
It reads, it invites it gets 18 bytes.
But this one here, it appears
to have got significantly more data.
And so on a previous run earlier today,
as we said, as Kate said, this is this is
simulated because it is not
as quick as that when you actually run it
on a previous run.
We dump this to.
A hex and somewhere.
Can anyone see that anyone
read that at all?
So it's got to turn up the font size.
We appreciate it. Thank.
So what you can see here is what we were
able to read out of that file in
is,
is what we were able to come to this file
was just all the memory we're able to
read from the USB descriptor location
onwards. And we were kind of going
through it, looking at it earlier and
like, well, we haven't had a chance to
analyze it yet.
And then what we found was
over here, it
says USB B, C, and under here it says USB
s. And those are incredibly telling
strings. If you've designed
USB systems before, this is a USB
command that's sent it's actually
because he commands sent over a USB
that's used in USB bulk only storage.
And this is the token
that precedes a response of status
when one of those commands is executed.
So this significantly suggests
that this from bootloader happens to have
inside of it some USB
mass storage functionality.
And our first response was, that's weird.
We didn't think this had be mass storage.
And then we went back to the datasheet
and reread it. And it does.
And it turns out we've done the code of
some of some wrong functions that
we didn't even know were in the chip.
So we were able to to
pull out and expose
ROM code for the LPC.
Forty three hundred Sarus.
And obviously you'll be able to go ahead
and analyze this, and that's not
particularly novel because you could grab
that up with GDB as well.
But yeah. Yeah, it's not the most novel
if you were to continue doing this work.
One of the theories that we have is that
we didn't let this go for that long.
We didn't capture that much data.
I don't have any Sacramone chips on me.
But the theory is that after this kind of
thing, the ashram you would grab would
have theoretically a decrypted firmware
image if it wasn't a firmware image over
a USB. So you could kind of use this as
an oracle to take encrypted
firmware images and
generate the decrypted ones.
So we're now, unfortunately, completely
out of time until we have to go, so we
will take questions outside
and if anyone has any questions, will be
outside. If you're somewhere, if you were
towards the Internet or Twitter, our
Twitter handle getting the absolute
beginning or just fundus, there's a great
I'll see on Freenode if you want to ask
questions there. And thank you
very much for listening.
And this is the URL for the project if
you want to download and contribute.
Thanks so much for listening.
Yeah.