so each of the provided %x is "eating"/"popping" 1 iitem from the stack (which is possible because printf does not have any char/param count/limit) and once we eat all the items on top of our address we use %n knowing that our address is at the top of the stack. Is that correct? Does that also mean that we could use larger string of "AAAAA" before the address to make our target contain specific value?
I've struggled to understand why it is that simply because the address is the last thing printed that it means the address is positioned at the top of the stack, and this is the only comment that seems to address this issue. I can see that placing more items on the stack shifts the value that the "%x " will print out down the positions on the stack. Eventually, the value printed will fall within the range of values in the first argument supplied to the program, and the exact number of characters supplied can be manipulated to position the target pointer. But just because the target pointer is the last value printed doesn't mean its anywhere near esp. In fact, when using gdb, esp seems to be at 0xbffff5d0, while the final address that the target pointer is set at is somewhere around 0xbffff7f0.
@@ponysopher First off, the challenge was not to modify ESP. The challenge was to modify the variable called 'target'. Nothing is being 'overflowed'. Instead, memory is being leaked, and allows the %n feature to be exploited to overwrite a variable. That is what the success message came from. Next, the address of target is not at the top of the stack. The address is somewhere above the 'main' stack frame, with argv.
Why are the chars AAAAAAAA at 7:35 not continuous on the stack, like 41414141 41414141, but are actually like this 41414100 41414141 20782541 (mixed with some other chars)?
I showed in the video what the input is. It's "AAAAAAAA %x %x %x %x %x %x..." ... so the 20782541 is the "%x %x" stuff. And there are 8x 41 in there. and 41414100 is actually in memory looking like this: 00 41 41 41, so it just means the string doesnt start aligned, there is a nullbyte at the start of it :)
I thought about this problem too. and I figured it out, it is just because four A or eight A are not neccessarily placed aligned on the stack for no special reason. XD
Why are some hex values not full 8 characters? For example, once you inject the A's, you get nice and neat 41414141 41414141, etc. But then you'll see groups less than 8 length. Why is that? How can those be interpreted?
I had trouble understanding on the format2 how the value is valuated with the %n. When we use %x i thought 2 hexits are 1byte, but since the hexadecimals are printed as chars 1 hexit is considered as 1byte, since its just a character in the string now.
I did not understand very well what happens is that it is stored in the memory address that says the code printed the total value of characters printed so far or something like that?
@@kim15742 If you mean that is referring to an undeclared variable it is actually declared above the vuln function as a global variable, I didn't see it at first too, if you're meaning that doing if(_int_variable) is undefined behavior it is actually a C legal instruction: 0 is false and non zero is true
If(variable) means if(variable != 0) and the opposite if(!variable) means if(variable == 0). Widely used syntax but a bit misleading if you don't know it.
When I do this command: ./format1 "`python2 -c "print 'AAAA' + '\x0c\x20\x00\x00' + 'BBBB' + '%x '*500 + '%x'"`" Sometimes it will show me the AAAA, BBBB, and all the %x's but other times it will just give me a bunch of 0's. What gives?
I rewrote the code,compiled it and linked it on my raspberry pi.I can not get the pointer to line up and the pointer has zeros at the start of the pointer.Can someone help?Thanks in advance for your help.
Loved this video! Question: I am trying to investigate on actual, real life examples in which this has happened (when, where, how). We can "hack" a small piece of code we made ourselves, but in the wild, how this has happened? It would be useful to know where to look for implementations to do some improvings
On the last section of this you suggest Python which clips at 500 chars - I'm doing a CTF (first ever) and the stack variable go from showing the 414141 and 424242 but also - there is a gap where the desired value exists. Each time I retry the program the returned data changes - how can I track it down if its different every time? thanks
I don't quite understand what you mean with "clips at 500 chars"? I think what you are referring to was me trying to say, that format strings are sometimes ugly to deal with and keeping a constant size input makes it easier. That's why I make sure my input is always 500 chars. But you can also make it bigger or not clip at all. So you can ignore that too. does that answer the question?
Hello - thanks. I am at the point where I need to decrease slowly the value 400 (in my example shown) however if I run the application multiple times and do not change the value 400 - all of the values on my screen change. Sometimes 0 0 0 0 0 and sometimes 25207825 20782520 78252078 - but not consistent. The system is 64bit and is maybe ASLR stopping me? ./program "`python -c "print 'AAAA'+'\0x00\0x34\0x0b\0x60'+'BBBB'+'%x '*400"`" thanks for these videos - amazing work
Ok what I don't get, is when I get to the step where we put the AAAA in there, I scan the entire stack and that value does not exist like it does in the video. I also cannot find the memory address for target anywhere. For me, the address is 0x804a020 and it is no where to be found in the stack values, even if I do a x/500x $esp. I added a new variable to the program for testing purposes and intialized it, and I was able to locate it on the stack, however.
Did you compile it yourself? are you using the VM? The input is placed on the stack, so if you break at the correct point, you can find your input AAAA on the stack. Maybe you break at the wrong point when you do the x/500x $esp?
Die Addresse von target ist bei mir 0000000000601044 also kürzer als bei dir und wenn ich \x44\x10\x60 reinschreibe steht am ende immer 25601044 auf dem stack weil er keine führenden Nullen schreibt sondern was anderes reinschreibt. Was kann ich da machen???
I had little problems getting the informatation to stay ordered nicely when it printed out. I figured the problem was that my input "%x " only took 3 bytes of space in the stack and it can hold 4. This caused stuff to move very annoyingly. Once I made it to take 4 bytes with two spaces it was alot easier to find the correct place where to put %n.
yep, whenever you do one %x it increments the internal pointer of printf (this is meant to point to the given argument, but if none are supplied it reads from the stack). You could do something like %50$x to increment the pointer by 50 places to read the value of the [ESP+50].
@@cyber1377 wouldnt %50$x mean that it takes the argument at [ESP+200] since printf points at the first four bytes when %x and the second 4 bytes when %2$x
Help please, how can i do if the memory address of my variable is like '0x00aabbcc'? i mean, when i try to put the address into the stack to override it's content i can't put the 00 at the start: i obtain 'ddaabbcc' where 'dd' is a character in the stack that follows 'aa'. This is a problem cause i can't override 'ddaabbcc' cause this address doesn't exist.
Hi @LiveOverflow . Thank you for your vids. I have been hooked since my very first CTF last year December. Please can you tell me 1) why the format string should contain \x38 . Is this to escape the string? (otherwise we would write the ASCII value of the digits?) What is the x for specifically? 2) Why they are in reverse order? I understand what endianness is as a concept, but don't see how it affects address pointers. Is the format string input read left to right or right to left?
I think it does not matter if the format string is read from lower address or higher, the important thing is that when it is represented by %x, it will be ordered in little endian. But the order you write the address in print(python) is important, because I assume it writes the address first to lower address then to higher
So to get it straight. I place the actual target address on the stack and then I pass enough %x to pop items off the stack until I reach that target address. And then I write (anything in this case, as long as there is something and not 0) to that address using %n. If that is correct, then I do not fully understand the idea of placing the address of target manually on the stack. I am missing something here. Could anyone elaborate on this?
Because %n is using to write into a variable address that is placed on top of the stack. Therefore if we place on top of the stack an address (the address of our target value) %n will modify it.
I am assuming that you are talking about the objdump command? In that case it is most likely because you are compiling with 64-bit c so your addresses are twice as long. You can compile to 32 bit binary tho just look up how to do it
i still don't understand, how did he write to that specific memory address, he just had to find it in the stack then write the %x to that address? im very confused now
@@yaseen_elolemy What he was searching for was the ability to call: `printf("...some characters... %n", &target)` which is equivalent to `printf("...fewer characters... %x %n", 0, &target)` `printf("...even fewer characters... %x %x %n", 0, 0, &target)` `printf("...a couple of characters... %x %x ... more %x ... % x %n", 0, 0, ..., 0, &target)` Now, the point is that you can get printf to read deeper and deeper (shallower and shallower?) in the stack for more "function arguments" by adding more and more %x, until printf is looking for its next argument at a location in memory that contains the value equal to `&target`. Once you have something that behaves like `printf("...some characters... %n", &target)`, then that printf call -- according to the printf specification for %n -- will basically do this: `*(&target) = strlen("...some characters... ")` This changes the value of target to some non-0 value. (It's probably been set to something closer to 4 + 4 + 5 + 8 * 127, since that's approximately how many characters have been printed out by printf before consuming the %n, but this attack only cares that it's not 0.)
for a different perspective, for those of us just coming to grips with format strings... @@yaseen_elolemy think of how the entire runtime stack looks once we enter printf: Lo-mem Hi-mem [printf stack frame] | vuln-ebp | vuln-eip | string (argv[1]) | [vuln stack frame] | main-ebp | main-eip | argv[1] | ...stuff... | target-address think of consecutive %x specifiers as popping values off the stack to read - note that is not what actually happens, of course, just consider it this way for a minute. with the correct number of %x "pops," we are tricking printf into thinking we pass it an address to write the %n to
Hallo erstmal einen Lob für deinen Kanal, Danke super Erklärt, wollte deinen beispiel nachmachen, aber leider , habe ich komische weten, muss dazu sagen ich arbeite auf einen VM mit ubuntu 64 bit, den binary wurde mit gcc -m32 option compiliert, ich sehe auf den stack keine values die aaaa entsprechen, kannst du mich da weiter helfen, thanks Elreys
64bit hat eine andere calling convention. Und ich weiß auch nicht was der compiler auf dem neuen ubuntu baut. Du solltest die VM nutzen, sonst wirds am anfang schwer. You should checkout episode "Buffer overflow on a modern system impossible? stack0: part 1 - bin 0x21"
Hallo LoF habe wahrscheinlich rausgefunden wo das eigentliche Problem besteht, ich habe komische Werte auf Windows 10 Running VM workstation 12 , habe das gleiche auf Virtual Box mit windows 7 64 Bit getestet und da funktioniert es einwandfrei.
So if whatever `arvg[t]` points to would not be placed on the stack by the system, but into some memory allocated somewhere else (e.g. on the heap), there would be no way for us to supply this addres of the `target` variable so that `printf` could use it? :q
But who in their right mind passes user-supplied data as the FIRST argument to `printf`? I have never seen any actual real-world code that would do that. They rather have the first parameter a static string, and pass user data to the SECOND parameter, if any.
if you look closely that x08 isn't even in the python -c print (it's not being supply to the program) I think it's just an artifact on the terminal since at the start it came up as \x08, which is ASCII for backspace.
Thanks man, it helped me clear something I was reading in Jon Erickson's book. Kudos to you !!!!
For better readability pipe the output to `| grep --color=always -e "^" -e "41"`. This will highlight the A's for blind people like me.
this is a sick tip thanks buddy
I love you
The idea with the padding is great
I wonder why pwntools isn't doing that by default. It makes things a lot easier
Congratulations for the channel. All your videos are awesome.
The videos were great 0/! Thank you very much for sharing this knowledge, it is very difficult to find good materials on the subject ....
This is one of the most greatest tutorials that i have ever seen :D .Keep the good job up ,I really appreciate it .
Happy hacking :D
so each of the provided %x is "eating"/"popping" 1 iitem from the stack (which is possible because printf does not have any char/param count/limit) and once we eat all the items on top of our address we use %n knowing that our address is at the top of the stack. Is that correct?
Does that also mean that we could use larger string of "AAAAA" before the address to make our target contain specific value?
exactly ;)
I've struggled to understand why it is that simply because the address is the last thing printed that it means the address is positioned at the top of the stack, and this is the only comment that seems to address this issue. I can see that placing more items on the stack shifts the value that the "%x " will print out down the positions on the stack. Eventually, the value printed will fall within the range of values in the first argument supplied to the program, and the exact number of characters supplied can be manipulated to position the target pointer. But just because the target pointer is the last value printed doesn't mean its anywhere near esp. In fact, when using gdb, esp seems to be at 0xbffff5d0, while the final address that the target pointer is set at is somewhere around 0xbffff7f0.
@@ponysopher First off, the challenge was not to modify ESP. The challenge was to modify the variable called 'target'. Nothing is being 'overflowed'. Instead, memory is being leaked, and allows the %n feature to be exploited to overwrite a variable. That is what the success message came from. Next, the address of target is not at the top of the stack. The address is somewhere above the 'main' stack frame, with argv.
Thanks LiveOverflow I Just used This Knowledge to Solve in A Live CTF
Please help me. I'm still stuck with echooo :(
@me on discord pulkit.singhania#9456
dude thanks for all your videos,
Why are the chars AAAAAAAA at 7:35 not continuous on the stack, like 41414141 41414141, but are actually like this 41414100 41414141 20782541 (mixed with some other chars)?
I showed in the video what the input is. It's "AAAAAAAA %x %x %x %x %x %x..." ... so the 20782541 is the "%x %x" stuff. And there are 8x 41 in there. and 41414100 is actually in memory looking like this: 00 41 41 41, so it just means the string doesnt start aligned, there is a nullbyte at the start of it :)
LiveOverflow Thanks! :) The tutorials are awesome by the way! No other tutorials come even close to yours :)
little endian
@@LiveOverflow xx se need overwrite
I thought about this problem too. and I figured it out, it is just because four A or eight A are not neccessarily placed aligned on the stack for no special reason. XD
Man, it motivates me =D Thanks a lot for this channel. From your channel, I got already a lot of knowledge. Peace
Amazing. I've just simply found my passion.
Cap
Hello, tôi cũng mới tìm ra kênh này :))
@@huyvuquang2041 :v
Why are some hex values not full 8 characters? For example, once you inject the A's, you get nice and neat 41414141 41414141, etc. But then you'll see groups less than 8 length. Why is that? How can those be interpreted?
that's just because the leading zeroes are not printed: 0x00004141 -> 4141
@@LiveOverflow lol XD
when doing the same thing some adresses get some of it s part swapped for no reason can t figure it out
4:39 humble
I had trouble understanding on the format2 how the value is valuated with the %n. When we use %x i thought 2 hexits are 1byte, but since the hexadecimals are printed as chars 1 hexit is considered as 1byte, since its just a character in the string now.
I found the target address and write it to the stack, and then %n write the number to it, but do not know why I got a segmentation fault. :/
Same
I did not understand very well what happens is that it is stored in the memory address that says the code printed the total value of characters printed so far or something like that?
Wait, isn't if (target) undefined behavior @ 2:20
Ok, I take it back, seems like that's not an issue when hacking ^^
@@kim15742 If you mean that is referring to an undeclared variable it is actually declared above the vuln function as a global variable, I didn't see it at first too, if you're meaning that doing if(_int_variable) is undefined behavior it is actually a C legal instruction: 0 is false and non zero is true
If(variable) means if(variable != 0) and the opposite if(!variable) means if(variable == 0). Widely used syntax but a bit misleading if you don't know it.
When I do this command: ./format1 "`python2 -c "print 'AAAA' + '\x0c\x20\x00\x00' + 'BBBB' + '%x '*500 + '%x'"`"
Sometimes it will show me the AAAA, BBBB, and all the %x's but other times it will just give me a bunch of 0's. What gives?
I think that it is kind of system protection, where it start with variable length of the stack.
You can use the Vm of the book "The art of the explotatio " nostarch.com/hackingCD . Test with it
I rewrote the code,compiled it and linked it on my raspberry pi.I can not get the pointer to line up and the pointer has zeros at the start of the pointer.Can someone help?Thanks in advance for your help.
Loved this video! Question: I am trying to investigate on actual, real life examples in which this has happened (when, where, how). We can "hack" a small piece of code we made ourselves, but in the wild, how this has happened? It would be useful to know where to look for implementations to do some improvings
Also, what's with the last function you were writing at the end?
@@jag831 the function at the end is used to get a string of the same lenth, this is used to keep the stack fixed
How come my objdump -t doesn't provide hex values?
Great tutorial. It's a great help to me, thank you!
How did you make that binary rabbit running?
I don't know much about video editing, but I guess he just put a picture over the clip and used an effect.
$ ./rabbit
` oh damn it printed a number ` lel
kmlh
Keep these coming!!!!!!!!!!!!!!!!!!!!!!!!!!!!
On the last section of this you suggest Python which clips at 500 chars - I'm doing a CTF (first ever) and the stack variable go from showing the 414141 and 424242 but also - there is a gap where the desired value exists. Each time I retry the program the returned data changes - how can I track it down if its different every time? thanks
I don't quite understand what you mean with "clips at 500 chars"? I think what you are referring to was me trying to say, that format strings are sometimes ugly to deal with and keeping a constant size input makes it easier. That's why I make sure my input is always 500 chars. But you can also make it bigger or not clip at all. So you can ignore that too.
does that answer the question?
Hello - thanks. I am at the point where I need to decrease slowly the value 400 (in my example shown) however if I run the application multiple times and do not change the value 400 - all of the values on my screen change. Sometimes 0 0 0 0 0 and sometimes 25207825 20782520 78252078 - but not consistent. The system is 64bit and is maybe ASLR stopping me? ./program "`python -c "print 'AAAA'+'\0x00\0x34\0x0b\0x60'+'BBBB'+'%x '*400"`" thanks for these videos - amazing work
Try compiling the source with `--no-pie`. Your toolchain may have been built with PIE set to default.
this didn't help me
Ok what I don't get, is when I get to the step where we put the AAAA in there, I scan the entire stack and that value does not exist like it does in the video. I also cannot find the memory address for target anywhere. For me, the address is 0x804a020 and it is no where to be found in the stack values, even if I do a x/500x $esp. I added a new variable to the program for testing purposes and intialized it, and I was able to locate it on the stack, however.
Did you compile it yourself? are you using the VM?
The input is placed on the stack, so if you break at the correct point, you can find your input AAAA on the stack. Maybe you break at the wrong point when you do the x/500x $esp?
Hi, I didn't get the consecutive '41's either, and I was doing this experiment on a VM virtual machine. Is that due to VM?
Die Addresse von target ist bei mir 0000000000601044 also kürzer als bei dir und wenn ich \x44\x10\x60 reinschreibe steht am ende immer 25601044 auf dem stack weil er keine führenden Nullen schreibt sondern was anderes reinschreibt. Was kann ich da machen???
how did you solve it?
Whoooa! Thank you again.
You make awesome videos!
What if your values never show up on the stack?
i do not get how can you live using a terminal where strings are colored red
I had little problems getting the informatation to stay ordered nicely when it printed out. I figured the problem was that my input "%x " only took 3 bytes of space in the stack and it can hold 4. This caused stuff to move very annoyingly. Once I made it to take 4 bytes with two spaces it was alot easier to find the correct place where to put %n.
Am I right, that printf("%x") depending on how many "%x" I write just prints the value of [ESP+CURRENTX] ?
yep, whenever you do one %x it increments the internal pointer of printf (this is meant to point to the given argument, but if none are supplied it reads from the stack). You could do something like %50$x to increment the pointer by 50 places to read the value of the [ESP+50].
@@cyber1377 wouldnt %50$x mean that it takes the argument at [ESP+200] since printf points at the first four bytes when %x and the second 4 bytes when %2$x
@@uuuuuhhlettuce3909 ye i got it wrong, since each address is 4 bytes it would actually be 50*4
Help please,
how can i do if the memory address of my variable is like '0x00aabbcc'? i mean, when i try to put the address into the stack to override it's content i can't put the 00 at the start: i obtain 'ddaabbcc' where 'dd' is a character in the stack that follows 'aa'. This is a problem cause i can't override 'ddaabbcc' cause this address doesn't exist.
fra per favore come hai risolto, ci sono fermo da 2 giorni su sta stronzata
@@education4454 sinceramente non riprendo in mano sta roba da un botto e non mi ricordo per niente, mi dispiace
@@education4454 hai risolto? lol
@@education4454 quindi?
i cant insert python command in elf file
if you have any idea please share
I can not get the address to line up.
Hi @LiveOverflow . Thank you for your vids. I have been hooked since my very first CTF last year December.
Please can you tell me 1) why the format string should contain \x38 . Is this to escape the string? (otherwise we would write the ASCII value of the digits?) What is the x for specifically?
2) Why they are in reverse order? I understand what endianness is as a concept, but don't see how it affects address pointers. Is the format string input read left to right or right to left?
\x38 at first is for the purpose of little endian (reverse ordering of address)
I think it does not matter if the format string is read from lower address or higher, the important thing is that when it is represented by %x, it will be ordered in little endian. But the order you write the address in print(python) is important, because I assume it writes the address first to lower address then to higher
So to get it straight. I place the actual target address on the stack and then I pass enough %x to pop items off the stack until I reach that target address. And then I write (anything in this case, as long as there is something and not 0) to that address using %n. If that is correct, then I do not fully understand the idea of placing the address of target manually on the stack. I am missing something here. Could anyone elaborate on this?
Because %n is using to write into a variable address that is placed on top of the stack.
Therefore if we place on top of the stack an address (the address of our target value) %n will modify it.
you know how to solve the previous Format0 following their "Hints: This level should be done in less than 10 bytes of input." ?
%64d is similiar to 'A'*64
thanks!
i see lots of zeros .. and iam not able to exploit it .. why ?
I am assuming that you are talking about the objdump command? In that case it is most likely because you are compiling with 64-bit c so your addresses are twice as long. You can compile to 32 bit binary tho just look up how to do it
How to read from and write an arbitary address using this vulnerability.?
i still don't understand, how did he write to that specific memory address, he just had to find it in the stack then write the %x to that address? im very confused now
how to did he just print the variable's memory address and write to it if he just had written it himself
@@yaseen_elolemy What he was searching for was the ability to call: `printf("...some characters... %n", &target)`
which is equivalent to
`printf("...fewer characters... %x %n", 0, &target)`
`printf("...even fewer characters... %x %x %n", 0, 0, &target)`
`printf("...a couple of characters... %x %x ... more %x ... % x %n", 0, 0, ..., 0, &target)`
Now, the point is that you can get printf to read deeper and deeper (shallower and shallower?) in the stack for more "function arguments" by adding more and more %x, until printf is looking for its next argument at a location in memory that contains the value equal to `&target`.
Once you have something that behaves like `printf("...some characters... %n", &target)`, then that printf call -- according to the printf specification for %n -- will basically do this:
`*(&target) = strlen("...some characters... ")`
This changes the value of target to some non-0 value. (It's probably been set to something closer to 4 + 4 + 5 + 8 * 127, since that's approximately how many characters have been printed out by printf before consuming the %n, but this attack only cares that it's not 0.)
for a different perspective, for those of us just coming to grips with format strings...
@@yaseen_elolemy think of how the entire runtime stack looks once we enter printf:
Lo-mem Hi-mem
[printf stack frame] | vuln-ebp | vuln-eip | string (argv[1]) | [vuln stack frame] | main-ebp | main-eip | argv[1] | ...stuff... | target-address
think of consecutive %x specifiers as popping values off the stack to read - note that is not what actually happens, of course, just consider it this way for a minute. with the correct number of %x "pops," we are tricking printf into thinking we pass it an address to write the %n to
@@nez14526 Thanks, ur explaination is pretty clear.
Btw what is \x08 at 9:18 for?
Great video
this is amazing
i dont understand why i get not aligned , how it can solve ? whi it appens ?
Hallo erstmal einen Lob für deinen Kanal, Danke super Erklärt,
wollte deinen beispiel nachmachen, aber leider , habe ich komische weten, muss dazu sagen ich arbeite auf einen VM mit ubuntu 64 bit, den binary wurde mit gcc -m32 option compiliert, ich sehe auf den stack keine values die aaaa entsprechen, kannst du mich da weiter helfen, thanks Elreys
64bit hat eine andere calling convention. Und ich weiß auch nicht was der compiler auf dem neuen ubuntu baut. Du solltest die VM nutzen, sonst wirds am anfang schwer. You should checkout episode "Buffer overflow on a modern system impossible? stack0: part 1 - bin 0x21"
Hallo LoF habe wahrscheinlich rausgefunden wo das eigentliche Problem besteht, ich habe komische Werte auf Windows 10 Running VM workstation 12 , habe das gleiche auf Virtual Box mit windows 7 64 Bit getestet und da funktioniert es einwandfrei.
Like si tu es là grâce à SLO
What if we dont know the target address?
then you don't know where to write?
This time is "read", for example, the CTF challenge wants us to read variable without giving us source code or binary file, what should we do?
you can use the format strings like %x %x %x etc to leak values from the stack. Maybe the variable is there. Or at least the address of the variable.
I'll try , thank you so much :)
So if whatever `arvg[t]` points to would not be placed on the stack by the system, but into some memory allocated somewhere else (e.g. on the heap), there would be no way for us to supply this addres of the `target` variable so that `printf` could use it? :q
Needed ELF 64/32 bit encryption vedio
But who in their right mind passes user-supplied data as the FIRST argument to `printf`? I have never seen any actual real-world code that would do that. They rather have the first parameter a static string, and pass user data to the SECOND parameter, if any.
Plenty of real world software that did that. Just search for CVEs related to format string vulnerabilities
@@LiveOverflow Yeah, "did" is the right word. Because as this vulnerability became known, I don't suppose anyone still does.
lol. If this is how it would work, then there would be no need for security reviews anymore :D of course these issues are still found
@@LiveOverflow Can you provide any recent example instead of loling?
So what if you don't have the binaries?
You compile the source?
@@NotStirred9 Or the source. Not everything is open source
@@MauricioMartinez0707 So you want to exploit something, without having it?
@@NotStirred9 Well generally the point of exploitation is to gain access on a machine that is not yours, so yeah. That's the idea
Regards
Holy shit
ok
cant even pronounce stack correctly, kind of hard to understand
9:20 like what is that "`"x08' at the end?
You're an idiot
if you look closely that x08 isn't even in the python -c print (it's not being supply to the program)
I think it's just an artifact on the terminal since at the start it came up as \x08, which is ASCII for backspace.