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/329 Thanks!
Because in the keynote, it was said that
we should go to talks where we have no
clue what the title or the description
of the talks means.
So I thought I can use that as an excuse
to do the Herald job for this,
sir.
And this guy will talk about reverse
engineering of chips
of ICS integrated circuits
in nondestructive but
rather complex way of
doing electrical stuff that's not in
the data sheets rather
randomly at times.
The priest that should give us this
introduction into this type of voodoo
magic is let's be
excited about Exide.
All right, so thanks, everyone, for
coming out here. So the
title of this talk is GLITCHING for
Newby's A Journey to Coax Out
Chip's Inner Secrets.
So basically, this is kind of
over the last couple of years, I've
got interested in the topic of
glitching and have
been trying a whole bunch of different
experiments and trying to learn for
myself what it was all about.
So this will kind of be a chronological
kind of summary of what
I've been up to in the last couple of
years and what my findings have have
been.
So just the quick agenda for
the talk, quick intro
background, which is kind of the
classroom learning about what glitching
is platforms, which
is some of the various hardware
platforms I've I've come up with
in the last couple of years.
Some of them were epic failures.
Some of them were actually actually
seemed to work. So it'll be an
explanation of the pros and cons,
for example,
will be a real world example
of a secure microcontroller where I was
able to basically
get some glitching results out of and
and maybe some food for thought, some
some thoughts that you guys could carry
forward and how you could approach some
of the some of your own chips.
And then finally, any Q&A section.
So intro about me.
I'm an IT monkey or a consultant
by day and I consider
myself a hardware hacker by night.
So some of my interests are designing
and reversing embedded systems.
I see security and failure analysis,
arcade platforms and automotive stuff.
Anything electrical or mechanical or
whatever is pretty cool to me.
And my contact info you can see there
is just my Exide three one three three
seven at Yahoo!
Dotcom email.
So let's go into the background section,
the classroom section, so what is
glitching so a glitch
and this is not necessarily electrical.
Right now, the definition would be a
transient, which can induce alteration
in a device operation.
So a glitch is something that can mess
up a device's normal operation.
For this talk, we'll talk about
electrical glitches specifically
and specifically Klok glitching and
voltage or power glitching.
And there are other our other variants
like laser thermal, radioactive.
But I'm not enough of an expert
in those topics to
to give them a good speech.
So if we focus on the right hand side,
they're on
noninvasive, semi invasive and invasive
types.
So electrical glitching would be
considered a form of noninvasive attack
on a device.
So this doesn't permanently alter
the devices package, the physical epoxy
block part of the chip.
It doesn't permanently alter operation
of the device. So when you remove the
glitching stimulus or you stop glitching,
it should work normally again and it's
repeatable, which means you can you can
start glitching, stop, go
away for a little while, come back and do
it again. And it's not going to harm the
device and you can keep repeating it.
It's also surreptitious, which means
there's no miling or drilling or etching
or things of that nature.
So it shouldn't look like you actually
did anything to the chip physically.
It should just look like normal.
And another characteristic that's
fairly important is that noninvasive
attacks are usually cheap.
So you don't need an expensive lab
and you usually don't need things
like specialized microscopes or
other expensive tools.
And the kind
of drawback to the noninvasive attack
is that any background details you
have beforehand are very helpful
because they'll help to narrow
the scope and what strategy you want to
do when you're trying to glitch rather
than a completely black box
device where you have no idea to where to
start. You could take many wrong turn.
So any information you have beforehand
would be quite helpful.
So some examples of
noninvasive attacks in the
umbrella, there's three one umbrella,
so there'd be fault injection, which
would include Klok leeching voltage
glitching.
You can do thermal glitching, which is
kind of where you're trying to affect the
junction temperature of transistors.
So but really, from a noninvasive
standpoint, you're either trying to heat
up an individual pin
or try and heat up the
whole chip package all at once.
And it's not really precise.
So I'm not sure if there's if
a lot of beneficial effects could come
from the thermal side.
There's also radiation
radioactive glitching.
So if you just happen to have a source of
x rays, gamma rays, alpha particles
are neutrons walking around in your
pocket, you may be able to sit
those nearby the chip and get it to
flip bits of memory or cause the
CPU's instruction to
cause the CPU to latch
or invalid instruction or something like
that.
So the next umbrella is kind of side
channels. So that's where there's power
analysis where you're basically studying
the current consumption or power
consumption. The chip, which can leak
operations being performed,
can reveal things like Krypto
round keys or kind of intermediate
keys that could be used to derive like a
full break on the encryption.
And it can also indicate where
the CPU CPU is,
provide an indicator where the CPU is in
its instruction, in its instruction
execution of the overall program.
So there's timing attacks, which is
simply trying to exploit
the fact that conditional branches,
when you're checking for a password or
something else, you might stop when you
find the first incorrect
character and it'll stop a lot
faster than if it went through
all the correct characters.
So you'd be able to exploit the
difference in timing to know if your
guess at a secret password is correct
or not. Data Revenants.
That's pretty much kind of like your cold
boot type attacks.
Or if you do a reset or
power up the device and it doesn't wipe
its memory, then there might be
secrets still in memory.
And then finally, the third umbrella is
software. So this could be simple code
vulnerabilities. The authors of the
secure device may
not actually be that versed in secure
coding practices. So there may be just
vulnerabilities sitting around like
buffer overflow, stack overflow and
things like that brute
forcing.
So you this you could try
you could simply try brute forcing.
If the key strength is is small enough,
the the secret that gets gains
you access to, to restricted
memory areas, code protection.
You might try brute forcing a crypto key,
but if it's a relatively modern
implementation, it's probably not going
to work for you.
And then finally, the back doors,
which could be undocumented
instructions in the CPU core,
could be debug interfaces geotag.
You are hanging off the device somewhere.
I scored CSPI, stuff like that.
So those are can
be some of the more low hanging fruit,
but may or may not be present.
So the second major class of
attack is semi invasive, so this
is where you are altering the
package of the device, so
you might decapitate, so you might etch
away the epoxy packaging of the chip
or you might miss the
chip from the top of the bottom to to
gain a better access of the
actual dye sitting inside
the chip package.
It doesn't permanently alter the device
operations. So, again, you'll be
able to to apply or
remove some sort of glitching stimulus
to the chip.
And when you're done glitching, it
should it should operate normally.
Again, it's repeatable unless
you're doing laser laser glitching
where you leave the laser on too long and
you burn up something that you didn't
want to, it's
more expensive. So now you
you may need things like lasers,
microscopes, chemicals,
a M. And this may be this class
of attack maybe beyond a single person's
budget. So it depends
how well-funded you are not.
And then this kind of attack can provide
background details rather than require
them. So you'll be able to
to help narrow the scope and strategy
potentially for your noninvasive
glitching attack
and get a basic floor plan of the chip,
for example, if you've got an optical
microscope or something like that.
So some semi invasive
examples glitching, you can still glitch
semi invasively.
So now you've got access to the chips
surface in some way.
So you can use things like
laser flash, like a camera
flash, high intensity light
and thermal glitching where now
you might be able to direct a source of
heat at a more precise area,
but still going to be probably pretty
could be fairly unreliable all year
round.
You'll end up altering
bits, order or transistor gates
in a larger area.
So another
type of example is laser scanning.
So you can do it with the device being
unpowered or powered.
And so when it's unpowered, you
basically have an optical beam inducing a
current flow in the chip, which
will change the current signature, the
like the power consumption signature.
And then if the device is powered on your
optical beam can cause a measurable
voltage change in the
in the output of the transistor
or the bus that the transistor is
connected to. So it may be possible to do
things like read out memory bit at a time
by watching the current consumption and
then sweeping the the beam across
the different rows or columns of
a memory, for example.
And then finally, there is the you
can do imaging attacks were either
due from the front of the chip or the
back of the chip where you mulloway the
back material.
You can do visible wavelengths
versus infrared and
you can do things like using optical
microscopes versus electron
or iron beam based workstations.
And this will allow you to get
the floor plan of the structures and
features of the chip a lot more
precisely. So things like rom
ram, flash E squared configuration,
security, fuzes, things
like that.
So now the the
highest notch, the most complicated
type of attack is the invasive attack.
So this is where you not only have the
copulation and miling of the semi
invasive, but now you also have DIW
alteration itself.
So the actual little
the little chip part of the
of the microchip.
And you can render the device
nonfunctional with this process.
For example, if you're trying to image
the device layer by layer, obviously
you're removing your etching away
material. So the device, once that
layer's gone, it's gone for good.
So you'll want to have many
samples available so that you can
image the device like that.
However, if you if you don't want to
do that, but you want to have access to
the to the service of the chip, for
example, and depending if
you're if you've got
access to an FRB workstation where
the device input pins like voltage,
ground clock, et cetera, are outside the
vacuum chamber or outside the chuck, you
can actually power the device up and run
it while you're making modifications to
it. So like
I said, this these most these techniques
are one time, especially the delayering
process. Where is the FIB workstation can
allow you to create edits, undo
edits, and so you can go back and forth.
So this class of attack is
can be very costly.
So whereas the the decapitation
and the readouts of the the imaging
of the chip can be somewhat reasonable,
the actual being able to edit
the chip can be very prohibitive,
depending on if you have access
to the equipment or kind of an hourly
rate to get on the equipment.
And then finally, this type of
this class of attack will pretty much
provide you with complete background
details so you can use all the floor
plan data. You can actually
force certain transistors or
busses on circuit nets
on and off and actually get a good idea
of how the device operates.
And then you can feed this information
back into the semi invasive and
noninvasive attacks to make them a lot
easier because you know where on the chip
to target.
So as I mentioned previously,
so some examples of invasive are
decapitation. So taking
the chip out of the package, delayering
the actual dye, you could do a memory
readout, which if the circuit has ROM,
for example, you'd need to get through
all the layers, all the metal layers down
to the very first metal layer.
And then that's where the actual Romme
transistors are formed.
You can do circuit edit.
So etching where you're removing material
from the from the dye in certain areas,
deposition where you're using something
like platinum or tungsten to
to deposit conductive material
on the surface. So you actually create a
conductive path wire bonding where
you're actually taking
a wire bonding machine and putting gold
bonding wires from the dye of the chip or
from areas of the chip out to a larger,
more human friendly package, like a very
large dip or something, a dip package
where it's two rows of, you know,
10 or 20 pins or whatever.
And then you can you can easily work with
that. And then you could also purposely
destroy traces or transistors at this
point if they're causing some sort of
functionality you don't want.
And finally, you can do microprobe
probings. So when you've got really,
really tiny, for example, tungsten
needles, you can actually stick them down
on the surface of the chip and either
listen to what's going on or if
that or drive
drive a signal back into
the core of the chip somewhere.
So that kind of concludes
the different classes of attacks and
kind of from the cheapest, the most
expensive.
So back to electrical
glitch. So how do you actually where do
you get started?
How do you how do you do how do you
generate glitches?
So when you're when you're making these
glitch pulses that you're sending into
the chip either through either on the
clock lines or the power lines of the
chip, here's four methods that
I basically came up with.
And I'm you guys are some of you guys are
probably really smart and can think of
other ideas. But these these are the ones
that I could think of a simple clock
divider phase locked loop.
If your device in this example had an
FPGA with a PLL,
use that Pawley pulse
with multiple modulation where you've got
multiple ummed signals
for their part from each other and then
poly phase where you've got three
signals that differ from each other in
their phase.
So the first.
Divider example, this one's the simplest,
where you literally
take as many flip flops as
you want, and every time
you go through a through
D flip flop, you basically divide the
original input signal by two.
When you when you when you feed the
output of the flip flop back to the
input. So you go from forty eight
divided by two down to twenty four,
divide by two again down to 12.
And so now what you do is you have this
multiplexed where you feed it, the
slow 12 megahertz signal and the original
system clock. Forty eight megahertz
signal for example, and
you run the device through most
of its lifetime on the slow
signal and then you toggle the glitch
select line down here.
At the moment you want a glitch and then
now all of a sudden you'll get some forty
eight megahertz pulse pulses, pulse train
instead of the slower
12 megahertz in this case.
And you can use this directly as the
clock signal to the input of the device,
or you can use it to get the switching
of the voltage from a
high value to a value that's known
to cause the device issues so
it gets flexible and can be used either
way. So this is what the waveform would
kind of look like. Here's let's say
here's a single speed clock
and here's a double speed clock.
And then when you bring your select line
high on the which is a select line on
this multiplex down here,
then all of a sudden you
will switch the actual waveform that goes
to the chip from the slow to the fast.
So it simply just switches between slow
and fast.
So the second method is the phase locked
loop PLL, so the the
the PLL uses integer
multipliers and dividers to create a
fraction of an integer fraction,
something over something that can
be used to multiply up and then divide
down to get you many more different kinds
of clock speeds than simply
dividing by two each time.
So then this way you'll get for example,
have the feed the PLL with the normal
fast clock and then instead of 24 and 12,
you also get 16 and four or
whatever combination of speeds you want
in between.
Combine all those with the with the fast
system clock, add a couple more select
lines and now you've just given yourself
more choices in terms of what speeds you
want to play around with. So if you do
the if you do this work up front, then
you don't have to
have to keep changing your circuitry down
the road. It's more flexible.
So the third method is poorly.
Um, so this is where
you use multiple pulseless modulation
blocks to generate clock signals was
successively longer and longer duty
cycles. So now in this case, instead of
change in the frequency, we just keep
our system clock at 12, 12,
12, 12 all the way through these blocks.
But now we have a 50 percent duty cycle,
which means 50 percent
duty cycle means half half of the
waveform.
There's equal parts on and off
in the cycle of a waveform.
So you'll see in the picture 70
percent means that the waveform is on 70
percent of the time, off 30 percent of
the time. So the remainder between
seventy and one hundred percent.
And then the third one is eighty five
percent.
And then what you do is you feed this
into XOR gate and
then the output of that couple it with
one more exer. So it's basically like
you're, you're exploring the two signals
and then exploring in the third signal
with it and then that'll get you
a glitch pulse.
And then again you just take your select
line to go between the original
clock and then the the
shorter pulse.
And here's kind of
how how the how the pulse,
the short pulse gets generated.
So again, the frequency is the same.
The phase is fixed.
So these things are locked.
If you look here right in the
middle, those lines all start at the same
time. So the phase is they're all locked
with each other.
However, when you
when you change the duty cycle,
you'll see that the 60 percent wave
is on a little bit longer than the 50
percent and the 70 percents longer than
both of them. And it kind of it's like a
staircase effect.
And so what happens is when you run
these through the those two XOR gates,
the difference between the.
The first and the first and the second
pulse gives you when you want the pulse
to start. So that's right.
This this left side of it right here is
when you want it to start in
horizontal relation to
the end part of the pulse and then this
third duty cycle with
the difference between the third and the
second.
So the 70 percent in the 60 percent gives
you how long you want the actual pulse
to last for how long you want it on for.
So this is actually a pretty flexible
method and you don't need PLL hardware
in your device if you want to be able to
generate these waveforms.
And so basically you get one
pulse of it, whereas the
kind of the fourth Messitte method that I
can think of was poorly fais so
multiphase.
And this is where you generate multiple
waveforms, but each one is phase shifted
from the previous waveform
by some so many of degrees.
So the frequency again, the frequency is
the same 12 megahertz, 12, 12, 12.
So it's all 12.
But now you're shifting the actual
relation of the second and third waves
to the first wave and
again, selecting when you want normal
normal clock versus glitch clock.
So now the only real difference is
now the waves, the on time
duration, for example, right here is the
same in all three waves.
So it's not different like last time, but
the waves are offset.
They're beginning when they start is
is further and further ahead from each
other.
And effectively what it does is it gives
you a glitch pulse on the leading the
beginning edge and the trailing the the
end edge of the waveform.
So you get twice the many pulses as
you did with the polyp.
So do you need it or not?
It all depends on your application.
It may help you to be able to generate
them more quickly or more often, but
it's just another way to
to do that. So a quick aside,
like I'm using ultra FPGA so you
don't have to worry about reading all
this big paragraph.
This was just an excerpt out of Ultra's
manual on, for example.
And Xilinx will be similar if the FPGA
has a hardware PLL
how you're able to.
These are the steps. How to instruct the
Paltalk should create phase shifts
from its different PLL outputs, which is
basically how I took those different
phase shifted outputs and created the
these waveforms.
So then
it's got this specific timing
diagram where you're supposed to give it
these, whether you want to step
at one or more degrees, one that you want
to step forwards or backwards
and phase done is just what the
module outputs back to you when it's done
shifting. So this was looking kind
of complicated to get all these timings
right, because the FPGA was using had
a soft CPU in it.
So I ended up
having to make a state machine because
the my soft CPU
was so slow in relation to the peoples
ability to shift its phase that I would
say go shift by what I think
is one degree and it would come back like
seven or eight degrees of shift, which
to be to be scientific
about it. I want to go one degree at a
time so I could see the effects with each
degree of shift.
So I just made a simple state machine
that just literally when the CPU says,
I want you to shift one degree,
it goes off programs,
the PLL and then it exits the state
machine and waits.
So and the CPU will still have said,
I want you to to shift one degree and
it'll be stuck in the start equals one
position. Then finally, like many,
many clock cycles later when the CPU,
because it's much slower than this PLL
when it finally responds, then you can
tell it to put the start bit to zero
and then it'll, it'll bring you back to
the initial. So this way allows you to
shift one degree at a time so it'll get
trapped in this loop until you're to your
CPU is actually able to
shift.
So back
to the corner of the classroom.
So what is glitching actually doing?
So basically
it's a momentary burst in frequency, as
you could see, with those little pulses
compared to the normal clock pulse.
Also, you had a quick one, usually
greater than the max frequency of the
device.
So simple cases.
If you got a datasheet, look it up, see
what the device is rated to run at and go
even faster or many multiples faster.
The glitching is timing critical.
So the value of
the program where the program is
and its overall execution, where the CPU
is and its overall execution of its
program, you need to know if
at the specific point you think it's
going to be doing a compare.
You know, it's doing a compare.
You have you want it to land there and
then now you know that it's doing a
compare where in the actual compare
instruction, do you want the glitch to
hit? So that's your offset of the glitch
within a single instruction.
And then finally, how long do you want
that pulse to last, which was kind
of that third duty cycle or that
third phase shift wave in those diagrams,
determined how long the actual pulse
lasted for?
So basically what
this does is it causes registers
inside the device or flip flops to latch
invalid data because signals
are still propagating through
combinatorial logic through the device
when you suddenly clock it.
And so basically the destination flip
flop. So from from the source to
the destination, as the signals
propagating, you clock it ahead of
schedule. So the device
will basically latch invalid data because
the correct signal hasn't propagated its
way towards the destination flip flop
yet.
So what the SO will actually be
happening is you'll either get
instruction instructions in the CPU
korrell, either be duplicated or mutated
so and so what would happen with a
duplication is, let's say,
the real program, how to compare
and then followed by a jump.
So it's checking some condition in an if
statement and then jumping.
What you'll actually get is the COMPAR
will become compare, compare, so
that jump will actually go away.
And that's usually caused by a fault in
the fetch stage of
of instruction processing.
So you've got usually fetch, decode,
execute
memory operations and register right
back, or typically you're four or five
stages of your risk CPU, for example.
So it'll mess up the very first
stage. The next is mutation.
And this is where you actually turn
like a jump instruction into an ad, which
is probably harmless in this case.
It gets you what you want.
It bypasses an error check, for example,
but just turns it into an ad.
And usually in the fetch decode
execution step, it's the actual
execution stage that gets messed up
when instruction is mutated.
So the actual core is about to execute an
instruction and then it gets mutated into
something else.
So this is kind of the hardware
equivalent of patching a software binary
where you go into your hex editor at its
edit instruction to become something
harmless.
And so kind of technically
the instruction is not actually skipped.
So the program counter, the instruction
pointer on the CPU doesn't just
skip ahead to two memory locations.
The next instruction, it's still
executed. It's just it's either going
to do it's going to become a duplication
or or a mutation.
So
it'll feel like it's being skipped,
though, in those cases.
So sometimes this quick burst
of clock frequency can affect your config
or security fuzes.
So they'll either fail to set in some in
some cases or they're set incorrectly.
So this can this could actually be kind
of helpful to wipe out some certain
code, protect fuzes or things like that.
But it's a lot more
particular in how it works depending on
the device.
So here's kind of an overview of that
phenomenon where you have the source
flip flop and the destination flip flop.
Then you've got a bunch of material like
individual and or etc.
gates through the middle.
And what you're doing is you have.
You have a clock event, so now you
also know you have your glitch pulse, and
this pulse occurs down here
well before it was expected
over on the right hand side, which
coincides with where the actual
destination flip flop is in time and
propagation distance.
So you clock it way ahead of schedule and
now it'll clock in some garbage
data here rather than the proper signal
making its way all the way through.
So that was clock ticking, so
what are the what are the what's the
mechanism of voltage glitching?
So this is a momentary reduction in
supply voltage to the device.
So what you do is you you drop the
the voltage to or below the transistors
switching threshold.
And a rule of thumb is try
supply voltage divided by two and
and start from there.
It could be it could be lower.
It could be higher. But it's a good
starting point.
So what this does is this increases the
propagation delay, which is
literally the delay this
of the signal propagating through the
device. So it gives you kind of the same
end effect.
And why that happens is because you
when you decrease the supply voltage, it
decreases the drive strength of the
transistors and this lower drive strength
will cause slower rise
time. So you'll actually, instead of a
sharp edge rate, a sharp transition
of of signal transitioning,
you'll actually get a slow it'll take a
long time to plateau and a long
time to discharge, basically.
So that gives you that buys you that
gives you that effect where it's
slows that propagation of the signal
down. And again, just like
clock clicking, you want to be accurate
to where the instruction
is in the overall program, where
inside the particular instruction you
want the offset of the glitch and then
how long you want it to
how long you want it to be
active for.
So also.
So what it's doing is it's also altering
the values at the memory sensor
amplifiers for for for flash
E squared, RAM, et cetera.
And so this has the effect of
corrupting, corrupting
data latched onto the address or data.
So you can actually have the program
swing off wildly to an invalid location
because you you lock a
bad value onto the address.
Most cases it'll crash the chip, but in
some cases it might jump you into an area
that the program was never supposed
to reach.
So and again, Security Fuze logic
in the voltage glitching mode
can also latch KRUP values due to that
effect where you're right at the
switching threshold of the transistors.
So just to dispel a few misconceptions.
I don't recommend throwing random volt
voltage sags and
sags and surges at the AC and seeing what
happens.
I would recommend respecting the absolute
maximum VXI and VXI for
the Eyeopener ratings on the data sheet
if you have one.
Otherwise you can have lock-Up occur,
which is basically kind of a short
between the power rails of a device or
two to two pins of an icy.
And this can cause the device to overheat
or basically destruct due to overcount.
So you want to avoid Lache up some
74 series logic.
You can you can give it very
high and low voltage swings on the input
pins, but usually they have a current
limited condition in the data sheet,
like specific Fairchild chips, for
example. But not National Semiconductor
will say you can do this, and
that's because you have to put a giant
current limiting resistor in front of the
pin, basically. So.
Don't don't throw these crazy
high or low voltages out a chip unless
you've got a bunch of them, basically.
And you're not randomly jarring the clock
frequency, to what extent you're
you're specifically targeting that pulse
at a certain point and you're not
technically skipping instructions, you're
as I said, you're kind of duplicating or
mutating them.
Again, it's timing critical.
And finally, if the chip unless the
chip is stuck in a loop, just randomly
glitching like like with with random
voltages or the clock
at certain offsets randomly
is not is usually going to be
counterproductive unless
the device is stuck in a loop, a tight
loop with a few instructions.
Then obviously the search space that your
glitch has to hit is very constrained.
It's very small and it's more
likely you can pop out of the loop.
So what are some of the outcomes
in general that voltage or clock
glitching can or potentially
any glitch and can can provide for you
so you can make the CPU replace impeding
instructions. So you turn that jump
into a compare compare, which doesn't
jump anymore.
You can truncate cryptographic operations
or keys, so reduce the number of rounds
in a crypto
encryption or decryption process.
You can do linear code extraction where
you basically dump you.
You walk the address space of the device,
address location, one, two, three, four,
all the way until the memory map loops,
dumping out the data from the device bite
by bite. However, you do usually need an
IO channel to actually get the data out.
So you are PIN or
something of that nature.
You can do things like bypass bootloader
enforced checks so you can stop the
memory management unit or page tables
from initializing if they're mapping in
sections of memory overtop of the
bootloader to hide it or conceal it or
just to save to provide more space,
you can stop that from happening.
In some cases, you can prevent lock out
counters from rolling. So if it's a
secure crypto memory or something like
that where you only have so many tries
before your lock, though, the device, if
you glitch when it's recording or
decrement in your try counter
that the number of tries will never
change.
So you can just keep doing
your malicious activity over and over
again without the device finally reaching
zero and then erasing itself or halting
or something of that nature.
And then finally, in some cases, you can
trace security forces are lock bits.
So what this will do is keep the Flash
and R-squared intact.
So then you can just take the device off
the board, for example, plug it into a
parallel, parallel or similar program and
just read out the device that way.
So if you're looking at chips to try
some of this stuff on, there's pretty
much your general purpose and your
security enhanced categories.
So things like general purpose, things
like CPU's, microcontrollers, memories,
digital signal processors.
Then on the security and hand side,
you've got things like SIM card, smart
meters, military devices, chip and PIN,
pay-TV transit transmitter,
metro and then automotive devices.
However, the security and hand side is
I'm not saying like stuff's going to work
necessarily there. It depends on the age
of the device and how smart the
developers were when they made it.
A lot of these security enhanced devices
are actually really, really good.
So things I don't recommend is
trying to trying to
attack like FPGA is or ASICs simply
because there's so many unknown
variables. And unless, you know, there's
a certain CPU core inside that async or
that they've programed a certain block of
logic in the FPGA, it's
you'd be fishing around in the dark,
basically.
So what are some countermeasures that,
for example, a manufacturer or if you're
writing code or embedded embedded
code for a device, what could you do as a
countermeasure?
You could use a CPU which halts or traps
on invalid instructions.
However, in the case of the instruction
mutation, where your jump became an ad,
the ad instruction is still a valid
instruction in the in the table of
instructions in that device.
So that may not even trigger in an
invalid instruction fault.
So better than nothing,
though you could erase volatile
memory on start up or reset
just no matter what device comes up.
Just a good best practice to wipe the
wipe the memory.
So what you want to do is minimize the
number of copies of important secrets are
primitives. So like for RSA, P
and Q or any combination of those
intermediate values that could drive
back to your private key,
keep as few of those as possible and
obviously wipe them between iterations of
a routine in certain
parts of the program. If you don't need
them, if you don't need them, get rid of
them.
So clocking when you're clocking the
device, you could run, you could use a
device that runs off an internal
oscillator. So it just ignores
the clock pin from the outside world.
So that pretty much would cut
off any clock launching attacks.
You could use asynchronous logic wherever
you could. So if something didn't need to
be clocked by a clock signal, then
don't.
And finally, you could use a periodic or
random clock period generation, which is
where the actual clock
period is changing between cycles.
So it's it's unpredictable in
terms of the timing.
Finally, you could use obscurity, which
is another kind of last layer of defense.
It's not a.
Not a prime defense, but use a really
complicated 48 bit, very long instruction
word DSP corps with poor documentation
in your product, it'd probably make it
harder for you to write if you're the
developer as well. So it's not that great
of a countermeasure.
Finally. So supply voltage
use, glitch or brownout detection.
And this can be very complicated
with fans fast transition detection that
actually detects and responds.
You could use a simple low pass filter
which simply
ignores and erases that quick transient
as far as the chips concerned so it
doesn't even see it.
Or you could be more aggressive
and reset, halt or wipe the device if you
detect someone is trying
to mess with your chip this way.
So many general-purpose devices have
little or no design and protection.
So these are chips that you guys
could look at in terms of
interesting targets.
So Abers picks Tempy,
for example. They do have they do have
code protection. So
it may not be your first choice if you're
if you're just starting out learning.
And then at the at the extreme level,
modern spart smart cards,
chip cards have extensive protections.
So they've got glitch detectors.
They've got the random in a periodic
internal clock, which is changing and
changing in its length between cycles.
And you'll have to CPU cores
in lock step that are sanity checking one
another. So if something if some
instruction goes wrong in one chord, the
other core will be offset and catch it
and do something like either reset the
device or erase the memory, etc..
So this will detail some
of the actual
hardware platforms that I made over the
last couple of years that that
were that I use for voltage and clock
glitching. So the summary of this guy
is basically this is an off the shelf
aero low power reference platform
board that I found for really cheap on
eBay, like I think it was between 20 and
50 US dollars.
So not not crazy expensive.
So it has an ultra cyclone, three FPGA,
which I put a MIPS 32 bit soft
CPU inside of it, that
3:00 a.m.
clock generator.
So it should be for the three
polyphasic the polyphasic clock
generator. It's got a regular 60 and 550
UAT.
It's got some driver functionality
for RAM and flash control and then some
output. Multiplex's to switch between
your low speed normal signal
and your high speed glitch signal.
And then this massive breadboard
at the bottom is just doing a voltage
level shifting and signal conditioning,
conditioning and buffering so that
the end target in the FPGA, for
example, doesn't get blown up by if the
target device is running higher voltages
than the FPGA.
So this is a close up where you've got
kind of general purpose.
It opens up here.
You got three point three volt supply,
five volt supply,
thirty two USB to
you, chip SD
card, which I'm not using at the moment,
but could probably be used for data
logging.
CPD, which is just used to program
the FPGA from a PC,
the actual FPGA intel flash
and then some micron dram which is
actually dram with rapt
with an stream interface.
So it's just easier to to
work with it. You don't need to have all
the crazy DRM timing signals.
Exactly right.
And then on the Saulius breadboard,
there's just some these 74,
the LV is important.
So one twenty five is just
a buffer that takes it just a buffer,
takes an input signal, provides an
output and then it's got an beside each
pair, those input output pins, there's an
output enabled pen lets you
float the signal or drive it.
And the LV is important because it's
five volt tolerant.
So you can power the device with three
point three but it'll accept five volts
as input. So any outputs from
it will be three point three.
But let's say your device runs at five
volts. It can output it signals to the
input of this as five and then this
will output them at three point three to
the FPGA where you won't blow it up,
whereas if you drive it the FPGA at five,
it won't last very long.
So other not just your
five and three point three volt power
rails. And then just the pull up part I
was playing with to strengthen
the the drive strength of the
one of the signals.
So here is another another iteration,
Saderat Breadboard, which is kind of
beefed up version of this that
I thought would work at higher
frequencies because it's slaughtered.
But clearly you can see from this mess of
wires that my routing is amazing.
And so
I use this board for both Voltage and
Klok looking.
And it has what I call a ghetto deck,
which is basically
you provide a source of varying
duty cycle signal of how much
on time to off time into a low pass
filter. And the output out low pass
filter will actually be a steady
zero to five volt range
DC voltage based on the pulse
width of the signal coming.
And so it's just an easy way for a
microcontroller or FPGA to send
a signal and you end up getting a varying
voltage rather than having a real
digital to analog chip that
does that in its
own way.
So for a while, I
seriously considered Arduino for about
seven minutes, because
why not?
And the problem with Arduino is
the crystal is fixed on board
wherever wherever it is.
Uh.
Can't see it at the moment, but anyways,
it's I think it's 16 megahertz.
And as soon as you go and use any of the
timer output, compare registers
to divide that clock down.
You can't actually you can't take the 16
megahertz and provide it directly at 16
megahertz on an output pin.
It automatically goes through a divide by
two as soon as you turn any of those
timers or compare features on.
So already before I even started,
all I could do is eight megahertz signals
out of this thing.
And so if your device
is running at two or four megahertz, that
might be enough. But if your device is
running at thirty two megahertz, then
obviously this isn't even
going to help you. So it just wasn't
flexible enough.
So then I thought I'd make an even more
feature. Rich Boards and
because I'm thrifty, decided to educate
myself, which was
pretty much an epic failure because
what happened was my transparency that
you shine the fluorescent light through
with your mask of the layout was
slightly off the surface of the board,
which had the effect of being out of
focus. The artwork was out of focus.
So basically I had blurred pads and
traces that didn't develop properly.
So you can see stuff
like this probably isn't conducting
too much credit through it.
Sections right here were wiped out
entirely.
And you can see the ground plane is
starting to get attacked because you
leave it in there to try and
eat through some areas.
Meanwhile, it's starting to eat through
areas you want to stay there.
Here's another kind of example of that.
More failure, so then
what I decided to do is break down and go
to Ash Park and make a professional PCB
because as you can see, it required a few
edits after the fact already.
And so this board was primarily designed
for for voltage glitching.
It has a tiny 23 13
CPU that I just had lying around.
And why it's not great for Klok
leeching is that it's obviously there's a
fixed crystal on there.
So you only have a certain range of
divisions you can do with that.
And it also, like the other board uses,
the uses the ghetto deck,
and this buffer simply strengthens
the output drive current so that you can
actually power the device up through this
buffer rather than having a weak, you
know, five, 10, 20 million signal coming
right off of one of these seventy
four series logic chips or.
Here is another device, my
my sniffer board, which is just
basically used as a man in the middle, so
this would plug into the FPGA and then
this HHC one twenty five is just like
this seventy four, LV one twenty five.
So it's just a five volt tolerant
chip that can drive signals at three
point three volts to correct the
voltage mismatch between the FPGA
and the target.
And so basically that allows for data
logging.
And then what you can also
do for a cheap and dirty data logging and
logic analysis is you can use this
logic block called ultra signal top two
in the FPGA.
And what this is, is a logic and kind
of a soft logic analyzer block
that can analyze almost any signal
that boss, external pins, whatever you
want, and you can save more
and more samples by using up more logic
elements or slices if in Xilinx
terminology of the FPGA.
So there's plenty of trigger
options from simple, low, higher edge
triggering, too. You can chain events, do
multiple segments of capture.
So it's got all sorts of triggering
and storing that a full logic and
a hardware logic analyzer would have.
Then you can export the data in plaintext
images or
other formats of the plaintext would be a
time a comma separated list of the
signals over time, like one zero one
zero. Then you can pack that back into an
actual parse it back into a protocol.
So it's equivalent.
It's also called Xilinx Chip Scope if
you're using if you're using
the Xilinx product.
So here's a quick summary of
what you do.
Just you basically pick the clock that
you want to clock the logic analyzer at
pick which signals of interest you want
and what logic levels or triggering you
want the the recording
to kick in at.
And then you get a nice
you get a nice waveform view where it
shows you what those signals did after
the trigger, after and below that before
the trigger point if you want.
So let's roll
into the last section, which is the
example of example
device I was I was playing with.
So I had a victim, I see I knew it was a
secure microcontroller, but I wasn't sure
what the internal architecture was of the
CPU core, I knew that it paired
with a partner device.
So a reader
and then the target chip.
So the target, the reader would send
data to the chip.
The chip would encrypt and decrypt it
with a key that was inside of it and then
send the data back to the reader, which
would go off to the rest of the device.
So I was basically starting with a black
box and so I wasn't sure
what data sheets to look for.
Even if the device was not on, the data
sheets might not have been public
anyways.
So what I did was basically
start probing the pads of the
of the chip of the victim.
Chip did an initial sweep of the
multimeter. I've got like a little fluke
meter. So the little bar graph part of
the meter will respond a lot faster than
the actual numeric digits.
And then I'd come back with an actual
oscilloscope for any pads that showed
interesting quick moving activity.
So one I found one pad appeared to speak
slowish serial protocol.
So all I did was capture and just
transcribe the beginning of that waveform
because my scope had a really
small amount of memory onboard memory
and it was only one pin doing that.
So my guess was that it was some sort of
have to flex communication going back and
forth because I knew what the the
victim talked to the reader.
So then I used that sniffer board
to to basically man
in the middle of the conversation.
And I use that signal type logic
analyzer software in FPGA to export
the waveforms, the plaintext pack those
individual bits back into bytes, read
the byte string. And I found out that I
after Googling that, I had a
ISO seventy eight sixteen AP du header
that I found.
So at that point this was good.
So then what I was able to do is add a U
r to the FPGA and so
that sixteen five fifty.
So what this does was allow for hardware
framing of the transmission and
receive data with the victim.
Otherwise you don't need a report, you
can do it with Big Bang, but then you
have to waste like two or three days
potentially to get the timing perfect.
So just easier.
And then with the Altera you can use this
logic block called Geotag.
You are to talk to the MIPS
thirty two bit soft CPU running in the
FPGA and then the CPU
can talk to the victim.
So then that way you just need one
programing cable from the board to a USB
port on your computer. You don't need a
cable to the victim and a cable to the
FPGA. So now that I had
that kind of intermediate speaking going
on, I had the PC speak
ISO seventy eight, sixteen smart card
protocol with the victim.
And so the seven, eight, 16 header has a
length field, so I made a
I proposed the theory that the
victim is probably comparing the length
that you send it in the length field from
from from the device or
from the reader to the max
that'll allow as its buffer
input usually like I'm not going to allow
you any more than this because I've only
set aside sixty four bytes of RAM to
store the commands to RAM, for example.
And if the length is if the length, my
hunch was that if the length was too long
then issue an error.
So then what I was able to do,
the next theory was issued a whole
bunch of two long
commands to the victim, but otherwise
corrected up the checksum to correct it
up the checksum so that it was correct
and then observed the error response from
the from the
CPU.
And at this point
now is when you get ready to glitch.
So this is what I call the sucker punch,
which is this is a clock glitch where you
see a quick pulse in time
versus the normal.
Like this pulse wouldn't be here normally
in the normal speed of the device.
So you can do a one two punch, which is
simply two pulses, one after another, and
you can try any variation of this one,
two, three, four, five different
periods.
So this is clock clicking and glitching
during the suspected victims
command handler.
So where the where the victim would be
accepting commands and checking the
length on them, the length
of the packet.
So what I do is try a different pulse,
offsets and durations to try and narrow
down when it was when it was
executing, for example, to compare
instruction that would be checking the
length of the packet you're sending it.
And so, you know, you've hit a milestone
when the victim instead
of instead of when you give it these
length, these packets
that are very long, but with correct
checksums and it normally errors out,
all of a sudden it doesn't erode.
And it actually processes the command,
even though it's carloss garbage bytes at
the end of it, to make it way longer.
So now you know that you've
probably hit the COMPAR or the jump
instruction with your glitch and you've
stopped the the device from
issuing an error.
So at this point, if
if you're already sure, like there's
usually Motorola six zero five based
cores or until 1851 cores are the
majority of of smaller eight
or 16 bit embedded devices.
So use
that as your guess you can.
So as I said, you had more and more data
to the end of the to the end of the
command and then wait till the victim
crashes or does something weird.
So you
might if so, as you're padding
more and more data eventually if it
crashes. So now you've sent in a too long
value, but you make it
even more longer.
More long.
That's not good English, but whatever.
So eventually you'll stock the smash
or but it could be hard to notice if
there's a hardware watchdog that notices
that all of a sudden the CPU flew off
into nowhere land and then reset it.
But basically, that's what I
was able to get to the point where I knew
where the stock pointer was gone, be on
it and over and over wrote
the return address.
So now that you know,
now that you know where the return
address is, you can actually start
writing programs for this device because
now you control the return address so you
can write minimal tiny little program
that tries to write to low address
special registers to like Motorola 60
800, for example, port, which
is the output pin value
pin, which is the input pin DDR, which is
your data direction register.
Start playing with those and seeing if
you see if you can get your eyeopener one
of the important pins on your victim to
toggle all of a sudden change
because now you know where the address
now.
Now you know which that those pins exist
and how they're mapped into memory.
So here is your typical layout
of the
the victims memory space.
Yeah, so your next milestone is where you
do actually have the output pin chain,
one of the pins on the device, either the
eye open that you're talking to it on or
a different pin that might be bonded into
the chip if it changes
value. Now, you've confirmed code
execution. Your architecture guess is
probably pretty good because you wrote a
little program in that target
architecture of a few bytes to write to
that low area.
And it's probably von Neumann or modified
hardware Halvard that lets you do that.
So now you're getting really
close to the next thing I did
was write more code in that architecture
in the six zero five that loads a dummy
ASCII byte like five or F or A
or some value of words, alternating bits
into a register like.
Yeah, so a on the sixty five for example,
then sweep's jumps into outer space.
So what that's doing is I'm searching for
the serial transmit routine
software, the address and software,
because this thing, the victim bit bang
the output. So it didn't have a hardware,
you thought it had to jump to a software
address when it wanted to exabyte back to
me. So I just kept sweeping addresses
in as far as that return address
with the with the smash stack until
I got my byte back
that I sent in. And now I knew I found
that the serial transmit handler and
software of the microcontroller.
So now all you have to do is make a code
loop that starts wherever you want,
wherever the current execution is, or
maybe it jumps to zero zero zero zero
loads. The data from zero zero zero
addresses, zero into a register
jumps to the serial transmit routine
which will which will echo that data,
byte out the serial port, increment
the address pointer, and then keep going
over and over again, moving to the next
memory location.
And you have to be prepared to
empty the FGS,
receive your buffer quickly
and regularly, because basically the
entire code and data space in this
particular chip will be dumped out in an
endless loop. It'll just keep mirroring
and rapping over the the outer space.
And this is kind of what's known as
linear code extraction.
So the summary, so
now that you've got this whole dump of
the code and data space, you can try and
figure out the memory map.
If if you're still not
sure of it, analyze the dump for any
mirroring of the outer space.
So you know where the overall dump
starts repeating because it's going to be
in an endless loop. So eventually it's
going to be a finite bounds of where the
memory map is. Try poking values into
certain memory locations, see if they
change. If they are, you're
probably dealing with REM or maybe E
squared or flash depending, but usually
estcourt and flash of more complicated
right routines.
And now you're back in familiar territory
so you can disassemble that code dump you
have or write a disassembly.
If if you don't have one on hand, you can
search for crypto secrets or keys
in that dump, serial numbers,
keys, whatever, and you can discover any
code vulnerabilities that where it was
just pure craftsmanship on the
on the creator of the of the code
where you can just find Vollans so
conclusion's electrical glitch and can be
a viable attack vector against a variety
of eses except for security,
hardened purpose built security.
EQs can be cheap to perform.
You don't need a big lab or expensive
lab. It's usually nondestructive in
nature, so it doesn't affect the device.
And it's another tool in the in your
arsenal when when
other approaches have failed.
So that is everything.
And I guess I'm not sure if we can
get a few a couple of questions or.
Yeah, I think we have some time for time
for maybe three or four questions.
If you have questions, please line up at
the microphones down here.
Up there, there are no microphones for
questions.
And while you pile up, we
hear a question from the Internet.
Angel, thank you.
First question, how many chips do you
destroy on average until you successfully
break in some devices where
you where you only have one
device? You have to be very careful with
how you proceed. So in those ones you
like I said, with the absolute maximum
ratings of the device, you do not exceed
them. You play it very safe.
Other devices where it's a more general
purpose, microcontroller, whatever, you
got a whole tube of them, then you can
throw seventeen volts at a five volt chip
or whatever you want, and in some cases
you'll blow up 10 percent of the devices
very quickly. But the other
story, you'll blow up ninety percent of
your devices very quickly.
About 10 percent of might actually latch
something advantageous and do something
you want before they blow up.
Thanks. There is somebody at microphone
one, please ask a short question.
But I was just wondering how
reproducible the glitches are,
like if you find a particular offset in
length, once you find the offset,
depending on the timing drift
of your own hardware.
That's pretty much the limitation.
You will be able to hit that construction
every single time.
Nearly always do the same thing every
time.
Usually. Usually, yeah. Like if it is a
compar or a jump right after it from a
conditional branch, it will stop
the branch from happening or caused the
branch to happen with very good
repeatability other than the drift in
your own clocking hardware.
And are there any more questions?
Yes. Microphone number four, please.
Yes.
Is it possible to work a glitch
through a PLL?
It's almost impossible or two
to glitch an actual PLL device or one
that's clocked behind a PLL as
proof that I haven't actually
tried. I would assume it would be a good
defense, but I can't comment
too much more. I haven't haven't actually
tried specific hadan devices
like that.
No more questions for now.