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/64 Thanks!
Yes. OK,
great.
So for everyone who saw me on the plane
this morning, desperately making these
slides, it was all an act.
I had these slides done months ago, so
I floored everyone.
So the task, the name of my talk is from
our fat camp.
I want to talk about defensive techniques
that I've been working on at Columbia
University. That's part of my thesis
work for
retrofitting embedded devices, removing
vulnerabilities from them automatically
and fortifying their code to make
exploitation of those devices more
difficult.
But we're not really going to do that.
Not yet. I want to talk about something
more fun. I want to talk about Fantana.
And you can see this is my super awesome.
Very professionally made antenna here
that we brought for you guys.
And this is really to finish up a
presentation that I did last year.
I came here and I talked about
the the Cisco phone exploitation
that we did. And at the end of the day,
we figured out ways to exploit
the kernel of this phone and pull the
microphone data from the handset mike
over there.
And the way we did that was
by reconfiguring what we had to hack a
physical switch. Now this sounds like a
difficult thing. It shouldn't be
possible, but it was.
And the reason why it was was because the
switch was connected to open
the general input, general
purpose input and output pinned, which we
reconfigured from inputs output to
for the software into thinking that the
handset was picked up when it really
wasn't.
So that worked.
And when we did that, we looked at the
the pen now, and all of a sudden it
occurred to us that if we can reconfigure
this pen and have it turn up high
and low and high and low, if we can do
that fast enough, we probably would be
able to make an antenna, a transmitter
out of it to exfiltrate arbitrary data
from this phone.
And, you know, pretty low frequency,
probably, but it's still something that
you can pick up using something like an
Edison research like us or SDR
or really like the AM radio hooked up to,
you know, your audio, your sound card.
So we looked at it, it seemed reasonable
and we went home and we didn't really do
anything about it. And it bugged me for a
long time, and I really
had to mythbusters this thing out to
really see if this type of attack, this
type of technique would work at all.
And we did that, and here is the result
that I'd like to show you guys.
So first, what is the definition of
antenna? Fontana is a software payload
that intentionally causes the host
hardware to act as an improvised
RF transmitter using existing
hardware, which are typically not used,
typically not designed for RF emulation.
Right? And sort of signal intelligence
parlance, this is more like a piece of
software that intentionally causes
compromising lamination.
So if we're talking about intentionally
causing emanation, let's talk about
unintentional, compromising lamination.
There's a lot of work, a lot of prior art
in this area.
Most of it is classified awesome sauce.
Not a lot of it is unclassified.
So there's not a lot of detail, but some
things have slipped out.
And I want to tell a story about
this is a story that Peter Wright told he
was a RM5 counterintelligence officer
who wrote a book about his life and
and work caused by catcher.
So this story takes place in 1960.
OK. This is an embassy.
You can tell because the table is
embassy like right?
And on this embassy is a telex,
a teletype device, right?
I had to. Oh, and this is a French
embassy. So there's that I
had to Google. What a teletype look like.
This is my rendition of what what it
probably didn't look like.
But because this is inside an embassy,
this is not a typical teletype.
This is a super secret crypto teletype,
right in the way. Oh, and also has a
cable back to the mothership, right?
Probably to somebody in France
so that this is the way it works.
You type in clear text, OK?
And this machine encrypted the clear text
and send out ciphertext,
and that's good. But it turns out
ciphertext is really hard to read, and
the British intelligence people wanted to
read what was going on inside the French
embassy, and they couldn't really figure
out an easy way to crack the encryption,
so they turn to something else.
They noticed that if you watched
the output of this cable right along with
the cipher text, there was what they
called an electronic echo of the clear
text right along with the signal.
And this happened because the device
wasn't properly shielded.
So every time you press the button on the
device, there is enough
ammunition that would trickle down to the
wire. That would tell the observer
which key was pressed on the thing along
with the ciphertext that was being
transmitted. So this is a really good
example of unintentional compromising
ammunition.
Like I said, most of the stuff is
classified, but some of this work has
been made out into the public.
For example, a V-neck freaking this was
paper that was published in the 60s,
I guess 80s that
basically said that you
can reconstruct the output of CRT
displays by looking at the RF emanation
of that device in real time.
So you can listen with a radio and
reconstruct the words that are being
printed on.
TS and this makes sense because, you
know, CRT is a big electron gun that's
that's scanning around, it's putting a
lot of power.
And years later, Marcus wrote a paper
that said, Well, there's only not only
works on CRT is this also works on LCDs.
Right? The DVI connector
was actually something that was emanating
of our power, that you
can actually reconstruct what was being
said or what was being displayed on the
LCD as well.
And displays were not the only things you
can. You can read from from using a
radio.
You can actually observe the
output of hours to 30 two communication,
a serial cable from something like 10
feet away.
By receiving the signal that
it put out right over
basically FM range.
So this is another paper somebody did, I
think maybe 15 20 years ago,
and compromising ammunition
doesn't only have to do,
they don't only have to live in RF range,
right? They can live in acoustic range.
So this is a very recent paper that
talked about extraction of RSA keys
right through acoustic leak of
the hardware.
So that's a really cool paper.
You guys check it out.
So knowing that you can capture
and analyze unintentional ammunition,
it should make sense that we should be
able to construct a piece of software
to cause this type of ammunition and
choose the text or choose the data that
we can transmit out of the device.
So we wanted to build a proof of concept
and this proof of concept.
We wanted to have it be on open hardware
and open software.
So the community can take a look at it,
can play with an improvised improve on
it. We also wanted to use hardware
or specifically embedded device hardware
that is ubiquitous with capabilities that
are found and on as many embedded
devices as possible.
Right. So we eventually settled on
this. We use the big open and
open and a wire.
Right. So GPIO is something that you can
find on all sorts of embedded devices.
The big and runs arm, it's not
really important which architecture the
CPU runs, but this is something that
if we can get the antenna to work on this
reference design, we would have some
confidence. We would have some confidence
that would say that this type of attack,
this type of technique, will work on a
lot of different devices that are in the
world today.
OK, so this is our first montage
of science learning.
OK, we are.
I said, Well, how do we do this?
I want to do this in software.
I want to make a radio. So let's figure
out how to write a simple, software
defined radio, right?
We got to some books on that.
And, you know, it's really complicated
and took a long time.
Right. And then we ask ourselves
like, Well, how do radios work?
That was really complicated, too.
And then we're like, How do electrons
like, what do they do?
Right?
And eventually we came up with
what we thought we needed for an SDR.
And you know, this is sort of a reference
design for like your typical
standup software defined
radio transmitter architecture.
So you start with the DSP and then
you have something that converts digital
to analog, right?
And then you filter that through a low
pass filter.
You combine that with a local variable
oscillator of some sort.
You pump it through a band pass filter
and then you power amplify it and
you then put it on a transmitting element
and then you have your SDR transmitter.
But we don't really have that.
We have a board in a wire.
So do we have a DAC?
No, we have a wire.
Or do we have a low pass filter?
You know, we have a wire, right?
Whatever oscillator we do, we actually
do. We can control the pin high and
loudness. So we kind of have that sort of
maybe the we have a power note, we
have a wire, right?
And we have a band pass filter.
No wire do have an antenna.
Yes, right.
We have a wire like.
Like.
This award.
So here's the idea.
This is the reference Fontana
implementation idea.
You have a system on a chip, right, which
is home to either a input
pin, which is held to a button of some
sort which is not grounded, right?
And or you have an output pin
that's meant for transmission that may
not be connected to ground or some other
load, for example, the user pin
sitting on devices.
Right.
And the idea is, if you can flip the bits
fast enough, right in the predefined
pattern, that would be enough to
emanate out of power.
And if you can do that, you can receive
it from some feet or tens
of feet, maybe hundreds of feet away.
And then you would win.
And this is what we set out to build,
and I'm going to turn it over to my
colleague Zach, who is going to talk
about what we build and how it works
and.
Hey, so I'm Zach, I worked
with Aung on the reference implementation
of the Fantana and I want to talk.
We registered the domain name frontend
org. Don't go there because
it is empty right now.
We spent most of today trying to fix
our demo, but we
really would like this to be a very
community driven thing.
We think the idea of a Fantana is cool
and it's even cooler.
If there if there is a gigantic list
of like many, many devices on which the
fund has been proven to work.
So within a day or so, we're going to
throw all of our information up on their
details about what we tried, what worked.
What didn't.
What we think are possible
improvements.
What means you can we think you
can use to make a FANTANA and we want it
to be an open source, community driven
effort.
So we're going to throw all the code we
used and instructions so that
you can try this at home.
Yeah. So anyway, as Aung
said, for our reference implementation,
we used bitcoin, which is currently duct
taped to my laptop.
And the reason we wanted to use this
is it's well documented,
unlike a lot of the
potential Fontana hardware out there.
This does not take away from the spirit
of the FANTANA. That just makes it easier
to sort of flesh out a proof of concept.
And then we can move on to the hard part
of doing it on a real, real world
device.
And it's reasonably
cheap and it's reproducible, and you can
get one of these pretty easy.
Yeah. So as you can see, we just stuck a
wire out of one of the GPIO pins
and that that is our antenna.
And to receive we used
fancy schmancy USB to software
defined radio from Edison Research.
This is really nice.
And so to pair with our fancy schmancy
software defined radio hardware unit, we
have this antenna, which is
looking real professional.
And so we found this combination worked
pretty well for picking up signals and
honestly at the frequencies we're
working with.
We got the Beagle mode to transmit at
about 12 and a half megahertz.
You can you can probably use an AM
radio receiver or something similar.
You don't. You don't need anything quite
quite as fancy as this.
Um, so
in an ideal world, what's going to happen
right now is I'm going to show you a demo
and it's going to work swimmingly.
We found this room
like 40 minutes ago,
and we didn't really have time to see if
everything works.
But I'm going to I'm going to walk you
through what the process
of me sending a message through the phone
and it should look like.
So so what I'm doing right now
is pulling up a virtual machine.
Running new radio has a nice
suite of equipment for working with
our software, for working with software
defined radio.
It does a bunch of signal processing and
we wrote some of our own stuff to
go along with that.
And
that doesn't work.
Here it is. OK.
So what you're seeing now is
I am just for calibration
and transmitting zero one zero
one zero one pulse
from the Beagle one
does not look the best.
Yeah.
OK. So we're going to we're going to
use a human to hold our antenna.
This might work better.
The reason why everything
is stuck down is because we did crowd job
soldering all these
things
on the plane. A lot, a lot of wires
jostled loose and we were we were they
were not.
Not a good fun day to day.
But so, yeah, so what's happening right
now is I'm just transmitting on off, on,
off, on, off.
You want me to restart this?
Yeah.
So we're we're going to
show you the show, you sort of around
the fun kind of land.
Um, so this is
this is the scope of the top flight
is the signal that's being received
by the radio.
Um, and hopefully
you'll see pretty soon this nice on-off
pattern, which is what we're sending out.
That signal is being generated by the
wire on the beagle bone on my
laptop or that that is taped
to my laptop and down here
is where we're trying
to parse that and do a zero one
zero one zero one.
And sort of the flow for this
is we have the signal
coming out of the US up
through a band pass filter that captures
the band or the frequency we're
interested in smooths it out with
our arms.
We use gain control to
hopefully
be able to deal with any signal strength.
We average it to smooth it out.
We take a threshold to convert it into a
binary zero one.
We this logic here is logic we rode
to. Sample,
hopefully one one sample permit
that we're broadcasting, and I'll get
into the nitty gritty of the
protocols that we were using.
And then we have encoded our data
for error tolerance.
And then we this this looks like a
mess down here, but it really just packs
the nibbles we get out of the ham
encode data back into bytes,
and that information comes out
into this file right here.
Do you want to move?
I don't want to hear a little bit.
Yeah. So let let's let's see if we can't
get a stronger signal here.
Is this thing ready?
Yeah.
Let's restart that,
OK?
Yeah, and then I'll
explain a little more in detail about
the Beagle vote in a flash.
But as I said, all we're doing is turning
a high, low, high, low, high, low and as
fast as we possibly can in order to get a
signal.
And if
all goes well in a minute, I'll have a
message for you.
Yeah. So the beagle bone,
like I said, there's documentation about
it. We wrote a kernel module that just
toggles on off, on, off, on, off as fast
as we possibly can.
And we came up with a
duration for each symbol.
We used what's called on-off
queen, so we either transmitted a signal
for a one or didn't transmit a single
signal for a zero
like like, Aung said, we don't really
know anything about radios, and this is
why we want it to be a community driven
effort. I think I'm sure many, many of
you are are
much better at RF than we are.
So if you can make improvements
that prevent things like this from
happening to make it because
the reason the reason this is not working
is due to us and not not due to this.
But yeah, but it's it's leveling out.
OK.
I think this just has to do with
interference in the room around this
frequency.
Maybe. Yeah, like wiggle that pin
a little bit this one.
All right. It's so much better now.
I will not move.
OK. This is the the reason why we
had to duct tape everything down because
he brought this and it's totally paying
off because the wires are kind of
loose and it really matters the
connection between that wire
and and the board.
But you can see now there's a pretty
clear way for right, and this is the
beagle bone just flipping its pen on and
off. And it's transmitting, you know, a
good amount of distance and with a better
antenna like the one we have in our
office, this can go much further.
All right.
So, so don't move your finger.
Let's try to transmit something
here.
Right.
Um,
let's let's go for gold.
No,
the demo gods are not smiling on us
today.
Do you want to restart this thing one
more time? Yes.
OK. All right, let's.
It's really cool when it works so
well, like.
Do
you?
Um, yeah, anyway, it's a little more
about what we're doing behind the scenes,
so that on-off keen is
not the best method of
transmitting data, but again, the dead
simplest path to a proof of concept.
We've seen this work successfully.
We're not. We're not just messing with
you all at a distance
of up to 30 feet, and I think the signal
is strong enough that we probably could
have gone a little further.
We were limited by the the room
because we are working in New York where
there is zero space for activities.
All right.
So that looks like it's nice and stable.
I'm going to try to not move
my finger.
Look, it works.
Don't move, don't breathe.
Wait for it, wait for it.
Oh, no.
And
that was ASCII art.
Yeah, well, it's still ASCII art now
it's Unicode art.
We need better error correction, but it's
supposed to dump our part of the chaos
rocket,
which are usually good enough to put on a
website. But but you can see this
thing is transmitting, right?
Yeah.
Cool. So you're not headed back to find.
Thanks for sharing with us.
Oh my.
PowerPoint is about to die.
Well.
That looks wrong.
Yes.
So anyways, we're using on off key, and
we decided we decided we did arbitrarily
that we use one hundred thousand on off
cycles per bit.
Oh yeah, that
sort. It doesn't mean
it's not changing when I do this,
which is pretty critical.
No, hold on.
Hold on, I could do this.
OK.
So and that that so we
fixed this that signal duration for a
bit.
We wrote our messages in
a format that involved prolog
of one one zero zero one one zero zero
just to let us know that we're
transmitting a packet and then you
encode the packet length.
And then we had encoded the data,
which
supposedly protects against errors.
We must have had we used to have
seven four codes. So for each nibble of
information that we were transmitting, if
we have one bit flip, it gets corrected.
If we have to, it doesn't.
And I think that's what we saw out there.
But but sometimes this works and it's
cool. Yeah. So this is exactly what I was
talking about with the on off gain.
We used one hundred thousand cycles per
bit, and these are all parameters that
could be targeted for improvement.
Yeah. And then our data comes in the
having code.
So some of the some of the real world
issues we were struggling with that
people who make nice like network cards
and stuff don't have to deal with our.
We were doing all the bit flipping in
CPU.
So things were getting cramped in.
Our symbols were of
irregular duration.
You can see that's eleven milliseconds.
That's twelve milliseconds.
This is a very scientific draw on
seven or nine, right?
And so all the all the bits are like
slightly different lengths.
So I'm sure you can design the
over their protocol in a way that would
cope with this a little better.
It stopped again.
Wait, wait, did I
make it better?
Yes. OK.
And so combined with that prior thing,
we have the the idea of sample drift,
which is when when something goes wrong,
it can go really, really wrong.
We tried to sample in the middle of each
bit.
But if that's a bunch of all low
values, we might, we might
sample too many times.
And then from that point on, everything
looks bad.
And again, people who do who know
radios, hopefully you all can
deal with this stuff.
But we were. So the bandwidth we got was
also pretty unimpressive.
We were doing calling out megahertz one
hundred thousand cycles per bit,
which is about 16 bytes per second,
which I think I can talk faster than
that.
But in theory, we should be able to do
much faster.
I brought it down to fifteen hundred and
five goals per bit, which would be about
eight point three kilometers per second.
And as you can see on the on the
scope, there's still a very clearly
defined on off pattern.
There is room for other improvements.
You could use something better than on
occasion. You could use frequency shift
gains, though broadcast at one frequency
for one zero
broadcast at another four zero zero
another four zero one another four one
one and get more information out faster.
You can do that's
cut off. You can.
You can make improvements to the protocol
to deal with sample drift to make sure
that each bit
or each byte arrives intact,
packets of fixed size and so on and so
forth.
And you can do things in the kernel to
make it so that the duration
is less irregular.
And as long as you got to talk about it
in a couple of minutes, if you do things
other than GPIO, you don't run into this
problem.
Um, yeah, that's right.
That's my bet.
So we took our reference implementation
and we said, OK, it works on
the beagle bone. Let's go back to the
phone that we already we originally
looked at, and this is where the Fantana
meets reality and reality one
here. So we thought, wouldn't it be nice
of the guy on the phone to work this way,
where all the pins go to buttons, right?
And you can just reconfigure the buttons
and turn them into little and
transmitters?
It turns out you can for the software
into thinking that the pen has been
pressed, right? But when you actually do
that, the voltage is not actually pushed
out to the pen, to the button.
And here's why that happens.
And this is not just this specific phone,
but we looked at a few other embedded
devices, too, that have GPIO.
It turns out GPIO is generally
multiplexed, right?
So there are about maybe eight pins of
GPI or going to some multiplayer logic,
which then goes out to all of the buttons
and whatnot, which means you can actually
send a current down right this
this path. But it would hit some
multiplexing logic and it would actually
not emanate very much higher power at
all. So we lose there and we got
super bummed, but we went back to
the phone and we looked at the other
things that are on this board,
and we started doing some creative
thinking and we noticed that there
are two gigabit ethernet ports here.
So these are gigabit ethernet cable or
interfaces, and they can obviously flip
bits and more or less that speed.
And there's also an art
that we can maybe do something with.
We went with the more direct approach,
not messing with the other new
controller. We went directly to the user
and we thought, Well, wouldn't it be
really nice if I can just flip the
European really fast, right?
And have it be a transmitter as well?
And this is when I looked at arm Linux
implementation.
You can find a lot of source code in the
arm kernel or in the Linux kernel and arm
for how this stuff all works.
And we looked at the Play zero one One
UI, which is pretty common in the devices
that I was looking at.
Here's how that all works.
For example, the PCM Ring Class of
processors system on chips have what's
called an ember bus.
So the advanced microcontroller bus
architecture and the uart sits
as a slave on their bus
and that you are has two pins or
more on the two. But the one that we
really care about is a pin,
and the ARM SoC provides
a reference clock to the unit, which then
that you are divides to set.
It's portrayed appropriately
and you can find the data sheet here so
that this data sheet is publicly
available and their source code in the
external in the Linux kernel.
And it turns out you can actually
overclock this clock by four times
and get it to send data really, really
fast, right? Much faster than it was
supposed to.
And this is the call that you have to
make in the kernel. This is all very well
documented.
That you are a clock is five to say five.
I want you to go four times faster and
it'll just do it.
And all you have to do then is send a
string of characters to the unit.
And then it would put that bit pattern
onto the wire. And if you do that fast
enough, then you have a transmitter.
So that actually works, and I'll
show you some data we have on that.
This is what a ninety six hundred baud
transmission looks like under
the spectrum analyzer, right?
You get a four point eight kilohertz
signal. It's not very impressive at all
if you set it, and this is the way form
that you get when you send the letter,
you write who you are.
If you set it to the maximum baud rate
that this device supported,
you would get something like a two
hundred twenty nine point five kilohertz
transmission. Still, you know it's
getting there, but it's really not that
great. But if you overclock this thing
four times, right, you get all of a
sudden a nine hundred eighteen megahertz
signal. And actually, this is you can
double that because the way in Manchester
encoding works.
So all of a sudden you have like a one
point eight megahertz transmitter
that is just sitting on the sort of
pretty much every device that you have,
right? Your your laptop has one.
This embedded device has one, the phone
has one, and you can use that device
to transmit radio signal for
antenna.
So here it is. We sent the letter, you
write, which is.
The pattern zero one zero one zero one.
But if you really wanted to send the fast
signal or to send either
a soft rain or the no
character, which would
go up and down very fast, so the
highest speed that I was able to get this
particular you are to transmit that was
about one point eight megahertz.
And then we also notice that there
harmonics that goes all the way up to the
11 megahertz told me or her range as
well.
So that worked, and
I started looking at other potential of
antennas and devices that have been
looking at. And here's one you know,
Travis good speeds paper right on back
during hard drives, right?
Really cool. And it turns out the hard
drive controller is arm computer with and
you are on it, right?
That's not connected to any cable.
So all of a sudden, you can have your
hard drives transmitting, you know,
information out, and you can
also use either interfaces, right?
Four out of the eight pins on Cat five
not used, not connected, right, but
sometimes the cables are still run, which
makes it a really nice antenna, possibly.
And look at all these ports on your
laptop. So these are all things that are
capable of very high data rates.
Now, if you're if you're able to control
the software that makes, you know the
patterns come out of these pins, you can
potentially use these things as fine
tennis, too. So there are all sorts of
possibilities and the devices that we
have around us, and we hope that with the
code that we put up, the community will
go out and find more tennis and such.
OK, so no more procrastinating.
Like now I have to talk about my Page
three research. I guess
it's just called former
fat cat.
Oh, I'm listening to bass.
It's really not called that.
It's, you know, in academic speak, it's
called out of make binary structure
randomization. And this is a collection
of two different techniques that are
designed to improve the security
of existing and better devices without
requiring hardware modification or
assess the source code.
And I'm going to talk about asking
me first and then binary search for
randomization. So Artemis is
essentially the idea that your embedded
device has a whole bunch of features
inside that you don't want.
You didn't configure that you don't
really need, and it should never execute.
So if that's really the case.
So, for example, this is a Cisco router
you don't really need mocp.
VP, HAARP, every other p
HTP set skinny
DHCP server. Maybe, maybe not.
You might as well just take it out of the
firmware, right? If you could do that.
The code is gone.
It can never be re-enable by an attacker.
It cannot be reused by the attacker to
do malicious things.
And one good example of that is lawful
intercept, which I think has a really
good talk on, right?
So I'm going to that's going to be very
interesting because a lot of these
routers who don't necessarily need to run
lawful intercept actually has the code to
do a lot of lawful intercept in them.
And if you are not familiar with what
lawful intercept, this is exactly what it
sounds like. It is lawful intercept.
So if you don't have to run a lawful
intercept code, you might as well just
take it out of the router. And I'm going
to show you ways an algorithm, a
generalized algorithm to do this
automatically, right?
So it's not configured.
Take it out of the firmware.
Now, once you have taken the unnecessary
firmware out of unnecessary code,
out of the firmware you end up with, you
know, a piece of firmware with a whole
bunch of spots in it, right?
Empty spaces that you can not all of a
sudden use for whatever you want to use.
And what if you started moving
actual code around into those empty
spaces like an eight puzzle game?
So all of a sudden, you can do
randomization on the binary structure of
the code that actually should run
relocating that code into other
other locations?
Right? Basically doing something like
what address space layout randomization
does without any hardware support in 32
bit address space?
Right? All by just shifting basic blocks
around iteratively in a
in a functionality preserving manner.
And I'm going to show you some algorithms
for doing that.
So here's you know, graphically what that
looks like. You take a piece of firmware
and you look at its configuration.
So if you don't have the issue to be
server configured for your Cisco router,
you figure out the code that corresponds
to the HTP server, right?
And you remove it and you end up with
a piece of firmware that has a bunch of
holes and you take those holes
and you split up the basic blocks of
the code that you actually do need right?
And you relocate them over and over
again. Each time you relocate the basic
block, you're not changing the
functionality of it all.
You're just changing the binary structure
of it, right?
And basically, what this means is that
you introduce a bunch of jumps right
inside, basically blocks and you get a
bunch of different functional equivalent
binary, different variants of the same
firmware. Right.
So imagine if an attack depended
on knowing the specific address of, say,
a specific function.
Right? This type of technique will
prevent that from happening for from from
succeeding.
So that totally works.
And I'll show you a demo running on the
Cisco Eighteen Seventy One router, right
at the code for the AT&T P server has
been taken out.
I'll show you then a little bit, but
let's look at the generalized algorithm
for auditing me.
How do you figure out what code to take
out what code you can take out?
Suppose you know this thing is HCV
server. It has.
A function entry point that goes
out starts the server, causes a bunch of
other helper functions.
Maybe some library functions and some
other internal functions.
So for example, it'll call printouts,
call function A, B and C, and then it'll
call a library function right.
By recursively traversing this call
graph, you can figure out what
references each of these functions.
You can see other functions outside
of the server.
Server X actually makes reference
to print F and Lib one function
one. So in this case, you can actually
remove this code because if you do other
pieces of code that has nothing to do
with the server, it will break.
But if you look function, A, B and C
are only referenced by pieces
of code. That's the part of the sub call
graph right of the server.
In this case, it's completely safe to
remove this code entirely right if
you disable the server in the server and
then restarts.
So you just do that.
But first, you have to make sure that the
function of the entry point returns
something that won't crash the system.
You basically do static analysis to
figure out what the return code should be
here and whether it's just a zero or
error no code.
And that, for the general case, is very
difficult to do. It's intractable, but
for specific cases like this, it's very
easy, very predictable.
OK, and then once you do that, you can
remove function A, B and C, and all the
data that is that refers
to or is used by these functions
exclusively. So you can take out the code
and the data by doing this automatic
recursive graph traversal.
OK.
And then here's an example for, you know,
this in the general case, it's really
difficult to do. But in specific cases
like Cisco iOS, there is enough structure
in the in the operating system in the way
that this code is put together, that you
can absolutely infer which piece of code
starts from where and the call graph,
etc..
So, for example, we can see that
it should be core rate starts at a
specific address, and you can go from
there and apply the generalized Attomey
algorithm to figure out what pieces of
code and data can be removed from there.
OK. And then binary structure
randomization is basically taking
a single basic block and then splitting
it into two or more basic blocks
and relocating them into different places
without changing the functionality or the
side effect of those basic blocks.
Right? Taking one basic lock
and moving into two and adding a jump in
between. So this is the very simple as
one. It's a basic block split, right?
This is the transform that preserves the
functionality that just adds a single
instruction.
So all of a sudden, you can take those
basic blocks and you can move it anywhere
you want
and then you can swap basic blocks,
right? This is basically a compound
transform that takes one basic
block and then another basic block breaks
in half and then replace them together,
provided that the two basic blocks are
equal in size, right?
And you can do this even when they're not
equal in size.
And here is a real world example of,
you know, taking this binary structure
and then adding some jumps and converting
it to this binary structure.
It's super late, and I am sure you
guys are, you know, exactly what this is
doing. You figure it out, but they look
different, but they do the same thing,
and that's that's really the point.
So I'm going to do a demo now, and this
demo comes from is running on a Cisco
Eighteen Forty One router, running twelve
point four iOS,
and it is running.
Without the
webserver or the SS,
each server.
All right, can you see that?
OK, so we're unable.
OK, there we go, so now I'm enabled
on the router.
I'm going to go and try to
IP, HSDPA and server.
Go right.
So this is the configuration you have to
put into the router that say, I want you
to start at the web server. And
generally, if you're running, you know,
backbone routers, core routers, you never
wanted to run the h8ve server.
That's just asking for it.
You really want the code out, and this
one has no code that corresponds
to the issues to be server anymore.
And it gives you a very polite
go away message that says you don't want
to do this, you can do it.
The code is not even there. I don't even
think about it right?
And nothing bad happened.
The router booted up. It's so roots it
still switches it. So it does all sorts
of things.
So if you want to do show IP
HTP server status,
you know it would say yes, you've
configured it, but it's disabled and it's
not working.
The system continues to work right, but
the code has been removed, and all of a
sudden we can take the empty spots
created by the HTP server.
So relocating basic blocks to make
randomize instances of the same iOS
firmware.
OK, so that works.
Then I want to show you some and we
did this for a bunch of other services,
you know, Asus H, the R.P.,
Skinny CIP, et cetera.
And here's some preliminary quantitative
data that we've collected about how much
data and how much to code you can
actually remove from the various
services inside iOS.
The actual numbers are really important.
What's important to observe here is that
this is the amount of code that you can
remove based on
the steps of recursion.
So like I said before, this is a
recursive graph traversal algorithm.
You start from the root.
You figure out what you can remove
at layer one and then you keep on going
recursively. So the deeper you look,
the deeper you should be able to, the
more code you should be able to remove.
In every case, we looked at
the data removal, right?
Basically, stay the same right at
at higher recursion levels.
And that kind of makes sense because you
put your debugging messages usually at
the top of the call graph where you're
about to start a server, right?
You never put a debugging message inside
something like malloc, for example,
right? And this, to me,
at least makes sense that basically
this is saying if you want to just remove
data, you don't have to look very deep.
But if you want to remove code, the
deeper you go, the more code you'll get.
At some point, there is a diminishing
return. So there's going to be some
mechanism that will tell you, OK, it's
time to stop.
And then
when you combine multiple
features into one, you actually end up
removing more code than those two
pieces together separately.
All right, those two pieces separately,
right? Because you have an opportunity to
remove code that is used both by HGTV
and as a sage, if that does exist right?
And you wouldn't otherwise be able to do
if you just remove one or the other.
So that's it, that's my talk.
This stuff works that demo
work like.
Presidents do have some time for
questions or yes, questions,
comments.
Now, question time.
We don't have any question from the
internet, anybody else.
Then come to the.
Mr fitted with free blocks of code in
firmware, would that be?
I don't know if he was doing it, would
that be just as applicable in normal
boundaries?
Oh yeah, absolutely.
But so the question is we're doing
this in firmware. Would it be applicable
to, you know, general purpose
applications as a general purpose
computers? And it is.
But there are other features inside
general purpose computers like the 64 bit
address space and address space layout
randomization that essentially does some
of this randomization that you
wouldn't ever be able to to get on this
device right here, right?
So if I had a 64 bit
address space and aceler on this router,
then the, you know, the words
that you have to go through to actually
randomly relocate basically blocks and
splitting them inside firmware.
I mean, that's still you can still use
it, but it's probably less efficient.
But this is designed specifically for
legacy embedded devices.
Six. Any more questions?
And so what is your
how do you deal with this
virtual methods or like indirect
jumps?
Yeah. So there they're always corner
cases, right?
And the thing to point out about this
type of technique is you don't actually
have to remove every piece of code and
you don't actually have to remove or
relocate the entirety of the code.
You can keep the pointer where it is
right, keep the first instructions where
that pointer is and then remove the rest
of the basic lock.
All right. So if you have, you know, a
jump that goes to another memory location
that has a basic lock, you can just take
away. You can keep the first two
instructions of their basic block and
then move the rest of it.
OK.
Anything else?
Well, and I thank you again,
and I think if.
Thank you.