[00:00.760 --> 00:08.040]  Let's kick it. Normally, I would like to look out and gaze into your eyes and figure out,
[00:08.040 --> 00:12.820]  by peering into your soul, what's bothering you, what's exciting you, whether you're engaged,
[00:12.820 --> 00:17.820]  if you're on your phone. But since I can't, I'm just going to throw pencils there and pick on
[00:17.820 --> 00:31.600]  him. That's fine. Go ahead. Oh, in order of events here, we're going to do some dry PPC,
[00:31.600 --> 00:37.780]  because we're gigantic nerds. We're going to talk about the kind of guts of this,
[00:37.780 --> 00:46.780]  which is the vivisect stuff. Who cares about PowerPC?
[00:49.140 --> 00:52.820]  Only us nerds, right? 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:14.360]  I'm going to insert an x86 joke here. We've been programming PowerPC for a long time.
[01:15.000 --> 01:23.480]  We always used to pick on the x86 people. And the reverse engineers care, which is an
[01:23.480 --> 01:31.120]  interesting topic, because the tools for doing that are not that great. Oh, and I'm pointing
[01:31.120 --> 01:35.100]  on my screen like people can actually see me. Not like I'm pointing up at the...
[01:37.240 --> 01:42.380]  NMFTA, they care. 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:50.760]  Who am I? Oh, okay.
[01:50.960 --> 01:53.700]  We skipped the intro slides here.
[01:53.700 --> 02:00.240]  I guess so. I am Aaron, or Acorn. I'm a security researcher with Grimm.
[02:00.930 --> 02:06.960]  For most of my career, I was doing embedded software and system development,
[02:06.960 --> 02:13.540]  used typically on safety critical systems. I've worked on telecom and Motorola.
[02:13.540 --> 02:22.160]  And I've worked on medical devices, industrial control, aerospace, a wide array of different
[02:22.160 --> 02:26.470]  platforms and architectures and processors and languages and junk.
[02:26.470 --> 02:30.590]  And now I get to do what I've always wanted to do, which is
[02:30.590 --> 02:32.990]  pull things apart and figure out how they work.
[02:34.350 --> 02:37.990]  Indeed. Awesome. I'm so glad to hear that you love that.
[02:38.850 --> 02:47.730]  And I am Atlas. I've been hacking, reversing stuff for about 15 years. And I've had the
[02:47.730 --> 02:53.170]  opportunity, the good fortune to hack with some of the most amazing people on some of the most
[02:53.170 --> 03:00.670]  intriguing targets, including virtual machines, smart meters, all sorts of RF things, automotive
[03:00.670 --> 03:11.450]  embedded things. And now, as of recent, space things. Please forgive me if I snore sometime
[03:11.450 --> 03:17.430]  during the presentation. Aaron, you'll have to yell. I was up for 26 hours straight hacking
[03:17.430 --> 03:23.970]  satellites last night. And when my kids got up and started meandering around the house at 9.30
[03:23.970 --> 03:29.790]  this morning, I thought I should probably go to bed. So I did get about four and a half hours
[03:29.790 --> 03:34.970]  sleep. So I didn't short you guys too much. That's what I would have normally gotten in DEF CON
[03:34.970 --> 03:43.750]  Vegas. So a little about me. I love, just like Aaron, I love tearing things apart, figuring how
[03:43.750 --> 03:52.870]  they work, how we can make them work better or interesting. I am a Christian, a father of three
[03:52.870 --> 04:05.270]  and a husband of one. And I love talking to you guys. So why would anybody other than us nerds
[04:05.270 --> 04:09.790]  care, Aaron? Where do we see power PC chips these days?
[04:10.730 --> 04:26.770]  Well, we see them in my mouse works. Or not, whichever, you know. Oh, I'm skipping ahead.
[04:27.490 --> 04:35.330]  I guess I think we got a word. Where we see them here today, mainframes, IBM, all of those systems
[04:35.330 --> 04:43.150]  that, what is it called now? I, system I, I think is what they call it. Oh yeah, IBM I.
[04:43.510 --> 04:52.310]  Those are all power PC systems, not the weird 48-bit things they used to be. Embedded controls,
[04:52.310 --> 05:03.330]  right? Yep. IBM also, they've got their I platforms and their AIX, used to be the RS6000s.
[05:04.450 --> 05:10.330]  And they all run on power PC. In fact, they've put them under the umbrella known as the power
[05:11.650 --> 05:21.550]  systems. So go figure. 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:32.750]  Oh, rhetorical questions here. Automotive, industrial systems, aerospace,
[05:32.750 --> 05:42.210]  they're heavily favored for platforms that, I guess, prize, what, reliability, durability,
[05:42.210 --> 05:48.510]  determinism. The littler things though. Yeah. Not the things that you carry in your backpack.
[05:48.510 --> 05:54.490]  Well, I mean, maybe, but not your laptops and. Right. Embedded things. NXP has dominated that
[05:54.490 --> 06:00.830]  space. Right. Yeah. They, they also have satellites and space things, but unfortunately
[06:01.730 --> 06:06.090]  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.610]  But for power PC is very traditional, typically or radiation hardened systems. I think they call
[06:18.610 --> 06:27.270]  it the rad 750 is a very, very common one. It's the old G3 series stuff. Assuming I remember
[06:27.270 --> 06:32.990]  right. It's been a few years since I confirmed. But yeah, so power PC, for those of you who don't
[06:32.990 --> 06:42.070]  know, right. Risk. Kind of. Fixed instruction words. About every, every risk process I ran
[06:42.070 --> 06:50.350]  into actually. You know, every time you get a risk platform, you start finding very non-reduced
[06:50.350 --> 06:56.230]  parts of it very quickly. Fixed instruction word, 32 bits, every instruction.
[06:57.450 --> 07:04.510]  Kind of. We saw a bit of a sneak preview on that of my other work slides here. Those of you who
[07:04.510 --> 07:10.390]  are familiar with Apple in the nineties and early two thousands will of course recognize
[07:11.050 --> 07:21.030]  power PC from that. Power books, right? Power books. Their releases, the G3, G4,
[07:21.750 --> 07:28.070]  G5. I think they were all actually tied into the different releases of the,
[07:28.770 --> 07:36.630]  the power PC architecture documentation. Yep. So yeah, the things that they're used in
[07:36.630 --> 07:41.590]  bed controls, IBM and old apples. I should have said old Apple computers there, right?
[07:41.590 --> 07:47.450]  I guess it's the slides titled history lesson. So I thought it was kind of obvious.
[07:47.930 --> 07:56.290]  Here's the caveat for a 32 bit thing. Freescale created a variable instruction word
[07:57.550 --> 08:07.970]  within APU, which is what power PC companies call extensions, extra things.
[08:07.970 --> 08:12.850]  If evolution and Darwinism was applied to computer systems,
[08:13.590 --> 08:18.810]  APUs would be the mechanism through which evolution occurred. And the platypus was
[08:18.810 --> 08:27.930]  formulated. So not my favorite thing. They have fractured the, the entire power PC world and made
[08:27.930 --> 08:34.150]  it ever so difficult to make good tooling for it, but we'll get to that. Yeah. Yeah.
[08:35.370 --> 08:38.870]  Found this fun slide here. It's probably only interesting to me.
[08:39.430 --> 08:45.790]  I loved it. I love the title of it though. Power architecture demystified, which is an extremely
[08:45.790 --> 08:52.370]  bold claim for anybody who's familiar with power PC. But here they've got the, you know,
[08:52.370 --> 08:58.470]  there's this little highlighted section here. Somebody who worked at Freescale slash NXP. I
[08:58.470 --> 09:02.650]  think this was produced in 2000. This paper was from 2007. So this would be somebody who was at
[09:02.650 --> 09:09.670]  Freescale at the time. With benchmarking, they said that the code is 30% smaller with only a 5%
[09:09.670 --> 09:18.110]  reduction in performance. You know what I read that to say? What? I read that to say ARM's doing
[09:18.110 --> 09:24.790]  it. We should probably do something like that too. Probably. 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:41.310]  Yeah. 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:57.550]  And it's kind of a big deal because as Alice said, it makes producing tooling very, very
[09:57.550 --> 10:07.270]  complicated. Like making PowerPC tools is like making tools for like 20 different processors
[10:07.270 --> 10:13.770]  for architectures. And reading the documentation for them makes it feel like you're making it,
[10:13.770 --> 10:20.830]  you're making tools for thousands of architectures. Yeah. Because they don't coalesce well.
[10:23.540 --> 10:28.060]  So, Vivisect. Can you tell me something about Vivisect?
[10:28.060 --> 10:34.800]  Yeah. So, Vivisect is a binary analysis framework that was created specifically
[10:34.800 --> 10:38.040]  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:54.880]  It speaks my language, so to speak. It's pure Python. It allows me a ton of power
[10:57.160 --> 11:03.320]  in many different ways, including from the command line. I'm an IPython person. I go to
[11:03.320 --> 11:09.840]  work and I type IPython and I feel like I'm starting to do something meaningful. So, there's
[11:09.920 --> 11:17.100]  a lot of cool, meaningful things I can do with Vivisect there. But it's been forward thinking
[11:17.100 --> 11:25.380]  since it was originally created. And so, instead of a disassembly framework, we got every
[11:25.380 --> 11:32.620]  architecture that you disassemble for has an emulator wrapped in with it. But not just an
[11:32.620 --> 11:41.040]  emulator, like a QEMU, a partial emulation engine, which allows for things to have
[11:41.040 --> 11:46.920]  taint tracking, for example. If we try to read memory that doesn't exist or if we try to access
[11:48.140 --> 11:54.820]  uninitialized variables or whatever. So, we can focus not just on code flow from the beginning
[11:54.820 --> 11:59.920]  of a program, but we can say, hey, this function looks interesting. Give me a feel for what it
[11:59.920 --> 12:06.480]  does and an emulator can roll through and say, oop, that's a problem, but I've been programmed
[12:06.480 --> 12:13.140]  to keep going and I just kind of keep track of that. Or, oop, that's ARG1. So, I know that ARG1
[12:13.140 --> 12:22.020]  is now going to propagate through this calculation and whatnot. But then a few years later, I was
[12:22.020 --> 12:29.060]  talking to Vizi and he said, you know, emulation is awesome and super powerful, but you really
[12:29.060 --> 12:36.260]  need to focus on symbolic execution. And I'm like, what is that? And I looked into it and it turns
[12:36.260 --> 12:41.560]  out the first thing that I found of interest with symbolic execution, this is way before CGC was
[12:41.560 --> 12:51.180]  around, was NASA talking about how they were using symbolic execution to identify flaws and potential
[12:51.180 --> 12:59.040]  problems before shipping satellites into space or the Mars rovers to Mars, since repairing those
[12:59.040 --> 13:11.920]  things kind of sucks. So, BIVSEC also has, wraps in cross-platform debugging in a subsection that
[13:11.920 --> 13:19.340]  we don't call out here called BDB, vulnerability debugger. And so, these things all wrap around
[13:19.340 --> 13:31.280]  and support x86, 32 and 64-bit. MSP430, there's also 8051 in there, ARM and thumb mode,
[13:31.280 --> 13:40.820]  v7 at the moment, we have some deltas to wrap in ARM v8, z80, hate, I love just saying that name
[13:40.820 --> 13:45.820]  because it's also another one of those architectures that I just really love.
[13:48.420 --> 13:53.220]  I think I love BIVSEC the most because not only is it really pretty because it's green
[13:53.220 --> 14:01.720]  and black for most things, but the ability to easily extend it and do inspection of what's
[14:01.720 --> 14:08.000]  going on under the hood, so I understand how to reuse the tooling and use it to the best of
[14:08.000 --> 14:16.300]  my ability in my own external tools. So, command line stuff, just programming plugins, whatnot.
[14:17.040 --> 14:20.980]  Okay, enough about that. I've said four and a half hours sleep.
[14:23.360 --> 14:33.700]  So, why don't you talk about this, Aaron? Well, let me give a little backstory. A while back,
[14:34.340 --> 14:39.760]  I was already working on wrapping PowerPC into BIVSEC, and
[14:41.760 --> 14:48.840]  NMFTA said, we'd like to fund some of that research, just make sure that it benefits the
[14:48.840 --> 14:57.280]  world. And so, it was already open source, so that was an easy sell. And so, they paid for us
[14:57.280 --> 15:05.800]  for a bit of research, and Aaron donated a lot of his time as well, in addition, over and above
[15:05.800 --> 15:12.580]  what we were paid to do, just because he's awesome and recognizes the value. So, I tapped him, and
[15:12.580 --> 15:18.000]  it was one of the best things that I could have done for that project, because, well,
[15:18.000 --> 15:24.200]  I'll tell you that later. Talk about this, Aaron. Sure, sure. So, adding an ISA to BIVSEC,
[15:25.580 --> 15:32.460]  as Alex said, there's a couple different parts of it. You've got to figure out how to disassemble
[15:32.460 --> 15:35.600]  the different instructions, right? You've got to get your documentation to figure out what the
[15:35.600 --> 15:41.400]  instructions look like. Then you need to figure out how to emulate their behavior. You need to...
[15:41.400 --> 15:46.440]  symbolic analysis is a bit outside of my wheelhouse there.
[15:46.820 --> 15:52.060]  Yeah, I took most of that on. It's a different way of thinking.
[15:53.040 --> 15:58.580]  Testing is not where I thought I would end up doing a lot of work, but apparently, it's where
[15:58.580 --> 16:07.360]  I did a lot of work. Figuring out how to test tools to handle a new architecture is interesting.
[16:07.800 --> 16:10.960]  You know, how do you... where do you get that information from? Obviously, you get your
[16:10.960 --> 16:16.760]  documentation. At least, I hope you do. It's going to be a stretch. You get existing compilers and
[16:16.760 --> 16:24.160]  object dump tool. That's useful. 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.820]  You can just make gigantic lists of instructions to parse from your documentation. Don't forget,
[16:35.820 --> 16:42.160]  you also have to figure out how to do the behavior of that. No matter which one of these paths you
[16:42.160 --> 16:49.020]  take. Oh, and also option D, which I forgot to put down there, which is get the hardware
[16:49.020 --> 16:58.080]  and run it. For PowerPC, that would really mean get, like, what, 20, 30, 40 different pieces of
[16:58.080 --> 17:03.620]  hardware. It's not going to be challenging to do it for everything, but it is useful.
[17:04.080 --> 17:08.440]  We got our hands on a couple different architectures for it. A couple different
[17:08.440 --> 17:14.100]  platforms. One embedded and one more server-esque.
[17:15.820 --> 17:25.080]  So we were able to have all that at our disposal. So, Aaron, this sounds a lot like magic.
[17:25.400 --> 17:26.480]  It does.
[17:28.860 --> 17:36.220]  But what's it really mean? What's it look like to write disassembly code or an emulation
[17:37.040 --> 17:39.300]  instruction? How do you emulate an instruction?
[17:40.680 --> 17:42.680]  How do you emulate an instruction?
[17:43.220 --> 17:49.840]  Mostly the disassembly part. 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 --> 18:02.520]  Sure. Well, you know, once you... I guess it's basically about the numbers, right? Everything
[18:03.200 --> 18:09.280]  at its base form in computers is a number. Hexadecimal, decimal, whichever way you prefer
[18:09.280 --> 18:15.740]  to read it. Everything is numbers. If it's data, if it's code, whatever it is, it's just a number.
[18:15.840 --> 18:21.700]  So you just read in byte by byte or four bytes by four bytes or however many bytes by however
[18:21.700 --> 18:27.140]  many bytes for your architecture. And then you just start taking a look. This particular pattern
[18:27.140 --> 18:31.820]  here means that it's this instruction. 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.780]  Wish we could have gotten your scrolling version going. That would have been...
[18:41.780 --> 18:47.180]  Yeah, I don't know. For some reason, I just can't... media, you know...
[18:47.740 --> 18:54.720]  Aaron wrote a list of about 30... he took a list of about 30 times this length
[18:54.720 --> 18:59.500]  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:15.180]  Yeah, so in this particular case, what I started doing was I took a PowerPC Linux kernel
[19:15.760 --> 19:22.240]  and I disassembled it, which I figured that that would have a fantastic variety of instructions of
[19:22.240 --> 19:27.440]  different encodings and forms. And then what you do after you do that is you go through and you
[19:27.440 --> 19:32.860]  fix all the bugs. Because every single one of those four things I talked about, the documentation,
[19:32.860 --> 19:38.500]  the disassembler, the object dump, the compiler, the hardware, every one of those, of course,
[19:38.500 --> 19:42.700]  for anybody who's done embedded development or tool development knows, every single one of those
[19:42.700 --> 19:48.080]  has bugs. So you go through and you fix your bugs and then you find other bugs that are not your
[19:48.080 --> 19:54.960]  bugs but are actually bugs in other tools. So that's kind of the process there. You go through
[19:54.960 --> 20:04.060]  and you just fix the bugs. But yeah, so it's not magic. You just start with the data.
[20:04.280 --> 20:10.840]  You go through and then in Python, you make the function. When you match this pattern,
[20:10.840 --> 20:19.120]  then you use this function to emulate it, right? So Aaron, he really ended up taking
[20:19.120 --> 20:27.660]  charge of the testing and it was incredible. He wrote the most versatile testing or
[20:29.460 --> 20:35.300]  instruction analysis framework I've seen. He basically rewrote an entire disassembler.
[20:35.380 --> 20:40.880]  But instead of spitting out Python objects, he spit out this metadata that he could then bend
[20:40.880 --> 20:47.520]  to his will going, oh, you want it represented this way? And boom, the unit tests started just
[20:47.520 --> 20:53.460]  looking a different way. Oh, that's how that is. Yeah, that's a weird thing. Nobody really agrees
[20:53.460 --> 21:00.080]  on how that works. So that's how Vivisect wants to do it. Okay, I gotcha. So this all goes back
[21:00.080 --> 21:07.560]  to the fact that it's all just bits. When you type a letter to your mom, when you write your report,
[21:07.560 --> 21:15.980]  when you download a video or a picture, that's all just bits. The computer system decides what
[21:15.980 --> 21:20.900]  to do with them. And our disassembler is doing the same thing. It takes in just a
[21:20.900 --> 21:26.680]  string of bytes because bytes are the easiest way for us to deal with the world.
[21:26.680 --> 21:35.020]  And then it looks at a combination of the bits and says, based on these things,
[21:35.020 --> 21:39.860]  that's this instruction. And every architecture kind of has its own nuance and its own flow
[21:39.860 --> 21:47.500]  for Intel. It goes byte by byte going, hey, this first byte puts us into this table of
[21:48.200 --> 21:53.100]  options for instructions. And oh, we hit the second byte here. That falls into another table
[21:53.100 --> 22:00.980]  of instruction options. ARM, it's kind of like a bunch of bit masks and comparisons.
[22:01.200 --> 22:06.900]  Take the thing, mask it with this, and compare it against this. Oh, it's not that? Okay,
[22:07.300 --> 22:11.960]  and it moves down the list until it finds the escape hatch. And then it goes down the escape
[22:11.960 --> 22:17.820]  hatch route when there's a match and says, okay, now pull in these bits and put them as this and
[22:17.820 --> 22:24.420]  that and spits out an op code with operands. It's pretty close to how the PowerPC stuff
[22:24.420 --> 22:33.300]  in VitaSec ended up. Lots of bit masking. Yes. With all these different instructions here,
[22:33.300 --> 22:39.780]  the fun thing with the VLE parts is that they've got different modes. They can run
[22:39.780 --> 22:48.740]  variable instruction mode or full 32-bit instruction mode. But the full 32-bit
[22:48.740 --> 22:55.020]  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:07.440]  Hmm? Can I just look? Yep. Oh, okay.
[23:11.240 --> 23:19.100]  So ARM, if anybody's watched, if anybody's paid attention or done reversing on ARM instructions,
[23:19.840 --> 23:31.500]  ARM breaks things down into different modes of operation by basically jumping,
[23:32.140 --> 23:38.880]  address, to go from ARM to thumb mode. It's a simplistic way of viewing it,
[23:38.880 --> 23:43.440]  but basically that's it. So you can have ARM instructions right next to,
[23:44.300 --> 23:50.580]  grouped right next to a bunch of thumb instructions. In PowerPC with VLE,
[23:50.580 --> 23:58.860]  with variable length encoding, they're not the same. PPC and PowerPC decided to
[23:58.860 --> 24:06.720]  mark individual memory pages as being either VLE or straight PowerPC.
[24:07.720 --> 24:12.940]  So that was actually a push for me to wrap that into Vivisect where I'm going,
[24:12.940 --> 24:17.600]  this is the first time I've ever had that, where it depends on the memory page.
[24:17.600 --> 24:25.140]  We have to configure the memory pages to be either VLE or not so that when the disassembler,
[24:25.140 --> 24:32.960]  that's kind of dumb for all intents and purposes, it jumps to, you give it an address and it's got
[24:32.960 --> 24:42.300]  to spit out an instruction at you. It needs to know which way to decode. So that's just how
[24:42.300 --> 24:48.400]  PowerPC chose to do it. Sure. So if you, and not every single PowerPC processor supports
[24:48.400 --> 24:57.160]  full PowerPC, or the very VLE, maybe they do both. Some of them do only one or the other.
[24:57.520 --> 25:02.160]  Embedded parts, they don't have Altebec for those. Oh, here's another, yeah, no doubt.
[25:02.160 --> 25:09.360]  Altebec, the vector math instructions. Another thing is in most architectures,
[25:09.360 --> 25:17.200]  most embedded architectures in particular, you start out with an interrupt vector table
[25:17.200 --> 25:22.440]  with a reset vector in it. So when you power up the reset vector, however that architecture
[25:22.440 --> 25:28.280]  implements it, the reset vector points to an interrupt service routine or interrupt handler
[25:28.880 --> 25:36.020]  that starts up the processor and boots. And many architectures, that's like address zero.
[25:38.340 --> 25:46.400]  Not PowerPC. PowerPC, there's weird ways of figuring out where code should start. In fact,
[25:46.960 --> 25:52.760]  there's a boot assist module in a lot of the architectures. And the boot assist module is
[25:52.760 --> 25:58.540]  the thing that gets code execution first. And it just starts scouring through specific areas of
[25:58.540 --> 26:06.080]  the flash or hard drive or whatever you're running as your storage. And it looks for a signature.
[26:06.900 --> 26:16.520]  And if the signature is on the right boundary, and it knows then that somewhere a little bit
[26:16.520 --> 26:24.620]  later is a pointer to where instructions should start executing at power up. So weird things,
[26:24.620 --> 26:30.620]  just like all sorts of weirdness. For a long time, PowerPCs had the ability to change which
[26:30.620 --> 26:39.800]  page of memory is big-ending or little-ending. They call it the TLB, just a slightly more
[26:39.800 --> 26:46.600]  granular MMU, I guess. I don't know. Hey, at least it's not a 27-bit middle-ending
[26:46.600 --> 26:54.640]  architecture. I will give it that much. It could be worse. Yeah, I don't know. The
[26:54.640 --> 27:02.880]  documentation, boy, that was really annoying. What was it? The registers. It took me forever
[27:02.880 --> 27:07.780]  because the documentation said the registers are 64 bits. It's interesting for an embedded
[27:07.780 --> 27:15.020]  processor. Oh, except for when you're in VLE mode, you can't access the upper 32 bits of those
[27:15.020 --> 27:23.800]  registers. Okay. Fine. Whatever. Oh, by the way, they're numbered 0 to 31 as the highest,
[27:23.800 --> 27:32.220]  most significant bits. When you're talking about 32-bit mode, you're talking about 32 through 63.
[27:32.220 --> 27:38.220]  Everything is 32 through 63. The architecture isn't the problem. The people writing the freaking
[27:38.220 --> 27:42.780]  documentation are. And it's always been that way. You can't blame the newer stuff for that. It's
[27:42.780 --> 27:48.940]  always been that way. I blame IBM for that one. I'm betting it was them. I don't know. It reads
[27:48.940 --> 27:55.400]  very much like a bunch of companies in the early 90s kind of got together and eventually agreed on
[27:55.400 --> 28:00.820]  stuff. And they agreed by doing it in weird ways. By bringing their weird way to the table and
[28:00.820 --> 28:09.080]  saying you must do it this way because we did it already. Right, right. So let's do something fun
[28:09.080 --> 28:18.680]  here. Okay. So PowerPC is a little different. We're here. We're at DEF CON. We're talking about
[28:18.680 --> 28:26.800]  security things, right? How do you exploit PowerPC? Or no, no. Sorry. Damn it. I did it wrong.
[28:28.240 --> 28:33.320]  Go back a few seconds. Pretend I didn't say that. PowerPC is secure, right? Nobody knows
[28:33.320 --> 28:39.760]  the number. You can hack it. Absolutely. It's in Big Iron. Those are unhackable. Right, right.
[28:42.320 --> 28:50.800]  So obviously, I mean, it's not. It's not impossible to hack. You just need to do it differently.
[28:52.180 --> 28:59.020]  Every processor, it reads in data, spits out data, interprets data as instructions, as I said
[28:59.020 --> 29:05.480]  earlier. You just need to figure out the way you can tell it what's what. So there's no jump ESP
[29:05.480 --> 29:15.620]  instruction in PowerPC, unfortunately, as there's no way to branch directly to a general purpose
[29:15.620 --> 29:27.000]  register. And as the previous slide here pointed out, the stack is a general purpose register,
[29:27.000 --> 29:32.840]  but the link register, very much like ARM, link register, though, is a special register. If you
[29:32.840 --> 29:37.940]  go and look at the documentation for the special purpose registers in PowerPC, I mean, I don't
[29:37.940 --> 29:44.140]  know. Alice, do you remember how many? There's like thousands. Only a couple thousand. I don't
[29:44.140 --> 29:49.800]  even know what you do with all of them. We have a table with a lot of them in the decoder.
[29:50.620 --> 29:56.960]  There's a lot of them. So move to link register is actually not even an instruction. It's actually
[29:56.960 --> 30:12.640]  move to SPR with LR as an operand. That's true. Move MTSPR 1, LR. MTLR is a mnemonic that some
[30:12.640 --> 30:20.860]  assemblers allow. Now, we like that. It's intuitively pleasing. But I'm just saying that's
[30:20.860 --> 30:27.460]  how the architecture breaks down. Yep. Yeah. So move to link register. Link register is, of
[30:27.460 --> 30:34.260]  course, where you return to. Again, like ARM, you store the value place you came from on the link
[30:34.260 --> 30:40.560]  register. And when you need to return to it, it loads an address back into the link register.
[30:40.580 --> 30:46.400]  Well, if you can make some, whatever that was stored on the stack, if you can modify that
[30:46.400 --> 30:50.840]  address on the stack, you can jump back to where you want it to go to, not where it's supposed to
[30:50.840 --> 30:56.580]  go. Account register is a weird one. Account register in PowerPC is used for a lot of jump
[30:56.580 --> 31:04.300]  tables and function pointers. So that's another one. You could just modify that and get hold of
[31:04.400 --> 31:12.620]  a switch statement. So nice little rock gadgets here. Yeah. I wanted to put some fun in here,
[31:12.620 --> 31:22.300]  you know? I love that you consider that fun. Right. Right. This was not as fun. This is not
[31:22.300 --> 31:32.380]  so fun. If you go and look at, I'd say, I don't know, probably two thirds or so,
[31:33.080 --> 31:38.380]  66% of all bugs in all PowerPC tools are related to this instruction.
[31:39.140 --> 31:45.160]  Wait, that's one instruction? Yeah, it's one instruction, right? Actually, no,
[31:45.160 --> 31:51.180]  this isn't one instruction. It's only a couple. Two or three, whatever. It doesn't matter.
[31:51.180 --> 31:58.900]  There's these rotate instructions. Rotate left with bullshit. That's what I read there.
[31:58.900 --> 32:04.940]  Rotate left. Word. Immediate. Thing. This one. 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:25.500]  We don't need to make it up, though. I mean, they included the EIEIO instruction.
[32:25.500 --> 32:33.560]  Yes. I mean, that's dropping the mic for instruction lunacy. Right. So,
[32:34.120 --> 32:38.580]  I don't have much time left in the talk, unfortunately. A little bit.
[32:39.340 --> 32:44.440]  Go ahead. Should move, probably move it along instead of making jokes about PowerPC instructions,
[32:44.440 --> 32:53.040]  as much fun as that is for me, anyway. Yep. Oh, hey, we're to story time.
[32:53.040 --> 33:03.180]  Story time with Atlas. So, we do a lot of work with a lot of people that we care very deeply for.
[33:03.240 --> 33:11.020]  And so, there's stuff that we have, but we can't use it for a talk. So, we were scouring the
[33:11.020 --> 33:17.760]  internet for something that we could show and not have to make anybody uncomfortable.
[33:17.760 --> 33:23.970]  We ended up finding a repository of a whole bunch of automotive code on some
[33:25.240 --> 33:32.220]  sketchy website. So, downloaded a bunch of things that I could identify as something
[33:32.220 --> 33:43.960]  potentially PowerPC. And thankfully, I threw one in Vivisect. And it's just a blob at this point.
[33:43.960 --> 33:54.500]  So, this is a VBF. VBF is basically a file package, almost a file format. Not really.
[33:54.500 --> 34:01.480]  It starts off with a couple headers and then goes to binary code. So, I slapped in a VBF
[34:03.440 --> 34:06.900]  into Vivisect, and I just started scouring around
[34:06.900 --> 34:14.900]  what things were. And thankfully, the very first one I loaded in,
[34:14.900 --> 34:23.820]  I guessed well. And I hit decode, or I hit C for make code. And I got a branch instruction
[34:24.420 --> 34:29.440]  followed by three NOPs, another branch instruction, followed by three NOPs, and
[34:31.080 --> 34:36.960]  a repeating pattern. There are like a thousand of these in this firmware.
[34:39.060 --> 34:45.300]  But it could have been just a weird repeating pattern. So, I wasn't going to bank on that.
[34:45.980 --> 34:49.420]  So, I started looking through. What's that, Aaron?
[34:49.420 --> 34:56.460]  Oh, I just wanted to interject here. For those of us who have been done PowerPC programming,
[34:56.460 --> 35:04.120]  this type of pattern is extremely common. PowerPC lines up every interrupt handler, every...
[35:05.180 --> 35:13.260]  what's that? 64 bytes? No. 148 bytes? Whatever. And that's very common. Of course, you'll need
[35:13.260 --> 35:19.000]  this many instructions to handle your interrupts. So, the thing that made me queasy and, well,
[35:19.000 --> 35:24.780]  it made me uncertain was that this is not a full firmware image. This is something that
[35:26.840 --> 35:35.320]  an ECU would basically have its own base image because if you have a firmware upgrade go bad,
[35:35.320 --> 35:41.020]  you don't want to lose your CAN interface, for example, because that's how you flash firmware.
[35:41.020 --> 35:48.460]  So, they have a core bootloader base image that gets the device on the CAN network and
[35:48.460 --> 35:56.100]  accesses, you know, allows access through the various tooling and protocols. And so,
[35:56.100 --> 36:01.200]  I knew that that was going to own the interrupt service routines and the interrupt vector table
[36:01.200 --> 36:06.260]  and anything that would be normally things I would go looking for in a piece of firmware.
[36:06.860 --> 36:14.460]  That wasn't in this. This was going to be something else. So, I saw this and I thought,
[36:14.460 --> 36:23.940]  it could be PowerPC and this could be a branch table that is indexed so that the base firmware
[36:23.940 --> 36:30.920]  knows, hey, this index at this address just go, boom, there's the thing and the rest of the
[36:30.920 --> 36:37.980]  firmware handles it, the new firmware that we've just installed. Or it could be some crazy other
[36:37.980 --> 36:43.940]  architecture that has nothing to do with PowerPC. You can never be certain unless you actually know
[36:43.940 --> 36:49.680]  and the VBF file in its text comment didn't have anything about what architecture. Plus,
[36:49.680 --> 36:53.280]  there's this architecture I keep running into that I don't know much about. Aaron,
[36:53.280 --> 37:01.320]  you know more about it, TriCore, that I haven't done enough reversing on to actually know if I
[37:01.320 --> 37:08.460]  would identify it. So, I was still kind of skeptical. So, next slide, Aaron.
[37:08.460 --> 37:20.220]  Yep. So, I right-click on the first address that it's being branched to and I send the target,
[37:20.220 --> 37:26.220]  the 4250C address, over to another analysis window. So, this is the VIV window. I've created
[37:26.220 --> 37:43.540]  another memory viewer called foo. Why? Because foob are best. So, anyway, I think I threw this
[37:43.540 --> 37:52.200]  in out of order. Sorry. So, here's like you can see that backup one. One slide. So, we start at
[37:52.200 --> 38:00.640]  40,000 hex. So, that's a lot bigger than 40,000. But anyway, 40,000 hex. Scroll forward one.
[38:01.640 --> 38:16.160]  And we're still doing this table thing. 1,300 hex into this firmware. And that is 130 hex
[38:16.160 --> 38:28.840]  options. So, far, just 130 hex different branch options. Okay. Now, next. So, we follow the
[38:28.840 --> 38:39.160]  location. And here's what they point at. Another table of branches that some of them point to the
[38:39.160 --> 38:46.060]  same thing. And as you can see, so, they're branching to location 43228. And you'll notice
[38:46.060 --> 38:53.220]  that the bytes that make up those instructions are not the same. It's not like boom, boom, boom,
[38:53.220 --> 38:58.200]  boom, boom, a table of all the same thing repeated. It's all the same thing, but these are
[38:58.200 --> 39:04.620]  relative branches. So, the numbers decrease as they go higher. So, the fact that each of those
[39:04.620 --> 39:11.900]  points at 43228 gives me a clue that this might actually it's getting more likely that this is
[39:12.600 --> 39:18.880]  PowerPC firmware. I mean, it's easy to just look at this. You'll start looking at those values
[39:18.880 --> 39:25.880]  that make up those instructions. It almost looks like this is just, you know, a bunch of, you
[39:25.880 --> 39:33.260]  know, sequential memory addresses or something like that. It's very weird. Yep. Okay. Next.
[39:34.020 --> 39:41.200]  Until we run into hex 43,000. And at hex 43,000, we start to see real
[39:42.340 --> 39:47.800]  instructions. Now, many architectures, you give them four bytes, they can spit out an instruction.
[39:47.800 --> 39:55.400]  So, this does not mean that it's PowerPC. But we see these things peppered throughout a little
[39:55.400 --> 40:02.680]  bit of the previous table where everything was pointing to one location. And then after a bunch
[40:02.680 --> 40:13.240]  of them, we run into move to SPR, SPR G0, and we move from R3 into that. Okay. And then we move
[40:13.240 --> 40:23.100]  from SPR counter, the counter register, into R3. So, we've stored R3 and then we put the counter
[40:23.100 --> 40:31.800]  into the counter register value into R3. And then we move to the SPR G1 from R3. Okay.
[40:32.680 --> 40:42.720]  Could be logical. Okay. Load immediate shifted zero into R3. So, we're not overwriting anything
[40:42.720 --> 40:48.300]  that we've just put into R3 without storing R3. So, okay. Sanity still exists.
[40:49.300 --> 40:55.440]  Load word zero extended. I think that's what that means. Although, I've been having to look up a lot
[40:55.440 --> 41:08.440]  of words. Okay. So, we take R3 and yeah, anyway, you're seeing the pattern. Things are actually
[41:08.440 --> 41:13.440]  starting to make sense. And after doing things with R3, we then move it into the counter register.
[41:14.400 --> 41:22.080]  We load immediate zero into register three. So, we wipe out, we clear R3 again, and then we branch
[41:22.080 --> 41:29.640]  to counter. Okay. That makes sense. 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:39.900]  Because there's no branch with a link. There's no return. No nothing. It just goes somewhere.
[41:40.540 --> 41:45.520]  After that, though, we see STWU. No, that's not shut the what up.
[41:47.840 --> 41:54.200]  And this, man, I captured the pointer right in front of that. Right in front of that. Anyway,
[41:54.200 --> 42:01.140]  that's actually part of a function prologue. A very standard function prologue for RPC.
[42:01.220 --> 42:10.020]  So, R1. R1 is a stack pointer, right? So, this is moving the stack pointer.
[42:10.540 --> 42:21.580]  Yep. Basically storing the stack pointer and storing register 0, 2, 4, 5, 6, 7, 8, 9, 10,
[42:21.580 --> 42:29.000]  11, 12 into the stack. So, we create stack space and then we write registers into it. Okay. That
[42:29.000 --> 42:35.040]  sounds legit. The PowerPC calling convention includes handing arguments as registers.
[42:36.060 --> 42:41.440]  And you got to clean up after yourself when you're done. So, storing the registers
[42:42.100 --> 42:50.360]  that aren't arguments totally makes sense. Move from SPR, the link register into R0.
[42:50.360 --> 42:58.240]  Okay. So, our link register now, the return address now lives in R0. And then, okay. I'm
[42:58.240 --> 43:04.760]  convinced. This is PowerPC. So, next? Well, from the point of view of somebody
[43:04.760 --> 43:11.720]  who's written RPC for embedded systems, SR0, SR1 down at the bottom there, those are special
[43:11.720 --> 43:16.360]  purpose registers that are the system state, system control registers, telling you, like,
[43:16.360 --> 43:21.660]  what your current state is. The stuff up at the top of this, this was taking a look at
[43:24.400 --> 43:30.000]  SPRG0 and G1, I believe are... oh, boy. It's been too long. I probably shouldn't say
[43:30.000 --> 43:36.700]  anything. Anyway, what it looks like to me is it looks like it's saying what address caused
[43:36.700 --> 43:43.760]  the particular interrupt. Why are we here? Right? And then, it's looking up, it's doing a
[43:43.760 --> 43:51.100]  calculation based on R3, which is, I guess, zero, right? So, it's jumping. For some reason,
[43:51.100 --> 43:57.840]  doing a jump calculation to one specific address. This LIS... I keep pointing my screen,
[43:57.840 --> 44:01.960]  like people can see what I'm pointing at. I can't help it. Make sure you're pointing at the camera.
[44:01.960 --> 44:08.440]  At the camera? Right. So, LIS, LW, those are very common for PowerPC. It's also something that a
[44:08.440 --> 44:16.180]  lot of first engineering tools have issues with, because this is PowerPC fixed instruction work.
[44:16.180 --> 44:19.760]  You can't have a 32-bit address in one instruction. You've got to have two,
[44:19.760 --> 44:26.120]  so it's lower 16, and then low, the upper 16 bits. Right.
[44:27.140 --> 44:33.720]  Which is very common in any fixed width instruction architecture, because,
[44:33.720 --> 44:40.200]  turns out, the register size typically is the same as the instruction size. So,
[44:40.200 --> 44:44.900]  try loading the full value into a register in one instruction. It's impossible,
[44:44.900 --> 44:51.020]  unless you store the value and somehow dereference some other address to load it
[44:51.020 --> 44:58.560]  into a register, which ARM does, actually, all the time. Okay. So, I wanted to throw in
[44:58.560 --> 45:06.480]  an interesting thing. There's so many different details that make Vivisective fun and exciting
[45:06.480 --> 45:13.820]  reversing platform. Part of it is that there are many things that are not hidden from you.
[45:14.380 --> 45:21.520]  So, one of the things that Vivisect does for branch analysis, for switch case analysis,
[45:21.520 --> 45:29.100]  for example, most often, a switch case turns into one or more dynamic branches.
[45:29.740 --> 45:37.940]  So, if you've got, let's say, switch on this variable being 1, 2, 3, 4, and 5. Okay. Those
[45:37.940 --> 45:44.280]  are, those different options are going to be stored as pointers to the code that handles
[45:44.280 --> 45:53.400]  each of those options. And then indexing into a table to grab the address to then branch right
[45:53.400 --> 45:57.980]  into that. That's a dynamic branch. You cannot figure out where that branch is supposed to go
[45:57.980 --> 46:05.540]  without an emulator. Or a lot of emulation written down into code that's not an emulator.
[46:06.340 --> 46:17.720]  There's also a lot of things like C++ method invocation. When you've got multiple inheritance
[46:17.720 --> 46:28.400]  with virtual function tables, you basically have a table that lists each type of call. So,
[46:28.400 --> 46:38.320]  an object called ball, and I have a method, get color, bounce, throw in the trash,
[46:38.320 --> 46:45.080]  throw at my sister. These are all method calls that go into a virtual function table.
[46:45.080 --> 46:52.700]  And so, when executing any of those, actually, the code goes, okay, grab my virtual function
[46:52.700 --> 47:00.660]  table and index into that virtual function table and then call, make the desired call.
[47:00.980 --> 47:07.880]  And since all of this is done on heap, typically heap objects that just have a pointer to a virtual
[47:07.880 --> 47:14.140]  function table, there's no way that the code can just say, this is a foo call that goes to this
[47:14.140 --> 47:21.460]  address location. At least not when virtual function tables are involved. So, we get,
[47:21.460 --> 47:27.480]  as part of the process, Vivisect stores all dynamic branches in what's called a VA set,
[47:27.480 --> 47:34.300]  or a virtual address set. And virtual address sets are nothing more than analysis tools. It
[47:34.300 --> 47:39.620]  just happens to be an analysis tool that Vivisect then makes use of, but I get to make use of it as
[47:39.620 --> 47:46.980]  well, where I can just list all the dynamic branches through that has been updated as
[47:46.980 --> 47:55.240]  code flow analysis happens. And then, turns out, dynamic branches are very, very interesting
[47:55.240 --> 48:06.100]  things. They tell a ton about what's going on with the code. Typically, making sense of
[48:06.100 --> 48:15.300]  assembly instructions is not typically terribly hard. Spark notwithstanding.
[48:16.220 --> 48:26.080]  Just kidding. However, finding in this massive, maybe four megabytes of firmware, what things are
[48:26.080 --> 48:32.920]  interesting, that can be hard. And I love doing this. I could do this all day long, and I could
[48:32.920 --> 48:37.820]  work myself right out of a marriage, and right out of my kids' lives, and right out of a job.
[48:38.460 --> 48:44.020]  But if I want to do the things that I love, including being a dad, being a husband, riding
[48:44.120 --> 48:51.220]  a motorcycle, and hacking, then I need to be able to focus in very easily, quickly on interesting
[48:51.220 --> 48:56.380]  things. And so that's why I threw this in there. Dynamic branch handling is very interesting. And
[48:56.380 --> 49:03.340]  of course, these are a bunch of branch to control, or I'm sorry, branch to the counter register
[49:03.960 --> 49:13.520]  with link, which means it's a call, not a straight branch. So things are expected to,
[49:13.520 --> 49:23.400]  this instruction. So that's very likely, that could very well be C++ stuff, or it could be
[49:23.860 --> 49:30.560]  function pointers, or whatnot. So either way, it's very interesting. I'm done if you...
[49:31.620 --> 49:45.710]  Okay. So I was just poking through this, one of the firmwares that I was looking at for this
[49:45.710 --> 49:54.130]  presentation. And of course, I was looking at the dynamic branches. And here's one. This was an
[49:54.130 --> 50:02.090]  oddity. I mean, it actually wasn't an oddity. It struck me weird. But I'm just looking at it. And
[50:02.090 --> 50:09.050]  in this code block, if you're not familiar, this is a code flow graph. It's a great way to display
[50:09.690 --> 50:18.590]  assembly language code for humans that don't want to sit with a linear look and draw arrows to where
[50:18.590 --> 50:27.090]  code flow happens. It just kind of flows naturally. So in the code block in the middle,
[50:27.090 --> 50:38.510]  there's a discrete code block. And it looks like we are loading values into the R12 register.
[50:39.650 --> 50:44.270]  And then we're moving the R12 register data into the counter register. And then we're branching to
[50:44.270 --> 50:49.530]  the counter register with link. We're calling whatever is at this thing that we're loading into
[50:49.530 --> 51:00.970]  R12. So I'm going, hmm, how's that work? And I'm wanting to make sure that I understand what's
[51:00.970 --> 51:07.390]  going on. So I walk through and I'm like, okay, load immediate shift. That loads
[51:10.790 --> 51:24.230]  basically 40000 into R12. So the shift means shifted 16 bits. And then load word. Word is 16
[51:24.230 --> 51:35.190]  bits with zero extension. That 4 with parentheses around R12. Now, when I first thought it,
[51:35.190 --> 51:43.230]  I'm going, that's not, I didn't actually, I got it wrong. I'll just say it. And I said, okay,
[51:43.230 --> 51:57.490]  that's going to say 40000 plus 4 is going to be 4004. Okay. That's not what ends up in R12.
[51:57.590 --> 52:06.370]  But that's what I thought. Next. So I went there. And I thought, okay, let's see what that's doing.
[52:07.970 --> 52:17.970]  40004, it has, let's look at the first four bytes. 000D5C20. VimSec has a preview instruction
[52:18.710 --> 52:27.610]  option. It's control P from the keyboard to use the already selected architecture. But I wanted
[52:27.610 --> 52:32.990]  to show you, so I right clicked and the context menu said preview instruction, because it's not
[52:32.990 --> 52:42.090]  anything right now. That only shows up if it's not decoded as anything. And then I get to pick
[52:42.090 --> 52:48.730]  the platform, and I chose PPC embedded, PowerPC embedded. I don't know if you can hear the
[52:48.730 --> 52:56.190]  lightning. Okay. So I click on that, and I did it three times, because, you know, once isn't
[52:56.190 --> 53:02.110]  enough. And each time I got a decode exception, I'm going, uh-oh, crap, I've got a bug. I've got
[53:02.110 --> 53:14.870]  to go figure out why this is not working. And so next, remember, 40004. So I loaded up a tool
[53:14.870 --> 53:23.250]  that I built a long time ago, and it has only become more dear to me. I used this tooling to
[53:23.250 --> 53:30.670]  reverse engineer a lot of different things with VimSec, and actually it found its way into a
[53:30.670 --> 53:38.610]  Deliverable one time. But this is part of the Atlas Utils tool belt, which I think I started as
[53:38.790 --> 53:49.970]  a Perl, a library of Perl, way back in 2006, 2005, 2006. It was crazy. Made the switch to Python,
[53:49.970 --> 53:57.570]  and just kept adding to it. Basically, I'll make no bones. It's a pile of steaming shit code that
[53:57.570 --> 54:04.710]  you may not want to read. But I found it to be exceedingly useful. So I share it. Please don't
[54:04.710 --> 54:15.050]  hate me for it. So I created a thing called an MUtils package, which was based around originally
[54:15.050 --> 54:26.370]  VDB and VTrace, the tracing library underneath that makes VDB work. But I really ended up using
[54:26.370 --> 54:32.590]  it a lot for emulators. So VimSec makes emulators available. In fact, I'm using right here what's
[54:32.590 --> 54:40.110]  called a workstation emulator. And workstation emulators come with some special sauce. For
[54:41.070 --> 54:48.810]  example... all right, I'm unplugging the laptop now. Special sauce here, you'll see weird entries
[54:48.810 --> 54:55.910]  for R0, R2, R3, R4, R5, R6, blah, blah, blah, blah. And basically what that is, workspace
[54:55.910 --> 55:03.750]  emulator, when it first wraps in the concepts of memory, registrar, and instruction emulation,
[55:04.250 --> 55:10.150]  the workspace emulator goes a little further and it says, I'm going to do taint tracking on all the
[55:10.150 --> 55:19.890]  argument or all the registers that could possibly be arguments. So it just takes and puts specialized
[55:19.890 --> 55:26.150]  numbers into each of those locations that will then trace through code. And we'll be able to see
[55:27.030 --> 55:38.050]  if any uninitialized registers are accessed before assigning values to them. Because that
[55:38.050 --> 55:44.570]  could mean either an uninitialized variable, or it could mean that that's an argument.
[55:44.570 --> 55:53.250]  So we use this to identify calling convention and to do other various analysis. So the first
[55:53.250 --> 56:02.890]  instruction is a load immediate shift of 4 into R12. So 4, 0, 0, 0, 0. You can see that at the
[56:02.890 --> 56:09.830]  bottom. In fact, hold on, back up, Aaron. One of the things I love, again, it's really ugly code
[56:11.570 --> 56:16.610]  that I take no pride in, but I take pride in the results. You'll see that I print out a whole
[56:16.610 --> 56:21.310]  bunch of interesting registers for each instruction. And that's kind of how I am with GDB,
[56:21.310 --> 56:25.250]  too. I like dump all the things, and this is actually a lot better than doing info register
[56:25.250 --> 56:35.170]  after every instruction. But then the Emutils throws in anything that could be a dereference.
[56:35.170 --> 56:45.290]  It prints out some context around that data. So let's see. We're looking at memory location
[56:45.290 --> 56:54.530]  address 4, and I think that's because I don't actually... oh, because we have the number 4.
[56:54.530 --> 56:59.030]  So it says, oh, okay, there's an immediate 4 here. That could be an address. So let's kind of look at
[56:59.030 --> 57:08.090]  that, because memory address 4 is valid in this case. Okay. So next... so the next instruction is,
[57:08.090 --> 57:13.990]  oh, we see highlighted here, R12, and I'm moving my mouse pointer around R12 right now.
[57:13.990 --> 57:23.450]  Thanks, Aaron. So R12 shows up. Okay. 4, 0, 0, 0, 0. Cool. But one of the things that I love about
[57:23.450 --> 57:29.730]  emulators and disassembler, or in debuggers, is that they teach me so much about an architecture,
[57:29.730 --> 57:39.190]  and they correct me all the time. So the next instruction is that LWZ R12 4 with parentheses
[57:39.190 --> 57:47.590]  wrapped around R12. Okay. What's that do? I think that should create an address 4, 0, 0, 0, 4.
[57:49.330 --> 57:57.430]  Yep. And by the way, as you can see, it registers, and then it prints out the value of what's at 4,
[57:57.430 --> 58:10.130]  0, 0, 0, 0, 0. It then prints out some context data around D5C20. No idea why. Okay. I do.
[58:10.130 --> 58:20.290]  Spoiler alert, though. 4, 0, 0, 0, 4. Okay. Oh, that's it. I must... this must add 4 to 440,000
[58:20.290 --> 58:32.330]  hex. And so it's printing off... oh, wait. 4,000... 40,004 starts off with D5C20. Huh. So hit enter.
[58:34.780 --> 58:42.280]  Okay. So that instruction updated R12, and it put D5C20. See, the thing that I was forgetting is
[58:42.280 --> 58:50.980]  that the integer followed by parentheses and a register in it isn't the addition of the two
[58:50.980 --> 58:56.780]  things together. It is actually adding them together and using that as a memory dereference
[58:56.780 --> 59:04.820]  point. So it went to 40,004, and it grabbed a pointer there, and it put it into the register
[59:06.840 --> 59:13.080]  because D5C20 is actually the location of code. So if I go to D5C20, I'm going to be able to
[59:13.080 --> 59:21.340]  decode code, or it may already be decoded. So we move R12 into counter, and then we branch. 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:34.120]  I don't have time to talk about Symbolics much today, but that's coming. But I did want to throw
[59:34.120 --> 59:40.780]  this at you. Right-clicking, I have a Symbolics window up, and so I send that address to Symbolic
[59:40.780 --> 59:50.760]  zero. That's the window. And this is probably a lot to digest, and the idea is to reduce things
[59:50.760 --> 59:58.020]  down to make programmatic analysis easier, but this view is a way for making Symbolics
[59:59.160 --> 01:00:07.380]  valuable to the reverse engineer that's using the GUI. And as you can see, at 24,104, that address
[01:00:07.380 --> 01:00:14.540]  that you'll see highlighted on the left in yellow, because when we get into Symbolics view,
[01:00:14.540 --> 01:00:20.760]  we have to pick a path through code. And we can direct it some, but we have to pick a particular
[01:00:20.760 --> 01:00:29.160]  path to make sense. And so for that path, it then highlights all the instructions in yellow
[01:00:29.160 --> 01:00:36.740]  that are in that path. So as I scroll through the different paths, those yellow backgrounded
[01:00:36.740 --> 01:00:42.640]  things will change. But as you see highlighted down here, I've shown that it's the memory
[01:00:42.640 --> 01:00:53.620]  dereference of 40,004, four bytes long, that is used as a pointer to call a function. And then
[01:00:53.620 --> 01:01:00.320]  the arguments are listed here. And you'll notice some of these, the cascades. So up above, you've
[01:01:00.320 --> 01:01:07.240]  got 23C60 as a call. The results of that are then used in various different things throughout the
[01:01:07.240 --> 01:01:11.480]  analysis. 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:28.940]  So PowerPC is huge in a lot of areas that are kind of not getting a lot of attention by
[01:01:28.940 --> 01:01:35.380]  security researchers, at least not publicly. So we're using this as a launching point to do
[01:01:35.380 --> 01:01:48.700]  reversing and analysis of IBM and embedded things. So the IBMI and the P-series, the power stuff.
[01:01:51.140 --> 01:01:56.100]  And this is going to make its way into some emulation projects that are very,
[01:01:56.100 --> 01:01:59.500]  very interesting that we'll talk about more later. And
[01:02:01.900 --> 01:02:10.520]  I intend to make the symbolic analysis engine in PowerPC push forward the art of reverse
[01:02:10.520 --> 01:02:18.420]  engineering and exploitation. So that's all for that slide. And I intend to make Aaron
[01:02:19.440 --> 01:02:24.100]  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:40.220]  Yeah, so DevSec. I honestly for the PowerPC resources themselves, you could probably go
[01:02:40.220 --> 01:02:46.560]  back and read a large number of documents. But these are some of the more useful ones,
[01:02:46.560 --> 01:02:51.420]  at least for embedded. We didn't even touch on it. SPE is kind of the
[01:02:54.020 --> 01:03:02.680]  PSP stuff for embedded NXP processors. 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:18.300]  Yeah, no doubt. All right. 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:24.580]  All right. Thank you all. Thank you, Aaron.
[01:03:24.740 --> 01:03:25.760]  No, thank you.