This is my first time watching a series of binary exploitation and I think you couldn't have explained it any better. As a noob at binary exploitation, I was able to understand all the concepts you taught very well and the writeups that you shared helped a lot as well. Thank you for creating such a wonderful playlist. You are an amazing teacher, sir.
hello, I have several questions: 1. Why we look for rsp when search for the rip offset. Is that only applicable for x64? 2. Why we need the enter other input like 'A' in the first example, after that we enter the value of cyclic (at 13:34 in the video). How do we know to do like that because the previous example just need us to enter the cyclic value directly
1) Exactly, IIRC 64-bit programs don't allow invalid memory address in the instruction point (which the cyclic pattern obviously is) so we read from RSP. The 32-bit programs do display in the EIP 2) I probably just used A's, B's and C's to help visualise the payload structure in the previous example
I have this gbg issue that closes the gbg terminal that opens open after the code executes but getting the base manually after finding the main function address is not so bad so It's alright
Hi! I got 2 problems: 1. When I'm trying to get the padding offset for the buffer overflow, I always get the offset 327. But if I tried it in my exploit, it doesn't work. Looks like using your offset (264) was able to pull out the puts address and all the stuff. 2. I got the libc, system and bin_sh address (using offset 264), and I also checked them manually like you did in the video at 24:30. But if I am running the whole exploit, the program just crash. Did I missed something ? Unfortuatelly, none of the scripts worked for me ;( Btw, this the best binary series I've ever watched.
Thank you! Did you try using the binary from the github repo or compiling it yourself? Whichever you did, try and do the opposite and see if it works. Also, bare in mind that the addresses and offsets will be different for your own libc.
@@_CryptoCat Both mysteries solved. 😋 1. I was receiving offset 327 because i entered the cyclic payload immediatly when i started the program, so I forgot that I had to do the format string exploit before entering the payload to bufferoverflow 2. I had to add 'ret" gadget to my payload to do the stack alignment (I still don't know exactly why I have to do that, but I know you provided some resources for that, so I will look into it now. And I should not skip your resources anymore :D). My final payload is: payload = flat ({ padding_offset: [ p64(ret), # where ret = base_pie + 0x1016 # the offset can be found using ropper pop_rdi, bin_sh, system_addr ] })
Awesome Awesome Video man, Thanks for all you do This one had a bit of confusing parts, maybe it was because of we relied mostly on automation and I'm ass at automating xD
hi, when i run all my script, exploit, autopwn, and ropstar the output its always: Process './pie_server' stopped with exit code -11 (SIGSEGV) (pid 1090) [*] Got EOF while sending in interactive can u help me??
when i checked in other vid, like in part 6, return to libc, when i execute the program say : Process './secureserver' stopped with exit code -11 (SIGSEGV) (pid 2457) [*] Got EOF while sending in interactive
Hmmm very difficult to debug from my end.. I can't recall someone else running into this issue with all the binaries. Maybe some permissions issue 🤔 What OS are you on?
Hello ! I was wondering, it seems like i cannot find any "pop rdi" gadget with ropper, only a "pop rbp". is there something i'm missing ? Or perhaps could it be because of my libc ?
Hey, i really love your videos but i'm struggling to understand this one. You say that PIE is randomization of base address to make the code layout unpredictable for attackers. But in this case pie base is always the same so if we leak the pie base we just win and we can do the same method you show in the last episode isn't it ?
Thanks! Been a while since I made this but maybe ASLR is disabled system wide - flameeyes.blog/2009/11/02/the-pie-is-not-exactly-a-lie/ Give it a go with ASLR + PIE enabled and see how it goes 😊
We're looking for an address that will help us find the the base on the binary, a lot of the values we see are clearly not memory addresses (0xc2, 0xa70243625, (nil), 0x10000000 etc..) so we'll rule those out first. Next, many addresses start with 0x7fffffff, which is nowhere near the range of our program memory (but these are likely to help us find the lib-c base later), so we rule those out. We're left with 0x55555555xxx addresses, which is the correct range for the program (you can run in GDB and see what addresses get assigned to functions etc in general). So, the next criteria is that we want the address to be stable, e.g. have the same offset (last 3-4 digits) each time the program runs. I picked 9 (the 10th index) but probably many other values on the stack would of been suitable, we just need to adjust the offsets in our exploit script accordingly 🙂
@@_CryptoCat thanks so much for your help! I was able to solve my first buffer overflow ctf challenges thanks to following techniques in your video series.
Hey! A few people have contacted me about this, looks like a compiler update has changed the instructions around. I can't remember what they swapped it with, it may still be possible to construct a payload for the ret2win but probably best to download the binary if you're just learning. You could also try compiling with an older version of gcc or manually adding a "pop rdi" instruction to the C code, something like this: github.com/Crypto-Cat/CTF/blob/main/pwn/binary_exploitation_101/06-return_to_libc/32-bit/secureserver.c 🙂
Great video series but I'm afraid this one confused me a bit. I would have loved to have seen the grabbing "puts" address done manually so I could understand what's happening instead of using elf.got.puts. Can you please try to explain the difference between "elf.got.puts" and "elf.plt.puts" when you are using them in your payload? I'd like to understand how to do this manually if I don't have access to use Pwntools for a target binary
Ah, good point, sorry about that! You can check episode 6 to see how we can find the lib-c function offsets manually, around this timestamp: ruclips.net/video/0CFWHjc4B-I/видео.html and you can do similar, or use ghidra/GDB/radare etc for identifying the offsets manually.. In this video, around timestamp 7:28 you can see the offsets of functions in the got.plt. Note that puts() is 0x4018, so once we calculated the base of the binary, we could replace the "elf.got.puts" in the script with "elf.address + 0x4018". The "elf.plt.puts" was offset 0x1030 in this case, so we could replace it with "elf.address + 0x1030" in the script. As for the difference between the two, the address of "plt.puts" is just a stub that looks up addresses in the "got.plt". If the function has already been called before, the got.plt will contain the address (in lib-c), if it hasn't been called before, it will first look up the address and then write it. This means if you try to leak a function that has not yet been invoked, it wont work (leaking the function you're invoking is ok). I simplified that a little bit.. There's actually a ".got", ".plt", ".got.plt" and ".plt.got" 😆 Basically the .plt just contain stubs to jump to the target (.got), which is holding the actual address. Here's a good explanation of that: systemoverlord.com/2017/03/19/got-and-plt-for-pwning.html
@@_CryptoCat Thanks very much for getting back to me. That all makes sense, thanks for explaining. I have watched all the videos up to this point, was just confused on that part
@@jeremypeaks2800 np, i should of explained that a little more. The next episode involves overwriting a GOT entry using a printf() format vuln, so hopefully that will provide some extra info 😊
I followed along with this tutorial, but I can't get the exploit.py to work. I can get the binary to run system and set rdi = "/bin/sh", but I get stuck at this instruction: "► 0x7f4f9c207973 movaps xmmword ptr [rsp], xmm1"
I disabled ASLR at the start of this video, but it's not required - you can skip that part if working on the challenge 🙂
This is my first time watching a series of binary exploitation and I think you couldn't have explained it any better. As a noob at binary exploitation, I was able to understand all the concepts you taught very well and the writeups that you shared helped a lot as well. Thank you for creating such a wonderful playlist. You are an amazing teacher, sir.
Awwww thanks, great to hear! 🥰
Another awesome video man. I've learned a lot from watching this series!
ayyy thanks again mate! appreciated 🥰
As always, excellent and detailed explanation of the topic. Thanks !
thanks mate 🥰
hello, I have several questions:
1. Why we look for rsp when search for the rip offset. Is that only applicable for x64?
2. Why we need the enter other input like 'A' in the first example, after that we enter the value of cyclic (at 13:34 in the video). How do we know to do like that because the previous example just need us to enter the cyclic value directly
1) Exactly, IIRC 64-bit programs don't allow invalid memory address in the instruction point (which the cyclic pattern obviously is) so we read from RSP. The 32-bit programs do display in the EIP
2) I probably just used A's, B's and C's to help visualise the payload structure in the previous example
I have this gbg issue that closes the gbg terminal that opens open after the code executes
but getting the base manually after finding the main function address is not so bad so It's alright
Hi! I got 2 problems:
1. When I'm trying to get the padding offset for the buffer overflow, I always get the offset 327. But if I tried it in my exploit, it doesn't work. Looks like using your offset (264) was able to pull out the puts address and all the stuff.
2. I got the libc, system and bin_sh address (using offset 264), and I also checked them manually like you did in the video at 24:30. But if I am running the whole exploit, the program just crash. Did I missed something ?
Unfortuatelly, none of the scripts worked for me ;(
Btw, this the best binary series I've ever watched.
Thank you! Did you try using the binary from the github repo or compiling it yourself? Whichever you did, try and do the opposite and see if it works. Also, bare in mind that the addresses and offsets will be different for your own libc.
@@_CryptoCat Both mysteries solved. 😋
1. I was receiving offset 327 because i entered the cyclic payload immediatly when i started the program, so I forgot that I had to do the format string exploit before entering the payload to bufferoverflow
2. I had to add 'ret" gadget to my payload to do the stack alignment (I still don't know exactly why I have to do that, but I know you provided some resources for that, so I will look into it now. And I should not skip your resources anymore :D). My final payload is: payload = flat ({
padding_offset: [
p64(ret), # where ret = base_pie + 0x1016 # the offset can be found using ropper
pop_rdi,
bin_sh,
system_addr
]
})
Great job! 👊
Awesome Awesome Video man, Thanks for all you do
This one had a bit of confusing parts, maybe it was because of we relied mostly on automation and I'm ass at automating xD
Thanks mate 💜
hi, when i run all my script, exploit, autopwn, and ropstar the output its always:
Process './pie_server' stopped with exit code -11 (SIGSEGV) (pid 1090)
[*] Got EOF while sending in interactive
can u help me??
when i checked in other vid, like in part 6, return to libc, when i execute the program say :
Process './secureserver' stopped with exit code -11 (SIGSEGV) (pid 2457)
[*] Got EOF while sending in interactive
Hmmm very difficult to debug from my end.. I can't recall someone else running into this issue with all the binaries. Maybe some permissions issue 🤔 What OS are you on?
I experienced the same incident, my OS: Linux kali 6.8.11-amd64 #1 SMP PREEMPT_DYNAMIC Kali 6.8.11-1kali2 (2024-05-30) x86_64 GNU/Linux
Hello ! I was wondering, it seems like i cannot find any "pop rdi" gadget with ropper, only a "pop rbp". is there something i'm missing ? Or perhaps could it be because of my libc ?
Hey, I believe there's some updated to lib-C / compilers as I see this a lot now. You could try to use older one or look for another exploit chain.
This is so helpfull !! Thank you
🙏🥰
Hey, i really love your videos but i'm struggling to understand this one. You say that PIE is randomization of base address to make the code layout unpredictable for attackers. But in this case pie base is always the same so if we leak the pie base we just win and we can do the same method you show in the last episode isn't it ?
Thanks! Been a while since I made this but maybe ASLR is disabled system wide - flameeyes.blog/2009/11/02/the-pie-is-not-exactly-a-lie/
Give it a go with ASLR + PIE enabled and see how it goes 😊
Awesome video, thanks
15:32
How do you know that value’s interesting?
We're looking for an address that will help us find the the base on the binary, a lot of the values we see are clearly not memory addresses (0xc2, 0xa70243625, (nil), 0x10000000 etc..) so we'll rule those out first. Next, many addresses start with 0x7fffffff, which is nowhere near the range of our program memory (but these are likely to help us find the lib-c base later), so we rule those out. We're left with 0x55555555xxx addresses, which is the correct range for the program (you can run in GDB and see what addresses get assigned to functions etc in general). So, the next criteria is that we want the address to be stable, e.g. have the same offset (last 3-4 digits) each time the program runs. I picked 9 (the 10th index) but probably many other values on the stack would of been suitable, we just need to adjust the offsets in our exploit script accordingly 🙂
@@_CryptoCat thanks so much for your help! I was able to solve my first buffer overflow ctf challenges thanks to following techniques in your video series.
@@anntakamaki1960 No problem! That's great to hear, well done 👏
Great videos!
thank youuu 💜
Why can't I find the pop rdi gadget ?
Hey! A few people have contacted me about this, looks like a compiler update has changed the instructions around. I can't remember what they swapped it with, it may still be possible to construct a payload for the ret2win but probably best to download the binary if you're just learning. You could also try compiling with an older version of gcc or manually adding a "pop rdi" instruction to the C code, something like this: github.com/Crypto-Cat/CTF/blob/main/pwn/binary_exploitation_101/06-return_to_libc/32-bit/secureserver.c 🙂
wow
🥰
Great video series but I'm afraid this one confused me a bit. I would have loved to have seen the grabbing "puts" address done manually so I could understand what's happening instead of using elf.got.puts. Can you please try to explain the difference between "elf.got.puts" and "elf.plt.puts" when you are using them in your payload? I'd like to understand how to do this manually if I don't have access to use Pwntools for a target binary
Ah, good point, sorry about that! You can check episode 6 to see how we can find the lib-c function offsets manually, around this timestamp: ruclips.net/video/0CFWHjc4B-I/видео.html and you can do similar, or use ghidra/GDB/radare etc for identifying the offsets manually..
In this video, around timestamp 7:28 you can see the offsets of functions in the got.plt. Note that puts() is 0x4018, so once we calculated the base of the binary, we could replace the "elf.got.puts" in the script with "elf.address + 0x4018". The "elf.plt.puts" was offset 0x1030 in this case, so we could replace it with "elf.address + 0x1030" in the script.
As for the difference between the two, the address of "plt.puts" is just a stub that looks up addresses in the "got.plt". If the function has already been called before, the got.plt will contain the address (in lib-c), if it hasn't been called before, it will first look up the address and then write it. This means if you try to leak a function that has not yet been invoked, it wont work (leaking the function you're invoking is ok).
I simplified that a little bit.. There's actually a ".got", ".plt", ".got.plt" and ".plt.got" 😆 Basically the .plt just contain stubs to jump to the target (.got), which is holding the actual address. Here's a good explanation of that: systemoverlord.com/2017/03/19/got-and-plt-for-pwning.html
@@_CryptoCat Thanks very much for getting back to me. That all makes sense, thanks for explaining. I have watched all the videos up to this point, was just confused on that part
@@jeremypeaks2800 np, i should of explained that a little more. The next episode involves overwriting a GOT entry using a printf() format vuln, so hopefully that will provide some extra info 😊
I followed along with this tutorial, but I can't get the exploit.py to work. I can get the binary to run system and set rdi = "/bin/sh", but I get stuck at this instruction:
"► 0x7f4f9c207973 movaps xmmword ptr [rsp], xmm1"
Hmmm might be stack alignment issue, see if you can add a ret instruction to the payload like here: ruclips.net/video/Q5Xx3aM0cUE/видео.html
@@_CryptoCat Thank You So Much For This 😭😭😭.