in the 8:00 section do you know why the integer variable needed to be placed in the higher offset instead of just the current RSP offset ? I am a little bit confused 😔 and would appreciate it if someone enlightened me 😁
Just for the record: I did this on Ubuntu and used gcc to compile the code. When i tried to exploit the exec the error " *** stack-smashing detected *** ... terminated" showed up. The solution: When compiling use the "-fno-stack-protector" argument to aviod extra protection.
I dont even know how many times I have watched this. But every time I watch it, I manage to learn something new. How??? I watched the video 10 times to fully understand
I cannot thank you enough for the nice stack animation! At 06:14 , esp has value 0xbffff7d8 and is subtracted 0x60 , the video shows that esp now becomes 0xbffff770, but doing "hex(0xbffff7d8 - 0x60)" in python gives '0xbffff778'. Any hints would be helpful!
+Akhil Sharma You forgot the "and"-operation in the line before, where the last 4 bits of esp are set to 0, so that the value of esp before the subtraction is 0xbffff7d0 +LiveOverflow Thank you for your videos. They're really great!
I've had this exact problem and I found out that the `and esp, 0xfffffff0` operation does this. If I understood correctly BBIT-Solutions' comment, it just serves as a "clean up" so that the address ends with 0. LiveOverflow also mentioned it at 4:48. Please correct me if I'm wrong.
Fantastic content! But I would prefer if you draw the stack upside down, since it starts at a higher-numbered address, and ends at a lower-numbered address.
10:53 in this scenario you just simply need to echo those characters that over flow the address and pipe it to wc -c to count how many characters and multiplay it with A :)
The video is amazing and the explanations as well. Thank you :) I would prefer to see that the Stack in the visualisation grows downwards as we "start" at the highest memory address and then move the stack pointer to lower address. And I think there is something messy with the addresses of the base pointer, when I compare it to the maped address space you showed earlier in this video. The newer comments here seem to be confused as well so maybe a update on that video would be helpful for all of us who are new to that topic :) @5:37 the base pointer ebp = 0xbffff900. At 3:49 in the mapped address space, the start and end address of the stack are 0xbffeb000 and 0xc000000 respectively. I thought the base pointer points at the highest address of the stack - why isn't that here? And why is the stack pointer address at 05:41 0xbffff7dc, at 05:43 0xbffff7e4 and at 05:47 back to 0xbffff7dc? At 6:07 you say we overwrite ebp with the value of esp, but you did the reverse: you overwrote esp with the value of ebp. Or what did you mean with "value"? But tbh at 10:09 I was just mindblown. For the first time I really understood what a Stack Buffer overflow is. Thank you! And it would have been helpful to enumerate the memory addresses in you visualisation at 5:49 to have one row with the memory address and the other row with the content in there.
*_Just a tip for whoever is doing stack2 exercise:_* you can escape characters on the environment variable on without Python but using Bash by doing the following: WHATEVER=$'\x41\x42\x43\x44' result of echo $WHATEVER: ABCD PS: you can also use \u0041 and so on, but then you need to see the ways of escaping characters. \u is for UTF-16 (or UTF-8), for example. \U I believe is for UTF-32 (or UTF-16 or UTF-8). And there may(must?) be other ways. You can also escape in octal, for example.
8:30 If esp is a register, that contains an address then adding 0x1c to it will us directly the address at offset 0x1c. Why then do we need to use bracket notation if we want to store the address itself in eax and not the value that it points to?
I believe this is what you mean? You probably don't need it anymore, but others might, so I decided to still answer. This is the video, hopefully (in playlist mode): ruclips.net/video/HSlhY4Uy8SA/видео.html
I leave this comment to prove that during my life, i've watched this video "First Stack Buffer Overflow to modify Variable - bin 0x0C" and i've done this level
It's a little bit ambiguous. But by "new ebp is pointing to the old ebp" at 6:38, he meant that the memory ebp is pointing to now stores the value of ebp of the previous function. More specifically, at 6:38, value of ebp is 0xbffff7d8, which means it now points to memory address 0xbffff7d8, and at this address, the memory stores value 0xbffff900. And remember that "push ebp" at first line of the main function disassembly? It just pushed value of ebp into stack, value of ebp at that time was still the "old one", which was 0xbffff900. Hope I can help to explain well. Just remember that value of these pointer registers stand for memory address they are pointing to.
Thank you very much for your awesome videos !! if anyone doesn't mind, at 6:36 why is ebp still pointing to the old value of ebp even after overwriting it with esp ? doesn't it point to the memory address it has as value (in general) ? your help is much appreciated !
i don't know why but a lot of people get very confused right there including me, caller(function that callled current function) ebp got pushed on the stack so its on the stack and it is also the top of the stack because its the only thing in stackframe right now so esp is pointing to it, then new ebp is made to point to esp which points to the old ebp and then esp is decremented sub esp xxx for local variables
9:00 char buffer char[64]; I take it to mean 64 bytes, Why is there no 0x40 hex value on the shown disassembly output that corresponds to the number 64 in decimal?
I have a problem. My gcc has registered the 0x0 of the int modified variable at esp-0x54. What means that it's even more deeper on the stack than the buffer. So then, I cannot affect the variable.
@@LiveOverflow I found an easy solution for this by just grouping the data on a struct, and worked. But you're right, I'm going to start using it. By the way, if you are reading this, the exploit exercicies links are down
"4 characters here". AAAA -> 0x41414141. "Then 4 times 4 that's 16 for a row". so 16 bytes per full row. We have 3 rows that are filled full with 4. "And with the next fill row we can ...". So the fourth full row would write over the 0x00000000.
I'm curious about the stuff that is in the stack frame memory region before we write our As, Bs, and Cs into it. Presumably it is just junk from some previous program that happened to use that part of memory before or even random stuff from turning on our machine. Now, if we write the pattern of letters into memory and not properly clean it up, it should still be there somewhere, right? Is it at all possible to try to access data in memory that served as a stack frame of some prior program? Or does memory virtualization prevent that one can reliably find that region of (physical) memory ever again?
I replaced the gets function with scanf and hoped to observe the same thing as in the video because I've heard people say that scanf is also an insecure function, but it never overflowed, what do you think?
Thanks a lot for the presentation but I have few questions trying to understand it... Is the following representation of "leave" and "ret" instructions correct? leave is like: mov esp, ebp mov ebp, [esp] add esp, 0x8 ret is like: mov eip, [esp] // move value at current stack pointer to eip (that value was stored at top of the stack when "call" instruction was used) add esp, 0x8 Would it be possible to actually use the instructions above instead of "leave" and "ret"? And why both instructions increase esp register by 8 instead of 4 which would be expected knowing that registers are 4 bytes in size? Is it the way how 32-bit system can be ran on 64-bit processor? Meaning that if I ran the same program (recompiled?) using old 32-bit processor then "leave" and "ret" would actually increase esp by 4?
Great video, but at 6:12 you said mov esp,ebp and its mov ebp,esp ( since you are using the intel syntax that is not correct, as you already know) its just a note ;)
I know what is going on ... You are moving into ebp esp and you said that, but if you read using the intel syntax ( dest , source ) you should say mov esp "into" ebp ) ... Or am i wrong ?
I say: "Now we overwrite EBP with the value from ESP. move ebp, esp". I don't get it? First I say what the instruction does, and then I mention the instruction again.
Did you find a answer to this question? My guess would be the binary automatically allocates some extra space for protection against buffer overflows even when accounted for the other variables to be pushed to the stack.
To crack stack 1I ran it in gdb and found it was comparing 0x61626364 with $eax, I then ran the stack1 program with test values AAAA, AAAAAAAAA... to see at what point i would overflow into the register it was checking i eventually ran it with AAAAAA and saw the message saying "try again you got 0x414141... i then went back and ran the program with the values AAAA...dcba and it worked, is this an effective way of breaking the c program or should i have done it using a different method?
I come back to this video sometimes for the stack frame animation. It all made sense and I think I understood what is pushed/popped from the stack and in what order. Today I looked at stack example from this book (page 130, figure 6-5): www.electroons.com/8051/ebooks/expert%20C%20programming.pdf and the order seems "flipped". Did the author make mistake or in some circumstances the order is just different? I mean, order of stack frame contents in relation to order of stack frames themselves is different. It looks like in the book the return address is pushed onto the stack as the last thing (which seems weird considering it actually happens first).
I know this is a little late, but for anyone else who is wondering why this is the case, it's simply a matter of which computer architecture you're working with.
Does this exploit have to be compiled inside the given Linux VM to work ?. I tried to compiled the source code on my Mac and seems like the same technique doesn't work anymore
This is an oldschool example before stack canaries. But in episode 0x23 we compile this challenge on a more modern Ubuntu Linux, with stack cookies, and try to exploit it again ;)
When I tried it I observed that in my case the input buffer came after the modified variable, resulting in me not being able to overwrite the buffer. Basically the stack looked like this (from bottom to top): 0x00000000 ('modified') 0x41414141 (input buffer) ... I tried it on my own machine instead of a virtual machine so maybe that's the reason why ? But I guess it should work on any machine right ?
*_A question. I've been on stack1 exercise._* And I've been for the last half-hour or something XD. Trying to understand the endianness and I think I finally got it but I'm unsure and I'd like anyone to tell me if I'm right or not, please. So for stack1 I wrote as input string "ABCDBBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOOPQRSdcba" and ABCD, PQRS and dcba seem to be in opposite order in IDA's Stack View (using IDA Freeware 7.0 - AMAZING program for Windows, Linux and Mac). BUT...... It's only in opposite order in THAT LINE of 4 bytes (32 bits). So my guess is: the CPU reads the first ABCD all at once and writes starting at D through A. The same for the others... Then the same for PQRS which starts on S through P, and then it gets to dcba and it writes a, b, c and d in memory --> all this starting ALWAYS on the lower addresses first. Address Value FDB477C 44434241 FDB4780 42424242 FDB4784 43434343 FDB4788 44444444 FDB478C 45454545 FDB4790 46464646 FDB4794 47474747 FDB4798 48484848 FDB479C 49494949 FDB47A0 4A4A4A4A FDB47A4 4B4B4B4B FDB47A8 4C4C4C4C FDB47AC 4D4D4D4D FDB47B0 4E4E4E4E FDB47B4 4F4F4F4F FDB47B8 53525150 FDB47BC 61626364 So it's all in the "correct" order LINE BY LINE but in the opposite order IN THE SAME LINE - because it reads 32 bits at a time and switches the bytes at those 32 bits. Then reads the next 32 bits and switches the bytes again. But it's reading every 32 bits in the "correct" order! Now... Is this right? I'd love it to be, so it would mean I got this hahaha. EDIT: from here I think I'm correct, but I'd still like a confirmation: www.scadacore.com/tools/programming-calculators/online-hex-converter/. EDIT 2: with this helping much on the positive side: stackoverflow.com/questions/2846914/what-is-meant-by-memory-is-8-bytes-aligned (in this case it would be on a 64-bits CPU, not on a 32-bits one). EDIT 3: I think the inside the parenthesis on EDIT 2 is wrong. I think I should say not depending on CPU bits, but on the data being read. If it's only 1 byte (character), 2 bytes, 4 bytes or 8 bytes (or 16 in case of SSE instructions acording with a StackOverflow user) - that's what I think that defines the alignement. That would say the number of nibbles to be swapped. Not sure though. EDIT 4: Nope, I think it's wrong... :´-(
I cannot express enough gratitude for how much I love these videos. Live0verflow is the only person ON PLANET EARTH explaining exploitation this well.
in the 8:00 section
do you know why the integer variable needed to be placed in the higher offset instead of just the current RSP offset ? I am a little bit confused 😔
and would appreciate it if someone enlightened me 😁
This is some of the best stack explanation I have seen, allowing the viewers to easily follow along with the diagram and the gdb. Thanks a lot!
just wanna say thank you to the author. this series of video is even more informative than the $1000 course I purchased before
If you don't mind, which course?
yup, OSCP certification training course. Lab hours are included of course.
Are they provided by the OSCP guys? Mind dropping the link? I am looking forward to do it. Thanks
that stack illustration is brilliant
Just for the record: I did this on Ubuntu and used gcc to compile the code. When i tried to exploit the exec the error " *** stack-smashing detected *** ... terminated" showed up.
The solution: When compiling use the "-fno-stack-protector" argument to aviod extra protection.
USE GDB
The extra protection is the addition of a stack canary value for anyone curious.
This playlist is pure gold. I wish you could make videos on topics such as ELF Code Injection, Packers, Crypters one day. Keep up the great work bud!
conway's game of life pfp??
Thanks for making those videos, I hadn't found such a good hacking related channel ever
I saw something wrong with the value of esp at 6:30, but so thank you about this video, very basic and clear, i lost much time to meet this video!
I dont even know how many times I have watched this. But every time I watch it, I manage to learn something new. How??? I watched the video 10 times to fully understand
I cannot thank you enough for the nice stack animation! At 06:14 , esp has value 0xbffff7d8 and is subtracted 0x60 , the video shows that esp now becomes 0xbffff770, but doing "hex(0xbffff7d8 - 0x60)" in python gives '0xbffff778'. Any hints would be helpful!
+Akhil I may have screwed up this when I made the video. Thanks for watching my videos so closely!
+LiveOverflow. Thanks for the clarification. I am trying to learn as much as I can from your awesome videos. Cheers :)
+Akhil Sharma You forgot the "and"-operation in the line before, where the last 4 bits of esp are set to 0, so that the value of esp before the subtraction is 0xbffff7d0
+LiveOverflow Thank you for your videos. They're really great!
I've had this exact problem and I found out that the `and esp, 0xfffffff0` operation does this. If I understood correctly BBIT-Solutions' comment, it just serves as a "clean up" so that the address ends with 0. LiveOverflow also mentioned it at 4:48. Please correct me if I'm wrong.
Thank you for these videos! They keep getting better and better :)
Amazing vids man. I hope you get way more views, you definitely deserve it.
FINALLY I understand buffer overflows and what they have to do with the IP register :)
Fantastic content! But I would prefer if you draw the stack upside down, since it starts at a higher-numbered address, and ends at a lower-numbered address.
Amazing illustrations. Thank you very much, it couldn't have been explained better.
10:53 in this scenario you just simply need to echo those characters that over flow the address and pipe it to wc -c to count how many characters and multiplay it with A :)
I just set a break point at the * Test eax, eax * and then set it's value to 0, and it magically worked!!
The video is amazing and the explanations as well. Thank you :)
I would prefer to see that the Stack in the visualisation grows downwards as we "start" at the highest memory address and then move the stack pointer to lower address.
And I think there is something messy with the addresses of the base pointer, when I compare it to the maped address space you showed earlier in this video. The newer comments here seem to be confused as well so maybe a update on that video would be helpful for all of us who are new to that topic :)
@5:37 the base pointer ebp = 0xbffff900. At 3:49 in the mapped address space, the start and end address of the stack are 0xbffeb000 and 0xc000000 respectively. I thought the base pointer points at the highest address of the stack - why isn't that here?
And why is the stack pointer address at 05:41 0xbffff7dc, at 05:43 0xbffff7e4 and at 05:47 back to 0xbffff7dc?
At 6:07 you say we overwrite ebp with the value of esp, but you did the reverse: you overwrote esp with the value of ebp. Or what did you mean with "value"?
But tbh at 10:09 I was just mindblown. For the first time I really understood what a Stack Buffer overflow is. Thank you!
And it would have been helpful to enumerate the memory addresses in you visualisation at 5:49 to have one row with the memory address and the other row with the content in there.
Great video.
Thanks for explaining with the help of animations, really helped me to understand.
*_Just a tip for whoever is doing stack2 exercise:_* you can escape characters on the environment variable on without Python but using Bash by doing the following:
WHATEVER=$'\x41\x42\x43\x44'
result of echo $WHATEVER:
ABCD
PS: you can also use \u0041 and so on, but then you need to see the ways of escaping characters. \u is for UTF-16 (or UTF-8), for example. \U I believe is for UTF-32 (or UTF-16 or UTF-8). And there may(must?) be other ways. You can also escape in octal, for example.
Woahh awesome trick, very helpful and save a lot of my time!
Nice video :)
You should have way more subscribers
+VoOoLoX Thank you! You can help by sharing this with your friends ;)
+LiveOverflow I know i already shared your channel with few of my friends
When professor says do your own research instead of teaching the real stuff, here I come :)
Hey man,
I am loving your videos. Fantastic content and great production quality. Thanks a lot for this and please keep it up. :)
8:30
If esp is a register, that contains an address then adding 0x1c to it will us directly the address at offset 0x1c. Why then do we need to use bracket notation if we want to store the address itself in eax and not the value that it points to?
Can you make a video on writing shellcode for buffer overflows?
I believe this is what you mean? You probably don't need it anymore, but others might, so I decided to still answer. This is the video, hopefully (in playlist mode): ruclips.net/video/HSlhY4Uy8SA/видео.html
"Don't be a script kiddie" - Every master once a script kiddie.
The stack animation is great! Thanks.
That's goddamn best tut on youtube ever. Keep it up, man!
I leave this comment to prove that during my life, i've watched this video "First Stack Buffer Overflow to modify Variable - bin 0x0C" and i've done this level
Wow......... this is SO AMAZING!!!!!! THANK YOU MAN!!!!!!!!
6:38 new ebp is pointing to the old ebp.Not able to digest it. Can anyone give a simple explanation for it @liveoverflow
It's a little bit ambiguous. But by "new ebp is pointing to the old ebp" at 6:38, he meant that the memory ebp is pointing to now stores the value of ebp of the previous function.
More specifically, at 6:38, value of ebp is 0xbffff7d8, which means it now points to memory address 0xbffff7d8, and at this address, the memory stores value 0xbffff900. And remember that "push ebp" at first line of the main function disassembly? It just pushed value of ebp into stack, value of ebp at that time was still the "old one", which was 0xbffff900.
Hope I can help to explain well. Just remember that value of these pointer registers stand for memory address they are pointing to.
yeah, i got stuck there for 3 months don't worry :)
Thank you very much for your awesome videos !! if anyone doesn't mind, at 6:36 why is ebp still pointing to the old value of ebp even after overwriting it with esp ? doesn't it point to the memory address it has as value (in general) ? your help is much appreciated !
i don't know why but a lot of people get very confused right there including me, caller(function that callled current function) ebp got pushed on the stack so its on the stack and it is also the top of the stack because its the only thing in stackframe right now so esp is pointing to it, then new ebp is made to point to esp which points to the old ebp and then esp is decremented sub esp xxx for local variables
How can I love the video not just like it ?
9:00
char buffer char[64];
I take it to mean 64 bytes, Why is there no 0x40 hex value on the shown disassembly output that corresponds to the number 64 in decimal?
0x60 - 0x5c = 0x4
96 - 90 = 4
is that actually mean the int size is 4 byte?
yes! 32bit integer is 4 bytes
I have a problem. My gcc has registered the 0x0 of the int modified variable at esp-0x54. What means that it's even more deeper on the stack than the buffer. So then, I cannot affect the variable.
I would recommend to not compile it yourself, but find and use the protostar VM
@@LiveOverflow I found an easy solution for this by just grouping the data on a struct, and worked. But you're right, I'm going to start using it. By the way, if you are reading this, the exploit exercicies links are down
Noob here. Isn't it setting ESP value into EBP?? You said the opposite at 7:05 but at 4:30 the Intel document states that ESP is set to EBP
There is no longer a website running on www.exploit-exercises.com
do you have another link to download the image of the exploit-exercises ?
drive.google.com/drive/u/0/folders/0B9RbZkKdRR8qbkJjQ2VXbWNlQzg
web.archive.org/web/20171027043402/exploit-exercises.com/
03:14 Can it be set as default forever so that I wouldn't have to type-in that command every time I run GDB? :q
Sorry but, I can't understand you at 9:50. How did you counted these rows? Thank you.
"4 characters here". AAAA -> 0x41414141. "Then 4 times 4 that's 16 for a row". so 16 bytes per full row. We have 3 rows that are filled full with 4. "And with the next fill row we can ...". So the fourth full row would write over the 0x00000000.
LiveOverflow Thank you very much:).
I'm curious about the stuff that is in the stack frame memory region before we write our As, Bs, and Cs into it. Presumably it is just junk from some previous program that happened to use that part of memory before or even random stuff from turning on our machine.
Now, if we write the pattern of letters into memory and not properly clean it up, it should still be there somewhere, right? Is it at all possible to try to access data in memory that served as a stack frame of some prior program? Or does memory virtualization prevent that one can reliably find that region of (physical) memory ever again?
I replaced the gets function with scanf and hoped to observe the same thing as in the video because I've heard people say that scanf is also an insecure function, but it never overflowed, what do you think?
ok, i have decided i will study this video until i understand it
Thanks a lot for the presentation but I have few questions trying to understand it... Is the following representation of "leave" and "ret" instructions correct?
leave is like:
mov esp, ebp
mov ebp, [esp]
add esp, 0x8
ret is like:
mov eip, [esp] // move value at current stack pointer to eip (that value was stored at top of the stack when "call" instruction was used)
add esp, 0x8
Would it be possible to actually use the instructions above instead of "leave" and "ret"?
And why both instructions increase esp register by 8 instead of 4 which would be expected knowing that registers are 4 bytes in size? Is it the way how 32-bit system can be ran on 64-bit processor? Meaning that if I ran the same program (recompiled?) using old 32-bit processor then "leave" and "ret" would actually increase esp by 4?
Great video, but at 6:12 you said mov esp,ebp and its mov ebp,esp ( since you are using the intel syntax that is not correct, as you already know) its just a note ;)
huh? I'm rewatched the part like 5 times and I'm sure I said "mov ebp,esp"? Or what do you mean?
I know what is going on ... You are moving into ebp esp and you said that, but if you read using the intel syntax ( dest , source ) you should say mov esp "into" ebp ) ... Or am i wrong ?
I say: "Now we overwrite EBP with the value from ESP. move ebp, esp". I don't get it? First I say what the instruction does, and then I mention the instruction again.
I understand you both, its very confusing, but is just a interpreting thing
I don't understaaaaaand :D I didnt say it the wrong way around, did I? Or am I looking at the wrong minute?
So, the task sold is to share to stack0 a big amount of "AAA" to rewrite zero variable.
Could someone explain why the buffer is 64 bytes but 0x60 size is reserved on the stack? Shouldnt that be 0x40 just for the buffer?
Did you find a answer to this question? My guess would be the binary automatically allocates some extra space for protection against buffer overflows even when accounted for the other variables to be pushed to the stack.
0x60 is hexadecimal notation so in decimal it is 96. Why 96? there is some other things that stack needs to store.
this is still a bit murky... so you push on the stack and push the modified variables address where?
Video was excellent tho
Why does the program allocates 0x60 (96) bytes on the stack while the summed size of the variables is 64+4=68 bytes??
0x60 is hexadecimal notation so in decimal it is 96. Why 96? there is some other things that stack needs to store.
What software did you use for creating the stack animation?
8:50 nice trick everytime breakpoint was hit
define hook-stop
info registers
x/24wx $esp
x/2i $eip
end
To crack stack 1I ran it in gdb and found it was comparing 0x61626364 with $eax, I then ran the stack1 program with test values AAAA, AAAAAAAAA... to see at what point i would overflow into the register it was checking i eventually ran it with AAAAAA and saw the message saying "try again you got 0x414141... i then went back and ran the program with the values AAAA...dcba and it worked, is this an effective way of breaking the c program or should i have done it using a different method?
I come back to this video sometimes for the stack frame animation. It all made sense and I think I understood what is pushed/popped from the stack and in what order. Today I looked at stack example from this book (page 130, figure 6-5):
www.electroons.com/8051/ebooks/expert%20C%20programming.pdf
and the order seems "flipped". Did the author make mistake or in some circumstances the order is just different?
I mean, order of stack frame contents in relation to order of stack frames themselves is different. It looks like in the book the return address is pushed onto the stack as the last thing (which seems weird considering it actually happens first).
That's just due to different memory layout. Sometimes the stack grows towards the end, sometimes at the start of the address space.
I know this is a little late, but for anyone else who is wondering why this is the case, it's simply a matter of which computer architecture you're working with.
but the stack grows down ? why is it up in the video ???
Does this exploit have to be compiled inside the given Linux VM to work ?. I tried to compiled the source code on my Mac and seems like the same technique doesn't work anymore
I think your system has to be 32bit but not sure
You are best
Why did u only use x/24wx for examining the esp and not x/32wx or x/28wx
Did you understood after 9 months?
@@coder_rc Did you get this after 2 year? I'm still confused :(
@@amberchen7817 I think it's better if you start with a blog post on buffer overflows on linux
I cant understand. Please guide me so that i can gather some basic knowledge and come back
When something is pushed on to the stack, the stack pointer isn't incremented, it's decremented?
Yes, that's right.
@@markusjohansson2945 yeah kinda brainfucks
The website for protostar is down
exploit.education/protostar
Those who didnt understood this video can read this article by null byte and comeback to here
And what with the stack canaries? Why the protection doesn't work there?
This is an oldschool example before stack canaries. But in episode 0x23 we compile this challenge on a more modern Ubuntu Linux, with stack cookies, and try to exploit it again ;)
Oh ok that makes sense, thanks for really quick answer :)
why can't we dynamically modify the "modified" variable?
The best video
i like the fonts you use.. can you please name them
Is anybody else getting:
Program exited w/ code 013
Error while running hook_stop:
The program has no registers now.
:(
got it..
I had to add the second memory address break point. back to work :)
if you should never use gets why does it exist to use?
Straight proof
Good video
cant i just change the value from gdb using set command ?
you could. the obvious implication, then, is that you have to run the program with gdb (or any debugger).
If you are looking for the website, here you go; www.exploit.education
Why is Eax compared to Eax shouldn't the be equal?
Please add the time, I don't have time to rewatch a 10min video and guess what you are referring to
yeah sorry about that i kinda sent the questions in sucession so it is at 8:40
stackoverflow.com/questions/13064809/the-point-of-test-eax-eax
this is great
I cannot acces to protostar
exploit.education/protostar
Amazing! Can we donate (buy you a beer?)
Don't know if you still need this, but he has a patreon and a channel membership
@@arandomstranger6954 yeah was a member for a while :) thanks.
why is this hard to follow :(
Over C++ 11, there is no function get
When I tried it I observed that in my case the input buffer came after the modified variable, resulting in me not being able to overwrite the buffer. Basically the stack looked like this (from bottom to top):
0x00000000 ('modified')
0x41414141 (input buffer)
...
I tried it on my own machine instead of a virtual machine so maybe that's the reason why ?
But I guess it should work on any machine right ?
My solution, bash only :) enjoy ;
echo $(for x in $(seq 64) ; do printf A ; done ; echo 0666) | ./binary
lol vtf is that stack still don't understand
*_A question. I've been on stack1 exercise._* And I've been for the last half-hour or something XD. Trying to understand the endianness and I think I finally got it but I'm unsure and I'd like anyone to tell me if I'm right or not, please.
So for stack1 I wrote as input string "ABCDBBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOOPQRSdcba" and ABCD, PQRS and dcba seem to be in opposite order in IDA's Stack View (using IDA Freeware 7.0 - AMAZING program for Windows, Linux and Mac). BUT...... It's only in opposite order in THAT LINE of 4 bytes (32 bits). So my guess is: the CPU reads the first ABCD all at once and writes starting at D through A. The same for the others... Then the same for PQRS which starts on S through P, and then it gets to dcba and it writes a, b, c and d in memory --> all this starting ALWAYS on the lower addresses first.
Address Value
FDB477C 44434241
FDB4780 42424242
FDB4784 43434343
FDB4788 44444444
FDB478C 45454545
FDB4790 46464646
FDB4794 47474747
FDB4798 48484848
FDB479C 49494949
FDB47A0 4A4A4A4A
FDB47A4 4B4B4B4B
FDB47A8 4C4C4C4C
FDB47AC 4D4D4D4D
FDB47B0 4E4E4E4E
FDB47B4 4F4F4F4F
FDB47B8 53525150
FDB47BC 61626364
So it's all in the "correct" order LINE BY LINE but in the opposite order IN THE SAME LINE - because it reads 32 bits at a time and switches the bytes at those 32 bits. Then reads the next 32 bits and switches the bytes again. But it's reading every 32 bits in the "correct" order!
Now... Is this right? I'd love it to be, so it would mean I got this hahaha.
EDIT: from here I think I'm correct, but I'd still like a confirmation: www.scadacore.com/tools/programming-calculators/online-hex-converter/.
EDIT 2: with this helping much on the positive side: stackoverflow.com/questions/2846914/what-is-meant-by-memory-is-8-bytes-aligned (in this case it would be on a 64-bits CPU, not on a 32-bits one).
EDIT 3: I think the inside the parenthesis on EDIT 2 is wrong. I think I should say not depending on CPU bits, but on the data being read. If it's only 1 byte (character), 2 bytes, 4 bytes or 8 bytes (or 16 in case of SSE instructions acording with a StackOverflow user) - that's what I think that defines the alignement. That would say the number of nibbles to be swapped. Not sure though.
EDIT 4: Nope, I think it's wrong... :´-(
thanx
Can u crack anti debugger apps .
Depending on the app and what anti debuging techniques it using
mind ones business not the other
Machst du auch ein solches Video auf Deutsch? Wäre geil.
+Solomon Tan Dafür habe ich leider keine Zeit
Schade drum. Übrigens, deine Videos sind die besten. Die gefallen mir sehr. :) Gut gemacht! Hast du Patreon? Ich unterstütze gerne.
in today there is pwndbg for that trick 🤣🤣🤣🤣
you are cool
">alert('super')
youtube doesnt allows your script huh? sad :(
@@d1rtyharry378 i am waiting for haha react button on youtube replies
I just typed to it 66 As xD
i can't even say in words how 6:30 annoying and not understandable it was for me
oh...my...god...is to much bug
cant understand a shit from assembler, and i thought JS is a fucking nightmare...
+Ragnar Lothbrok you should watch the angularJS JavaScript sandbox escape series I did ;)
Sure man, I plan to watch all your vids even though some are too damn smart for me.Cheers
Hi
i like the fonts you use.. can you please name them