1 00:00:09,670 --> 00:00:12,346 So, I have already been introduced 2 00:00:12,346 --> 00:00:14,175 My name is Stefan Widmann 3 00:00:14,175 --> 00:00:18,325 and maybe I can have my slides? 4 00:00:26,215 --> 00:00:28,979 Hello, my slides? 5 00:00:34,489 --> 00:00:39,528 *laughter* 6 00:00:39,528 --> 00:00:42,149 Ich bin am VGA drauf. 7 00:00:47,599 --> 00:00:50,122 [hums] 8 00:00:52,342 --> 00:00:54,129 Yeah, um... 9 00:00:57,899 --> 00:01:00,098 [mumbling] 10 00:01:10,578 --> 00:01:17,191 Okay, so while we're waiting until my slides appear somehow. 11 00:01:17,191 --> 00:01:19,270 Who has seen the incredible talk about 12 00:01:19,270 --> 00:01:22,314 hacking the VoIP phones from Cisco, last year 13 00:01:22,314 --> 00:01:25,599 either live or on video? 14 00:01:25,599 --> 00:01:28,034 Okay some of you. 15 00:01:28,034 --> 00:01:30,528 When we think about this talk 16 00:01:30,528 --> 00:01:34,945 The Cisco VoIP phones have an embeddd 17 00:01:34,945 --> 00:01:37,889 Linux operating system, but they did not only 18 00:01:37,889 --> 00:01:41,889 have to deal with the linux OS, but also with 19 00:01:41,889 --> 00:01:44,372 the firmware of the DSP. 20 00:01:44,372 --> 00:01:50,910 So I want to tell you there's not only one system, 21 00:01:50,910 --> 00:02:03,300 but several systems. Several sub-systems containing firmware 22 00:02:03,300 --> 00:02:06,940 Slides would be nice, we can start without slides, there's no problem. 23 00:02:06,940 --> 00:02:09,899 So what are we going to talk about today? 24 00:02:09,899 --> 00:02:15,497 First we are going to talk about motivation, why should we do firmware analysis. 25 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. 26 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, 27 00:02:34,102 --> 00:02:41,191 how can we analyze it, and how can we modify it. 28 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. 29 00:02:54,001 --> 00:02:58,029 [speaks german] 30 00:03:33,254 --> 00:03:34,568 Hmm 31 00:03:37,658 --> 00:03:43,174 Okay, so we can do without slides, it's okay. 32 00:03:43,174 --> 00:03:48,902 Let's start with the motivation, why do we want to do firmware analysis. 33 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. 34 00:03:58,244 --> 00:04:06,568 And left is, you can do it if you want to gain interoperability. 35 00:04:06,568 --> 00:04:10,110 *laughter* 36 00:04:10,110 --> 00:04:14,791 You can do it if you want to get rid of errors, and the manufacturer 37 00:04:14,791 --> 00:04:21,561 does not want to or is unable. And one interesting point under 38 00:04:21,561 --> 00:04:29,240 discussion is, what about forensics, taking a look in those thousands of devices 39 00:04:29,240 --> 00:04:35,730 in everyday life. Do they only do what they are supposed to do? 40 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 41 00:04:48,030 --> 00:04:54,123 have one here within 1 minute. Again, very sorry. 42 00:05:06,473 --> 00:05:11,986 We now have Nick Farr on stage, our certified Powerpoint specialist. 43 00:05:11,986 --> 00:05:17,274 *applause* 44 00:05:17,274 --> 00:05:20,114 It can only take minutes now. 45 00:06:06,331 --> 00:06:10,764 Maybe we can continue. So I will just tell you something about prerequisites you 46 00:06:10,764 --> 00:06:19,194 should bring when starting to analyse You should at least have a good knowledge 47 00:06:19,194 --> 00:06:26,081 of embedded system architecture. You should have dealt with peripherals, 48 00:06:26,081 --> 00:06:32,223 bus interfaces and so on. You should be able to read 49 00:06:32,223 --> 00:06:35,185 and write assembler. Some might say: 50 00:06:35,185 --> 00:06:39,196 I have a very good decompiler, which is fine. 51 00:06:39,196 --> 00:06:45,518 If it works for you, okay, but don't rely on the availability of a decompiler 52 00:06:45,518 --> 00:06:49,191 for the architecture you're going to be working on 53 00:06:49,191 --> 00:06:55,675 Especially if you are going to work low down in the register stuff. 54 00:06:55,675 --> 00:07:03,664 And in my opinion, a decompiler output will confuse you more than help you. 55 00:07:03,664 --> 00:07:12,542 You will go to disassemble maybe, C runtime libraries, optimized to be as small as possible 56 00:07:12,542 --> 00:07:18,368 That can be really hard in decompiler output. 57 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 58 00:07:28,726 --> 00:07:36,340 your arduino or whatever. You write some little C code, handling some hardware stuff. 59 00:07:36,340 --> 00:07:45,497 Then you just compile it and take a look, what the disassembly looks like. 60 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. 61 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. 62 00:08:03,931 --> 00:08:09,330 And last but not least, what you need most is time. 63 00:08:09,330 --> 00:08:16,511 Time, time, time. It may take hours, days without any progress, so please be patient. 64 00:08:20,951 --> 00:08:26,560 *laughter* 65 00:08:29,680 --> 00:08:35,888 Any volunteers to make up some slides here? 66 00:08:43,628 --> 00:08:50,974 I swear, it worked perfectly okay with my external monitor. 67 00:08:50,974 --> 00:09:04,296 Yes? [illegible] 68 00:09:04,296 --> 00:09:08,305 So I'll have to fetch my USB stick, wait a moment. 69 00:09:08,305 --> 00:09:52,524 No problem, we're flexible. [whistling] 70 00:10:09,571 --> 00:10:15,257 So is there anyone who knows their way around a computer around here? 71 00:10:15,257 --> 00:10:19,803 Herald: While we figure that out, it might be a good possibility to remind you all 72 00:10:19,803 --> 00:10:27,505 that we are still looking for some Angels. You could do video angels, which are in 73 00:10:27,505 --> 00:10:32,699 high demand right now. Or you could just do any other work you'd like to. 74 00:10:32,699 --> 00:10:38,189 You can do one or two shifts, that's fine. It would be greatly appreciated 75 00:10:38,189 --> 00:10:49,230 because we require volunteer work for this event. Also if you brought any beverages in here, 76 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 77 00:10:54,262 --> 00:11:01,991 storage cases located all around the building. Trust me when we are finished, 78 00:11:01,991 --> 00:11:10,768 you'll be able to do this announcement. Are we good? No, not really. 79 00:11:10,768 --> 00:11:12,539 *laughter* 80 00:11:12,539 --> 00:11:15,812 It looks good on the laptop. 81 00:11:15,812 --> 00:11:19,184 You want to give a quick intro to the new Ubuntu desktop? 82 00:11:19,184 --> 00:11:27,888 Because I did not get that at all. 83 00:11:27,888 --> 00:11:33,403 Yeah, mirror displays man. 84 00:11:33,403 --> 00:11:39,708 4 zur 3 folien. 85 00:11:39,708 --> 00:11:41,821 Now we are making progress 86 00:11:41,821 --> 00:11:45,502 *applause* 87 00:11:45,502 --> 00:11:47,813 Enjoy the talk! 88 00:11:47,813 --> 00:11:51,747 Okay, perfect, now with slides. 89 00:11:51,747 --> 00:11:56,981 One small announcement, there will be 5 more minutes of extra talk at the end. 90 00:11:56,981 --> 00:12:04,203 We'll do that. So just please ignore the yellow bars. 91 00:12:04,203 --> 00:12:07,805 *laughter* 92 00:12:07,805 --> 00:12:18,308 Not really no. 93 00:12:18,308 --> 00:12:26,333 High level devices. Big complexity. YES! 94 00:12:28,563 --> 00:12:31,121 Perfect, thank you, without yellow bars, thank you. 95 00:12:31,121 --> 00:12:41,750 Okay. So we already talked about prerequisites, so now we're going deep into the topics. 96 00:12:41,750 --> 00:12:49,849 First we need to obtain a firmware. We will go from non-invasive to invasive. 97 00:12:49,849 --> 00:12:57,506 Because first thing we want to try is getting the firmware without opening the device. 98 00:12:57,506 --> 00:13:03,262 We will first try to download a plain binary from the manufacturer. 99 00:13:03,262 --> 00:13:12,147 or maybe someone else have extracted a binary and placed it on the internet. 100 00:13:12,147 --> 00:13:19,440 You can try to download a bootdisk, USB, CD-ROM, bootimage, whatever the manuf. provides. 101 00:13:19,440 --> 00:13:25,640 and extract it using, for example, WinRAR on windows or just mount it on linux. 102 00:13:25,640 --> 00:13:34,781 Search for files named .bin, .hex, .s19, .mot. like motorola, .rom or .raw. 103 00:13:34,781 --> 00:13:42,439 Most times binary, that means .bin, .rom or .raw files are already real binary files. 104 00:13:42,439 --> 00:13:50,691 Non-binary files should be converted to bin files, e.g with converters like hex2bin. 105 00:13:50,691 --> 00:13:55,876 If this doesn't work out, maybe we get an updater from the manufacturer 106 00:13:55,876 --> 00:14:00,461 Normally they're .exe files built for windows. 107 00:14:00,461 --> 00:14:07,429 There are different updater types. First the self-extracting archives. 108 00:14:07,429 --> 00:14:12,417 It might be an installer too, like Installshield or whatever. 109 00:14:12,417 --> 00:14:18,973 It might be an updater, simple .exe file without any installation, just containing the image. 110 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, 111 00:14:25,493 --> 00:14:31,675 but packed with an executable packer like UPX or PECompact. 112 00:14:31,675 --> 00:14:33,487 Let's go a little bit into detail. 113 00:14:33,487 --> 00:14:43,000 So if it's a self-extracting archive search for signatures like RARSFX or PK. 114 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. 115 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 116 00:14:59,223 --> 00:15:06,153 very hard to use and extremely version specific. It might work, it might not. 117 00:15:06,153 --> 00:15:10,994 The best way is to just let it install and search in the installed files 118 00:15:10,994 --> 00:15:20,242 for a plain image or updater. If it's an updater containing the firmware image, 119 00:15:20,242 --> 00:15:26,280 we can search for the image in the executable using your favorite hex-editor. 120 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 121 00:15:33,678 --> 00:15:40,735 it after usage. You can use ProcessMonitor which is like strace but on Windows 122 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 123 00:15:45,903 --> 00:15:52,300 before it's deleted. Maybe the updater is just checking your device, so its just 124 00:15:52,300 --> 00:15:57,477 a little downloader. Checking your device type, take a look on the ftp-site of the 125 00:15:57,477 --> 00:16:02,519 manufacturer and is downloading an image if there's one available. 126 00:16:02,519 --> 00:16:08,583 So if it's downloading the image to a file, use ProcessMonitor again. 127 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. 128 00:16:19,289 --> 00:16:27,297 If you have a packed updater, which of course is only done to save size. 129 00:16:27,297 --> 00:16:36,520 If it's standard UPX, you can download UPX and use UPX -d to unpack it. 130 00:16:36,520 --> 00:16:44,145 Sometimes the manufacturer violate the license of UPX and modify UPX by removing 131 00:16:44,145 --> 00:16:51,504 vital file information to make it un-depackable. So you would need a special unpacker. 132 00:16:51,504 --> 00:17:00,730 Other executable packers are most times designed not to be uncompressed. 133 00:17:00,730 --> 00:17:05,377 So you would need special unpackers too. 134 00:17:05,377 --> 00:17:12,243 One challenge that awaits us is, maybe the updaters contain compressed images. 135 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 136 00:17:20,714 --> 00:17:27,245 the process memory with a debugger and dump it. 137 00:17:27,245 --> 00:17:34,205 What's a bit more challenging is when the firmware is sent compressed to the device. 138 00:17:34,205 --> 00:17:40,827 So we have to use invasive techniques we will talk about later. 139 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. 140 00:17:47,752 --> 00:17:56,230 Maybe the favourite bloatware coming with the device wants to update it instantly. 141 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, 142 00:18:04,257 --> 00:18:14,313 there's TraceSPTI, a fantastic tool tracing SPTI SCSI PassThrough Interface. 143 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 144 00:18:22,573 --> 00:18:33,240 this protocol on Windows. to identify S/ATA USB devices, especially if they are ATAPI. 145 00:18:33,240 --> 00:18:39,042 On the linux side you might use Wireshark to trace the communication, because Wireshark 146 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 147 00:18:47,308 --> 00:18:54,752 to watch communication on buses. But the problem is they are normally very expensive. 148 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 149 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. 150 00:19:13,610 --> 00:19:20,643 If we do not have a firmware yet, it might get invasive now. 151 00:19:20,643 --> 00:19:26,891 We'll search for serial interfaces, sometimes they are accesible without opening the device, 152 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. 153 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, 154 00:19:42,221 --> 00:19:47,511 so I've included a link here. 155 00:19:47,511 --> 00:19:53,195 So, still no firmware? Get your screwdriver, let's void warranties. 156 00:19:53,195 --> 00:19:58,555 We open the device and we search for memory devices on the PCB. 157 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 158 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 159 00:20:15,233 --> 00:20:25,947 and the big flash devices with 48-pins for example with various other names. 160 00:20:25,947 --> 00:20:35,507 Very nice to see is that serial flashes, those 8-pin devices 25..., sometimes 24... 161 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 162 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 163 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. 164 00:21:02,327 --> 00:21:07,632 To make it a little bit harder, firmware can be contained in chip-internal memories. 165 00:21:07,632 --> 00:21:17,143 You can try to use proprietary programming interfaces to read the firmware, of course JTAG. 166 00:21:17,143 --> 00:21:24,389 Some devices do have bootloaders in a mask ROM. You can try to use them. 167 00:21:24,389 --> 00:21:29,623 If none of these approaches succeed, you can try microprobing. 168 00:21:29,623 --> 00:21:38,320 There was a talk on last years congress about low-cost chip microprobing, I've 169 00:21:38,320 --> 00:21:46,960 included a link here. So just for matter of completeness I've mentioned CPLDs and FPGAs. 170 00:21:46,960 --> 00:21:53,855 You know CPLDs are built up using internal EEPROMs. 171 00:21:53,855 --> 00:22:04,111 FPGAs, Field Programmable Gate Arrays have internal SRAM and an external serial configuration flash. 172 00:22:04,111 --> 00:22:12,411 Some years ago they were marketed as being reverse-engineer proof, okay. Yeah, maybe. 173 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. 174 00:22:22,960 --> 00:22:29,130 Yeah, congratulations, we've done it, we have our firmware, perfect. 175 00:22:29,130 --> 00:22:33,658 So what's next, now we have to analyze it. 176 00:22:33,658 --> 00:22:40,302 The problem is what processor is used. We don't know which disassembler to use. 177 00:22:40,302 --> 00:22:45,530 So we are searching the web for any datasheets, can we get any information. 178 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. 179 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. 180 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. 181 00:23:16,716 --> 00:23:24,297 You can use specific disassemblers, they are only built for one architecture. 182 00:23:24,297 --> 00:23:29,756 You can use a very good tool, the Interactive Disassembler, IDA. There's a freeware version. 183 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. 184 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. 185 00:23:46,423 --> 00:23:55,050 It's ODA, the Online Disassembler, supporting thirty something architectures, and it's free. 186 00:23:55,050 --> 00:24:01,477 You can upload binary files, you can upload code, and try different architectures, 187 00:24:01,477 --> 00:24:07,504 and find out what might be the correct one, and we'll do that now. 188 00:24:07,504 --> 00:24:12,350 So I've prepared some binary code. 189 00:24:12,350 --> 00:24:17,521 I know which architecture this has been written for, because I did it. 190 00:24:17,521 --> 00:24:24,537 I put this code to Online Disassembler, and I chose different architectures, 191 00:24:24,537 --> 00:24:28,283 and now lets look at what the disassembly looks like. 192 00:24:28,283 --> 00:24:36,501 Let's first start with former Hitachi, now Renesas, H8S. I hope you can read it. 193 00:24:36,501 --> 00:24:41,538 Take some time and please raise your hand if you think this is valid disassembly and 194 00:24:41,538 --> 00:24:48,299 we have found our architecture. 195 00:24:48,299 --> 00:24:53,334 I see one hand. 196 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. 197 00:24:59,589 --> 00:25:06,223 The disassembler was not able to disassemble the data and it's just an undefined instruction. 198 00:25:06,223 --> 00:25:12,875 There are several .word's in the code. It's not H8S. 199 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. 200 00:25:22,251 --> 00:25:27,206 *laughter* again? 201 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. 202 00:25:39,480 --> 00:25:50,690 What about Panasonic MN103 family? The same hand again? Oh I see another hand. 203 00:25:50,690 --> 00:25:57,127 Ok, several hands now. Yeah, OK, thank you. 204 00:25:57,127 --> 00:26:01,220 So the problem is, it's not valid. I have to disappoint you. 205 00:26:01,220 --> 00:26:06,786 The problem is in this case, it looks really good and you have to dig deeper. 206 00:26:06,786 --> 00:26:14,020 You will have to look at, are all subroutines correct. Do they make sense? 207 00:26:14,020 --> 00:26:17,270 Are there subroutine calls at all and so on. 208 00:26:17,270 --> 00:26:23,144 And you will see something strange. Ok last try. 209 00:26:23,144 --> 00:26:28,533 What about Texas Instruments MSP430? 210 00:26:28,533 --> 00:26:33,258 And again, please raise your hands. 211 00:26:33,258 --> 00:26:40,895 Okay? Yeah, this time it is MSP430! 212 00:26:40,895 --> 00:26:48,172 We have found our architecture, perfect, eureka, bingo, we have it. 213 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 214 00:26:56,770 --> 00:27:04,850 not the offset in address space. This is no real problem when the architecture is 215 00:27:04,850 --> 00:27:12,030 using relative adressing. Relative adressing means we have register content and whatever 216 00:27:12,030 --> 00:27:20,130 we want to access is based on some registers content. Location independent code. 217 00:27:20,130 --> 00:27:27,468 But we have a big problem when absolute adressing is being used, and even architectures 218 00:27:27,468 --> 00:27:36,617 supporting relative adressing do have some absolute adressing, somewhere on some accesses. 219 00:27:36,617 --> 00:27:40,893 We would not know, where's the entry point. Where should we start? 220 00:27:40,893 --> 00:27:47,551 Interrupt vectors might be decoded completely wrong, subroutine calls do not make any sense. 221 00:27:47,551 --> 00:27:54,376 They go to [addresses] outside of our firmware for example, or in the middle of instructions. 222 00:27:54,376 --> 00:28:01,227 So the load offset has to be found. 223 00:28:01,227 --> 00:28:08,909 I'll now show a method I call "call distance search". 224 00:28:08,909 --> 00:28:15,572 We will select closely located subroutine adresses and we'll have to decide either to use 225 00:28:15,572 --> 00:28:21,959 preceding return instructions in front of the subroutines, or the start of the function 226 00:28:21,959 --> 00:28:31,319 entry sequence. We build a search string containing wildcards, and then we search. 227 00:28:31,319 --> 00:28:36,284 Now we'll do that together, I've prepared an example. 228 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 229 00:28:45,771 --> 00:28:53,654 because it's cheap as dirt and you can implement it wherever you want. 230 00:28:53,654 --> 00:29:01,725 In the left column we see the addresses of our example, from 0x00 to 0x13 hex. 231 00:29:01,725 --> 00:29:13,430 We see four subroutines, with the first being the root subroutine, calling the other three subroutines. 232 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. 233 00:29:23,443 --> 00:29:30,472 So what we do is take the three subroutine adresses and sort them. 234 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. 235 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. 236 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, 237 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 238 00:30:11,500 --> 00:30:15,229 So you can trigger on that one. 239 00:30:15,229 --> 00:30:24,548 On 8051 it's not possible. Take a look at address 0x0A It's 0xE0. 240 00:30:24,548 --> 00:30:28,530 Take a look at address 0x0D , it's 44, and 0x11 is 7B. 241 00:30:28,530 --> 00:30:32,108 The are not equal, it does not help us. 242 00:30:32,108 --> 00:30:39,690 So we look at the preceding returns and yes there are returns in front 243 00:30:39,690 --> 00:30:45,483 of every subroutine. So we take the 0x22 [ret] as our anchor. 244 00:30:45,483 --> 00:30:51,259 Our search string will look like this; We start with the 0x22, we have a 245 00:30:51,259 --> 00:30:56,823 subroutine with a length of 3 bytes, so we have 0x22 [ret], two wildcards and 246 00:30:56,823 --> 00:31:04,483 again a return. The second part of the search string encodes the second 247 00:31:04,483 --> 00:31:13,244 subroutine with 4 bytes. So we have wildcard, wildcard, wildcard and again a return [0x22] 248 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. 249 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, 250 00:31:27,888 --> 00:31:33,447 so we are not using the 0x09, we are using the 0x0A. 251 00:31:33,447 --> 00:31:40,662 What we do is we take the original destination address 0x0100, we subtract 0x0A 252 00:31:40,662 --> 00:31:49,411 and we get the base address of our code example, which is 0xF6 253 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 254 00:31:58,392 --> 00:32:06,430 starting now at 0x00F6 in the left column we see that all three subroutines now match. 255 00:32:06,430 --> 00:32:14,706 The call to 0x0100, the call to 0x0107 and the call to 0x0103. 256 00:32:14,706 --> 00:32:22,706 Ok, I think this was hard, so let's repeat what we have already done. 257 00:32:22,706 --> 00:32:30,647 So we have obtained our image, we have successfully found the processor architecture, 258 00:32:30,647 --> 00:32:35,143 we have found a disassembler to disassemble the firmware, 259 00:32:35,143 --> 00:32:43,746 and we have hopefully found the original load offset. So what's next 260 00:32:43,746 --> 00:32:49,358 Maybe the question arises, is there additional firmware in this device? 261 00:32:49,358 --> 00:32:56,254 I see jumps and calls outside of firmware we already know, although we have adjusted 262 00:32:56,254 --> 00:33:02,446 the load offset. Is it chip internal? We can see it on the figure, maybe 263 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. 264 00:33:10,387 --> 00:33:18,900 So we will have to see what we can do using a modification of the firmware. 265 00:33:18,900 --> 00:33:26,843 Now having done that, we can start with normal reverse engineering of the code. 266 00:33:26,843 --> 00:33:31,537 We search for strings, we search for references to the strings, 267 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, 268 00:33:39,353 --> 00:33:48,580 data references and operands. Search for USB descriptor fields, you have extracted with /bin/lsusb 269 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 270 00:33:55,228 --> 00:34:03,727 usb communications. Take a look for IDE, SATA and ATAPI ID strings, saying 271 00:34:03,727 --> 00:34:15,761 "I'm a OCZ SSD device" for instance. When you've sniffed the device communication 272 00:34:15,761 --> 00:34:21,920 you've already found some typical datablocks. You can try to find them [in the binary] 273 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, 274 00:34:28,145 --> 00:34:33,887 or for operands in the opcodes. 275 00:34:33,887 --> 00:34:38,954 It's very interesting to find hidden firmware update sequences, because 276 00:34:38,954 --> 00:34:47,220 they would allow non-invasive modifications. For example search for chip erase and 277 00:34:47,220 --> 00:34:51,870 programming commands, you can take the appropriate commands from the datasheet 278 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 279 00:35:01,519 --> 00:35:07,917 learnt a lot about the device. Now we are going to modify it. 280 00:35:07,917 --> 00:35:14,320 First, we have to think about, If we are going to modify the firmware, we have 281 00:35:14,320 --> 00:35:19,687 to prepare to brick our device. 282 00:35:19,687 --> 00:35:25,042 Manufacturers implement several integrity checks, and why do they do that? 283 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. 284 00:35:34,766 --> 00:35:42,409 So they do checksums. There are softwarebased checksum calculations, CRC for example. 285 00:35:42,409 --> 00:35:48,537 There are even hardwarebased checksums where some HW peripheral will do the job for us. 286 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. 287 00:35:57,179 --> 00:36:03,656 It might be hardcoded in the peripheral too, so you won't see anything. 288 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. 289 00:36:13,168 --> 00:36:18,739 What we have to do to modify the firmware is either correct those checksums, 290 00:36:18,739 --> 00:36:26,140 or we have to patch those checksum algorithms not to trigger. 291 00:36:26,140 --> 00:36:32,309 What are the goals of our modification, of course we heard it in our motivation section. 292 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 293 00:36:44,751 --> 00:36:51,369 having right now. Maybe we have to dump additional memory regions. 294 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. 295 00:37:02,249 --> 00:37:08,551 If you don't find a memcpy routine maybe you can implement your own. Why not? 296 00:37:08,551 --> 00:37:15,892 You could dump code from other memory regions to output buffers. 297 00:37:15,892 --> 00:37:20,427 If you have space in an external memory device, why not program it to the device 298 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. 299 00:37:29,918 --> 00:37:36,561 For example doing a RAM dump, because during static analysis, you always wonder 300 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, 301 00:37:48,435 --> 00:37:53,960 we can inject it back to the device. For example using the original updater. 302 00:37:53,960 --> 00:37:58,437 It might contain the next checksum check, who knows. 303 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. 304 00:38:06,598 --> 00:38:14,163 This might be done using a serial interface, either JTAG or proprietary. 305 00:38:14,163 --> 00:38:17,967 That's it. Thank you very much. 306 00:38:17,967 --> 00:38:25,766 *applause* 307 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. 308 00:38:42,573 --> 00:38:47,125 Are there any questions? Microphone 1 please; 309 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, 310 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. 311 00:39:06,456 --> 00:39:08,858 So they are left over after reprogramming the device. 312 00:39:08,858 --> 00:39:10,733 A: Do you have tip what to use in that case? 313 00:39:10,733 --> 00:39:11,723 Q: Sorry? 314 00:39:11,723 --> 00:39:14,262 A: Do you have a tip, is there a special tool? 315 00:39:14,262 --> 00:39:18,902 Q: It's not necessary, windows has the function already built in. 316 00:39:18,902 --> 00:39:20,422 A: OK. 317 00:39:20,422 --> 00:39:26,622 Q:And I don't know the word. 318 00:39:26,622 --> 00:39:27,506 A: OK 319 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. 320 00:39:34,288 --> 00:39:37,407 A: OK, thank you. 321 00:39:37,407 --> 00:39:42,603 Angel: Are there any more questions? 322 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. 323 00:39:50,631 --> 00:39:54,821 *applause* A: On [microphone 2] 324 00:39:54,821 --> 00:39:57,465 Angel: There is one more question... No? 325 00:39:57,465 --> 00:39:59,546 A: OK 326 00:39:59,546 --> 00:40:02,268 Angel: If you're leaving please do take your...