WEBVTT
00:00:09.670 --> 00:00:12.346
So, I have already been introduced
00:00:12.346 --> 00:00:14.175
My name is Stefan Widmann
00:00:14.175 --> 00:00:18.325
and maybe I can have my slides?
00:00:26.215 --> 00:00:28.979
Hello, my slides?
00:00:34.489 --> 00:00:39.528
laughter
00:00:39.528 --> 00:00:42.149
Ich bin am VGA drauf.
00:00:47.599 --> 00:00:50.122
[hums]
00:00:52.342 --> 00:00:54.129
Yeah, um...
00:00:57.899 --> 00:01:00.098
[mumbling]
00:01:10.578 --> 00:01:17.191
Okay, so while we're waiting until
my slides appear somehow.
00:01:17.191 --> 00:01:19.270
Who has seen the incredible talk about
00:01:19.270 --> 00:01:22.314
hacking the VoIP phones from Cisco, last year
00:01:22.314 --> 00:01:25.599
either live or on video?
00:01:25.599 --> 00:01:28.034
Okay some of you.
00:01:28.034 --> 00:01:30.528
When we think about this talk
00:01:30.528 --> 00:01:34.945
The Cisco VoIP phones have an embeddd
00:01:34.945 --> 00:01:37.889
Linux operating system, but they did not only
00:01:37.889 --> 00:01:41.889
have to deal with the linux OS, but also with
00:01:41.889 --> 00:01:44.372
the firmware of the DSP.
00:01:44.372 --> 00:01:50.910
So I want to tell you there's
not only one system,
00:01:50.910 --> 00:02:03.300
but several systems. Several
sub-systems containing firmware
00:02:03.300 --> 00:02:06.940
Slides would be nice, we can start
without slides, there's no problem.
00:02:06.940 --> 00:02:09.899
So what are we going to talk about today?
00:02:09.899 --> 00:02:15.497
First we are going to talk about motivation,
why should we do firmware analysis.
00:02:15.497 --> 00:02:25.545
Then we need to be able to do it, so we
have some prerequisites to bring with us.
00:02:25.545 --> 00:02:34.102
Then we'll dig deep into the topics, We will
try to look at how we obtain a firmware,
00:02:34.102 --> 00:02:41.191
how can we analyze it, and how can we modify it.
00:02:41.191 --> 00:02:54.001
Hmm. Angel: We are sorry for the brief hiccup, we're
working on that. It's the second talk. I'm sorry.
00:02:54.001 --> 00:02:58.029
[speaks german]
00:03:33.254 --> 00:03:34.568
Hmm
00:03:37.658 --> 00:03:43.174
Okay, so we can do without slides, it's okay.
00:03:43.174 --> 00:03:48.902
Let's start with the motivation, why do we
want to do firmware analysis.
00:03:48.902 --> 00:03:58.244
When talking to my lawyer I learned that I
had to clean up 90% of my motivation slide.
00:03:58.244 --> 00:04:06.568
And left is, you can do it if you
want to gain interoperability.
00:04:06.568 --> 00:04:10.110
laughter
00:04:10.110 --> 00:04:14.791
You can do it if you want to get rid
of errors, and the manufacturer
00:04:14.791 --> 00:04:21.561
does not want to or is unable.
And one interesting point under
00:04:21.561 --> 00:04:29.240
discussion is, what about forensics,
taking a look in those thousands of devices
00:04:29.240 --> 00:04:35.730
in everyday life. Do they only do
what they are supposed to do?
00:04:43.230 --> 00:04:48.030
Herald: Yes, we are still hunting for a Video
Angel to sort this little problem out. We should
00:04:48.030 --> 00:04:54.123
have one here within 1 minute.
Again, very sorry.
00:05:06.473 --> 00:05:11.986
We now have Nick Farr on stage,
our certified Powerpoint specialist.
00:05:11.986 --> 00:05:17.274
applause
00:05:17.274 --> 00:05:20.114
It can only take minutes now.
00:06:06.331 --> 00:06:10.764
Maybe we can continue. So I will just tell
you something about prerequisites you
00:06:10.764 --> 00:06:19.194
should bring when starting to analyse
You should at least have a good knowledge
00:06:19.194 --> 00:06:26.081
of embedded system architecture.
You should have dealt with peripherals,
00:06:26.081 --> 00:06:32.223
bus interfaces and so on.
You should be able to read
00:06:32.223 --> 00:06:35.185
and write assembler.
Some might say:
00:06:35.185 --> 00:06:39.196
I have a very good decompiler,
which is fine.
00:06:39.196 --> 00:06:45.518
If it works for you, okay, but don't
rely on the availability of a decompiler
00:06:45.518 --> 00:06:49.191
for the architecture you're going to be working on
00:06:49.191 --> 00:06:55.675
Especially if you are going to work
low down in the register stuff.
00:06:55.675 --> 00:07:03.664
And in my opinion, a decompiler output
will confuse you more than help you.
00:07:03.664 --> 00:07:12.542
You will go to disassemble maybe, C runtime
libraries, optimized to be as small as possible
00:07:12.542 --> 00:07:18.368
That can be really hard in decompiler output.
00:07:18.368 --> 00:07:28.726
If you want to practice how embedded systems
are working, then it might be a good idea to fetch
00:07:28.726 --> 00:07:36.340
your arduino or whatever. You write some
little C code, handling some hardware stuff.
00:07:36.340 --> 00:07:45.497
Then you just compile it and take a look,
what the disassembly looks like.
00:07:45.497 --> 00:07:55.767
Very nice to have is a device reader or programmer,
like galib. The problem is they are expensive.
00:07:55.767 --> 00:08:03.931
If you think we are going to do firmware analysis, it
may be a valuable investment for your hackerspace.
00:08:03.931 --> 00:08:09.330
And last but not least, what you need most is time.
00:08:09.330 --> 00:08:16.511
Time, time, time. It may take hours, days
without any progress, so please be patient.
00:08:20.951 --> 00:08:26.560
laughter
00:08:29.680 --> 00:08:35.888
Any volunteers to make up some slides here?
00:08:43.628 --> 00:08:50.974
I swear, it worked perfectly okay with
my external monitor.
00:08:50.974 --> 00:09:04.296
Yes? [illegible]
00:09:04.296 --> 00:09:08.305
So I'll have to fetch my USB stick, wait a moment.
00:09:08.305 --> 00:09:52.524
No problem, we're flexible.
[whistling]
00:10:09.571 --> 00:10:15.257
So is there anyone who knows their
way around a computer around here?
00:10:15.257 --> 00:10:19.803
Herald: While we figure that out, it might
be a good possibility to remind you all
00:10:19.803 --> 00:10:27.505
that we are still looking for some Angels.
You could do video angels, which are in
00:10:27.505 --> 00:10:32.699
high demand right now. Or you could just
do any other work you'd like to.
00:10:32.699 --> 00:10:38.189
You can do one or two shifts, that's fine.
It would be greatly appreciated
00:10:38.189 --> 00:10:49.230
because we require volunteer work for this event.
Also if you brought any beverages in here,
00:10:49.230 --> 00:10:54.262
it'd be awesome if you could take them out
with you. And put them into the little
00:10:54.262 --> 00:11:01.991
storage cases located all around the building.
Trust me when we are finished,
00:11:01.991 --> 00:11:10.768
you'll be able to do this announcement.
Are we good? No, not really.
00:11:10.768 --> 00:11:12.539
laughter
00:11:12.539 --> 00:11:15.812
It looks good on the laptop.
00:11:15.812 --> 00:11:19.184
You want to give a quick intro
to the new Ubuntu desktop?
00:11:19.184 --> 00:11:27.888
Because I did not get that at all.
00:11:27.888 --> 00:11:33.403
Yeah, mirror displays man.
00:11:33.403 --> 00:11:39.708
4 zur 3 folien.
00:11:39.708 --> 00:11:41.821
Now we are making progress
00:11:41.821 --> 00:11:45.502
applause
00:11:45.502 --> 00:11:47.813
Enjoy the talk!
00:11:47.813 --> 00:11:51.747
Okay, perfect, now with slides.
00:11:51.747 --> 00:11:56.981
One small announcement, there will be
5 more minutes of extra talk at the end.
00:11:56.981 --> 00:12:04.203
We'll do that. So just please ignore the yellow bars.
00:12:04.203 --> 00:12:07.805
laughter
00:12:07.805 --> 00:12:18.308
Not really no.
00:12:18.308 --> 00:12:26.333
High level devices. Big complexity. YES!
00:12:28.563 --> 00:12:31.121
Perfect, thank you, without yellow bars, thank you.
00:12:31.121 --> 00:12:41.750
Okay. So we already talked about prerequisites,
so now we're going deep into the topics.
00:12:41.750 --> 00:12:49.849
First we need to obtain a firmware. We
will go from non-invasive to invasive.
00:12:49.849 --> 00:12:57.506
Because first thing we want to try is getting
the firmware without opening the device.
00:12:57.506 --> 00:13:03.262
We will first try to download a plain binary
from the manufacturer.
00:13:03.262 --> 00:13:12.147
or maybe someone else have extracted
a binary and placed it on the internet.
00:13:12.147 --> 00:13:19.440
You can try to download a bootdisk, USB,
CD-ROM, bootimage, whatever the manuf. provides.
00:13:19.440 --> 00:13:25.640
and extract it using, for example, WinRAR
on windows or just mount it on linux.
00:13:25.640 --> 00:13:34.781
Search for files named .bin, .hex, .s19, .mot.
like motorola, .rom or .raw.
00:13:34.781 --> 00:13:42.439
Most times binary, that means .bin, .rom or
.raw files are already real binary files.
00:13:42.439 --> 00:13:50.691
Non-binary files should be converted to
bin files, e.g with converters like hex2bin.
00:13:50.691 --> 00:13:55.876
If this doesn't work out, maybe we get
an updater from the manufacturer
00:13:55.876 --> 00:14:00.461
Normally they're .exe files built for windows.
00:14:00.461 --> 00:14:07.429
There are different updater types.
First the self-extracting archives.
00:14:07.429 --> 00:14:12.417
It might be an installer too,
like Installshield or whatever.
00:14:12.417 --> 00:14:18.973
It might be an updater, simple .exe file
without any installation, just containing the image.
00:14:18.973 --> 00:14:25.493
It might be an updater that is downloading
an image, or it might be some of the others,
00:14:25.493 --> 00:14:31.675
but packed with an executable packer
like UPX or PECompact.
00:14:31.675 --> 00:14:33.487
Let's go a little bit into detail.
00:14:33.487 --> 00:14:43.000
So if it's a self-extracting archive search
for signatures like RARSFX or PK.
00:14:43.000 --> 00:14:53.440
You can unpack them, e.g. if you rename
a PK containg file to .zip you can unzip it.
00:14:53.440 --> 00:14:59.223
If it is an installer, like Installshield, there are
special unpackers, but the problem is they are
00:14:59.223 --> 00:15:06.153
very hard to use and extremely version specific.
It might work, it might not.
00:15:06.153 --> 00:15:10.994
The best way is to just let it install
and search in the installed files
00:15:10.994 --> 00:15:20.242
for a plain image or updater. If it's an
updater containing the firmware image,
00:15:20.242 --> 00:15:26.280
we can search for the image in the executable
using your favorite hex-editor.
00:15:26.280 --> 00:15:33.678
Maybe the updater is writing the data to a file, a temporary file in most cases, and deleting
00:15:33.678 --> 00:15:40.735
it after usage. You can use ProcessMonitor
which is like strace but on Windows
00:15:40.735 --> 00:15:45.903
and you can take a look at what files
are written to disk can try to capture it
00:15:45.903 --> 00:15:52.300
before it's deleted. Maybe the updater is
just checking your device, so its just
00:15:52.300 --> 00:15:57.477
a little downloader. Checking your device
type, take a look on the ftp-site of the
00:15:57.477 --> 00:16:02.519
manufacturer and is downloading an
image if there's one available.
00:16:02.519 --> 00:16:08.583
So if it's downloading the image to a
file, use ProcessMonitor again.
00:16:08.583 --> 00:16:19.289
If it's just downloading to RAM, you have
to go for a debugger, and dump it from memory.
00:16:19.289 --> 00:16:27.297
If you have a packed updater, which
of course is only done to save size.
00:16:27.297 --> 00:16:36.520
If it's standard UPX, you can download UPX
and use UPX -d to unpack it.
00:16:36.520 --> 00:16:44.145
Sometimes the manufacturer violate the
license of UPX and modify UPX by removing
00:16:44.145 --> 00:16:51.504
vital file information to make it un-depackable.
So you would need a special unpacker.
00:16:51.504 --> 00:17:00.730
Other executable packers are most times
designed not to be uncompressed.
00:17:00.730 --> 00:17:05.377
So you would need special unpackers too.
00:17:05.377 --> 00:17:12.243
One challenge that awaits us is, maybe
the updaters contain compressed images.
00:17:12.243 --> 00:17:20.714
They are normally unpacked before the image
is written to the device, so we can just watch
00:17:20.714 --> 00:17:27.245
the process memory with a debugger and dump it.
00:17:27.245 --> 00:17:34.205
What's a bit more challenging is when the
firmware is sent compressed to the device.
00:17:34.205 --> 00:17:40.827
So we have to use invasive techniques
we will talk about later.
00:17:40.827 --> 00:17:47.752
It's a good idea to get a sniffer ready
when you first connect your device to your PC.
00:17:47.752 --> 00:17:56.230
Maybe the favourite bloatware coming with
the device wants to update it instantly.
00:17:56.230 --> 00:18:04.257
What can you do to sniff the transfers?
On Windows XP and I'm sorry it's only XP,
00:18:04.257 --> 00:18:14.313
there's TraceSPTI, a fantastic tool tracing SPTI
SCSI PassThrough Interface.
00:18:14.313 --> 00:18:22.573
So you might think SCSI? I do not have any SCSI
devices, but very much communication is done using
00:18:22.573 --> 00:18:33.240
this protocol on Windows. to identify S/ATA
USB devices, especially if they are ATAPI.
00:18:33.240 --> 00:18:39.042
On the linux side you might use Wireshark
to trace the communication, because Wireshark
00:18:39.042 --> 00:18:47.308
on linux can trace and sniff USB. There are
various other tools like Bushound and so on
00:18:47.308 --> 00:18:54.752
to watch communication on buses. But the
problem is they are normally very expensive.
00:18:54.752 --> 00:19:00.767
A problem you'll have if you're trying to sniff
the update transfer and reconstruct the image is
00:19:00.767 --> 00:19:13.610
that it's like a puzzle. You don't know how to
build the image, and if you're doing it right or not.
00:19:13.610 --> 00:19:20.643
If we do not have a firmware yet,
it might get invasive now.
00:19:20.643 --> 00:19:26.891
We'll search for serial interfaces, sometimes
they are accesible without opening the device,
00:19:26.891 --> 00:19:33.542
sometimes not. Do we have an embedded linux
system? Yes, we can search for a serial console.
00:19:33.542 --> 00:19:42.221
Maybe we have to use JTAG, there was a very
good talk on 27C3 about JTAG, serial flash and so on,
00:19:42.221 --> 00:19:47.511
so I've included a link here.
00:19:47.511 --> 00:19:53.195
So, still no firmware? Get your screwdriver,
let's void warranties.
00:19:53.195 --> 00:19:58.555
We open the device and we search for
memory devices on the PCB.
00:19:58.555 --> 00:20:07.385
If you have a very old device, maybe you'll
encounter EPROMS or even PROMS, 27-somethings
00:20:07.385 --> 00:20:15.233
If it's a little bit newer, you might see EEPROMS
and flash. 28, 29, 39, 49 something and
00:20:15.233 --> 00:20:25.947
and the big flash devices with 48-pins for
example with various other names.
00:20:25.947 --> 00:20:35.507
Very nice to see is that serial flashes,
those 8-pin devices 25..., sometimes 24...
00:20:35.507 --> 00:20:42.989
are more and more becoming the standard.
They are easy to de-solder, easy to re-solder
00:20:42.989 --> 00:20:51.679
and there are very cheap readers and programmers
available. But please, even if some say we can
00:20:51.679 --> 00:21:02.327
do it in system without desoldering the chip,
please don't do it. It can lead to very big problems.
00:21:02.327 --> 00:21:07.632
To make it a little bit harder, firmware can be
contained in chip-internal memories.
00:21:07.632 --> 00:21:17.143
You can try to use proprietary programming
interfaces to read the firmware, of course JTAG.
00:21:17.143 --> 00:21:24.389
Some devices do have bootloaders in a mask ROM.
You can try to use them.
00:21:24.389 --> 00:21:29.623
If none of these approaches succeed,
you can try microprobing.
00:21:29.623 --> 00:21:38.320
There was a talk on last years congress
about low-cost chip microprobing, I've
00:21:38.320 --> 00:21:46.960
included a link here. So just for matter of
completeness I've mentioned CPLDs and FPGAs.
00:21:46.960 --> 00:21:53.855
You know CPLDs are built up using internal EEPROMs.
00:21:53.855 --> 00:22:04.111
FPGAs, Field Programmable Gate Arrays have internal
SRAM and an external serial configuration flash.
00:22:04.111 --> 00:22:12.411
Some years ago they were marketed as being
reverse-engineer proof, okay. Yeah, maybe.
00:22:12.411 --> 00:22:22.960
There's a talk tomorrow, same time I think, in
Saal 2, about taking a closer look at FPGAs.
00:22:22.960 --> 00:22:29.130
Yeah, congratulations, we've done it,
we have our firmware, perfect.
00:22:29.130 --> 00:22:33.658
So what's next, now we have to analyze it.
00:22:33.658 --> 00:22:40.302
The problem is what processor is used.
We don't know which disassembler to use.
00:22:40.302 --> 00:22:45.530
So we are searching the web for any
datasheets, can we get any information.
00:22:45.530 --> 00:22:57.622
Can we find out what processor is in use? The
problem is in many cases you won't get the datasheets.
00:22:57.622 --> 00:23:08.378
The manufacturer says, you buy 1 million devices
a year, and you sign an NDA, you get the datasheets.
00:23:08.378 --> 00:23:16.716
Now you have to be really patient, now it gets
to trial and error, trying different disassemblers.
00:23:16.716 --> 00:23:24.297
You can use specific disassemblers, they
are only built for one architecture.
00:23:24.297 --> 00:23:29.756
You can use a very good tool, the Interactive Disassembler, IDA. There's a freeware version.
00:23:29.756 --> 00:23:37.902
I've included a link in the link section of this talk,
but the freeware only has a little set of architectures.
00:23:37.902 --> 00:23:46.423
If you want the full set, it gets very expensive.
But there is a new tool that I really like.
00:23:46.423 --> 00:23:55.050
It's ODA, the Online Disassembler, supporting
thirty something architectures, and it's free.
00:23:55.050 --> 00:24:01.477
You can upload binary files, you can
upload code, and try different architectures,
00:24:01.477 --> 00:24:07.504
and find out what might be the correct one,
and we'll do that now.
00:24:07.504 --> 00:24:12.350
So I've prepared some binary code.
00:24:12.350 --> 00:24:17.521
I know which architecture this has been
written for, because I did it.
00:24:17.521 --> 00:24:24.537
I put this code to Online Disassembler,
and I chose different architectures,
00:24:24.537 --> 00:24:28.283
and now lets look at what
the disassembly looks like.
00:24:28.283 --> 00:24:36.501
Let's first start with former Hitachi, now
Renesas, H8S. I hope you can read it.
00:24:36.501 --> 00:24:41.538
Take some time and please raise your hand
if you think this is valid disassembly and
00:24:41.538 --> 00:24:48.299
we have found our architecture.
00:24:48.299 --> 00:24:53.334
I see one hand.
00:24:53.334 --> 00:24:59.589
Okay, I have to disappoint you, I'm sorry, it's not valid disassembly, we can see it in the second line.
00:24:59.589 --> 00:25:06.223
The disassembler was not able to disassemble
the data and it's just an undefined instruction.
00:25:06.223 --> 00:25:12.875
There are several .word's in the code. It's not H8S.
00:25:12.875 --> 00:25:22.251
Let's try MIPS. Again take some time and raise
your hand if you think that's valid.
00:25:22.251 --> 00:25:27.206
laughter again?
00:25:27.206 --> 00:25:39.480
It's invalid too. We can see it in the second line,
because there's a dword that's not disassembled.
00:25:39.480 --> 00:25:50.690
What about Panasonic MN103 family?
The same hand again? Oh I see another hand.
00:25:50.690 --> 00:25:57.127
Ok, several hands now. Yeah, OK, thank you.
00:25:57.127 --> 00:26:01.220
So the problem is, it's not valid.
I have to disappoint you.
00:26:01.220 --> 00:26:06.786
The problem is in this case, it looks really good
and you have to dig deeper.
00:26:06.786 --> 00:26:14.020
You will have to look at, are all subroutines
correct. Do they make sense?
00:26:14.020 --> 00:26:17.270
Are there subroutine calls at all and so on.
00:26:17.270 --> 00:26:23.144
And you will see something strange. Ok last try.
00:26:23.144 --> 00:26:28.533
What about Texas Instruments MSP430?
00:26:28.533 --> 00:26:33.258
And again, please raise your hands.
00:26:33.258 --> 00:26:40.895
Okay? Yeah, this time it is MSP430!
00:26:40.895 --> 00:26:48.172
We have found our architecture, perfect,
eureka, bingo, we have it.
00:26:48.172 --> 00:26:56.770
But what's next? The offset in the file,
of the firmware file we loaded is often
00:26:56.770 --> 00:27:04.850
not the offset in address space. This is no
real problem when the architecture is
00:27:04.850 --> 00:27:12.030
using relative adressing. Relative adressing
means we have register content and whatever
00:27:12.030 --> 00:27:20.130
we want to access is based on some
registers content. Location independent code.
00:27:20.130 --> 00:27:27.468
But we have a big problem when absolute
adressing is being used, and even architectures
00:27:27.468 --> 00:27:36.617
supporting relative adressing do have some
absolute adressing, somewhere on some accesses.
00:27:36.617 --> 00:27:40.893
We would not know, where's the entry point.
Where should we start?
00:27:40.893 --> 00:27:47.551
Interrupt vectors might be decoded completely
wrong, subroutine calls do not make any sense.
00:27:47.551 --> 00:27:54.376
They go to [addresses] outside of our firmware
for example, or in the middle of instructions.
00:27:54.376 --> 00:28:01.227
So the load offset has to be found.
00:28:01.227 --> 00:28:08.909
I'll now show a method I call "call distance search".
00:28:08.909 --> 00:28:15.572
We will select closely located subroutine adresses
and we'll have to decide either to use
00:28:15.572 --> 00:28:21.959
preceding return instructions in front of
the subroutines, or the start of the function
00:28:21.959 --> 00:28:31.319
entry sequence. We build a search string
containing wildcards, and then we search.
00:28:31.319 --> 00:28:36.284
Now we'll do that together, I've prepared an example.
00:28:36.284 --> 00:28:45.771
This is 8051 code. The 8051 core is very old, it's
an 8-bit controller, but it's still widely used in the field
00:28:45.771 --> 00:28:53.654
because it's cheap as dirt and you can
implement it wherever you want.
00:28:53.654 --> 00:29:01.725
In the left column we see the addresses
of our example, from 0x00 to 0x13 hex.
00:29:01.725 --> 00:29:13.430
We see four subroutines, with the first being the root
subroutine, calling the other three subroutines.
00:29:13.430 --> 00:29:23.443
We can see the first call to 0x100 is outside our
example, we do not have 0x100 in this example.
00:29:23.443 --> 00:29:30.472
So what we do is take the three subroutine
adresses and sort them.
00:29:30.472 --> 00:29:40.678
So we're getting 0x100, 0x103, and 0x107. We calculate
the difference to figure out the length of the subroutines.
00:29:40.678 --> 00:29:53.443
We get 3 bytes and 4 bytes. Now we look at how
subroutines are built in this specific architecture.
00:29:53.443 --> 00:30:01.818
On x86 you will mostly find it, not on the 64-bit
platforms, but on the 32-bit and 16-bit platforms,
00:30:01.818 --> 00:30:11.500
You will find a stack-frame entry sequence in
every function, like push bp or push ebp 0x55
00:30:11.500 --> 00:30:15.229
So you can trigger on that one.
00:30:15.229 --> 00:30:24.548
On 8051 it's not possible. Take a look at address 0x0A It's 0xE0.
00:30:24.548 --> 00:30:28.530
Take a look at address 0x0D , it's 44, and 0x11 is 7B.
00:30:28.530 --> 00:30:32.108
The are not equal, it does not help us.
00:30:32.108 --> 00:30:39.690
So we look at the preceding returns
and yes there are returns in front
00:30:39.690 --> 00:30:45.483
of every subroutine.
So we take the 0x22 [ret] as our anchor.
00:30:45.483 --> 00:30:51.259
Our search string will look like this;
We start with the 0x22, we have a
00:30:51.259 --> 00:30:56.823
subroutine with a length of 3 bytes,
so we have 0x22 [ret], two wildcards and
00:30:56.823 --> 00:31:04.483
again a return. The second part of the
search string encodes the second
00:31:04.483 --> 00:31:13.244
subroutine with 4 bytes. So we have wildcard,
wildcard, wildcard and again a return [0x22]
00:31:13.244 --> 00:31:22.383
In this simple example we get only one hit,
perfect. We get a hit at address 0x09.
00:31:22.383 --> 00:31:27.888
But we do not want the address of the
return, we want the address of the subroutine,
00:31:27.888 --> 00:31:33.447
so we are not using the 0x09, we are using the 0x0A.
00:31:33.447 --> 00:31:40.662
What we do is we take the original destination
address 0x0100, we subtract 0x0A
00:31:40.662 --> 00:31:49.411
and we get the base address of our
code example, which is 0xF6
00:31:49.411 --> 00:31:58.392
If we apply this newly found out load
offset to the code and we adjust the offset
00:31:58.392 --> 00:32:06.430
starting now at 0x00F6 in the left column
we see that all three subroutines now match.
00:32:06.430 --> 00:32:14.706
The call to 0x0100, the call to 0x0107
and the call to 0x0103.
00:32:14.706 --> 00:32:22.706
Ok, I think this was hard, so let's
repeat what we have already done.
00:32:22.706 --> 00:32:30.647
So we have obtained our image, we have
successfully found the processor architecture,
00:32:30.647 --> 00:32:35.143
we have found a disassembler
to disassemble the firmware,
00:32:35.143 --> 00:32:43.746
and we have hopefully found the
original load offset. So what's next
00:32:43.746 --> 00:32:49.358
Maybe the question arises, is there
additional firmware in this device?
00:32:49.358 --> 00:32:56.254
I see jumps and calls outside of firmware
we already know, although we have adjusted
00:32:56.254 --> 00:33:02.446
the load offset. Is it chip internal?
We can see it on the figure, maybe
00:33:02.446 --> 00:33:10.387
we have only firmware part A. And maybe
it's using a library or chip internal part B.
00:33:10.387 --> 00:33:18.900
So we will have to see what we can do
using a modification of the firmware.
00:33:18.900 --> 00:33:26.843
Now having done that, we can start
with normal reverse engineering of the code.
00:33:26.843 --> 00:33:31.537
We search for strings, we search
for references to the strings,
00:33:31.537 --> 00:33:39.353
but as we are in a very low end embedded
system, maybe we can search for very specialized,
00:33:39.353 --> 00:33:48.580
data references and operands. Search for USB
descriptor fields, you have extracted with /bin/lsusb
00:33:48.580 --> 00:33:55.228
Take a look for USB magics like USBC and USBS,
you know these two dwords are used in
00:33:55.228 --> 00:34:03.727
usb communications. Take a look for IDE,
SATA and ATAPI ID strings, saying
00:34:03.727 --> 00:34:15.761
"I'm a OCZ SSD device" for instance. When
you've sniffed the device communication
00:34:15.761 --> 00:34:21.920
you've already found some typical datablocks.
You can try to find them [in the binary]
00:34:21.920 --> 00:34:28.145
Last, but not least, maybe the device provides some error codes, and you can search for strings,
00:34:28.145 --> 00:34:33.887
or for operands in the opcodes.
00:34:33.887 --> 00:34:38.954
It's very interesting to find hidden
firmware update sequences, because
00:34:38.954 --> 00:34:47.220
they would allow non-invasive modifications.
For example search for chip erase and
00:34:47.220 --> 00:34:51.870
programming commands, you can take the
appropriate commands from the datasheet
00:34:51.870 --> 00:35:01.519
if there's any external memory device available.
We've done it, we have analysed it and we've
00:35:01.519 --> 00:35:07.917
learnt a lot about the device.
Now we are going to modify it.
00:35:07.917 --> 00:35:14.320
First, we have to think about, If we are
going to modify the firmware, we have
00:35:14.320 --> 00:35:19.687
to prepare to brick our device.
00:35:19.687 --> 00:35:25.042
Manufacturers implement several integrity
checks, and why do they do that?
00:35:25.042 --> 00:35:34.766
They do it because firmware is stored to flash,
which is prone to aging, especially if heat is involved.
00:35:34.766 --> 00:35:42.409
So they do checksums. There are softwarebased
checksum calculations, CRC for example.
00:35:42.409 --> 00:35:48.537
There are even hardwarebased checksums
where some HW peripheral will do the job for us.
00:35:48.537 --> 00:35:57.179
So what you see in the code is maybe the start
offset, the end offset, and if you're lucky the polynomial.
00:35:57.179 --> 00:36:03.656
It might be hardcoded in the peripheral too,
so you won't see anything.
00:36:03.656 --> 00:36:13.168
It can be a combination of both, being done
only on startup or cyclically in the background.
00:36:13.168 --> 00:36:18.739
What we have to do to modify the firmware
is either correct those checksums,
00:36:18.739 --> 00:36:26.140
or we have to patch those checksum
algorithms not to trigger.
00:36:26.140 --> 00:36:32.309
What are the goals of our modification, of
course we heard it in our motivation section.
00:36:32.309 --> 00:36:44.751
We are about to correct errors, and maybe the errors
are contained in another part of firmware we are not
00:36:44.751 --> 00:36:51.369
having right now. Maybe we have to dump
additional memory regions.
00:36:51.369 --> 00:37:02.249
That's what they did in the Cisco VoIP hack.
They tried to find a memcpy routine and use it.
00:37:02.249 --> 00:37:08.551
If you don't find a memcpy routine maybe
you can implement your own. Why not?
00:37:08.551 --> 00:37:15.892
You could dump code from other memory
regions to output buffers.
00:37:15.892 --> 00:37:20.427
If you have space in an external memory
device, why not program it to the device
00:37:20.427 --> 00:37:29.918
and read it from the device. It can be very
interesting to gather more device internal information.
00:37:29.918 --> 00:37:36.561
For example doing a RAM dump, because
during static analysis, you always wonder
00:37:36.561 --> 00:37:48.435
what may be in RAM at this and that address.
Now as we have modified the firmware,
00:37:48.435 --> 00:37:53.960
we can inject it back to the device. For
example using the original updater.
00:37:53.960 --> 00:37:58.437
It might contain the next checksum check, who knows.
00:37:58.437 --> 00:38:06.598
We can try to re-program it to the external
memory device if available, or to the processor.
00:38:06.598 --> 00:38:14.163
This might be done using a serial interface,
either JTAG or proprietary.
00:38:14.163 --> 00:38:17.967
That's it. Thank you very much.
00:38:17.967 --> 00:38:25.766
applause
00:38:25.766 --> 00:38:36.093
Angel: If you have any questions, please line up
at the room microphones, there are four here.
00:38:42.573 --> 00:38:47.125
Are there any questions? Microphone 1 please;
00:38:47.125 --> 00:38:54.427
Question: Not a question, but a tip. If you need some binary dump or some left over files on windows,
00:38:54.427 --> 00:39:06.456
you can deny the delete right, so the install
or updater program is unable to delete its tempfiles.
00:39:06.456 --> 00:39:08.858
So they are left over after reprogramming the device.
00:39:08.858 --> 00:39:10.733
A: Do you have tip what to use in that case?
00:39:10.733 --> 00:39:11.723
Q: Sorry?
00:39:11.723 --> 00:39:14.262
A: Do you have a tip, is there a special tool?
00:39:14.262 --> 00:39:18.902
Q: It's not necessary, windows has
the function already built in.
00:39:18.902 --> 00:39:20.422
A: OK.
00:39:20.422 --> 00:39:26.622
Q:And I don't know the word.
00:39:26.622 --> 00:39:27.506
A: OK
00:39:27.506 --> 00:39:34.288
Q: But you are able to revoke rights completely
from a directory, there's a special right for deleting.
00:39:34.288 --> 00:39:37.407
A: OK, thank you.
00:39:37.407 --> 00:39:42.603
Angel: Are there any more questions?
00:39:46.603 --> 00:39:50.631
Angel: Doesn't look like it, please give a warm
round of applause to our speaker Stephan Widmann.
00:39:50.631 --> 00:39:54.821
applause
A: On [microphone 2]
00:39:54.821 --> 00:39:57.465
Angel: There is one more question... No?
00:39:57.465 --> 00:39:59.546
A: OK
00:39:59.546 --> 00:40:02.878
Angel: If you're leaving please do take your...
00:40:02.878 --> 00:40:11.092
subtitles created by c3subtitles.de