 All right. All right. Morning, everyone. We've started in on the material. I'll take two minutes to answer homework questions. Can't do that. They can't do it. Possibly. Well, either today or tomorrow. One of the days, yes. Yes, the hints will be... You shouldn't rely on them, right? I'm trying to help you get unstuck. Any other questions? Part one is the significance of the type of message we are sending, like ICMP or TCP or... What do you mean significance? Like we just check the type specified in the parameters and then just make it something like IP by TCP or... Yeah. Yeah, so you're right. So the IP packet is below or it's going to encapsulate whatever the lower-level messaging layer is. Exactly. So the point of the type is that you can show that you can use easily different types of messages to encapsulate. Any other questions? Yeah. From the type, the interface that is given, that is the interface in which we use this ending there. Yes. So does it mean that if it is like ETS0, we have to make an ETS0 packet, 100 packets of the lower level? No. See? It's just like telling us that this is true, which I want to pay back. Yeah, you can actually... Specifically that part, it's actually been chosen. So you can assume that the host you're going to be sending to will be available on that ethernet. If you just send it to that host, because in Seattle there's two functions, the send and the send physical, you can just use the send function. You actually don't have to specify the interface, but if you're using a different type of thing, you may need to know exactly which interface to read from. Question 3. I was wondering if Scapi3 is on Scapi... Is anybody else using Python 3? I can install it. I'll do it. It'll take a while. Yeah. What is Scapi? Actually, it's not that different. What is Scapi? Why is it Python 3 and 2? No. Python 3 and Scapi 3 take... Yeah. No. The code is the send. So you just change it to the top of the Python 3, but it works? I don't know. Or just an input? Yeah. I would look into it. Yeah. It's not going to matter. You should be able to use anything. It'll be an easy fix, I think. I just have to actually do it and push it out. I'll let everyone know. So that way they can really use Scapi3. All right. Last question. Make a good one. Yeah. We have to see if all this... As he said, we can add a name for Scatify, and we're typing in packages for an assembly. Does that work? Because Python might just have to use some... Yeah, it will not. That's the problem with Scapi3, because it's not installed. It's not a package. It's a hidden file. So that's good. Python might just have to use... It does. It's not a code. So can we implement a name for the... How would you want me to do it? How would you want me to do it? Yeah. Or you could do it in Python. You could even download Scapi3, or you could install Scapi3. I would actually be fine. But I'll do it. I mean, I would install that package if I said it would be installed. My question is generally, if you want to use a Python package from Java, so... I mean, in general... Right. But you can always download, like a Python package is nothing, but Python files in a folder. So you can download that, and you can even... I think somebody else in the last project submitted a zip file, and then the big file unzipped the zip file so that everything was in the proper directories and then everything could run properly. Yeah, so that's the other option. It's to get Scapi put it in, like, whatever the Scapi folders, however that folder structure needs to be, so you can import it, and you can do it then. Cool. All right, let's get started. So, up until now, I hope everybody watched the lecture on PlayZ, the awesome recorded lecture that I made in the hotel room, which was a lot of fun. It's always actually a lot better being in front of you and being able to talk to you than not talk to myself. So, the main part about that lecture was we dove into X86 assembly, and so, if you're not familiar with X86 assembly, you should definitely review that lecture and go through some of the examples. I know some people are having problems compiling the example Hello World file. I think it's a library, or I have to dig up exactly which packages you need to install to do multi-architecture support so that you can compile a 32-bit application on a 64-bit operating system. I think you just need a cross-compiler. You need the compiler, but also the libraries. You need the libc 32-bit corrections of the libraries as well, so usually that's what fails. Okay, so, now that we know how processes are built, we know how the compiler takes the C code, compiles it into the assembly code, we know how the assembly language works. Now we want to know, okay, how does this, how does the execution actually happen, right? When we run A.out, how does the operating system know how to load and execute our program? So what are processes for? Why does the operating system have processes? What's that abstraction for? So we want our operating systems to be able to run two or more programs at once. What do we also want them to be able to do or not do? Yeah, we want them to be isolated, right? Sandbox isolation, right? It should be the case, right? If we're running two programs on a machine, if one crashes it should not crash the other one, and it should not crash the operating system too. And the sandbox concept is taking even further when we think about browsers and how browsers implement things, right? They're actually running, like Chrome is running each tab in a separate process, and so that way if your tab crashes it doesn't take down the whole browser, hopefully. Okay, so when we invoke a program we know that the operating system is going to start a new process for that program. And so what it's going to do is it's going to parse that L file, right? So we saw that L file format. It's going to look at each of those seconds of the L file, and then it's going to say, okay, each segment says, at this memory address I want these bytes from the program in there based on this file. And so it's going to copy that, put it all in there. And so you can actually, with most of the Linux system, have the proc file system, so you can look for any process that's running on your Linux system. You can cat the file, proc slash PID. What does PID mean? Process ID. The process ID, and then maps. And that will show you all the memory layout, the entire memory layout of that process. So say things like, hey, I'd address this for this length, that's mapped to this part. And this address to this length, this is mapped to some other file. And so it's actually very interesting to look at that to see where everything is being mapped. If any relocation needs to happen, so operating system can choose to move things around. If there's relocation information in the L file, then the operating system will do that before it's actually executed. Finally, we saw in the L header there was the entry point of the function. So right before the operating system executes the program, there's the instruction pointer to be the entry point of the program. And then it starts it and it lets it go. And then execution begins. So this is how the OS lifts that L file and actually creates memory out of it and creates a whole space for this process to execute in. So then what is the process C as the memory layout? So specifically in x86, and this is specific to Linux and this is actually something that is configurable. But by default, usually when you use a 32-bit machine in each process space, one gig of memory is reserved for the kernel in the highest level memory ranges. So from all f's to starting with C, that should be one gig of memory. That's all reserved for the kernel. And so everything else below that. So what's the next address under C, 0, 0, 0, 0, 0? It's all the way down to 0. This is the space for the program. So why does it need to do this? Why does the kernel need to reserve? So a 32-bit application we've seen can only access two to 32 bytes of memory. So here we have our entire 4 gigabyte address space. So what's the process that the operating system does or what's the functionality of the operating system that allows each application to think that it's getting the entire 4 gigs when there may not even be 4 gigs? Virtual memory. Virtual memory? It says virtual memory work. You give it an angel, but you give it to the... So one way to think about it is there's an additional level of indirection. So there's a lookup table that defines translations that, hey, for this process, when it's executing and when it accesses memory-addressed BFFFF, actually in physical memory, that maps to something completely different. And so for each process, each process sees 4 gigs of space that it can do whatever it wants to, but actually it's due to this... the virtual memory, each process is actually like where that memory, physical location of that memory is going to be completely different and we can give each process the illusion that it has unlimited access to those 4 gigs of memory. So then why this kernel stuff in here? When the OS starts... You need to access the point of good record to actually build it up. Yeah, so we actually do need to do that but here at this point, right, the OS is already booted up completely and now it's starting to run a user-mode application. Sometimes we run it under the... Yeah, so it's actually kind of a performance hack in some sense, right, because you don't actually need to do that. You could have, because of virtual memory, right, if you call... So what's a system call? That's just due for the... Right, so when you do a system call, right, that's a call from a user space, so user space means not in the operating system kernel. From the user space into the kernel to provide some service. Right, so for instance, reading from files, writing the files, opening network sockets. These are all things that the operating system provides. Why does the operating system provide it? Yeah, be a huge pain if every application had to know how to parse the EXT2 file system or the EXT4 or NTFS for all these different file systems. Right, every application would have to do that and know how to read and write a file from every different file system. But if we use the abstraction layer of the OS, the OS then has to know how to do that and every application doesn't have to need to know how to do that. So because of these system calls, when we call something like read or write this string to a file, if we actually already have when the kernel executes, if the kernel can be executing in our process space, now we don't have to change any of the virtual memory tables or any of the virtual memory tables when we do this system call because we can directly access the memory of the program. So, interesting artifacts. The other thing that this does change that I've heard, one thing that does change that I'm not 100% sure about is I've seen some weird behavior. I think it's when you're running a 32-bit application on a 64-bit machine, I've seen the top of user space programs be all Fs. And I'm not 100% sure why that's happening yet. But I'm pretty sure that's the case. But on normal, if you're using a 32-bit operating system, you'll see that the top of the program here is at this memory, starts with like BFs. Okay. So then we dig down, we dig into the user space of the memory and say, okay, what is actually happening here? So what's this memory layout? And this is actually, it seems like this is a very theoretical, high-level concept. This idea and actually the details of how this is done is very important when it comes to writing reliable exploits for binaries. Because you need to know where things are in memory and where the layout's gonna be and how what you're doing is changing the memory layout. So first, at the very top, at the high level, we have all of the environment variables and arguments to the program. So what are arguments to the program? How do you access them in like a C program? Arc V. Yeah, so Arc C tells you how many arguments there are and the Arc V is a pointer to a list of pointers and each of those points to the actual argument that was passed in. So what's the environment? Yeah, environment variables. So all the environment variables that you have declared, what are some environment variables that you've heard of or used? Path? Yeah, the path, P-A-T-H, right? Lib include home, your home directory, which directory is your home directory? Right? These are all environment variables and when you type in a command, when batch executes that command, that newly created process inherits your environment. So this is why when you execute a process in a current directory, it knows the current directory because it actually uses the CWD, the current working directory, to know where it is. So at the very top of the process structure is the actual environments and the actual argument parameters. And so we're going to do so always throughout this and I hope I'm not going to sell myself. We're going to have high memory at top and low memory at bottom. So we're going to have the high memory, the BFFFs at the top and the low memory of the user spaces, at least the data process that we're looking at now is down to 008. So at the very top we have the actual environment and RV strings, the actual data, the actual string data that we're passing in. So what's a string in C? Character point. What is a character point? How do we know it's a string? What was it? Yes, just bytes that end with an old character. That's how we know it's a string. That's the only way we know. After that we have pointers to these RV, these strings. Because what gets passed into our main function? What was it? Point is. Yeah, but what else? We have argc, the number of arguments and then the next one is pointers to the RV and the environment. Actually, you can write a main method that has argc int and then argv pointer and then an environment pointer. So you can actually have access to the environment variables too. Or you can use the libc function to access that. So these are all on the stack. Sorry, this is all on, not the stack. This is all at the top of the processes structure. And then after that is the stack. So what's a stack generally? It's a data structure. Stacks. What was that? Letho, yeah. Push and pop. And when you take something out, it's the last thing that you put in, right? So you push things on and then you pop things off. So we have a stack and we'll see exactly what that's used for in a bit. But in terms of memory layout, the stack, which is used for local parameters, it's also used as kind of scratch memory for code that's being executed. Some code that uses too many, right, has too many temporary variables, too many temporary variables for the number of registers, right? Because we have to store things in registers and we need some memory location to store these values. So we store them on a stack as well. And so the stack is here. So if we can continually push things on the stack, what does this mean about the stack section? So just to say thanks to a certain... Yeah, it grows down, right? So this is the other thing. So our stack's going to start here. As we push things onto the stack, the stack's going to move down. And then when we pop things off, the stack is going to move up, right? And we'll have, as our program executes, the stack is going to be continually changing. Things are going to get popped off and things are going to get pushed on until wherever the current location of the stack is. So all of this in here. So what does this mean when we have a program and we execute a program about the starting location of the stack? What do we have that affects that starting location? The number of arguments, right? As we pass more arguments, the stack's going to start a little bit down. What else? The amount of data that we feed into those arguments, right? As we pass more arguments into RV, or more string data, right? That's going to make this part of data bigger, which is going to push everything else farther down, which means now our stack's going to be starting farther down than it was originally. What else? Say that? Recursive function calls. Recursive function calls? That's when we start executing. What about when we, before we even start changing the stack? Before code executes, right? So before anything executes, if we pass in more argument data, that's going to move the stack. Environment data. Yeah, that's actually a crazy kind of thing, but if you execute a program in different directories, the start of the stack can be different. It can be different than where you expect that to be. And then we'll see precisely how the stack changes based on function calls and all that during runtime execution. That's also incredibly important. After this, we have a segment for memory mapping. So any shared libraries that we're using will get mapped in kind of below the stack. So what's the difference between the stack and the heap? What's a heap? Yeah, I guess actually the data structure analogy kind of breaks down here. So what do we mean by a heap in a program? Emilokin2. What was that? Emilokin2. Yeah, malloc or anything like that, right? We want to dynamically create memory that's going to give us chunks of memory. So the heap usually will start somewhere below the stack. It usually starts at a fixed location and it's going to actually grow up. So what you're going to see is it's kind of nice because we have these two sections of data that as our program executes are going to be continually changing. So the stack's going to be growing down as we push things on, as function gets called. And the heap, as we malloc data, as we create new objects, if we're thinking C++ every time we call new, something is going to be alloc on the heap. That heap is going to grow up. So what happens if we use too much heap or stack? Overflow. Yes, overflow. Very horrible things happen, right? We run out of memory. Cool. Okay, so the heap's up there. And then after the heap, we have our data section. So our data section, as we kind of saw a little bit, has our initialized variables and any uninitialized variables, the .data section and the .dss section. And that usually lives under the heap, under that, and then we have the data section. And then finally, at kind of the very bottom, well, yeah, close to the bottom of our address space, we actually have what's missing from here? Code. Yeah, we need the code that we're actually executing, right? And because x86 is, what's a von Neumann architecture? What does that mean? What's that? What is it? Can people output something? Not quite. Input process, output process. Kind of, these may be all correct. It's not quite the thing I'm looking for, though. They can have more than we can have more. Yes, right? So the code and data is in the same part of memory, and memory can be code and memory can be data, right? So we actually don't have a separate part for, hey, this is code memory and this is data memory, right? Which actually allows us to do cool things, like have JIT compilers that can compile code on the fly and execute code, right? So that's why Java is able to be fast, because it's able to do this JIT compilation on the fly. So we need the code segment in here. So code was data, and it's going to be kind of at the very bottom. So this is why when we look at some pointers, and we see the pointers, we'll see things on the stack usually start with BFFF, because they're at the top of the stack. And then the code, our code functions are usually in the 8, usually start with an 804 or 8 or something. Okay, questions on process structure again? Is that 008 address fixed? More or less, yes. But the question is, can you change it? That's the question that I'm not 100% sure. Like you can change this top, you can change this, the split here between kernel and program memory, you can change that. So you could probably change this. And yes, so probably. Okay, so each process on Unix, we're executing a process, so remember we're thinking about program as process, the program we saw where all the data is laid out, and we saw where the code is laid out, and so it's going to be executing and doing some things. So now this kind of gets into the access control of the Unix system. So what are some of the key concepts on a Unix Linux system for access control? Process ownership, what does that mean? I don't know how exactly to put it, but when two different users are running at the same time, one user's process cannot be killed by or interrupted by another. Perfect, yeah. So every process, so there's two main concepts, there's users and groups on Unix. So every user has a distinct user ID, and a user can belong to one or more groups or zero or more groups. And so every process that you run on your Linux machine is running as your user and as your group. So you can use the ID command. The ID command tells you exactly who you are and how you're running. Let's try that now. Back is still a Unix thing. I can see that my user ID is AdamD, my group ID is staff, and I have actually a bunch of groups that I'm a part of. A weird Windows thing, or a weird Unix thing, or Mac. Okay, let's start with this guy so we can have that. If I do sudo su, so what am I doing here? I guess I should fake type more characters so that we can try to get my password from what I typed. So when I do sudo, I'm now trying to be run as the root user. So if I run ID, it's telling me that my user ID is root, and my group ID is zero as the wheel, and so I'm in all these groups that I was previously in. So if I do, let's go to this guy. So if I look at my ID here, I can see user ID AdamD, ID 500, group ID 500, I'm in the groups AdamD and wheel. Where are these IDs and names stored in where? Yeah, so EDC group, all the groups, so I believe it's, let's look at the exact file format. I think it's the name of the group, maybe the hash password, and the group ID. So this is where all the group IDs are stored. So you can see here, and then at the end, it's the user names that are in that group. So I can see here that in the wheel group, which has group ID 10 is the user AdamD, saying there's mail on here, there's all these other things, and we can see my own group here. So where's the user information stored? Password. Password, yeah, passwd, our old friend. So what are the fields in passwd here? So first the name of the user, then the hash pass. What does this X mean? Does this mean the password for root is an X? Just type an X and you're good to go. Maybe I'll try it. What does it mean? Yeah, so it means that the password is actually in the shadow file, so we'll talk about exactly why in a second. Then it has the UID. What's this next one? Group ID? Ah, okay, okay, this is, the groups file has all of your groups in it. I see, I see. Okay, that makes sense. Then this would be what then? User. The name again? Seems strange. The name is up here? If it was, name one by C. That's weird. The name is five. Five, there we go. Password, file, all the bar. Okay. Tell us about the good old days. Okay, so we have account, password, user ID, group ID, G-E-C-O-S, which is, this field is optional induced for, ah, the full username. Okay, that makes sense. Yeah, so that's the general electronic, or electric, I don't know, electronic, electric comprehensive operating systems. That totally makes sense. That's just the name. Then we have after that is the directory, the user's home directory. Then after that is the user's default shell. If we look at my password file, so we can see that root is shell is bin bash. If we look, actually I don't even know what my home is. So here I didn't put a full name in from here, so I have an empty entry here for that G-E-C-O-S thing. My home is home out of D, and my bash is in bin bash. Okay, so this means when I run, right, so when I run ID, it's showing me the user ID and the group ID of this command that I ran. And we can see here, so then how does the operating system know if I can access files? How do we, how does it specify what things I can or cannot access? I have permissions. How do I check the file permissions? Yeah, so the L option of LS will give me the full directory listing. So let's check out ETC password. So this is giving me the listing here. So how do I interpret this? Who owns this file ETC password? Group. What user owns this file? What group owns this file? Group. So we can tell from here, so if you have no experience with this, you should definitely take time to understand and see how to do this. We can see here that the owner of this file is root. So what are the permissions then on this file? So on files, we can look at this directory and we can see, okay, it's a three. There's three permissions, or three, that's the only thing about it, permissions, capabilities. Read, write, and execute for the user, the group, and other, everybody else who's not in those two categories, right? So what does this mean? So looking for this, who can read the ETC password file? Everyone can read it, right? So we have reads in the user, the group, and everyone. Who can actually change the ETC password file? Only root can actually change that, right? So if I... So when I run this cat command, that is just a program, bin cat. Output this to ETC password. Can I do this? Why not? Right, I'm not allowed to do this. I'm user, right? We can see here from the ID command, I'm user Adam D. My group is Adam D. None of these things are root, right? I'm not the user ID of root, so therefore I can't access this. I can't write to this file ETC password. So do I want to be able to change ETC password? What was in ETC password, right? So there's a lot of information in here, right? This is information about every user in the system. But is my information in here? My information is here, right? Would I want to be able to maybe change my name? Yeah, it's my name, right? What about my shell? What if I wanted to change to ZSH, or, I don't know, what if I wanted to go back to just plain SH, or what if I wanted to do some crazy shell? So how do I do that? I have to get root to do it? I have to convince the administrator to change my bank, please, sir or ma'am, change my shell. And if this was a server with all 120 of you, do you think that's something I wouldn't want to do? No, I'd make the TA do it. But even that, I probably still wouldn't do that, right? Okay, let's talk about passwords. So we said that the x in the ETC password file, right? The x meant that the password's not here somewhere else. So where's the password actually stored? Yeah, ETC shadow. Ooh, look at those permissions. Right, so why doesn't it allow me to read those passwords? Yeah, it contains the hash value of the password, right? So if you think about your big systems like general, I don't know, I actually know that general is using ETC shadow, ETC password if they're using something. They're using like Kerberos or LDAP or, I don't know, some other authentication mechanism. But the idea is, if I had all of you on this system, right, are you all gonna choose very awesome passwords that are unique and hard to guess? And if I can, oh, I can't bless that, but I can bless passwords, right? But what I can do, I would try the, what would be the first password you would try for everybody on the system? Password. Password. I'd try password. That's what you're getting people to do. Right, so I can go through and I can try to see if anybody else in the system has the password or password, right? I can actually check each of them to see if that, if I can read these hash files, you read the hash passwords. But I can't, right? I mean, I can't see that because I need the ETC shadow file. That's where the actual password is stored. So we've separated out now the secret information, right? But I should be able to know who else is on the system. Right? In the password file, I can see who all the users are. I can see the home directory. So because of this, pretty much nobody has access to this file, which is good. Actually, Root can still modify it, but I'm not gonna show you this file. I have defeat purposes, especially when it's gonna be recorded forever. Okay. So how do I change that shell? So I guess first question, should I be able to change my own shell without talking to an administrator? Yeah, right. But what's the problem with this file? Right? It's unrightable. Only Root can change this file. So how do we do that? I think environment variables. Environment variables aren't gonna persist. So this shell is, when I log into the machine, what's the program that first starts? Second? But then bash still has to start, right? I want csh to start as soon as I log in. I don't want bash. I hate bash. I never want bash. What was that? These are all things that... So the very first thing we log in the system, whatever's in the shell, it's gonna execute, right? This program's gonna be executed, and what bash does is it does all these things. It reads the .profile, it reads .bashrc, it reads like a host of other files, right, or it reads and executes them. And as part of that, you could have it start up your shell of choice, right, and start executing your shell, but you still haven't really solved the problem of bash starts first and you hate bash. User month? Yeah, almost, well, let's... Oh, okay, yeah, I did find it there. All right, yeah, let's look. So what are the permissions here on this file? What's the X? So what are the three permissions? Read, write, and execute. Can execute this program, right? So what do these file permissions mean here? Yeah, the user root and the group root are the only people who can execute user add, so does this make sense? Yeah, otherwise I could be able to add users to the system, right? User add is how you add new users to the system, so I'd add down, I'd add all the users I wanted to the system, right? But we want, the only administrator, the root user should be able to do that, right? So I can't call the user add, I'm gonna try to change root shell. We do dash U, okay, we can put in the username. So yeah, so it seems like this CH, I'm gonna change it back. So I have to do, if I type in, what do you want me to type in for my password? You get one guest, you get my password. Adam's awesome. Adam's awesome, I like that. Okay, so medication failure. So close. So close. Oh, okay. And then ends with the next question point, obviously. Right? Okay, so if I wanna change it back, I put in my real password. I want bin dash as my shell, shell changed. If I go back to the UPC password file, I can see it's been changed. So what is this CSH file that we've been using, right? So it's a program, right? You can see from that, and using the which command will tell me where that program is actually located, like which program is actually gonna be executed when I type in CSH. So let's check the permissions on that. It looks so cool. So what are the permissions on this? It's like going to S for now. But at least what can I do? So who owns this file? Group, owner, and group. And what can I do with this file? I can execute it because of the X, right? This means that anybody can execute this file. So what's different about this than the user add or something that we saw? So what's the S mean? Sticky bit? It means when you touch it, you're handling it. Sticky bit. It's not, I mean, it is the sticky bit. It's not about touching it. So the idea is this is an additional flag, an additional bit that says when you execute this program, execute this as if it was the, here in this case, the owner of the program. If the sticky bit was on the group, it would be execute this program as if you were the group owner of this program. So when we execute this program, what permissions do we have? Group permissions, yeah. So we're actually executing this change shell program as if we were root on the system. And so when this change SH program goes to change the ETC password file, can it read and write that file? Yes, because it's root. It's running as root. Let me do this. I mean, H top doesn't work. Okay. Okay, let's try this. If I do change shell, and then I go into another terminal, I do ps and ux. So I'm trying to look through the process list to find that change SH. So we can see here that change SH is running as user root. So what if, okay, let's kill it. Right, so this is how it's able to set you ID bit, ID key bit means that execute this binary as if you were the owner of that binary. So this means you have all the permissions that that person has. So now what if I can convince change SH to execute any code that I want? Then what permissions does that code have? Let's say I trigger it to output any file that I want. What file would I want it to show me to output? ETC shadow, right? And does it have permissions to... Actually it may not, because the permissions were all zero. But you could change the permissions back because you own the file. So you could change the permission so that you could read it and then you output that file, right? So yeah, you can actually have it show you that file that you, the user, have no permissions to view. But because this change SH program, when you run it is running as root, then it has all the permissions. So the way this works, we get down to it. So each process has what's called a real user ID, group ID, an effective group ID, user ID, and a saved user ID, group ID. User ID, group ID, they're all the same but different. So the real ID defines the person who actually started and owned that process. So when you execute something with the SH root, your real ID is going to say, hey, this is actually Adam D. We did this. Your effective ID, though, is used to determine if you're allowed to do that thing. That's what's being checked against when you access a file. So when we run CSH, what's our real user ID? Me. Yeah, that user. What's our effective user ID? We are effectively root, exactly. Then the saved user ID comes into play if you want to try to drop and regain privileges. I'm not going to go over the details here. So this is where that setUID bit is set. So that way, when this program is executed, it executes as if it is that user. And so you think about it from, like a maintenance perspective, this is actually nice, right? This is what you want. I mean, this is how the administrator can basically give you little bits of functionality to change your shell, to even change your password. To change your password, you're altering that ETC shadow file that is not readable even by you, or writable by you. So I think it's the PASSWD command that's to change your password. So we kind of saw, if we look at user bin password, we saw it on change shell, but password also has the sticky bit set. Change shell. So it's also is interesting. So maybe this shows you can actually execute a program even though you can't read what that binary actually is. The chain user bin, change sh, change shell. And here we're actually able to do it. Okay. So why is this important? So why are we talking about this? Okay, these are just some methods of how to do this. I think I'm going to... This is how to switch between the two. So why is setUID important? If you set it to zero, you become... you have good probabilities. There are programs on our system that are owned by root and have the setUID bit, the sticky bit set. Then when we execute them, we execute them as root. So if there's a vulnerability or a problem in any of those files, we can leverage that to become the administrator of the system. And so that's what we'll look at next. On Monday, we're going to get into all the binary attacks. So we've gone through all the background, but this is all the different ways you can essentially trick any binary, but specifically in this case, we want to setUID binary because we're actually on the system. We have an account. So we're going to take care of the entire system. Cool.