WEBVTT 00:00.760 --> 00:02.020 Let's kick it. 00:02.960 --> 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. 00:13.900 --> 00:18.440 But since I can't, I'm just going to throw pencils there and pick on him. 00:18.680 --> 00:19.460 That's fine. 00:22.280 --> 00:25.380 Go ahead. 00:25.580 --> 00:34.360 Oh, in order of events here, we're going to do some dry PPC, because we're gigantic nerds. 00:34.980 --> 00:39.440 We're going to talk about the kind of guts of this, which is the vivisect stuff. 00:42.000 --> 00:46.780 Who cares about PowerPC? 00:49.140 --> 00:50.880 Only us nerds, right? 00:51.760 --> 00:52.820 I hope not. 00:53.260 --> 00:56.640 Or, you know, I suppose the people developing embedded devices care. 00:56.900 --> 01:01.540 I hope that the people whose lives are in jeopardy care, but we'll get into that. 01:05.120 --> 01:07.980 I'm going to insert an x86 joke here. 01:10.420 --> 01:14.360 We've been programming PowerPC for a long time. 01:15.000 --> 01:18.980 We always used to pick on the x86 people. 01:20.300 --> 01:29.180 And the reverse engineers care, which is an interesting topic, because the tools for doing that are not that great. 01:29.180 --> 01:33.920 Oh, and I'm pointing on my screen like people can actually see me. 01:33.920 --> 01:35.100 Not like I'm pointing up at the... 01:37.240 --> 01:38.920 NMFTA, they care. 01:40.260 --> 01:42.380 People running mainframes care. 01:42.980 --> 01:45.700 Why would they care? 01:45.700 --> 01:46.780 Why would they care? 01:46.860 --> 01:48.760 Actually, Aaron, who are you? 01:48.780 --> 01:49.540 Who am I? 01:49.540 --> 01:50.760 Oh, okay. 01:50.960 --> 01:53.700 We skipped the intro slides here. 01:53.700 --> 01:54.780 I guess so. 01:54.900 --> 01:57.880 I am Aaron, or Acorn. 01:57.880 --> 02:00.240 I'm a security researcher with Grimm. 02:00.930 --> 02:09.200 For most of my career, I was doing embedded software and system development, used typically on safety critical systems. 02:09.200 --> 02:13.540 I've worked on telecom and Motorola. 02:13.540 --> 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. 02:26.470 --> 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. 02:34.350 --> 02:35.310 Indeed. 02:35.390 --> 02:35.870 Awesome. 02:35.870 --> 02:37.990 I'm so glad to hear that you love that. 02:38.850 --> 02:40.770 And I am Atlas. 02:40.830 --> 02:45.430 I've been hacking, reversing stuff for about 15 years. 02:45.550 --> 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. 03:03.190 --> 03:08.330 And now, as of recent, space things. 03:08.610 --> 03:12.890 Please forgive me if I snore sometime during the presentation. 03:12.890 --> 03:14.470 Aaron, you'll have to yell. 03:14.490 --> 03:19.170 I was up for 26 hours straight hacking satellites last night. 03:19.170 --> 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. 03:27.210 --> 03:30.530 So I did get about four and a half hours sleep. 03:30.530 --> 03:33.050 So I didn't short you guys too much. 03:33.050 --> 03:36.290 That's what I would have normally gotten in DEF CON Vegas. 03:36.890 --> 03:39.910 So a little about me. 03:39.910 --> 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. 03:48.930 --> 03:55.530 I am a Christian, a father of three and a husband of one. 03:55.750 --> 04:00.370 And I love talking to you guys. 04:00.830 --> 04:06.490 So why would anybody other than us nerds care, Aaron? 04:06.570 --> 04:09.790 Where do we see power PC chips these days? 04:10.730 --> 04:20.870 Well, we see them in my mouse works. 04:21.250 --> 04:23.230 Or not, whichever, you know. 04:24.810 --> 04:26.770 Oh, I'm skipping ahead. 04:27.490 --> 04:29.030 I guess I think we got a word. 04:29.030 --> 04:37.830 Where we see them here today, mainframes, IBM, all of those systems that, what is it called now? 04:38.830 --> 04:41.870 I, system I, I think is what they call it. 04:41.870 --> 04:43.150 Oh yeah, IBM I. 04:43.510 --> 04:50.810 Those are all power PC systems, not the weird 48-bit things they used to be. 04:51.230 --> 04:53.030 Embedded controls, right? 04:54.130 --> 04:55.030 Yep. 04:55.490 --> 05:03.330 IBM also, they've got their I platforms and their AIX, used to be the RS6000s. 05:04.450 --> 05:06.750 And they all run on power PC. 05:06.750 --> 05:12.750 In fact, they've put them under the umbrella known as the power systems. 05:12.750 --> 05:14.730 So go figure. 05:15.950 --> 05:21.550 So NXP, NXP, I've seen their name somewhere. 05:21.650 --> 05:24.250 Kind of things that they get their, their chips into. 05:25.510 --> 05:28.730 Oh, rhetorical questions here. 05:29.670 --> 05:43.310 Automotive, industrial systems, aerospace, they're heavily favored for platforms that, I guess, prize, what, reliability, durability, determinism. 05:44.070 --> 05:45.810 The littler things though. 05:45.810 --> 05:45.990 Yeah. 05:45.990 --> 05:48.510 Not the things that you carry in your backpack. 05:48.510 --> 05:51.290 Well, I mean, maybe, but not your laptops and. 05:51.290 --> 05:52.330 Right. 05:52.330 --> 05:53.090 Embedded things. 05:53.090 --> 05:55.210 NXP has dominated that space. 05:55.210 --> 05:55.970 Right. 05:57.010 --> 05:57.410 Yeah. 05:57.410 --> 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. 06:06.470 --> 06:11.810 Yeah, that's a, it's a different, a different presentation talking about Leon and Spark. 06:12.390 --> 06:18.010 But for power PC is very traditional, typically or radiation hardened systems. 06:18.010 --> 06:22.090 I think they call it the rad 750 is a very, very common one. 06:22.090 --> 06:25.890 It's the old G3 series stuff. 06:26.270 --> 06:27.910 Assuming I remember right. 06:27.910 --> 06:29.970 It's been a few years since I confirmed. 06:30.970 --> 06:34.150 But yeah, so power PC, for those of you who don't know, right. 06:34.150 --> 06:35.050 Risk. 06:35.710 --> 06:37.650 Kind of. 06:38.650 --> 06:39.870 Fixed instruction words. 06:39.870 --> 06:43.290 About every, every risk process I ran into actually. 06:43.570 --> 06:52.170 You know, every time you get a risk platform, you start finding very non-reduced parts of it very quickly. 06:53.270 --> 06:56.230 Fixed instruction word, 32 bits, every instruction. 06:57.450 --> 06:58.590 Kind of. 06:58.590 --> 07:02.610 We saw a bit of a sneak preview on that of my other work slides here. 07:03.210 --> 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. 07:12.830 --> 07:14.630 Power books, right? 07:15.270 --> 07:16.050 Power books. 07:16.770 --> 07:22.550 Their releases, the G3, G4, G5. 07:22.550 --> 07:32.210 I think they were all actually tied into the different releases of the, the power PC architecture documentation. 07:32.350 --> 07:33.470 Yep. 07:34.190 --> 07:39.230 So yeah, the things that they're used in bed controls, IBM and old apples. 07:39.230 --> 07:41.590 I should have said old Apple computers there, right? 07:41.590 --> 07:44.650 I guess it's the slides titled history lesson. 07:44.650 --> 07:47.450 So I thought it was kind of obvious. 07:47.930 --> 07:51.770 Here's the caveat for a 32 bit thing. 07:51.770 --> 08:07.970 Freescale created a variable instruction word within APU, which is what power PC companies call extensions, extra things. 08:07.970 --> 08:17.310 If evolution and Darwinism was applied to computer systems, APUs would be the mechanism through which evolution occurred. 08:17.310 --> 08:19.910 And the platypus was formulated. 08:20.670 --> 08:23.650 So not my favorite thing. 08:23.650 --> 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. 08:32.850 --> 08:33.390 Yeah. 08:33.390 --> 08:34.150 Yeah. 08:35.370 --> 08:37.170 Found this fun slide here. 08:37.170 --> 08:38.870 It's probably only interesting to me. 08:39.430 --> 08:40.870 I loved it. 08:41.110 --> 08:43.030 I love the title of it though. 08:43.030 --> 08:50.450 Power architecture demystified, which is an extremely bold claim for anybody who's familiar with power PC. 08:50.730 --> 08:54.390 But here they've got the, you know, there's this little highlighted section here. 08:55.290 --> 08:58.410 Somebody who worked at Freescale slash NXP. 08:58.410 --> 09:00.250 I think this was produced in 2000. 09:00.250 --> 09:01.550 This paper was from 2007. 09:01.550 --> 09:04.390 So this would be somebody who was at Freescale at the time. 09:05.310 --> 09:11.690 With benchmarking, they said that the code is 30% smaller with only a 5% reduction in performance. 09:12.770 --> 09:14.510 You know what I read that to say? 09:14.510 --> 09:15.190 What? 09:15.190 --> 09:18.430 I read that to say ARM's doing it. 09:18.430 --> 09:21.030 We should probably do something like that too. 09:21.370 --> 09:22.370 Probably. 09:22.570 --> 09:24.790 That's probably exactly it. 09:25.830 --> 09:30.530 Automotive especially loves their small memory footprint parts. 09:30.530 --> 09:33.850 Well, you know, you save a fraction of a penny per chip. 09:34.190 --> 09:34.810 Yeah. 09:34.830 --> 09:41.310 But this type of thing, the VLE stuff, it's a big, all of the, well, I shouldn't say all. 09:41.310 --> 09:50.410 A great deal of the embedded components use the VLE features on embedded controls right now. 09:51.150 --> 09:59.310 And it's kind of a big deal because as Alice said, it makes producing tooling very, very complicated. 10:00.230 --> 10:09.170 Like making PowerPC tools is like making tools for like 20 different processors for architectures. 10:09.410 --> 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. 10:17.750 --> 10:18.070 Yeah. 10:18.070 --> 10:20.830 Because they don't coalesce well. 10:23.540 --> 10:24.940 So, Vivisect. 10:24.940 --> 10:28.060 Can you tell me something about Vivisect? 10:28.060 --> 10:28.780 Yeah. 10:28.780 --> 10:38.040 So, Vivisect is a binary analysis framework that was created specifically for the purpose of finding and exploiting vulnerabilities. 10:38.980 --> 10:43.840 Originally created by a really good friend of mine named Invisigoth. 10:46.820 --> 10:50.320 It speaks my language, so to speak. 10:50.320 --> 10:51.660 It's pure Python. 10:52.200 --> 11:00.620 It allows me a ton of power in many different ways, including from the command line. 11:00.620 --> 11:02.300 I'm an IPython person. 11:02.300 --> 11:08.100 I go to work and I type IPython and I feel like I'm starting to do something meaningful. 11:09.060 --> 11:14.380 So, there's a lot of cool, meaningful things I can do with Vivisect there. 11:14.420 --> 11:19.440 But it's been forward thinking since it was originally created. 11:19.860 --> 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. 11:31.960 --> 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. 11:42.760 --> 11:50.620 If we try to read memory that doesn't exist or if we try to access uninitialized variables or whatever. 11:50.820 --> 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. 11:58.220 --> 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. 12:09.360 --> 12:11.660 Or, oop, that's ARG1. 12:11.660 --> 12:18.500 So, I know that ARG1 is now going to propagate through this calculation and whatnot. 12:19.900 --> 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. 12:32.580 --> 12:34.680 And I'm like, what is that? 12:34.960 --> 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, 12:57.700 --> 13:00.720 since repairing those things kind of sucks. 13:02.700 --> 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. 13:16.100 --> 13:24.360 And so, these things all wrap around and support x86, 32 and 64-bit. 13:25.540 --> 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. 13:48.420 --> 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. 14:11.240 --> 14:16.300 So, command line stuff, just programming plugins, whatnot. 14:17.040 --> 14:18.760 Okay, enough about that. 14:18.900 --> 14:20.980 I've said four and a half hours sleep. 14:23.360 --> 14:26.500 So, why don't you talk about this, Aaron? 14:28.240 --> 14:30.560 Well, let me give a little backstory. 14:30.700 --> 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. 14:50.300 --> 14:54.820 And so, it was already open source, so that was an easy sell. 14:55.740 --> 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. 15:11.300 --> 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. 15:19.220 --> 15:20.560 Talk about this, Aaron. 15:20.920 --> 15:22.000 Sure, sure. 15:22.040 --> 15:29.640 So, adding an ISA to BIVSEC, as Alex said, there's a couple different parts of it. 15:29.740 --> 15:33.660 You've got to figure out how to disassemble the different instructions, right? 15:33.660 --> 15:36.660 You've got to get your documentation to figure out what the instructions look like. 15:36.660 --> 15:39.220 Then you need to figure out how to emulate their behavior. 15:39.800 --> 15:41.400 You need to... 15:41.400 --> 15:46.440 symbolic analysis is a bit outside of my wheelhouse there. 15:46.820 --> 15:48.440 Yeah, I took most of that on. 15:48.520 --> 15:52.060 It's a different way of thinking. 15:53.040 --> 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. 16:00.560 --> 16:07.360 Figuring out how to test tools to handle a new architecture is interesting. 16:07.800 --> 16:10.420 You know, how do you... where do you get that information from? 16:10.420 --> 16:11.760 Obviously, you get your documentation. 16:11.760 --> 16:12.760 At least, I hope you do. 16:12.760 --> 16:14.200 It's going to be a stretch. 16:14.980 --> 16:17.660 You get existing compilers and object dump tool. 16:17.660 --> 16:18.880 That's useful. 16:19.480 --> 16:24.160 If you take existing disassembly tools, those can be useful. 16:24.160 --> 16:30.040 Those will give you a certain view of the results that may or may not match the object dump. 16:30.140 --> 16:35.120 You can just make gigantic lists of instructions to parse from your documentation. 16:35.380 --> 16:38.320 Don't forget, you also have to figure out how to do the behavior of that. 16:39.980 --> 16:43.220 No matter which one of these paths you take. 16:43.520 --> 16:50.300 Oh, and also option D, which I forgot to put down there, which is get the hardware and run it. 16:50.640 --> 16:58.980 For PowerPC, that would really mean get, like, what, 20, 30, 40 different pieces of hardware. 17:00.140 --> 17:03.620 It's not going to be challenging to do it for everything, but it is useful. 17:04.080 --> 17:07.280 We got our hands on a couple different architectures for it. 17:07.420 --> 17:09.400 A couple different platforms. 17:09.740 --> 17:14.100 One embedded and one more server-esque. 17:15.820 --> 17:19.580 So we were able to have all that at our disposal. 17:19.620 --> 17:25.080 So, Aaron, this sounds a lot like magic. 17:25.400 --> 17:26.480 It does. 17:28.860 --> 17:30.400 But what's it really mean? 17:30.400 --> 17:37.660 What's it look like to write disassembly code or an emulation instruction? 17:37.660 --> 17:39.300 How do you emulate an instruction? 17:40.680 --> 17:42.680 How do you emulate an instruction? 17:43.220 --> 17:44.780 Mostly the disassembly part. 17:44.780 --> 17:49.840 I feel most people think that is more magic than it really is. 17:49.840 --> 17:50.460 It is. 17:50.460 --> 17:55.480 The magic really is about finding the documentation and understanding what they meant. 17:55.820 --> 17:56.460 Sure. 17:56.460 --> 18:02.020 Well, you know, once you... I guess it's basically about the numbers, right? 18:02.020 --> 18:06.840 Everything at its base form in computers is a number. 18:07.060 --> 18:10.340 Hexadecimal, decimal, whichever way you prefer to read it. 18:10.440 --> 18:12.240 Everything is numbers. 18:12.240 --> 18:15.740 If it's data, if it's code, whatever it is, it's just a number. 18:15.840 --> 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. 18:23.700 --> 18:26.080 And then you just start taking a look. 18:26.140 --> 18:29.400 This particular pattern here means that it's this instruction. 18:29.400 --> 18:31.820 This particular pattern here means it's this instruction. 18:32.440 --> 18:37.420 This right here is a fun list of test inputs. 18:38.160 --> 18:41.280 Wish we could have gotten your scrolling version going. 18:41.280 --> 18:41.780 That would have been... 18:41.780 --> 18:43.220 Yeah, I don't know. 18:43.220 --> 18:47.180 For some reason, I just can't... media, you know... 18:47.740 --> 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. 19:00.180 --> 19:05.680 About like 30 megabyte GIFs did not play nice. 19:08.080 --> 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. 19:25.040 --> 19:28.460 And then what you do after you do that is you go through and you fix all the bugs. 19:28.460 --> 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. 19:44.040 --> 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. 19:51.180 --> 19:54.500 So that's kind of the process there. 19:54.500 --> 19:58.460 You go through and you just fix the bugs. 20:00.380 --> 20:01.920 But yeah, so it's not magic. 20:01.920 --> 20:04.060 You just start with the data. 20:04.280 --> 20:08.820 You go through and then in Python, you make the function. 20:08.920 --> 20:15.740 When you match this pattern, then you use this function to emulate it, right? 20:15.860 --> 20:23.140 So Aaron, he really ended up taking charge of the testing and it was incredible. 20:24.480 --> 20:32.000 He wrote the most versatile testing or instruction analysis framework I've seen. 20:32.000 --> 20:35.300 He basically rewrote an entire disassembler. 20:35.380 --> 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? 20:44.460 --> 20:48.980 And boom, the unit tests started just looking a different way. 20:48.980 --> 20:50.920 Oh, that's how that is. 20:50.920 --> 20:52.660 Yeah, that's a weird thing. 20:52.660 --> 20:54.280 Nobody really agrees on how that works. 20:54.280 --> 20:55.980 So that's how Vivisect wants to do it. 20:55.980 --> 20:57.160 Okay, I gotcha. 20:58.000 --> 21:01.860 So this all goes back to the fact that it's all just bits. 21:02.140 --> 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. 21:13.920 --> 21:17.000 The computer system decides what to do with them. 21:17.000 --> 21:19.260 And our disassembler is doing the same thing. 21:19.260 --> 21:25.040 It takes in just a string of bytes because bytes are the easiest way for us to deal with the world. 21:26.200 --> 21:35.980 And then it looks at a combination of the bits and says, based on these things, that's this instruction. 21:36.100 --> 21:41.720 And every architecture kind of has its own nuance and its own flow for Intel. 21:41.800 --> 21:50.000 It goes byte by byte going, hey, this first byte puts us into this table of options for instructions. 21:50.000 --> 21:51.580 And oh, we hit the second byte here. 21:51.580 --> 21:54.960 That falls into another table of instruction options. 21:55.260 --> 22:00.980 ARM, it's kind of like a bunch of bit masks and comparisons. 22:01.200 --> 22:05.940 Take the thing, mask it with this, and compare it against this. 22:05.940 --> 22:06.640 Oh, it's not that? 22:06.640 --> 22:10.660 Okay, and it moves down the list until it finds the escape hatch. 22:10.660 --> 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. 22:21.780 --> 22:25.800 It's pretty close to how the PowerPC stuff in VitaSec ended up. 22:25.800 --> 22:27.160 Lots of bit masking. 22:28.320 --> 22:29.360 Yes. 22:30.060 --> 22:39.080 With all these different instructions here, the fun thing with the VLE parts is that they've got different modes. 22:39.080 --> 22:44.700 They can run variable instruction mode or full 32-bit instruction mode. 22:44.920 --> 22:55.020 But the full 32-bit instructions don't necessarily match the real PowerPC instruction encodings either. 22:55.020 --> 23:00.520 So there's just a ton of different ways to do things. 23:03.300 --> 23:04.640 Hmm? 23:04.900 --> 23:05.540 Can I just look? 23:05.540 --> 23:06.240 Yep. 23:06.240 --> 23:07.440 Oh, okay. 23:11.240 --> 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. 23:36.300 --> 23:40.340 It's a simplistic way of viewing it, but basically that's it. 23:40.340 --> 23:47.680 So you can have ARM instructions right next to, grouped right next to a bunch of thumb instructions. 23:48.180 --> 23:54.380 In PowerPC with VLE, with variable length encoding, they're not the same. 23:55.240 --> 24:06.720 PPC and PowerPC decided to mark individual memory pages as being either VLE or straight PowerPC. 24:07.720 --> 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. 24:17.600 --> 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. 24:35.180 --> 24:37.860 It needs to know which way to decode. 24:38.280 --> 24:44.000 So that's just how PowerPC chose to do it. 24:44.080 --> 24:44.620 Sure. 24:44.620 --> 24:53.700 So if you, and not every single PowerPC processor supports full PowerPC, or the very VLE, maybe they do both. 24:53.700 --> 24:57.160 Some of them do only one or the other. 24:57.520 --> 24:59.940 Embedded parts, they don't have Altebec for those. 24:59.940 --> 25:02.160 Oh, here's another, yeah, no doubt. 25:02.160 --> 25:06.620 Altebec, the vector math instructions. 25:06.760 --> 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. 25:19.060 --> 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. 25:32.320 --> 25:36.020 And many architectures, that's like address zero. 25:38.340 --> 25:39.680 Not PowerPC. 25:39.680 --> 25:45.640 PowerPC, there's weird ways of figuring out where code should start. 25:45.640 --> 25:50.560 In fact, there's a boot assist module in a lot of the architectures. 25:50.640 --> 25:54.920 And the boot assist module is the thing that gets code execution first. 25:54.920 --> 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. 26:03.160 --> 26:06.080 And it looks for a signature. 26:06.900 --> 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. 26:22.980 --> 26:26.480 So weird things, just like all sorts of weirdness. 26:27.180 --> 26:34.220 For a long time, PowerPCs had the ability to change which page of memory is big-ending or little-ending. 26:35.460 --> 26:41.740 They call it the TLB, just a slightly more granular MMU, I guess. 26:41.740 --> 26:43.220 I don't know. 26:43.280 --> 26:47.320 Hey, at least it's not a 27-bit middle-ending architecture. 26:47.320 --> 26:48.660 I will give it that much. 26:49.120 --> 26:50.440 It could be worse. 26:52.560 --> 26:54.520 Yeah, I don't know. 26:54.520 --> 26:57.020 The documentation, boy, that was really annoying. 26:58.540 --> 26:59.800 What was it? 26:59.800 --> 27:00.920 The registers. 27:01.640 --> 27:06.520 It took me forever because the documentation said the registers are 64 bits. 27:06.520 --> 27:08.860 It's interesting for an embedded processor. 27:09.280 --> 27:16.000 Oh, except for when you're in VLE mode, you can't access the upper 32 bits of those registers. 27:16.960 --> 27:17.660 Okay. 27:17.660 --> 27:18.100 Fine. 27:18.100 --> 27:18.940 Whatever. 27:19.520 --> 27:25.420 Oh, by the way, they're numbered 0 to 31 as the highest, most significant bits. 27:25.620 --> 27:32.220 When you're talking about 32-bit mode, you're talking about 32 through 63. 27:32.220 --> 27:34.780 Everything is 32 through 63. 27:35.320 --> 27:37.260 The architecture isn't the problem. 27:37.260 --> 27:39.760 The people writing the freaking documentation are. 27:39.800 --> 27:40.860 And it's always been that way. 27:40.860 --> 27:42.660 You can't blame the newer stuff for that. 27:42.660 --> 27:44.340 It's always been that way. 27:44.660 --> 27:46.100 I blame IBM for that one. 27:46.100 --> 27:47.740 I'm betting it was them. 27:47.940 --> 27:48.480 I don't know. 27:48.480 --> 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. 27:55.860 --> 27:58.200 And they agreed by doing it in weird ways. 27:58.460 --> 28:04.100 By bringing their weird way to the table and saying you must do it this way because we did it already. 28:04.100 --> 28:05.060 Right, right. 28:05.580 --> 28:09.940 So let's do something fun here. 28:10.980 --> 28:11.660 Okay. 28:12.940 --> 28:15.500 So PowerPC is a little different. 28:15.520 --> 28:16.460 We're here. 28:16.460 --> 28:17.720 We're at DEF CON. 28:17.760 --> 28:20.040 We're talking about security things, right? 28:20.600 --> 28:22.580 How do you exploit PowerPC? 28:23.780 --> 28:24.620 Or no, no. 28:24.620 --> 28:25.140 Sorry. 28:25.360 --> 28:25.900 Damn it. 28:25.900 --> 28:26.800 I did it wrong. 28:28.240 --> 28:29.480 Go back a few seconds. 28:29.480 --> 28:31.120 Pretend I didn't say that. 28:31.580 --> 28:32.920 PowerPC is secure, right? 28:32.920 --> 28:33.680 Nobody knows the number. 28:33.680 --> 28:34.520 You can hack it. 28:35.380 --> 28:36.080 Absolutely. 28:36.080 --> 28:37.420 It's in Big Iron. 28:37.460 --> 28:38.820 Those are unhackable. 28:38.900 --> 28:39.760 Right, right. 28:42.320 --> 28:46.380 So obviously, I mean, it's not. 28:46.380 --> 28:48.400 It's not impossible to hack. 28:49.000 --> 28:50.800 You just need to do it differently. 28:52.180 --> 28:59.800 Every processor, it reads in data, spits out data, interprets data as instructions, as I said earlier. 28:59.840 --> 29:03.940 You just need to figure out the way you can tell it what's what. 29:04.000 --> 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. 29:17.860 --> 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. 29:32.460 --> 29:38.460 If you go and look at the documentation for the special purpose registers in PowerPC, I mean, I don't know. 29:38.460 --> 29:40.020 Alice, do you remember how many? 29:40.020 --> 29:41.120 There's like thousands. 29:41.120 --> 29:42.640 Only a couple thousand. 29:43.020 --> 29:46.380 I don't even know what you do with all of them. 29:46.380 --> 29:49.800 We have a table with a lot of them in the decoder. 29:50.620 --> 29:51.760 There's a lot of them. 29:52.120 --> 29:56.400 So move to link register is actually not even an instruction. 29:56.400 --> 30:01.840 It's actually move to SPR with LR as an operand. 30:01.840 --> 30:02.900 That's true. 30:02.900 --> 30:08.660 Move MTSPR 1, LR. 30:09.180 --> 30:14.800 MTLR is a mnemonic that some assemblers allow. 30:15.020 --> 30:16.480 Now, we like that. 30:16.480 --> 30:19.160 It's intuitively pleasing. 30:19.160 --> 30:22.480 But I'm just saying that's how the architecture breaks down. 30:22.920 --> 30:23.480 Yep. 30:24.420 --> 30:24.940 Yeah. 30:24.940 --> 30:26.280 So move to link register. 30:26.380 --> 30:28.980 Link register is, of course, where you return to. 30:29.700 --> 30:35.040 Again, like ARM, you store the value place you came from on the link register. 30:35.140 --> 30:40.560 And when you need to return to it, it loads an address back into the link register. 30:40.580 --> 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. 30:51.820 --> 30:53.620 Account register is a weird one. 30:54.160 --> 31:00.200 Account register in PowerPC is used for a lot of jump tables and function pointers. 31:01.340 --> 31:02.440 So that's another one. 31:02.440 --> 31:05.340 You could just modify that and get hold of a switch statement. 31:06.840 --> 31:10.080 So nice little rock gadgets here. 31:10.160 --> 31:10.480 Yeah. 31:10.900 --> 31:13.600 I wanted to put some fun in here, you know? 31:15.040 --> 31:16.980 I love that you consider that fun. 31:17.480 --> 31:18.560 Right. 31:18.840 --> 31:19.860 Right. 31:20.260 --> 31:21.820 This was not as fun. 31:21.820 --> 31:23.240 This is not so fun. 31:24.920 --> 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. 31:39.140 --> 31:40.960 Wait, that's one instruction? 31:41.320 --> 31:43.380 Yeah, it's one instruction, right? 31:44.380 --> 31:46.140 Actually, no, this isn't one instruction. 31:46.140 --> 31:48.300 It's only a couple. 31:48.300 --> 31:50.340 Two or three, whatever. 31:50.340 --> 31:51.180 It doesn't matter. 31:51.180 --> 31:52.760 There's these rotate instructions. 31:53.600 --> 31:56.940 Rotate left with bullshit. 31:57.640 --> 31:58.900 That's what I read there. 31:58.900 --> 31:59.900 Rotate left. 31:59.900 --> 32:00.800 Word. 32:00.940 --> 32:01.880 Immediate. 32:01.880 --> 32:02.980 Thing. 32:03.060 --> 32:03.920 This one. 32:03.920 --> 32:04.940 This one, right? 32:08.020 --> 32:12.480 Unfortunately, this Twitter account didn't tweet for very long. 32:14.620 --> 32:19.720 But it's really interesting to, as you say, nerds like me. 32:20.700 --> 32:22.180 We don't need to make it up, though. 32:22.180 --> 32:25.500 I mean, they included the EIEIO instruction. 32:25.500 --> 32:26.600 Yes. 32:26.600 --> 32:31.000 I mean, that's dropping the mic for instruction lunacy. 32:31.020 --> 32:31.900 Right. 32:32.320 --> 32:37.120 So, I don't have much time left in the talk, unfortunately. 32:37.120 --> 32:38.580 A little bit. 32:39.340 --> 32:40.660 Go ahead. 32:40.780 --> 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. 32:48.620 --> 32:49.600 Yep. 32:50.220 --> 32:53.040 Oh, hey, we're to story time. 32:53.040 --> 32:54.740 Story time with Atlas. 32:55.740 --> 33:03.180 So, we do a lot of work with a lot of people that we care very deeply for. 33:03.240 --> 33:09.040 And so, there's stuff that we have, but we can't use it for a talk. 33:09.040 --> 33:17.760 So, we were scouring the internet for something that we could show and not have to make anybody uncomfortable. 33:17.760 --> 33:26.780 We ended up finding a repository of a whole bunch of automotive code on some sketchy website. 33:26.780 --> 33:34.240 So, downloaded a bunch of things that I could identify as something potentially PowerPC. 33:35.380 --> 33:40.760 And thankfully, I threw one in Vivisect. 33:40.760 --> 33:43.960 And it's just a blob at this point. 33:43.960 --> 33:46.180 So, this is a VBF. 33:46.320 --> 33:53.900 VBF is basically a file package, almost a file format. 33:53.900 --> 33:54.500 Not really. 33:54.500 --> 33:58.020 It starts off with a couple headers and then goes to binary code. 33:59.080 --> 34:11.740 So, I slapped in a VBF into Vivisect, and I just started scouring around what things were. 34:11.740 --> 34:16.260 And thankfully, the very first one I loaded in, I guessed well. 34:16.260 --> 34:21.160 And I hit decode, or I hit C for make code. 34:21.380 --> 34:31.980 And I got a branch instruction followed by three NOPs, another branch instruction, followed by three NOPs, and a repeating pattern. 34:31.980 --> 34:36.960 There are like a thousand of these in this firmware. 34:39.060 --> 34:42.200 But it could have been just a weird repeating pattern. 34:42.200 --> 34:45.300 So, I wasn't going to bank on that. 34:45.980 --> 34:48.460 So, I started looking through. 34:48.460 --> 34:49.420 What's that, Aaron? 34:49.420 --> 34:51.240 Oh, I just wanted to interject here. 34:51.240 --> 34:59.020 For those of us who have been done PowerPC programming, this type of pattern is extremely common. 34:59.360 --> 35:04.120 PowerPC lines up every interrupt handler, every... 35:05.180 --> 35:06.120 what's that? 35:06.120 --> 35:07.340 64 bytes? 35:07.340 --> 35:08.100 No. 35:08.100 --> 35:09.380 148 bytes? 35:09.440 --> 35:10.320 Whatever. 35:10.420 --> 35:12.060 And that's very common. 35:12.060 --> 35:16.600 Of course, you'll need this many instructions to handle your interrupts. 35:16.600 --> 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. 35:23.620 --> 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. 35:41.020 --> 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. 35:55.480 --> 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. 36:06.860 --> 36:09.020 That wasn't in this. 36:09.120 --> 36:12.200 This was going to be something else. 36:12.200 --> 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. 36:34.540 --> 36:41.200 Or it could be some crazy other architecture that has nothing to do with PowerPC. 36:41.200 --> 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. 36:49.220 --> 36:53.100 Plus, there's this architecture I keep running into that I don't know much about. 36:53.100 --> 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. 37:03.780 --> 37:07.180 So, I was still kind of skeptical. 37:07.180 --> 37:08.460 So, next slide, Aaron. 37:08.460 --> 37:09.260 Yep. 37:10.900 --> 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. 37:24.500 --> 37:25.840 So, this is the VIV window. 37:25.840 --> 37:29.640 I've created another memory viewer called foo. 37:29.640 --> 37:30.360 Why? 37:30.360 --> 37:32.720 Because foob are best. 37:37.080 --> 37:44.580 So, anyway, I think I threw this in out of order. 37:44.580 --> 37:45.380 Sorry. 37:46.160 --> 37:50.020 So, here's like you can see that backup one. 37:50.260 --> 37:51.460 One slide. 37:51.460 --> 37:54.500 So, we start at 40,000 hex. 37:54.500 --> 37:57.160 So, that's a lot bigger than 40,000. 37:57.160 --> 37:58.900 But anyway, 40,000 hex. 37:58.900 --> 38:00.640 Scroll forward one. 38:01.640 --> 38:05.980 And we're still doing this table thing. 38:06.220 --> 38:12.540 1,300 hex into this firmware. 38:12.540 --> 38:17.300 And that is 130 hex options. 38:18.940 --> 38:25.240 So, far, just 130 hex different branch options. 38:25.240 --> 38:25.440 Okay. 38:25.440 --> 38:26.560 Now, next. 38:27.740 --> 38:29.860 So, we follow the location. 38:30.680 --> 38:32.400 And here's what they point at. 38:32.520 --> 38:40.200 Another table of branches that some of them point to the same thing. 38:40.200 --> 38:44.220 And as you can see, so, they're branching to location 43228. 38:44.820 --> 38:51.960 And you'll notice that the bytes that make up those instructions are not the same. 38:51.960 --> 38:55.680 It's not like boom, boom, boom, boom, boom, a table of all the same thing repeated. 38:55.820 --> 38:59.180 It's all the same thing, but these are relative branches. 38:59.180 --> 39:01.860 So, the numbers decrease as they go higher. 39:02.500 --> 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. 39:14.460 --> 39:17.020 I mean, it's easy to just look at this. 39:17.020 --> 39:20.500 You'll start looking at those values that make up those instructions. 39:20.500 --> 39:28.420 It almost looks like this is just, you know, a bunch of, you know, sequential memory addresses or something like that. 39:28.420 --> 39:29.500 It's very weird. 39:31.500 --> 39:32.280 Yep. 39:32.280 --> 39:32.520 Okay. 39:32.520 --> 39:33.260 Next. 39:34.020 --> 39:38.360 Until we run into hex 43,000. 39:38.800 --> 39:43.080 And at hex 43,000, we start to see real instructions. 39:43.080 --> 39:47.800 Now, many architectures, you give them four bytes, they can spit out an instruction. 39:47.800 --> 39:50.440 So, this does not mean that it's PowerPC. 39:52.300 --> 39:59.780 But we see these things peppered throughout a little bit of the previous table where everything was pointing to one location. 40:00.980 --> 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. 40:11.280 --> 40:11.760 Okay. 40:11.860 --> 40:19.680 And then we move from SPR counter, the counter register, into R3. 40:19.700 --> 40:26.140 So, we've stored R3 and then we put the counter into the counter register value into R3. 40:26.140 --> 40:31.500 And then we move to the SPR G1 from R3. 40:31.500 --> 40:31.800 Okay. 40:32.680 --> 40:34.320 Could be logical. 40:34.760 --> 40:35.300 Okay. 40:35.300 --> 40:39.820 Load immediate shifted zero into R3. 40:39.820 --> 40:45.820 So, we're not overwriting anything that we've just put into R3 without storing R3. 40:45.820 --> 40:46.500 So, okay. 40:46.500 --> 40:48.300 Sanity still exists. 40:49.300 --> 40:52.300 Load word zero extended. 40:52.300 --> 40:53.840 I think that's what that means. 40:53.840 --> 40:56.620 Although, I've been having to look up a lot of words. 40:57.520 --> 40:58.080 Okay. 40:58.760 --> 41:06.980 So, we take R3 and yeah, anyway, you're seeing the pattern. 41:07.300 --> 41:09.660 Things are actually starting to make sense. 41:09.660 --> 41:13.440 And after doing things with R3, we then move it into the counter register. 41:14.400 --> 41:18.380 We load immediate zero into register three. 41:18.380 --> 41:22.900 So, we wipe out, we clear R3 again, and then we branch to counter. 41:22.900 --> 41:23.260 Okay. 41:23.260 --> 41:24.580 That makes sense. 41:25.080 --> 41:29.640 That actually is a chunk of code that makes sense to me. 41:31.600 --> 41:35.280 After that, so branch with counter, that's the end of a code block. 41:35.800 --> 41:37.600 Because there's no branch with a link. 41:37.600 --> 41:38.400 There's no return. 41:38.400 --> 41:38.860 No nothing. 41:38.860 --> 41:39.900 It just goes somewhere. 41:40.540 --> 41:43.560 After that, though, we see STWU. 41:43.560 --> 41:45.520 No, that's not shut the what up. 41:47.840 --> 41:52.440 And this, man, I captured the pointer right in front of that. 41:52.500 --> 41:53.620 Right in front of that. 41:53.620 --> 41:57.060 Anyway, that's actually part of a function prologue. 41:57.060 --> 42:01.140 A very standard function prologue for RPC. 42:01.220 --> 42:02.360 So, R1. 42:02.520 --> 42:05.680 R1 is a stack pointer, right? 42:05.680 --> 42:10.020 So, this is moving the stack pointer. 42:10.540 --> 42:11.320 Yep. 42:11.460 --> 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. 42:24.140 --> 42:27.600 So, we create stack space and then we write registers into it. 42:27.600 --> 42:28.500 Okay. 42:28.580 --> 42:29.920 That sounds legit. 42:29.920 --> 42:35.040 The PowerPC calling convention includes handing arguments as registers. 42:36.060 --> 42:40.440 And you got to clean up after yourself when you're done. 42:40.440 --> 42:45.700 So, storing the registers that aren't arguments totally makes sense. 42:46.300 --> 42:50.360 Move from SPR, the link register into R0. 42:50.360 --> 42:50.520 Okay. 42:50.520 --> 42:55.580 So, our link register now, the return address now lives in R0. 42:56.160 --> 42:57.780 And then, okay. 42:57.780 --> 42:59.160 I'm convinced. 42:59.160 --> 43:00.420 This is PowerPC. 43:01.260 --> 43:02.600 So, next? 43:02.740 --> 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. 43:18.400 --> 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. 43:28.160 --> 43:28.940 It's been too long. 43:28.940 --> 43:30.600 I probably shouldn't say anything. 43:31.040 --> 43:38.300 Anyway, what it looks like to me is it looks like it's saying what address caused the particular interrupt. 43:38.300 --> 43:40.000 Why are we here? 43:40.220 --> 43:40.740 Right? 43:40.740 --> 43:49.120 And then, it's looking up, it's doing a calculation based on R3, which is, I guess, zero, right? 43:49.120 --> 43:50.300 So, it's jumping. 43:50.300 --> 43:55.240 For some reason, doing a jump calculation to one specific address. 43:55.280 --> 43:59.580 This LIS... I keep pointing my screen, like people can see what I'm pointing at. 43:59.580 --> 44:00.420 I can't help it. 44:00.420 --> 44:01.960 Make sure you're pointing at the camera. 44:01.960 --> 44:02.580 At the camera? 44:02.580 --> 44:03.020 Right. 44:03.020 --> 44:07.160 So, LIS, LW, those are very common for PowerPC. 44:07.240 --> 44:15.880 It's also something that a lot of first engineering tools have issues with, because this is PowerPC fixed instruction work. 44:15.880 --> 44:18.700 You can't have a 32-bit address in one instruction. 44:18.700 --> 44:25.200 You've got to have two, so it's lower 16, and then low, the upper 16 bits. 44:25.340 --> 44:26.120 Right. 44:27.140 --> 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. 44:39.900 --> 44:43.860 So, try loading the full value into a register in one instruction. 44:43.860 --> 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. 44:54.700 --> 44:55.140 Okay. 44:55.140 --> 44:59.840 So, I wanted to throw in an interesting thing. 44:59.840 --> 45:08.080 There's so many different details that make Vivisective fun and exciting reversing platform. 45:08.660 --> 45:13.820 Part of it is that there are many things that are not hidden from you. 45:14.380 --> 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. 45:29.740 --> 45:37.420 So, if you've got, let's say, switch on this variable being 1, 2, 3, 4, and 5. 45:37.420 --> 45:37.740 Okay. 45:37.740 --> 45:45.440 Those are, those different options are going to be stored as pointers to the code that handles each of those options. 45:45.860 --> 45:53.820 And then indexing into a table to grab the address to then branch right into that. 45:53.820 --> 45:54.740 That's a dynamic branch. 45:54.740 --> 45:59.280 You cannot figure out where that branch is supposed to go without an emulator. 46:01.160 --> 46:05.540 Or a lot of emulation written down into code that's not an emulator. 46:06.340 --> 46:15.620 There's also a lot of things like C++ method invocation. 46:15.620 --> 46:28.200 When you've got multiple inheritance with virtual function tables, you basically have a table that lists each type of call. 46:28.200 --> 46:39.720 So, an object called ball, and I have a method, get color, bounce, throw in the trash, throw at my sister. 46:40.000 --> 46:45.080 These are all method calls that go into a virtual function table. 46:45.080 --> 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. 47:00.980 --> 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. 47:16.460 --> 47:19.480 At least not when virtual function tables are involved. 47:19.480 --> 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. 47:29.280 --> 47:33.600 And virtual address sets are nothing more than analysis tools. 47:34.000 --> 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. 47:49.780 --> 47:55.700 And then, turns out, dynamic branches are very, very interesting things. 47:55.700 --> 48:00.680 They tell a ton about what's going on with the code. 48:01.200 --> 48:12.520 Typically, making sense of assembly instructions is not typically terribly hard. 48:12.540 --> 48:15.300 Spark notwithstanding. 48:16.220 --> 48:17.360 Just kidding. 48:18.920 --> 48:28.320 However, finding in this massive, maybe four megabytes of firmware, what things are interesting, that can be hard. 48:29.180 --> 48:30.900 And I love doing this. 48:30.900 --> 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. 48:38.460 --> 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. 48:52.320 --> 48:54.220 And so that's why I threw this in there. 48:54.220 --> 48:56.240 Dynamic branch handling is very interesting. 48:56.240 --> 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. 49:08.560 --> 49:14.900 So things are expected to, this instruction. 49:15.560 --> 49:26.240 So that's very likely, that could very well be C++ stuff, or it could be function pointers, or whatnot. 49:26.240 --> 49:28.400 So either way, it's very interesting. 49:29.680 --> 49:30.560 I'm done if you... 49:31.620 --> 49:32.160 Okay. 49:36.650 --> 49:46.730 So I was just poking through this, one of the firmwares that I was looking at for this presentation. 49:47.510 --> 49:51.550 And of course, I was looking at the dynamic branches. 49:51.810 --> 49:53.050 And here's one. 49:53.170 --> 49:54.990 This was an oddity. 49:57.070 --> 49:59.330 I mean, it actually wasn't an oddity. 49:59.330 --> 50:00.730 It struck me weird. 50:00.870 --> 50:02.030 But I'm just looking at it. 50:02.030 --> 50:06.050 And in this code block, if you're not familiar, this is a code flow graph. 50:06.750 --> 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. 50:20.770 --> 50:23.570 It just kind of flows naturally. 50:23.970 --> 50:30.250 So in the code block in the middle, there's a discrete code block. 50:30.250 --> 50:38.510 And it looks like we are loading values into the R12 register. 50:39.650 --> 50:43.330 And then we're moving the R12 register data into the counter register. 50:43.330 --> 50:45.970 And then we're branching to the counter register with link. 50:45.970 --> 50:50.370 We're calling whatever is at this thing that we're loading into R12. 50:52.310 --> 50:56.370 So I'm going, hmm, how's that work? 50:56.370 --> 51:02.110 And I'm wanting to make sure that I understand what's going on. 51:02.110 --> 51:06.430 So I walk through and I'm like, okay, load immediate shift. 51:06.430 --> 51:07.390 That loads 51:10.790 --> 51:14.690 basically 40000 into R12. 51:14.690 --> 51:18.970 So the shift means shifted 16 bits. 51:19.170 --> 51:22.870 And then load word. 51:22.870 --> 51:27.750 Word is 16 bits with zero extension. 51:28.730 --> 51:33.390 That 4 with parentheses around R12. 51:33.390 --> 51:39.470 Now, when I first thought it, I'm going, that's not, I didn't actually, I got it wrong. 51:39.470 --> 51:41.010 I'll just say it. 51:41.550 --> 51:51.250 And I said, okay, that's going to say 40000 plus 4 is going to be 4004. 51:52.830 --> 51:53.890 Okay. 51:55.110 --> 51:57.490 That's not what ends up in R12. 51:57.590 --> 51:59.230 But that's what I thought. 51:59.230 --> 52:00.190 Next. 52:00.670 --> 52:02.730 So I went there. 52:02.850 --> 52:06.370 And I thought, okay, let's see what that's doing. 52:07.970 --> 52:12.090 40004, it has, let's look at the first four bytes. 52:13.950 --> 52:15.150 000D5C20. 52:15.710 --> 52:19.910 VimSec has a preview instruction option. 52:20.190 --> 52:26.630 It's control P from the keyboard to use the already selected architecture. 52:26.630 --> 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. 52:36.790 --> 52:41.050 That only shows up if it's not decoded as anything. 52:41.410 --> 52:45.570 And then I get to pick the platform, and I chose PPC embedded, PowerPC embedded. 52:47.030 --> 52:49.430 I don't know if you can hear the lightning. 52:51.890 --> 52:52.310 Okay. 52:52.310 --> 52:56.970 So I click on that, and I did it three times, because, you know, once isn't enough. 52:56.970 --> 53:01.830 And each time I got a decode exception, I'm going, uh-oh, crap, I've got a bug. 53:01.830 --> 53:06.510 I've got to go figure out why this is not working. 53:07.770 --> 53:12.530 And so next, remember, 40004. 53:13.010 --> 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. 53:20.930 --> 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. 53:33.790 --> 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. 53:46.010 --> 53:47.530 It was crazy. 53:48.030 --> 53:52.810 Made the switch to Python, and just kept adding to it. 53:52.810 --> 53:55.210 Basically, I'll make no bones. 53:55.210 --> 53:59.690 It's a pile of steaming shit code that you may not want to read. 53:59.690 --> 54:03.030 But I found it to be exceedingly useful. 54:03.030 --> 54:04.230 So I share it. 54:04.230 --> 54:06.110 Please don't hate me for it. 54:06.670 --> 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. 54:22.390 --> 54:27.970 But I really ended up using it a lot for emulators. 54:27.970 --> 54:30.410 So VimSec makes emulators available. 54:30.510 --> 54:34.690 In fact, I'm using right here what's called a workstation emulator. 54:35.110 --> 54:39.610 And workstation emulators come with some special sauce. 54:40.010 --> 54:44.190 For example... all right, I'm unplugging the laptop now. 54:44.590 --> 54:54.230 Special sauce here, you'll see weird entries for R0, R2, R3, R4, R5, R6, blah, blah, blah, blah. 54:54.230 --> 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. 55:15.770 --> 55:25.110 So it just takes and puts specialized numbers into each of those locations that will then trace through code. 55:25.110 --> 55:37.430 And we'll be able to see if any uninitialized registers are accessed before assigning values to them. 55:37.430 --> 55:44.570 Because that could mean either an uninitialized variable, or it could mean that that's an argument. 55:44.570 --> 55:52.230 So we use this to identify calling convention and to do other various analysis. 55:52.630 --> 55:59.010 So the first instruction is a load immediate shift of 4 into R12. 55:59.010 --> 56:00.950 So 4, 0, 0, 0, 0. 56:01.910 --> 56:03.630 You can see that at the bottom. 56:03.650 --> 56:05.570 In fact, hold on, back up, Aaron. 56:05.690 --> 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. 56:15.250 --> 56:19.890 You'll see that I print out a whole bunch of interesting registers for each instruction. 56:19.890 --> 56:21.510 And that's kind of how I am with GDB, too. 56:21.510 --> 56:28.230 I like dump all the things, and this is actually a lot better than doing info register after every instruction. 56:28.370 --> 56:35.170 But then the Emutils throws in anything that could be a dereference. 56:35.170 --> 56:39.890 It prints out some context around that data. 56:40.010 --> 56:43.730 So let's see. 56:43.730 --> 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. 56:54.530 --> 56:57.150 So it says, oh, okay, there's an immediate 4 here. 56:57.150 --> 56:58.030 That could be an address. 56:58.030 --> 57:02.990 So let's kind of look at that, because memory address 4 is valid in this case. 57:03.390 --> 57:03.970 Okay. 57:04.010 --> 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. 57:13.990 --> 57:15.050 Thanks, Aaron. 57:16.530 --> 57:18.350 So R12 shows up. 57:18.350 --> 57:18.750 Okay. 57:18.750 --> 57:20.350 4, 0, 0, 0, 0. 57:20.350 --> 57:21.110 Cool. 57:21.950 --> 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. 57:32.790 --> 57:40.150 So the next instruction is that LWZ R12 4 with parentheses wrapped around R12. 57:40.150 --> 57:40.510 Okay. 57:40.510 --> 57:41.730 What's that do? 57:42.330 --> 57:47.590 I think that should create an address 4, 0, 0, 0, 4. 57:49.330 --> 57:50.510 Yep. 57:50.510 --> 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. 57:59.250 --> 58:06.310 It then prints out some context data around D5C20. 58:06.570 --> 58:08.430 No idea why. 58:08.910 --> 58:09.470 Okay. 58:09.470 --> 58:10.130 I do. 58:10.130 --> 58:11.470 Spoiler alert, though. 58:11.970 --> 58:13.550 4, 0, 0, 0, 4. 58:13.550 --> 58:13.950 Okay. 58:13.950 --> 58:14.950 Oh, that's it. 58:14.950 --> 58:21.210 I must... this must add 4 to 440,000 hex. 58:21.410 --> 58:23.730 And so it's printing off... oh, wait. 58:23.730 --> 58:30.150 4,000... 40,004 starts off with D5C20. 58:30.350 --> 58:31.090 Huh. 58:31.090 --> 58:32.330 So hit enter. 58:34.780 --> 58:35.580 Okay. 58:35.580 --> 58:40.740 So that instruction updated R12, and it put D5C20. 58:40.740 --> 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. 58:52.460 --> 58:57.560 It is actually adding them together and using that as a memory dereference point. 58:57.620 --> 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. 59:09.860 --> 59:16.160 So if I go to D5C20, I'm going to be able to decode code, or it may already be decoded. 59:16.320 --> 59:19.900 So we move R12 into counter, and then we branch. 59:20.580 --> 59:21.340 Okay. 59:21.340 --> 59:28.420 And we don't have time to really talk much about... actually, we are out of time. 59:28.420 --> 59:32.960 I don't have time to talk about Symbolics much today, but that's coming. 59:33.080 --> 59:35.140 But I did want to throw this at you. 59:35.220 --> 59:41.280 Right-clicking, I have a Symbolics window up, and so I send that address to Symbolic zero. 59:41.280 --> 59:42.340 That's the window. 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. 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. 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. 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. 01:00:30.680 --> 01:00:38.180 So as I scroll through the different paths, those yellow backgrounded things will change. 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. 01:00:53.480 --> 01:00:55.560 And then the arguments are listed here. 01:00:55.560 --> 01:00:59.360 And you'll notice some of these, the cascades. 01:00:59.360 --> 01:01:03.260 So up above, you've got 23C60 as a call. 01:01:03.260 --> 01:01:08.220 The results of that are then used in various different things throughout the analysis. 01:01:08.940 --> 01:01:11.480 And with that, I think we're about done. 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. 01:01:16.400 --> 01:01:20.120 Yeah, well, let's let's take a second and talk about future, just for future. 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. 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. 01:01:42.360 --> 01:01:48.700 So the IBMI and the P-series, the power stuff. 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. 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. 01:02:12.180 --> 01:02:15.120 So that's all for that slide. 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. 01:02:25.140 --> 01:02:27.400 You have to teach me some math, I guess. 01:02:28.520 --> 01:02:31.360 Okay, so we want to throw in some resources. 01:02:31.560 --> 01:02:34.360 Yeah, so DevSec. 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. 01:02:44.480 --> 01:02:48.440 But these are some of the more useful ones, at least for embedded. 01:02:48.800 --> 01:02:50.060 We didn't even touch on it. 01:02:50.060 --> 01:02:59.580 SPE is kind of the PSP stuff for embedded NXP processors. 01:02:59.580 --> 01:03:02.680 You can see this is the NXP files. 01:03:04.900 --> 01:03:06.080 They're subtle. 01:03:08.820 --> 01:03:12.560 I think the weather is telling us it's time to move on, isn't it? 01:03:12.560 --> 01:03:13.800 Yeah, no doubt. 01:03:14.600 --> 01:03:15.360 All right. 01:03:15.700 --> 01:03:18.300 No time for Q&A, but you can hit us in... 01:03:18.900 --> 01:03:20.320 We'll be in Discord. 01:03:21.420 --> 01:03:21.780 All right. 01:03:21.780 --> 01:03:22.620 Thank you all. 01:03:23.520 --> 01:03:24.580 Thank you, Aaron. 01:03:24.740 --> 01:03:25.760 No, thank you.