Go check out my Medium post on the same topic: medium.com/@lowlevellearning/your-first-buffer-overflow-b44e5ba5598a

A few additional notes for those who are interested: - At 3:13, we use `objdump` to find the address of the `debug()` function. Note that this only works for program binaries that are compiled with no ASLR (hence, the `-no-pie` GCC flag). Enabling ASLR will randomize the base address of the executable. However, note that even when ASLR is enabled, it does not mean that the program is invulnerable. Some techniques would allow attackers to leak the base address of the executable and thus, they would still be able to find the address of the `debug()` function by using relative offsets. - At 4:14, we determine our initial guess for the payload size by looking into the source code for the length of the `password` buffer, which is 64 bytes. This does not mean that compiled programs with no source code available to us are not vulnerable to this attack, assuming that they also use `gets()`. First off, we can reverse engineer and statically analyze the compiled code to find that `64` constant. A much easier method would be to dynamically run the program using `gdb` and inspect its memory during runtime to figure out the length of the payload needed to overwrite the return address. Alternatively, there is also a great library called `pwntools` that can also allow us to figure out the payload length by inputting a de Bruijn sequence. - This attack can only be performed if there are no stack canaries (hence, the `-fno-stack-protector` GCC flag). However, even with stack canaries enabled, this (again!) does not mean that programs are invulnerable. Some techniques would allow attackers to leak the value of the stack canary, which would render it useless since now, attackers can simply include the stack canary in their payload. - What if there are no functions like `debug()` in the first place? After all, a real production-grade application would surely have no such tantalizing target functions that allow attackers to drop a shell and execute arbitrary code? Well, even without the `debug()` function being present, as long as attackers are still able to overwrite the stack, they can still perform a technique called return-oriented programming or a return-to-libc attack. The basic idea would be to "return" to and jump around between snippets of code in other functions of the binary or even in library functions (such as in `libc`). These code snippets are called "gadgets". With a sufficiently large library such as `libc` (which is definitely used by many applications worldwide), return-oriented programming is Turing-complete. Hence, attackers can eventually do whatever they want, including dropping a shell and executing arbitrary code. The lesson to learn here is that mitigations can be bypassed and they should not be considered silver bullets in production-grade applications. Buffer overflow is also generally considered the simplest class of vulnerabilities (there are more involved ones such as double-free attacks, race condition attacks, and side-channel attacks). Try to avoid having buffer overflow vulnerabilities in the first place at all costs by reviewing your code and by using tools that could analyze your code and detect such vulnerabilities (either statically or dynamically). That is the only way to make your code truly more secure!

the biggest vuln in your server is that your service says the words "welcome to" in its announcement banner, and nothing about unauthorized access being prohibited, thus ensuring that anyone who breaks in cannot be prosecuted under the precedented legal defense "It literally welcomed me in, therefore my access was not prohibited"

In the end it's not necessarily about being a genius, it is about understanding how it works..

keep uploading more exploit dev / binary exp videos bro, great job

Wow :) very good desc of how a buffer exploit works. I knew the theory but great to see how it actually works in practice.

echo "Perfect video; Amazing Content; No Waste Time; Sponsor at the end, that i see entirely for respect and becouse doesn't ruin nothing; = Great Job; More More More!!!"

I like how you release this video after I had a project in my computer security class on performing buffer overflow attacks

Great demonstration! In fact, there is yet another vuln in this code introduced purely by using the system() function at all. You can read why system() is discouraged in programs that run as any privileged user on the manpage for that Linux C function under the Notes section.

Plese make more videos like this! As someone who didn't understand this kinda stuff well I was able to (kind of) understand how a buffer overflow works! I plan to to take cybersecurity as like a hobby in the future so your videos are really nice

Thanks for practical demonstration! Thank you!

Absolutely love this channel :) keep up the good work!

This is my favourite channel about programming. Thanks a lot mate!

Not into C at all but very educational and well explained. Thank you

this is a GOLDEN content. Please keep it up. I love your channel it's unique.

OK, this was, obviously, way oversimplified, with much more info available to us than would be to a typical attacker, but still it illustrates the principle of buffer overrun exploit, the most common of them all, very nicely.

though i knew most of what was said in the video, it was still really well made and i enjoyed it regardless, good job :D

This was really interesting! Loved it, keep em coming!

Where have you been all my life? I needed this content ❤

Exploit dev is so cool! Keep doing these!

Great info! *SUBSCRIBED*

I think this is a perfect start

Glad that your channel got a sponsor! Thanks for the content

I would recommend cyclic the command to find the location of where to put in the instruction pointer

"2" instead of "too" in the password would have been even cooler

Found this channel by pure chance and I'm glad I did!

Well, this video just made me turn all notifications from this channel to on. Great vid

amazing content man! thank you

Very nice video; though how would you find the debug() address on windows?

amazing man !!! thank you very much !!

LOVE this video!!!!! Awesome!!!

