 Let's kick it. Normally I would like to look at 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 but since I can't I'm just going to throw pencils there and pick on him. That's fine. So, go ahead. So in order of events here we got, we're going to do some dry PPC, RPC introduction stuff because we're gigantic nerds. We're going to talk about the kind of the guts of this which is the bit of sex stuff. Who cares about power PC. Only us nerds right. Or the, you know, I suppose the people developing embedded devices care. I hope that the people whose lives are in jeopardy care, but something something x86 insert x86 joke here from RPC been programming RPC for a long time to be development. So it's, we always used to pick on the x86 people. And then reverse engineers care, which is an interesting, interesting topic, because the tools for doing that are not that great. Oh, and she I'm pointing on my screen like people can actually see. Not like I'm pointing up at the MFTA. They care. Or any mainframes care thing. Why would they care. Why would they care. Actually, Aaron, who are you. Who am I. Oh, I skipped. We skipped the, the intro slides here. I guess so I am Aaron or acorn. I'm a security researcher with room. I, for most of my career I was doing embedded, embedded software and system development used to put beyond safety critical systems have worked on telecom and more role. I've worked on medical devices, industrial control aerospace of wide array of different platforms and architectures and processors and languages and junk. I'm now I get to do what I've always wanted to do, which is pull things apart and figure out how they work. Awesome. I'm so glad to hear that you love that. And I am Atlas. I've been hacking reversing stuff for about 15 years. 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. And some of those sorts of RF things automotive embedded things. And now as of, as a recent space things. Please forgive me if I, if I snore sometime during the presentation, Aaron, you'll have to yell. I was up for 26 hours straight hacking satellites last night. And when my, my kids got up and started me entering around the house at 930 this morning I thought, just probably go to bed. I did get about four and a half hours sleep. So, I didn't short you guys too much that's what I would have normally gotten in Defcon Vegas. But so little about me, I love slick air and I love tearing things apart, figuring how they work, how we can make them work better or interesting. I'm a Christian, a father of three and husband of one. And I love talking to you guys. So, why, why would anybody other than us nerds care Aaron, where do we see power PC chips these days. Well, we see them in my mouse works. Or not, whichever, you know. Oh, I'm skipping ahead. Where we see them here today. Mainframes IBM all of those systems that what is it called now. I system I think is what they call it. Those are all our PC systems, not the weird 48 bit things they used to be embedded controls right. Yep. IBM also, they've got their I platforms and their AI X used to be the RS 6000s. And they'll run on our PC and in fact they've put them under the umbrella, known as the power systems. So, go figure. So, and XP, and XP I've seen their name somewhere. Kind of things that they get their chips into. And the rhetorical questions here, automotive, industrial systems aerospace, they're heavily favored for platforms that I guess prize reliability, durability determinism. The little things though. Yeah, not the things that you carry in your backpack. Yeah, not your laptops and right embedded things and XP has dominated that space. Yeah, they, they also have satellites and space things but unfortunately, I've been working on spark systems for the last day or so. That's a different, a different presentation, talking about Leon and spark. But for power PC is very traditional, typically, or radiation hardened systems, think they call it the rad 750 is a very, very common ones, the old G three series stuff. That's something I remember right, been a few years since I confirmed. But yeah, so power PC for those of you don't know, right risk. Kind of. Fixed instruction words about every every risk process I run into actually. You know, every time you get a risk platform, we start finding very non reduced parts of it very quickly. Fixed instruction word 32 bits every instruction. Kind of, we saw a bit of a sneak preview on that of my other words slides here. People who are familiar with Apple in the 90s and early 2000s will force recognize power PC from that power books, right. Their releases the G three G four G five. I think they were all actually tied into the different releases of the power PC architecture documentation. Yep. So yeah, the things that they're used in very controls IBM and old apples I should have said old Apple computers that right. We have the slides titled history lesson so I thought it was kind of obvious. Here's the caveat for 32 bit free scale created a construction work within APU, which is what power PC companies call extensions extra things. So evolution and Darwinism was applied to computer systems. APUs would be the mechanism through which evolution occurred and the platypus was formulated. So, not my favorite thing. 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. I found this fun slide here. It's probably only interesting to me. I loved it. I love the title of it though. Power architecture demystified which is an extremely bold claim for anybody who's familiar. But here they've got the, you know, there's this little highlighted section here. So this would be somebody who worked at free scale slash NXP I think this was produced in 2000 this paper was in 2007 so this would be somebody who was at free scale at the time. With benchmarking they said that the code is 30% smaller with only a 5% reduction in performance. You know what I read that to say, what I read that to say arms doing it we should probably do something like that to probably. Automotive especially loves their small flat, small memory footprint parts. Well, you know you save a fraction of a penny per chip. Yeah, but the, this type of thing the VLE stuff. It's a big, all of the, I shouldn't say all. A great deal of the embedded components. You use the VLE features on embedded controls right now. It's kind of a big deal because as Alice said it makes producing tooling very very complicated. Like making power PC tools is like making tools for like 20 different processors or architectures. And reading the documentation for them makes it feel like you're making it, you're making our tools for thousands of architectures. And that coalesce well. So, a bit of a sec. Um, can you tell me, tell me something about that the second. Yeah. So, this act is a binary analysis framework that's that was created specifically for the purpose of finding and exploiting vulnerabilities may originally created by a really good friend of mine named in busy goth. That speaks my language. So to speak, it's pure Python. It allows me a ton of power in in many different ways, including from the command line, I'm an iPython person. I, I go to, I go to work and I type iPython and I feel like I'm starting to do something meaningful. That's a cool, meaningful things I can do with the sec there. But it's been forward thinking since it was originally created. And so instead of a disassembly framework. We got every architecture that that you disassemble for has an emulator wrapped in with it but not just an emulator like a Q&U, a partial engine, which allows for things to, to have tank tracking, for example, if we try to read memory that doesn't exist, or if we, we try to access uninitialized variables or whatever. So we can focus not just on code flow from the beginning of a program but we can say hey this function looks interesting. Give me a feel for what it does and then emulator can roll through and say, oop, that's a that's a problem but I've been programmed to keep going and I just kind of keep track of that. Or that's arg one. So I know that arg one is now going to propagate through this, this calculation and whatnot. But then a few years later I was talking to busy and he said, you know, emulation is awesome and super powerful, but you really need to focus on symbolic execution. And I'm like, what is that. I looked into it and 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 since repairing those things kind of sucks. But the sector is also has a raps in cross platform debugging in a subsection that we don't call out here called bdb vulnerability debugger. And so these things all wrap around in support x86 32 and 64 bit MSP for 30, there's also 8581 in there. So we have some mode v7 at the moment we have some deltas to to wrap in on v8 z80 hate. I love. I love just saying that name because it's also another one of those architectures that I just really love. And I love this tech the most because, 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. So command line stuff programming plugins whatnot. I said four and a half hours late. Wow. So, once you talk about this Aaron. Well, let me let me get a little backstory. All right, a while back. Yeah, I was already working on wrapping power PC into vivisect and MFTA said, we'd like to fund some of that research. I just make sure that that it benefits the world. And so it was already open source. So that was that was an easy sell. Thank you for 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. So I tapped him and he was fun. It was one of the best things that I could have done for that project because well, I'll tell you that later. Talk about this air. Sure, sure. So adding an ISA to vivisect. As I said, there's a couple different parts of it. You got to figure out how to disassemble the different instructions right you got to get your documentation to figure out what the instructions look like. Then you need to figure out how to emulate their behavior. We need to symbolic analysis is a bit outside of my wheelhouse there. I took most of that and it's, it's a different way of thinking. Testing is not where I thought I would end up being a lot of work, but apparently it's where I did a lot of work. Figure out a test tools to handle a new architecture or is interesting. So how do you, where do you get that information from obviously your documentation. At least I hope you do. It's going to be a stretch. You get existing compilers and object on tool that's useful. If you take existing disassembly tools that those can be useful. Those will give you a third of the results that may or may not match the object on. You can just make gigantic list of instructions to parse from your documentation. And also have to figure out how to do the behavior of that. No matter which one of these paths you take. Oh, and also option D, which I forgot to put down there, which is get the hardware and run it. The power PC that would really mean get like what 2030 40 different pieces of hardware. And so that could be challenging to do it for everything but it is useful. We got our hands on a couple different architectures for a couple different platforms sorry the one embedded in one more server ask. So you're able to have all that at our disposal. So, Aaron the sounds a lot like magic. It does. But what's it really mean what's it look like to write this assembly code, or, or an emulation instruction. How do you emulate an instruction. How do you emulate instruction, mostly the disassembly part because that I feel, I feel most people think that that is more magic than that it really is. It really is about defining the documentation and understanding what they meant. Well, you know once you I guess it's basically about the numbers right everything and it's based form in computers is a number hexadecimal decimal whichever way you prefer to read it. Everything is numbers if it's data, if it's code, whatever it is, it's just a number. 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. And then you just start taking a look at this particular pattern here means that it's this instruction this particular pattern here is this instruction. This right here is a fun list of test inputs. Just because it got your scrolling version going that would have been. Yeah, I don't know for some reason I just can't media. Aaron right brutalist about 30. You took a list of about 30 times this length and had it just scrolling and video and yeah Google box didn't like it. It was about like, 30 megabyte gifts. Not play nice. The. Yeah, so what in this particular case, I what I started doing was I took a power PC Linux kernel. And I disassembled it, which I figured that that would have a fantastic variety of instructions of different encodings and forms. What you do after you do that is you go through and you fix all the bugs because every single one of those four things I talked about the documentation, the disassembler object dump the compiler, the hardware, every one of those of course, for anybody who's done in better development or tool development knows every single one of those has bugs. So you go through and you fix your bugs, and then you find other bugs that are not your bugs but are actually bugs and other tools. So that's kind of the process there you go through and you just. Fix the, fix the bugs, fix the bugs. But yeah so it's not magic you just start with the data. You go through and then in Python if you make the function was this when you match this pattern, and you use this function as to emulate it right. And Aaron, he really ended up taking charge of the testing. It was, it was incredible. You basically, he wrote the most versatile testing for a instruction analysis framework, I've seen he basically rewrote an entire disassembler. 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. Boom the unit tests started just looking a different way. Oh, oh, that's, that's how that is. Yeah that's a, that's a weird thing nobody really agrees on how that works so that's how vivid sec wants to do it. Okay, I got you. So, in this all goes back to the fact that it's all just bits, when you type a letter to your mom, when you write your report when you. When you write a video or picture, that's all just bits. The computer system decides what to do with them and our disassemblers doing the same thing it takes into just a string of bytes, because bytes are the easiest way for us to deal with the world. And then it looks at a combination of the bits and says, based on these these things. That's this instruction, and every architecture kind of has its own nuance and its own flow for Intel, it goes bite by bite going, hey, this first bite puts us into this table of options for instructions and oh we hit the second bite here that falls into another table of instruction options arm it's kind of like a bunch of a bunch of masks, bit masks and comparisons. Take the, take the thing, mask it with this and compare it against this oh it's not that okay next thing and it moves down the list until it finds the escape hatch and then it goes down the escape hatch route when there's a match and says, okay now pull them these bits and put them as this and that and spits out an opcode with operands. It's pretty close to how the power PC stuff in the second ended up lots of bit masking. Yes. With all these different instructions here. There's the fun thing with the VLE parts is that the big back different mode so they can run variable instruction mode or full 32 bit instruction mode. But the whole instructions don't necessarily match the real power PC instruction in codes either. So there's like, there was just a ton of different ways to do things. Yep. Yep. Okay. Unlike 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 branching to an odd instruction address to go from arm to thumb mode. It's an simplistic way of viewing it but basically that's it. So you can have arm instructions right next to a group right next to a bunch of some instructions in power PC with the only was variable length and coding. They're not the same. So CPC and power PC decided to mark individual memory pages as being either VLE or straight power PC. So that was that was actually a push for me to wrap that into vivisect where going this is the first time I've ever had that where it depends on the memory page, we have to configure the memory pages to be either VLE or not. So when the disassembler that's kind of, 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, it needs to know which way to decode. So, that's, that's just how power PC chose to do it. So if you, and not every single power PC processor supports full power PC, or the very elite, maybe they do both some of them. You only one or the other embedded parts they don't have all the back. Here's another. Yeah, no doubt all to back the vector, right math instructions. Because in most architectures most embedded architectures in particular, you start out with an interrupt vector table with a reset vector. So when you power up the reset vector. However, that architecture implements it, the reset vector is points to interrupt service routine or interrupt handler that starts up the processor and boots. And many architectures that's like address zero. Not power PC power PC. There's weird ways of figuring out where code should start. In fact, there's a, there's a boot assist module in a lot of the architectures and the boot assist module is the thing that gets code execution first and it just starts scouring through specific areas of the flash or hard drive or where you're running as your storage. And it looks for a signature. 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. So weird things just like all sorts of weirdness. For a long time power PCs had the ability to change which page of memory is big ending or little and another just weird. They call it the TLB select just a slightly more granular MMU I guess I don't know. Yeah, at least it's not a 27 bit middle Indian architecture I will give it that much. Could be worse. Yeah, I don't know the documentation boy that was really annoying. Like, what was it the registers, the registers. It took me forever, because the documentation said the registers are 64 bits. It's interesting for an embedded processor. Oh, except for when you're in VLE mode, you can't access the upper 32 bits of those registers. Okay, fine, whatever. Oh, by the way, they're numbered zero to 31 as the highest, most significant bits. When you're talking about 32 bit mode like, you're talking about 32 through 63. Everything is 32 through 63. The architecture isn't the problem, the people writing the freaking documentation are. And it's always been that way. You can't blame the newer stuff for that it's always been that way. I blame IBM for that one I'm betting it was them. All right, it reads very much like a bunch of companies in the early 90s kind of got together and eventually agreed on stuff and they agreed by doing it weird ways. By bringing their weird way to the table and saying you must do it this way, because we did it already. Right, right. So let's. Next, something fun here. So power PCs a little different. We're here, we're at DEF CON, we're talking about security things right. How do you exploit porpoise? Or no, no, sorry. I did it wrong. Go back a few seconds pretend I said I didn't say that power PC is secure right nobody knows so nobody can hack it. Absolutely. It's in big iron. Those are unhackable. Right, right. Obviously, I mean, it's not, it's not impossible to hack. It's just need to do it differently. Every processor it reads in reads in data spits out data interprets data as instructions. As I said earlier, you just need to figure out the way you can tell it what's what. So there's no jump ESP instruction and power PC. Unfortunately, as there's no way to branch directly to a radio, a general purpose register. 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. So go and look at the documentation for the special purpose registers and power PC. I mean, Alice, do you remember how many there's like thousands and a couple thousand. Yeah. I don't even know what you do with all a lot of them are like a table with a lot of them in the in the decoder. There's a lot of them. So move to link register is actually not even an instruction. It's actually moved to SPR. Yeah, as an operand. That's true. Move, move MTS PR one comma LR. Yeah, MTLR is mnemonic that some assemblers allow. Now we like that it's easy to it's intuitively pleasing, but I'm just saying that's, that's how the architecture breaks down. So move to link register link registers of course where you return to. Again, like arm, you store the value place you can link register. And when you need to return to it, it loads about an address back into the link register. Well, if you can make some whatever it's out store on the stack, if you can modify that address on the stack where you can jump back to where you want it to go to not where it's supposed to go. There's a weird one. Count register and power PC is used for a lot of jump tables and function function pointers. So that's another one you could just modify that and get hold of a switch statement. So, nice little rock gadgets here. Yeah, I just, I wanted to put some fun in here, you know. So love that you consider that fun. Right. Right. This is not as fun. This is not so fun. If you go and look at, I'd say, probably two thirds or so 66% of all bugs in all power PC tools are related to this instruction. That's, wait, that's one instruction. Yes, one instruction, right. Actually, no, this isn't one instruction it's like, it's only a couple, two or three. It doesn't matter. There's these rotate instructions. It's the things that everybody. Left with bullshit. That's what I read there. Rotate left word. Immediate thing. This one. This one. Unfortunately, this, this Twitter account didn't tweet very long. But it's really interesting to, as you say, nerds like me. We don't need to make it up though. I mean, they included the EIO instruction. Yes. That said, I mean, that's dropping the mic for instruction. Right. So, I don't have much time left in the talk. Unfortunately, a little bit. Go ahead. She'd move a, probably move it along instead of making jokes about power PC instructions as much fun as that is for me anyway. Oh, hey, we're to story time. Story time with Atlas. So, we do a lot of work with a lot of people that we care very deeply for. And so there's stuff that we have, but we can't use it for a talk. So we were scouring the internet for something that we could show and not have to make anybody uncomfortable. We ended up finding a repository of a whole bunch of automotive code on some sketchy website. So downloaded a bunch of a bunch of things that I that I could identify as something potentially power PC. And thankfully, I threw one in vivisect. And it's just a blob at this point. I so this is a VBF VBF is a is basically a file package. Almost a file format, not really it starts off with a couple headers and then goes to binary code. I slapped it on a VBF into vivisect. And I just started scouring around what things were and thankfully the very first one loaded in, I guess well, and I hit, I hit C for make code. And I got a branch instruction, followed by three knobs and another branch instruction, followed by three knobs and a repeating pattern they're like a thousand of these in this firmware. But it could have been just a weird repeating pattern. So I wasn't going to bank on that. So I started looking through what's that. Oh, I just wanted to interject here for those, those of us who have been done RPC programming. This type of pattern is extremely common power PC lines up every interrupt handler every was that 64 bytes. No, 148 bytes, whatever. And that's very common theory of course you'll need this many instructions to handle your interrupts. So the thing that made me queasy and, well, it made me uncertain was that this is not a full firmware image. This is something that in an ECU would basically have its own base image, because if you have a firmware upgrade go bad. You can use your can interface, for example, because that's how you flash firmware. So they have, 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. 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 at a firm piece of firmware. That wasn't in this. This was going to be something else. So I saw this and I thought you know it could be, it could be power PC and this could be a branch table that is indexed. 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 just installed. Or it could be some crazy other architecture that has nothing to do with power PC. You can never be certain, unless you actually know and the VBF file in its text comment didn't have anything about what architecture. Plus there's this this architecture I keep running into that I don't know much about Aaron, you know more about it. Try core that I haven't done enough reversing on to actually know if I would identify it. So I was, I was still kind of skeptical. So next slide there. Yeah. So, I right click on the first address that that's being branched to. And I send the target, the 425 o c address over to another analysis window so this is the Vib window I've created another memory viewer called food. Why because food bar bass. So, anyway, I think I think I threw this in out of order. Sorry. So here's like, you can see that backup one one slide. So we started 40,000 hex. So that's a lot bigger than 40,000. But anyway, 40,000 hex scroll forward one. And we're still doing this table thing. So we put the hex into this, this firmware. And that is 130 hex options like so far, just 130 hex different, different branch options. Okay, now next. So we follow the location. And here's what they point at another table of branches that some of them point to the same thing. And as you can see so they're branching to location 43 228. And you'll notice that the bites that make up those instructions are not the same it's not like boom boom boom boom boom a table of all the same thing repeated. But these are relative branches so the numbers decrease as they go higher. So the fact that each of those points at 43 228 gives me a clue that this might actually it's getting more likely that this is actually our PC firmware. So if you just look at this, if you start looking at those, the values that make up those instructions, it almost looks like this is just, you know, a bunch of, you know, sequential memory addresses or something like that. It's very weird. Yep. Next, until we run into hex 43,000. We start to see real instructions now. Many architectures you give them four bytes they can spit out an instruction. So this does not mean that it's power PC. But we see these, we see these things peppered throughout a little bit of the previous table where everything was pointing to one location. And then after after a bunch of them, we run into move to SPR SPR G zero, and we move from our three into that. Okay. And then we move from SPR counter, the counter register into our three. So we've stored our three and then we put the counter into the counter register value into our three. And then we move to the SPR G one from our three okay this could be logical. Load immediate shifted zero into our three. So we've. We're not overwriting anything that we've just put into our three without storing our three so okay sanity still exists. Load word, zero extended, I think that's that means I've been having to look up a lot of word. Yeah, zero extended. Okay, so, so we take our three. Yeah, anyway, you're seeing the pattern. Things are actually starting to make sense. And after doing things with our three, we then move it into the counter register. We load immediate zero into register three so we wipe out the clear our three again, and then we branch to counter. Okay, that makes sense. That actually is a is a chunk of code that makes sense to me. So branch with counter that's the end of a code block, because there's no branch with a link there's no return, no nothing it just goes somewhere. After that though we see STWU know that's not shut the lot up. And this man, I capture the pointer right in front of that. Anyway, that's actually part of a function pro log, very standard function pro log for our PC. So, our one, our one's a stack pointer, right. This is with update. So this is moving the stack pointer. And basically storing the stack pointer and it's storing storing register 02456789101112 into the stack. So we create stack space and then we write registers into it. Okay. That sounds legit. The power PC calling convention includes handing arguments as registers. So you want to clean up after yourself when you're done. So storing the registers that aren't arguments totally makes sense. Move from SPR, the link register into our zero. Okay, so our link register now, the return address now lives in our zero. And then, okay, I'm convinced this is power PC. Well, from from the point of view of somebody who's written for embedded systems. SR zero SR one 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 the stuff up at the top of this, this was taking a look at SPR G zero G one, I believe are why it's been too long. I probably shouldn't say anything. Anyway, what it looks like to me is it looks like it's saying what address caused the particular interrupt. Why are we here. Right. And then it's looking up. It's doing a calculation based on our three, which is I guess zero right so it's jumping. For some reason with doing a jump calculation to one specific address. This LIS L I keep pointing like my screen like people could see when I'm pointing at help it. Make sure you point at the camera at the camera right so LIS LW. Those are very common for power PC. It's also something that a lot of first engineering tools have issues with. And because this is our PC fixed instruction work, you can't have a 32 bit address in one instruction, you got to have two. So it's low to say lower 16, and then load the upper 16 bits. Which is very common in any fixed with instruction architecture because turns out the register size typically is is the same as the instruction size. So try loading the full value into right into a register in one instruction it's impossible unless you store the value and somehow be reference some other address to load it into a register which arm does actually all the time. Okay, so I wanted to throw in an interesting thing. There are so many different details that make vivisective fun and exciting reversing platform. Part of it is that there are many things that are not hidden from you. 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. So if you've got, let's say switch on this variable being 12345. Okay, those things are those different options are going to be stored as pointers to the code that handles each of those options. And then, and then indexing into a table to grab the address to the branch right into that that's a dynamic branch you cannot figure out where that branch is supposed to go without an emulator. Or a lot of emulation written down into code that's not an emulator. There's also a lot of things like C++ method invocation. When you've got multiple inheritance with with virtual function tables, you basically have a table. You can just each type of call so if I've got a an object called ball and I have a method. Get color bounce throw in the trash, throw out my sister. These are all method function method calls that go into a virtual function table. And so when you're executing any of those, actually, the code goes, okay, grab my virtual function table and then index into that virtual function table, and then call, make the make the desired call. And since all of this is done on he 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, this is a food call that goes to this, this address location. And that's not when virtual function tables are involved. So we get. So as part of the process, this extors all dynamic branches in what's called a VA set or a virtual address set and virtual address sets are nothing more than analysis tools. And this 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, that has been updated as code flow analysis happens. And then turns out dynamic branches are very, very interesting things they tell a ton about what's going on with the code or it is only typically. Making sense of assembly, the instructions is not typically terribly hard. Okay. Spark not let's be not withstanding. Just kidding. However, finding in this massive maybe four megabytes of firmware, what things are interesting, that can be hard. And I love doing this I could do this all day long and I could I could work myself right out of a marriage and right out of my kids lives and right out of a job. But if I want to do the things that I love, including being a dad being a husband riding motorcycle and hacking, then I need to be able to focus in very easily quickly on interesting things. And so that's why I threw this in there, dynamic branch handling is very interesting 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 not a straight branch so things are expected to execution is expected to return right after this instruction. So that's very likely. That could very well be a C++ stuff, or it could be function pointers, or whatnot. So, either way it's very interesting. I'm done if you. Okay. Okay. So, I was just poking through this. That I was that I was looking at for this presentation. And, and, of course, I was looking at the dynamic branches. And here's one. This was, this was an oddity. I mean, it actually wasn't an oddity it struck me weird. I'm just looking at it and in this code block, if you're not familiar this is a code flow graph. 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 it just kind of flows naturally. There's a code block in the middle. There's a discrete code block. It looks like we are loading values into the R 12 register. And then we're moving the R 12 register data into the counter register and we're branching to the counter register with link we're calling whatever is at this thing that we're loading into our 12. Hmm. How does that work. And I'm wanting to make sure that I understand what what's going on. So walk through and I'm like, okay. Load immediate shift that loads. Basically 40000 into our 12. So the shift means shifted 16 beds. And load word word is 16 bits with zero extension that for with parentheses around our 12. Now, when I first thought it, I'm going, that's not so I didn't, I didn't actually I got it wrong. I'll just say it. And I said, okay, so that's going to say, or 0000 plus four is going to be 4004 or 4004. Okay. That's not what ends up in our 12. But that's what I thought. Next. So I went there. And I thought, okay, let's let's see what that's doing. So it's going to be 4004. It has, let's look at the first four bytes 0000 D5 C to zero. The insect has has a preview instruction option. It's control P from the keyboard to use the, the already selected architecture but I wanted to show you. So I right clicked and the context menu said preview instruction because it's not, it's not anything right now. That only shows up if it's not decoded as anything. And then I get to pick that platform and I chose PPC embedded power PC embedded outside. I don't know if you'd hear the lightning. Okay, so I click on that and I did it three times because you know once isn't enough. And each time I got a decode exception I'm going oh crap. I've got a bug I've got to go figure out what's why this is not working. And so next. Remember 4004. So I loaded up a tool that I built a long time ago and it is only become more dear to me. I use this tooling to reverse engineer a lot of different things with this act. And actually it found its way into a deliverable one time. But this is part of the Alice utils tool belt which I think I started as a pearl, a library or Pearl way back in 2006, 2005 2006 it was crazy. I made the made the switch to Python, and just kept adding to it. Basically, I'll make no miss Omega bones. It's a pile of steaming shit code that you may not want to read, but I found it to be exceedingly useful. So I share it. Please don't hate me for it. So I created a thing called an M utils package, which was based around originally VDB and V trace the tracing library underneath that makes VDB work. But I really ended up using it a lot for emulators. So that this act makes emulators available. In fact, I'm using right here what's called a workstation emulator. And workstation emulators come with with some special sauce. For example. All right, I'm unplugging the laptop now. Special sauce here. You'll see weird entries for our zero R2 R3 R4 R5 R6 blah blah blah. 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 tank tracking on all the argument or all the registers that could possibly be arguments. So it just takes and puts specialized numbers into each of those locations that will then trace through code and we'll be able to see. And if any uninitialized registers are are accessed before before assigning values to them, because that could mean either an uninitialized variable, or it could mean that that's an argument. So we use this to identify calling convention and to do other various analysis. And the first instruction is a load immediate shift of four into our 12 so four zero zero zero zero. You see that at the bottom. In fact, hold on backup. One of the things I love I again, it's really ugly code that I that I take no pride in but I take pride in the results. And I turn out a whole bunch of interesting registers for each instruction, and that's kind of how I am with gdb to I like dump all the things and this is actually a lot better than doing info register after every, after every instruction, but then the m utils throws in anything that could be a dereference, it prints out some context around that that data so let's see, we're looking at memory location address for, and I think that's because I don't actually because we have the number four. So it says, Oh, okay, there's an immediate for here that could be an address so let's kind of look at that, because memory address for is valid in this case. Okay, so next. The next instruction is, Oh, we see highlighted here are 12, and I'm moving my mouse pointer around our 12 right now. Thanks, Aaron. You can point at the screen. So our 12 shows up. Okay, 40000 cool. 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. So the next instruction is that LWZ are 12 for with parentheses wrapped around our 12. Okay, what's that do. I think that should create an address 400004. And by the way, as you can see it registers and then it prints out the value of what's at 4000000. It prints out the seven context data around D five C 20. No idea why. Okay, I do spoiler alert though. 400004. Okay, oh, that's it. I must. This must add four to four 40,000 hex. And so it's printing off. Oh wait, 40,000 40,000 four starts off with D five C 20. Huh. So hit enter. Okay, so that instruction updated our 12. And it put D five C 20. See the thing that I was forgetting is that the, the integer, followed by parentheses and register in it isn't the addition of the two things together. It is actually adding them together and using that as a memory D reference point. So it went to 400004 and it grabbed a pointer there and it put it into the register. Because D five C 20 is actually the location of code so if I go to the five C 20. I'm going to be able to decode code or it may already be decoded. So we move our 12 into counter and then we branch. Okay. And we don't have time to really talk much about actually we are out of time. I wouldn't have time to talk about symbolic much today. But that's coming, but I did want to throw this at you. Right clicking. I have a symbolic window up and so I send that address to symbolic zero. That's the window. And this is probably a lot to digest and the idea is to is to reduce things down to make programmatic analysis easier but this view is a way for for making symbolic valuable to the reverse engineer that's using the GUI. So you can see at 24104 that address that you'll see highlighted on the left in yellow because when we get into symbolic view we have to pick a path through code, and we can we can direct it some, but we have to pick a particular path for to make sense. So for that path that then highlights all of the instructions in yellow that are in that path. So as I scroll through the different paths, those yellow ad those yellow background and things will change. But as you see highlighted down here I've shown that it's the memory dereference of 40,000 for four bytes long. And that is used as a pointer as a pointer to call a function. And then the arguments are listed here. And you'll notice some of these, the cascade so up above you've got 23 C 60 as a call. The results of that are then used in various different things throughout this analysis. And with that, I think we're about done. Yeah, we're kind of out of time here but we can probably leave it up on that for a bit. And let's, let's take a second and talk about future just for future. So, our PC is huge in a lot of areas that are kind of not getting a lot of attention by security researchers at least not publicly. So, we're using this as a launching point to do reversing and analysis of IBM and embedded things. And the IBM I and the, and the peace series that they power stuff. And this is going to make its way into some emulation projects that are very, very interesting that we'll talk about more later. And I intend to make the symbolic analysis engine in power PC. And go over the art of reverse engineering and exploitation. So, that's all for that slide. And I intend to make Aaron, the lead on a lot of stuff, but his wife doesn't know it yet. You have to teach me some math I guess. Okay, so we want to throw in some resources. Yeah. So, I'm going to go back to the sector, your details. Honestly, for the power PC resources themselves, you could probably go back and read a large number of documents, but these are some of the more large, at least for embedded. We didn't even touch on it as PE is kind of the ultimate. It's just a bunch of large stuff for embedded NXP processors. You can see this is the NXP files, but they're subtle they're under. I think the weather is telling us it's time to move on isn't it. Yeah, no doubt. All right. All right, no time for q amp a but you can hit us in will be in discord. Thank you all. Thank you, Aaron. Thank you.