< Return to Video

An introduction to Firmware Analysis

  • 0:10 - 0:12
    So, I have already been introduced
  • 0:12 - 0:14
    My name is Stefan Widmann
  • 0:14 - 0:18
    and maybe I can have my slides?
  • 0:26 - 0:29
    Hello, my slides?
  • 0:34 - 0:40
    laughter
  • 0:40 - 0:42
    Ich bin am VGA drauf.
  • 0:48 - 0:50
    [hums]
  • 0:52 - 0:54
    Yeah, um...
  • 0:58 - 1:00
    [mumbling]
  • 1:11 - 1:17
    Okay, so while we're waiting until
    my slides appear somehow.
  • 1:17 - 1:19
    Who has seen the incredible talk about
  • 1:19 - 1:22
    hacking the VoIP phones from Cisco, last year
  • 1:22 - 1:26
    either live or on video?
  • 1:26 - 1:28
    Okay some of you.
  • 1:28 - 1:31
    When we think about this talk
  • 1:31 - 1:35
    The Cisco VoIP phones have an embeddd
  • 1:35 - 1:38
    Linux operating system, but they did not only
  • 1:38 - 1:42
    have to deal with the linux OS, but also with
  • 1:42 - 1:44
    the firmware of the DSP.
  • 1:44 - 1:51
    So I want to tell you there's
    not only one system,
  • 1:51 - 2:03
    but several systems. Several
    sub-systems containing firmware
  • 2:03 - 2:07
    Slides would be nice, we can start
    without slides, there's no problem.
  • 2:07 - 2:10
    So what are we going to talk about today?
  • 2:10 - 2:15
    First we are going to talk about motivation,
    why should we do firmware analysis.
  • 2:15 - 2:26
    Then we need to be able to do it, so we
    have some prerequisites to bring with us.
  • 2:26 - 2:34
    Then we'll dig deep into the topics, We will
    try to look at how we obtain a firmware,
  • 2:34 - 2:41
    how can we analyze it, and how can we modify it.
  • 2:41 - 2:54
    Hmm. Angel: We are sorry for the brief hiccup, we're
    working on that. It's the second talk. I'm sorry.
  • 2:54 - 2:58
    [speaks german]
  • 3:33 - 3:35
    Hmm
  • 3:38 - 3:43
    Okay, so we can do without slides, it's okay.
  • 3:43 - 3:49
    Let's start with the motivation, why do we
    want to do firmware analysis.
  • 3:49 - 3:58
    When talking to my lawyer I learned that I
    had to clean up 90% of my motivation slide.
  • 3:58 - 4:07
    And left is, you can do it if you
    want to gain interoperability.
  • 4:07 - 4:10
    laughter
  • 4:10 - 4:15
    You can do it if you want to get rid
    of errors, and the manufacturer
  • 4:15 - 4:22
    does not want to or is unable.
    And one interesting point under
  • 4:22 - 4:29
    discussion is, what about forensics,
    taking a look in those thousands of devices
  • 4:29 - 4:36
    in everyday life. Do they only do
    what they are supposed to do?
  • 4:43 - 4:48
    Herald: Yes, we are still hunting for a Video
    Angel to sort this little problem out. We should
  • 4:48 - 4:54
    have one here within 1 minute.
    Again, very sorry.
  • 5:06 - 5:12
    We now have Nick Farr on stage,
    our certified Powerpoint specialist.
  • 5:12 - 5:17
    applause
  • 5:17 - 5:20
    It can only take minutes now.
  • 6:06 - 6:11
    Maybe we can continue. So I will just tell
    you something about prerequisites you
  • 6:11 - 6:19
    should bring when starting to analyse
    You should at least have a good knowledge
  • 6:19 - 6:26
    of embedded system architecture.
    You should have dealt with peripherals,
  • 6:26 - 6:32
    bus interfaces and so on.
    You should be able to read
  • 6:32 - 6:35
    and write assembler.
    Some might say:
  • 6:35 - 6:39
    I have a very good decompiler,
    which is fine.
  • 6:39 - 6:46
    If it works for you, okay, but don't
    rely on the availability of a decompiler
  • 6:46 - 6:49
    for the architecture you're going to be working on
  • 6:49 - 6:56
    Especially if you are going to work
    low down in the register stuff.
  • 6:56 - 7:04
    And in my opinion, a decompiler output
    will confuse you more than help you.
  • 7:04 - 7:13
    You will go to disassemble maybe, C runtime
    libraries, optimized to be as small as possible
  • 7:13 - 7:18
    That can be really hard in decompiler output.
  • 7:18 - 7:29
    If you want to practice how embedded systems
    are working, then it might be a good idea to fetch
  • 7:29 - 7:36
    your arduino or whatever. You write some
    little C code, handling some hardware stuff.
  • 7:36 - 7:45
    Then you just compile it and take a look,
    what the disassembly looks like.
  • 7:45 - 7:56
    Very nice to have is a device reader or programmer,
    like galib. The problem is they are expensive.
  • 7:56 - 8:04
    If you think we are going to do firmware analysis, it
    may be a valuable investment for your hackerspace.
  • 8:04 - 8:09
    And last but not least, what you need most is time.
  • 8:09 - 8:17
    Time, time, time. It may take hours, days
    without any progress, so please be patient.
  • 8:21 - 8:27
    laughter
  • 8:30 - 8:36
    Any volunteers to make up some slides here?
  • 8:44 - 8:51
    I swear, it worked perfectly okay with
    my external monitor.
  • 8:51 - 9:04
    Yes? [illegible]
  • 9:04 - 9:08
    So I'll have to fetch my USB stick, wait a moment.
  • 9:08 - 9:53
    No problem, we're flexible.
    [whistling]
  • 10:10 - 10:15
    So is there anyone who knows their
    way around a computer around here?
  • 10:15 - 10:20
    Herald: While we figure that out, it might
    be a good possibility to remind you all
  • 10:20 - 10:28
    that we are still looking for some Angels.
    You could do video angels, which are in
  • 10:28 - 10:33
    high demand right now. Or you could just
    do any other work you'd like to.
  • 10:33 - 10:38
    You can do one or two shifts, that's fine.
    It would be greatly appreciated
  • 10:38 - 10:49
    because we require volunteer work for this event.
    Also if you brought any beverages in here,
  • 10:49 - 10:54
    it'd be awesome if you could take them out
    with you. And put them into the little
  • 10:54 - 11:02
    storage cases located all around the building.
    Trust me when we are finished,
  • 11:02 - 11:11
    you'll be able to do this announcement.
    Are we good? No, not really.
  • 11:11 - 11:13
    laughter
  • 11:13 - 11:16
    It looks good on the laptop.
  • 11:16 - 11:19
    You want to give a quick intro
    to the new Ubuntu desktop?
  • 11:19 - 11:28
    Because I did not get that at all.
  • 11:28 - 11:33
    Yeah, mirror displays man.
  • 11:33 - 11:40
    4 zur 3 folien.
  • 11:40 - 11:42
    Now we are making progress
  • 11:42 - 11:46
    applause
  • 11:46 - 11:48
    Enjoy the talk!
  • 11:48 - 11:52
    Okay, perfect, now with slides.
  • 11:52 - 11:57
    One small announcement, there will be
    5 more minutes of extra talk at the end.
  • 11:57 - 12:04
    We'll do that. So just please ignore the yellow bars.
  • 12:04 - 12:08
    laughter
  • 12:08 - 12:18
    Not really no.
  • 12:18 - 12:26
    High level devices. Big complexity. YES!
  • 12:29 - 12:31
    Perfect, thank you, without yellow bars, thank you.
  • 12:31 - 12:42
    Okay. So we already talked about prerequisites,
    so now we're going deep into the topics.
  • 12:42 - 12:50
    First we need to obtain a firmware. We
    will go from non-invasive to invasive.
  • 12:50 - 12:58
    Because first thing we want to try is getting
    the firmware without opening the device.
  • 12:58 - 13:03
    We will first try to download a plain binary
    from the manufacturer.
  • 13:03 - 13:12
    or maybe someone else have extracted
    a binary and placed it on the internet.
  • 13:12 - 13:19
    You can try to download a bootdisk, USB,
    CD-ROM, bootimage, whatever the manuf. provides.
  • 13:19 - 13:26
    and extract it using, for example, WinRAR
    on windows or just mount it on linux.
  • 13:26 - 13:35
    Search for files named .bin, .hex, .s19, .mot.
    like motorola, .rom or .raw.
  • 13:35 - 13:42
    Most times binary, that means .bin, .rom or
    .raw files are already real binary files.
  • 13:42 - 13:51
    Non-binary files should be converted to
    bin files, e.g with converters like hex2bin.
  • 13:51 - 13:56
    If this doesn't work out, maybe we get
    an updater from the manufacturer
  • 13:56 - 14:00
    Normally they're .exe files built for windows.
  • 14:00 - 14:07
    There are different updater types.
    First the self-extracting archives.
  • 14:07 - 14:12
    It might be an installer too,
    like Installshield or whatever.
  • 14:12 - 14:19
    It might be an updater, simple .exe file
    without any installation, just containing the image.
  • 14:19 - 14:25
    It might be an updater that is downloading
    an image, or it might be some of the others,
  • 14:25 - 14:32
    but packed with an executable packer
    like UPX or PECompact.
  • 14:32 - 14:33
    Let's go a little bit into detail.
  • 14:33 - 14:43
    So if it's a self-extracting archive search
    for signatures like RARSFX or PK.
  • 14:43 - 14:53
    You can unpack them, e.g. if you rename
    a PK containg file to .zip you can unzip it.
  • 14:53 - 14:59
    If it is an installer, like Installshield, there are
    special unpackers, but the problem is they are
  • 14:59 - 15:06
    very hard to use and extremely version specific.
    It might work, it might not.
  • 15:06 - 15:11
    The best way is to just let it install
    and search in the installed files
  • 15:11 - 15:20
    for a plain image or updater. If it's an
    updater containing the firmware image,
  • 15:20 - 15:26
    we can search for the image in the executable
    using your favorite hex-editor.
  • 15:26 - 15:34
    Maybe the updater is writing the data to a file, a temporary file in most cases, and deleting
  • 15:34 - 15:41
    it after usage. You can use ProcessMonitor
    which is like strace but on Windows
  • 15:41 - 15:46
    and you can take a look at what files
    are written to disk can try to capture it
  • 15:46 - 15:52
    before it's deleted. Maybe the updater is
    just checking your device, so its just
  • 15:52 - 15:57
    a little downloader. Checking your device
    type, take a look on the ftp-site of the
  • 15:57 - 16:03
    manufacturer and is downloading an
    image if there's one available.
  • 16:03 - 16:09
    So if it's downloading the image to a
    file, use ProcessMonitor again.
  • 16:09 - 16:19
    If it's just downloading to RAM, you have
    to go for a debugger, and dump it from memory.
  • 16:19 - 16:27
    If you have a packed updater, which
    of course is only done to save size.
  • 16:27 - 16:37
    If it's standard UPX, you can download UPX
    and use UPX -d to unpack it.
  • 16:37 - 16:44
    Sometimes the manufacturer violate the
    license of UPX and modify UPX by removing
  • 16:44 - 16:52
    vital file information to make it un-depackable.
    So you would need a special unpacker.
  • 16:52 - 17:01
    Other executable packers are most times
    designed not to be uncompressed.
  • 17:01 - 17:05
    So you would need special unpackers too.
  • 17:05 - 17:12
    One challenge that awaits us is, maybe
    the updaters contain compressed images.
  • 17:12 - 17:21
    They are normally unpacked before the image
    is written to the device, so we can just watch
  • 17:21 - 17:27
    the process memory with a debugger and dump it.
  • 17:27 - 17:34
    What's a bit more challenging is when the
    firmware is sent compressed to the device.
  • 17:34 - 17:41
    So we have to use invasive techniques
    we will talk about later.
  • 17:41 - 17:48
    It's a good idea to get a sniffer ready
    when you first connect your device to your PC.
  • 17:48 - 17:56
    Maybe the favourite bloatware coming with
    the device wants to update it instantly.
  • 17:56 - 18:04
    What can you do to sniff the transfers?
    On Windows XP and I'm sorry it's only XP,
  • 18:04 - 18:14
    there's TraceSPTI, a fantastic tool tracing SPTI
    SCSI PassThrough Interface.
  • 18:14 - 18:23
    So you might think SCSI? I do not have any SCSI
    devices, but very much communication is done using
  • 18:23 - 18:33
    this protocol on Windows. to identify S/ATA
    USB devices, especially if they are ATAPI.
  • 18:33 - 18:39
    On the linux side you might use Wireshark
    to trace the communication, because Wireshark
  • 18:39 - 18:47
    on linux can trace and sniff USB. There are
    various other tools like Bushound and so on
  • 18:47 - 18:55
    to watch communication on buses. But the
    problem is they are normally very expensive.
  • 18:55 - 19:01
    A problem you'll have if you're trying to sniff
    the update transfer and reconstruct the image is
  • 19:01 - 19:14
    that it's like a puzzle. You don't know how to
    build the image, and if you're doing it right or not.
  • 19:14 - 19:21
    If we do not have a firmware yet,
    it might get invasive now.
  • 19:21 - 19:27
    We'll search for serial interfaces, sometimes
    they are accesible without opening the device,
  • 19:27 - 19:34
    sometimes not. Do we have an embedded linux
    system? Yes, we can search for a serial console.
  • 19:34 - 19:42
    Maybe we have to use JTAG, there was a very
    good talk on 27C3 about JTAG, serial flash and so on,
  • 19:42 - 19:48
    so I've included a link here.
  • 19:48 - 19:53
    So, still no firmware? Get your screwdriver,
    let's void warranties.
  • 19:53 - 19:59
    We open the device and we search for
    memory devices on the PCB.
  • 19:59 - 20:07
    If you have a very old device, maybe you'll
    encounter EPROMS or even PROMS, 27-somethings
  • 20:07 - 20:15
    If it's a little bit newer, you might see EEPROMS
    and flash. 28, 29, 39, 49 something and
  • 20:15 - 20:26
    and the big flash devices with 48-pins for
    example with various other names.
  • 20:26 - 20:36
    Very nice to see is that serial flashes,
    those 8-pin devices 25..., sometimes 24...
  • 20:36 - 20:43
    are more and more becoming the standard.
    They are easy to de-solder, easy to re-solder
  • 20:43 - 20:52
    and there are very cheap readers and programmers
    available. But please, even if some say we can
  • 20:52 - 21:02
    do it in system without desoldering the chip,
    please don't do it. It can lead to very big problems.
  • 21:02 - 21:08
    To make it a little bit harder, firmware can be
    contained in chip-internal memories.
  • 21:08 - 21:17
    You can try to use proprietary programming
    interfaces to read the firmware, of course JTAG.
  • 21:17 - 21:24
    Some devices do have bootloaders in a mask ROM.
    You can try to use them.
  • 21:24 - 21:30
    If none of these approaches succeed,
    you can try microprobing.
  • 21:30 - 21:38
    There was a talk on last years congress
    about low-cost chip microprobing, I've
  • 21:38 - 21:47
    included a link here. So just for matter of
    completeness I've mentioned CPLDs and FPGAs.
  • 21:47 - 21:54
    You know CPLDs are built up using internal EEPROMs.
  • 21:54 - 22:04
    FPGAs, Field Programmable Gate Arrays have internal
    SRAM and an external serial configuration flash.
  • 22:04 - 22:12
    Some years ago they were marketed as being
    reverse-engineer proof, okay. Yeah, maybe.
  • 22:12 - 22:23
    There's a talk tomorrow, same time I think, in
    Saal 2, about taking a closer look at FPGAs.
  • 22:23 - 22:29
    Yeah, congratulations, we've done it,
    we have our firmware, perfect.
  • 22:29 - 22:34
    So what's next, now we have to analyze it.
  • 22:34 - 22:40
    The problem is what processor is used.
    We don't know which disassembler to use.
  • 22:40 - 22:46
    So we are searching the web for any
    datasheets, can we get any information.
  • 22:46 - 22:58
    Can we find out what processor is in use? The
    problem is in many cases you won't get the datasheets.
  • 22:58 - 23:08
    The manufacturer says, you buy 1 million devices
    a year, and you sign an NDA, you get the datasheets.
  • 23:08 - 23:17
    Now you have to be really patient, now it gets
    to trial and error, trying different disassemblers.
  • 23:17 - 23:24
    You can use specific disassemblers, they
    are only built for one architecture.
  • 23:24 - 23:30
    You can use a very good tool, the Interactive Disassembler, IDA. There's a freeware version.
  • 23:30 - 23:38
    I've included a link in the link section of this talk,
    but the freeware only has a little set of architectures.
  • 23:38 - 23:46
    If you want the full set, it gets very expensive.
    But there is a new tool that I really like.
  • 23:46 - 23:55
    It's ODA, the Online Disassembler, supporting
    thirty something architectures, and it's free.
  • 23:55 - 24:01
    You can upload binary files, you can
    upload code, and try different architectures,
  • 24:01 - 24:08
    and find out what might be the correct one,
    and we'll do that now.
  • 24:08 - 24:12
    So I've prepared some binary code.
  • 24:12 - 24:18
    I know which architecture this has been
    written for, because I did it.
  • 24:18 - 24:25
    I put this code to Online Disassembler,
    and I chose different architectures,
  • 24:25 - 24:28
    and now lets look at what
    the disassembly looks like.
  • 24:28 - 24:37
    Let's first start with former Hitachi, now
    Renesas, H8S. I hope you can read it.
  • 24:37 - 24:42
    Take some time and please raise your hand
    if you think this is valid disassembly and
  • 24:42 - 24:48
    we have found our architecture.
  • 24:48 - 24:53
    I see one hand.
  • 24:53 - 25:00
    Okay, I have to disappoint you, I'm sorry, it's not valid disassembly, we can see it in the second line.
  • 25:00 - 25:06
    The disassembler was not able to disassemble
    the data and it's just an undefined instruction.
  • 25:06 - 25:13
    There are several .word's in the code. It's not H8S.
  • 25:13 - 25:22
    Let's try MIPS. Again take some time and raise
    your hand if you think that's valid.
  • 25:22 - 25:27
    laughter again?
  • 25:27 - 25:39
    It's invalid too. We can see it in the second line,
    because there's a dword that's not disassembled.
  • 25:39 - 25:51
    What about Panasonic MN103 family?
    The same hand again? Oh I see another hand.
  • 25:51 - 25:57
    Ok, several hands now. Yeah, OK, thank you.
  • 25:57 - 26:01
    So the problem is, it's not valid.
    I have to disappoint you.
  • 26:01 - 26:07
    The problem is in this case, it looks really good
    and you have to dig deeper.
  • 26:07 - 26:14
    You will have to look at, are all subroutines
    correct. Do they make sense?
  • 26:14 - 26:17
    Are there subroutine calls at all and so on.
  • 26:17 - 26:23
    And you will see something strange. Ok last try.
  • 26:23 - 26:29
    What about Texas Instruments MSP430?
  • 26:29 - 26:33
    And again, please raise your hands.
  • 26:33 - 26:41
    Okay? Yeah, this time it is MSP430!
  • 26:41 - 26:48
    We have found our architecture, perfect,
    eureka, bingo, we have it.
  • 26:48 - 26:57
    But what's next? The offset in the file,
    of the firmware file we loaded is often
  • 26:57 - 27:05
    not the offset in address space. This is no
    real problem when the architecture is
  • 27:05 - 27:12
    using relative adressing. Relative adressing
    means we have register content and whatever
  • 27:12 - 27:20
    we want to access is based on some
    registers content. Location independent code.
  • 27:20 - 27:27
    But we have a big problem when absolute
    adressing is being used, and even architectures
  • 27:27 - 27:37
    supporting relative adressing do have some
    absolute adressing, somewhere on some accesses.
  • 27:37 - 27:41
    We would not know, where's the entry point.
    Where should we start?
  • 27:41 - 27:48
    Interrupt vectors might be decoded completely
    wrong, subroutine calls do not make any sense.
  • 27:48 - 27:54
    They go to [addresses] outside of our firmware
    for example, or in the middle of instructions.
  • 27:54 - 28:01
    So the load offset has to be found.
  • 28:01 - 28:09
    I'll now show a method I call "call distance search".
  • 28:09 - 28:16
    We will select closely located subroutine adresses
    and we'll have to decide either to use
  • 28:16 - 28:22
    preceding return instructions in front of
    the subroutines, or the start of the function
  • 28:22 - 28:31
    entry sequence. We build a search string
    containing wildcards, and then we search.
  • 28:31 - 28:36
    Now we'll do that together, I've prepared an example.
  • 28:36 - 28:46
    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
  • 28:46 - 28:54
    because it's cheap as dirt and you can
    implement it wherever you want.
  • 28:54 - 29:02
    In the left column we see the addresses
    of our example, from 0x00 to 0x13 hex.
  • 29:02 - 29:13
    We see four subroutines, with the first being the root
    subroutine, calling the other three subroutines.
  • 29:13 - 29:23
    We can see the first call to 0x100 is outside our
    example, we do not have 0x100 in this example.
  • 29:23 - 29:30
    So what we do is take the three subroutine
    adresses and sort them.
  • 29:30 - 29:41
    So we're getting 0x100, 0x103, and 0x107. We calculate
    the difference to figure out the length of the subroutines.
  • 29:41 - 29:53
    We get 3 bytes and 4 bytes. Now we look at how
    subroutines are built in this specific architecture.
  • 29:53 - 30:02
    On x86 you will mostly find it, not on the 64-bit
    platforms, but on the 32-bit and 16-bit platforms,
  • 30:02 - 30:12
    You will find a stack-frame entry sequence in
    every function, like push bp or push ebp 0x55
  • 30:12 - 30:15
    So you can trigger on that one.
  • 30:15 - 30:25
    On 8051 it's not possible. Take a look at address 0x0A It's 0xE0.
  • 30:25 - 30:29
    Take a look at address 0x0D , it's 44, and 0x11 is 7B.
  • 30:29 - 30:32
    The are not equal, it does not help us.
  • 30:32 - 30:40
    So we look at the preceding returns
    and yes there are returns in front
  • 30:40 - 30:45
    of every subroutine.
    So we take the 0x22 [ret] as our anchor.
  • 30:45 - 30:51
    Our search string will look like this;
    We start with the 0x22, we have a
  • 30:51 - 30:57
    subroutine with a length of 3 bytes,
    so we have 0x22 [ret], two wildcards and
  • 30:57 - 31:04
    again a return. The second part of the
    search string encodes the second
  • 31:04 - 31:13
    subroutine with 4 bytes. So we have wildcard,
    wildcard, wildcard and again a return [0x22]
  • 31:13 - 31:22
    In this simple example we get only one hit,
    perfect. We get a hit at address 0x09.
  • 31:22 - 31:28
    But we do not want the address of the
    return, we want the address of the subroutine,
  • 31:28 - 31:33
    so we are not using the 0x09, we are using the 0x0A.
  • 31:33 - 31:41
    What we do is we take the original destination
    address 0x0100, we subtract 0x0A
  • 31:41 - 31:49
    and we get the base address of our
    code example, which is 0xF6
  • 31:49 - 31:58
    If we apply this newly found out load
    offset to the code and we adjust the offset
  • 31:58 - 32:06
    starting now at 0x00F6 in the left column
    we see that all three subroutines now match.
  • 32:06 - 32:15
    The call to 0x0100, the call to 0x0107
    and the call to 0x0103.
  • 32:15 - 32:23
    Ok, I think this was hard, so let's
    repeat what we have already done.
  • 32:23 - 32:31
    So we have obtained our image, we have
    successfully found the processor architecture,
  • 32:31 - 32:35
    we have found a disassembler
    to disassemble the firmware,
  • 32:35 - 32:44
    and we have hopefully found the
    original load offset. So what's next
  • 32:44 - 32:49
    Maybe the question arises, is there
    additional firmware in this device?
  • 32:49 - 32:56
    I see jumps and calls outside of firmware
    we already know, although we have adjusted
  • 32:56 - 33:02
    the load offset. Is it chip internal?
    We can see it on the figure, maybe
  • 33:02 - 33:10
    we have only firmware part A. And maybe
    it's using a library or chip internal part B.
  • 33:10 - 33:19
    So we will have to see what we can do
    using a modification of the firmware.
  • 33:19 - 33:27
    Now having done that, we can start
    with normal reverse engineering of the code.
  • 33:27 - 33:32
    We search for strings, we search
    for references to the strings,
  • 33:32 - 33:39
    but as we are in a very low end embedded
    system, maybe we can search for very specialized,
  • 33:39 - 33:49
    data references and operands. Search for USB
    descriptor fields, you have extracted with /bin/lsusb
  • 33:49 - 33:55
    Take a look for USB magics like USBC and USBS,
    you know these two dwords are used in
  • 33:55 - 34:04
    usb communications. Take a look for IDE,
    SATA and ATAPI ID strings, saying
  • 34:04 - 34:16
    "I'm a OCZ SSD device" for instance. When
    you've sniffed the device communication
  • 34:16 - 34:22
    you've already found some typical datablocks.
    You can try to find them [in the binary]
  • 34:22 - 34:28
    Last, but not least, maybe the device provides some error codes, and you can search for strings,
  • 34:28 - 34:34
    or for operands in the opcodes.
  • 34:34 - 34:39
    It's very interesting to find hidden
    firmware update sequences, because
  • 34:39 - 34:47
    they would allow non-invasive modifications.
    For example search for chip erase and
  • 34:47 - 34:52
    programming commands, you can take the
    appropriate commands from the datasheet
  • 34:52 - 35:02
    if there's any external memory device available.
    We've done it, we have analysed it and we've
  • 35:02 - 35:08
    learnt a lot about the device.
    Now we are going to modify it.
  • 35:08 - 35:14
    First, we have to think about, If we are
    going to modify the firmware, we have
  • 35:14 - 35:20
    to prepare to brick our device.
  • 35:20 - 35:25
    Manufacturers implement several integrity
    checks, and why do they do that?
  • 35:25 - 35:35
    They do it because firmware is stored to flash,
    which is prone to aging, especially if heat is involved.
  • 35:35 - 35:42
    So they do checksums. There are softwarebased
    checksum calculations, CRC for example.
  • 35:42 - 35:49
    There are even hardwarebased checksums
    where some HW peripheral will do the job for us.
  • 35:49 - 35:57
    So what you see in the code is maybe the start
    offset, the end offset, and if you're lucky the polynomial.
  • 35:57 - 36:04
    It might be hardcoded in the peripheral too,
    so you won't see anything.
  • 36:04 - 36:13
    It can be a combination of both, being done
    only on startup or cyclically in the background.
  • 36:13 - 36:19
    What we have to do to modify the firmware
    is either correct those checksums,
  • 36:19 - 36:26
    or we have to patch those checksum
    algorithms not to trigger.
  • 36:26 - 36:32
    What are the goals of our modification, of
    course we heard it in our motivation section.
  • 36:32 - 36:45
    We are about to correct errors, and maybe the errors
    are contained in another part of firmware we are not
  • 36:45 - 36:51
    having right now. Maybe we have to dump
    additional memory regions.
  • 36:51 - 37:02
    That's what they did in the Cisco VoIP hack.
    They tried to find a memcpy routine and use it.
  • 37:02 - 37:09
    If you don't find a memcpy routine maybe
    you can implement your own. Why not?
  • 37:09 - 37:16
    You could dump code from other memory
    regions to output buffers.
  • 37:16 - 37:20
    If you have space in an external memory
    device, why not program it to the device
  • 37:20 - 37:30
    and read it from the device. It can be very
    interesting to gather more device internal information.
  • 37:30 - 37:37
    For example doing a RAM dump, because
    during static analysis, you always wonder
  • 37:37 - 37:48
    what may be in RAM at this and that address.
    Now as we have modified the firmware,
  • 37:48 - 37:54
    we can inject it back to the device. For
    example using the original updater.
  • 37:54 - 37:58
    It might contain the next checksum check, who knows.
  • 37:58 - 38:07
    We can try to re-program it to the external
    memory device if available, or to the processor.
  • 38:07 - 38:14
    This might be done using a serial interface,
    either JTAG or proprietary.
  • 38:14 - 38:18
    That's it. Thank you very much.
  • 38:18 - 38:26
    applause
  • 38:26 - 38:36
    Angel: If you have any questions, please line up
    at the room microphones, there are four here.
  • 38:43 - 38:47
    Are there any questions? Microphone 1 please;
  • 38:47 - 38:54
    Question: Not a question, but a tip. If you need some binary dump or some left over files on windows,
  • 38:54 - 39:06
    you can deny the delete right, so the install
    or updater program is unable to delete its tempfiles.
  • 39:06 - 39:09
    So they are left over after reprogramming the device.
  • 39:09 - 39:11
    A: Do you have tip what to use in that case?
  • 39:11 - 39:12
    Q: Sorry?
  • 39:12 - 39:14
    A: Do you have a tip, is there a special tool?
  • 39:14 - 39:19
    Q: It's not necessary, windows has
    the function already built in.
  • 39:19 - 39:20
    A: OK.
  • 39:20 - 39:27
    Q:And I don't know the word.
  • 39:27 - 39:28
    A: OK
  • 39:28 - 39:34
    Q: But you are able to revoke rights completely
    from a directory, there's a special right for deleting.
  • 39:34 - 39:37
    A: OK, thank you.
  • 39:37 - 39:43
    Angel: Are there any more questions?
  • 39:47 - 39:51
    Angel: Doesn't look like it, please give a warm
    round of applause to our speaker Stephan Widmann.
  • 39:51 - 39:55
    applause
    A: On [microphone 2]
  • 39:55 - 39:57
    Angel: There is one more question... No?
  • 39:57 - 40:00
    A: OK
  • 40:00 - 40:03
    Angel: If you're leaving please do take your...
  • 40:03 - 40:11
    subtitles created by c3subtitles.de
Title:
An introduction to Firmware Analysis
Video Language:
English
Duration:
40:11

English subtitles

Revisions