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/867 Thanks!
A warm welcome to you all, and
especially to humorous will now talk
about the avatar to
reverse engineering framework for Fermer.
Thank you.
All right.
Thanks for the introduction.
I stated, I Marios, and I'm here
today
to talk about Avatar
two.
I develop it as
part of my Ph.D.
studies
over at your home.
And if I say
Avatar, I don't refer to
a movie by James Cameron or a metal band,
nor I refer to as actual Avatar
two framework.
Let's see how I
try to communicate
with you about the framework.
So first, I want to tell
you a little bit about binary firmware
analysis of general
want shortly to discuss the Turing
landscape, to
see what other people have done
and are doing.
Then I actually introduce the
high level concepts of Avatar through
to framework itself.
And in the end, I'm going to
give you a couple of examples to show
how the tool can be used and
is used by us, in fact.
So let's not restrict
binary film analyzes.
Why are we interested in analyzing
film well for better devices?
Well, as we know, the amount
of embedded devices is steadily
increasing. Day by day words like
Internet of Things and so on are around.
In the end, these are just interconnected
embedded devices.
Misconfigurations, box
and vulnerabilities are common on those
devices.
And I would say that
a majority of the reported wounds
we find so far on those devices
are mainly misconfigurations
on low end fruits like
disclosed private keys.
This configuration and the web server, or
just simple box in
the web server itself.
However, we hope
that in the future
someone is going to change and renders
maybe secure their software more
and then would need to
actually hunt for more complex
box, which are also still
in there and film will.
However, when we want to find
more complex box,
we need more sophisticated
tooling to succeed.
Of course, we
can sit down and reverse engineer
a long time, but at some point in
time, tooling will greatly benefit us.
However, there are especially
compared to desktop systems.
A lot of
challenges present for firmware
analysis.
First of all, there are a
variety of platforms.
There were riots of different parts
system
on chips, which all comes with their
own memory layout
and their own hardware peripherals, which
may be mapped at certain addresses and
may behave completely different on
other devices.
Furthermore, there's often no operating
system level of abstraction.
Some of the film will do is
based on Linux.
However, there's also a lot of
monolithic firmware around which
just use non kernel at all or
have some small, tiny
kernel embedded systems.
In both cases, the
hardware interactions will be embedded
in the firmware
court itself and not
as part of the kernel.
This forms actually a problem because
when the firmware X's hardware is what
might be, we are memory input output,
or it might receive
interrupts from the hardware, for
instance,
where new data is available on a bus.
We need to
somehow fetch it in our analyzes
and our tooling.
On top of that, there are just a
variety of architectures
like not only a lot of platforms, but
also a lot of windows and architectures
are around
while we have on desktop systems,
mainly
x86 and x86 64
around
on embedded devices.
So we can have all the different
architectures from MIPS, PowerPC,
even sometimes SPARC.
And just
to give you
one example, please don't attempt to read
the next slide.
This is just a list of the
microarchitecture as defined by ARM.
And this is just itself,
not the third party windows for ARM,
which made it system on
chips.
These are around 30
different micro architectures, all
with tiny differences
in the architecture, which is quite
sheltering to grasp in
a generic tool.
And there are even
more challenges which we are facing in
comparison to desktop systems.
Biden Reanalyze was on desktop systems,
normally greatly
uses
instrumentation,
sort instruments, the software
on the
test or the analyzers to
add certain hook or address any type, for
instance, checks during RAM times that
everything's
going fine and on a better device.
This was challenging due
to two reasons.
One. Again, the
missing abstraction
of the operating system.
And furthermore, quite often, the court
only recycles inside read
only memory of a
embedded device.
So what does this mean?
Read only memory.
We will need to flesh it to change its
contents. However, then on the other
side, from where it might be
encrypted or signed by the window.
So instrumentation is
harder than our desktop system.
Likewise, emulation is challenging
while on
modern desktop systems, all abstraction,
all hardware to actions is handled
by the kernel, which can be easily
obstructed by an emulator.
We don't have this
comprehensive
possibilities for embedded devices.
The reason for that is that there are a
lot of peripherals around which
are active
differently with the hardware,
and as a result, am you
being able to emulate
all of the underlying hardware?
Also, a better device is
a lot of implementation effort.
Likewise, fall detection
when we, for instance, fastest
desktop systems, we most
often times rely
on observable crashes like
segmentation, fault or
error handling of the life of
Lipsy for heap corruptions
and so on. So we get a physical output
or we got a notable, not noticeable
output when we corrupt
memory
on firmware. This is different.
Firstly, even line
of Linux based embedded devices are
not well. Most of the times
are not utilizing Lipsy,
so heap protections are
way, way smaller, if
present at all.
And some devices
may not even contain about a
memory management unit,
which at the first place enables the
notion of set false or invalid memory
accesses.
So in this case,
the film might just continue to be
executed or
to be corrupted the state of the program.
Another big issue is interrupt trembling
because a lot
of film is basically designed in
a way that it runs continuously
inside a single main loop
and
just checks memory contents.
Source memory contents are
updated by interrupt handlers
and will derive
the execution pass of the main loop.
Once triggered,
if we go with static analysis,
we will need to define
where those interrupts are triggered.
Furthermore, as we saw before,
there are a lot of different mid-quarter
architectures around, and micro
architectures have a lot of
small, tiny
changes and single
instructions only present to this
microarchitecture.
I mean, for instance, co-processor
accesses on arm costs
are very varying from
core to core or from microarchitecture
to microarchitecture.
So this showed
a little bit of the challenges
we have in the field of dynamic firmware
analyzers.
Let's look at the tooling landscape.
Compared to
desktop surface systems,
the tooling landscape is due to the
challenges way smaller
and especially
smaller when only considering open source
tools.
Furthermore, while
a lot of static
analyzer systems for desktop systems
exist,
they may exceed
the bounds
when being applied to embedded firmware
because they need to approximate
environment, which is not
always possible in the embedded case.
And it is also possible to
infer the behavior of peripherals and
interrupts
in the following.
I will show you for open
source tools which are
aiming to analyze firmware.
So obviously this is not a
comprehensive list, but gives a glimpse
of
what have been done and what kind of
different approaches are out there.
So let's start with Phi
Phi as symbolic
execution engine for MSP
for 30 firmware, which was based
on clear so clear as the
main symbolic execution
framework here, which
basically operates on the LVM immediate
representation.
In order to have fire working, the
analyst needs to specify
explicit analisis memory
and interrupt specifications.
The analytical specification hereby
defines, among others,
the memory layout of
the firmware under analyzers.
Furthermore, the memory
specification.
Specifies how memory should react
when it's read to read from
and write
to. So this is
basically a way to abstract memory
ill so that one
particular memory cells are accessed.
Symbolic value or specific concrete
values can be injected into
the analysis.
The interrupt specification is
wealth defining at
which points
interrupt, quote unquote, which
interrupt handler shall be executed.
While this is a great work which
don't need any presence of a physical
device and could successfully
analyze, quite so, there must be 430
film where it required
the presence
of the source code of the film, because
that's basically the way Hulk
works.
So unfortunately,
source code is not that
often
available when we are analyzing film
well.
So let's have a look at
binary analysis tools.
First, there Film a Dying,
which is a binary
analysis
framework based on
Kohima popular full
system emulator, which
also enables
use of space emulation of signal
processors.
However, in this context, Kojima
is Houston's full system emulator
and brings a lot of
architecture which can be emulated
and additionally,
a lot of hardware bots
or hardware layouts,
former die targets, armored MIPS firmware
and specifically and uses
an
instrumented Linux kernel.
So basically, it takes the extracted
Linux based firmware, puts it
inside the chemo emulator,
and
runs it with their own implemented
kernel.
This kernel allows automated
analysis what allows plugins
for allows analyzers off
webpages and secure network monitor
protocol implementations.
Additionally, interesting is that this
framework has capabilities
to automatically rule
known exploits, mainly known
from Metasploit against
the emulated firmware.
And quite interestingly,
a lot of exploits
found on one devices can be propagated
to other devices,
which basically means that there's also
a huge code base shared among different
kind of embedded devices,
at least on the Linux based world.
Yeah, unfortunately, the downside here
is that it's only work for Linux based
firmware and only if there's
not two specific kernel modules around.
Because if somebody's device needs to
do hardware to actions this remote
or
specific hardware
peripheral, this will most likely be
done. We are specific kernel modules,
and if they can't be emulated,
Coumadin fails to succeed.
Another interesting project, which was
released this year is Lua Keemo,
which is us the name kind
of suggests,
also based on XML.
It is considered a work in progress,
and the example released together
with the tool was targeting
BCM four three
five eight chip's firmware.
So these chips are
wi fi chips
used, for instance, in a lot of
smartphones.
They are enabling
Lower Kimo, the prototyping of custom
hardware platforms or bots, and
Chemo Dragon with Lua, and
also at
instrumentation capabilities based on
Lua for different events inside
chemo.
Unfortunately, this
only emulates the firmware alone,
and there is a lot
of hardware interaction going on,
especially during initialization
function. This requires either
a lot of modeling or trial
and error to
prune out execution parts which are not
relevant for the analysis
or for the analyst.
So the last tool I
want to talk about is Avatar,
the first one.
So some of you may have thought
if I'm talking about Avatar two, there
must have been the first avatar.
And this tool
was based on S3, which basically
is again a combination of Kojima
and Leave, which allows
symbolic execution
from key, more emulated firmware.
Additionally, Avatar utilizers
utilizes Mozilla and GDB
and allows partial emulation
of ARM
firmware.
So was partial emulation.
It's basically means
that the
firmware itself or parts of the firmware
itself.
Run on the board on
inside simulator emulator
and specific
hardware requests
like a memory deal are
forwarded to the actual physical device
we as a collection of or more seedy
and GDB.
Additionally, Avatar provided
way for ways for orchestration
so that you can, for instance, start
executing on the device, then
transfer the important
states or the important memory layouts
and through rigid US inside the emulator
and continue execution
inside the emulator inside
S3.
This allows basically to skip
all
the initialization function of a bot
which are not interested an analyzers.
Additionally, and quite obviously,
as S3 is using CLI, it also
brings symbolic execution
and selective symbolic execution
for firmware.
Unfortunately, Avatar one was
heavily tied to the S2 infrastructure,
and it requires in every
set up
the presence of the physical device
to succeed with
was the partial emulation.
So what did we learn from
looking at those four tools?
First of all, there's a lot of focus
on the
architecture of
them, really.
The majority of tools utilizing
Chemo's emulation capabilities
as
a basic block for building
up the framework.
Unfortunately, the resulting frameworks
are then heavily bound
to chemo so they don't see
any ways or don't define
any ways to
get to analyze or stayed
off the emulator into another tool.
This missing
way of transfer in states of
analyzers is at the same time,
a little bit the motivation
of the avatar to framework.
So in a very big picture,
it's a framework for a
dynamic multi target orchestration
and instrumentation.
We will see what this means with lifetime
was later on.
The focus of Avatar is on firmware
analyzers, and the whole thing is an
open source
and titan based framework,
which we
released in June this year.
So it's quite new and it's
a research project, so
we try to have a clean
and usable code base, but
sometimes some
things may be a bit fragile
in comparison to Avatar one.
Avatar two
was redesigned and we implemented
from scratch to especially focus
on better usability and
a better abstraction
of targets.
It was developed by the Software and
Systems Security Group at Euro.
Com specifically next
to me.
The main developers are
on the Easy or William Frisian and
David Aboutwhat.
The main goals, one we designed
and started to write
Avatar were to have
the possibilities of target
orchestration, separation
of execution and memory and state
transfer and synchronization
capabilities,
target orchestration means
that we orchestrated
different kind of frameworks
with abstractions inside patents.
Those targets could
be anything debug emulators,
other frameworks, and we easily want
to be able
to add new targets to the Avatar
two ecosystem.
Furthermore, we want a clean separation
between execution and memory
because this is basically the
core concept,
although the main requirement to
allow AI or for warding
or remote memory so that the analyzers
runs inside one target and
operates with memory of another target.
Furthermore, state transfer and
synchronization is important to
us because once we are starting
to analyze those and one specific target,
we don't want to
keep the analyzes local to that
target. We may be or may
want at a later point in time to switch
to execution, for instance, from
an embedded device to
an emulator.
And for doing so, we need easily
easy ways
to transfer the state.
So we came up in the end
with a framework which basically consists
of four components the
Avatar two Core, which is
a patent library and
is the main interface
from the analyst to the analysis
inside the framework.
There are
the so-called targets, which are the
patent abstractions of so-called
end points
and hereby are
all
the things you you want to
have as endpoints or emulators
frameworks.
Teabaggers, however,
targets and points are not
talking directly to each other.
They are
just interconnected by an additional
layer of so-called protocols,
which we can also see here.
And this picture where we have
the avatar to call
at the top, which defines and
orchestrates a set of targets
which all talk we are execution
protocol, a memory protocol
and request a protocol to the distinct
endpoints.
So the question is why
did we add the abstraction
for protocols?
The idea is quite simple.
A lot of
tools actually have
similar ways to communicate.
For instance,
both key mode and almost
Edee offer
a GDB server to talk to the analysts
for a framework or to the
software under analyzers.
And by separating the protocols
into purposes like
execution or memory, we
allow
the clean separation
of those different concepts during the
execution.
Oops. So let's move on
to the implementer targets, which
could
also be a
small cross of know your open source.
MASCOT's on the top left.
We have Zarqa Fitch, which
was actually the
mascot
of 3TB,
which was quite interesting because this
pushes users to
spit or total spit water
from another water or face above
and shoot at single box and puts them
down. So I think it's quite matching
mascot FAU-G to be
on the bottom left.
We have quibble, which is
the full system emulator.
We just talked about a little
bit more
on the top right there, a of framework,
which is a reverse engineering framework
based on Cremer and
aims to allow
repeatable
reverse engineering.
It does so by basically
recording all
the non deterministic Io,
adhering
to the software under emulation
and then later on those non
deterministic I can just
replay to the very same stuff software
from the same initialization state,
which will result into the
same execution
that went edge of doing so
is
that the
resulting memory footprint of a record
is way smaller than
instruction or memory trace.
Additionally, Ponda allows a plugin
system which
allows to hook different functions
or different events inside Keemo to
add phone analyzers.
The last tool on the slide
is the anger framework, which is,
as of now
still under development, will
be made public or will be merged into
the public branch
soonish.
And anger is basically
a symbolic
execution framework,
which
provides quite powerful symbolic
execution entrance capabilities.
Sorry.
Oh one thing I forgot.
We also support a fifth target, which is
not represented on the slide, which
was almost
a tool
to talk to JTC interfaces, which
then in turn can talk.
We are the gateway protocol to embedded
devices.
So just a little bit of background
knowledge. J Tech is
debugging port
present on some embedded devices.
And if it is available, we can use
Mortada to dynamically debug
firmware on the target device.
As we've seen before, a lot
of tools are based on XML.
So if we want to
have them easily integrated
into the Avatar ecosystem,
we
need to have our changes of more or less
locally. That's what we did.
So we changed Khemu a little bit to work
with Avatar and to forward to state
and memory and so on.
And all of the changes
are located in one single
sub folder, which make
it
straightforward to implement new KHEMU
based targets for Avatar two.
More specifically, the changes which we
did or the most notable is the addition
of a configurable machine, which is
similar to the
Lua based port description
present in leukemia.
But the here by
the configuration of the hardware
we want to emulate is
defined in adjacent file,
which was automatically
generated by Avatar two based on
the specifications and I-listed and
Python.
It allows, in general,
flexible configuration of
two different hardware you may want
to emulate.
Additionally, we added new peripherals
Avatar Peripheral, which communicates
with Avatar two.
We are politics message cues
and basically allows
the remote memory from inside chemo.
So the idea is that if chemo,
or if there is some peripheral
was memory mapped, i o which you have to
emulate, you will use the avatar
peripheral, which will then forward
all memory reads and writes to the Avatar
two framework, which will then dispatch
it, for instance, to the
physical device.
A couple of other features I want to
highlight about the framework is
that we
aim to design
architecture independent.
This basically means that we
have for subfolder inside
the framework, which just deals with
architecture abstractions
so that the framework can work with those
architectural abstractions laugher to any
analyzes.
As of now, we have
abstractions for ARM x86
and 86 64,
and we are currently
developing another one for MIPS
Avatar to use as an internal memory
layered representation.
So just to lay out or not some memory
contents itself in order to be able
to
push it to different targets or to come
to the adjacent
file needed for the key,
more configurable machine.
Furthermore, Avatar allows modeling
of peripheral worlds
directly in Python so
you can move on and
script your peripheral directly
implies if you know how it has to behave,
or if you just want to have something
which statically returns the same values
because you don't care about the specific
peripheral.
Additionally, we want to keep
our Tatu Core a small and
maintainable as possible.
But on the other side, there are a lot of
tasks which are
which have to be repeated during and
analyzers.
For instance, we frequently want to
assemble or disassemble instructions.
So in order to enable it, we
added a flexible plug in systems,
which also has already
a couple of example, plug ins, for
instance, in the orchestration plugin,
which automatically orchestrates
the execution of targets
in the normal way.
You would write
an avatar script, you explicitly
define which
when you did what.
When you do
what. While in the
orchestration setting, you will just
define a set of transitions, and Avatar
two will automatically
change the state around
according to your defined transitions.
Likewise, there's an instruction for
water, which basically.
Aims to deal with those and emulated
instructions, so small micro architecture
depend on instructions.
So once Avatar encounters one
of those instructions, it were
not executed inside emulator, but
on the embedded device.
So that's a state changes.
At least they're accordingly.
So after this
kind of
high level talking about the framework,
let's go directly to the
examples
I will
and the following sure to use
cases how to use Avatar as
dynamic instrumentation
framework and
how to use it as dynamic
orchestration framework.
So if you want
to write an avatar script, you normally
need to do three or four things.
First, you need to create the main avatar
object.
Then you need to refine the set of
targets you want to deal with in your
analyzes.
Optionally, if required, if you have
more than one target or KHEMU based
target, you need to define a memory
layout.
And last but not least, you need
to specify an execution plan.
So let's start with a
simple demo,
which basically is a demonstration for
Hello World.
So we have
here on the left, I hope the font is
big enough for everyone to read it
an executable file 8ot out
and
Python script helloworld or pay, which
we should see here also on the right.
So if we execute
a note out,
basically nothing happens.
Just exits with the error code
42
on the right side.
We have our full analysis
of what analysis of instrumentation
on one side.
So a step
zero, we create the avatar
object and defines architecture.
For those analyzers, we add
the
concrete target, which is in this case,
a GDP target.
Then we not only
etc. but
as
a sub process.
The end points the GDP server where
our avatar target connects towards the
end,
which was basically just
executing this old
file.
We initialize the GDP
target, which will
connect to the GDP server
and does all the initialization
functions.
Down here we have some shellcode which we
want to inject into the target.
This shellcode is basically
just a show called for
the simple Helloworld
output on steady order.
So it basically just us.
So it's called right helloworld.
Here is the interesting
part of the framework we
instrument GDB from the outside
we had was to write memory.
That's the current
location of the instruction pointer.
The memory we rewrite has the lengths
of our shell. Called is our shell code
and
raw memory
after we wrote this.
We want
to continue our
execution.
So let's see
the demo
gods with us.
And here we go.
We had Helloworld as an output.
Well, this is just a very simple demo.
It directly demonstrates
the instrumentation capabilities
of Avatar two
and especially what
what what I really like is
the possibility to script really be
from the outside like without being
without having to execute your
Python script from inside 3D.
So you
can say here on the right
side the full analyzer, so you're
doing a centralized in one place.
Let's continue with binary
instrumentation on a real
target,
a real target.
We choose Huawei,
which is a pure
rootkit, which
was presented last
year at the ISS,
and it basically
injects or basically
works based on code injection
on, yeah, normal commercial off
the shelf policy.
The policy itself has multiple board.
We can have a look if everything
works and we can see it.
So.
No, no.
Here we go.
So this stone here is
the open policy,
which we can possibly could very shortly.
Well, most of the right one.
OK. Sorry for that,
I forgot to do it beforehand.
OK, so
so this
demo is very fragile, which
was going to show up.
But here we basically have
our P.A. starting to
boot. We see several bots
here, here
on the side. We have human
machine interface
port, which basically deals with
all interactions to the exterior worlds
like SD cards, a physical switch, the
network interface. So you would be
interface
on the top here.
We have the
ideas for this programable
loader controller, so here you can
connect the different aisles.
Right now, all the policy is booted.
Everything that's fine.
It has no also detected
all the status LEDs here for different
aisles.
To say about
what's special here is that on
lower board, which we can see here,
it's a Cortex three
MCU, which is just responsible
for dealing with updates or
mainly responsible for dealing with
updates of the exterior road.
So updates of the
state
and this quoting some
MCU, interestingly, also
has enabled J
Tech Dybbuk Port so
we can easily sort out
some things and have here
on the side
our J Take Interface Connector to this
policy,
which will lead us to
the demo.
This device is particularly interesting
because parts
of the firmware are residing inside SRM,
so the board initialize us
and so we don't have perfect
and firmware is loaded
into into
the
SRM.
So this basically means
we can instrument
those parts of the firmware,
which we also did
in
the by re implementing the proof
of concept implementation of
hardware.
So here we basically do the same
creator IoT object.
Lots of assembler plug in
at an automated target
set a breakpoint at the main loop
because we want to skip all the
instruments, all the initialization
function.
We continue our execution until
we eventually
hits the spray point.
This is done, by the way,
and once we are here, we are going
to inject some assembly code.
So this assembly court is rather simple.
A state of just a proof of
concept implementation of the hardware
may were not full implementation,
but it already shows, well, we'll
show that
we can
divert the execution so that
people see the human machine interface
things.
Certain inputs are enabled
and we do so by hooking an interrupt
handler, which was executed
frequently to check the state of
the board and
modify the state manually.
So let's see if this
works.
I think I forgot
to mention to say that we try to have
both Python two and patents we you
a comparable code.
So let's use the latency python
in this example.
And here we go.
OK. So the camera is now off, so I
cannot show you, but
on here
to let's started to blink,
which basically symbolizing
that input is
present. Also, clearly no input is
connected to this policy.
I added a picture of it
just to be safe said in case just
or doesn't work, we can see it.
Let's move on
to the next example,
which aims to improve
fall detection on embedded devices.
This work is part of the
what you corrupt is not what you crash
paper by our research group,
which will be
presented at the Oscars next
year and
is a joint work on Siemens.
In parallel to this
talk, we uploaded so slides
so you can go and check out the paper.
If you're interested in more details of
what I'm going to say here.
In a nutshell, this paper investigates
the challenges specific to fast testing
embedded devices, which are,
on the one hand, fault detection and
instrumentation which we already
talked
about. But additionally,
one additional problem is scalability.
First, testing greatly
benefits from having the possibilities
of running
multiple
instances of the same fast.
Also, same software and fostered in
parallel.
This, in the better case, would mean
that you need a few test, traditionally
just a lot of different embedded.
Weiss's and
furthermore, in the paper, we
evaluate different strategies
to aid first testing of embedded devices.
For instance, for
the query hosting
static instrumentation or binary
rewriting.
And in the end, we try to
give
some approach or give some direction
by utilizing partial and full emulation
or firmware using the latter tool
framework.
So for this paper, the
set up has
two targets on the one hand
S.T.A.R.T.
two one five two EA
Development Board,
which we have here.
It's a nice
board which has nice features like
directly having a JTC interface embedded
and even
providing serial access to it over
USB.
On the other hand, the target we are
using is Panda,
the reverse engineering framework.
We have targeted software
for our test.
We used expert
on instrumented version
of expert was artificially
vulnerabilities,
and the analyzers itself
orchestrates in the sense that
the initialization of the better device
is run
on the physical keyboard.
And the emulation of the
main loop of the main part of the
firmware is done inside Panda
for the analysis.
We brought five panda plug ins, which
check on verify
during revelations of state of the
firmware
by mimicking already existing
techniques which are used for analyzing
desktop software.
So, for instance, we have something
which is similar to a shadow stack
implementation or some tools
with checks, while one plugin
which tries to check the consistency
of the heap by
tricking malachite freed
and reallocate object.
The big advantage of this approach is
that there's no need to
modify the firmware.
So for evaluating those, we did 100
first session of one hour each
in quite some different set ups.
We foster space and
then again, the native port.
Then we used partial emulation with
forwarding of i o to the board.
We use partial insulation without
support, but
was an avatar peripheral and we utilized
fully utilizations
with the plug ins.
We called previously.
We could detect previously undetected
faults and quite interestingly,
the
full emulation provided better
performance than native, even
due to the fact that even inside
the emulator, the clock speed of the
emulated firmware is higher than on the
actual device.
Now, the next demo
is actually a subset of this work.
It shows the record
and replay features which we have
when using Panda.
This is especially cool because
normally if you analyze
or dynamically analyze an embedded
device, you need the device physically
with you physically present.
However, by utilizing
Panda, we can
record one execution and
replay it later to the
inside two emulator without the need
of having the device present.
So let's look
this up in a demo.
So first of all that you believe me,
the software
running on the sky is
actually the
example. Paula, as I
stated.
So we are just
looking at the serial output and writing.
Some refer to the serial output
input.
And here we have
echoed the example file itself
and the main loop of the firmware
just brings us back the documentary.
So fine this work so far.
So let's look
at the Avatar two script
for recording this.
This was a little bit more.
We have more huge than
the Avatar scripts we saw before
we defined
two targets here.
The Panda targeted
normal 2D target.
We at different memory made arrangements,
one for the read only memory.
With a firmware sample.
We searched one
for the run off of size 14
pages
and several ones
for memory mapped, all whereby
we want to emulate a similar interface
with an avatar peripheral.
You don't hear as an example
how to use the orchestration plugin.
So basically we define a
starting target at a transition
and starts orchestration.
This orchestration will
automatically transfer the state from
nuclear from the board to the panel at
once.
This specific addresses hit an
execution and was
synchronized as rum wrench.
Once we are there, we are beginning the
recovery and going
into an IPX8 and trial or
continuing the execution inside the
emulator, going into an iPod and channel
for dynamic for further
analysis.
So all we need to specify
a trace in the name.
OK.
And the demo
is not good with us this time.
The GDB protocol was unable
to connect.
Too bad.
I don't have time
to report it right now.
However, trust me, this works
and.
And on top of that, I've prepared
already some records before, which
are
impressively unspectacular, so we have
a run
replay
script which basically just executes a
panda with the configurable
machine, with the
configuration automatically
generated by Avatar.
So let's see if at
least the replay works of a
previously recorded execution
at four five.
And here
we go. We have a replay completed
successfully and a lot of debug output
about
sort of configurable machine,
the number of executed instructions and
the number of
replayed non deterministic
AI off.
OK, let's move on
to the last example.
I want to show you some work in progress
where we
basically want to leverage symbolic
execution to complex software using
Avatar.
So for this, we inserted an
artificially buck because we are still
testing phase
inside Firefox and executed
Firefox concretely
inside GDP until the function of
interest.
This was particularly interesting because
anger
itself won't be able to run complex
software as Firefox
or will be needed to create
it with a state.
We analyzed only one threat,
and once we had the
interest in the function, we
automatically extracted
the memory from GDP while the memory
lay from driving sorry not of memory
and copy just two layered into
anger, while then the memory
content itself a copy on Read.
So if any excessive memory,
it actually copies it from
GDP to anger.
Reason for that is that
anger to associate a lot of metro
information with the data
and this world,
if we will dump the full
memory contents into anger first
would exceed the amount
of RAM we have present, at least on this
machine.
Furthermore, we symbolize the symbolic
the function of symbolized the function
arguments and start of a symbolic
exploration.
Our preliminary results here
are that we had approximately
10 minutes of runtime in the script for
just executing thirty six
basic blocks
excessively and 21 uniquely
Rove's Patris
uniquely, and we found
the bug.
So let's recap the example we saw.
We saw five example
dynamic instrumentation of 3D
dynamic instrumentation of a APAC
fall detection on an development
board together was panda
record. What we did not saw the record,
but the replay
of the development brought in panda
setting, and
we very briefly saw symbolic
execution was Firefox and 3D.
Note that some of those examples
are already available open source, and
the ones which are not will most likely
be made available within the next months.
So let's wrap it up.
Dynamic firmware analysis is still
a very challenging topic, and I
don't claim to have all that.
We have solved it completely.
However, Avatar to tackle some
of the challenges and tries to
improve the state of the art.
Additionally, one interesting thing which
we recognized is that multi
target
orchestration for the concept of having
different emulators and frameworks
interacting with each other during the
same analyzes
is a concept which
was not
limited to firmware only, but also
desktop software analyzers
can benefit from it.
Although that's almost the end of
the year, we also make
some plans for the New
Year for the next year.
We basically want to move our main
development to get up.
Currently, we develop
a private repo, which is
a little bit set because keeping it
and saying is a little bit harder
than we want to introduce proper
versioning to the Avatar tool and of
course, add more and exciting targets to
enable more and exciting analyzes.
So if you're interested in helping us
or just want
to have some question,
feel free to contact us on ISC
on may just ask to
talk directly to me and
one small disclaimer.
We may be looking for people to join our
group in the near future future.
Although I'm running out of time.
I just Prinsloo acknowledgment
shortly, and I guess we can move
over
to the Q&A.
Thank you. And the first question goes to
the internet.
So does the framework
support the complex x86
systems like the Intel me?
So the framework itself is
not executing
any and
any software itself.
Instead, it uses underlying tools to
other tools and targets to execute
software.
So if you execute a concretely
on GDP, using
GDP on your machine, the tool
is just fine.
What you probably need to do is
to augment a little
bit to register definition insights,
architecture or insights
architecture abstractions.
OK, next question goes on microphone
four.
Yeah, I haven't heard about
Panda before, but as I understand,
you can record and replay executions
and that includes like
executions on possibly
the real hawk around, partly in Kuwait.
Could you use it for debugging as well?
Like also like reversible debugging,
like, for example, you step into code and
then you chomp back to a certain point
of the recording?
Actually, yes.
So the original purpose
of panda is
just reverse engineering of
software just executed on
inside the emulator.
And it also helps.
Or I don't
know how far the development state is for
stepping back, but I think they were
working on it.
And in general,
while replaying, you can
always
attach to the replay to
execution was GDP or another
tool and start analyzing for your
words and purposes.
Thank you.
The sensors have additional questions.
Then we go back to microphone four again.
Yeah, thanks.
First of all is the I have two questions,
OK? First is upon the
release now because I guess it's
it's part of is still going
to publish the paper about it or
no panda is released
as open source and we instrumented
and have a modified version of panda
insights about a two framework.
But you can also get it on
GitHub dot com slash panda
slash panda, I think.
OK. So a second
I remember the problem with Avatar
one, which was
it was a slow and
I want to know what are the improvements
in Avatar two?
So regarding this?
Yeah. Yeah, that's a very excellent
questions.
And we improved
the.
The speeds quite a lot.
Unfortunately, we couldn't see it in the
demo of
of of recording the executions
here, but
let's say Avatar one,
the main bottleneck
was memory interactions with the physical
device.
And we had some time
of benchmarks to transfer of of
40k pages,
which we needed for this example,
took an avatar, something around two to
five minutes. Well, here we are done and
one to five seconds.
So it's a significant speed up,
but still not
fast enough to compress real time
requirements.
Thanks.
OK, next question goes to microphone two.
Hi, I'm embedded
systems rather often have Real-Time
components.
Could you then, for example, just
walk into a free
autos threat to
just analyze a
non time critical parts?
Yes, this should be possible.
I mean, in general, we
have to investigate more a little bit
Real-Time Independent
Embedded Systems.
We currently put it a little bit out of
scope, but it's for sure one input
we will look to in the future.
And I think
we
are Real-Time critical parts.
Maybe just working.
To thank.
OK.
Yes, Internet
and hideous sort
of like to know if
there is a road map to
the maps
for maps support to ever
talk to.
No, there's no road
map currently available.
We started implementing it and it gets
improved a little bit side on a side.
If someone wants to
step in and help to it,
help with it.
We are happy.
I can tell what's this for what
has to be done to enable support
and well,
in general,
we are we are working on it.
But sorry, I cannot tell a specific time
when it's going to be ready.
OK. Any further questions?
No, thank you.
When you leave, please take your trash
for shoes and other belongings with you
and to wash your hands.
Thank you.
The.