okay thank you I'll hand you over now to
alrash khabai
okay hello everyone greetings to you
today
I will talk about 40 injections today
against embedded systems
a couple of words about the topic and
why I was chosen this because it is
important activity opened a dedicated
day for embedded security which is quite
important change and the good progress
in a case of these Hardware security
related areas so
this is something that has huge impact
on the Hardware security and embedded
security so this is one of the key
points why I have chosen this another
one is that I like Hardware hacking so I
do this at home I have my own research
lab and the research corner at home and
this is something that I also do at work
so with regards to the organ though
there will be basically three main areas
covered we'll get a short intro but
really just a quick summary into the
forward injection attacks then there
will be demonstrations with regards to
the voltage glitching against the Tresor
and the emfi related attack against the
UDS diagnostic service running on an
automotive ECU
it's a couple of years about me
well it turned out that I don't have too
much funny looking pictures about myself
so I have to choose between a suit and
tie company profile picture or this so
considering the event I chose this but
trust me I'm a friendly guy despite the
picture
I'm a director at the sideberry services
at the Hungarian Deloitte and I'm
responsible for the special services
that cover basically car hacking
automotive security related services and
Hardware hacking services so beside
traditional penetration testing we do
have a special specific and specialized
lab equipment and a specialized team who
are dealing with this kind of projects
and we are delivering projects worldwide
so
fold injection in a nutshell what it is
what the hell it is so electronic
components like CPUs microcontrollers
tend to work and expect it to work
properly in a range of safe Zone this is
coming from a specification it can be a
voltage range so the typical voltage
that is expected for example by a
microcontroller or a CPU
can be moved in a small range and below
that or above that something unexpected
or non-determined deterministic could
happen
or this could be something else as well
this could be also a temperature so
CPUs microcontrollers other components
are qualified to work properly in a
range of safe Zone this is the main
message and outside of the sales Zone
there is something magic that could
happen and for the injection attacks are
typically trying to bypass these borders
and move at the sharp edge of the border
to find the exact spot and exit
configuration the exact environment and
settings that is necessary to let the
target keep up and running but to
achieve something
unexpected that let us the auto care to
achieve something meaningful and bypass
some security features
so there are various type of faulty
injections the typical ones are the
wattage glitching this will be also
covered in the demo for voltage
glitching we are typically targeting the
target's power source typically if
possible we tend to go directly to the
core voltage because that is a different
one that is used by for example the
external interfaces and we introduce
glitches some shorts for example to the
ground on the power Lane
there is an electromagnetic fault
injection emfi that releases big and
powerful electromagnetic pools close to
the chip surface and generates some
current inside of the chip die and could
flip for example some bits in registers
or in memory it could fastify the
information that is transferred on the
bus or there are for example other
attacks in photo injections like the
clock bleaching then for example we
introduce also again a glitch an
additional unexpected clock signal in
the external clock of the Target that
is out of the space range and enforces
for example the CPU to try to execute
the next common
why for example data between the
registers are not yet moved
so this is something that can be
exploited and there these were all
non-destructive attacks against the
targets but for example there is one the
optical fault injection where you have
to perform typically
um cheap encapsulation to have a direct
view to the chip die and use a focused
laser to the right point on the cheap
diode to the silicon and introduce
glitches and forwards to the chip with
Optical laser
how it looks like oh coming back to the
main graph here so this is a very
generic representation of the forward
injection there is something that the
timeline that exists in case of every
attack and there is a trigger point that
belongs to the given attack it could be
authentication probe it could be a
povertent it could be anything that you
can use precisely or as a starting point
to fix your attack in time and using
this trigger you start to count
typically precisely so there is no
Jitter enabled here to perform a
successful attack and you start to count
and after a specified amount of delay
you execute the attack and the attack is
depends on the forward injection type in
case of what is glitching the green line
here is the VCC the power of the
microcontroller or the CPU in case of
VCC and the voltage glitching you
somehow
insert glitch here this could be
injected in several ways typically a
very fast featuring mosfet is used for
example to short the VCC line to ground
and then basically for a very small
amount of time it
reduces the available power that is
available and can be used for the CPU
core and because of this it could
malfunction if it is too long data is
too long then there are built-in
electronics and detection that can
detect and react to the
unexpected voltage changes and could for
example reset the target itself so you
have to be fast enough to be sure that
your attack is not detected but long
enough
to have the right impact on the target
in case of emfi the attack is basically
the same the only difference is that you
don't Target the voltage of the talk of
the target microcontroller or CPU but
you introduce electromagnetic poses but
basically you have to follow the same
approach wait for the trigger count
until the specific delay then execute
the attack with the right configuration
and we will get back to this later
against the target
so
fault injection in Notch continued what
a successful attack could result in it's
very interesting because no one expects
this but a successful attack against a
microcontroller or CPU could easily
result in skipping an instruction
changing in data that is being processed
by the core so for example data that is
transferred from memory to registers or
the next instruction that is being
fetched before executed so these are all
folds that could happens and that could
turn the code and command execution to a
direction that is valuable for another
care so what one key what can we do
really with this so if you check for
example Some Loops that you introduced
in cool sections we will see it later
where you specify a point that what you
would like to exclude from the common
execution then you can turn the whole
firmware or code execution to a total
different Ray and May maybe because of
this you can bypass a security check you
can re-enable for example a log debug
interface
you can basically do a lot of malicious
stuff against the target
there are typical tools that are often
used to execute these Autos the most
well-knowns are the new AIS AES products
the GPS shift shelter Pico EMP tools
Pico EMP is a quite
a cheap one that can be also built by
your own at home so it is a DI DIY
friendly tool set and affordable for a
robust as well the others are a little
bit expensive
Solutions especially if you go for more
commercial and professional tools that
are available on the market but you can
also build your own
Solutions and I will show you on the
demo videos that how quite cheap and
affordable products available on the
market can be turned to effective
glitchers
so let's see how the glitching could
work against some sample code basis so
here we see two very trivial code Parts
one with regards to Firmware checking
and one with regards to authentication
checking before doing anything in case
of firmware checking for example when
the target has a second reboot and the
only boost the firmware that is
digitally signed and verified prior to
executing the firmware that could be
depending on the implementation a check
like this at the very beginning of the
firmware and it checks for example the
whole content stored in the Flash before
execution and checks the signature
whether it is proper or not and if not
then it gets stuck in an endless loop
still problem solved if there is a
unexpected custom firmware deployed to
the Target Hardware then no one expects
that the non-trusted firmware can be
executed right let's see that later
there is another solution here where
before executing a privileged
functionality we check whether the given
session or user or whatever else is
authenticated or not and only
access to that given functionality is
possible if the right conditions are
present but what if
we introduced forward injection and
Target these codes by fi in the given
sections so by introducing for example a
forward injection attack at that point
as we learned in the previous slides we
can
skip an instruction what happens if in
the endless loop I skip as a result of a
forward injection attack an instruction
that jumps back to the beginning of the
loop then we will break out from the
endless loop and continue the firmware
execution there
or what happens here
if the authenticated subroutine is
forced then basically scientific
functionality is not stored but if we
are able to manipulate somehow the
result of this
Evolution and get back a different
result because the forward injection
attack then we can get to this
functionality and call a previous
function without actually being
authenticated so this is why forward
injection is very powerful because
software based security can be bypassed
by hardware-based otaks
I have prepared two demos for you as I
noted one will be executed against the
threshold one Hardware crypto wallet and
another one will be executed against the
automotive UDS diagnostic service that
is running on a custom ECU so the first
one is to unlock the microcontroller
using the treasure one to basically
regain debug access and control over the
microcontroller unit with the swd access
the second one is to bypass an
authentication that is checked before
executing a privileged functionality to
in such case let us open a door in a car
uh important to note that these are not
novel attacks and no novel hacks here
these are just selected for
demonstration purposes and there are
some relevant work in this area that
were already done and
presented prior to this presentation but
uh basically in this setup there is a
total different tool set and
implementation and other approach to
Target this
so let's go into the details
I think all of you know this target this
is a Trestle one when on crypto wallet
open source open Hardware very nice
stuff by the way they have a very good
and responsive team they react to
security issues they are quite fast and
the development they did with the
firmware is very good so they they have
a quality firmware so from software
perspective it is very nice
uh there you can see also some security
features and content measures they use
for further information and details you
can also go to the official site and
check the details so
it could be a secure device by by
assuming that everything works properly
and appropriately based on the spec and
the definitions so let's see what kind
of microcontrollers they have and what
kind of security features it provides
the sem 32205 is a generic purpose
microcontroller basically it has a
security feature called RDP read data
protection read protection and it has
basically three different levels level
zero where there is no protection so
everything is allowed you can connect to
the bootron you can to the bootloader
you can connect to the
swd to the debug interface you can
refresh the content you can extract the
content and so on so there is no
protection there is rdp1
where the access to the debug interface
still exist but this is quite limited so
you still have access to the RAM for
example but don't have access to the
flash still you can refresh the device
but that will for first Purge and most
Aries the content and then you can write
a new firmware to that
most important info is that firmware and
store secrets in Flash cannot be
extracted and there is level two a
complete lock and the hardened version
then everything is logged and protected
it is not possible to connect to the
bootloader it is not possible to connect
to the debug interface and the Flash is
of course protected
so beside protect it it is irreversible
I don't know how much it is readable but
as soon as you turn your microcontroller
to rdp2 it is irreversible as per the
data sheet
another important thing is that the
status of the RDP is coming from option
Buys in case of option byte a a this is
RDP level zero no protection c c that's
level two complete lock and anything
else but AA or CC it is level one
so what can we do with this
would be
to downgrade somehow our Target to rdp1
because a single bit change from CC
[Music]
anything will be changed from CC will
let us downgrade to RDP 1 or if we are
super lucky then
to RDP 0 but most probably to rdp1
so let's see what can we do with this
this is how a booting of the
microcontroller looks like and there is
a bunch of information here I'm going to
explain the details so the option bites
in modern microcontrollers and
configurations tend to be stored not in
fuses that are just configured one time
but in Flash
so they are referring sometimes to them
as fuses but actually they are not fuses
they are stored in Flash that will be
important later the boot process looks
like this in case of a microcontroller
whenever it receive a power it starts to
prepare the internal peripheral
peripherals and the whole architecture
for be ready for execute commands as
soon as every internal started buying
configuration is ready the reset line
the negated reset line from low goes to
high and this is the point from where
the core of the target the CPU starts to
execute commands so the yellow line is
the reset line that you see here the
blue or grayish line is the voltage of
the core of the target so as you can see
as we
hit this point when the microcontroller
started it starts to process something
and the pattern changes here and here
basically there is a boot room burned in
to the microcontroller so it starts to
execute the boot run for first and after
that it reaches a point
here it will start to access the Flash
and load content from The Flash and
because accessing Flash and reading out
information in the flash is consuming
more power this is why you see different
uh voltages and the bigger fluctuation
on the voltage line it is important to
note that to get this kind of
information you have to remove some
components from the board because
decoupling capacitors usually flattened
now decoupling capacitors have the
target to be stable even if there is a
small variance in the voltages but that
is for us for analyzing and for attack
is bad because capacitors are working
against us so we have to remove these
decoupling capacitors at the right point
and now we can see something like this
and we can perform attack effectively so
here we know that the most probably
Flash access is happening probably it
reads the configuration and option buys
here and after that if everything is up
and running and the configured according
to the store settings the application
code the exother firmware is started to
be executed so we have from the actual
start of execution of the bootstrom to
The Flash access about 200 microseconds
to rate so this is probably the time we
have to wait until we execute the attack
then we have this amount of time which
you can see the horizontal scale is
about 50 microseconds and this is about
one slot so it is about a 50 microsecond
slot
to execute the attack the glitch itself
and let's see what I think what we can
do with this and how to achieve that
going after the details in the data
sheet you can see how the power supply
looks like a power supply chain look
like and the Target and basically it can
be figured out that there is a point V
cap one and vcam 2 where we can
basically have direct access to the
internal course voltage so if we have
access to these capacitors that are
installed to that pins and remove those
then we can perform glitching directly
on the core wattage that is very
important because other voltages
provided from external pins other than
these pins will be sent through the
internal voltage regulator that will
basically filter out kind of our attacks
and glitches and we need to directly
have impact with the better results and
the better
quality glitching directly on the canal
the CPU
so going after the data sheet the
schematic and the PCV because it is Open
Source Hardware it is quite easy to
locate the right config right capacitors
at the schematic figure them on the PCB
and also identify all of those
additional points that will be
interesting in the autok so we need svdx
access for the debug and we need the
core voltage to Target basically the
device so this is what you can see here
the interesting points and capacitors
that need to be removed additional ones
for example installed to the reset line
needs to be also removed because it has
direct impact on the curve on the reset
and as we are planning to trigger our
attack to the reset the this capacitor
also works against us so after removing
these components a picture for the scale
so you have to work with this kind of
small SMD capacitors or even smaller
ones the target is ready for being
evaluated and
just a pro tip because I ran into
troubles previously sometimes I always
use a Target device that survived your
preparation and don't spend hours on
debugging on why the target chip did not
react to the attack
so
let's see how the test setup looked like
and I hope you understand now why I did
not provide you a real life attack here
this is not that kind of setup that is
easy to move or transfer very
stands off to every move and uh short uh
small changes so we have basically a
Raspberry Pi that controls the whole
attack it has a Jupiter notebook running
from there with a custom python script I
can control everything
there is a threshold one of course which
is the target
fpga this is the istick development
board where I have a custom verilog and
a bit stream downloaded to the fpga that
is acting as a precise timer to from the
trigger to execute the actual glitching
there is a duty interface that I'm
running
as the GDB server server this is
connected to the treasure one it runs by
the way at this setup Blackmagic probe
open source firmware and this is used to
access the debug interface once it is
unlocked there is a glitch in
electronics which contains the analog
multiplexers to fast switching between
different input voltages and antenna
mosfets to let us short the voltage to
ground
and of course we have some oscilloscope
probes connected to the right and
interesting points to trigger to watch
how the the setup works and how the
process is going on
so quick recap on on the setup and how
it is being executed the attack the
Raspberry Pi controls everything it is
connected to the remote GDB service on
the Dual board the fpga is configured by
the Jupiter notebook as well and the
Raspberry Pi is also responsible on the
power cycle of the target so whenever it
is needed after executing every attack
it turns off and on the power to the
Target
and the fpga as soon as the MCU is
recovering after power on triggered by
the reset line starts to count and after
hitting the garage delay right delay it
will control the glitcher electronics
and in their right glitch with changing
pools lengths and changing delay to the
Target
so this is how it looks like
and let's see
the demo
so the demo
yep
so this is a test setup
does it run
oh come on
okay
the test setup that contains basically
the Jupiter notebook the external camera
for the Target and what I do is
basically walking through on the custom
code I implemented here just executing
them this is just kind of some kind of
function supporting the target here I
open basically a GDB session for the
remote service and they're basically
just checking whether SVD is available
at the moment or not
and hopefully it will confirm us soon
that
yes as we the so the debug access is not
available so we are going forward these
are really just supporting stuff for the
fpga and configuration and this is the
settings that I use in the big Loops
that iterates over the various
glitching settings with regards to the
delay the repeats the pools with changes
and so on so after executing the
effective Auto at this point you can see
that the scope started to change and
update
the waves and the treasury started to
reboot so after every glitch attempt the
target is rebooted and the glitch
setting is iterated to the next one and
the other continued continued continued
until we finally reach the attack so our
the center line is about 200
microseconds from the trigger this is
zoomed in the cold wattage unfortunately
because of the light this is not that
visible but there is a big drop down
here close to ground in the course what
if this is the glitch that we introduced
and we are triggering on the reset line
and basically we are continuously
increasing the delay from the specified
specified amount of time the width of
the Poor's length and so on and we are
iterating over and over and over on the
configuration and here I am speeding up
a bit the video because there are two
time consuming part of the forward
injection attacks one is the preparation
and another one is the execution wait
until it gets succeeded so and this is a
very well fine-tuned people the
environment so I made a lot of
experience to find a sweet spots
so usually you leave your environment
and the equipment even four days or
weeks to find the right configuration
so getting closer to the
end of the video hopefully somewhere
here
we will find a sweet spot where our
Target finally found swd access on the
target so it is now the common execution
stopped because we attached our debugger
to the Target so using the GDB session
I'm now executing done binary memory
command and basically dumps out the
memory of the content and what you can
see it is loaded back from the dumped
file this is nothing else but the USB
class memory structure that you can also
find for example in
the treasures code
so what it means
we successfully done graded rdp2 to
rdp-1 got access to the Target
microcontroller which provided us
partial access to Parts like the Astron
in such case because of the fender
version running on the trezor was not
vulnerable no sensitive information was
accessible in this trezor however
private versions of the firmware are
suffering from different vulnerabilities
that makes act access and extraction of
sensitive data like the pin or the
passphrase
possible with this kind of access so
unpatched Hardware unpatched resource
are still vulnerable so with the updated
and patched versions you might expect
that you are safe but there is another
way to move forward because as
introducing an additional age and for
example Auto King the bootloader itself
and the bootloaders read memory command
you can basically bypass the security
checks applied on the read memory
command that checks whether you are an
RDP 0 or rdp1 and extract The Flash
content and from that moment if you are
not using passphrase on the treasure
then basically it is quite easy to Brute
Force the pin and
access the sensitive information there
important to note that it was just a
good candidate the Tresor to demonstrate
the talk and the effectiveness of such
an attack
but it does not directly belong to the
treasure it belongs to the
microcontroller and every product that
is using this kind of microcontrollers
or other microcontractors that are
suffering from the same attacks
so let's move forward and talk about
emfi
electromagnetic quality injections
and I'm trying to speed up to make sure
that we can fit into the time so we are
targeting the ECU that is a small
component in a car in such case to do
not harm any vendor
we are using our own ECU that we
developed for our car hacking training
environment but basically it runs a
similar feature similar functionalities
it has a diagnostic xtp anything else
that are often used in automotive and we
are trying to attack this because in
diagnostic there are protected and
sensitive routines and functions that
can be called only after a successful
authentication via security access and
we are trying to bypass the
authentication on this so quick security
access one-on-one just to understand
what you will see on the packets
basically to the challenge response base
the authentication
the seed that is used for that is a 27
so basically this is how it looks like
the client and sends 27 plus the
security level identifier
like 2701 for that the server responds
with positive response which is always
hex 40 plus to the request instead so 27
x 40 meaning
67 so 67 then repeating the same value
and something that is in such case the
seed so this is a seed that we received
from the remote service and the client
then calculates the right key for the
given seed and sends out the secret
security access send key message with
the right key to the Target and if the
authentication was successful then the
target response with 270 to otherwise
depending on the situation an error code
starting with 7f will be received from
the target so this is very nice this is
Automotive protocol uh you are almost a
car hacker now so how to hack this what
if we introduce a glitch here somewhere
here because there should be after
sending a key some kind of validation
check against the authentication probe
and if there is something like this and
we try to hack this with faulty
injection then if we successfully bypass
that check then maybe we can
use an authenticated session later to
execute something interesting
so with regards to mfi
it needs a bit of experiment and mapping
of the target before a valuable attack
can be performed so usually you have
amfi tool with a tip at the end this is
the side view this is the top view so
and you have to find the street spot the
street point on the microcontroller
surface where with the right settings
that belongs to the voltage you use to
generate the electromagnetic boost the
Boost length the repeating pattern the
length and distance from the physical
representation of the
microcontroller unit and and the surface
is is all accounting and all needs to be
considered and checked so there is a lot
of experiment that needs to be done
usually the best effort is to run a
customized firmware on the same chip in
a test setup with the automated tool
like XYZ table on a small CNC and as
soon as you find the right spot then you
can use the right settings on your final
Target by moving to the same location so
this is the
nice small setup how it looks like there
is a small CNC what I noted to you the
ECU there the Raspberry Pi that I
already noted previously
we have a dude can interface that is
basically performing most authentication
probes against the target so it performs
the security access seed request and
then a key send messages we have the
fpga for the same purpose like
previously we have
um
yeah
this is the heart that triggers this
year so as we are dealing with uh emfi
so electromagnetic pools there is a big
risk that something could malfunction or
be damaged in the closed proximity of
the device so there is just additional
separation from the custom fpga and
between the chip shelter emfi tool so
even the trigger is separated with the
additional Electronics
uh we have the target issue as I noted
that is coming from our car hacking
environment there is a Servo connected
to it so it represents now the door lock
and the chip shoe shelter from new uh a
AE and the USB can interface that is
connected to the Raspberry Pi to let us
execute Commons through the canvas
connection if we succeeded
so
the overview of the setup and the
execution flow is the following
basically the cheap shelter the fpga
and everything is controlled by the
Raspberry Pi the same Jupiter that
uploaded with a different code and
Raspberry Pi launches basically data by
allowing dude can to start the
authentication after sending out the
authentication probe to the can bus the
dude can also release is a hardware
trigger to the fpga the fpga start to
count as soon as it reached the
appropriate amount of delay it basically
releases the chip shelter which fires uh
electromagnetic pools and if everything
goes well then a dude can recognize
that the authentication was succeeded
even if it used the same fake key every
time and as soon as this happens it
informs the Raspberry Pi which at the
end of the day let us know and we can
execute the previous attacks this is as
easy so let's see it how it works in
practice
so basically the same setup
excluding that we have a terminal here
where I'm dumping and filtering for
it's not
for the cam messages and you can see
that I'm switching to external
diagnostic interface and try to open the
door with the routing control but as you
can see there is a 7f which is a good
indicator for the error code because of
lack of authentication it wasn't
possible and by executing basically the
autok you can see how the
electromagnetic poses are injected to
the Target we are continuously
monitoring here what is happening on the
canvas and as you can see the patterns
basically 270 ones are sent out then we
receive different seats than 2702 with a
free key fake key one two three four is
sent out for authentication probes and
basically we always receive 7f error
codes that authentication was failed
until
if you zoom out you you will see that
compared to the trigger there's a lot of
time it passes before we execute the
actual attack
and finding the streets point
fee sweet spot is Just Happening Here
where basically
the appropriate settings
and the Magnetic boost targeted and
released against the microcontroller let
us
be authenticated as you can see we get a
positive response there
and having this access we can easily
jump back here and execute the same
command which
opens the doors for us
so this way we managed to bypass the
authentication on the unified diagnostic
service
so as a quick recap basically both the
emfi and voltage greeting provided us
ways to circumvent the security
implementations made in software by
attacking the hardware itself there are
ways to improve the security for example
limit the number of atoms or security
access and so on but UDS can be targeted
in a different ways so for example there
is the read memory by address where you
can unleash the is authenticated checks
for example to achieve this as a results
and the final thoughts about the
hardware hacking of these targets and
default injections
especially the emfi and voltage
glitching is that these are
attacks that are feasible and
valuable attacks and should be
considered by Jeffrey van door and there
is no secular
device no secular product with just only
secure software you could have the best
and the most secure firmware ever if
you're underlying Hardware is vulnerable
for such an attack because in such case
fault injections are the one way to
circumvent this kind of implementations
in Security in software there are some
software related mitigation
possibilities to introduce for example
multiple redundant checks in condition
checks or store
critical information with their
compliments and always check them
against each other then you are
evaluating them this can pinpoint
issues then that are introduced by
forward injections and you can react to
them appropriately however it is
important to know that these kind of
mitigation is always Target the
application remember itself not the
hardware software that is the beauty
inverting
bootron for example so you can maybe
enhance the security of your firmware
and it will be more resilient against
these kind of attacks but if the
underlying microcontroller and this boot
room is still vulnerable to forward
injection attacks then maybe the Auto
Care will focus on that to get full
control over the device even before your
firm is getting being executed
so that was it I think I run out a
couple of minutes
about my time so thank you very much for
your attention and there should not be
time now for questions but you can reach
me reach out to me at the Deloitte boot
if you have any questions later on thank
you very much
[Applause]