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!
@@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 ;)
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!
@@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! :)
@@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 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.
@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!
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
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!
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.
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
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 :)
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
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'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.
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!
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.
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?
2 года назад
Yeah, I was wondering the same... Any answers to this?
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.)
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
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
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
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?
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
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
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!
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.
Hi. I've been programming for a while, but this is my first real attempt at doing exploits of any kind, so I apologize if I accidentally skip over any details by accident. As a challenge, I'm very doing a related program which I made specifically as an introductory program. The full source code of said program can be found here: pastebin.com/sYyGsrkZ. Additionally, the disassembly of the main function can be found here: pastebin.com/xMJEfDPT. I've successfully managed to get the program to jump to stack, similarly to how you mention at 3:08, and correctly land the instruction pointer to the opcode in my array. However, the program immediately throws a SEGFAULT upon execution of my array. My exploit string is simply 1024 ret instructions followed by the pointer to the beginning of the code as to overwrite the function pointer, and the program most certainly does land there correctly. I think I may have a nonexecutable stack, which may be interfering with the exploit. For reference, I'm using arch linux with linux kernel 4.16.6 on an x86_64 intel xeon x5670. Any help or tips of any kind would be appreciated. Thanks so much for your time.
if you compile it yourself on this modern linux, then yep, stack is not executable. I suggest you to practice these introduction challenges on older VMs such as the one shown in the videos. But overthewire is also great!
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 =)
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.
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 :)
for who got stuck like me (i got stuck 2 days even watching the video) the /bin/sh shell give seg.. fault change the shellcode same issue and then i created a reverse tcp shell from msfvenom same issue. for some reason the prob was that the shellcode does not have the setuid(0) for root so u should include it on your shellcode so in msfvenom u should include "PrependSetuid=True" and i run nc and the exploit bam got the reverse shell with root prv
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
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
+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
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.
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.
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?
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
Hello guys, and thanks to +LiveOverFlow for the amazing video. First of all, just wanted to say I am not a hacker, I am really new to this and I am just doing it for fun and educational purposes. I am getting stuck at 6:20, In the first terminal I got the Trace/Break Point, and if I go to the second terminal and I execute the file I got the "Illegal Instructions" message, however, when I try to run the file using gdb (In 2nd Terminal) I only get Trace/breakpoints traps and I have to step forward like 4 times in order to get the "Illegal Instructions" here. Due to this when Im comparing the stack address I have in Terminal 1 and Terminal 2, they are identical. Any ideas? Sincerely, NewbornHacker (Not even) hahahah!
+Bryce Andress I wanted to illustrate that we can jump anywhere. If you make the nop-slide long enough, you have a big range where you can jump to... so +0, +30 +100, all would work, because of the long nop slide. And I felt safer adding something to the previous eip with +30, rather than accidentally jumping short of the nop sled and not hitting it.
That what I was thinking but was not 100% sure. Thanks for the videos man they are the best! My CTF team was able to place to 100 in our first event the other week. Big part of that was 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?
@ 2:25 why did we overwrite it with T's? shouldnt it be R? i mean we have a buffer of 64chars. If we now print each character 4 times it would mean we can store 16 characters in the buffer ( 64 / 4 = 16 ) The 16th Character is the P. After the Buffer there comes the basepointer(overwritten with Q) now the next element on the stack is the return address which is used by "ret" instruction so we should have overwritten it with R Why are there two more elements on the stack that we have to overwrite to get there? What did i miss?
maybe there are just some empty elements on the stack between the base pointer and the last legal element of the buffer, i don't think he said that the stack is necessarily exactly 64 bytes
Probably because of the compiler padding, He mentioned it in other video that sometime compiler adds some padding so its not necessary we will get the eip after the buffer
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?
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.
If anyone is getting seg fault please be aware 1st of all that gets() doesnot work nowadays as it has been removed from the gcc. Instead if you want to accomplish a similar behaviour one may use strcpy(). However it will not work with the input redirection command which is "
LiveOverflow thnku sir since I am learning from your videos I might be wrong but I discovered this during complication on gcc which recommended fgets instead of gets. Please throw some light
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.
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
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
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?
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?
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?
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?
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)
Great RUclips 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.
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.
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 ..
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
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.
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
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
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 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.
@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?
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
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
Instructions unclear, ran out of wizard hats!
lol
Illegal instruction
3:37 op code "\xCC" (INT3)
8:09 NOP sled
9:03 shellcode database
10:27 shell without input
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.
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.
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!
That last 30 seconds is very tricky/clever. Thanks for including it. I would have been stuck for a long time... :)
I was shocked that my left speakers stopped working after hearing your intro. Damn they are my new ones :O
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
I like your pronunciation is very clear to understand and how you explain is awesome.
I think I just fried my brain, this was so intense for me, but I got it working in the end, so worth!
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.
1st time I watch this I was like wtf is going on... 2nd time... okay now it makes more sense..... great logic and explaination
Seriously these are some of the best instruction vids!
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!
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
this took me a long time. had to add some extra nops. but finally it worked. Awesome!! superb video. thanks a lot
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 ?
I had a different memory address and had to add 64 to my stack for me to get Trace/breakpoint trap to work
Thanks for your tutorial sir, I was able to do my first buffer overflow with shellcode execution. It feels so satisfying
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!
This is one of the few channels that actually makes sense and has quality security content. Good job sir!
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.
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?
Your tutorials are just awesome!
Keep do that and thanks for investing all the time to make these vids.
Fucckkkkk!!! I've been scratching my head over for this for days !
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.)
My brain overflow!
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
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
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
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?
Why do you +30 to the eip @8:20?
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
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
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!
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 !
this is gonna be asked on my infofrmation security exam the day after tomorrow, wish me luck
Hi. I've been programming for a while, but this is my first real attempt at doing exploits of any kind, so I apologize if I accidentally skip over any details by accident.
As a challenge, I'm very doing a related program which I made specifically as an introductory program. The full source code of said program can be found here: pastebin.com/sYyGsrkZ. Additionally, the disassembly of the main function can be found here: pastebin.com/xMJEfDPT.
I've successfully managed to get the program to jump to stack, similarly to how you mention at 3:08, and correctly land the instruction pointer to the opcode in my array. However, the program immediately throws a SEGFAULT upon execution of my array. My exploit string is simply 1024 ret instructions followed by the pointer to the beginning of the code as to overwrite the function pointer, and the program most certainly does land there correctly. I think I may have a nonexecutable stack, which may be interfering with the exploit. For reference, I'm using arch linux with linux kernel 4.16.6 on an x86_64 intel xeon x5670.
Any help or tips of any kind would be appreciated. Thanks so much for your time.
if you compile it yourself on this modern linux, then yep, stack is not executable. I suggest you to practice these introduction challenges on older VMs such as the one shown in the videos. But overthewire is also great!
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 =)
east or west
YOU ARE THE BEST....
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
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
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 :)
for who got stuck like me (i got stuck 2 days even watching the video) the /bin/sh shell give seg.. fault change the shellcode same issue and then i created a reverse tcp shell from msfvenom same issue. for some reason the prob was that the shellcode does not have the setuid(0) for root so u should include it on your shellcode so in msfvenom u should include "PrependSetuid=True" and i run nc and the exploit bam got the reverse shell with root prv
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
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
instructions unclear, wearing two wizard hats 00:54
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
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.
Great video! Thank you. How can I determine how long my nop slide should be?
`(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
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.
very interesting, thanks! keep it up dude!
this whole thing can only happen if the stack is executable right?(basically NX disabled)
yeah, pretty much
Sounds like you might need to check the edit on this!
Great content as always.
can you please explain why we have to point EIP to ESP?
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?
Very informative and inspiring video.
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
Hello guys, and thanks to +LiveOverFlow for the amazing video. First of all, just wanted to say I am not a hacker, I am really new to this and I am just doing it for fun and educational purposes. I am getting stuck at 6:20, In the first terminal I got the Trace/Break Point, and if I go to the second terminal and I execute the file I got the "Illegal Instructions" message, however, when I try to run the file using gdb (In 2nd Terminal) I only get Trace/breakpoints traps and I have to step forward like 4 times in order to get the "Illegal Instructions" here. Due to this when Im comparing the stack address I have in Terminal 1 and Terminal 2, they are identical. Any ideas?
Sincerely,
NewbornHacker (Not even) hahahah!
At about 8:15ish why do you append +30 to the $eip?
+Bryce Andress I wanted to illustrate that we can jump anywhere. If you make the nop-slide long enough, you have a big range where you can jump to... so +0, +30 +100, all would work, because of the long nop slide.
And I felt safer adding something to the previous eip with +30, rather than accidentally jumping short of the nop sled and not hitting it.
That what I was thinking but was not 100% sure. Thanks for the videos man they are the best! My CTF team was able to place to 100 in our first event the other week. Big part of that was you!
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...
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?
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
@ 2:25 why did we overwrite it with T's? shouldnt it be R?
i mean we have a buffer of 64chars. If we now print each character 4 times it would mean we can store 16 characters in the buffer ( 64 / 4 = 16 )
The 16th Character is the P.
After the Buffer there comes the basepointer(overwritten with Q)
now the next element on the stack is the return address which is used by "ret" instruction so we should have overwritten it with R
Why are there two more elements on the stack that we have to overwrite to get there? What did i miss?
maybe there are just some empty elements on the stack between the base pointer and the last legal element of the buffer, i don't think he said that the stack is necessarily exactly 64 bytes
Probably because of the compiler padding, He mentioned it in other video that sometime compiler adds some padding so its not necessary we will get the eip after the buffer
dude this ( ; cat) thing... spend two days >_
Thx so much to this dude also
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.
If anyone is getting seg fault please be aware 1st of all that gets() doesnot work nowadays as it has been removed from the gcc. Instead if you want to accomplish a similar behaviour one may use strcpy(). However it will not work with the input redirection command which is "
where did you hear that gets() is removed from libc? Also strcpy doesn't read input, so it has nothing to do with input redirections ;)
LiveOverflow thnku sir since I am learning from your videos I might be wrong but I discovered this during complication on gcc which recommended fgets instead of gets. Please throw some light
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.
4:36 I don't think I have a deburgrarr
i love him even more because of his accent ! he is great
floating point exception instead of illegal instruction at 6:21 anyone??
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
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
What on earth does the x/1i $eip do ?
eXamine (print) / one instruction from the address where $eip points to
Hi,
*After successfully executing shellcode*
I just wanted to know why my shellcode process always exits after a single command like "ls"...
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?
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
The stack has no execution privilege, how was it solved in this video?
The stack has execution priviledge on this older linux VM
@@LiveOverflow It is problem of VM or Linux on this VM? Hard or soft?
The more you watch this video the more your kernel panic you will feel in your system.
hi bro,why segmentation fault appear when i run stack5 but it is not in gdb?
Why do I need buffer Oveflow to inject shellcodes? Can't I run shellcodes by itself?
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?
Did you know an online course of the Tel Aviv University links to this video for extra information?
The (
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?
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?
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
Great RUclips 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 ;-)
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.
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 ..