[NahamconCTF] Pwn Challenges (So Much Cache & Gopherflow Returns)


( بِسْمِ اللَّـهِ الرَّحْمَـٰنِ الرَّحِيمِ )
(إن أحسنت فمن الله، وإن أسأت فمن نفسي والشيطان)

Hoy, let's go through the challenges from NahamconCTF.

I wanna thank Mohamed (ixSly) for his support in this CTF.

1. So Much Cache (hard)

This one was easy and direct if we understand what it is doing we finish, let's start.

it gives us the ability to allocate places in memory, free it, and jump to a location that the binary chooses, if we can control this location it will be a simple "ret2win" (we have a win function to read the flag).

we can write in our allocation with size (input size * 3) if we create an allocation 8 we can write into the memory (8*3) size which will overflow and corrupt the next heap allocation metadata and that is what we need.

what we will do?
  1. create allocation with size "16" (you can do it with different size).
  2. fill this allocation with "(A* ((16*3)-1) )" the "-1" for the "0x0a" newline.
  3. choose "Prepare Jump" choice that will allocate memory with size "24" after our allocation.
  4. now choose to jump into the first location "1" It will try to jump to "
so what we have to do is to add the win address to the place that will jump to and replace the "A's", you can calculate it or just add unique values for each "8" bytes and check where the jump will be.

and that is it for this challenge, easy right?.

Solution script on GitHub.

2. Gopherflow Returns (hard)

this is my first exploit with a "go" binary and this post helped me understand what I have to do thanks to @Adel for sharing it with me.

our approach overflowing and get a crash fix it and go to the next crash until we control the rip after that we will build our ROP.

the binary security controls

lets use favorite char to fuzz "A's" and we get our first crash in function "slicebytetostring" and you can see that we controlled the arguments of it

check the main function in Ghidra to know what is the used functions

if we add a breakpoint on this function, re-run the binary in gdb and check before and after overflowing we will find the following

after overflow

before overflow

so we overwrite the "rcx" and if we fix it the crash will disappear and that what happen but we didn't finish all crashes yet i did the same with the following 2 crashes

memmove crash

bufio crash1

bufio crash2

just i added a breakpoint on each instruction that crashed and got the right value, added it to my payload, and send it.

After fixing all crashes it's time for more padding to control the RIP and I got it.

and our "0xdeadbeef" is the new RIP

I used "ropper" to create the "ropchain" but it was not that good and I edited it a lot to fit my case, finally i got a running ropchain that will push "bin/sh" to memory and use it with syscall "execve".

ropper ropchain

modified ropchain

running it we got a call for our "execve" with a shell, note that you have to set the "envp" to zero to make the syscall work it took time for me to note this issue "ropper will not do that" and the arrangement of gadgets is important because some gadgets corrupt others.

Solution script on GitHub.

That's it 😉,
Thank you.

عن عبد الله بن عمرو قال: قال رسول الله صلى الله عليه وسلم: من صمت نجا. رواه الترمذي وأحمد.


Popular posts from this blog

Exploit & Debug Looney Tunables CVE-2023-4911 Local Privilege Escalation in the glibc's ld.so

Lets Analysis STM32F103 Chip Firmware from Attify

[Debug/Exploit CVE-2022-24355] TP-Link TL-WR940N Stack-based Buffer Overflow