 Hey folks, Adam DuPay here, and today we're going to be looking at the ponable.kr challenge BOF. So reading this challenge, it says, Nana told me that buffer overflow is one of the most common software vulnerability. Is that true? And the answer to that question is yes, buffer overflow is one of the most common software vulnerabilities even though it's now almost 30 plus 40 years old. And the interesting thing here, unlike all of the previous challenges we've seen so far rather than having an SSH to a machine, we download the binary presumably and the .c file and it's going to tell us that it's running at on the machine. So what this is, this is netcat. So this is a command to create a pzp connection to the machine located at with ponable.kr on port 9000. So presumably when we look at this c code that will actually be there. So I've, let's see. So here I have the code here. And this is actually a very short program, which is nice. So here we have, let's see the main function argc argv doesn't do anything with the arguments calls function with 0x dead beef. This function gets called with a key and has a buffer called overflow me with 32 bytes and a print f of overflow me and then calls gets on overflow me. And one of the things we know is that gets is inherently insecure. Why? Because it reads a line. So it reads from standard input until it gets to the end of a line and it copies all the bytes into the buffer. But there's absolutely no way beforehand to know how many bytes you're copying into this buffer because you can actually look at the signature of gets. It does not take in an integer to specify how much of the buffer to read. So this is a clear problem here. And so and it's obviously the title of it is bof, which probably stands for buffer overflow. So it's going to call gets buff overflow me. And then it's going to check if the key is equal to cafe baby. Then it will call system SH which gets us a big SH shell, otherwise it prints out not. And it has so you can see that what gets passed into function is dead beef. So this check should never occur. And we can actually check this ourselves. We can do copy this line here netcatpunable.kr9000. And it's waiting for some output from us will say hello. Or maybe it's hanging. Let's use the V option for netcat that will tell it verbose mode. So it'll tell us more information about what's going on. And so presumably this should work if the internet is working properly. There we go. So now this is the dash B. So this is the connection to planable.kr9000 port succeeded. We should get the we should get this overflow me output. But if not, we can still type in our input hello world. And says overflow me. So we can see we got to the we got the overflow me. One reason why we don't actually see this overflow me, presumably they're using XINETD to run these thing to run this output. And because of the buffering that's happening, it will usually buffer an only output when it gets to a standard output. So if this is overflow me new line, it would actually print that out. Or if there was an F flush after this print F, it would probably flush it as well. So that's just some kind of details to kind of help you think like, Oh, man, is it actually working? It is actually working properly. So great. So now we we also have it locally. And so the idea is we need to change this key to be cafe baby. So one key thing that I like to do when I'm looking at these challenges, especially a buffer overflow, the C code is great. But really, when you're doing a buffer overflow, you've got to look at the binary itself because you want to overflow exactly as much as you need to. So what I'm going to do is I'm going to open this up in hopper. And I think I actually have this already. So I use hopper, you can use object dump, you don't actually need anything fancy for this object dump dash capital D to try to disassemble everything of bof and pass that through less. So we can see here, we get all of this and I can search for main or. So that's the main function, I can search for funk. And actually, I don't even need hopper. So I won't. Let's not use this. Well, I'll show you, you can do this just with GDP, but any kind of disassemblers. So here we're looking at the assembly instructions. So we can look at the C code. And this is the C code. And then we can look at the assembly instructions to see, okay, what does the C code get compiled into. So by looking at this here, you'll notice there's some interesting things in here. For instance, this call 645, presumably the linker will go in and link that up to the actual call that it's supposed to be. But we know so we can easily check. So if key is equal to cafe baby, so here's compare EBP plus eight with cafe baby. So that's exactly what we want to deal with here. So what we can do, so we know that this is the comparison. And so we know right before that is the call to gets. So this instruction is going to be the call to gets. And then here, this is going to, if we look at this code here, this is going to move EBP. So load effective address is going to calculate whatever's in EBP minus two C and copy that value into EAX. And then it's going to move EAX onto the stack and then presumably call gets. So this means that gets is being passed our buffer. So we know that our buffers at EBP minus two C. So why is this important? This means we can start constructing our exploit. And because this thing is remote, what we're going to do exploit.py is we are going to use PON tools to do this. And this has a lot of benefits so that this way our exploit is repeatable. And we can launch our exploit at the remote system or we can even launch it against our local machine. So I need to get the I already have a solution for this. So I'll not try to do this. So let's do this. There we go. We'll just copy this. So we're going to input from PON tools, we're going to input all we're going to set the and if you don't have PON tools, you should definitely check out PON tools. It's a great tool chain to use. And it's really important, even on these very basic challenges to write them in these PON tools format because that becomes incredibly important. And getting those skills is really important for future CTF. So if you can't quickly write a Python script to use PON tools on a simple challenge like this, then how are you going to do it on a more complex challenge? So that's an important thing to be excuse me be able to practice. So what payload do we want to send? Well, we know our buffer. So the problem is, if we just looked at the C code, we'd say, oh, our buffer is 32 bytes. But depending on how this is compiled and how the compiler wants to allocate space on the stack, we can see here, if we go back here, that our buffer is actually allocated negative to C below EPP. So if I get a calculator, and I can calculate C to C calculate that it's actually 44 bytes. So what I need is, and I can actually do to see here. So these. So when we think about what's the stack layout going to look like. So there'll be an actual bring up notability to do this because I like doing this here. So let me go here. Good thing. There we go. All right. So what we know, so we have our lovely, lovely stack, and I don't have a good drawing utensil. So I'm just being very getting kind of a rough stack here. So we know, let's say EPP is here, right? This is EPP. And we know, so this is a stack. So remember, I always draw it zero X, zero, zero at the bottom, and these are all Fs. So this is FFFF. And so at, so here's EPP at EPP minus 2C is our buffer. So this distance here is going to be 2C, right? So it's important it's not 32. So just try to do 32. You're not going to overflow. But if we, so when we start writing, when we have this gets command, now we're going to fill this up with A's. So all of this in our exploit that we're writing here is going to be 2C A's. Now, what is currently at EPP? It's the saved EPP. So it's the previous function frames EPP. Above that, we have saved EIP. And in a normal buffer overflow, this is what we'd be trying to target is to try and overflow that saved EIP. Of course, that's not always the case. So above what we do want to do is above that is the key. So this is the value that we will want to overflow. So what we're going to do is we want, we're going to have 2C A's, then we're going to have four bytes of the EPP, and then four bytes of the instruction pointer, and then our key. And so that's going to be, and we can make this a little bit easier. P plus equals B, P plus equals the C. Now this is our key. So now we just go back to the C code here. And, you know, it's always good. Actually, the first time I did this, since this is a walkthrough, I manually typed in cafe baby, and I did cafe BB, BEBE, and it did not work. And it took me a good 30 minutes of debugging time. So P32 is a function that's going to pack that in terms of little endianness. So it's going to make sure that the endianness is correct here. So rather than we could do this ourselves and go XBE, XBA, and so on. But this is one of the things of getting used to and getting better at using Pone Tools is we don't need to do that. And now we should be able to send a line. And why do we need send line? Well, when we looked at the man page for gets, it reads a line. So it reads until it gets to a terminating new line. And so that's what we want to make sure to pass in. So we need to send a line, send our P, which is our payload, and then connection dot interactive. And that will turn this to be interactive. And so let's see how this goes. So Python exploit. So it's opening a connection to LS. Cat out the flag. And here we go. So actually, I can see that here's all the files here, you have bof, you have everything that you need. And we have the flag right here. We did cat flag. So there we go. We just pwned it. And go back here off. Of course, the login here, it must set cookies to a very short value. So do bof, flag it, auth it. And we already authenticated it. So there you go. That's the walkthrough. And that's how you do the buffer overflow for the Poneable.kr challenge. Alright, thanks, folks. See you later.