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/141 Thanks!
So our next talk is about SD card
and SD card, reverse engineering.
I'm really eager to wait
for that because I think that's going to
be really interesting.
So please welcome Bonnie Unsub's
for a talk on SD memory cards.
All right, thanks. It's nice to be in
Hamburg at the Congress again, and this
is an absolutely massive haul.
Holy cow.
Today we're going to talk to you about
the exploration and exploitation
of SD memory cards.
And we so maybe
get you started with how we got into
this whole project in the first place.
Actually, many years ago,
we were working for a company called
Chukumba, and we had a production run or
using micro SD cards
as the boot media for some of our devices
that were selling.
And we found that some of the cards were
not running properly, they were not
booting correctly, and we're having boot
issues. So we went and we looked
at the cards and compared them and found
certain anomalies in the way that
they were labeled and the way that the
logos are printed and sent them back to
the vendor. And we said, Hey, guys, you
know, these cards are not seeming
to be consistent with the with the
labeling. And the quality standard vendor
came back and said, No, no, no, no, these
are totally authentic cards.
So the next thing we do
is we go ahead and we
buy a bunch of fake cards and
a bunch of real cards and we tear
them down. We put acid on them,
reveal the insides, take a look at what's
on the inside and show the vendor that
their cards actually have part.
Composition looks exactly like the fake
cards that we get on the market versus
with authentic cards look like at
which point they come back in and say,
Well, OK, we'll take the cards back and
give you the the real cards, right?
But at the end of the day,
one of the interesting things
that we found was that
inside every card
was a microcontroller, a small
embedded device to manage the flash,
right? It typically tends to be an 1851
ARM seven type CPU.
It's a few square millimeters silicon.
And as a former silicon guy,
I like to always think in terms of like,
what's it cost and so forth.
And so back of the envelope calculation,
about twenty five cents or so is
what adds the cost of the card.
If they're able to get the flash, you
know, sorry, the microcontrollers
directly without markup from the from
the fab.
Compare that to the die area of the flash
100 square millimeters, which about the
size of this piece of flash memory here
is about $3 cost.
A very minor cost ED compared
to the cost of the flash.
And to put it in perspective, if you
were to go ahead and at the wafer scale,
so take the raw flash wafers and
use like a high end sort
of wafer protesting station, which costs
about a million dollars to purchase
if it takes you 30 seconds to test that.
The amortization amortization of
that tester alone for
that for 30 seconds would cost you about
45 cents.
So in fact, economically speaking,
putting a small controller on every
single day, whether Dai is good or not,
and using that to help run the tests that
could determine what's going on the
inside actually makes sense.
And so a little bit about why
the mission control is actually
necessary.
One of the things that maybe
many of you are aware of or maybe not, is
that flash memory is unreliable, like
incredibly unreliable.
You don't don't want to look under the
hood and see the sausage that's inside.
You're not really storing your data or
storing a probabilistic approximation of
your data.
They do a lot of.
They do a lot of work arounds
to try and work with us, for example,
ICC. So you're bitrate may be absolutely
terrible, but they're using very now a
very sophisticated, high density codes
to go ahead and try to correct block
errors and errors and so forth.
And also, you
have lots and lots of bad blocks.
Flash memory is really, really
cheap now. It's a point one
nano dollars per bit, approximately,
right?
And so things have come a long
way since, you know,
back in the day.
But this is only achievable because every
piece of silicon that comes off a wafer
is sold.
Nothing is thrown away.
So normally if you do like a run of CPUs
or something, you have a good margin.
You can go ahead and afford to bin out,
you know, some 10 percent, a few percent
and throw it away.
These guys basically have
to sell every chip that's made.
Otherwise they lose money and they're
still probably losing money half the time
anyways.
And so they have a workaround, which is
bad block remapping.
And so sometimes some
chips are sold to you with 80 percent or
more of the block speed.
So people will make chips.
They're supposed to be 16 gigabytes of
flash. Only two gigabytes are good.
Well, guess what? They sell it to use a
two gigabyte device, and they just have
to remember which blocks are bad.
And hopefully your data doesn't end up in
those bad blocks.
Also, with more program
in erase cycles,
the memory will actually degrade over
time. IT kid can no longer reliably store
your data.
So this graph on the right here shows
you sort of with process node,
you know, so from 50 nanometer, 30 to 20
nanometer, the number of programing
recycles which you're able to get and
also plotted versus multi level on TLC
Flash. And in fact, the latest generation
TLC devices are only good for less
than a thousand program erase cycles.
So you need to have something in the
inside that if you know if you just
keep on pounding a particular sector, say
you have a swap disk or something like
that which all maps the same logical
sector, you actually want to wear level
and move those blocks around the flash do
not constantly pound in the same sector.
Otherwise you'll find your SSD is have a
very short lifetime.
So there's a question. So why do it at
this layer? Do we have to put a
controller inside every flash
device? You know, why don't we put it in
the OS when we just throw it in Linux,
right? Why don't we do it at the
application layer, right?
And there's some places where this
happens. So, you know, back in the day,
it was Jefferson's office where they did
bad block management and even
revealed some of the details of S.E.C.
to the Linux kernel layer.
And some applications, like if you're
building a rainbow table, you just want
massive amounts of flash.
You actually don't care if the data is
not completely perfect.
You just want lots and lots of cheap
flash. So you just take raw flash.
Throw data in there and just hope it
comes out OK.
But these are very, very special cases.
Typically, flash geometry,
the actual memory itself that the
geometry of the fabrication the chip
is changing every 12 to 18 months
at a very fast pace and with every
new process generation of making flash
chips, there's a new set of XY
rules that use stronger and harder ICC.
There's new page sizes and block mapping
algorithms.
And this is an intensely cost sensitive
market, so the lowest cost and highest
performing flash memory will tend to be
have very proprietary specifications
around what you're required to do to
make the Flash actually appear to be
reliable.
So if we were to go ahead and push this
up the stack a bit and say put the OS
or at the application layer, you know
these, you would have to have NDAs sine
and specs going back and forth and people
pointing fingers at each other over.
It's a driver bug or it's a hardware bug.
And, you know, take, you know, two years
just to ship a product, right?
So the easiest thing to do is to just
like again, 15 to 30 cents solves
the problem through the algorithm in the
controller and present the illusion
of perfect data to
the user.
Now the concern is that now
that we know that these microcontrollers
are not going away and they're in every
flash device, whether it's a USB disk or
an SSD or a micro SD EMC,
all the things that we use to store
memory inside our mobile phone and
whatnot.
We know there's a microcontroller has to
stay there.
The question is is like, what does
this controller run?
Can it be hacked?
Do I trust this? I've actually created
the perfect setup for the man in the
middle attack. We've just invited in
someone to go ahead and sit in between
our data, and we just trust them to do
whatever they want to do.
And so, you know, we
turned in the fixed quest and we got
handed a new quest, which was to hack an
SD card.
We decided we would go ahead and search
for an SD card and just to demonstrate
that we can run some code on it, maybe
make an LED flash or something
particularly challenging because these
controllers are very obscure.
There's virtually no public documentation
available, no data sheets.
People haven't even heard of the
manufacturers like Apple Tech or
Sky Medi-.
You know, SMI, these guys, they are, they
make millions and millions of
microcontrollers that you probably have
them in your pocket. It right now, but
you've never heard of them.
And so the bulk of this talk is going
to be our story about
how we got into these microcontrollers,
what we found, some of the hardware
tools we developed. I'm going to focus on
on that aspect.
And as I'm sure we'll talk about the
software tools and a static code analysis
we did to discover backdoors and
controller structure.
So the first step is to acquire targets,
and we wanted probably
a good wide selection of
the most fakest,
worst cards we could find
because they tend to have, you know, the
radius construction and there's one place
in the world to really go find these,
which is Watchmen Bay in China and
have how many people you have heard of
Shenzen or watch them be in China.
Oh, good, good.
I'm very good. That's very pleasing to
see that people know about the area.
It's like my favorite place is like, I'm
like a pig in shit, like rolling around
their components.
This is this is a typical picture
of of a vendor booth there.
So this guy is sewing flash memory.
He has a little glass stall and
inside of it. If you could see from the
picture, it's packed like with
probably, you know, 50000 flash
chips or so you can walk up there and
say, Hey, I like 20 flash chips.
You negotiate price in Chinese yuan and
some cash gives you something and you
know, it's cash and carry.
If you got fake ones, it's your fault.
If you got real ones great, you got to
deal wherever it is.
So wondering on the market, you know,
there's little vendors here who sell lots
and lots of SD cards
of questionable origin.
Lots of them are use cards or fake
cards or whatever it is.
This one's, you know, proudly
advertising that can give you a 512
megabyte SD card.
Very exciting.
And we bought a bunch of them and
tore them apart.
Eventually, I got very good at using
nothing more than a pair of wire cutters
to extract the circuits
on the inside of an SD card without
damaging them.
And you learn all sorts of little things
like how to tell if a card is
fake or real, or like the construction
of the inside by just sort of feeling the
card and and and
bending it a little bit.
This is what's on the inside.
So there's generally a couple broad
categories of SD card construction
we found on the left is what we call a
discrete construction.
They have a standard teashop flash memory
that started on to the board when we
show it removed on the left and a little
spot where you see the red circle is
where the microcontroller is the chip on
board with a glob of epoxy on top.
So if you if you knock off the epoxy, you
can see the chip beneath it.
One interesting thing you see this little
sort of little bit of cut tape.
They stuck on the inside there.
That's actually not a mistake.
They actually put down the inside to make
the card feel stiffer so that if you're
doing the field test to see if it's fake
or not, you don't know.
It's a very cheap way to do that.
And then on the right hand side are the
what you call the monolithic
constructions. Typically, the higher end,
more reputable vendors like SanDisk will
use this construction.
Everything is molded into a single piece.
There's no opportunity for tampering with
the flash or replacing it with fake
flash. But you'll notice on the back side
there's a set of test points.
There's a little gold dots in the bottom,
and if you put up, you know, a saw scope
on it and you see the card boot, you can
see actually, in fact, identify the
Alysha Leave right enabled chip enabled
data pins for all the flash on the
inside. And there's also a set of pins,
which look suspiciously like JPEG tag
pins for a controller.
One thing sort of interesting thing is,
of course, you know, I like to take
apart stuff and see what's on the inside.
And so we want to recap some chips.
Some of these over molded chips
are actually really poorly constructed.
So the first thing my instinct was to go
ahead and we have to go find some nitric
acid and get a, you know,
safety goals and a few more and
everything like that to go and digest
these zombies.
It's like, I don't know.
I think you can just take this off of the
screwdriver. I'm like, Nah, I can't do
that. So he starts, he starts playing
with it and starts flexing it in like the
top just pops right off.
And so you can see, like on the upper
right hand side is the top.
You can see the imprint of the the chip
and the the PCB in the plastic where it
was bonded and the pretty
much the perfect intact chip and the
controller and so forth all just kind of
coming out. So this was the easiest
job you ever did.
There's some pictures of some of the
hardware that we built for tapping
one of our first generation.
We want to tap the monolithic cards.
So he built a little jig that could
hold the SD card in a frame,
and then it would press down and there
would be this spring loaded pins
they would touch down on to the test
points in the back.
And then this would then hook into
another board that we had actually made
ourselves called Covenants 800 megahertz
Linux board with an FPGA, and we could
go ahead and monitor the
SD pins and in the flash internally
using this mechanism
that turned out to be not the best
approach because it was very hard to get
the alignment just right, and the cards
does a lot of mechanical issues.
So for the second generation, we decided
to build disposable tap boards.
These are actually flex PCBs.
So there I have
no.
I have samples here.
I can show people if they want to come up
afterwards, but they
they are flexible.
I should take that.
So they're flexible and they bend
over on themselves like this.
So the general idea was that there was
there's there's supposed to be in the
in the region there that which looks like
the foot footprint for a tie up.
You can go ahead and start of that in
place of the flash memory.
And then you would flex the the the
board over onto where the SD
pins were and the fact that was flexing
and we had a long piece right there.
We accommodate a variety of sizes of
boards, so we didn't have to layout.
Just one board can use one tap board for
multiple cards.
This is what the
cards look like when they're actually
mounted. So in the middle kind
of on the upper middle, you can see what
when the SD cards look on the inside, we
took off the flash.
We went ahead and put the tap board and
placed loop to flex back over in the
backside and put the high speed hide
around it, plugged into our
nabena platform, which we designed
ourselves because an FPGA and so forth,
the high speed header.
And and then on the left, you can see we
build a version for doing monolithic
chips as well.
This is what the tap looks like in
system. So again,
the on the on the left hand side and the
lower left there is the
the tap with the SD card mounted on it.
And then above it is.
Some of you may know this better as our
open source laptop motherboard,
but we actually use it as a general
hardware development platform for all
kinds of things. When you have a hammer,
everything looks like a nail.
And so has this one here has an FPGA
120 256 megs of DDR3,
a quad core arm CPU
on the inside, and all the other fixings
that you need to go ahead and build
a functional system.
The tapping system diagram
you can see here this is sort of like a
block diagram of what's on the inside.
The green stuff is on the FPGA,
the sort of the pink stuff on
the right or salmon or orange.
And what this link is is the Linux host.
It talks through a memory map to register
interface and then
on the bottom side is where the SD card
is. And for the SD card, we
can either override
the memory of the flash chip and do
what we call Romney leader.
We use the DDR three memory to go ahead
and emulate about 256 megabytes
of flash memory or if we want bigger, we
just loop it over and over and over again
and just record when addresses
are out of range.
Or we can go ahead and just do like a
logic analysis with it.
We can go in and capture traces of
the microcontroller, talking to
the SD card and the memory internally.
So what this system allows us to do is
from the from the Linux host, we can go
ahead, control the SD interface,
observe what the controller does to the
flash, modify the flash
on the fly without the controller knowing
and see what the controller does in
response to that. So it's a very good
system for automatically phasing
and scripting and figuring out what these
controls are doing on the inside.
And, of course, is a
tool that is indispensable and this is
around reader, the humble run reader.
And this is actually the beginning of one
of our most successful threads.
Let's figure out what's going on.
We found a discrete implementation that
luckily used SLC memory,
so SLC memory is a very easy
to read with round reader type of memory.
We found exactly two cards in the whole
market that were still using SLC memory,
and this is, of course, easy just to
strings and cat four.
If we took it around first thing and
found this string on the inside China
build, when SD controller
go into Google Plug in a little bit of a
bug, come out OK, there's a chemical
appetite that makes this likely an 1851
figure, probably the 211 microcontroller.
We figured that somehow
that firmware that's on the on
the on the memory card had to get there.
So there has to be some sort of factory
tool for flashing that firmware
in. And so we went ahead and we
did a little research to try and figure
out, you know, can we find
the tool that they're using or whatever
it is? And this is where I'll hand the
presentation over to jobs to talk
about that part.
So if you ever need to hack on a dodgy
Chinese product, there's a website that I
really recommend you're going to.
Baidu is the Chinese
equivalent of Google and we figured
that it was an to 11.
And so we type that into Baidu
and the first side
hit up there's for car.
The second one know what that is, looks
like a phone. The third one is
an X to 11 SD and you click on that
and you brought to this page, which will
actually let you download the software to
program the card.
That's pretty lucky, first step.
So you open the program until it runs on
windows and you're greeted with this.
If you actually translate this, there's
some really interesting strings.
Go ahead. If you actually translate this,
you can figure out that this is setting
every parameter for the SD card that you
want to burn. You can set the manufacture
code. You can set the serial number in
the bottom right there. You can actually
set right now set for auto, but you can
have it manually. Specify what it reports
the card size to be, which if you're
making counterfeit cards, that's a great
box to have.
Now we're looking through the actual
program and we noticed that there are
some strange file names.
This is what the directory structure
looks like, and there's the normal
windows executable. And then there are
these directory.
These these files called there's a scan
dl l a five test boot
deal.
What's a deal l file doing in a
firmware program?
We thought, you know, maybe if you open
it up in Idaho, it's not x86 code.
What is that?
We decided to open up it and
actually read it as 1851 code.
We were greeted with this, which if
you look at it, that's actually
completely legal 1851 code.
There's just one problem with the 1851
Byte code.
This is where I got this firmware file
from.
Uh, that's just random noise.
It's completely legitimate.
1851 executable code.
The CPU will try to execute this and
make it somewhere, but it's not
not useful information.
8:51 has a really dense instruction set.
If you look at this is every single one
of the eight beat up codes.
There's one up code that's undefined.
Anything else, a code to an instruction?
So this is our data sheet that we found
it's one page, it's in
English with the data sheet
we've reproduced in Chinese.
And if you zoom in to the English, you
can get all sorts of interesting features
that this has a couple of ones to
call out. It's got sports, SLC
or MLC. Those are the two kinds we saw.
It's actually available in an actual
chip package in addition to the dye form
that we saw from the from the markets.
It's also got a 32 bit risk
CPU, which
kind of puzzled us for a while.
We thought the A51, that's eight bit
what's up with that.
Anyway, the actual programing process
goes something like this.
There are three devices involved.
There's a Windows programmer.
There's what we think is an 1851 program,
and we never actually saw this device,
but we saw that we buy.
Disassembling the Windows program have
managed to figure out kind of what this
thing does.
And then there's the actual 1851 SD
card or the actual A6 211 SD card
that is under test.
And just in terms of the program, is that
the main process? What happens is you
open the program or program Windows
application, it loads the firmware onto
the X to 2005 program.
In jig, you say that you want to burn a
card. It then loads a
512 byte test boot up bin
into the tool of an SD card.
The SD card responds ready.
It sends over a flash scanner that
actually verifies what the flash size
is. It tries to determine what brand
of flash you're using.
It does a bad block scan and
then eventually the X to the
Windows software uploads a programmer.
Then it uploads the bin file and then you
have an SD card that's all programed.
And it does this all over the SD
protocol. And I'm just going to go into a
little bit about this because it comes in
really handy when you're trying to
access this card.
The SD protocol has three main
signals. There's command, there's one
to four data signals and there's a clock.
And the way it works is every time the
clock seven of those low, it samples the
commander data signals and every
channel is protected by the command.
Signal uses CRC seven and
the data channels use CFC 16.
There's one CFC 16 per data channel.
Just as a side note, most cards also
support spy mode, which if you're going
to connect an SD card to like an Arduino
or something like that you talked to in
spy mode, but everything we did talks
to it in normal native SD mode.
Now, in SD protocol, there are 64
possible commands labeled zero through
63.
Some of the interesting ones command zero
is reset, and that's the very first one
you send to a card when you want to talk
to it. It's supposed to not respond
at all when you power it up until you
send commands zero.
Some of the other interesting ones are
Command 10, which is the gift card
identifier.
There's Command 41, which is like, we're
going to escape and run in a
different set of commands.
But there's also these are called Class
eight commands 60 through 63 that are
explicitly reserved in the specification
for manufacturer.
So that looks pretty interesting.
Every command also takes 32 bits of
argument data, so if you look at the
bottom, you send the command,
followed by the argument data followed by
the CRC seven, followed by just an end
bit, and the CSC seven in SD
mode must actually match the
data. When you're running in spy mode, it
actually turns that off.
But for us, we had to get the CRC seven
correct.
Now, when the car responds, it sends
another 48 bit response back
to the host.
It sends the start, bit the transmission,
bit the command that you sent it
and then a 32 bit card status field,
which has this really interesting bit
in there, the illegal command bit.
So if you send a card a command and it's
not in a state, where can you respond to
it? It will respond with
this invalid command bit,
which means you can now fuzz
it. You can send random commands.
Look for that illegal command bit.
And if you get either a freeze
or a not
illegal command back then, you've found a
valid command. Great.
So we're going to do is we're going to
fold the sequence, we're going to reset
the card, we're going to power it down
power to send the commands zero to
actually reset it.
Then we'll send a random command with a
random argument, check for a response.
And if it doesn't respond or if it does,
if it responds with a not illegal
command, then we
have something interesting going on.
Maybe its code execution, maybe not.
If it doesn't respond, it probably means
the card crashed, which is great.
Now there's something interesting funny
show this picture earlier, which shows
the X to 11 nicely labeled right in
the middle with no NAND attached anymore.
The idea was you're supposed to use the
rommie later that we wrote to emulate the
ROM.
But the interesting thing is, with this
particular card, if you reset it said it
commands zero, it'll still respond to
some commands.
It will respond to commands zero because
that means go ready.
It will respond to things like turn CRC
on or off.
But the go ready command,
the Hey, I want to actually read the file
system doesn't work because of course, it
doesn't have either firmware or
any NAND flash to store it on.
So the actual fuzzing, we didn't get much
huge success just because there's, you
know, 64 times two to the 32
possibilities.
But the nice thing is the fussier can
actually run on its own and just let us
know if something's going on.
So we can let the fuzzy run and we could
try a different approach so we won't look
at that x 2005 firmware burner
to see if there's anything interesting in
there.
And you open it up
and we notice it's a bit banged SD.
This is also A51 code,
and this is a subroutine we found
that all it does is it checks
for a bit.
It turns a line, low
weights one cycle turns the
line high.
Now that is.
And Steve Cycle, that's it, clocking in
an SD bit and then releasing the line
high. That's pretty good.
Based on that, we know that it's actually
SD
now in looking at the firmware, we
noticed somewhere up the stack that
there's actually this string a PPO.
Well, we know this an Apple Card that's
kind of an interesting string.
It's also four letters.
It's also preceded by constant
63, which is squarely within
that command reserved for manufacturer.
That's promising.
So maybe the Knackers Command 63,
followed by a PPO and sure enough,
we send that and the cards seem to
respond. It doesn't say invalid command.
And if you send it 130
bytes, I say it will
not respond if the CFC 16 is valid,
which probably means
it can encode code. Great.
We have a problem.
What code we run like you?
An exit, you have a CPU, you're executing
code on it.
Now what?
Well, we know that they use
the protocol to actually run
code and get a response, so let's just go
ahead and do that. And the nice thing is
we have example code,
so we have the test boot that it sends
first. It's five it until bytes.
It's easy enough to analyze.
It tells us the entry point, which is
really important because that could be
anywhere in RAM, and it also contains
the SD state machine that they can't
communicate with.
We also have the former dump that we did
from the original card, and this is
pretty interesting if you use IDA and
you highlight a particular function,
it'll highlight everything else that is
the same address.
And if you look at the SD card spec over
there, I've highlighted all of the
reserved commands for the first
14 possible SD card commands,
and you'll notice that the pattern of
yellow boxes matches up directly
with the pattern of
functions that are jumping to the same
address, which probably means that this
on the left is the SD card
state machine for the actual live SD
card, which is another good
source of, you know, they do
it there. Why don't we do the same thing?
So the first thing we do to write a
debugger is we borrow test boot up in
and it doesn't work.
We don't already have a debugger, so we
can't figure out what it does.
And the first thing I want to do and this
is maybe we can wiggle a pin, you know,
get some sign of life.
So we decided to go hunting for a Jeep Go
Jeep GOES-R, you write, a bait line goes
high. Clear the bite, it goes low.
It's probably going to be one to three
registers. One register is definitely
going to be the value.
Another register might be to setter clear
pull up. We don't know.
Another one might be if a pin can have
multiple uses, it might be a set pin
function register.
And what we're going to want to do is we
want to target them low and high and low
and high so we can look for some sort of,
hey, this is wiggling up and down.
That means that it's alive.
Cyril Ramaphosa, another father,
poses a grave.
And the father is going to take a random
number and poke it into a random
value in the special function memory
map register area.
It's going to delay a while, it's going
to change that special function register
value to a different value.
It will delay again and repeat.
And this is actually working.
We should be able to see on the host
the line going low and then high and then
low and then high. Just kind of a Hey,
I'm here.
And so we let this run. We let it run
for, I think about three hours before we
finally got a hello world that worked.
Let me explain this, what this does is
this moves the constant zero zero into
the special function register.
If it sleeps,
then it moves the constant fefe into the
register. F sleeps again and
it jumps. So that's just writing zero
zero at the GPO.
And when you read the pins, the SD pins
from the host.
You could see it going up and down.
It's gone from 2G to WD,
which is great.
We now have Hello World.
So we know that we have code running.
We know we have some sort of one bit bi
directional information.
Great. It's enough to actually get code
working. You can try things
by comparing the test to tap in and
sticking this hello world.
In there, you can figure out where it's
going. You can figure out which jump
sequences are it's hitting, which
is not. And eventually you can build this
up and you can get bi directional SD
communications.
And so we wrote a debugger on this.
What we do is we send a command
with four eight bit arguments and that
ends up getting that. That fills that 32
bit SD argument.
The card looks it up on a table,
responds, sends a command
back with the same value in a four
eight bit values, and it goes to
one.
And so we implemented a debugger that has
basic pick poke.
You can do GPO detection IQ status.
We interface with the NAND emulator so
that we were able to determine
what's going on with the how the NAND
registers work.
And we also found maybe
the data she was right.
Maybe this is a 32 bit CPU because we
found these up codes that are what's
going on there.
Turns out A5, that A5
CPU up code is actually
a 32 bit command standard.
A51 does not define this at all, but it's
all over the place in the X to 11
firmware, and it's always in the format
of a five plus one
byte or a five seven something
and then another bite.
Which brings us to the question What is
this chip? Is it a bit or is it 32
bit?
We found that these four registers or 32
bits.
We wrote a stop debugger command that we
can use to send random, arbitrary A5
instructions.
And we discovered, at the very least, we
found 32 bit clear not increment and
decrement instructions, which when you're
writing a CSC 16 engine and software and
an eight bit CPU are really useful to
have.
But there's a whole huge opcode
space that we never actually looked into.
So I'm going to turn it back over to.
Bunny is going to talk about the
extra 15.
Thanks, Sean.
And so again, there was a link earlier
to a GitHub repo where you can
go ahead and see all the code that we
have for the debugger and running it, and
you can go ahead and actually
replicate most of this.
The code is is custom to our nabena
platform, but because the actual GPIO
protocol to see is doing bit being,
you can port it to a Raspberry Pi and
Arduino or something like that if you
want to go ahead and play with these.
Which leads us to a point which brings us
to the 215 the X
211. As I had said earlier, we found
two of these in the market the really
old. And when we contacted the vendor,
they said, Sorry, these are end of life.
You can't buy x 11.
And we were like, That will be really
lame. If we go to CCC, we'll talk about
a card where there's only two in the
world that you can hack.
And so in preparation
for coming here, we we asked
them what is the most recent
card that they have?
And they say there was x 215 and
we said, OK, that's fine.
We'll go ahead and look at it.
It's basically it's very similar to X
to 11. It's faster runs at 90
megahertz has more.
GPOs has a slightly
different, actually radically different
special function register map, the harder
map, harder register mappings.
And we went ahead and repeated the
fuzzing and the activity to bring up the
debugger in the X 256.
So we put forward ported the debugger to
the X 215.
There's one really important difference
is that they got a little bit smarter and
obfuscated their code
binaries that were stored in these,
you know, the things that would be using
the factory programmers, but this is the
whole routine that they use for
obfuscation. They came with some, I don't
know, crazy.
It doesn't even look that good kind of
byte shift swizzle kind of thing, but
we can just pull it with it and
get it to run.
And so we, you know, we
wanted to make sure that so
sorry, we say it
because it's not obvious what
controller is mapped was what flash.
When you buy a particular card, it's very
hard to say, just go ahead and buy like
bazillions of cards and keep trying them
until you find one with appetite control
on the inside.
So we went ahead and we.
Brought along
a couple of hundred SD cards
to the talk, which they're
actually very cheap, they're about one
euro apiece. So we're just
going to leave them at the front of the
stage after the talk if you want to grab
one.
You can grab one and go ahead and try to
play with it and see if you can get
something to run on the microcontroller.
Because I'm a very big fan of being able
to run code on any hardware that you own,
including your SD card.
So.
So we'll just leave them up in the front,
just just please only just take one.
Don't try to take a whole handful of them
because, you know, we only have a couple
of hundred of them, so.
So now time for tinfoil
hats. Right.
So now that now that we know that we can
run code on these things?
What are the scenarios?
Well, there's clearly a scenario
for eavesdropping.
This is the case where unlike the people
who are selling you fake cards, we
actually give you a card with much more
memory than we say we have.
So there's eight gigabytes in a card.
We say we only have four.
And then when you go ahead and
you write some files in there, we look
for properties in a file name.
We take a copy of it.
We put it in, save our banking store and
you can go ahead and do everything you
want from the File OS label.
To erase it, you can fill the card with
random data and you raise it and raise
it. But it will never.
You'll never touch the stuff in the
banking store so we can do eavesdropping
with this mechanism.
There's a time of check the time of use
attack where, you know, for example,
a file can be presented in one version
for verification, another for execution,
which is an opportunity for all kinds of
fun manipulations and
also because SD cards are so massive.
I mean, it's not inconceivable to also do
things like selective modify.
So four gigabytes
is plenty of space to hold lots
of versions of particular files.
So if you were to go ahead and try to
copy some source code and there you can
look at the name of it, know your random
number, generator whatever it is, and
say, Oh, if it's a random number
generator, we'll go into our huge library
of random number generator files, go
ahead and swap one in and actually store
this one instead.
On the cards for the next person, reads
it out gets a different version of the of
the file.
We can go ahead and modify
keys, for example.
It's very easy when you can, when
you know where the keys are to go and
change a few digits and make them very
insecure factor and so forth.
So there's a lot of scenarios where
if you want to put on your tinfoil hat
and worry about what's going on,
we've always sort of trusted that these
controllers on the inside are running but
running correctly and doing the right
thing. But currently there's no
protocol or no method to attest
to the code that's running inside of
these things. We can't expect in the full
black boxes.
We just trust them that we put a secure
data on it and everything's perfectly
fine.
Other directions
are that we could go into
is there's the
the snow here that we had.
We've been pointed to the Samsung
actually had pushed a patch, a firmware
patch to eMMC
EMC cards, which are basically
SD cards and BGA form factor
cited on to a motherboard
inside Android device.
I think they're in like the note or
something like that.
And what was happening was that during
certain operations, the devices would
break. They would just not come on
because their city controller would would
go tits up.
And so in order to fix
this, they went ahead and pushed a patch
to all the cards. You can run it.
And so some enterprising people were
like, Well, what's inside this patch to
look? And inside they find this arm code
on the inside again command
sixty two, which is right inside the
reserve space, a few bytes that look
like knock sequences, you can go ahead
and bring the card in to RAM reading mode
and so forth. So these are these are
cards that are known to be in particular
mobile phones, which have a
vulnerability that was essentially
published by the manufacturer
to go ahead and let you update the
firmware.
Another sort of future direction is
TLC and MLC flash.
So this is this gets in a bit of the
details of how flash memory works.
TLC stands for a tri level
cells. They actually store three bits
Purcell, so it's eight voltage
levels. Purcell, they're
great for density.
They're terrible for reliability.
They actually have a problem called read
disturb, which is if it sounds disturbing
to you, it is.
It means that if you keep reading the
data, you can actually disturb adjacent
data and cells from these particular
memory cards, right?
So not only does a controller have to
control like where the bad blocks are, it
has to say if you've read a block too
many times, we have to read it back and
refresh the data again in order
to minimize this problem.
They have to do some manipulation of the
data stored on the card by
exploring it with a scrambling algorithm,
which helps distribute the states across
the data. It's data dependent.
Its proprietary algorithm, it's every
vendor has a different algorithm,
but as you can see the data, how you
structure, it just took one of the ride
dumps we have and put it into an image
viewer. You can see there's a lot of
structure in the code, so it's not really
there using. It's not for a security type
thing. It's more of just making sure that
the statistical properties of the data
stored is consistent with something that
minimizes the reading of issues.
So sort of on a wrap up.
So SD cards and also
any sort of flash type
memory will contain a fully programable
microcontroller, perhaps a very powerful
microcontroller.
This applies to SD cards, micro SD
cards, EMC,
SD, USB controllers.
The controller program, we have
demonstrated, is modifiable by a special
host commands, and these are typically
not locked out because of the complexity
of the flash memory space.
You want to mix and match controllers to
the newest latest greatest flash chips,
and they can't really burn the code into
the flash chip. The half have a way to
load code into them and oftentimes
patch them in the field so they don't
close the hardware backdoor.
This on the Black Hat side
is a potential for man in the middle of
tech scenarios.
And the sort of the white hat side, which
is what really got me into the project,
is is a potential for an extremely cheap
microcontroller for fun projects.
You know, I couldn't stand up here in
Canada or do we knows that costs like $20
a piece or something like that, they're
too expensive, but these are one euro
apiece.
These cards only have 100 megabytes
of memory on them, or so, they say.
And and and the
thing is, is that if you can control the
SD card, it is either limited,
but it makes a great data logger.
For example, you can go ahead and you
know, being a password C or a spy
and have a single chip data logging
solution for one euro, which is very
exciting to me.
We want to just give a special thanks to
show it to Mudge, who had created the
cyber fast track program, who
enabled this research and many
other good things. Some are still yet to
come.
So thank you much.
And now we're going to cut to a
demo, which we do have time to allow for
this. So can we get the camera over here
and maybe get the camera showing on
to this device here?
Just a minute. Yeah, this one here.
So there's lots of stuff on the plane,
including get the view on.
There you go. So we gave this
presentation on November
or the laptop we built ourself.
And so you can see.
As I mentioned, is a quad core arm
device, and it's running, you know,
this one's running Ubuntu, this one's
running Debian, so you can
have your pick.
No, no religious words here
and in here is actually the
we have the SD card plugged into a
adapter, which is going into the FPGA,
which is on the main board, and
jobs would go ahead and demonstrate sort
of the, you know how this all works?
Can we can we actually get like a picture
in picture for the for
the for on the console screen as well as.
All right.
So.
Here you go. Perfect.
So he's going to go ahead and configure
the FPGA on the inside with the
the firmware file to go and have it.
It's actually just we just cap
the bit failed to dev SBI
and then we go ahead and we can run the
debugging software.
Give it the argument to the binary for it
to run.
What are you going?
What's going on?
All right.
So the first thing the debugger does is
it goes ahead and tries to knock.
You could see because the card wasn't
plugged in all the way.
There are a few tries times it tried
where it didn't actually communicate with
it, but eventually it managed to load
the debugger and check the card
communication. So it actually sends a
random set of packets back to the card,
and the card is supposed to echo random
packets. Back then,
it dumps the ram of
the SD card that dumps 512
bytes, which hopefully is our program.
And after that, it looks through for some
fixed up posters printed to the screen,
enable some interrupt service routines
and presents us with a show.
So we've got a few commands you can run
as Hello Peek Poke the usual ones
jump so you can load code in with peak or
with poke and actually jump to it.
There's the IQ, which is what
we use to figure out what the IQ table
does.
This card has four or five.
Syracuse 024 IQ
zero we know of just from 1851 is
reset.
If you look at this, I accuse one or two.
They're not zero.
And if we query the excuse again, they
keep going up.
So these are these are counters for the
number of times the Syracuse fire.
Yeah. So yeah,
because these numbers keep going up, it
means IQ is one and two are probably have
to do with the SD communication.
Other things we could do is you can dump
the special function registers.
One of the nice things about 1851
code is that there are only 128 possible
registers makes it really easy to fuzz.
There's also an external optical command,
so I mentioned this
in the talk where you can actually have
an execute, an arbitrary opcode.
So, Senator, a five
and then one
day.
Sorry.
I guess so back so you can send it
up and then one
zero
starts, it's our cue.
And you can say that we now have negative
one Syracuse.
That's that's because.
Next up, one zero is the
invert of code,
and so using this, we can actually fuzz
all of the up codes on the system and
basically generally figure out how this
card works.
And so and so the you know, just just
to clarify, the two counters are actually
using the 32 bit registers that we
discovered inside the A51 because
you want a bigger than 256 bit counter.
So I do use the stop codes to go ahead,
manipulate these extended instruction
sets and say the A51 to implement the
the IQ counters.
There's a disassembly in here, right?
We can actually disassemble
four seven zero zero or disassemble
64 bytes at Oxford
seven zero zero, which is the entry point
for the debugger.
When you load firmware, it gets loaded to
address four seven zero zero and
four disassemble that. We can actually
see there's the opening to
our debugger, plus our jump table.
Cool. All right.
So.
Read The Democrats are kind.
Yeah, so this thing worked amazingly.
I guess we can open the floor to
questions that we should have time now
for questions. So thanks everybody.
Thanks for coming.
Thank you so much.
And yes, we have quite some time left for
questions, so as always, please line up
in the room in the middle of the room or
if you have questions from the internet,
please write them on IQ or Twitter and
we will ask them life in the room.
So we please have a question from
microphone number one,
a very short question.
USB sticks
USB sticks also contain microcontrollers
on the inside.
In fact, if you look at a lot of the data
sheets, the ones that are made for SD
can also be used for USB use through the
USB, and they're virtually identical
in terms of the composition
actually to follow on that.
The X 215 factory programmer
actually uses an X 216
USB controller in GPIO mode,
so they actually use one USB continue
to program the SD controller.
Yeah, OK, microphone number two, please.
Hey, thanks for a great talk.
I'm really not knowledgeable about the
whole topic, but I wondered if you have
looked at the host site, like if you if
you have a laptop that has an own
microcontroller for communicating
with the SD card, right, then
I guess there are microcontrollers
for which some exploits are known.
Do you think that, like
we, the microcontrollers
in the SD cards are powerful enough to
basically, yeah, write some malware and
then you have some SD cards.
You plug it into your laptop, someone's
laptop, and you basically do
evil stuff there because you only talked
about man in the middle right now, and I
think you might be able to do even more
evil things.
I see so more like an active attack
where you plug the card in and the stuff
comes back. I think, yeah, I mean,
it could be possible.
The part of the thing about the SD
interface is it's that the host drives
the communication.
So if you tried talking back to the host,
it just it doesn't really do anything.
But I could imagine on the USB cards
there could be some other potential
venues for attack and so forth.
But I mean, there are a lot of I mean, to
your point, there are a lot of embedded
microcontrollers within every
like system that we don't really see.
So in fact, like a lot of laptops,
the SD readers actually implement itself
with a USB device.
So when you plug the SD card in, it
enumerates is a USB device.
That's because there's a microcontroller
inside emulating the C interface to the
laptop, which itself can be another
venue for potential exploitation.
So there's a lot of these layers and
layers that we just sort of trust
in everything.
Microphone number one, please.
I'd like to know what is
your guess?
Has this type of microcontroller
already been used before
for malicious intent or
for, for example, some proprietary
measures like DRM in the
wild? Aside from just being on like
my trusty controller,
what's our guess for that?
I mean, or
do you know?
No, no, I I don't
know of any
solid instances where it has
been done.
I do know that I we've been to the
factories where they burn the firmware
in. And there you can basically
just walk in and go up to the burner
and replace the files on it.
I mean, like literally as chickens
running through the factory and shit like
that. And like, there's no security,
there's no badges you just like,
here's the burner, right?
So it's like that.
And then they make these things and they
ship them all over the world.
So it wouldn't be hard for
someone to do that, whether
it's been done or not. I, you know, I
don't, I don't know so.
A key microphone on the tube, please.
I am.
I'm just wondering why you didn't mention
it will be because you're talking
about the host player and say it.
Yes. And she has to, but we have to
be well, albeit because
it's very known that all of this
is on chips.
Things are are very, very bets.
And if you're building a sane and better
device, you have to use flesh and
whoopee. Otherwise, you toss it.
Well, the actual answer to that is
because we stopped using NAND flash just
before we became popular.
So by the time that was the go to
standard, we were already moving to the
SD card stuff and we just pretty much
haven't looked back.
OK. So please look at it.
It's very nice.
OK, fair enough.
OK, no request from microphone number
one. Yeah, you mentioned that the
code and the controller is not protected
because of reasons.
Is there a possibility to protect it?
Is there Lockwood or something?
Can I flash a very special film and and
protect it from being overridden?
I think I think when we looked at some
of the SanDisk cards, they look like
there is some kind of maybe
protection going on of some type.
We we this
work was looking for the path
of least resistance to demonstrate the
proof of concept.
It doesn't mean that all controllers are
this bad per se.
The I don't want is bad in a
pejorative term.
It's just that
the the
when you are a manufacturer of third
party controllers and you're not like
SanDisk, you can make the controller and
the flash device yourself.
You have to make it so other people can
modify and load code on it, so you
get more market share by being very open
and sharing within that group of people.
The loading standards and so forth.
And so because it SanDisk,
if you look on the inside the die shots
of the controller, say SanDisk, as well
as the die shots and the flashes SanDisk,
presumably they're doing a lot of meeting
on the inside and mixing and matching,
and they can they can lock it down a bit
a little more carefully, but presumably
also they're not.
I mean, they're definitely not crypto
grade.
You know what I meant, primarily from the
tinkerers perspective.
If I buy one of those cards, can I
can I protect it
or can you protect it?
No, coming.
OK, so do we have any questions from the
internet?
There is one question and
Root asks, he had experience
with reduced card space on
3.8 gigabyte cards toward
two point eighty two gigabytes after
he changed the file system to
extended formats about three
times with same reduction, which was
apparently an amazing experience.
So I'm not sure exactly what
he's asking, but he's right.
What kind of flesh and VRM
would you recommend?
Looking for brand recommendations, yeah,
I I don't
really endorse any in particular.
They all they all have problems.
Just, I don't know.
I mean, like even even the big ones, you
can get fake ones because
I mean, again, the the industry
runs on such such tiny margins.
These fabs, basically, if they don't run
at exactly 100 percent capacity selling
on a good day, they're losing money.
These these memories are so incredibly
cheap. And so everywhere inside the
supply chain, there's a ton of pressure
for people to cheat, take old materials,
scrap it and recycle it,
like if you're one of those people who
are concerned about us.
This is great.
All your flash is being recycled.
There's no flash. So in a way, you can
sell it to you as a perfectly brand
spanking new card.
But at the end of the day, even
I mean, the intention of the
manufacturers is very good, but the
supply chain doesn't execute as well.
So I, you know, I can't say for sure
which one is going to be the best
to buy.
OK. A question from microphone number
three, please.
Hey, I was wondering, I really like
the work you've been doing on SD cards,
but I'm also curious about how that
applies to other forms of flash,
particularly things like MTD devices
on Android devices.
Do those also have these kind of logic
layers in there, or is that raw flash
that's handled by the OS?
Know the Android devices or typically
use in NAND or EMC,
which is exactly SD spec,
but just some different physical form
factor.
So and I had the one slide
where basically the EMC devices are empty
devices on Android.
Those those have a notable firmware.
They're known to have a lot of firmware
and can be modified.
OK. As a follow up, kind of unrelated,
but I'm wondering if if this
like the tool that you found was
accessible enough that like like
overclockers and things like that could
kind of poke at the memory that the
bad blocks and see if they were actually
good and try and squeeze some more space
out of the cards?
Yeah, yeah, you could probably try that.
I mean, if you're yeah, if you want to
live dangerously,
like I said, flash memory is already
pretty, pretty crap.
And so trying to eke out more space
from your card by going to what are known
to be bad blocks and use them for storage
is caveat emptor, right?
So, yeah, thanks.
Yep. And microphone number two, please.
Thanks for that great presentation.
Did you look at SD cards that have
embedded Wi-Fi?
No, we didn't.
We didn't look at those those and those
clearly have a controller on the inside
and they meaning they're known to run
Linux and other stuff, stuff like that.
We didn't look at those, but those those
are probably also an interesting target
for hacking
microphone number one.
Hi, can you guess
our estimates of the market share about
the EC's two one five?
Is it like one percent or is it like 20
percent?
How widespread is it?
Probably a tiny fraction of a percent,
Mike. You know, there's billions and
billions of micro SD cards made
in the world per year, and
the biggest players are SanDisk and
Samsung, and those guys will sometimes
buy controllers from smaller players like
SMI and A4Tech and so forth.
But they never tell you which ones on the
inside of those particular cards will
never reveal that it's a kind of a trade
secret for them, so they may have.
I mean, they've made
tens of millions, maybe hundreds of
millions of these, but compared to
billions of cards, it's a very small
fraction still.
So and a lot of question from
Mike Vernon before,
you know, I just remark
about those quite feisty icons a
few months ago, there was some story
on the horizon about
some white folks with a fully fledged
arm controller and it had
Linux running on it.
And I think they were evil
pretty easily able to root it and
turn it into some sort of
access point or some stuff like that.
Right. And I think it has really
great potential for a little
more interesting man in the middle
attacks and some
other eavesdropping scenarios.
So I think that's really
something to worry about, especially if
you think of a scenario where somebody
will label such a.
It makes it look like a normal dump
SD card.
Right, right.
That's true.
And it does. There's nothing that stops
people from like not using one of these
controllers, but sticking your own,
you know, taking STEM 32 or and stick
on the inside and label it as an SD card
and just say, like, you know, it's
it's SD flash.
People never take these apart.
So there's a lot of opportunities there.
OK, yeah. And another question number
four, yeah, I want to
kind of track you off
track here a little bit and see if we
could get an update on the.
Um, that would be
off track. We're going to actually
tell them about this.
Yeah, you got
it now.
And so
later on at four o'clock today, we're
going to have at least one of those
informal sessions where we're going
to talk about Nabena a
bit. So I don't want to bore people here
who don't want to hear about it with the
details. So where will I be?
I sit with a fail over to fail
overflow crew.
So it's like, I guess.
And a hack center saw three all the way
back. You see the big white dome turn
left and we're sitting inside the wall.
If a lot of people show up, we might
migrate away so we don't annoy
everybody in the room with, you
know, and the people at my table.
So thanks.
OK, so I'd like to jump in with
a last question as well.
Have you seen any SD cards that like
tell you there is a smaller number of
memory inside and inside there is like a
huge chip, so you could actually re flash
the chip and have a better memory card
like a fork you can do after if you have
a 16 GB memory card.
Have you seen anything like that?
Yeah, yeah. Yeah, I mean, a lot of a lot
of the cards that we got actually have
chips that are technically
have six gigabytes of memory.
But we actually like, for example, we're
find cards that were sold as 128
megabyte cards and they had eight
gigabyte memories.
But they only had 100 megabytes worth a
good sector, supposedly.
But you could re flash it and try to use
all of them if you wanted to.
You just probably wouldn't find you
had much storage. Actually
have random number generators.
OK, so please have again
one of the calls for Bunyan's on space
again for you. Three.
Talk.