All right, I'm like a little torn on five different topics that we'll need to talk about or whatever. You saw the flow chart. The flow chart had 12 boxes that you have to learn about, you know, whatever. And like has been the pattern in this class, it's kind of like, we're going to learn a thing and another thing and another thing and then loop back around. And you'll see, like, you know, this is the cross-stitch class. It's like each new stitch tightens up the old stitches. Or maybe that's a little anti-masculine or whatever. it's the spare tire tightening strategy and you've got four bolts and you kind of loosely tighten each of them and then you make each one tighter as you look back around, you know, because if you tighten one all the way and the others are kind of wacky, you get like a weird angle. There you go. Okay. So I don't feel like Monday was enough for you to go and just like do shell code all of a sudden or whatever, but I think conceptually in terms of just like the earliest little, you know, tightenings of. bolts or whatever, you get the idea that back in the day, stacks were executable, you could put op codes in the stack. If you had a leak a stack address, you can jump to the stack and then execute the code there. I think that, I think what I'm in the mood to talk about right now is mastery task G, that is address randomization. And that is to say, like, you know, it's an important deal to me. every time I'm talking about hacking or whatever, I'm saying there's three things you've got to be able to do. Conquer Address for Automization is number one. And so I think just like logging some hours, talking about how randomization really works, all the analogies around that, what are, you know, what exactly is, you know, PIE and what is GOT and PLT, which you've never heard before this moment. All these sorts of important things, what is ASLR and all that stuff. I think it's nice to understand how address randomization, like, entered the picture when it came to preventing hackers from doing hackery stuff from the 90s into now. Okay. But there's, like, eight other things that are worth talking about, too, that are all kind of interspersed. So what I did is I put a bunch of notes up, and I'm going to, like, sample from all of them. So here's, like, the four kind of topics -ish. I essentially want to be able to talk freely about anything up to here. So I want to be able to jackknife between all of these topics, D-E-F-G-H and I, which are kind of in a big cluster that all feed each other and things like that or whatever. And it does mean that I want to lean heavily on you telling me like where I'm shitting the bed and where I need to like go spend more time or whatever and things like that. or where I need to like, you know, it's like, cool, we got it. Probably none of it. You're going to be like, cool, we got it, because this is low -level hard stuff. So you just need to put fingers in the keyboard to get to the place where you feel like, yes, I got it. So that's fair. We got our flock of geese. Squat, squawk. So they'd move faster. Fine. So here are my dumb little questions for you about address randomizations. Okay. Which types of addresses? That already has a lot deep in it, like, you know, there's a lot of different types of addresses going on in any given binary. But which types of addresses change every time a program is run? The main types of addresses here are where the instructions live, the stack, the heap, which we've not touched at all, and, like, external libraries. And really, I'm thinking G-lib C. what exactly does PIE position independent execution do how exactly are the library functions imported like printf and system and files IO and all that stuff how does that actually get into your binary to be usable what is ASLR and how is it different than PIE and for each one of the types of addresses instruction space the stack the heap and external libraries, if the hacker had one leak from one of those segments, what's the rest of the cool stuff they can do with that one bit of information? So it is to say, what are like the security implications of each of the four types of addresses? Okay, you're not ready to answer like any of those questions or whatever, but I want to walk you there mentally to be able to reason about this stuff. Okay. H-TMI works. You don't no longer have to hack me with your Omani device. sorry Ramadan time he's not in the moot to joke okay Mubarak is that the greeting Ramadan Mubarak you know so I want to jump around between address randomization because I want to do rap chains and because I want to talk about what G-LibC does and I want to make sure that you can like do the shell code stuff okay all right body language says that I you know I'm not making you feel comfortable In fact, as I was talking, people were going in and adding reds. They're like, hey, slow down, fella. I don't get it. Notice on adding greens. They're like, I'm in here to add these reds right the second. Slow your ass down. I was like, all right, fine. That's okay. So let's make it simple and relatable or something or whatever. As I was dancing this morning, I wrote this C program. Let's take a look at this C program for a second. We've got X equals 23. All right. That is a variable. Where is that variable going to live, kiddos? On the stack. This is new for you. I'm going to malloc a segment of memory and store it in the void star pointer heap. All right. this is the heap is like the stack but for things that I don't know at run time how or at compile time how big how much memory I'll need that is to say I can ask for things in the heap it will give me dynamic amounts of memory and it can grow with the needs of the user versus the stack is normally known ahead of time exactly how much memory is needed and things like that the stack is like kindergarten cubbies the heap is like Amazon bucket storage and it's put whatever you need in the bucket. It's cool. We've got plenty of space up there. Okay. All I really care about is this which is I want to look at a stack variables address, the address of Maine, the address in the heap and this little beauty this is literally the address where the code that implements printf lives when i run this thing all right yeah that huh is good good good audience participation with that huh that huh is saying i never thought of printf needing to live somewhere i thought of printf is like the architecture or whatever but no printf is also just code it's just code written by somebody smarter than you. And so when there's smart people code, it lives in cool little libraries. And you import their smart people code and you call it. But it's still just operations. Still just like, Anas nods knowingly because he has stepped through Printep like an idiot for two hours or whatever waiting to get back to his breakpoint or whatever because he didn't know capital S at that time. So he has seen every line of op code inside a printf, but it's still just opcodes. And so the question is, like, when I call printf or when, like, this whole thing, it's often calling things that are implemented by other people. Where does that shit live? It's got to live somewhere. Like the op codes aren't just magically there or whatever. Like, where does that live and how does that work? So this is all kind of what's up. All right. I ran this once. These are the addresses I got. I'm going to run it again. I'm going to run it again. I'm going to run it again. Here's four instances of running that thing. okay step one just play the little role of first principles detectives you know you're like colombo and you're like well if you were saying that is true then what do you observe about these suspects in your lineup hmm yeah okay anything that lives in the stack he said the last four digits are not changing. I think that's a little bit loosey-goosey. He's saying the last nibble is C. I love saying nibble, not only because it reminds me of because it's half a bite. A bite is eight bits, and half a bite is a nibble is four bits. And so when you look at this address, it's sort of in hex. What he's really saying is that it always ends in C. that's all he was observing there is that the same stack variable it always ends in C what else is always true well it always starts with 7 f f okay that's kind of cool how about the stuff in between hell if I know oh that could have it could have said what do you get when you cross an elephant and a rhino but anyway whatever um they're just random every time okay uh and but actually it's not even like that random ed and c like they're all kind of like big hex numbers you know that's non-trivial it's actually because like half of that nibble is determined as like a one um and and half is not you know so half a nibble i don't have a word for that but a taste whatever um so half of this bite is going to be fixed with the rest of these ones, but the other half is, like, free to change a little bit, which is kind of quirky. How about this guy? B-D-3-7? They might all be odd. There might be one bit left over from the bottom. It might be as many as five bits are fixed every time or whatever, but the rest is randomized every time. Okay. Interesting. Let's look at the main address. It does look like it's, like, very close to the heap. so the heap and the main are like near each other how about the Anas observation how many nibbles are fixed every time I ran this he did this how cool get some shot in Inglorious Bastards but so we've got one seven and nine are the same every time how interesting how interesting how interesting how about at the top 5-5-5-5-5-5 5-5 5 -5 all right the 5-5 locked in okay cool now why am I saying this the other day I was like hey do you guys see that address that leak can you guess what kind of address it is and you're like no now maybe you could right like okay cool I kind of see that if I'm in a 64-bit binary I've got like a randomized instruction pointer that's somewhere in the it's going to start with a 5-5 or a 5-6. Okay. Stack variables, I'm going to start with 7F. Okay, cool. The heap, kind of right next door. A good chunk, like this much was different in that heap address, this much was different. So about six nibbles were different for the heap. So it's like close to where, yeah. Yeah. Yeah, I mean, honestly, so the question is, like, do these change with the hardware that I've got? All of this is presuming, like, an Intel or AMD chip. So, so, like, the machine code itself is dictated by the hardware. Oh, I see. So if you've got more or less right, no, this will not be affected by the other crap other than your chip. So the only bit of hardware that affects this is, what the machine code is like running for this executable Linux format. If you go into Windows Hackery, which is a very profitable field also, all of these, all the same stuff kind of applies. It's still the same chip for Windows versus other things. But the libraries will be different and like the way that the executables are set up are a little bit different to things like that or whatever. So, so I am specific, aiming at Linux servers. And I'm aiming at that because that's like 99% of the internet is like open source of Buntu servers. When you are hacking individuals, you're probably get more mileage out of learning Windows hackery. But I'm targeting institutions. You might be targeting people. All right. We're all just babies with machine guns here. It's really just where is the baby going to the park or is the baby? Anyway, whatever. All right. That's that's a little dark. the victims of the baby with a machine gun. I should, yeah. Anyway, it's a fun topic. Always a pilot. How about the G-LibC address? What do we have in common, not in common? 7F. Yes, but not 7F. So G-LibC is always, almost like the stack, but the stack is a little more one. 7FF, because F is like 1,1, 1.1. 7F for the G-LibCs. How many nibbles are fixed every time I run this? The three at the bottom. So 12 bits fixed every single time. Okay. All right. Interesting. Now, I'm going to try to do this from memory. If I screw it up, I'm going to go straight to Google. which is the old man version of chat cheap t so i want to turn this off with no p i e hell yeah all right i didn't need google you know chat gpt i got this all right so what have i just done i compiled the same program but i turned off address randomization all right observe how it feels now. Okay. So now that I've turned off PIE, what is different, what is not different? Yeah. Main is the exact same every friggin' time. The heap is not the same every time, but it's a lot shorter somehow. Okay, interesting. And the stack in G-LIPC, have they been affected at all? Oh. I don't think so. I think they're different. Or I think they're the same as they were before. But they still have the same commonalities. I'll see. So the stack is still ending in C, still starting with 7FF. That's all I got out of that. The rest is hell if I know. And this one's still ending in 6FO and still starting with 7F. So in my mind, stack and Glib C are not a affected by me telling the binary to turn off address randomization. But I accept that it might look like they're a little different. But I think in practice, they're not, and it's just a trick of the brain, because we're here to find tigers and stay safe from them in the weeds. The wheat? The wheat. I don't know where tigers are hanging. Let's demo that. I demo that. Okay, got it. Let's go into this program, and we're just going to add one line. And I'm just going to say, like, Carr, Y, 16, F gets, Y, 15, from standard N. I'm just adding a dumb little pause, basically. This is now paused at that moment waiting for me to type up to 16 characters or whatever, 15 characters. So what I want to do now, let me be careful with this. I think I can tell it, I think I can give it an ampersand, and it's going to throw it into the background, It'll tell me the process ID. Yeah, there we go. Process idea is here. Okay. I'm too nervous to hit Control C there, so I'm just going to like jump back into the box from over here. I could have used T-Mux. This is one more tool. Yeah, yeah. No, you're right. T-Mux is really cool or whatever. And I'll introduce T-Mux later on when we go into here. Keep mode or whatever. T-Mox is probably worth introducing now. I think I was just being a, if you have a hammer, everything's a nail guy. Rather than using the right tool for the job, I'm just going to use the tools that we already know. Okay. This is the address randomization, or these are the segments according to the operating system of addresses that that program is allowed to access. these are the segments and what will you observe well the segments down here I would say are not being determined by the program running but they are determined by the operating system the segments up here are related to the code that I provided so when the code that I provided the executable, the book that the monkey is reading, when the book that the monkey is reading is telling the, you know, I don't know if I have a good analogy for the monkey book with address randomization. It's almost like saying every time you're reading me, just make sure you put me in like the upper leftmost slot of the first bookshelf in the whole library. Don't let me be moved anywhere else. I want to make like the reference material for everybody else to always find me. Like, the turn off the, like, if I have address randomization on, maybe the books are scattered all over the place or whatever. This book is always going to be in the same exact spot in the room, something like that. So, like, how does this literally work? The op codes of my binary are going to be, you know, fixed off set from the beginning, and it's going to plop them down. The operating system is going to plop them down, and it's going to give me an address where I can find those op codes every single time. If address randomization is on, these segments that hold the op -codes of my binary are going to be at a different weird-ass prefix. But if I turn off address randomization, they're always at this exact prefix. Okay. So when we saw Maine, we saw the address of Maine, Maine was 401166. And over here, what they're really saying is that 401 is one of the segments, where the code in a dot out will live and probably one six six you know hex one six bytes deep into that is where main begins so it's 256 plus or you know 300 or so bytes before main and then main will be there okay um and this segment you'll notice is the one that can be read and executed yeah what's up um so this is the place where the executable op codes of my binary will live, and it's going to be the same every single time. These guys, every time I run, they're determined by the operating system. The operating system is like, hey, dude, you're going to need some RAM. And to your point about the hardware or whatever, they're like, you've got RAM available to your program. Your hardware is more like how much RAM the operating system has to run a whole bunch of things at once. But when it goes to run the program, it's going to be like, this is how much RAM you've got for that one program. Now, you could probably go to your computer and set that setting where, like, every time it runs a process, give it more RAM. And the process can ask for more RAM and things like that. And honestly, even this code here, I'm mallocs, but I never freed. If ever you've learned malloc before, they almost always say, every malloc needs a free. I didn't. I just made a memory. Fuck you. Because this is so low level that I asked for memory out there, and I never reclaimed it. now in this case it won't matter because the binary is gone and the operating system will clean up house but if this program were running for a long time in a loop and every time I did this one operation will do that there was like a bug in the firmware of a Boeing no surprise that if the Boeing just stayed on for like 250 days then it would just magically shut off you know or whatever that's a memory leak where you've got like a long running piece of firmware that's just not freeing up the memory that it needs. And so after time, it just asks for more and more and more segments of memory until there's no more left. And then the thing just crashes. Okay, cool. So memory leaks can kill people. But, you know, but just restarting your computer fixes it magically because like now I just have brand new segments and I've started all over again. I'm not leaking anything anymore, you know. So the old IT stuff, it works. The old, what's that? What's that? What's that? quote you get don't don't quote the old laws to me I was there when they were written you know like this kind of thing like just turn it off and turn it back on again this is why it works and actually the whole operating system like Linux is based that way like they used to be that there was other operating systems that were pretty complex remember things like that and they're like dude we can fit this on one floppy disk if we just like you know just say hey if you crash just restart like if they don't have to recover you know then fine whatever um so that mentality is in all of modern architecture. Okay. So what have we just learned in terms of these questions that made you guys all be like, whoa, slow your horses, man. All right, let's see. What are the types of addresses that change every time a program is run? All of them change every time it's run unless I like turned off PIE. So these first things, what are the types of addresses? The op codes where my code will run, like the op codes of what I actually coded. That goes in that main segment. The stack that seemed to be controlled by the operating system. The operating system says, here's where your stack memory goes. Okay, fine. The heap was like half and half. The heap was near main, but not immediately after main. So there's like a little bit of a gap there, whatever, things like that. But it's near main, so if, you know, fine. And the external libraries, totally operating. system. They're like cool G-LibC stuff or whatever. We could look at that again here. I didn't talk about the rest of this stuff, but this is G-Lib-C. One of the topics that I want to talk about, somewhere in the next three or four lectures or whatever, is G-Lib-C. G-Lib-C is Disneyland for hackers. It's like, it's, it is G -Lip-C is Walmart if you are surviving in a post-apocalyptic zombie wasteland you're like all humans are dead but me and my little tribe of like gun-toting people or whatever and we just discovered walmart who level up you're right like um because now i've got twinkies now i've got ammunition now i've got fishing rods whatever you know whatever wacky thing i need there's something like that in the walmart that's glib see the op codes inside of this beautiful set of segments there are op codes in there that will just pop a shell for you There's op codes in there that will, like, shut down the system. There's op codes in there that will, like, open up an internet request. There's op codes in there that can open up any file you want anywhere, you know. Like, GlibC has everything that a person who code C can do. And what can you write C code to do? Literally anything. So if you're the hacker and you can find your way into an address inside of GlibC, then you have access to basically just start coding your own exploit through the dumb little program command line, right? So, like, on the stack, I can start coding things in really weird little assembly by just knowing any address in here. Pretty frigging cool. We haven't gotten that far yet or whatever something like I go. You know, we're going to suture this together. But G.LibC, amazing. Amazing. I love G.Lib C. All right. And, by the way, lest you think, gosh, we should live life without GLib C. All of you have GLib C on every single device that you've got. And any one of you can go and take the Glib C that's running your little computer and just delete it, and the computer will be bricked forever. You'll never even be able to shut it down again. It's just gone. You're just dead. That Glib C runs your world and everyone's world. It's the most important piece of software in the world, and we as hackers get to run around in it and just dance in our Walmart joy of our zombie apocalypse. We're probably pretty sad if we're zombie apocalypse survivors or whatever, you know, but somebody will be quirky enough to dance. All right. G-lib C. This is the linker. Never once in my hacking life have I cared to jump into the linker. Yeah. But the linker is how the code finds G-lib C. All right. So inside of the linker is some funky graph theory stuff going on in order to help get the address randomization right. So this is the code that enables this to be at a different address every time. This didn't exist before address randomization. This is how address randomization actually works, is inside the linker. I don't have that much useful hackery stuff to do inside of the linker segment of code, but I ignore it. But it's there and it's necessary for getting GlibC working. GlibC I love. The linker is just like their ugly friend that they bring to the bar or whatever you know like all right fine you're here too sorry sorry if you know but sometimes you just got to say how it is all right uh probably most of us in this room have been the ugly friend most of the time so uh it's those flocks of geese out there that are bringing us to the bar but fine we know our role we are the linkers they're not they're not asking us out Anyhow. Fine, fine, fine. Be a good wing, man. These analogies. All right. This is the stack. Stacks's okay. Stack's cool. Stacks where like local variables live. Stack is where I can put some shell code maybe if I get really lucky or it's 1990. Stack is where like I can control things. A lot of times the stack is where I'm launching my attacks from, you know, whatever. those are the segments these three i have no idea what they are and i've never cared cool they do something probably you can go be a grad student this shit and figure it out and you can invent some hack that uses those things that be cool and we'll all be studying you one day but i know they are right never needed okay um so that is to say when i look at this i look at this one this one and this one those are the four that I most care about. Okay, cool. All right, so how are you feeling this? You say, okay, there's four segments that Andy cares about. The instructions address, like the address of the executable, the stack, the heap, and GlibC. All right, those are what he cares about. What does PIE do? Well, it made the executable addresses fixed in space and the heap address fixed nearby. So PIE made it so that Maine is the same address every single time. Yeah, what's up? So, Ramirez's question was, how often is PIE not enabled? And the answer is it's only not enabled in the wild in low -level kernel stuff. Basically, the things that start up the computer or do very low-level things that can't afford a linker yet, you know, like all that linking takes some extra overhead. To have G-LIPC, take some overhead. If you're gonna go write an operating system, you're gonna write one file of assembly and then you'll write the rest in C. That one file of assembly, like that thing needs to know some addresses it can jump to or whatever, you know? So like the turning off PIE, that's used for very low level like BIOS crap. Because BIOS needs to know exactly where to go when the computer powers on for the first time ever. Beyond that, I don't wanna like go through all this weird graph theory to find your addresses. Now, the reason you ask that question is because you correctly, have the right to question the waste of your tuition dollars in this class. Is this a Doctor Who colloquium? No, it's not. But if I'm teaching you how to hack something where they've turned off address randomization, you might correctly say, is this going to help me in my career at the NSA hacking into Oman? I mean, into Yemen. Sorry. And the answer is You're not going to have to hack things that have PIE turned off for you very often other than CTS. But what you do need to do is this every freaking time. And so what I'm trying to do is add to your arsenal of ways to do each of these things and get you to think correctly about how this stuff works. Because the real one that you actually do for the NSA, it's going to take you six. months to develop. In a CTF, your, you know, attention span will let you do it for six minutes or whatever, you know, maybe 60 minutes. Fine. So, like, I've got to, like, throw away dimensions to concentrate on one skill at a time. And once you have all those skills firm, you can do this really complex, you know, I'm almost thinking, like, learning at a punch is going to be valuable in street fights or whatever, but, you know, it's going to be a big complex series of maneuvers all over the place or whatever, and you're going to go on to instinct and things, you know, like, you know, yes, punching is really important. It's foundation. Cool. And, you know, but it's like saying, can I get through a fight and never have to kick? Maybe, but like, no, but you're just going to concentrate on one at the time. First practice of kicks. Okay, this analogy sucks. I'm done with that analogy. All right. So, um, a lot of the stuff early on is patronizing to you. And I try to never make a class. we're going to turn off this protection and this protection and this protection, then you're going to hack it, you know. But you won't be babies with machine guns for long. Soon you'll be Spartan soldiers with machine guns. Okay. All right. Next up. How exactly does Printf work its way into my beautiful little program? No, okay. My program is stupid. How does that beautiful function Printf end up with a loser, like my program. There you go. That above his average. And that question is probably worth a whole lecture or two on its own, the GOT table, like the global offset table and the procedure linkage table. Do I start saying that now? I could. I could. There's more to say. These five reds are glaring at me to say, okay, maybe now I can go and do some more shell code or something. I'll see what I can say real quick. Okay, like I said, this morning I added literally four different sets of notes. Intro to rop chaining, like applied calling conventions for a 32-bit rap chain, looting Walmart slash escaping into Glib C, the PLT, GOT for linking, and random address hacks. This is kind of where I'm starting at the back. And this is like the analogy I've got. So here's like the same sort of exercise with some extra cool fun stuff. This is the analogy that I use for these things. I've used it for you already before. each of those segments I see as a battleship in a game of battleship every time we play the operating system is going to randomize the locations of the battleships unlike the game battleship that you played as a kid I'm not actually two-dimensional and I can't even change the orientation of the ships I am one -dimensional just like a really long strip of stuff and my battleships always have a like front and back which means the battleships are always oriented the only randomization that actually happens is just the starting place of the battleship i can't even like flip it um so what this is so what's my battleship analogy for then it's really saying this i am hungry for an address leak katina's a good thinker in this stuff so on monday she's like hey how would i get a stack leak like you're trying to give me to shell code but like how on earth am i going to even know where my shell code lives and she's right she's like the reason that I'm talking about this now instead of like doing more shell code is because in order to actually do shell code in practice, I need to drop a payload of crap somewhere and find my payload of crap and change the instruction pointer to my payload of crap. Be with me on why that's difficult? Like to say if the stack is random every single time and I'm writing op codes into the stack, the program I gave you was so idiotic to Ramirez's point that I'm just like, here, kids, let me tell you exactly where your payload lives, right? So I'm like, I'm just telling you where you can write a payload into an executable stack. And all you've got to do is, like, write your payload there and then jump there. I'm like, nobody's ever going to do that, right? Nobody's ever going to like just, hey, let me tell you exactly where you can drop some shell code and execute it, you know? Like, that's crazy. So what I'm really saying is that in order to pull off shell code, even in 1999 or whatever, you've got to identify. where your payload lives so that you can jump the instruction pointer to that place. All right. So in my mind map of how to do hacking, step one is addresses. Like we've controlled an instruction pointer because we like spent all that time talking about calling conventions. We have like a little buffer overflow or whatever and I can override a return address. But the question is what do you put there? Like what would you choose to jump to? like in order to do that you have to know how addresses work and to find an address that's interesting and jump to an interesting address now i'm telling you that glib c has some interesting ass shit so if i can find a glibc address i want to jump into there you know go do something cool over in glibc but how do i even get an address at a glibc how do i get an address from the stack how do i get an address of main how do i get any of these addresses um and so katina who's like a few steps ahead she was asking that question on monday like okay fine but in the wild how am i going to like get a stack address. Okay, you with me on that? So the reason for the battleship analogy is this. These segments are randomized every time, but only this part is sort of randomized. That is to say, like, these segments always start with an address ending in 0-0. That's because like the page length of how operating systems work. They don't even care about amounts of bytes less than a thousand hex bytes. So they're like, all of my segments always end in 00. So the reason we didn't see those addresses like changing a lot in the last three nibbles, in the last 12 bits, is because of this. I see 0.00. I've got a fixed offset into the Glib C, and so that fixed offset's going to be there every time. Do you guys remember what those last three nibbles were for printf? What? Good guess. 6F0. Dig this shit. I'm going to show you a really cool tool. And just the existence of this tool should tell you a hell of a lot about how this works in practice. We're going to go over to the internet. Say hello internet. Take me to libc.rip. Okay. That's cool, right? Go buy yourselves. dot rip domains today, and say, hey, I think I found a leak of printf, and it lives at 6FO as the last three nibbles of the address. Can you tell me which GlibC I might be using? One of these ones. Oh, cool. Thanks. SixFO was enough for it to say, these are all the GlibCs that have ever existed, where printf happens to be 6FO mod 1,000 bytes away from the beginning. So, like, which one of these might I be using? Probably the AMD -64 Ubuntu 2.35. Why? Because that's the long-term support Ubuntu when it launches. It's going to use the same G-lib-C until the end of support of that thing. They're not going to go update the G-LIPC, because if you change G-LU-C, you break everything. Everything rests on it. So every time a new long-term support of Buntu launches, which runs the whole Internet, you get that G -lib C for four to eight years or whatever. Can I group what? Yes. Okay, okay. That's a great, that's a great, I love that question. Not everybody's ready for the answer. It, I put a problem in the UDCTF based on that question, because I think it's such a beautiful question. I like writing CTF problems, but there's just a little bit of beauty, and I get to share it with somebody. So that's a little bit of beauty that I saw once that I, like, wanted to share with the rest of the poners who are coming and hacking our boxes. His question was, can I brute force the middle part of that address? When can I brute force the middle part of that address? When can I not brute force the middle part of the address? So, like, what changes here? This much changes. Okay. So, like, how many bits is that? 4, 8, 12, 16, 20, 24, 28 bits? Okay. That's not too bad. 2 to the 28? That's conceivable. You know, like every 2 to the 10th is about 1 ,000. So that's almost a billion possibilities. You would need to, like, run your script a billion different times and have it work once. So their server is probably going to catch on to you pretty quick, like, you know, indicators of compromise or whatever, something like that, maybe. But here's a cool thing you can do. Okay, oh, God, there's no way, forgive me in advance for losing 90% of you. But maybe I can make it make sense. All right. Suppose that on the stack was an address, right? And it's a GLIPC address. And this is not just some random supposition. Your stack has GLIPC addresses all over the place. Right. And anytime it jumps in a print DF or whatever, it leaves the remnant of what it was doing inside of GLIPC. So there are GLIPC addresses on your stack right now. Now, you're doing a little buffer overflow. And you can get it to jump to an address or something like that or whatever. Well, suppose that you can set it up so that it like flows all the way to that GLIPC address. But it's jumping to some random-ass place in G-LipC. how our address is working in terms of our little least significant bytes. The low part is going to be lowest, like it's going to be closest to your payload on the stack. The high part is the random part. That's going to be further from you on the stack, which means that what I could do is overwrite just the bottom byte or just the bottom two bytes of a G-Libc address where they've got the randomization already. And I'm just going to overwrite one or two bytes of their randomized address. to change what NG -LibC it's pointing at. So let's suppose I've got an address and I can jump to that address and it wants to return to that address at some point in the future. And I just like smash it and just change the lowest bytes. I can do that. Which means that like if I look at this rip-lipsi or whatever, suppose it was printout, you know? Well, okay, that means I could maybe change the bottom two bites and hit like puts instead or read instead or system instead or something like that, right? So, like, maybe I can get it to move from printf to system by just editing the bottom two bites because they're near each other in G-LIPC. I don't think they are here. They're, like, a little bit too far away. I need a little bit more. But the address randomization actually includes half of that second bite. So, like, shittily enough, if I were to overwrite the bottom, two bytes, I'm going to be, like, off by random noise for four of those bits. 12 of the bits are fixed every time and I can predict, but four of those bits I can't, like, do anything with. Okay. Well, if I only have to get four bits right randomly, then I can just try that payload 16 times, and I'm going to get it one and 16 times. So if I've got a thing where all you can do is like overwrite this address by two bytes, you're going to get a one in 16 chance of being correct. And that's a lot better than one a billion. Okay. So good question. I've made a CTF problem around the beautiful part of that. Forgive me if I lost everybody on that or whatever, something like that. But, you know, you can see that like the least significant bytes are the closest to your payload when you're smashing stuff or whatever. You know, okay. This, the existence of this website probably tells you a whole hell of a lot also, right? Which is that when I go to manufacture leaks, I'm going to try to like, you know, trick this buffer overflow into or something and just like getting a little bit off and leaking some data I shouldn't be leaking. And if I can leak some data that I shouldn't be leaking, I can start to do forensics on which type of like server they're running. shit, they had this offset for printf or whatever. Like, cool. Okay, I, like, I have a feeling it's this version of Ubuntu they're running. And if it's that version of a boon to that they're running, then I can do this and that, this and whatever, etc. So, like, now I can identify all the offsets inside of that G -lipC, and I can start to, like, get some clever -ass way to, like, jump to where I want to jump to. Okay. Versus my baby machine gun problems or whatever. It's like, here, here's a whole address or, you know, whatever, right? Like, so, so, like, how you get around address randomization is really sophisticated. stuff or it's really simple, you know, and so I could just turn off PIE for you, or I can give you a leak, or I could say, go figure it out yourself, you know, whatever. And so you get to, as like the problem author, kind of put the focus on which skill you're working on with each different problem. Okay. Cool. Now, I didn't answer what these guys are. There's no way I'm going to answer that in five minutes, but I'll try. I think. I could do this in five minutes. I could probably do this in five minutes. ASLR is address space layout randomization. So ASLR is not set by me, the coder on my particular binary. it is set by the system admin of that box. So the person who is running that computer can turn off address -based layout randomization. Which means that my binary could be randomized, but the stack and G-LibC and the others would not be randomized. Let's see if we can turn that off. It's always a little bit sophisticated to do this. This one I'm going to go straight to Google. Turn off ASLR. Yeah. To disable it, run that. To enable it again, run that. Okay, I want to look at this thing. Right now it's set to two. If I set that to zero, then every time it runs a process, it's going to not use address space randomization. Okay. Um, we're going to just trust these guys. Okay. Set to zero. let's go and run this process again i think i can kill 631 435 all right our new process will be 6323 oh you can already see you can already see um i now stack and glibc look a lot more similar right Now they're both 7FFFF, this just has more Fs. The only part that's like funky here is that, and that's all to do with how deep into the stack I am. So let's go take a look at those addresses. I have turned off address-based randomization on my precious box. That is where they're starting G-lib C this time. That is where they're starting the stack this time. All right. they don't they look a lot less random to me right before I'm like looking at a whole bunch of crap in here and it's just like all of that's noise this looks pretty darn structured to me but we'll run it again and just see that it's the same addresses still six three two three oh nine run again we now get this guy okay let's compare and contrast same shit okay so that is to say it is at the server level that I can turn on or off address randomization for the stack, GLIPC, the linkers, and that kind of thing. And it's at the binary level that I turn on and off randomization for the executable of the binary itself. So the coder who's compiling can turn it off with PIE for my program. ASLR is a system -wide setting for the other program. I'm going to turn back on ASLR. We're just going to put that back to two. All is well in my world again. Now when I run it, things will be randomized again. One thing to note, there was a random gap before from the end of the binary to the start of the heap. Not a huge gap, but a little bit of a random gap. Now there's no gap. Now that heap is directly at the, you know, abutted against the binaries code. Okay. You understand address randomization now, roughly? Okay, well, I've said some words. We've seen some examples. Now you must go play, and we must go play together, and things like that or whatever. I have not talked about how address randomization is really pulled off and things like that or whatever. This shit's really, really valuable for hackery. We'll get there, but not yet. Or one idea at a time. All right, cool. Thank you.
Address Randomization
From Andrew Novocin March 05, 2025
37 plays
37
0 comments
0
You unliked the media.
Zoom Recording ID: 4159319948
UUID: eRZETqRrQwiz5IMwLZDa8A==
Meeting Time: 2025-03-05 03:20:46pmGMT
- Tags
- Department Name
- ECE
- Department Division
- Date Established
- March 05, 2025
- Appears In
Link to Media Page
Loading
Add a comment