Brilliantly, my friend(:

Wow that's pretty cool.

Please keep uploading!

Great video but what I don't get is how the buffer overflows. Why does it keep loading your input into the memory if there is not enough space for it in the buffer you've declared? Is it strictly because of how the gets() function works?

dude this was fantastic! Thanks!

so great explanation and great demonstration keep it up bro if you can share more in medium community it would be great

You are doing Very great job 👍

Really nice👍👍

This is so freaking cool. Edit: i click on 1 video and watch all 3 related to it. Man this is so awesome.

Hey I had a question, at 5:48 you said that we had to reverse the order of the hex sequence since intel was 'little endian' , so why wasn't the hex sequence reversed in the compiled binary at 3:28

Hi I really enjoy your vids. Thank you for uploading them.

Hey! I am loving the recent content but have to ask a question, arent operating systems increasingly protective over buffer overflows? Like modern windows versions make it near impossible from what I have heard.

Thought you were John Hammond for a little bit and I was like "wow, he looks so different cleanshaven!"

THANKS@!

Wow. Does C# have same weaknesses? (Perfect video, 8 min long, easy to follow and understand, well explained, not too long)

what function instead of read() should we use to avoid buffer overflow from this situation. On windows, we have scanf_s, do we just use scanf with %[num]s or there exist some other "safer" function on unix?

Isnt the address of debug() function going to change when it is loaded into memory? I remember something like relocateable executable, but not sure.

is it bad that i dont space my brackets? I have them attached to their control struct or function.

thanks man, more please

can u please tell me the distro ure using in this video

I am note even remotely a coder, but I did write a horribly if then nested piece of code in LUA in Minecraft with the ComputerCraft mod and have been wanting to make a mostly secure password Programm from scratch for me there, too. I wonder if I can break that like this too ...

Assuming your program was some remote server, how would you get the address from it? Is that just based on hoping the program is the public build artifact?

Modern (post 90s) c compilers have compiler flags that protect function return addresses (shadow stack). In fact trying this on gcc version 13.2.1 gives with NO compiler flags gives: *** stack smashing detected ***: terminated rather than a segfault (perhaps my cpu just has better CFI?).

What protections did you disable for this demo?

I just discovered a whole new interest watching this video

Can you make one of these videos with the arduino environment: methods such as Serial.read() etc ??

c: a language python: a snake language for hackers

How do we know (as hypothetical hackers) that we want to look for the debug() function?

Is it possible to use the buffer overflow on an MCU considering that MCU is running its program from the flash and the buffer, obviously, is in RAM?

Why there is the full name of fonction in thé executable, that take place for nothing right?

In better processors (ARM, Aurix) the return-address (of the instruction pointer) is stored in a register i.e. separated from the stack.

I have a question: In c++, is the string standard library safe or is it vulnerable to similar attacks to what’s seen here?

Why would hacker have the execution file? And does this trick works on interpreted languages?

1. Finds address of debug function 2. Accesses debug function with the overflowing byte string where the overflow is the debug functions address. (Piping from exploit.py to hacked.c) - happens at gets(password). 3. Use file descriptor command to gain access to the system function which gives access to the shell. (Where the password is) 4. Cat password Where in the gets function is the debug function executed? In a catch block while printing?

Why wouldn't your code be compiled as a PIE with ASLR and SSP? Buffer overflows while still a major problem deferring address resolution until runtime with a cannery to pick up accidental overruns would lessen the number of people that could feasible attack the process.

Cybersecurity noob here; I have a question. You only knew the address of debug() because you had access to the compiled executable. How would someone hack in over the net not knowing the address of the function?

At 2:00 I appreciate the craft of running just the right amount of comands to reach pid 4567

I appreciate this video, however can you do an example that might be more subtle? Just something that doesn't involve gets or another already known red-flag function.

Right when you pressed enter at 2:21 KZfaq crashed because it was updating lmao

If your vulnerable program had the +s as premision, it could be used to privilage escalation, pleas make this remark in your next video, since it is important.

you forgot bonus points if you use alphanumeric shellcode.

rly cool

Hack The Box speedrun incoming?

Why would the executable file contain any information about the names of the functions?

Security on computers is just like security anywhere else, its all about how much security you need. For a lot of software, this exploit (except for the fact that it casuses a crash when the user inputs a password that is to long) is not something you need to worry about. For the same reason a pad lock is fine to use on your bike. Its hard enough to discourage people from even bothering because the benefit of breaking in is not worth the hassle of figuring out how. In my experience, buffer overflow attacks are (for any meaningful gains) usually way to hard to be a worth while endevaor (asides from possibly causing software to crash and using that to cause a service to be down).

great tutorial, but what if you don't have access to the source code?

For a school exercice i am trying to catch a flag by reading a non public file inside a db. The requesthandler is profided and the password use a bf of size 72. whenever i try a bucrash i get this error ERROR InvalidStackCanary ERROR SubProcessCrashed

I love you man

In no way did he start of the video by breaking bad.

Hmmm,,, Reminds me of the book by jon erickson. Hacking Art of Exploitation.

I like your funny words magic man

The title implies the solution is to just make the buffer longer. It should be called "what happens when you don't use fgets()"

If buffer overflows are such an obvious exploit, why do we permit core dumps?

Please tell me how i can be able to leaen a new language without forgetting C

this guy is p cool. low level gang 4 lyfe

Interesting for debugging your local code, but a "how to fix this hole" closing would be better for teaching.

I think we should just leave memory unsafe languages in the past. Having possible buffer overruns, bad pointers, etc. is just to dangerous in today's world. And they easily avoidable by using a memory safe language.

i never seen some one use tail linux for coding or exploit finding or hacking

But why buffer overflow causes instruction pointer to be overwritten?

using c or c++ is basically begging for getting hacked

When i try this in my WSL2 ubuntu installation, I successfully build the program using the build.sh file and cause the segfault with a big input, but it doesn't say "core dumped" and the dmesg command doesn't say anything about a segfault. Is there some other stuff I need to do?

gets() is a dangerous deprecated C function...

smart

A manager 😂😂😂

Just make the string store infinite of characters. Easy Solution!

Hi i would like to know something from you will you tell me ?

If you have access to the compiled binary cant you just edit it and write a call to the debug function at the start of the program? I cant see why you would need to write a python exploit and overflow the buffer.

Hacking ideas.

Would be good if you could add timestamps outlining the steps