LIVE: Exploit Development | Shellcoding | Cybersecurity | Red Team | AMA

Key Takeaways

Heat [Music] up here. [Music] Hey, what is up everyone? Andrew here. Going to be doing a live stream today and we'll be doing some exploit development which is going to be a lot of fun. But I'm going to kick things off here with an AMA. So feel free to ask me anything. can be uh cyber security, job related, reverse engineering, exploit development, programming, uh whatever you would like to ask, feel free and I'll pop them up here and we can talk about them. I also have one quick announcement to make today. We do have a sock live that's going to be coming up and I'll have some more details about that uh later, but that's going to be an awesome opportunity if you are looking to get some sock training. So, all right, I see some people hopping into the chat already saying hello. Hi, John. Hello, Dragonfire. Hello, Tyrell. Thanks for hopping in. We are going to be doing again some exploit developments. See a question already coming in here. Are going to be doing vulnerability exploitation on real websites today? No, we won't be doing anything on real websites today because I don't want to uh get us into any trouble. We only do ethical hacking here on this channel. So nothing on real websites but we are going to be running through uh a walkthrough that I've created to teach about binary exploitation and reverse engineering. Uh so today we'll be looking at writing shell code. All right, we've got another question here. Any advice for a senior in college for cyber security? Currently on a research team to break and hack our skater wall. I've grown very fond of IC security. Any advice to move into that avenue? That's a great question. Something that is near and dear to my heart having worked as an electrical engineer in the past. So some of the best resources for this actually come from Robert M. Lee who is the founder of Draos uh which is an IC security company. So I would suggest going out and looking for his blog because he gets asked this question a lot how to get into this and he has a really good blog. I know the one thing that he stresses and recommends is that you really need to understand uh how industrial control systems and things like power plants and factories work in order to get into that field. So that's actually what he recommends starting with is learning those fundamentals first uh and then moving into the security. But that is an excellent resource. There's also a couple courses on Udemy from uh an instructor goes by Marcel Rick Sen. So you can check those out as well. I have taken some of them and they're pretty short, but if you want to dip your toes and learn about it in an easy way, you can check out those Udemy courses. So, again, excellent question here. Exploit dev in assembly. Yes. So, we're going to be looking at uh assembly exploit development. Okay, we got another one popped up here. Can you please tell us how we can master binary exploitation and reverse engineering? Well, you are in the right spot. We're going to be working on that today. So, that's something that I'm interested in and I will be um walking through a walkthrough that I created. Uh we're going to do level two of it today where we're going to look at writing custom shell code and how to remove bad characters from that shell code. Is it recorded for later? Yes. Uh we will be able to watch the stream afterwards for at least a little while. Okay. I want to be a malware analyst or be any kind of research but a bit afraid for AI. Can you please tell me your opinion? It's a really good question actually because recently there have been a lot of really interesting and really powerful tools coming out uh to use AI and the new MCP protocol for reverse engineering malware. So there's one recently released by um someone that works at Google goes by Lori. She has a lot of really cool videos uh out on YouTube and she recently released a MCP plugin for Gedra that makes reverse engineering a lot easier using it because AI is actually very good at looking at decompiled or assembly better than humans is actually really good use um of AI. However, it's always a cat and mouse game, right? So, as new tools come out and detections come out and ways to reverse engineer come out, the malware authors who are also potentially going to be making use of AI come out with new ways of evasion. So, I think there's definitely still going to be a need for humans to work on this kind of thing. I mean, it's not we're not at the point for a while yet where it's just going to be, you know, AI versus AI. So, if you're interested in it, then I would still say to pursue it. But, you know, definitely be aware of those AI tools and probably if you want to excel in that field, then you're going to have to learn to use them. And yeah, I think really it's just it's going to be a tool um to make analysts better. and maybe you know an analyst can do the work of what two could before potentially but there's still going to be human need and the people that understand how those AI systems work and can leverage them are going to be the ones that um succeed in my opinion. So definitely like I'm I am myself personally trying to learn as much as I can about AI right now using AI tools because it's I think it's going to be a necessity in cyber security um moving forward. So you know not just specific to malware analysis but pretty much every single cyber security now's a good time it's still not too late to you know start really learning about how LLMs work. um their vulnerabilities, how you can write simple apps, how you can host them yourself. I would really suggest everyone, you know, start doing it right now. It's still in the early days, so you can set yourself apart from um potential other candidates by doing that. So, great, really good question though. Really appreciate that question. Okay, bug bounty question here. I am working as a bug bounty hunter. Can you please tell me which type of bugs is easy as a newcomer? So there's there's a couple um trains of thought to this and my personal one is that instead of thinking of what is the easiest as a newcomer is to pick something that you don't think is like right at the top of what everyone thinks is easiest. So, for example, it might be tempting just to go for cross-sight scripting or XSS because that's what everyone thinks of, but everyone is looking for that. Instead, I'd pick something else. I It doesn't need to be something super complicated, but that's, you know, a little bit more down the list of what people think of. And then get really, really good at just that. Um, and start looking for that. that that's my opinion on the matter because if you're just looking for what is supposed to be the easiest, everyone's going to be looking for that like those lowhanging fruits are going to uh be grabbed. So, pick something, get really good at that one thing um and then start looking for that. That's, you know, that's my opinion on that. Okay. Hey, are we going to work on modern mitigations and what architecture are we going to be looking at? So, the walkthrough that I've created starts from like assuming you know basically nothing about exploit development and reverse engineering and then all the way down. So, um not in this specific video today because we're going to be working on level two and it goes up to like level I think six or seven is what I've got planned for it. Um but in the further levels yes we will be working on modern mitigations like avoiding non-executable stacks with return object uh return oriented programming or chains and how we can uh chain together vulnerabilities like memory leaks to get around things like ASLR or stack canaries. Uh but those are going to come in later on levels. So today, what we'll be specifically looking at is writing custom shell code and how to remove bad characters. Here's a basic newbie question. Can you explain in layman terms why an unqued service path is such a problem? Um, this can be used for privilege escalation in Windows is I assume what you're talking about. I don't really fully understand the details of how it works in the background, but essentially you can use this to do perform privilege escalation. Um, so hopefully that helps answer your question. My face is new in this channel. So yeah, I haven't been live streaming as much on TCM. That's more uh Alex. But yeah, my name is Andrew Bellini. I also go by Digital Andrew. So I am a content creator at TCM Security. Been here full-time for about a year now, but I've you know had a a relationship with TCM Security for almost two years now. I do the I did the IoT course and certification, the help desk course and certification and also recently an assembly course so far. Ah good question. Is this stream okay for someone with no background knowledge? Yeah, absolutely. Everyone is welcome here. Um, so I have been working through the overflow me walk through. In the last live stream, I did level one. We're going to do level two today. Um, so if you didn't do level one, then you may want to go back at some point and go through that if something you're trying to um, learn. However, yeah, I'm starting from the beginner. And you're also welcome to ask any questions you want. Beginner questions, advanced questions. I'll try my best to answer them here. Oh, this is a great question here. Any suggestions to freshers who are interested to start or switch career? Yes, I have a lot of suggestions here. So it depends I guess on what you're coming from in your background knowledge. But I think the first thing that's most important is you do you got to learn the basics and build a good foundation before moving on to you know the more fancy stuff. So I would definitely suggest if you don't have the the prerequisite knowledge to nail that down. We do have a free tier at TCM. So 100% free. There's no payw wall, no credit card required. It's not like a sign up and you get a month free. It's just always 100% free. So, I would start with the courses there. Um, there's one on help desk which is 17 hours long and and even if you don't want to work in help desk, it still covers all the core technology you would need like Linux, Windows, what are operating systems, networking, all that stuff. Um, I would take the rest of the courses in there as well. And then try and decide on what you want to do. Nail down your dream job title. So if that's penetration tester, cool. If that is ethical hacker, if that is um, you know, sock analyst, figure out what you want to do. Um, and then what I would suggest is go look at job postings for those roles. um and see what they're asking. What kind of experience are they asking for? What kind of searchs are they asking for? And then create a road map, put dates on it for how you're going to get, you know, at least 50% of what's those job postings are asking for and work your way through that road map. That's my best advice. Uh, one other thing I always suggest to people that are trying to get into cyber security that maybe haven't done it or don't have that experience is if you're doing a a career switch, look at what you're doing right now in your current job and think of if there's any way you can do some security or IT related tasks in your current role. Usually, if you put your mind to it, there's some ways you can think of to do that. uh and if you're doing well in your current role and you go to your manager and say hey I want to take on these extra responsibilities and they're going to benefit you know our team our company whatever in these ways they're most likely going to say yes so for me for example uh in past roles I volunteered when I was working as a developer to be the security champion for a team which meant I was the liazison for the appseac team um even before that when I was working as electrical engineer we are going to have to have pen tests on our embedded devices. Uh, and I volunteered to be the liaison and be involved with working on the external pentest team, but you can even volunteer for example to give a lunch and learn about fishing or social engineering, anything like that. And then when it comes time to interview or put on your resume, you know, you actually have some security experience demonstrated uh in a job and you can talk about that, which to me has been beneficial and I've heard that from other people as well. Is there anywhere else we can watch this other than X Twitter? Yes, you can watch it on YouTube, Facebook, Twitch, and LinkedIn. Uh maybe Brit if you could post some of those channels into the chat to uh check them out. But yeah, you can watch us on all of those platforms and you should definitely make sure you are subscribed or connected with us on all those platforms, especially YouTube because we release a lot of awesome content on our YouTube, including we recently released the first about 12 hours of our sock 101 course, which is an amazing course by Andrew Prince, a paid course, and you can watch the first 12 hours of that for free, which is pretty cool. So, you should definitely check out our YouTube channel. All right. Just looking for some other good questions here. Another ICS one. Love the ICS and SCATA questions. Is there demand for cyber security thresholds in the Scattera industrial control system right now? say yes definitely. Um and personally I think there's going to be even more demand for this in the near future because just the landscape of the world right now and the importance of these systems and I think for the most part they're pretty insecure. Um, and one of the things that's really preventing them being exploited is that a lot of countries would see that as kind of being like an escalation past just a cyber attack to do something too sensitive control system. So really that's just kind of like why they're not doing it. But you know at some point that line's going to be crossed and I think yeah there's going to be a lot of need to secure those systems in the future because a lot of them the security is not great. They're very very um weak. Okay. What if I can't afford to go to a university but still want to go into cyber security? I that's a good question. I don't think you need a university degree at all to get into cyber security. I mean, some specific roles or job postings may require it, but for the most part, uh, it's definitely not required. You don't need to go, you don't need a degree. It's not like other roles, like for example, I'm an engineer and like you need, at least where I live, a degree in engineering to call yourself an engineer, but cyber security is nice. It's not like that. So yeah, you can definitely still get into the field. There's lots of free and very affordable training now, which is nice. So again, we talked about our free tier. Um we've got paid courses that are accessible for $30 a month, which is very affordable. There's also lots of other providers now that are doing excellent um pay what you can or free training. So one that I like is Black Hills Information Security, BHIS. They have a pay what you can course that you can pay zero dollars and take their training and it's very good. So I would suggest that as well. Definitely do not need a degree though. Um a lot of people that are in cyber security right now do not have degrees because university is slower to catch up to the demands of the market and cyber security is a new field. So it's only recently there's been degrees. I enjoyed your practical help desk course. Cheers. So anyway, there's a plug for our help desk course which is on our free tier. Again, 100% free. So I mean nothing to waste other than your time if you want to take a look at it. All right. Which programming language do I need to know for reverse engineering? I have experience in Node.js, JS Express, and MongoDB. So it really depends what you're going to be reverse engineering, but for the most part, you generally need to understand uh C and some assembly. Although assembly is becoming less and less required now with how good the decompilers are, but probably should have a basic understanding of assembly and C. And then also like you'll want to still know the language and the quirks of whatever um language the application you're reversing was written in because the way that it works with the decompiler right is say you write something in Golang for example. So then that gets compiled and turned into assembly assembled into the machine code and linked into a binary. when you go and look at that binary, if you disassemble it, it will just be an assembly, right? Because that's the great equalizer of all the code. And then if you take a decompiler to that assembler, generally it's going to spit it back out in C. But that's not how it was written. Um, so you will want to understand some of the the quirks of whatever language you're going to be reverse engineering. All right. I'm new to the cyber world, but I have background in languages, geopolitics, social media, disinformation, etc. I'm really interested in red teamwork, but I feel like I'm years behind because of a lack of programming knowledge. Do you have any tips? Okay, first off, you definitely do not need to do programming or fully understand programming to get into cyber security. I mean, it really depends on what you want to do. So, if you want to go into red teaming in the literal sense of it, where you're going to be doing like adversary emulation and things like that, then yeah, you're probably going to need to understand um programming. But with your background in things like languages, geopolitics, social media, disinformation, I think you could definitely leverage those if this is something you're interested into to get into more of uh open source intelligence, social engineering roles in a red team. I mean, that could be very valuable. there are quite a few people that have careers in cyber security without doing as much of the technical stuff, but instead they're doing that kind of um social engineering testing. So um I would suggest there's a if that's something that interests you um check out the podcast Darknet Diaries and there is one I think it's just called a leaf. It's al e t h e. Um, and she talks about her journey of getting into cyber security and she actually just works as like a social engineer. So doing fishing, testing of physical security, things like that. So definitely something to check out. If you do want to learn programming though and you want to get into the technical side, um, I would suggest just getting started. It's not as probably intimidating as it seems. And nowadays with tools like chatbt and other um AI assistant tools you can it makes it a lot easier to learn programming in my opinion. So and again there's a free course in the free tier uh programming fundamentals 100 will teach you Python absolutely free. So, I would check that out. Just picked up the PhD training insert voucher on section four now. Solidifying knowledge foundation as I'm going into month six of a health test grow. Cool. Awesome. Uh, good luck on taking the certification and glad you're enjoying the course so far. Okay. It is really hard getting into cyber security field as a fresher. No one wants to hire an unexperienced fresher. If no one hires, how am I going to gain some experience? Yeah, that is a tough one. There's this uh catch 22 of you need experience to get a job and you need a job to get experience. So I definitely agree that is frustrating and I've experienced that myself as well. So I have a couple thoughts on this. So the first one is I will admit the job market right now at least I'm in in North America and it is not great right now. Not just cyber security but also for most tech roles the the job market is just not good right now. Um, and we've seen that come in es and flows up and down. It'll be really hot and then it's not. Um, and one thing that you know seems to always happen is it bounces back and then there'll be jobs again. So, and then that's when it's easier to get some experience in as a fresher. So, that's one thing. The other thing is there are ways that you can get some experience. So, I already talked about one, which is trying to leverage your current job or role. Do anything you can to get some experience there. There's also volunteering. So, sometimes there'll be ways to pick up volunteering. You can do things like go to conferences and volunteer to work with some of the villages to get some experience. That's one. Um, you can also, it depends like what what roles you're looking for. But right now, if you're trying to go straight into a cyber security role without any tech experience, that's going to be hard to do. Honestly, it's I'm not going to say that it's impossible, but you may want to um lower your initial goal and try for an IT role that's going to be easier to land and then move up from there. And I'm not saying all of this is ideal or fair or anything like that. I just really want to share the reality of the job market right now and what's going on there. Good question though. And yeah, it kind of sucks that that's the uh that's what's going on right now. Okay. I am not able to find a pathway to start. I have got a ton of different courses but whenever I start I feel like I'm missing the prerequisites like API web requests etc. So you might want to check out a road map then like we've got a few road maps or if you Google different road mapaps or look for one on YouTube then you can usually find um road maps to get to whatever your end goal is and then I would start by taking a look at that just looking to see if there's any other Yeah. follow up to this one. Yes. So if you're doing like red teaming as so there there's two def kind of definitions of red teaming that I think people sometimes mix together early on when they're learning about cyber security. So you have like the red team which encompasses all of the offensive security side. So penetration testers would fit into like that grouping. But then you also have red teeming which is like a subset then a more advanced adversarial emulation or where you're going to try and be like way more sneaky. Um and a lot of times part of that is launching um fishing campaigns or social engineering. that is what uh like criminals or nation state actors or things like that would also be leveraging uh to get initial access. So um understanding really good Osent and social engineering is going to be an absolute for that and a lot of times there will be teams and there might be someone on the team that that's all they do is their job is to get in get an implant planted somewhere sneak into the building get in whatever and get some sort of first access to the server room or the network and then the other teams are other technical people are going to take it from there. So yeah, there's a lot of few really good um Darknet Diaries episodes about these types of teams and their their exploits of breaking into buildings and social engineering their way in. All right, I got time for one more question here. All right, here's one. What are the platform where we can volunteer? Um, so what I would suggest is take a look at the conferences that are going on in your area and see if there's like villages or a local Defcon chapter or if there's a bides or something like that and then seeing if you can volunteer for those and start meeting people because the other thing that we didn't really I haven't really talked about yet but that is also super important for um landing your first job is networking. So going to these conferences, being active as a volunteer uh is going to help you network as well and then meet other people that may already have jobs or can point you in the right direction or make an introduction or a suggestion. But I would suggest volunteering at your local conferences, helping out there and then yeah, that's going to to go really far. I want to ask want to answer one more and then we'll hop in. So why is the job market not good? What personnel are impacted by the bad job market? So there's a lot of factors that are going into this um right now. So a few of the big ones is just the general uncertainty around the stock market and that really seems to impact uh tech companies because they have a lot of reliance on keeping their stocks good and it is very easy to um cut costs by laying off people that are developing things or that they see as cost centers like cyber security. Uh and then definitely in the US the layoffs around cyber security personnel in uh government positions definitely isn't helping the job market there because you now have a lot of people that were working um in the public sector that are going to be moving to the private sector and competing for those jobs. So that's a couple of highle reasons for it and what personnel are impacted. Like it's kind of all across the board, but I would say like it definitely impacts the entry level the most because sometimes people if they need a job and they have experience, they'll settle for something a little bit less experience than they have and it just kind of bumps everyone down all the way. So that is who is being impacted the most. So, that is a lot of good questions today and if I see any other good ones pop through, I will do my best to answer them. But I am now going to move over and we're going to run through this walkthrough and take a look at writing some custom shell code. Uh, and we'll see how far we get in it today. And if we don't get all the way through this level, then I'll pick it up the next time that I live stream. So, let me switch over here. Perfect. Okay. Move myself down here. Okay. So, I am going to be working through again the overflow me walk through here. So, let's just go to the main readme here. Um, so this is like a vulnerable binary and walkthrough that I've written to teach about uh exploit development, reverse engineering binaries, stack overflows, uh, you name it. So if you want to, you can grab it here. I'll get maybe if Brick can drop a link into the chat as well. It's just in my GitHub profile. Um, and so we previously ran through level one. So, a quick recap of what we did in level one is that we there's a a binary overflow me that we walked through, took a look at how it worked, found out that it was vulnerable to a stack overflow, and then we wrote a very basic exploit that just jumped us to another section of code. So, we learned about how the return address works um inside of the stack and how we can modify that. So the second level here. So I'll just jump into level two here. And then if we take a look at the readme. So each level has its own readme. So this one is shell coding and exploiting. So the challenge for this one is to get the overflow binary to print out the message TCM rules without modifying the source code. And then so if you do want to follow along um and later so if it's too if it's I'm going too fast today you can look at like every single step here inside of the read me without and it has all of the commands and everything you need to copy in. So definitely check this out if you're interested. It's all in this GitHub. Um I'm going to walk through as much of level two here as I can today and talk about how to write shell code, custom shell code. And then if we have enough time, we'll do the exploit. And if not, we'll we'll do the exploit next time. Alrighty. So, let's hop open VS Code. So, I am on a I'm just going to close all these here. This is a a Linux virtual machine that I'm just remoted into here. So, you'll need to be on Linux to run this. Perfect. So, let's pop open the read me here and we'll walk through this here. Okay, perfect. Okay, so this level makes use of assembly source code to help teach about the basics of binary exploitation. So, we can create this. So we go in here, we have this overflow mess, which just really quickly to review, um, we have this echo print function. And here is the assembly code here that's responsible for reading the user input and storing it onto the stack. And we're creating here, we're actually moving down the stack to allocate space on it to hold it 512 bytes. And then we read in here onto the stack. However, there is a issue with the code here where we have a mismatch. This u move into RDX is what sets up the read sys call with how many bytes we should read in. So we are reading about double we're allowing to read in about double the amount that we have allocated which is where we can have that stack overflow take place. So we can assemble this and link it with the make file that's here. So if we go make overflow me. Oops. Got to go into level two here. Make overflow me. What am I? If I could type that would make this a lot better. Perfect. And then we can run the binary here. So, it's just asking for an input. So, we should say hi. Prints it back out and says, "Thanks for not overflowing me." However, if we do put in um more than 512 characters, it will overflow it. All right. So, let's go back to the read me here. So, we just assembled and linked the binary and we did this echo print. So in the previous level we found that this binary was vulnerable to a stack overflow and if we crafted that specific input then we could actually have it jump to uh the return address that we specified. So what we did is we actually jumped it to a section of the code. If we actually just open this up here, overflow me, we have a section of the code here called hidden print. And we jumped to this section of the code which was dead code and executed it. So now what we're going to do is we're going to uh do what's called a stack smashing attack. and instead of jumping to somewhere that's already existing in the code, we're going to put our own code into the stack and then jump to that. So, let's go back to the readme here and then let's take a look. So, now we need to print out TCM rules, but that's not anywhere actually in the source code. Um so what we're going to do is a stack smashing attack which this is a very very old um type of exploit to do. And what we're going to do now is when we craft our exploit that's going to be input. So when we run this it, you know, it gives us an opportunity to input some text. Instead of just putting in a or anything like that, we're going to do a specific um crafted input that's going to put in our own shell code. And then we'll use the return address. We'll overflow that to point into the stack so that it's going to execute our shell code. And this is called a stack smashing attack. So the first thing we'll need to do when setting up for this exploit is to start writing our own shell code. So there are a few ways that you can just get shell code. You can go out on the internet and get it. Uh you can use something like MSF Venom like part of Metas-ploit to generate shell code. However, the issue with these is that they're most likely going to be picked up by different detection methods, antiviruses, things like that. And then also, a lot of times when you're doing exploits, you're going to have restrictions on size or bad characters or other things that you need to work around. So, you should um definitely learn how to write your own so that you can work around those. Checking through the chat here. See this one that I want to talk about because this is my course. Do we have a assembly course? Yes, we do. So, you should check it out. It's called Assembly 101 and we go over stuff like this in much more detail as well. So, thanks Hamza for letting him know as well. Okay, so back to the writing of our own shell code. So yeah, we're going to need to write our own shell code because what happens when we run this binary um overflow me or any any binary, what happens is it gets loaded into the computer's memory, right? So and it's actually, you know, loaded in as ones and zeros. That's why it's called a binary. And there's going to be different parts of the binary. So we might have text or data sections where we have strings but part of it is going to be the actual machine code. So our assembly gets translated into actual machine code which is ones and zeros. Those are the actual instructions that go into the processor and tell it to do something. So if we're going to be injecting into the stack which is in the actual memory, we need to we can't just inject in our own you know code even assembly or anything like that. We need the raw ones or zeros or their hex representation of that code to be able to inject it in. So this is where writing shell code comes into play. And the reason it's called shell code is usually you goal of it is going to be to get a shell, but really we can write it to do whatever we want to do. Um, and in this one specifically, it's just to print a string. So we'll take a look at um how to print it. And I'm going to show my process for doing this. There's a lot of different ways that you can do this. This is just one way that I found that works well for me. Um, but yeah, there's multiple ways to to to do this. So the first thing that I do then is I like to write my shell code in raw assembly itself and then I'll convert that. So I'll assemble it and link it into a binary and then pull the actual machine code out of that. The reason for that is because it's just way too way too hard to write machine code itself and there's really no advantage to it. It's a lot easier to write assembly. So when you are writing shell code, generally what you're going to be doing is just setting up to make a system call. So if you're not familiar with what a system call is in Linux, this is when we can pass off to the operating system and ask it to do something for us. So there's lots of different SIS calls. Uh usually that's how they're referred to as SIS calls. and one of them is printing, but there is a um very excellent list of all of the SIS calls here at this chart. So, I'll just pop this open here and then bring it over so we can take a look at it. So, we've got this sysol table here. This is from the Chromium projects. This is Google open source, but if you you scroll down, I really like this table because it goes through um the details of all of the SIS calls for Linux. And you'll notice we have all of them here. So, we've got read, write, open, close, and then there's a lot of them here. So, there's even ones like exec and things like that. So, if you want to do um shells or things like that, we're able to. However, the one that we want is just a right sys call. So the nice thing here is that it gives us a sys call number. So we need to know this. And then it also tells us um what arguments we need to pass in. So for this one there's three. There is the file descriptor. So for us it's going to be standard out. There's a pointer to a character. This is going to be the start of the string we want to print. And then there is the size. So this is how many characters we want to print. So when I'm writing shell code, regardless of what I want it to do, I usually start by consulting this table and then picking the SIS call because pretty much that's always generally going to be what you're doing is setting up to make um some sort of SIS call and then passing that off. And then if you want some more details as well, you can go to the man pages for them. So here's one right here for the right sys call. So if we check out the man page here, you get some more details about it as well, which makes it a little bit easier. And sometimes there's some examples as well in these man pages. So taking a look at that right sys call we need arc zero which is rdi which is one of the registers in the processor that's set to the file descriptor which in our case is standard out. Arg one which is rsi is a pointer to the first character in the string. uh arg 2 is rdx which is the number of chars we want to print. So the steps that we'll need I like to write these out when I'm first starting out with um writing shell code is to just write out all the steps that we'll need to do. So the first thing is we'll need to push the string we want to print onto the stack in reverse order. So the reason for this if you have written other assembly or looked at it you might see that they can have like a a data section where we can put strings into uh our binary but we can't have any of that. We need everything to be self-contained in our actual shell code. Um so to do that we're going to push the string we want to print onto the stack. And you'll see this happening even in more advanced shell code where we're trying to execute cue a command or something. it'll be pushed onto the stack and we need to push it in in reverse order because of the way that the stack grows. So after that we'll then need to set rax to the sys call number which for read we just saw is one. We need to set ri to the file descriptor number for standard out which is also one. Then we need to set RSI to point to the start of the string, which conveniently for us is where the stack pointer is because if you think about how the stack works and if we push on um those eight characters for TCM rules, then it's going to move the stack pointer down eight bytes. And since we pushed it on backwards, then it's going to be right at the start of that T and then we can print through it. And then we just need to set RDX to the length of the string to print, which is eight. So if you want to see the code for this, which I'll go over now, this is print_shell code. S. So we can take a look at it here. Instead of just, you know, writing it out, I've included it here so we can talk about how this works. So at the start here, these are just assembler directives that are going to be required to assemble this. So the first thing we do again, this is setting up to push onto the string. So this is the actual ASI representation of TCM rule. So this is T for example, this is Z. Um and we're pushing this on in reverse order. Then we push it onto the stack. Then we have these moves here which this one just sets RX to one, sets RDI to one. Then we move the stack pointer into RSI because RSI is pointing to the um top of or is going to be pointing to the stack and then we move uh 8 into RDX and then we perform a sys call. So now what we can do is actually just assemble and link this and run it and make sure that it actually works. So again I've included a make file here. So, if you're not familiar with make, make is a tool um to help with compiling, assembling, linking, it's kind of like a build tool. Uh, and then it includes like all of the bash that would actually go behind the scenes and do what needs to be done. So, if you're curious what's happening behind the scenes, check out the make file. Um, so we can run make print shell code here. Perfect. And now you'll notice we actually have the binary there for print shell code. So if we run this here, we go dot slashprint shell code, you'll notice that it printed out TCM rules just like we wanted to. Uh however, then we have a segmentation fault, which means it crashed. Uh and seg fault usually means we're trying to access bad memory. So the reason for that is if we actually take a look at uh the code for this which right here we didn't end this program properly. So we didn't follow the proper flow of we should you know exit properly have a proper function epilog. We didn't do any of that. But that's okay because all we're concerned about is then being able to rip the raw machine code out of this. We don't care that this actual binary itself for this crashed. All we did was compile this so that it will get turned into the machine code and then we can grab it. Um, so to do that there's a few ways and I'll just walk through the one way that I like to do it. So first off, I'll usually look at it with a tool called obj dump. So that's obs terminal here. OBJ dump. And then we need to actually give the the syntax it's in. So this one's in Intel format. And then we'll go dash d for disassemble. And it's going to be called print shell code is what we named the binary. Perfect. And so this gives us some details about it. It's alf x and x64 x86-64. And then we have the disassembly here. So these left columns, this is all the memory addresses. In here in the middle, this is what we want. This is the actual machine code. And then to the right of it, we have the actual assembly. So each of these lines here refer to one instruction. They're called an op code and we actually want all of this in the middle. So the one thing with objump is it's kind of hard to get it to just print out the machine code. So you know we could like go through try and copy this then delete all the other stuff. We could do some like bash um for it as well. But I actually have um another tool that I really like to use that makes this a lot easier. It's called XXD. So if you run xxd and then you just run that on the binary. So it's print shell code now we get it in a little bit of an easier format. However, if we actually run that again, but we pass in the -p option, it will actually just show us the raw um hexadesimal of this. So you notice there's like a lot of zero padding and stuff in here still. But since we ran that odd jump, which I will just run it again here now, we can see where the start and end of it is. So it ends with 0 F-05 and it starts with 48 B954. So what I like to do then is I'll just pipe this into GP. I'm going to do A2. So we bring back two lines. And then I'll just do the first maybe three or four characters here. So we'll go 48 B9 54. Perfect. And then we can see all the code here. And we're just looking for where it ends with on 05. So then I'll grab this right here. Copy that. So that's the actual shell code here. So if I just actually paste it here. So you can see that now is the actual just string of raw uh shell codes that we need. So this is what we would use in our exploit. However, before we run that, what I like to do or before I actually waste time going and trying to go with the exploit because there can be a lot of stuff that goes wrong in your exploit. You want to make sure your shell code works. Um, so to do that, one of the easy ways is you can write a C program that you know works that basically mimics what happens when your shell code gets run. Um, so I've written one here called test_shell. C. And this is a basic yeah C program that essentially will execute shell code similar to how if you were to execute it out of the stack. Um, so all you need to do is just paste in your shell code here, which I've already got one example here. paste this shell code in and then compile this and run it and make sure it does what you expect it to do. So you'll notice here we actually need though our shell code to be in what's called hexadimal escape sequence. So we have this x slash in front of it. So if we just paste ours in here um we have it in this format. So we could go through and you know manually do slashx before each one. However, that is not very time efficient. So, I also have a Python script that I use for this um which I call shell code_formmatterater.py. So, we'll go Python 3 shell code and then you just paste in the string. So, just keep in mind if you copy it through GP like this, you'll notice how I've got two lines here. So, make sure you get rid of that extra line. And then yeah, this this just formats it, pops it out into how it's supposed to be set. So I'm gonna grab that and then we'll paste it into here. Save that. And then it's actually nice. I just put the compilation instruction right here into a comment. So we can copy this, paste it and then if we just run this dot slash test shell. Okay, so this printed it out and it worked. So you'll see here we got TCM rules seg fault. So this is good to see because it's basically exactly as when we ran the binary but just with the shell code stripped out. So now we know our shell code works. However, there is one more key step here that we need to take a look at. So in my in this program, I wrote it to also print out the length of bytes that it sees for the shell code. And you'll notice that it uses string len for that, which is a C function that works on strings. And if you take a look at it, it printed out 15 bytes. So if you look at the code here and we go so for example there's one 2 3 4 five 6 7 8 9 10 11 12 13 14 15. So there's 15. There's a lot more. So the reason for this is because the next bite here now is x0 0. So in C 00 or X0 is what's considered a null terminator. So that is used to signify the end of strings. So when this shell code which initially is going to be usually interpreted as data not machine code is uh handled by CC code that is treating it as a string. It sees this and says yes this is the end of the string. I'm not going to do what I want to do with this. So, for example, when it does string length, it's just loops over this. If you actually looked at like the the barebones assembly of it, it checks each of the bytes, you know, in increments a counter until it gets to zero and then it just stops. So the issue with this is very frequently in Ccode if you have stack overflows, buffer overflows, whatever, they're usually going to be from an input from a user which is going to be treated as a string. So for example, it might be copying things into a buffer which means that our shell code will not fully be copied in. So we need to avoid using null terminators. And now there could be other things too in the code like it could be stripping out maybe commas or spaces and all of those have their own asky character that is different than what is being used in the op code. Um so we need to find a way to be creative with how we write our assembly so that we do not include any bad characters. And for us in this one it's fairly easy. There's only one bad character which is zero. So let's take a look at how we can go about removing that. But first let's look at the offending um lines here. So if we run objump again here and then what is it? M dash. Yeah, that's right. Perfect. So each one of these lines here we want to look at and see if they have zero zeros in them. So if they have like one zero like this, right? That's fine. So this because remember we're working in bytes. So this is getting treated as zero f. However, if we look at so we've got three lines here that are going to be the ones impacting us. So this one, this one and this one. So the reason for that is if I just like write this out here. So if we do something like move uh rcx 8 or whatever uh or maybe rax1. So if we do that because rax is the full register this is actually the equivalent of writing out uh this it'll be like 1 2 3 4 5 6 7 right so that's why we end up with if I just clear this again and run that objump that's why we end up with all of this because the the actual op code for move rax is this 48 c70 and And then after that, we just put the number that's going to be moved in, which is all of those zeros. So, luckily, there's a way to get around this. And you'll notice for us, it's pretty straightforward. We just it's all these moves that are messing us up. Um, so for legacy purposes, we can actually move directly into um the lowest bytes of the register. So, I've already got it out here. So, we can take a look at it here. So instead of moving into all the way into RAX, we can go into the A low which is the lowest um bite of the register of the whole RAX register. So if we move one into this, then the op code for this is not it's just going to have zero one in it. It's not going to have all the zeros. The one thing to keep in mind when you are doing moves like this is that the other um bytes or segments of the register they aren't automatically cleared out. We can't trust what they are and the sis call is going to look at all of rax itself. So what we have to do beforehand is we actually have to go and zero out ra. So one thing we could do then is try and move zero into it. But then we're back into our scenario where we are using zero again. Luckily, we have access to exclusive ore, which is probably one of the most um powerful uh tools that you can use in assembly. You'll see it used a lot for lots of different things. But with an exclusive or if you exor the same thing with itself, it will always be zero. Just the way that it works. So if you exclusive or rax with rax that means that it will just essentially put zero into it. Now the nice thing about that is though that op code will not have zero anywhere in it. So you'll notice before we move in here we zero it out. Then rdi we just do a trick of well there's already one in rax so why don't we just move that into uh rdi. And then again to get into the rdx we do the same trick. We zero it out here. And then now if we go and make this. So we'll go make and it is uh what is it? Print underscore shell [Music] code_rm_bad_ch. Perfect. So now if we run well we can just run this and make sure it works. Works just like we wanted it to. And if we run uh objump on that. So perfect. So now if we take a look at it, if we go through all of these down here, there are no zero zeros anywhere in this. So we've got rid of So just a little bit of creative thinking about how different ways we can do this. Um, we have now gotten around those bad characters because now if we run that same uh xxdop and now we can grab here go Python three. Grab this now. Okay. And now go into test shell. Blow this all out of here. Now we can recompile this. So that's GCC. Perfect. So let's run. And now we get that it's 29 bytes and it runs properly. So now at this point we have our exploit string ready to go. Uh this kind of took us to where I thought we would get um at this point in the lesson. So since we're about an hour in now, I'm going to answer just a few more questions because I saw there were some good ones um come through here. And then the next time that I live stre