although this event i can only finished 1 one challenge but i learnt a lot from others writeup. It’s make me feel that I only have the width not the depth in exploiting. Now I need to reflect meself about what i’ve been doing right now. That’s some random shit I want to express. Let’s just dive into the game

###Dangerous

this is the eziest one (and the only one I solved :< ) so i won’t talk much about those

###SaaS

in this challenge i’m stuck at what should I do when I only know open, read, write flag and I don’t think much about the alternative way. Now thinking back I felt too bad :<

why we can’t open, read, write?

as you can see the binary pass into the syscall hex value, instead of “flag.txt” so there’s no way we can do the normal way. there’s alot of alternative way to write out the flag, in this writeup i’m using h4ck3rb0b writeup to help meself understand more

we’re gonna using the following syscalls:

  • the brk() syscall help us allocate the heap memory, we need it to create space to write() our flag
  • the arch_prctl() let you set the FS and GS segment registers x86_64 linux systems. long story short this function gonna let us write 4 bytes to where you point to.
  • the openat() is the same as open() but it’s will return fd if you provide dirfd(which is AT_FDCWD) and relative pathname (which is the one we wrote by arch_prctl())

that’s it! now let’s create the wrapper to send our data

and another one is for using arch_prctl()

use this to find the correct value of ARCH_SET_GS , ARCH_GET_GS , AT_FDCWD

  • we need to brk(0) to get the heap base
  • extend the length of the heap brk(0x1000)
  • write ‘flag.txt’ to heap by using the wrapper above
  • pop openat to get the dirfd for read(), write()

first is heap base and extend the heap

2nd is write flag to heap

3rd is fd

finally using the fd you received from openat we can have our flag

###shift-ahoy

the binary got bof at encrypt function. With no mitigation we can just send shellcode to the stack, but before that there’s a couple things to notice

you can see that the mov r15, rsp gadget set the stack address, if we pad our payload (shellcode + rubbish) = offset(0x58)then the r15 will point to shellcode. Now we have the stack address pointed to our shell, we just need to find a gadget that’s gonna call r15.

great, our gadget is 0x4011cd now we just pad it to the ret address and then the program gonna trigger our shell.

###syrup

then again this challenge got bof, but it’s only have 3 function, this one i really exciting when i saw the solution of WreckTheLine

take a quick look through the 3 function

as you can see there’s a bof at offset 0x400, and then the binary create a cookie check 0xdead^0xbeef if there’s something happen to the cookie, the control flow jump to nope, so to bypass it we just need p64(0xdead^0xbeef)*2 after the padding (*2 because of pop rbp). Now what should we do next? without any mitigation, we need to send our shell to where it writable and excutable

so i’m gonna use 0x402000 to store our shell. But how can we write it? notice the read syscall at fn1 function

notice the mov rsi, rbp , which is *buf, if we can change the value of rbp to point to 0x402000 then it will read input to 0x402000 .

fortunately, there’s a gadget that can solve this problem

adding to the previous payload, now we have

offset + p64(0xdead^0xbeef)*2 + p64(0x401080) + p64(0x402000)

ofc, that’s not enough to trigger the shell, as you notice, we need to add another cookie bypass and then point back to 0x402000

so our final payload is

and then send the shell

a loner