First Exploit! Buffer Overflow with Shellcode - bin 0x0E
Вставка
- Опубліковано 2 лют 2016
- We write our first real exploit to get root access. Solving stack5 from exploit-exercises.com with a simple Buffer Overflow and shellcode.
Run into some problems (illegal instruction): / found_what_i_think_is_...
Stack Level 5: exploit.education/protostar/s...
=[ 🔴 Stuff I use ]=
→ Microphone:* geni.us/ntg3b
→ Graphics tablet:* geni.us/wacom-intuos
→ Camera#1 for streaming:* geni.us/sony-camera
→ Lens for streaming:* geni.us/sony-lense
→ Connect Camera#1 to PC:* geni.us/cam-link
→ Keyboard:* geni.us/mech-keyboard
→ Old Microphone:* geni.us/mic-at2020usb
US Store Front:* www.amazon.com/shop/liveoverflow
=[ ❤️ Support ]=
→ per Video: / liveoverflow
→ per Month: / @liveoverflow
=[ 🐕 Social ]=
→ Twitter: / liveoverflow
→ Website: liveoverflow.com/
→ Subreddit: / liveoverflow
→ Facebook: / liveoverflow
=[ 📄 P.S. ]=
All links with "*" are affiliate links.
LiveOverflow / Security Flag GmbH is part of the Amazon Affiliate Partner Programm.
#BufferOverflow #BinaryExploitation #Shellcode
This guy is one of those guys I listen to in normal speed
lol thats so true
eh 1.4 / 1.5 but yup pretty dense.
Lol definitely. He also has some accelerations from time to time. Thats when I double back for a replay.
seriusan lu bang?
Tutorialları 2x hızda izlemeyen gaydir.
My left ear is jealous
lmao
good sense of humour lol
damn, made my day
are you talking about the music at the start
LOL xD
Instructions unclear, ran out of wizard hats!
lol
Illegal instruction
0:56 so do i put on two wizard's hats?
but you only allocated space for one, wizard hat overflow!
lol
REPETITION LEGITIMIZES
Daniel Chin Adam Neely ?
@@benjaminnadarevic5714 made my day :))
This was a great intro to buffer overflows. It was a bit little challenging to get working on modern 64bit Linux system, but finally figured it out. It would be really cool to see an updated video on this. Keep up the good work man!
Hahaha you just broke my brain with the NOP Slide vine and the comment: "Riiight, a NOP-Slide." It's like you injected an INT3 into my brain's stack. I can't process stuff anymore. Perfect comedic timing, Hahaha
Wow, I’ve been following your channel for quite a while and just stumbled upon this vid now. Have to say this is a great companion for my current course in x86 asm since the content ties everything I learned so far together and from a very practical POV too. Thanks for the great content as always!
These videos have helped me so much! The visuals really helped me visualize the stack better and understand where and why esp, ebp, and eip were located on the stack
This episode was pretty hard for me. I always firstly watch episode and make notes, and after that I try it for myself. I had big difficulties executing shellcode outside gdb, after like 1h putting it on different positions, I had finally got it work by making more nops and picking deeper address. What a nice feeling when it finally put me in root privileges.
I like your pronunciation is very clear to understand and how you explain is awesome.
That last 30 seconds is very tricky/clever. Thanks for including it. I would have been stuck for a long time... :)
Holy crap, took me 2 tries (messed up my nop slide) but the feeling when I typed "whoami" > root was SO worth it!
Thanks man, thanks a lot.
After watching this i have been discouraged to want to learn about computers. This intimidated the shit out of me, the level of understanding and knowledge you guys have is incredible!
You can simple take some time to understand better the things in the video and if you are new to computers stuff watch the entire Playlist of it
Seriously these are some of the best instruction vids!
Just a little reminder, at 8:18 he's adding 30 as a decimal value to the address. I was wondering why I still got an 'illegal instruction' message, until I checked in dbg only to see that it added 30 as a decimal value and not as hex. This resulted in my offset being to small and not hitting in the NOPs. Using 'eip = struct.pack("I", + 0x30)' resolved this issue and I got the 'Trace/breakpoint trap'. When you get your head around this stuff it's really fascinating. Thanks for the great videos!
Thanks, it worked for me also
i cant understand sir, " This resulted in my offset being to small and not hitting in the NOPs" what the meaning of this? can u explain to me pls
@@yehezkielsimbuang2349 Hey, so at 7:27 he shows how environment variables like PWD can influence where your return-address is located on the stack. On the right he executes the binary from a shorter directory-path (/tmp) and not the original one (/opt/protostar/bin), which results in the return-address being pushed down less towards lower addresses on the stack. Therefore the return-address and the payload that follows it, is located at a higher address on the stack.
To compensate for that you have to add an offset to the original address to get higher on the stack and reach your payload. Because you often don't know how much higher on the stack your new return-address and your following payload is located, you add NOPs between the return-address and the payload.
In my example I didn't set the offset high enough so I pointed somewhere on the stack before the NOPs begin. By using a hex offset of 0x30 (so 48 in decimal) I landed right in my NOPs which then lead to executing the payload after them.
For me it helped to draw this stuff on paper to really understand it. Hope it helps ;)
@@MyTokyodrift ah thank you sir, i understand now how it works
Thanks for your tutorial sir, I was able to do my first buffer overflow with shellcode execution. It feels so satisfying
I was shocked that my left speakers stopped working after hearing your intro. Damn they are my new ones :O
@10:55 you absolute legend, that's same thing has been stumping me for weeks. I tried similar commands but didn't think of putting in brackets. Thanks!
I got a broken pipe error when I applied that. Any suggestions?
I think I just fried my brain, this was so intense for me, but I got it working in the end, so worth!
this took me a long time. had to add some extra nops. but finally it worked. Awesome!! superb video. thanks a lot
As you mentioned, the stack can be unreliable, and even though you use "unset env" in gdb, you can have some trouble.
You can use set exec-wrapper in gdb to ensure that the program run with env -i.
(gdb) set exec-wrapper /usr/bin/env -i
Thanks a lot for all your work, I'm learning a lot.
Your tutorials are just awesome!
Keep do that and thanks for investing all the time to make these vids.
Woooooooooo !!!!!
That was almost the hardest tutorial-vids in my life !
But also one of the most tastiest tutorials. After spending one and a half day of trying different offsets (my adresses differs from that in your vid) count of nops and stuff like that i got the damn root shell !!! Understanding memory, assembly.... Long words short story:
You've filled my brain with that damn new knowledge, that i have to say, your vids are the best hackingtuts in youtube.
You made me understanding what the magic is, what behind the scenes lies.
And as if changed in that root-shell the sudoers file ;)
I've felt like god on cocain :D
Thanks my friend, for sharing this (real) knowledge with us !!
Btw guyz...
When it's not working, try different offsets, amount of nops, also there is other shellcode on that page. I had a different memory-address + 28 and to use different amount of nops.
(Maybe its worth to write some looping code that finds the right numbers ??? ) ;)
Aber, ums auf deutsch auszudrücken:
Echt, danke man !!
Das ist die fetteste Tutorialreihe, die ich seit den letzten 10 Jahren gesehen habe.
Liebe grüße,
Vince
Implemented the exploit on the buffer and got stuck for longer than I'd like to admit. One thing I learned the hard way: Make sure that your exploit instructions don't start overwriting themselves through stack "push" instructions..... shortening the noop-slide and adding more padding after the exploit instructions fixed things.
I now understand why @LiveOverflow chose to traverse the stack in the "opposite" direction. That made things considerably easier. Long noop-slide, no worries about shell-code-self-destruction and generally less space-restriction for the exploit.
Absolutely great content!
I actually want to cover this during the haxember videos :D sorry I didn’t do this earlier
@@LiveOverflow Oh that's great timing then, haha! I'd love to see it: it definitely challenged my (mediocre) understanding of what was going on. Finally fixing it made my Friday evening. Thank you! :)
How did you figure it out in the end? It’s a real WTFFFF issue
@@LiveOverflow Spoiler: I didn't figure it out fully. I got the exploit to spawn the shell from within gdb, but as in your video it closed immediately. Executing it with your cat-stdin-trick just gave me "illegal instruction"s. After some digging I found weird ssh variables defined on the stack (env-scope), including IP addresses and whatnot (in retrospect I'm wondering whether it was smart of myself to launch the VM on a desktop and ssh in with my laptop). I then just lied to myself and told myself that I had figured out how the shell-code "self-destructed" and the stack positioning was just an annoyance for another time. Then I implemented your solution :) So the truth is that I have absolutely no idea why it crashed with cat-stdin.
As for how I figured out the "self-desctruction": I looked at the instructions of the exploit and compared them to what gdb was showing as it stepped through the exploit (just after the noop-slide). I then noticed that at some stage instructions were different from the source instructions (just before crashing); even though I had checked the memory right after the jump ("ret"). After some contemplating I figured that these supposed instructions actually corresponded with "/bin/bash" and some other strings that had been pushed onto the stack. Since I only had 10 bytes of padding after my exploit, the last few instructions got overwritten by the stack racing up towards the exploit. So the shell-code eventually dug its own grave. I then shortened the noop-slide and extended the padding after the exploit and it worked!!
@@LiveOverflow Alright, I finally got a fair bit further. But I'm ever so confused. If before I was at a "height of understanding", I'm back to the valley. Oh well! To begin with, here is a terminal capture of the "stack suicide": asciinema.org/a/286368
Shortening the noop slide and adding padding to the end of the buffer allowed me to execute the shell from within gdb. However, I couldn't attach to it. And executing "cat /tmp/f; cat) | /opt/protostar/bin/stack5" only gave me "segmentation fault" and "illegal instruction"s. That's where I had been before. So far so good.
I then tried executing commands with "env -", which executes a process without environment variables. It turned out, that gdb still defines some env variables ("LINES", "COLUMNS"), which you can unset with "unset env VAR-NAME". I also executed commands from the same working directory using absolute paths. I thought that now I had the same buffer base address from within and outside of gdb. But I was clearly wrong, as things kept working in gdb, but not outside of it. I was contemplating for some time how to find out the "live" buffer base address without gdb (I could only think of source code modification..), and then decided to brute force the problem. So I wrote a script that simply "tries" 255 addresses to the top and bottom of the buffer base address that I got from gdb. And voila: Jumping to 0xbffffdbb spawned the shell, source code lying on the buffer!!!
Why is the base address different? I don't know. I'm also unsure how to investigate further. I'll sleep some nights over this. Frustratingly, the same exploit (using address 0xbffffdbb) did not work from within the terminal directly. Only from within the python script! Why? Again I have no clue.
If there's gonna be a haxember video about this (no pressure), I'll finally sleep well again :D
This is one of the few channels that actually makes sense and has quality security content. Good job sir!
very interesting, thanks! keep it up dude!
1st time I watch this I was like wtf is going on... 2nd time... okay now it makes more sense..... great logic and explaination
Very informative and inspiring video.
My brain overflow!
Sounds like you might need to check the edit on this!
Great content as always.
Fucckkkkk!!! I've been scratching my head over for this for days !
Great video! Thank you. How can I determine how long my nop slide should be?
I had a different memory address and had to add 64 to my stack for me to get Trace/breakpoint trap to work
I've done everything, watched the video, got it working, yet still not exactly sure what I did, I'm 90% sure of everything though so I'm just gonna drill this into my head until I get it before moving on. love the tutorials so far.
As someone whose just started. do you need to understand the dynamics behind all of this, and why things are happening exactly as they are ?
this is gonna be asked on my infofrmation security exam the day after tomorrow, wish me luck
Just an update, I was flying through these challenges and was perplexed about something. I never had to nop anything and my shellcode was executed no problem, never got an illegal instruction upon piping, the only time I got an "illegal instruction" was piping my script without the appended shellcode!
INFORMATION OVERFLOW
too much info and stuff happening. i will watch again few days later after doing some googling
Miscritz Brotherzz thought I was the only one. He was going so fast and the steps made no sense whatsoever. He should make a disclaimer that this is NOT for beginners
Did you know this is part of a series? This is the chapter number 0E, or in decimal, 14! Here's the full playlist: ua-cam.com/play/PLhixgUqwRTjxglIswKp9mpkfPNfHkzyeN.html
I was following the playlist but still was very confused
@@silverzero9524 did you understood it ?
If yes please explain!
It's awesome !!!!!!!!!!! Thank you so much
Haha, not only are your videos very educational, but they are also amusing at times. :D
omg now I understand why I do not understand it. He said to put on wizard's hats and he repeated it and I did not put it and I'm sure it is the reason =D Thanks for the tutorial. Danke noch mal =)
`(python /tmp/exploit.py ; cat) | /opt/protostar/bin/stack5` works, but `(python /tmp/x5.py ; cat) | ./stack5` gives me an Illegal Instruction message. Can someone explain why?
+Zane Helton probably because you are in a different folder. The current working directory and path etc is stored on the stack, so it pushes around the stack and the addresses for the exploit only match nicely for the one directory
AWESOME vids! They've taught me more in 10 mins than hours of reading.
I can open a shell if I run it on GDB, without escalated privileges and if I run it without gdb I get an Illegal instruction (core dumped) error. Any ideas?
im doing reverse engineering on the reverse engineering that ur teaching me lol, terms apply looking every 5 second of info from google to understand the whole video but i love it
to generate the alphabet one can use this one-liner: "".join([4*chr(a) for a in range(97, 120)]). Also metasploit framework has a utility for index finding
east or west
YOU ARE THE BEST....
But the question is : how can you execute malicious code remotly into victim machine if the exploit (buffer overflow) is only related to the app.
That is awesome!
First of all i love your videos, please never stop uploading ;)
Right now i have the problem that my program which i am trying to exploit is using strcpy to copy a string from a comand line argument to a buffer. I am able to inject the 0xCC byte and it will be successfully executed. But i am not able to access the /bin/sh. The trick with cat is not working since the program does not read from stdin. After all i am trying to read a File on the remote Server,should i try to write my own shellcode or is there a trick i could use?
if it apperas nuts at first few times - really just return to it few days later. I understood so much better after one week not thinking about it
you are a wizard, many thanks! I HAVE A QUESTION: when using nopeslide, how does the payload is executed? here you are jumping to a nop operation, lets say, you jump to address x but you payload is in address y. How do we get to y if you jump to x?
3:37 op code "\xCC" (INT3)
8:09 NOP sled
9:03 shellcode database
10:27 shell without input
can you please explain why we have to point EIP to ESP?
Thank you !!!
I leave this comment to prove that during my life, i've watched this video "First Exploit! Buffer Overflow with Shellcode - bin 0x0E" and i've done this level
Hi! Thank you very much for these great videos.
Just a short comment for people that use a x86_64 platform. You will get a Segmentation Fault when executing program instructions in the Stack unless you make the stack executable by using compilation flag -z execstack
+Christophe Crémy thanks! And same applies to x86 :) this VM is just specifically set up to teach this stuff
I compiled with flag gcc -fno-stack-protector -z execstack and I can't excute because Segmentation fault (core dumped). Help me ! Tks
Do I need to add an arbitrary number of nops (100 are showed) or there is a precise computation that I can do in order to assolve this task? Thank you
Nice tutorial. One thing to note though: When adding values to the esp-address to land in the nop sled: you should make them a multiple of 4 to keep the address aligned. (maybe 32 instead of 30)
Otherwise you could run into "Illegal Instruction" when hitting the shellcode, as the first half of the instruction would be the \x90 from the nop.
+Alexander Druffel are you sure? I don't think that that will happen. x86 assembler uses multi length byte code and cannot be misaligned. Only if you jump in the middle of a multi byte opcode. But NOP is a single byte, so hat won't happen. Or do you have a PoC?
My PoC is my exploit working with +32 and crashing with "Illegal Instruction" on +30.. So take that for what it's worth.
when i run ([...]+30) in gdb, i get SIGILL in 0xbffff7de.
Memory there is 0x9090bfff.
Here my python script.
import struct
q=lambda x:struct.pack("I",x)
shellcode = "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x89\xc1\x89\xc2\xb0\x0b\xcd\x80\x31\xc0\x40\xcd\x80"
nopslide = "\x90"*100
padding = "A"*76
stack = q(0xbffff7c0+32)
print padding + stack + nopslide + shellcode
0x9090bfff means it's actually
"\xff\xbf\x90\x90". So the instruction you try to execute is really \xff and not \x90 NOP. If that is the case, you don't quite hit your nopsled and you have to go two bytes further.
But, the exploit you shared works like a charm for me ;)
user@protostar:/opt/protostar/bin$ (python /tmp/exp1.py; cat) | ./stack5
id
uid=1001(user) gid=1001(user) euid=0(root) groups=0(root),1001(user)
Well you are right. It still works with +33. My bad for not trying it out first. :)
With x/50x $esp-16 i can see that i actually missed my sled. Thanks for the response.
thanks.. this conversations helped me out !
Hi,
*After successfully executing shellcode*
I just wanted to know why my shellcode process always exits after a single command like "ls"...
Master thank you....
Awesome!
03:10 Unless the stack is non-executable :q
So maybe a jump into some library code? I think we could modify the stack so that it contained a series of return addresses and then just allow the CPU to return through all of them to execute some code.
what would happen if you changed the environment variable user to root by changing the stack (by going to an address with your code, and have that code change the memory at that address?) would that work/do anything?
Warning: If you're watching in chronological uploads order, watch the next video first, then come back here. The two are unfortunately swapped. Watch the previous episode first: Buffer Overflows can Redirect Program Execution - bin 0x0D
D comes before E except on UA-cam. (Both videos were Published on Feb 3, 2016, presumably at the same time which caused the swap.)
After much searching i finally get the basic idea. So how would this work on "real" programs with the modern protections. I find the more i look into it the more complex it gets:D
Did you explain the nop-Slide in previous videos or did I miss something? I mean, I'll look it up anyway but I wondered.
And why exactly did we get root access to dash? Is it something about the execve command?
Also, great videos!
Because every binary in the protostar-levels is using the setuid. (Executing as root user)
So we bascially tricked the programm to start a new shell as root and giving us the input to it.
I'm getting a very weird problem. So I decided to have the shellcode in the buffer, rather than in its overflow. When I try the exploit in gdb it works(it says executing program bin/dash and program exitted normally), but when I run it without gdb it gives me Segmentation fault, which I can't wrap my head around. Note that also I'm doing this in the same working directory. I thought that it might be the problem that you mentioned with the envirorment variable of the pwd but I do have a nop slide and a return address that points somewhere around in the middle of it.
I replicated everything you did exactly and I still get segmentation fault
Now I magically got it work by tweaking it a bit. Still have no idea why it works now and not then
could you tell me how you got it to work, im running into the same error and its kinda frustrating :(
If you're executing stack5 from /opt/protostar/bin/stack5 then it behaves weirdly. Try executing it with the working directory in /tmp/ by typing "/opt/protostar/bin/stack5". Then it should behave the same with and without the debugger.
Nothing if it helps i found out that gdb uses the absolute path so "/opt/protostar/bin/stack5". Then everything makes a lot of sense becasuse from /tmp you are using the absolute path to stack5 but when your are in /opt/protostar/bin then you arent using the full path which changes the stack placement.
this whole thing can only happen if the stack is executable right?(basically NX disabled)
yeah, pretty much
Just a bit before 3:22 when you pipe the alphabet into the debugger, how do you do this? When I try it, no matter what I do it doesn't recognise it as input. It treats it as if I haven't inputted any arguments at all. My python script is exactly the same as the one in the video
I wonder when i ran the exploit in the terminal on stack5 file i see Trace/breakpoint trap, and when i do the gdb i see "illegal instruction" is there a reason for this?
my dumb ass.. I had to rewatch, and got it the second time around. I hand-typed the shellcode incorrectly the first time. So the second time around after rebooting, clearing env vars, etc, I got it by typing the shellcode from the webpage he was viewing, rather than waiting for him to copy/paste into his own term. Turns out I missed the \xb0\x0b. Cool to get that priviledge escalation. Nice video.
I'm running this on ubuntu 16.04 on VM, and I can't run shell as root even though i set setuid, setgid, and set ownership of the program to root. Why is it not working?
If you're running this on your own, also make sure you compile with the "-fno-stack-protector" flag and "-z execstack" flags
also with -no-pie flag
Just finished ARM/ARM64 version of the challenge :D
Btw to set the real user ID to root (uid=0) you can use shellcode with a setreuid call like /shellcode/files/shellcode-250.php at shell-storm. I came across binaries/files before that checked real uid instead of the effective uid
(python stack5.py ; cat) | /opt/protostar/bin/stack5
This does not give me any output and the shell simply exits. My exploit is working fine as '\xcc' gets executed when added before the shell.
Can anyone explain why 'cat' is not working as supposed to??
The (
After all nops at 8:34 we see from address 0xbffff824 to 0xbffff827 the content of "0xb7ff6200". Why do we not see our payload "0xcccccccc" at that location? According to the python script, 0xcccccccc should come right after the 100 nops. Why is this not visible at 8:34, when you examine the stack?
Also, thank you for this great series!
hi bro,why segmentation fault appear when i run stack5 but it is not in gdb?
yo guys I'm really stuck here and I dont know why I calculated the offset found 140 I created a payload containing 115 NOP sled + 25 byte of shell code + an address in the middle of nop sleds but i keep getting segmentation fault although i checkd again the offset and it's 100 % 140 bytes.And when I change the return address each time adding 8 bytes I arrive to a certain point where putty crushes as if I touched its configuration (wtf ?) Guys pleaaase heelp ..
instructions unclear, wearing two wizard hats 00:54
I am getting segementation fault instead of sigtrap when executed from terminal.
you should be getting illegal instruction, thats because "gdb is using int3 internally"
so pass "handle SIGTRAP nostop noprint pass"
you will get sigtrap...
btw: GREAT CONTENT, @LiveOverFlow
I hope someone can help me here. When executing the exploit in gdb everything works fine, but if i try to execute it outside of gdb i do get a Segmentation fault error?
srs any help here?
same here
Hi,the exploit don't work out the gdb,what can i do? :P
Why do I need buffer Oveflow to inject shellcodes? Can't I run shellcodes by itself?
LUL i am doing this challenges. Running exploit code via ssh always gives me error, but running exploit code from tty (i am using virtualbox) gives me root tty. I tried many exploit formats and it all works with tty.
7:54
Is it expected if in x86_64 the memory address of RIP didn't change? It seems the environment variable on phoenix version didn't affect the RIP location on the stack, so I thought I didn't need the NOP slide
but it still throws an illegal instruction if I do not add the NOP slide. I run gdb within the payload without nop slide, and it hits the breakpoint, but after continuing, it throws an illegal instruction, the same as running it without gdb.
BUT, if I run gdb within the payload and nop slide, it hits the breakpoint, and after continuing, it still throws illegal instructions. The weird thing is, if I run it without gdb and within the nop slide, it will stop on the breakpoint / SIGTRAP and not hit the illegal instruction (???)
I am confused why that happens. I would appreciate it if someone could enlighten me
04:48 What if the code is in a read-only memory? The debugger cannot just swap instructons with `int3` then, right? :q So how can it still debug such read-only code?
Anyone tried this on their base machine ? not while on ssh protostar ? because it dosent work on Linux 5.5.0-1parrot1-amd64 kernel ! or it doesn't related to kernel and I am doing something wrong ??
I don't think I understand this tutorial, I have my robe on and wizard hat, when do I cast Lvl. 3 Eroticism?
drset oh my god...
educational and hilarious
can someone please explain me why was the bash executed as root?
edit : okay so the setuid bit was set?
Why is at 8:36 no 0xcccccccc at the end of the NOP slide (at 0xbffff824)? There is 0xb7ff6200 instead.
The INT instruction gets somehow executed though. How? What did I miss?
Yeah, I was wondering the same... Any answers to this?
hi, maybe a noob question, but we used the return address of main on stack, right? Can we use the return address of "gets" on stack to enter shell code?
The memory allocated for the buffer is in the stack frame of main, so adding values to the buffer makes it grow from lower addresses to higher ones. This means that the buffer can overflow only into higher addresses, where the ebp of the stack frame that main was called from and the address where the program should return to after main is executed are stored. This means that with the buffer you can overwrite the address for the program to return to after the execution of main. However the gets function gets a stack frame on top of main's stack frame(in lower addresses). The address to return to after the execution of gets is stored on top of( in a lower address) than the buffer, therefore you cannot overwrite it because the buffer grows downwards.
Are you going to continue with the videos?
+Everything Media I working on it. But too much other stuff going on right now and I am slow. sorry
9:07 another good tool, especially if you're using Linux, is MSFVenom... Sure you've heard of it, a lot of different exploits to chose from, can generate shellcode without certain chars, of a certain size etc
Does this technique work on any machine with the same architecture? I ask it because I tried to recreate it on my own computer (I changed the memory address to where eip points since it was not the same as in the virtual machine) and throws a Segmentation fault (core dumped)
Or is it that "normal" distributions are protected against these exploits?
Great UA-cam Channel
I am starting from scratch trying to learn about Buffer Overflow , like f.x. "find starting address of heap and stack"
In what row should I watch the videos ?
there is a binary exploitation playlist that has some order. However a lot of topics create circle references and it also make sense to watch further than you understand. And then maybe revisit earlier videos again.
@@LiveOverflow Thanks for the quick answer ;-)
dude this ( ; cat) thing... spend two days >_
Thx so much to this dude also
At 12:08 you say, that we escalated priviledges to root. You proove that and I was fascinated!
But I don't understand why we got now a root shell. The python program you entered was started with the user "user" so how exactly could you escalated the the priviledges? Does it have something to do with the fact, we wrote an assembler instruction on the stack and the CPU executed that? But when are then lines of code executed as user and when as root? And how do syscalls come in here and when are permissions checked if the program / user has the right to execute something?
This topic is still pretty new to me but very interesting! Thank you :)
He got a root shell because the stack5 program is a setuid binary..He explains it in the 0xOB part in this video series.
For those getting SEGMENTATION FAULT when trying to execute the shellcode (INT3 interrupt), here's the solution:
recompile your code with this option "-z execstack" to make the stack memory executable.
thx bro