That method of setting the GOT entry from 0x84b4 to 0x0804 is insanely cool. What I did was write the bytes in reverse, where I switched the order of the addresses I used as input and wrote 0x0804 to the first half of the address and then then wrote 0x84b4 to the second half. Worked in format3, but I've got to try your method too.
This comment probably saved me 2 hours on nactf 2020. I've never heard of using the %hn before and I swear it isn't mentioned anywhere. I just got 300 points because of you. Thanks a bunch.
Question you ask @10:13 "How do we get a lower number, if we can only increase the amount of character?" I would respond with , "You write the lower number first?" I am guessing that the reason you don't write the lower number first, is because of what you mention later, about the least significant bytes actually overwriting the entire 4 bytes? ie. the second write would clobber the higher bytes from the first write. Is that right?
6:58 i am not sure what is that supposed to mean: does the size of buffer matter? as long as the 134513844 is not bigger as the max memory limit of the current process(or stack?), we can at the end overwrite address in GOT.
Awesome tutorial as usual. By the way, do you use the shellcoder's handbook as resource for making these? It seems like you cover the book's topic in sequence pretty smoothly, which also lines up with the exploit exercises.
hey, im doing the same thing on phoenix and for some reason as i saw on the internet sometime %$n doesnt work and you have to manually write for example %x 12 times and only after a %n iif its the 13th param from the SP pov. any explanations please ?
We can divide the address further into bytes, so we need to print even less. Also, why do you pad the input there? I don't think its required for the exploit to work.
Hi. Thx for the series. I really enjoy a lot. Can you give more information how you can overwrite the GOT address ? Maybe you overwrite the lower part and high part of address fuzzing until get the correct address ? Is this ? Thx.
just trying this in the new 64 bit version of exploit education. Man 64 bit addresses are hard since they are so damn filled with null bytes lol had to put the addresses at the end of the exploit since redirecting stdout of the exploit_script to stdout of the programme allowed passing null bytes (thank god) but the format string just wouldn't print since printf would catch the null bytes after the first address if it was kept at the beggining.
ohhh you mean the dollar ($) in the printf format string: stackoverflow.com/questions/19327441/gcc-dollar-sign-in-printf-format-string It's part of the format string syntax and this way you can reference the n-th value from the parameters (or generally speaking the stack).
I was thinking the same thing. I think the problem is that each write is actually overwriting 4 bytes (mentioned at 10:20). Since you have to write the smaller numbers/bytes first, sequence of bytes 0x08 0x04 0x84 0xB4, would have to be written 0x04 first, 0x08 second, 0x84 third, then 0xB4. The problem is, the 0x84 would clobber the 0x04 and 0x08 with 0x00000084. Make sense? I am not sure, but I had a similar question and I am going through it in my head. I should just try it with the code.
in a later heap related video we do exactly that. But generally you need to be able to control the destination address of the strcpy, so you can choose to write to GOT.
Just saw the 2 videos. Excellent explanation! I have always admired explanations that show the memory in gdb! malloc() memory allocation was contiguous and the overwrite changed entries for . Just wondering if we can also overwrite GOT entries for a buffer allocated in .data section. Something like: char mybuffer[10]; followed by strcpy() ?
Is this also a valid solution? : put shellcode at the start of your text input, that way you have a 100% guarantee of knowing the pointer to the shellcode, then just change the EIP to there.
it's a bit changed, gdb shows me calls and jmpq instead of call and jmp it shows me something like this jmpq *0x201962(%rip) # 0x602058 and I cannot access the address
Probably one of the hardest exploits to grasp in your series, but once you do, damn! It's beautiful
can't overwrite the return pointer? no prob, we GOT this :P
OMG what an incredible joke
joke 10/10
get got
now..that's a lot of info to grasp....and again...i'm going to watch this 10 times
better try the other FormatString exploids befor that 4th than it is much easier to understand
That method of setting the GOT entry from 0x84b4 to 0x0804 is insanely cool. What I did was write the bytes in reverse, where I switched the order of the addresses I used as input and wrote 0x0804 to the first half of the address and then then wrote 0x84b4 to the second half. Worked in format3, but I've got to try your method too.
This channel is the best for learning Binary Exploitation, thanks for those amazing videos.
Thanks to you, I was able to practice FSB GOT overwrite successfully!!
Python tip @5:10: this pad function should just be .ljust(512, 'X')
For the "double write", instead of %n(int*), we could use %hn(short int*)
This comment probably saved me 2 hours on nactf 2020. I've never heard of using the %hn before and I swear it isn't mentioned anywhere. I just got 300 points because of you. Thanks a bunch.
@@lordtony8276 i'm glad to hear that, gg!
It is mentioned in Hacking: The Art of Exploitation book
I've had to watch this a few times to understand it but I've learned a lot. Carry on doing what you do!
Thanks this video really helped with my school assignment to overwrite the GOT
Question you ask @10:13 "How do we get a lower number, if we can only increase the amount of character?"
I would respond with , "You write the lower number first?"
I am guessing that the reason you don't write the lower number first, is because of what you mention later, about the least significant bytes actually overwriting the entire 4 bytes? ie. the second write would clobber the higher bytes from the first write. Is that right?
that is indeed right, if you ask me
you could also write individual bytes with "%hhn" (half half int = byte)
6:58 i am not sure what is that supposed to mean: does the size of buffer matter? as long as the 134513844 is not bigger as the max memory limit of the current process(or stack?), we can at the end overwrite address in GOT.
Its a problem even on a vm your network will die, its only not a problem locally
Awesome tutorial as usual.
By the way, do you use the shellcoder's handbook as resource for making these? It seems like you cover the book's topic in sequence pretty smoothly, which also lines up with the exploit exercises.
+orcyngiser I follow exploit-exercises. But didn't intend to follow shellcoders handbook. But imo it's pretty much the most intuitive path to take.
Im a big fan, I know this is old, but the EXIT_PLT name confuses, cause its actually EXIT at GOT, right? Such a good material keep up the good work!
For some reason then code inside exit@plt(2:54) execute jmp [ebx+something], i can't understand why, can someone help me please?
Awesome tutorial, Thanks
hey, im doing the same thing on phoenix and for some reason as i saw on the internet sometime %$n doesnt work and you have to manually write for example %x 12 times and only after a %n iif its the 13th param from the SP pov. any explanations please ?
We can divide the address further into bytes, so we need to print even less.
Also, why do you pad the input there? I don't think its required for the exploit to work.
wow i think this is the most difficult episode so far
good stuff.. thanks for showing people how to hack and not to use auto-tools.
Sure its good to know how it works, but auto-tools are great for format strings ;-P
When I try to run the exploit.py I got this: 0xError while running hook_stop:
Value can't be converted to integer.
what can be do?
i think actually 4000 people look this video 10 times XD
great video, but i don't get the use of the pad() function, why do we really need it?
To keep a constant length by padding it. So that it always takes up the same amount in memory and doesn’t push other stuff around.
you are the best brow
Hi. Thx for the series. I really enjoy a lot. Can you give more information how you can overwrite the GOT address ? Maybe you overwrite the lower part and high part of address fuzzing until get the correct address ? Is this ? Thx.
If put shellcode in the buffer, should I be able to point EIP there and execute it?
You can control the execution flow so you can point your instruction pointer what ever you want
Really well explained!! Thank you =)
Your outro is so amazing goddamit! When you do something awesome like hacking. this music is to be played as a savage moment lol!
What's the point of padding? It comes after we've overwritten with %n?
Why is the global offset table's address remaining the same? Won't it change with ASLR?
I couldn't write to the 5th,6th value on the stack without modifying the first 2 `84b4` . Can someone help me ?
For me, i always use "info functions" in GDB because it will display all the functions and their address in the program
Same here. I also sometimes use objdump -d to display the address of functions.
just trying this in the new 64 bit version of exploit education. Man 64 bit addresses are hard since they are so damn filled with null bytes lol
had to put the addresses at the end of the exploit since redirecting stdout of the exploit_script to stdout of the programme allowed passing null bytes (thank god) but the format string just wouldn't print since printf would catch the null bytes after the first address if it was kept at the beggining.
what's the 4$ for?
What do you mean?
ohhh you mean the dollar ($) in the printf format string: stackoverflow.com/questions/19327441/gcc-dollar-sign-in-printf-format-string
It's part of the format string syntax and this way you can reference the n-th value from the parameters (or generally speaking the stack).
Couldn't you have done 4 writes instead of two ?
I was thinking the same thing. I think the problem is that each write is actually overwriting 4 bytes (mentioned at 10:20). Since you have to write the smaller numbers/bytes first, sequence of bytes 0x08 0x04 0x84 0xB4, would have to be written 0x04 first, 0x08 second, 0x84 third, then 0xB4. The problem is, the 0x84 would clobber the 0x04 and 0x08 with 0x00000084. Make sense? I am not sure, but I had a similar question and I am going through it in my head. I should just try it with the code.
Can you explain how can we overwrite GOT using buffer overflow of strcpy() ?
in a later heap related video we do exactly that. But generally you need to be able to control the destination address of the strcpy, so you can choose to write to GOT.
Oh cool, will check it out. Thanks
Just saw the 2 videos.
Excellent explanation! I have always admired explanations that show the memory in gdb!
malloc() memory allocation was contiguous and the overwrite changed entries for .
Just wondering if we can also overwrite GOT entries for a buffer allocated in .data section.
Something like: char mybuffer[10]; followed by strcpy() ?
Sorry, I just realized that was a stack overflow problem again
Is this also a valid solution? : put shellcode at the start of your text input, that way you have a 100% guarantee of knowing the pointer to the shellcode, then just change the EIP to there.
You may not have execute permissions
stack is not always executable
you can execute the excecutable code though, that's why you point EIP to a defined function
excellent !
hey you can even write 1 byte and and overwrite the address in 4 passes so that u dont have to print thousands of blank space characters.
you would have to write a lot of paddings anyway because of the previous padding... by using the technique to write like the 10804 for each chunk
too fast to understand , literally i need to watch this 3 times
it's a bit changed, gdb shows me calls and jmpq instead of call and jmp
it shows me something like this
jmpq *0x201962(%rip) # 0x602058
and I cannot access the address
type "set disassembly-flavor intel" in gdb whenever you open gdb.
You should remake this video with %4$hhn which writes 1 byte at a time
fmtstr_payload joined the chat 😅
Here's poc : drive.google.com/open?id=1NktZ6ne7fpiLwG7RAkeNA3QLTmgVasRJ
I become pro haXOR
nifty
Check your email again :p
But still, this entire thing relies on someone being so dumb to send user data as a format string to `printf`. Who does that in real code? :q
I can imagine someone not knowing about strcpy and using sprintf instead
@@danielweber9414 whether you are writing code, or finding exploits for it, stack overflow is your friend. Just a diffrent stack overflow.