First Exploit! Buffer Overflow with Shellcode - bin 0x0E
HTML-код
- Опубликовано: 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
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
Instructions unclear, ran out of wizard hats!
lol
Illegal instruction
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!
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.
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.
That last 30 seconds is very tricky/clever. Thanks for including it. I would have been stuck for a long time... :)
I like your pronunciation is very clear to understand and how you explain is awesome.
Seriously these are some of the best instruction vids!
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.
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
I was shocked that my left speakers stopped working after hearing your intro. Damn they are my new ones :O
Thanks for your tutorial sir, I was able to do my first buffer overflow with shellcode execution. It feels so satisfying
@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?
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
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 :))
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 took me a long time. had to add some extra nops. but finally it worked. Awesome!! superb video. thanks 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
I think I just fried my brain, this was so intense for me, but I got it working in the end, so worth!
Sounds like you might need to check the edit on this!
Great content as always.
Very informative and inspiring video.
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
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 ?
My brain overflow!
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?
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
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?
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!
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 =)
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
can you please explain why we have to point EIP to ESP?
It's awesome !!!!!!!!!!! Thank you so 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
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: ruclips.net/p/PLhixgUqwRTjxglIswKp9mpkfPNfHkzyeN
I was following the playlist but still was very confused
@@silverzero9524 did you understood it ?
If yes please explain!
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.
this is gonna be asked on my infofrmation security exam the day after tomorrow, wish me luck
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?
east or west
YOU ARE THE BEST....
Haha, not only are your videos very educational, but they are also amusing at times. :D
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?
`(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
hi bro,why segmentation fault appear when i run stack5 but it is not in gdb?
That is awesome!
Hi,
*After successfully executing shellcode*
I just wanted to know why my shellcode process always exits after a single command like "ls"...
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
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?
this whole thing can only happen if the stack is executable right?(basically NX disabled)
yeah, pretty much
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?
Thank you !!!
Hi,the exploit don't work out the gdb,what can i do? :P
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?
(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??
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
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.
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?
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.
can someone please explain me why was the bash executed as root?
edit : okay so the setuid bit was set?
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
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! 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
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?
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 ..
Master thank you....
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.
Why do I need buffer Oveflow to inject shellcodes? Can't I run shellcodes by itself?
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.
Why do you +30 to the eip @8:20?
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
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 ??
Awesome!
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
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.
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 RUclips. (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
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!
What on earth does the x/1i $eip do ?
eXamine (print) / one instruction from the address where $eip points to
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...
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.
Hey can you help me? When I try to put an adress into the instruction pointer, the adresses change all the time. In your video, the adresses remain the same. What am I doing wrong?
Are you doing it inside Protostar environment? Remember they disabled protections like ASLR, so if you're practicing somewhere else, chances are those protections will not be disabled.
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
At 5:39 you fill the buffer with "padding + eip + payload". Why does this work? I mean from what i understood you're jumping at the top of the stack and executing from there, but isn't the padding at the top of the stack? Shouldn't the program try to execute 0x41414141? Isn't the payload located after the overwritten return address? For me it makes sense to use the payload as the padding and then jump to it but that won't work. I get an error form gdb saying it can't find the bounds of the current function or something like that and it won't let me step through the program although eip seems to jump at the right address, the top of the stack.
> you're jumping at the top of the stack and executing from there
that is kinda true, but you should not forget, that the stack addresses can move around (which is explained in the video), so the address we choose might be on top of the stack now, but might not be when we execute it outside of gdb.
> isn't the padding at the top of the stack? Shouldn't the program try to execute 0x41414141
that padding is just called padding to fill up the buffer for the overflow, until we overwrite the return pointer, and I have decided to put the nopslide+shellcode AFTER the overwritten pointer. But you could also place it before. But if I had placed it before I would have to calculate the correct number of characters to hit the return pointer again. It's easier to keep the padding fixed and append stuff. Also the padding is at the top of the stack during the function, but before this function returns it moves again further down and then uses `ret` to return to the address on the stack (the return pointer). So at the moment where we gain control of the program, the stack will point exactly there, which will be the start of the nopslide.
> For me it makes sense to use the payload as the padding and then jump to it but that won't work.
Like I mentioned before, absolutely possible. Something else goes wrong for you. Maybe you didn't properly calculate the correct amount to pad the shellcode to the same length as the padding before?
> I get an error form gdb saying it can't find the bounds of the current function
that error is only relatd to `disassemble`. This command only works inside of a function, but your custom shellcode is not a function. You can use `x/10i $eip`, to display 10 instructions from current EIP.
Now i get it thank you. So the leave instruction is the reason this works. I was kind of hang up on the fact that you should fill the buffer with the nop slide because I have seen a video on the Computerphile channel where they did that and also the article you cited, "Smashing the stack for fun and profit", from the phrack website suggested to place the exploit in an env variable and jump to it if the buffer can't fit all the exploit. But I understood it now thanks a lot.
yeah all these things are valid. You have a buffer overflow. You have to put data in there... somehwere you have to place a nop-slide and shellcode. (env variable is also just placed on the stack). You can be creative and do whatever is easier :)
how con you run that terminal on windows?
I talk about it in a previous episode when I setup everything. checkout the Binary Hacking playlist
@LiverOverflow how is it the shell root? Why isn't it the user's shell?
Oh it's because the program is run as root!
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
educational and hilarious
When I do this, the memory mapped address of the stack is very different between inside GDB and out, and I'm at a bit of a loss as to how to reconcile this.
Inside GDB: 0xfffdd000-0xffffe000
Outside GDB: 0xffc67000-0xffc88000
I'm struggling on how to find some absolute jump address to overwrite the pointer on the stack that will reference the executable code I've placed onto the stack. Anyone have some idea?
Use nop slides, He talks about those in the video. In case you have watched it and didnt understand: nop slides are used for this exact same purpose! You spam a bunch of nops, and jump into an address where you are sure to find a nop instruction. And the rest is taken care of!
But how we get root privileges? Why not user?
instructions unclear, wearing two wizard hats 00:54
My esp changes every time. So i cannot just easily overwrite eip with that esp address. Is that because i was running stack5 from my host computer so other programs occupied the stack?
Yes that’s because you run it on your own computer. But your problem is ASLR - the stack address is randomized. And you will run into more issues because of DEP (non executable stack)
@@LiveOverflow Ok, but how do you connect to your protostar VM. I didn't find a sshd. Did you compile or dpkg one?
Found sshd with root. Sorry for stupid question.
The (
Can someone explain how the "cat" enables him to execute "ls", "whoami" etc near the end of the video? Thanks !
because if I did "cat" on *my own* shell, it just returns whatever I give as input, but if I typed commands like "ls" after typing 'cat', it just spits out "ls", instead of listing the directory contents, which is why i'm confused