1 00:00:00,760 --> 00:00:02,020 Let's kick it. 2 00:00:02,960 --> 00:00:13,900 Normally, I would like to look out and gaze into your eyes and figure out, by peering into your soul, what's bothering you, what's exciting you, whether you're engaged, if you're on your phone. 3 00:00:13,900 --> 00:00:18,440 But since I can't, I'm just going to throw pencils there and pick on him. 4 00:00:18,680 --> 00:00:19,460 That's fine. 5 00:00:22,280 --> 00:00:25,380 Go ahead. 6 00:00:25,580 --> 00:00:34,360 Oh, in order of events here, we're going to do some dry PPC, because we're gigantic nerds. 7 00:00:34,980 --> 00:00:39,440 We're going to talk about the kind of guts of this, which is the vivisect stuff. 8 00:00:42,000 --> 00:00:46,780 Who cares about PowerPC? 9 00:00:49,140 --> 00:00:50,880 Only us nerds, right? 10 00:00:51,760 --> 00:00:52,820 I hope not. 11 00:00:53,260 --> 00:00:56,640 Or, you know, I suppose the people developing embedded devices care. 12 00:00:56,900 --> 00:01:01,540 I hope that the people whose lives are in jeopardy care, but we'll get into that. 13 00:01:05,120 --> 00:01:07,980 I'm going to insert an x86 joke here. 14 00:01:10,420 --> 00:01:14,360 We've been programming PowerPC for a long time. 15 00:01:15,000 --> 00:01:18,980 We always used to pick on the x86 people. 16 00:01:20,300 --> 00:01:29,180 And the reverse engineers care, which is an interesting topic, because the tools for doing that are not that great. 17 00:01:29,180 --> 00:01:33,920 Oh, and I'm pointing on my screen like people can actually see me. 18 00:01:33,920 --> 00:01:35,100 Not like I'm pointing up at the... 19 00:01:37,240 --> 00:01:38,920 NMFTA, they care. 20 00:01:40,260 --> 00:01:42,380 People running mainframes care. 21 00:01:42,980 --> 00:01:45,700 Why would they care? 22 00:01:45,700 --> 00:01:46,780 Why would they care? 23 00:01:46,860 --> 00:01:48,760 Actually, Aaron, who are you? 24 00:01:48,780 --> 00:01:49,540 Who am I? 25 00:01:49,540 --> 00:01:50,760 Oh, okay. 26 00:01:50,960 --> 00:01:53,700 We skipped the intro slides here. 27 00:01:53,700 --> 00:01:54,780 I guess so. 28 00:01:54,900 --> 00:01:57,880 I am Aaron, or Acorn. 29 00:01:57,880 --> 00:02:00,240 I'm a security researcher with Grimm. 30 00:02:00,930 --> 00:02:09,200 For most of my career, I was doing embedded software and system development, used typically on safety critical systems. 31 00:02:09,200 --> 00:02:13,540 I've worked on telecom and Motorola. 32 00:02:13,540 --> 00:02:26,470 And I've worked on medical devices, industrial control, aerospace, a wide array of different platforms and architectures and processors and languages and junk. 33 00:02:26,470 --> 00:02:32,990 And now I get to do what I've always wanted to do, which is pull things apart and figure out how they work. 34 00:02:34,350 --> 00:02:35,310 Indeed. 35 00:02:35,390 --> 00:02:35,870 Awesome. 36 00:02:35,870 --> 00:02:37,990 I'm so glad to hear that you love that. 37 00:02:38,850 --> 00:02:40,770 And I am Atlas. 38 00:02:40,830 --> 00:02:45,430 I've been hacking, reversing stuff for about 15 years. 39 00:02:45,550 --> 00:03:02,570 And I've had the opportunity, the good fortune to hack with some of the most amazing people on some of the most intriguing targets, including virtual machines, smart meters, all sorts of RF things, automotive embedded things. 40 00:03:03,190 --> 00:03:08,330 And now, as of recent, space things. 41 00:03:08,610 --> 00:03:12,890 Please forgive me if I snore sometime during the presentation. 42 00:03:12,890 --> 00:03:14,470 Aaron, you'll have to yell. 43 00:03:14,490 --> 00:03:19,170 I was up for 26 hours straight hacking satellites last night. 44 00:03:19,170 --> 00:03:27,150 And when my kids got up and started meandering around the house at 9.30 this morning, I thought I should probably go to bed. 45 00:03:27,210 --> 00:03:30,530 So I did get about four and a half hours sleep. 46 00:03:30,530 --> 00:03:33,050 So I didn't short you guys too much. 47 00:03:33,050 --> 00:03:36,290 That's what I would have normally gotten in DEF CON Vegas. 48 00:03:36,890 --> 00:03:39,910 So a little about me. 49 00:03:39,910 --> 00:03:48,690 I love, just like Aaron, I love tearing things apart, figuring how they work, how we can make them work better or interesting. 50 00:03:48,930 --> 00:03:55,530 I am a Christian, a father of three and a husband of one. 51 00:03:55,750 --> 00:04:00,370 And I love talking to you guys. 52 00:04:00,830 --> 00:04:06,490 So why would anybody other than us nerds care, Aaron? 53 00:04:06,570 --> 00:04:09,790 Where do we see power PC chips these days? 54 00:04:10,730 --> 00:04:20,870 Well, we see them in my mouse works. 55 00:04:21,250 --> 00:04:23,230 Or not, whichever, you know. 56 00:04:24,810 --> 00:04:26,770 Oh, I'm skipping ahead. 57 00:04:27,490 --> 00:04:29,030 I guess I think we got a word. 58 00:04:29,030 --> 00:04:37,830 Where we see them here today, mainframes, IBM, all of those systems that, what is it called now? 59 00:04:38,830 --> 00:04:41,870 I, system I, I think is what they call it. 60 00:04:41,870 --> 00:04:43,150 Oh yeah, IBM I. 61 00:04:43,510 --> 00:04:50,810 Those are all power PC systems, not the weird 48-bit things they used to be. 62 00:04:51,230 --> 00:04:53,030 Embedded controls, right? 63 00:04:54,130 --> 00:04:55,030 Yep. 64 00:04:55,490 --> 00:05:03,330 IBM also, they've got their I platforms and their AIX, used to be the RS6000s. 65 00:05:04,450 --> 00:05:06,750 And they all run on power PC. 66 00:05:06,750 --> 00:05:12,750 In fact, they've put them under the umbrella known as the power systems. 67 00:05:12,750 --> 00:05:14,730 So go figure. 68 00:05:15,950 --> 00:05:21,550 So NXP, NXP, I've seen their name somewhere. 69 00:05:21,650 --> 00:05:24,250 Kind of things that they get their, their chips into. 70 00:05:25,510 --> 00:05:28,730 Oh, rhetorical questions here. 71 00:05:29,670 --> 00:05:43,310 Automotive, industrial systems, aerospace, they're heavily favored for platforms that, I guess, prize, what, reliability, durability, determinism. 72 00:05:44,070 --> 00:05:45,810 The littler things though. 73 00:05:45,810 --> 00:05:45,990 Yeah. 74 00:05:45,990 --> 00:05:48,510 Not the things that you carry in your backpack. 75 00:05:48,510 --> 00:05:51,290 Well, I mean, maybe, but not your laptops and. 76 00:05:51,290 --> 00:05:52,330 Right. 77 00:05:52,330 --> 00:05:53,090 Embedded things. 78 00:05:53,090 --> 00:05:55,210 NXP has dominated that space. 79 00:05:55,210 --> 00:05:55,970 Right. 80 00:05:57,010 --> 00:05:57,410 Yeah. 81 00:05:57,410 --> 00:06:06,090 They, they also have satellites and space things, but unfortunately I've been working on Spark systems for the last day or so. 82 00:06:06,470 --> 00:06:11,810 Yeah, that's a, it's a different, a different presentation talking about Leon and Spark. 83 00:06:12,390 --> 00:06:18,010 But for power PC is very traditional, typically or radiation hardened systems. 84 00:06:18,010 --> 00:06:22,090 I think they call it the rad 750 is a very, very common one. 85 00:06:22,090 --> 00:06:25,890 It's the old G3 series stuff. 86 00:06:26,270 --> 00:06:27,910 Assuming I remember right. 87 00:06:27,910 --> 00:06:29,970 It's been a few years since I confirmed. 88 00:06:30,970 --> 00:06:34,150 But yeah, so power PC, for those of you who don't know, right. 89 00:06:34,150 --> 00:06:35,050 Risk. 90 00:06:35,710 --> 00:06:37,650 Kind of. 91 00:06:38,650 --> 00:06:39,870 Fixed instruction words. 92 00:06:39,870 --> 00:06:43,290 About every, every risk process I ran into actually. 93 00:06:43,570 --> 00:06:52,170 You know, every time you get a risk platform, you start finding very non-reduced parts of it very quickly. 94 00:06:53,270 --> 00:06:56,230 Fixed instruction word, 32 bits, every instruction. 95 00:06:57,450 --> 00:06:58,590 Kind of. 96 00:06:58,590 --> 00:07:02,610 We saw a bit of a sneak preview on that of my other work slides here. 97 00:07:03,210 --> 00:07:12,830 Those of you who are familiar with Apple in the nineties and early two thousands will of course recognize power PC from that. 98 00:07:12,830 --> 00:07:14,630 Power books, right? 99 00:07:15,270 --> 00:07:16,050 Power books. 100 00:07:16,770 --> 00:07:22,550 Their releases, the G3, G4, G5. 101 00:07:22,550 --> 00:07:32,210 I think they were all actually tied into the different releases of the, the power PC architecture documentation. 102 00:07:32,350 --> 00:07:33,470 Yep. 103 00:07:34,190 --> 00:07:39,230 So yeah, the things that they're used in bed controls, IBM and old apples. 104 00:07:39,230 --> 00:07:41,590 I should have said old Apple computers there, right? 105 00:07:41,590 --> 00:07:44,650 I guess it's the slides titled history lesson. 106 00:07:44,650 --> 00:07:47,450 So I thought it was kind of obvious. 107 00:07:47,930 --> 00:07:51,770 Here's the caveat for a 32 bit thing. 108 00:07:51,770 --> 00:08:07,970 Freescale created a variable instruction word within APU, which is what power PC companies call extensions, extra things. 109 00:08:07,970 --> 00:08:17,310 If evolution and Darwinism was applied to computer systems, APUs would be the mechanism through which evolution occurred. 110 00:08:17,310 --> 00:08:19,910 And the platypus was formulated. 111 00:08:20,670 --> 00:08:23,650 So not my favorite thing. 112 00:08:23,650 --> 00:08:32,850 They have fractured the, the entire power PC world and made it ever so difficult to make good tooling for it, but we'll get to that. 113 00:08:32,850 --> 00:08:33,390 Yeah. 114 00:08:33,390 --> 00:08:34,150 Yeah. 115 00:08:35,370 --> 00:08:37,170 Found this fun slide here. 116 00:08:37,170 --> 00:08:38,870 It's probably only interesting to me. 117 00:08:39,430 --> 00:08:40,870 I loved it. 118 00:08:41,110 --> 00:08:43,030 I love the title of it though. 119 00:08:43,030 --> 00:08:50,450 Power architecture demystified, which is an extremely bold claim for anybody who's familiar with power PC. 120 00:08:50,730 --> 00:08:54,390 But here they've got the, you know, there's this little highlighted section here. 121 00:08:55,290 --> 00:08:58,410 Somebody who worked at Freescale slash NXP. 122 00:08:58,410 --> 00:09:00,250 I think this was produced in 2000. 123 00:09:00,250 --> 00:09:01,550 This paper was from 2007. 124 00:09:01,550 --> 00:09:04,390 So this would be somebody who was at Freescale at the time. 125 00:09:05,310 --> 00:09:11,690 With benchmarking, they said that the code is 30% smaller with only a 5% reduction in performance. 126 00:09:12,770 --> 00:09:14,510 You know what I read that to say? 127 00:09:14,510 --> 00:09:15,190 What? 128 00:09:15,190 --> 00:09:18,430 I read that to say ARM's doing it. 129 00:09:18,430 --> 00:09:21,030 We should probably do something like that too. 130 00:09:21,370 --> 00:09:22,370 Probably. 131 00:09:22,570 --> 00:09:24,790 That's probably exactly it. 132 00:09:25,830 --> 00:09:30,530 Automotive especially loves their small memory footprint parts. 133 00:09:30,530 --> 00:09:33,850 Well, you know, you save a fraction of a penny per chip. 134 00:09:34,190 --> 00:09:34,810 Yeah. 135 00:09:34,830 --> 00:09:41,310 But this type of thing, the VLE stuff, it's a big, all of the, well, I shouldn't say all. 136 00:09:41,310 --> 00:09:50,410 A great deal of the embedded components use the VLE features on embedded controls right now. 137 00:09:51,150 --> 00:09:59,310 And it's kind of a big deal because as Alice said, it makes producing tooling very, very complicated. 138 00:10:00,230 --> 00:10:09,170 Like making PowerPC tools is like making tools for like 20 different processors for architectures. 139 00:10:09,410 --> 00:10:17,750 And reading the documentation for them makes it feel like you're making it, you're making tools for thousands of architectures. 140 00:10:17,750 --> 00:10:18,070 Yeah. 141 00:10:18,070 --> 00:10:20,830 Because they don't coalesce well. 142 00:10:23,540 --> 00:10:24,940 So, Vivisect. 143 00:10:24,940 --> 00:10:28,060 Can you tell me something about Vivisect? 144 00:10:28,060 --> 00:10:28,780 Yeah. 145 00:10:28,780 --> 00:10:38,040 So, Vivisect is a binary analysis framework that was created specifically for the purpose of finding and exploiting vulnerabilities. 146 00:10:38,980 --> 00:10:43,840 Originally created by a really good friend of mine named Invisigoth. 147 00:10:46,820 --> 00:10:50,320 It speaks my language, so to speak. 148 00:10:50,320 --> 00:10:51,660 It's pure Python. 149 00:10:52,200 --> 00:11:00,620 It allows me a ton of power in many different ways, including from the command line. 150 00:11:00,620 --> 00:11:02,300 I'm an IPython person. 151 00:11:02,300 --> 00:11:08,100 I go to work and I type IPython and I feel like I'm starting to do something meaningful. 152 00:11:09,060 --> 00:11:14,380 So, there's a lot of cool, meaningful things I can do with Vivisect there. 153 00:11:14,420 --> 00:11:19,440 But it's been forward thinking since it was originally created. 154 00:11:19,860 --> 00:11:31,960 And so, instead of a disassembly framework, we got every architecture that you disassemble for has an emulator wrapped in with it. 155 00:11:31,960 --> 00:11:42,760 But not just an emulator, like a QEMU, a partial emulation engine, which allows for things to have taint tracking, for example. 156 00:11:42,760 --> 00:11:50,620 If we try to read memory that doesn't exist or if we try to access uninitialized variables or whatever. 157 00:11:50,820 --> 00:11:58,220 So, we can focus not just on code flow from the beginning of a program, but we can say, hey, this function looks interesting. 158 00:11:58,220 --> 00:12:09,280 Give me a feel for what it does and an emulator can roll through and say, oop, that's a problem, but I've been programmed to keep going and I just kind of keep track of that. 159 00:12:09,360 --> 00:12:11,660 Or, oop, that's ARG1. 160 00:12:11,660 --> 00:12:18,500 So, I know that ARG1 is now going to propagate through this calculation and whatnot. 161 00:12:19,900 --> 00:12:32,420 But then a few years later, I was talking to Vizi and he said, you know, emulation is awesome and super powerful, but you really need to focus on symbolic execution. 162 00:12:32,580 --> 00:12:34,680 And I'm like, what is that? 163 00:12:34,960 --> 00:12:57,700 And I looked into it and it turns out the first thing that I found of interest with symbolic execution, this is way before CGC was around, was NASA talking about how they were using symbolic execution to identify flaws and potential problems before shipping satellites into space or the Mars rovers to Mars, 164 00:12:57,700 --> 00:13:00,720 since repairing those things kind of sucks. 165 00:13:02,700 --> 00:13:15,620 So, BIVSEC also has, wraps in cross-platform debugging in a subsection that we don't call out here called BDB, vulnerability debugger. 166 00:13:16,100 --> 00:13:24,360 And so, these things all wrap around and support x86, 32 and 64-bit. 167 00:13:25,540 --> 00:13:45,820 MSP430, there's also 8051 in there, ARM and thumb mode, v7 at the moment, we have some deltas to wrap in ARM v8, z80, hate, I love just saying that name because it's also another one of those architectures that I just really love. 168 00:13:48,420 --> 00:14:10,880 I think I love BIVSEC the most because not only is it really pretty because it's green and black for most things, but the ability to easily extend it and do inspection of what's going on under the hood, so I understand how to reuse the tooling and use it to the best of my ability in my own external tools. 169 00:14:11,240 --> 00:14:16,300 So, command line stuff, just programming plugins, whatnot. 170 00:14:17,040 --> 00:14:18,760 Okay, enough about that. 171 00:14:18,900 --> 00:14:20,980 I've said four and a half hours sleep. 172 00:14:23,360 --> 00:14:26,500 So, why don't you talk about this, Aaron? 173 00:14:28,240 --> 00:14:30,560 Well, let me give a little backstory. 174 00:14:30,700 --> 00:14:49,680 A while back, I was already working on wrapping PowerPC into BIVSEC, and NMFTA said, we'd like to fund some of that research, just make sure that it benefits the world. 175 00:14:50,300 --> 00:14:54,820 And so, it was already open source, so that was an easy sell. 176 00:14:55,740 --> 00:15:10,940 And so, they paid for us for a bit of research, and Aaron donated a lot of his time as well, in addition, over and above what we were paid to do, just because he's awesome and recognizes the value. 177 00:15:11,300 --> 00:15:19,220 So, I tapped him, and it was one of the best things that I could have done for that project, because, well, I'll tell you that later. 178 00:15:19,220 --> 00:15:20,560 Talk about this, Aaron. 179 00:15:20,920 --> 00:15:22,000 Sure, sure. 180 00:15:22,040 --> 00:15:29,640 So, adding an ISA to BIVSEC, as Alex said, there's a couple different parts of it. 181 00:15:29,740 --> 00:15:33,660 You've got to figure out how to disassemble the different instructions, right? 182 00:15:33,660 --> 00:15:36,660 You've got to get your documentation to figure out what the instructions look like. 183 00:15:36,660 --> 00:15:39,220 Then you need to figure out how to emulate their behavior. 184 00:15:39,800 --> 00:15:41,400 You need to... 185 00:15:41,400 --> 00:15:46,440 symbolic analysis is a bit outside of my wheelhouse there. 186 00:15:46,820 --> 00:15:48,440 Yeah, I took most of that on. 187 00:15:48,520 --> 00:15:52,060 It's a different way of thinking. 188 00:15:53,040 --> 00:15:59,740 Testing is not where I thought I would end up doing a lot of work, but apparently, it's where I did a lot of work. 189 00:16:00,560 --> 00:16:07,360 Figuring out how to test tools to handle a new architecture is interesting. 190 00:16:07,800 --> 00:16:10,420 You know, how do you... where do you get that information from? 191 00:16:10,420 --> 00:16:11,760 Obviously, you get your documentation. 192 00:16:11,760 --> 00:16:12,760 At least, I hope you do. 193 00:16:12,760 --> 00:16:14,200 It's going to be a stretch. 194 00:16:14,980 --> 00:16:17,660 You get existing compilers and object dump tool. 195 00:16:17,660 --> 00:16:18,880 That's useful. 196 00:16:19,480 --> 00:16:24,160 If you take existing disassembly tools, those can be useful. 197 00:16:24,160 --> 00:16:30,040 Those will give you a certain view of the results that may or may not match the object dump. 198 00:16:30,140 --> 00:16:35,120 You can just make gigantic lists of instructions to parse from your documentation. 199 00:16:35,380 --> 00:16:38,320 Don't forget, you also have to figure out how to do the behavior of that. 200 00:16:39,980 --> 00:16:43,220 No matter which one of these paths you take. 201 00:16:43,520 --> 00:16:50,300 Oh, and also option D, which I forgot to put down there, which is get the hardware and run it. 202 00:16:50,640 --> 00:16:58,980 For PowerPC, that would really mean get, like, what, 20, 30, 40 different pieces of hardware. 203 00:17:00,140 --> 00:17:03,620 It's not going to be challenging to do it for everything, but it is useful. 204 00:17:04,080 --> 00:17:07,280 We got our hands on a couple different architectures for it. 205 00:17:07,420 --> 00:17:09,400 A couple different platforms. 206 00:17:09,740 --> 00:17:14,100 One embedded and one more server-esque. 207 00:17:15,820 --> 00:17:19,580 So we were able to have all that at our disposal. 208 00:17:19,620 --> 00:17:25,080 So, Aaron, this sounds a lot like magic. 209 00:17:25,400 --> 00:17:26,480 It does. 210 00:17:28,860 --> 00:17:30,400 But what's it really mean? 211 00:17:30,400 --> 00:17:37,660 What's it look like to write disassembly code or an emulation instruction? 212 00:17:37,660 --> 00:17:39,300 How do you emulate an instruction? 213 00:17:40,680 --> 00:17:42,680 How do you emulate an instruction? 214 00:17:43,220 --> 00:17:44,780 Mostly the disassembly part. 215 00:17:44,780 --> 00:17:49,840 I feel most people think that is more magic than it really is. 216 00:17:49,840 --> 00:17:50,460 It is. 217 00:17:50,460 --> 00:17:55,480 The magic really is about finding the documentation and understanding what they meant. 218 00:17:55,820 --> 00:17:56,460 Sure. 219 00:17:56,460 --> 00:18:02,020 Well, you know, once you... I guess it's basically about the numbers, right? 220 00:18:02,020 --> 00:18:06,840 Everything at its base form in computers is a number. 221 00:18:07,060 --> 00:18:10,340 Hexadecimal, decimal, whichever way you prefer to read it. 222 00:18:10,440 --> 00:18:12,240 Everything is numbers. 223 00:18:12,240 --> 00:18:15,740 If it's data, if it's code, whatever it is, it's just a number. 224 00:18:15,840 --> 00:18:23,460 So you just read in byte by byte or four bytes by four bytes or however many bytes by however many bytes for your architecture. 225 00:18:23,700 --> 00:18:26,080 And then you just start taking a look. 226 00:18:26,140 --> 00:18:29,400 This particular pattern here means that it's this instruction. 227 00:18:29,400 --> 00:18:31,820 This particular pattern here means it's this instruction. 228 00:18:32,440 --> 00:18:37,420 This right here is a fun list of test inputs. 229 00:18:38,160 --> 00:18:41,280 Wish we could have gotten your scrolling version going. 230 00:18:41,280 --> 00:18:41,780 That would have been... 231 00:18:41,780 --> 00:18:43,220 Yeah, I don't know. 232 00:18:43,220 --> 00:18:47,180 For some reason, I just can't... media, you know... 233 00:18:47,740 --> 00:18:59,500 Aaron wrote a list of about 30... he took a list of about 30 times this length and had it just scrolling in video and somehow Google Docs didn't like it. 234 00:19:00,180 --> 00:19:05,680 About like 30 megabyte GIFs did not play nice. 235 00:19:08,080 --> 00:19:24,540 Yeah, so in this particular case, what I started doing was I took a PowerPC Linux kernel and I disassembled it, which I figured that that would have a fantastic variety of instructions of different encodings and forms. 236 00:19:25,040 --> 00:19:28,460 And then what you do after you do that is you go through and you fix all the bugs. 237 00:19:28,460 --> 00:19:43,560 Because every single one of those four things I talked about, the documentation, the disassembler, the object dump, the compiler, the hardware, every one of those, of course, for anybody who's done embedded development or tool development knows, every single one of those has bugs. 238 00:19:44,040 --> 00:19:51,180 So you go through and you fix your bugs and then you find other bugs that are not your bugs but are actually bugs in other tools. 239 00:19:51,180 --> 00:19:54,500 So that's kind of the process there. 240 00:19:54,500 --> 00:19:58,460 You go through and you just fix the bugs. 241 00:20:00,380 --> 00:20:01,920 But yeah, so it's not magic. 242 00:20:01,920 --> 00:20:04,060 You just start with the data. 243 00:20:04,280 --> 00:20:08,820 You go through and then in Python, you make the function. 244 00:20:08,920 --> 00:20:15,740 When you match this pattern, then you use this function to emulate it, right? 245 00:20:15,860 --> 00:20:23,140 So Aaron, he really ended up taking charge of the testing and it was incredible. 246 00:20:24,480 --> 00:20:32,000 He wrote the most versatile testing or instruction analysis framework I've seen. 247 00:20:32,000 --> 00:20:35,300 He basically rewrote an entire disassembler. 248 00:20:35,380 --> 00:20:44,200 But instead of spitting out Python objects, he spit out this metadata that he could then bend to his will going, oh, you want it represented this way? 249 00:20:44,460 --> 00:20:48,980 And boom, the unit tests started just looking a different way. 250 00:20:48,980 --> 00:20:50,920 Oh, that's how that is. 251 00:20:50,920 --> 00:20:52,660 Yeah, that's a weird thing. 252 00:20:52,660 --> 00:20:54,280 Nobody really agrees on how that works. 253 00:20:54,280 --> 00:20:55,980 So that's how Vivisect wants to do it. 254 00:20:55,980 --> 00:20:57,160 Okay, I gotcha. 255 00:20:58,000 --> 00:21:01,860 So this all goes back to the fact that it's all just bits. 256 00:21:02,140 --> 00:21:13,780 When you type a letter to your mom, when you write your report, when you download a video or a picture, that's all just bits. 257 00:21:13,920 --> 00:21:17,000 The computer system decides what to do with them. 258 00:21:17,000 --> 00:21:19,260 And our disassembler is doing the same thing. 259 00:21:19,260 --> 00:21:25,040 It takes in just a string of bytes because bytes are the easiest way for us to deal with the world. 260 00:21:26,200 --> 00:21:35,980 And then it looks at a combination of the bits and says, based on these things, that's this instruction. 261 00:21:36,100 --> 00:21:41,720 And every architecture kind of has its own nuance and its own flow for Intel. 262 00:21:41,800 --> 00:21:50,000 It goes byte by byte going, hey, this first byte puts us into this table of options for instructions. 263 00:21:50,000 --> 00:21:51,580 And oh, we hit the second byte here. 264 00:21:51,580 --> 00:21:54,960 That falls into another table of instruction options. 265 00:21:55,260 --> 00:22:00,980 ARM, it's kind of like a bunch of bit masks and comparisons. 266 00:22:01,200 --> 00:22:05,940 Take the thing, mask it with this, and compare it against this. 267 00:22:05,940 --> 00:22:06,640 Oh, it's not that? 268 00:22:06,640 --> 00:22:10,660 Okay, and it moves down the list until it finds the escape hatch. 269 00:22:10,660 --> 00:22:21,540 And then it goes down the escape hatch route when there's a match and says, okay, now pull in these bits and put them as this and that and spits out an op code with operands. 270 00:22:21,780 --> 00:22:25,800 It's pretty close to how the PowerPC stuff in VitaSec ended up. 271 00:22:25,800 --> 00:22:27,160 Lots of bit masking. 272 00:22:28,320 --> 00:22:29,360 Yes. 273 00:22:30,060 --> 00:22:39,080 With all these different instructions here, the fun thing with the VLE parts is that they've got different modes. 274 00:22:39,080 --> 00:22:44,700 They can run variable instruction mode or full 32-bit instruction mode. 275 00:22:44,920 --> 00:22:55,020 But the full 32-bit instructions don't necessarily match the real PowerPC instruction encodings either. 276 00:22:55,020 --> 00:23:00,520 So there's just a ton of different ways to do things. 277 00:23:03,300 --> 00:23:04,640 Hmm? 278 00:23:04,900 --> 00:23:05,540 Can I just look? 279 00:23:05,540 --> 00:23:06,240 Yep. 280 00:23:06,240 --> 00:23:07,440 Oh, okay. 281 00:23:11,240 --> 00:23:36,000 So ARM, if anybody's watched, if anybody's paid attention or done reversing on ARM instructions, ARM breaks things down into different modes of operation by basically jumping, address, to go from ARM to thumb mode. 282 00:23:36,300 --> 00:23:40,340 It's a simplistic way of viewing it, but basically that's it. 283 00:23:40,340 --> 00:23:47,680 So you can have ARM instructions right next to, grouped right next to a bunch of thumb instructions. 284 00:23:48,180 --> 00:23:54,380 In PowerPC with VLE, with variable length encoding, they're not the same. 285 00:23:55,240 --> 00:24:06,720 PPC and PowerPC decided to mark individual memory pages as being either VLE or straight PowerPC. 286 00:24:07,720 --> 00:24:17,600 So that was actually a push for me to wrap that into Vivisect where I'm going, this is the first time I've ever had that, where it depends on the memory page. 287 00:24:17,600 --> 00:24:35,180 We have to configure the memory pages to be either VLE or not so that when the disassembler, that's kind of dumb for all intents and purposes, it jumps to, you give it an address and it's got to spit out an instruction at you. 288 00:24:35,180 --> 00:24:37,860 It needs to know which way to decode. 289 00:24:38,280 --> 00:24:44,000 So that's just how PowerPC chose to do it. 290 00:24:44,080 --> 00:24:44,620 Sure. 291 00:24:44,620 --> 00:24:53,700 So if you, and not every single PowerPC processor supports full PowerPC, or the very VLE, maybe they do both. 292 00:24:53,700 --> 00:24:57,160 Some of them do only one or the other. 293 00:24:57,520 --> 00:24:59,940 Embedded parts, they don't have Altebec for those. 294 00:24:59,940 --> 00:25:02,160 Oh, here's another, yeah, no doubt. 295 00:25:02,160 --> 00:25:06,620 Altebec, the vector math instructions. 296 00:25:06,760 --> 00:25:19,060 Another thing is in most architectures, most embedded architectures in particular, you start out with an interrupt vector table with a reset vector in it. 297 00:25:19,060 --> 00:25:31,980 So when you power up the reset vector, however that architecture implements it, the reset vector points to an interrupt service routine or interrupt handler that starts up the processor and boots. 298 00:25:32,320 --> 00:25:36,020 And many architectures, that's like address zero. 299 00:25:38,340 --> 00:25:39,680 Not PowerPC. 300 00:25:39,680 --> 00:25:45,640 PowerPC, there's weird ways of figuring out where code should start. 301 00:25:45,640 --> 00:25:50,560 In fact, there's a boot assist module in a lot of the architectures. 302 00:25:50,640 --> 00:25:54,920 And the boot assist module is the thing that gets code execution first. 303 00:25:54,920 --> 00:26:02,420 And it just starts scouring through specific areas of the flash or hard drive or whatever you're running as your storage. 304 00:26:03,160 --> 00:26:06,080 And it looks for a signature. 305 00:26:06,900 --> 00:26:22,840 And if the signature is on the right boundary, and it knows then that somewhere a little bit later is a pointer to where instructions should start executing at power up. 306 00:26:22,980 --> 00:26:26,480 So weird things, just like all sorts of weirdness. 307 00:26:27,180 --> 00:26:34,220 For a long time, PowerPCs had the ability to change which page of memory is big-ending or little-ending. 308 00:26:35,460 --> 00:26:41,740 They call it the TLB, just a slightly more granular MMU, I guess. 309 00:26:41,740 --> 00:26:43,220 I don't know. 310 00:26:43,280 --> 00:26:47,320 Hey, at least it's not a 27-bit middle-ending architecture. 311 00:26:47,320 --> 00:26:48,660 I will give it that much. 312 00:26:49,120 --> 00:26:50,440 It could be worse. 313 00:26:52,560 --> 00:26:54,520 Yeah, I don't know. 314 00:26:54,520 --> 00:26:57,020 The documentation, boy, that was really annoying. 315 00:26:58,540 --> 00:26:59,800 What was it? 316 00:26:59,800 --> 00:27:00,920 The registers. 317 00:27:01,640 --> 00:27:06,520 It took me forever because the documentation said the registers are 64 bits. 318 00:27:06,520 --> 00:27:08,860 It's interesting for an embedded processor. 319 00:27:09,280 --> 00:27:16,000 Oh, except for when you're in VLE mode, you can't access the upper 32 bits of those registers. 320 00:27:16,960 --> 00:27:17,660 Okay. 321 00:27:17,660 --> 00:27:18,100 Fine. 322 00:27:18,100 --> 00:27:18,940 Whatever. 323 00:27:19,520 --> 00:27:25,420 Oh, by the way, they're numbered 0 to 31 as the highest, most significant bits. 324 00:27:25,620 --> 00:27:32,220 When you're talking about 32-bit mode, you're talking about 32 through 63. 325 00:27:32,220 --> 00:27:34,780 Everything is 32 through 63. 326 00:27:35,320 --> 00:27:37,260 The architecture isn't the problem. 327 00:27:37,260 --> 00:27:39,760 The people writing the freaking documentation are. 328 00:27:39,800 --> 00:27:40,860 And it's always been that way. 329 00:27:40,860 --> 00:27:42,660 You can't blame the newer stuff for that. 330 00:27:42,660 --> 00:27:44,340 It's always been that way. 331 00:27:44,660 --> 00:27:46,100 I blame IBM for that one. 332 00:27:46,100 --> 00:27:47,740 I'm betting it was them. 333 00:27:47,940 --> 00:27:48,480 I don't know. 334 00:27:48,480 --> 00:27:55,860 It reads very much like a bunch of companies in the early 90s kind of got together and eventually agreed on stuff. 335 00:27:55,860 --> 00:27:58,200 And they agreed by doing it in weird ways. 336 00:27:58,460 --> 00:28:04,100 By bringing their weird way to the table and saying you must do it this way because we did it already. 337 00:28:04,100 --> 00:28:05,060 Right, right. 338 00:28:05,580 --> 00:28:09,940 So let's do something fun here. 339 00:28:10,980 --> 00:28:11,660 Okay. 340 00:28:12,940 --> 00:28:15,500 So PowerPC is a little different. 341 00:28:15,520 --> 00:28:16,460 We're here. 342 00:28:16,460 --> 00:28:17,720 We're at DEF CON. 343 00:28:17,760 --> 00:28:20,040 We're talking about security things, right? 344 00:28:20,600 --> 00:28:22,580 How do you exploit PowerPC? 345 00:28:23,780 --> 00:28:24,620 Or no, no. 346 00:28:24,620 --> 00:28:25,140 Sorry. 347 00:28:25,360 --> 00:28:25,900 Damn it. 348 00:28:25,900 --> 00:28:26,800 I did it wrong. 349 00:28:28,240 --> 00:28:29,480 Go back a few seconds. 350 00:28:29,480 --> 00:28:31,120 Pretend I didn't say that. 351 00:28:31,580 --> 00:28:32,920 PowerPC is secure, right? 352 00:28:32,920 --> 00:28:33,680 Nobody knows the number. 353 00:28:33,680 --> 00:28:34,520 You can hack it. 354 00:28:35,380 --> 00:28:36,080 Absolutely. 355 00:28:36,080 --> 00:28:37,420 It's in Big Iron. 356 00:28:37,460 --> 00:28:38,820 Those are unhackable. 357 00:28:38,900 --> 00:28:39,760 Right, right. 358 00:28:42,320 --> 00:28:46,380 So obviously, I mean, it's not. 359 00:28:46,380 --> 00:28:48,400 It's not impossible to hack. 360 00:28:49,000 --> 00:28:50,800 You just need to do it differently. 361 00:28:52,180 --> 00:28:59,800 Every processor, it reads in data, spits out data, interprets data as instructions, as I said earlier. 362 00:28:59,840 --> 00:29:03,940 You just need to figure out the way you can tell it what's what. 363 00:29:04,000 --> 00:29:16,860 So there's no jump ESP instruction in PowerPC, unfortunately, as there's no way to branch directly to a general purpose register. 364 00:29:17,860 --> 00:29:32,440 And as the previous slide here pointed out, the stack is a general purpose register, but the link register, very much like ARM, link register, though, is a special register. 365 00:29:32,460 --> 00:29:38,460 If you go and look at the documentation for the special purpose registers in PowerPC, I mean, I don't know. 366 00:29:38,460 --> 00:29:40,020 Alice, do you remember how many? 367 00:29:40,020 --> 00:29:41,120 There's like thousands. 368 00:29:41,120 --> 00:29:42,640 Only a couple thousand. 369 00:29:43,020 --> 00:29:46,380 I don't even know what you do with all of them. 370 00:29:46,380 --> 00:29:49,800 We have a table with a lot of them in the decoder. 371 00:29:50,620 --> 00:29:51,760 There's a lot of them. 372 00:29:52,120 --> 00:29:56,400 So move to link register is actually not even an instruction. 373 00:29:56,400 --> 00:30:01,840 It's actually move to SPR with LR as an operand. 374 00:30:01,840 --> 00:30:02,900 That's true. 375 00:30:02,900 --> 00:30:08,660 Move MTSPR 1, LR. 376 00:30:09,180 --> 00:30:14,800 MTLR is a mnemonic that some assemblers allow. 377 00:30:15,020 --> 00:30:16,480 Now, we like that. 378 00:30:16,480 --> 00:30:19,160 It's intuitively pleasing. 379 00:30:19,160 --> 00:30:22,480 But I'm just saying that's how the architecture breaks down. 380 00:30:22,920 --> 00:30:23,480 Yep. 381 00:30:24,420 --> 00:30:24,940 Yeah. 382 00:30:24,940 --> 00:30:26,280 So move to link register. 383 00:30:26,380 --> 00:30:28,980 Link register is, of course, where you return to. 384 00:30:29,700 --> 00:30:35,040 Again, like ARM, you store the value place you came from on the link register. 385 00:30:35,140 --> 00:30:40,560 And when you need to return to it, it loads an address back into the link register. 386 00:30:40,580 --> 00:30:51,440 Well, if you can make some, whatever that was stored on the stack, if you can modify that address on the stack, you can jump back to where you want it to go to, not where it's supposed to go. 387 00:30:51,820 --> 00:30:53,620 Account register is a weird one. 388 00:30:54,160 --> 00:31:00,200 Account register in PowerPC is used for a lot of jump tables and function pointers. 389 00:31:01,340 --> 00:31:02,440 So that's another one. 390 00:31:02,440 --> 00:31:05,340 You could just modify that and get hold of a switch statement. 391 00:31:06,840 --> 00:31:10,080 So nice little rock gadgets here. 392 00:31:10,160 --> 00:31:10,480 Yeah. 393 00:31:10,900 --> 00:31:13,600 I wanted to put some fun in here, you know? 394 00:31:15,040 --> 00:31:16,980 I love that you consider that fun. 395 00:31:17,480 --> 00:31:18,560 Right. 396 00:31:18,840 --> 00:31:19,860 Right. 397 00:31:20,260 --> 00:31:21,820 This was not as fun. 398 00:31:21,820 --> 00:31:23,240 This is not so fun. 399 00:31:24,920 --> 00:31:38,380 If you go and look at, I'd say, I don't know, probably two thirds or so, 66% of all bugs in all PowerPC tools are related to this instruction. 400 00:31:39,140 --> 00:31:40,960 Wait, that's one instruction? 401 00:31:41,320 --> 00:31:43,380 Yeah, it's one instruction, right? 402 00:31:44,380 --> 00:31:46,140 Actually, no, this isn't one instruction. 403 00:31:46,140 --> 00:31:48,300 It's only a couple. 404 00:31:48,300 --> 00:31:50,340 Two or three, whatever. 405 00:31:50,340 --> 00:31:51,180 It doesn't matter. 406 00:31:51,180 --> 00:31:52,760 There's these rotate instructions. 407 00:31:53,600 --> 00:31:56,940 Rotate left with bullshit. 408 00:31:57,640 --> 00:31:58,900 That's what I read there. 409 00:31:58,900 --> 00:31:59,900 Rotate left. 410 00:31:59,900 --> 00:32:00,800 Word. 411 00:32:00,940 --> 00:32:01,880 Immediate. 412 00:32:01,880 --> 00:32:02,980 Thing. 413 00:32:03,060 --> 00:32:03,920 This one. 414 00:32:03,920 --> 00:32:04,940 This one, right? 415 00:32:08,020 --> 00:32:12,480 Unfortunately, this Twitter account didn't tweet for very long. 416 00:32:14,620 --> 00:32:19,720 But it's really interesting to, as you say, nerds like me. 417 00:32:20,700 --> 00:32:22,180 We don't need to make it up, though. 418 00:32:22,180 --> 00:32:25,500 I mean, they included the EIEIO instruction. 419 00:32:25,500 --> 00:32:26,600 Yes. 420 00:32:26,600 --> 00:32:31,000 I mean, that's dropping the mic for instruction lunacy. 421 00:32:31,020 --> 00:32:31,900 Right. 422 00:32:32,320 --> 00:32:37,120 So, I don't have much time left in the talk, unfortunately. 423 00:32:37,120 --> 00:32:38,580 A little bit. 424 00:32:39,340 --> 00:32:40,660 Go ahead. 425 00:32:40,780 --> 00:32:48,100 Should move, probably move it along instead of making jokes about PowerPC instructions, as much fun as that is for me, anyway. 426 00:32:48,620 --> 00:32:49,600 Yep. 427 00:32:50,220 --> 00:32:53,040 Oh, hey, we're to story time. 428 00:32:53,040 --> 00:32:54,740 Story time with Atlas. 429 00:32:55,740 --> 00:33:03,180 So, we do a lot of work with a lot of people that we care very deeply for. 430 00:33:03,240 --> 00:33:09,040 And so, there's stuff that we have, but we can't use it for a talk. 431 00:33:09,040 --> 00:33:17,760 So, we were scouring the internet for something that we could show and not have to make anybody uncomfortable. 432 00:33:17,760 --> 00:33:26,780 We ended up finding a repository of a whole bunch of automotive code on some sketchy website. 433 00:33:26,780 --> 00:33:34,240 So, downloaded a bunch of things that I could identify as something potentially PowerPC. 434 00:33:35,380 --> 00:33:40,760 And thankfully, I threw one in Vivisect. 435 00:33:40,760 --> 00:33:43,960 And it's just a blob at this point. 436 00:33:43,960 --> 00:33:46,180 So, this is a VBF. 437 00:33:46,320 --> 00:33:53,900 VBF is basically a file package, almost a file format. 438 00:33:53,900 --> 00:33:54,500 Not really. 439 00:33:54,500 --> 00:33:58,020 It starts off with a couple headers and then goes to binary code. 440 00:33:59,080 --> 00:34:11,740 So, I slapped in a VBF into Vivisect, and I just started scouring around what things were. 441 00:34:11,740 --> 00:34:16,260 And thankfully, the very first one I loaded in, I guessed well. 442 00:34:16,260 --> 00:34:21,160 And I hit decode, or I hit C for make code. 443 00:34:21,380 --> 00:34:31,980 And I got a branch instruction followed by three NOPs, another branch instruction, followed by three NOPs, and a repeating pattern. 444 00:34:31,980 --> 00:34:36,960 There are like a thousand of these in this firmware. 445 00:34:39,060 --> 00:34:42,200 But it could have been just a weird repeating pattern. 446 00:34:42,200 --> 00:34:45,300 So, I wasn't going to bank on that. 447 00:34:45,980 --> 00:34:48,460 So, I started looking through. 448 00:34:48,460 --> 00:34:49,420 What's that, Aaron? 449 00:34:49,420 --> 00:34:51,240 Oh, I just wanted to interject here. 450 00:34:51,240 --> 00:34:59,020 For those of us who have been done PowerPC programming, this type of pattern is extremely common. 451 00:34:59,360 --> 00:35:04,120 PowerPC lines up every interrupt handler, every... 452 00:35:05,180 --> 00:35:06,120 what's that? 453 00:35:06,120 --> 00:35:07,340 64 bytes? 454 00:35:07,340 --> 00:35:08,100 No. 455 00:35:08,100 --> 00:35:09,380 148 bytes? 456 00:35:09,440 --> 00:35:10,320 Whatever. 457 00:35:10,420 --> 00:35:12,060 And that's very common. 458 00:35:12,060 --> 00:35:16,600 Of course, you'll need this many instructions to handle your interrupts. 459 00:35:16,600 --> 00:35:23,620 So, the thing that made me queasy and, well, it made me uncertain was that this is not a full firmware image. 460 00:35:23,620 --> 00:35:41,020 This is something that an ECU would basically have its own base image because if you have a firmware upgrade go bad, you don't want to lose your CAN interface, for example, because that's how you flash firmware. 461 00:35:41,020 --> 00:35:55,040 So, they have a core bootloader base image that gets the device on the CAN network and accesses, you know, allows access through the various tooling and protocols. 462 00:35:55,480 --> 00:36:06,260 And so, I knew that that was going to own the interrupt service routines and the interrupt vector table and anything that would be normally things I would go looking for in a piece of firmware. 463 00:36:06,860 --> 00:36:09,020 That wasn't in this. 464 00:36:09,120 --> 00:36:12,200 This was going to be something else. 465 00:36:12,200 --> 00:36:34,540 So, I saw this and I thought, it could be PowerPC and this could be a branch table that is indexed so that the base firmware knows, hey, this index at this address just go, boom, there's the thing and the rest of the firmware handles it, the new firmware that we've just installed. 466 00:36:34,540 --> 00:36:41,200 Or it could be some crazy other architecture that has nothing to do with PowerPC. 467 00:36:41,200 --> 00:36:48,780 You can never be certain unless you actually know and the VBF file in its text comment didn't have anything about what architecture. 468 00:36:49,220 --> 00:36:53,100 Plus, there's this architecture I keep running into that I don't know much about. 469 00:36:53,100 --> 00:37:02,880 Aaron, you know more about it, TriCore, that I haven't done enough reversing on to actually know if I would identify it. 470 00:37:03,780 --> 00:37:07,180 So, I was still kind of skeptical. 471 00:37:07,180 --> 00:37:08,460 So, next slide, Aaron. 472 00:37:08,460 --> 00:37:09,260 Yep. 473 00:37:10,900 --> 00:37:24,500 So, I right-click on the first address that it's being branched to and I send the target, the 4250C address, over to another analysis window. 474 00:37:24,500 --> 00:37:25,840 So, this is the VIV window. 475 00:37:25,840 --> 00:37:29,640 I've created another memory viewer called foo. 476 00:37:29,640 --> 00:37:30,360 Why? 477 00:37:30,360 --> 00:37:32,720 Because foob are best. 478 00:37:37,080 --> 00:37:44,580 So, anyway, I think I threw this in out of order. 479 00:37:44,580 --> 00:37:45,380 Sorry. 480 00:37:46,160 --> 00:37:50,020 So, here's like you can see that backup one. 481 00:37:50,260 --> 00:37:51,460 One slide. 482 00:37:51,460 --> 00:37:54,500 So, we start at 40,000 hex. 483 00:37:54,500 --> 00:37:57,160 So, that's a lot bigger than 40,000. 484 00:37:57,160 --> 00:37:58,900 But anyway, 40,000 hex. 485 00:37:58,900 --> 00:38:00,640 Scroll forward one. 486 00:38:01,640 --> 00:38:05,980 And we're still doing this table thing. 487 00:38:06,220 --> 00:38:12,540 1,300 hex into this firmware. 488 00:38:12,540 --> 00:38:17,300 And that is 130 hex options. 489 00:38:18,940 --> 00:38:25,240 So, far, just 130 hex different branch options. 490 00:38:25,240 --> 00:38:25,440 Okay. 491 00:38:25,440 --> 00:38:26,560 Now, next. 492 00:38:27,740 --> 00:38:29,860 So, we follow the location. 493 00:38:30,680 --> 00:38:32,400 And here's what they point at. 494 00:38:32,520 --> 00:38:40,200 Another table of branches that some of them point to the same thing. 495 00:38:40,200 --> 00:38:44,220 And as you can see, so, they're branching to location 43228. 496 00:38:44,820 --> 00:38:51,960 And you'll notice that the bytes that make up those instructions are not the same. 497 00:38:51,960 --> 00:38:55,680 It's not like boom, boom, boom, boom, boom, a table of all the same thing repeated. 498 00:38:55,820 --> 00:38:59,180 It's all the same thing, but these are relative branches. 499 00:38:59,180 --> 00:39:01,860 So, the numbers decrease as they go higher. 500 00:39:02,500 --> 00:39:13,940 So, the fact that each of those points at 43228 gives me a clue that this might actually it's getting more likely that this is PowerPC firmware. 501 00:39:14,460 --> 00:39:17,020 I mean, it's easy to just look at this. 502 00:39:17,020 --> 00:39:20,500 You'll start looking at those values that make up those instructions. 503 00:39:20,500 --> 00:39:28,420 It almost looks like this is just, you know, a bunch of, you know, sequential memory addresses or something like that. 504 00:39:28,420 --> 00:39:29,500 It's very weird. 505 00:39:31,500 --> 00:39:32,280 Yep. 506 00:39:32,280 --> 00:39:32,520 Okay. 507 00:39:32,520 --> 00:39:33,260 Next. 508 00:39:34,020 --> 00:39:38,360 Until we run into hex 43,000. 509 00:39:38,800 --> 00:39:43,080 And at hex 43,000, we start to see real instructions. 510 00:39:43,080 --> 00:39:47,800 Now, many architectures, you give them four bytes, they can spit out an instruction. 511 00:39:47,800 --> 00:39:50,440 So, this does not mean that it's PowerPC. 512 00:39:52,300 --> 00:39:59,780 But we see these things peppered throughout a little bit of the previous table where everything was pointing to one location. 513 00:40:00,980 --> 00:40:11,280 And then after a bunch of them, we run into move to SPR, SPR G0, and we move from R3 into that. 514 00:40:11,280 --> 00:40:11,760 Okay. 515 00:40:11,860 --> 00:40:19,680 And then we move from SPR counter, the counter register, into R3. 516 00:40:19,700 --> 00:40:26,140 So, we've stored R3 and then we put the counter into the counter register value into R3. 517 00:40:26,140 --> 00:40:31,500 And then we move to the SPR G1 from R3. 518 00:40:31,500 --> 00:40:31,800 Okay. 519 00:40:32,680 --> 00:40:34,320 Could be logical. 520 00:40:34,760 --> 00:40:35,300 Okay. 521 00:40:35,300 --> 00:40:39,820 Load immediate shifted zero into R3. 522 00:40:39,820 --> 00:40:45,820 So, we're not overwriting anything that we've just put into R3 without storing R3. 523 00:40:45,820 --> 00:40:46,500 So, okay. 524 00:40:46,500 --> 00:40:48,300 Sanity still exists. 525 00:40:49,300 --> 00:40:52,300 Load word zero extended. 526 00:40:52,300 --> 00:40:53,840 I think that's what that means. 527 00:40:53,840 --> 00:40:56,620 Although, I've been having to look up a lot of words. 528 00:40:57,520 --> 00:40:58,080 Okay. 529 00:40:58,760 --> 00:41:06,980 So, we take R3 and yeah, anyway, you're seeing the pattern. 530 00:41:07,300 --> 00:41:09,660 Things are actually starting to make sense. 531 00:41:09,660 --> 00:41:13,440 And after doing things with R3, we then move it into the counter register. 532 00:41:14,400 --> 00:41:18,380 We load immediate zero into register three. 533 00:41:18,380 --> 00:41:22,900 So, we wipe out, we clear R3 again, and then we branch to counter. 534 00:41:22,900 --> 00:41:23,260 Okay. 535 00:41:23,260 --> 00:41:24,580 That makes sense. 536 00:41:25,080 --> 00:41:29,640 That actually is a chunk of code that makes sense to me. 537 00:41:31,600 --> 00:41:35,280 After that, so branch with counter, that's the end of a code block. 538 00:41:35,800 --> 00:41:37,600 Because there's no branch with a link. 539 00:41:37,600 --> 00:41:38,400 There's no return. 540 00:41:38,400 --> 00:41:38,860 No nothing. 541 00:41:38,860 --> 00:41:39,900 It just goes somewhere. 542 00:41:40,540 --> 00:41:43,560 After that, though, we see STWU. 543 00:41:43,560 --> 00:41:45,520 No, that's not shut the what up. 544 00:41:47,840 --> 00:41:52,440 And this, man, I captured the pointer right in front of that. 545 00:41:52,500 --> 00:41:53,620 Right in front of that. 546 00:41:53,620 --> 00:41:57,060 Anyway, that's actually part of a function prologue. 547 00:41:57,060 --> 00:42:01,140 A very standard function prologue for RPC. 548 00:42:01,220 --> 00:42:02,360 So, R1. 549 00:42:02,520 --> 00:42:05,680 R1 is a stack pointer, right? 550 00:42:05,680 --> 00:42:10,020 So, this is moving the stack pointer. 551 00:42:10,540 --> 00:42:11,320 Yep. 552 00:42:11,460 --> 00:42:24,080 Basically storing the stack pointer and storing register 0, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12 into the stack. 553 00:42:24,140 --> 00:42:27,600 So, we create stack space and then we write registers into it. 554 00:42:27,600 --> 00:42:28,500 Okay. 555 00:42:28,580 --> 00:42:29,920 That sounds legit. 556 00:42:29,920 --> 00:42:35,040 The PowerPC calling convention includes handing arguments as registers. 557 00:42:36,060 --> 00:42:40,440 And you got to clean up after yourself when you're done. 558 00:42:40,440 --> 00:42:45,700 So, storing the registers that aren't arguments totally makes sense. 559 00:42:46,300 --> 00:42:50,360 Move from SPR, the link register into R0. 560 00:42:50,360 --> 00:42:50,520 Okay. 561 00:42:50,520 --> 00:42:55,580 So, our link register now, the return address now lives in R0. 562 00:42:56,160 --> 00:42:57,780 And then, okay. 563 00:42:57,780 --> 00:42:59,160 I'm convinced. 564 00:42:59,160 --> 00:43:00,420 This is PowerPC. 565 00:43:01,260 --> 00:43:02,600 So, next? 566 00:43:02,740 --> 00:43:18,040 Well, from the point of view of somebody who's written RPC for embedded systems, SR0, SR1 down at the bottom there, those are special purpose registers that are the system state, system control registers, telling you, like, what your current state is. 567 00:43:18,400 --> 00:43:28,160 The stuff up at the top of this, this was taking a look at SPRG0 and G1, I believe are... oh, boy. 568 00:43:28,160 --> 00:43:28,940 It's been too long. 569 00:43:28,940 --> 00:43:30,600 I probably shouldn't say anything. 570 00:43:31,040 --> 00:43:38,300 Anyway, what it looks like to me is it looks like it's saying what address caused the particular interrupt. 571 00:43:38,300 --> 00:43:40,000 Why are we here? 572 00:43:40,220 --> 00:43:40,740 Right? 573 00:43:40,740 --> 00:43:49,120 And then, it's looking up, it's doing a calculation based on R3, which is, I guess, zero, right? 574 00:43:49,120 --> 00:43:50,300 So, it's jumping. 575 00:43:50,300 --> 00:43:55,240 For some reason, doing a jump calculation to one specific address. 576 00:43:55,280 --> 00:43:59,580 This LIS... I keep pointing my screen, like people can see what I'm pointing at. 577 00:43:59,580 --> 00:44:00,420 I can't help it. 578 00:44:00,420 --> 00:44:01,960 Make sure you're pointing at the camera. 579 00:44:01,960 --> 00:44:02,580 At the camera? 580 00:44:02,580 --> 00:44:03,020 Right. 581 00:44:03,020 --> 00:44:07,160 So, LIS, LW, those are very common for PowerPC. 582 00:44:07,240 --> 00:44:15,880 It's also something that a lot of first engineering tools have issues with, because this is PowerPC fixed instruction work. 583 00:44:15,880 --> 00:44:18,700 You can't have a 32-bit address in one instruction. 584 00:44:18,700 --> 00:44:25,200 You've got to have two, so it's lower 16, and then low, the upper 16 bits. 585 00:44:25,340 --> 00:44:26,120 Right. 586 00:44:27,140 --> 00:44:39,900 Which is very common in any fixed width instruction architecture, because, turns out, the register size typically is the same as the instruction size. 587 00:44:39,900 --> 00:44:43,860 So, try loading the full value into a register in one instruction. 588 00:44:43,860 --> 00:44:53,620 It's impossible, unless you store the value and somehow dereference some other address to load it into a register, which ARM does, actually, all the time. 589 00:44:54,700 --> 00:44:55,140 Okay. 590 00:44:55,140 --> 00:44:59,840 So, I wanted to throw in an interesting thing. 591 00:44:59,840 --> 00:45:08,080 There's so many different details that make Vivisective fun and exciting reversing platform. 592 00:45:08,660 --> 00:45:13,820 Part of it is that there are many things that are not hidden from you. 593 00:45:14,380 --> 00:45:29,100 So, one of the things that Vivisect does for branch analysis, for switch case analysis, for example, most often, a switch case turns into one or more dynamic branches. 594 00:45:29,740 --> 00:45:37,420 So, if you've got, let's say, switch on this variable being 1, 2, 3, 4, and 5. 595 00:45:37,420 --> 00:45:37,740 Okay. 596 00:45:37,740 --> 00:45:45,440 Those are, those different options are going to be stored as pointers to the code that handles each of those options. 597 00:45:45,860 --> 00:45:53,820 And then indexing into a table to grab the address to then branch right into that. 598 00:45:53,820 --> 00:45:54,740 That's a dynamic branch. 599 00:45:54,740 --> 00:45:59,280 You cannot figure out where that branch is supposed to go without an emulator. 600 00:46:01,160 --> 00:46:05,540 Or a lot of emulation written down into code that's not an emulator. 601 00:46:06,340 --> 00:46:15,620 There's also a lot of things like C++ method invocation. 602 00:46:15,620 --> 00:46:28,200 When you've got multiple inheritance with virtual function tables, you basically have a table that lists each type of call. 603 00:46:28,200 --> 00:46:39,720 So, an object called ball, and I have a method, get color, bounce, throw in the trash, throw at my sister. 604 00:46:40,000 --> 00:46:45,080 These are all method calls that go into a virtual function table. 605 00:46:45,080 --> 00:47:00,660 And so, when executing any of those, actually, the code goes, okay, grab my virtual function table and index into that virtual function table and then call, make the desired call. 606 00:47:00,980 --> 00:47:15,980 And since all of this is done on heap, typically heap objects that just have a pointer to a virtual function table, there's no way that the code can just say, this is a foo call that goes to this address location. 607 00:47:16,460 --> 00:47:19,480 At least not when virtual function tables are involved. 608 00:47:19,480 --> 00:47:29,280 So, we get, as part of the process, Vivisect stores all dynamic branches in what's called a VA set, or a virtual address set. 609 00:47:29,280 --> 00:47:33,600 And virtual address sets are nothing more than analysis tools. 610 00:47:34,000 --> 00:47:49,600 It just happens to be an analysis tool that Vivisect then makes use of, but I get to make use of it as well, where I can just list all the dynamic branches through that has been updated as code flow analysis happens. 611 00:47:49,780 --> 00:47:55,700 And then, turns out, dynamic branches are very, very interesting things. 612 00:47:55,700 --> 00:48:00,680 They tell a ton about what's going on with the code. 613 00:48:01,200 --> 00:48:12,520 Typically, making sense of assembly instructions is not typically terribly hard. 614 00:48:12,540 --> 00:48:15,300 Spark notwithstanding. 615 00:48:16,220 --> 00:48:17,360 Just kidding. 616 00:48:18,920 --> 00:48:28,320 However, finding in this massive, maybe four megabytes of firmware, what things are interesting, that can be hard. 617 00:48:29,180 --> 00:48:30,900 And I love doing this. 618 00:48:30,900 --> 00:48:37,820 I could do this all day long, and I could work myself right out of a marriage, and right out of my kids' lives, and right out of a job. 619 00:48:38,460 --> 00:48:52,220 But if I want to do the things that I love, including being a dad, being a husband, riding a motorcycle, and hacking, then I need to be able to focus in very easily, quickly on interesting things. 620 00:48:52,320 --> 00:48:54,220 And so that's why I threw this in there. 621 00:48:54,220 --> 00:48:56,240 Dynamic branch handling is very interesting. 622 00:48:56,240 --> 00:49:08,560 And of course, these are a bunch of branch to control, or I'm sorry, branch to the counter register with link, which means it's a call, not a straight branch. 623 00:49:08,560 --> 00:49:14,900 So things are expected to, this instruction. 624 00:49:15,560 --> 00:49:26,240 So that's very likely, that could very well be C++ stuff, or it could be function pointers, or whatnot. 625 00:49:26,240 --> 00:49:28,400 So either way, it's very interesting. 626 00:49:29,680 --> 00:49:30,560 I'm done if you... 627 00:49:31,620 --> 00:49:32,160 Okay. 628 00:49:36,650 --> 00:49:46,730 So I was just poking through this, one of the firmwares that I was looking at for this presentation. 629 00:49:47,510 --> 00:49:51,550 And of course, I was looking at the dynamic branches. 630 00:49:51,810 --> 00:49:53,050 And here's one. 631 00:49:53,170 --> 00:49:54,990 This was an oddity. 632 00:49:57,070 --> 00:49:59,330 I mean, it actually wasn't an oddity. 633 00:49:59,330 --> 00:50:00,730 It struck me weird. 634 00:50:00,870 --> 00:50:02,030 But I'm just looking at it. 635 00:50:02,030 --> 00:50:06,050 And in this code block, if you're not familiar, this is a code flow graph. 636 00:50:06,750 --> 00:50:20,770 It's a great way to display assembly language code for humans that don't want to sit with a linear look and draw arrows to where code flow happens. 637 00:50:20,770 --> 00:50:23,570 It just kind of flows naturally. 638 00:50:23,970 --> 00:50:30,250 So in the code block in the middle, there's a discrete code block. 639 00:50:30,250 --> 00:50:38,510 And it looks like we are loading values into the R12 register. 640 00:50:39,650 --> 00:50:43,330 And then we're moving the R12 register data into the counter register. 641 00:50:43,330 --> 00:50:45,970 And then we're branching to the counter register with link. 642 00:50:45,970 --> 00:50:50,370 We're calling whatever is at this thing that we're loading into R12. 643 00:50:52,310 --> 00:50:56,370 So I'm going, hmm, how's that work? 644 00:50:56,370 --> 00:51:02,110 And I'm wanting to make sure that I understand what's going on. 645 00:51:02,110 --> 00:51:06,430 So I walk through and I'm like, okay, load immediate shift. 646 00:51:06,430 --> 00:51:07,390 That loads 647 00:51:10,790 --> 00:51:14,690 basically 40000 into R12. 648 00:51:14,690 --> 00:51:18,970 So the shift means shifted 16 bits. 649 00:51:19,170 --> 00:51:22,870 And then load word. 650 00:51:22,870 --> 00:51:27,750 Word is 16 bits with zero extension. 651 00:51:28,730 --> 00:51:33,390 That 4 with parentheses around R12. 652 00:51:33,390 --> 00:51:39,470 Now, when I first thought it, I'm going, that's not, I didn't actually, I got it wrong. 653 00:51:39,470 --> 00:51:41,010 I'll just say it. 654 00:51:41,550 --> 00:51:51,250 And I said, okay, that's going to say 40000 plus 4 is going to be 4004. 655 00:51:52,830 --> 00:51:53,890 Okay. 656 00:51:55,110 --> 00:51:57,490 That's not what ends up in R12. 657 00:51:57,590 --> 00:51:59,230 But that's what I thought. 658 00:51:59,230 --> 00:52:00,190 Next. 659 00:52:00,670 --> 00:52:02,730 So I went there. 660 00:52:02,850 --> 00:52:06,370 And I thought, okay, let's see what that's doing. 661 00:52:07,970 --> 00:52:12,090 40004, it has, let's look at the first four bytes. 662 00:52:13,950 --> 00:52:15,150 000D5C20. 663 00:52:15,710 --> 00:52:19,910 VimSec has a preview instruction option. 664 00:52:20,190 --> 00:52:26,630 It's control P from the keyboard to use the already selected architecture. 665 00:52:26,630 --> 00:52:34,890 But I wanted to show you, so I right clicked and the context menu said preview instruction, because it's not anything right now. 666 00:52:36,790 --> 00:52:41,050 That only shows up if it's not decoded as anything. 667 00:52:41,410 --> 00:52:45,570 And then I get to pick the platform, and I chose PPC embedded, PowerPC embedded. 668 00:52:47,030 --> 00:52:49,430 I don't know if you can hear the lightning. 669 00:52:51,890 --> 00:52:52,310 Okay. 670 00:52:52,310 --> 00:52:56,970 So I click on that, and I did it three times, because, you know, once isn't enough. 671 00:52:56,970 --> 00:53:01,830 And each time I got a decode exception, I'm going, uh-oh, crap, I've got a bug. 672 00:53:01,830 --> 00:53:06,510 I've got to go figure out why this is not working. 673 00:53:07,770 --> 00:53:12,530 And so next, remember, 40004. 674 00:53:13,010 --> 00:53:20,070 So I loaded up a tool that I built a long time ago, and it has only become more dear to me. 675 00:53:20,930 --> 00:53:32,170 I used this tooling to reverse engineer a lot of different things with VimSec, and actually it found its way into a Deliverable one time. 676 00:53:33,790 --> 00:53:46,010 But this is part of the Atlas Utils tool belt, which I think I started as a Perl, a library of Perl, way back in 2006, 2005, 2006. 677 00:53:46,010 --> 00:53:47,530 It was crazy. 678 00:53:48,030 --> 00:53:52,810 Made the switch to Python, and just kept adding to it. 679 00:53:52,810 --> 00:53:55,210 Basically, I'll make no bones. 680 00:53:55,210 --> 00:53:59,690 It's a pile of steaming shit code that you may not want to read. 681 00:53:59,690 --> 00:54:03,030 But I found it to be exceedingly useful. 682 00:54:03,030 --> 00:54:04,230 So I share it. 683 00:54:04,230 --> 00:54:06,110 Please don't hate me for it. 684 00:54:06,670 --> 00:54:22,110 So I created a thing called an MUtils package, which was based around originally VDB and VTrace, the tracing library underneath that makes VDB work. 685 00:54:22,390 --> 00:54:27,970 But I really ended up using it a lot for emulators. 686 00:54:27,970 --> 00:54:30,410 So VimSec makes emulators available. 687 00:54:30,510 --> 00:54:34,690 In fact, I'm using right here what's called a workstation emulator. 688 00:54:35,110 --> 00:54:39,610 And workstation emulators come with some special sauce. 689 00:54:40,010 --> 00:54:44,190 For example... all right, I'm unplugging the laptop now. 690 00:54:44,590 --> 00:54:54,230 Special sauce here, you'll see weird entries for R0, R2, R3, R4, R5, R6, blah, blah, blah, blah. 691 00:54:54,230 --> 00:55:15,690 And basically what that is, workspace emulator, when it first wraps in the concepts of memory, registrar, and instruction emulation, the workspace emulator goes a little further and it says, I'm going to do taint tracking on all the argument or all the registers that could possibly be arguments. 692 00:55:15,770 --> 00:55:25,110 So it just takes and puts specialized numbers into each of those locations that will then trace through code. 693 00:55:25,110 --> 00:55:37,430 And we'll be able to see if any uninitialized registers are accessed before assigning values to them. 694 00:55:37,430 --> 00:55:44,570 Because that could mean either an uninitialized variable, or it could mean that that's an argument. 695 00:55:44,570 --> 00:55:52,230 So we use this to identify calling convention and to do other various analysis. 696 00:55:52,630 --> 00:55:59,010 So the first instruction is a load immediate shift of 4 into R12. 697 00:55:59,010 --> 00:56:00,950 So 4, 0, 0, 0, 0. 698 00:56:01,910 --> 00:56:03,630 You can see that at the bottom. 699 00:56:03,650 --> 00:56:05,570 In fact, hold on, back up, Aaron. 700 00:56:05,690 --> 00:56:15,250 One of the things I love, again, it's really ugly code that I take no pride in, but I take pride in the results. 701 00:56:15,250 --> 00:56:19,890 You'll see that I print out a whole bunch of interesting registers for each instruction. 702 00:56:19,890 --> 00:56:21,510 And that's kind of how I am with GDB, too. 703 00:56:21,510 --> 00:56:28,230 I like dump all the things, and this is actually a lot better than doing info register after every instruction. 704 00:56:28,370 --> 00:56:35,170 But then the Emutils throws in anything that could be a dereference. 705 00:56:35,170 --> 00:56:39,890 It prints out some context around that data. 706 00:56:40,010 --> 00:56:43,730 So let's see. 707 00:56:43,730 --> 00:56:54,530 We're looking at memory location address 4, and I think that's because I don't actually... oh, because we have the number 4. 708 00:56:54,530 --> 00:56:57,150 So it says, oh, okay, there's an immediate 4 here. 709 00:56:57,150 --> 00:56:58,030 That could be an address. 710 00:56:58,030 --> 00:57:02,990 So let's kind of look at that, because memory address 4 is valid in this case. 711 00:57:03,390 --> 00:57:03,970 Okay. 712 00:57:04,010 --> 00:57:13,990 So next... so the next instruction is, oh, we see highlighted here, R12, and I'm moving my mouse pointer around R12 right now. 713 00:57:13,990 --> 00:57:15,050 Thanks, Aaron. 714 00:57:16,530 --> 00:57:18,350 So R12 shows up. 715 00:57:18,350 --> 00:57:18,750 Okay. 716 00:57:18,750 --> 00:57:20,350 4, 0, 0, 0, 0. 717 00:57:20,350 --> 00:57:21,110 Cool. 718 00:57:21,950 --> 00:57:32,110 But one of the things that I love about emulators and disassembler, or in debuggers, is that they teach me so much about an architecture, and they correct me all the time. 719 00:57:32,790 --> 00:57:40,150 So the next instruction is that LWZ R12 4 with parentheses wrapped around R12. 720 00:57:40,150 --> 00:57:40,510 Okay. 721 00:57:40,510 --> 00:57:41,730 What's that do? 722 00:57:42,330 --> 00:57:47,590 I think that should create an address 4, 0, 0, 0, 4. 723 00:57:49,330 --> 00:57:50,510 Yep. 724 00:57:50,510 --> 00:57:59,010 And by the way, as you can see, it registers, and then it prints out the value of what's at 4, 0, 0, 0, 0, 0. 725 00:57:59,250 --> 00:58:06,310 It then prints out some context data around D5C20. 726 00:58:06,570 --> 00:58:08,430 No idea why. 727 00:58:08,910 --> 00:58:09,470 Okay. 728 00:58:09,470 --> 00:58:10,130 I do. 729 00:58:10,130 --> 00:58:11,470 Spoiler alert, though. 730 00:58:11,970 --> 00:58:13,550 4, 0, 0, 0, 4. 731 00:58:13,550 --> 00:58:13,950 Okay. 732 00:58:13,950 --> 00:58:14,950 Oh, that's it. 733 00:58:14,950 --> 00:58:21,210 I must... this must add 4 to 440,000 hex. 734 00:58:21,410 --> 00:58:23,730 And so it's printing off... oh, wait. 735 00:58:23,730 --> 00:58:30,150 4,000... 40,004 starts off with D5C20. 736 00:58:30,350 --> 00:58:31,090 Huh. 737 00:58:31,090 --> 00:58:32,330 So hit enter. 738 00:58:34,780 --> 00:58:35,580 Okay. 739 00:58:35,580 --> 00:58:40,740 So that instruction updated R12, and it put D5C20. 740 00:58:40,740 --> 00:58:52,200 See, the thing that I was forgetting is that the integer followed by parentheses and a register in it isn't the addition of the two things together. 741 00:58:52,460 --> 00:58:57,560 It is actually adding them together and using that as a memory dereference point. 742 00:58:57,620 --> 00:59:09,860 So it went to 40,004, and it grabbed a pointer there, and it put it into the register because D5C20 is actually the location of code. 743 00:59:09,860 --> 00:59:16,160 So if I go to D5C20, I'm going to be able to decode code, or it may already be decoded. 744 00:59:16,320 --> 00:59:19,900 So we move R12 into counter, and then we branch. 745 00:59:20,580 --> 00:59:21,340 Okay. 746 00:59:21,340 --> 00:59:28,420 And we don't have time to really talk much about... actually, we are out of time. 747 00:59:28,420 --> 00:59:32,960 I don't have time to talk about Symbolics much today, but that's coming. 748 00:59:33,080 --> 00:59:35,140 But I did want to throw this at you. 749 00:59:35,220 --> 00:59:41,280 Right-clicking, I have a Symbolics window up, and so I send that address to Symbolic zero. 750 00:59:41,280 --> 00:59:42,340 That's the window. 751 00:59:43,700 --> 01:00:02,620 And this is probably a lot to digest, and the idea is to reduce things down to make programmatic analysis easier, but this view is a way for making Symbolics valuable to the reverse engineer that's using the GUI. 752 01:00:02,740 --> 01:00:17,300 And as you can see, at 24,104, that address that you'll see highlighted on the left in yellow, because when we get into Symbolics view, we have to pick a path through code. 753 01:00:17,480 --> 01:00:22,680 And we can direct it some, but we have to pick a particular path to make sense. 754 01:00:23,500 --> 01:00:30,680 And so for that path, it then highlights all the instructions in yellow that are in that path. 755 01:00:30,680 --> 01:00:38,180 So as I scroll through the different paths, those yellow backgrounded things will change. 756 01:00:38,520 --> 01:00:53,480 But as you see highlighted down here, I've shown that it's the memory dereference of 40,004, four bytes long, that is used as a pointer to call a function. 757 01:00:53,480 --> 01:00:55,560 And then the arguments are listed here. 758 01:00:55,560 --> 01:00:59,360 And you'll notice some of these, the cascades. 759 01:00:59,360 --> 01:01:03,260 So up above, you've got 23C60 as a call. 760 01:01:03,260 --> 01:01:08,220 The results of that are then used in various different things throughout the analysis. 761 01:01:08,940 --> 01:01:11,480 And with that, I think we're about done. 762 01:01:11,840 --> 01:01:16,040 Yeah, we're kind of out of time here, but we can probably leave it up on that for a bit. 763 01:01:16,400 --> 01:01:20,120 Yeah, well, let's let's take a second and talk about future, just for future. 764 01:01:22,340 --> 01:01:31,300 So PowerPC is huge in a lot of areas that are kind of not getting a lot of attention by security researchers, at least not publicly. 765 01:01:31,880 --> 01:01:41,300 So we're using this as a launching point to do reversing and analysis of IBM and embedded things. 766 01:01:42,360 --> 01:01:48,700 So the IBMI and the P-series, the power stuff. 767 01:01:51,140 --> 01:01:58,760 And this is going to make its way into some emulation projects that are very, very interesting that we'll talk about more later. 768 01:01:59,220 --> 01:02:11,940 And I intend to make the symbolic analysis engine in PowerPC push forward the art of reverse engineering and exploitation. 769 01:02:12,180 --> 01:02:15,120 So that's all for that slide. 770 01:02:15,340 --> 01:02:24,100 And I intend to make Aaron the lead on a lot of stuff, but his wife doesn't know it yet. 771 01:02:25,140 --> 01:02:27,400 You have to teach me some math, I guess. 772 01:02:28,520 --> 01:02:31,360 Okay, so we want to throw in some resources. 773 01:02:31,560 --> 01:02:34,360 Yeah, so DevSec. 774 01:02:35,420 --> 01:02:44,480 I honestly for the PowerPC resources themselves, you could probably go back and read a large number of documents. 775 01:02:44,480 --> 01:02:48,440 But these are some of the more useful ones, at least for embedded. 776 01:02:48,800 --> 01:02:50,060 We didn't even touch on it. 777 01:02:50,060 --> 01:02:59,580 SPE is kind of the PSP stuff for embedded NXP processors. 778 01:02:59,580 --> 01:03:02,680 You can see this is the NXP files. 779 01:03:04,900 --> 01:03:06,080 They're subtle. 780 01:03:08,820 --> 01:03:12,560 I think the weather is telling us it's time to move on, isn't it? 781 01:03:12,560 --> 01:03:13,800 Yeah, no doubt. 782 01:03:14,600 --> 01:03:15,360 All right. 783 01:03:15,700 --> 01:03:18,300 No time for Q&A, but you can hit us in... 784 01:03:18,900 --> 01:03:20,320 We'll be in Discord. 785 01:03:21,420 --> 01:03:21,780 All right. 786 01:03:21,780 --> 01:03:22,620 Thank you all. 787 01:03:23,520 --> 01:03:24,580 Thank you, Aaron. 788 01:03:24,740 --> 01:03:25,760 No, thank you.