about the old libc version on the server: you can find the address of system on the remote box using the leak and DynELF, but finding the /bin/sh string in there would probably involve lots of trial and error.
hey thanks for the tip! it seems like it would be quite a bit of extra hassle to find all the correct offsets without the lib-c DB 😩 i ran into similar problems when attempting ropmev2 but luckily it didn't matter in the end 🙂
@@_CryptoCat OH HOLY CRAP. I've been pulling my frickin hair out the past two days trying to figure out what the hell I was doing wrong 😅 Thank you thank you thank you for saying which version of libc this damn thing is using!
@CryptoCat Couldn't get your 2nd version with pwntools to work with the correct libc.so.6, for some reason the second rop chain builds wrong and I dont know what I don't know. To get the correct libc.so.6 just type in the memory leak and the gadget in their online database; I tried to just use the values from their table but ended up needing to download the lib strings the /bin/sh\x00 address manually. Oh and $ pwntools template {bin} {dir}...
hi mate, the correct libc version for this challenge wasnt on the online database anymore as far as i could see.. ropmev2 challenge is the same libc version as well. downloading the libc library manually to find the offsets is a good way to do it, providing you know which libc version to download first 😁
@@_CryptoCat My apologies, I used this database: libc.rip/ I somehow had the impression they were affiliated. Cheers and thanks for the video, it helped me learn.
np 🥰 the elf.got.puts is the address of the puts() in the global offset table in the binary, so it will always be the same location. when you leak it, you are getting the address that it points to, i.e. the actual address that's been populated from the lib-c library (may be different each time due to aslr, lib-c versions etc). hope that makes sense.. sounded a bit confusing, even to me haha xD
@@vgxp560 A better way to say it; the elf.got.puts address we access with pwntools is the address in the binary which points to the real libc.gots location (once it's been populated). So when we print elf.got.puts, we print that address in the binary's GOT section. When we use ROP payload to call puts(got.puts) we are putting out the value *stored* at the address of gots.puts. Actually, not sure if that was clearer but oh well 😅
![ropmev2 [hard]: HackTheBox Pwn Challenge (ROP execve with syscalls)](http://i.ytimg.com/vi/G4AHIPGpniU/mqdefault.jpg)
![ropmev2 [hard]: HackTheBox Pwn Challenge (ROP execve with syscalls)](/img/tr.png)
about the old libc version on the server: you can find the address of system on the remote box using the leak and DynELF, but finding the /bin/sh string in there would probably involve lots of trial and error.
hey thanks for the tip! it seems like it would be quite a bit of extra hassle to find all the correct offsets without the lib-c DB 😩 i ran into similar problems when attempting ropmev2 but luckily it didn't matter in the end 🙂
@@_CryptoCat OH HOLY CRAP. I've been pulling my frickin hair out the past two days trying to figure out what the hell I was doing wrong 😅 Thank you thank you thank you for saying which version of libc this damn thing is using!
@@screamerchaotix5182 haha np! i lost some hair to this one as well if i recall 😂
you are a life saver!! Where can I send you some lunch money?
haha ty! they say there's no such thing as a free lunch.. but here it is 😉
@CryptoCat Couldn't get your 2nd version with pwntools to work with the correct libc.so.6, for some reason the second rop chain builds wrong and I dont know what I don't know. To get the correct libc.so.6 just type in the memory leak and the gadget in their online database; I tried to just use the values from their table but ended up needing to download the lib strings the /bin/sh\x00 address manually. Oh and $ pwntools template {bin} {dir}...
hi mate, the correct libc version for this challenge wasnt on the online database anymore as far as i could see.. ropmev2 challenge is the same libc version as well.
downloading the libc library manually to find the offsets is a good way to do it, providing you know which libc version to download first 😁
@@_CryptoCat My apologies, I used this database: libc.rip/ I somehow had the impression they were affiliated. Cheers and thanks for the video, it helped me learn.
oh nice i dont think ive seen that one before, will remember it if run into the issue again. thanks mate 😊
Can you tell me where to find the source of 'pwntools_template.py'?
Can't find in links you posted,
thank you!
of course! 😀 github.com/Crypto-Cat/CTF/blob/main/HTB/pwn/pwntools_template.py
@@_CryptoCat Link dosent work says 404
Thanks for the tutorial. May I ask please, what is the difference between the elf.got.puts value and the leaked got_puts ?
np 🥰 the elf.got.puts is the address of the puts() in the global offset table in the binary, so it will always be the same location. when you leak it, you are getting the address that it points to, i.e. the actual address that's been populated from the lib-c library (may be different each time due to aslr, lib-c versions etc). hope that makes sense.. sounded a bit confusing, even to me haha xD
@@_CryptoCat Ah, ok. Think I'm starting to get it now. Thanks!
@@vgxp560 A better way to say it; the elf.got.puts address we access with pwntools is the address in the binary which points to the real libc.gots location (once it's been populated).
So when we print elf.got.puts, we print that address in the binary's GOT section. When we use ROP payload to call puts(got.puts) we are putting out the value *stored* at the address of gots.puts.
Actually, not sure if that was clearer but oh well 😅
@@_CryptoCat That did clear it up a bit more. Your other videos are helping a lot too. Thanks again!
@@vgxp560 Awesome 🥰 Theres a great explanation here I forgot about as well on the differences between GOT and PLT.. and the GOT.PLT and PLT.GOT 😆