Binary Exploit

PWN: bop I didn’t get to solve this by my own but there were many interesting things that I wasn’t aware of that can be used to solve this challenge. However, I wanted to talk about a few things I got to know during the struggle of working on this challenge. ret2dlresovle References: https://syst3mfailure.io/ret2dl_resolve https://ir0nstone.gitbook.io/notes/types/stack/ret2dlresolve When a binary uses the shared libraries by dynamically linking to them, they do not have (or know) all the addresses for those library functions as the program starts up. They would resolve this issue (finding the addresses of those functions) when the functions are actually called. And the trick in this technique is to force the dynamic linker to resolve (or relocate) all the addresses of the library functions as the program starts. The pwntools python library allows us to choose the functions of our choice and and use them as their addresses were already resolved. ...

References 1: https://mregraoncyber.com/picoctf-writeup-guessing-game-1/ 2: https://github.com/dannyc-dev/Building-the-ROP-Chain 3: https://cyb3rwhitesnake.medium.com/picoctf-guessing-game-1-pwn-bdc1c87016f9 Investigation file ./vuln vuln: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=94924855c14a01a7b5b38d9ed368fba31dfd4f60, not stripped This tells us that this executable contains all the libraries so we will be able to find a lot of gadgets if we have to find some. Checksec result Arch: amd64-64-little RELRO: Partial RELRO Stack: Canary found NX: NX enabled PIE: No PIE (0x400000) PIE is disabled and NX is enabled so we won’t be able to execute anything by putting things onto the stack. We will need to do some ROP. ...

References https://git.mbund.org/mbund/buckeyectf-2022/src/branch/main/writeups/ronin/ronin.md Decompiled code After decompiling the binary, I was able to take a look at those major funtions that make up this program. main(): int __cdecl main(int argc, const char **argv, const char **envp) { char shellcode_buffer[80]; // [rsp+0h] [rbp-50h] BYREF setvbuf(_bss_start, 0LL, 2, 0LL); scroll(txt); fgets(shellcode_buffer, 80, stdin); if ( !strncmp("Chase after it.", shellcode_buffer, 15uLL) ) { scroll(off_4028); chase(); } scroll(off_4030); return 0; } scroll(): ize_t __fastcall scroll(const char *addr_to_some_buffer) { __useconds_t v1; // eax size_t result; // rax char single_char; // [rsp+1Fh] [rbp-11h] size_t v4; // [rsp+20h] [rbp-10h] size_t i; // [rsp+28h] [rbp-8h] v4 = strlen(addr_to_some_buffer); for ( i = 0LL; ; ++i ) { result = i; if ( i >= v4 ) break; single_char = addr_to_some_buffer[i]; // printing a single char from the string array putchar(single_char); if ( single_char == 10 ) v1 = 1000000; else v1 = 50000; usleep(v1); } return result; } encounter(): ...

BuckeyeCTF 2022 - pwn: samurai What I didn’t understand was the program inserts ./n which can be represented as 0x2ea. This is just a part of the string that it gets printed out to STDOUT. How this program works is it reads in some input from STDIN using fgets. fgets inserts a newline char after reading everything in (EOF or newline). But, if the input that I pass in to overflow the buffer that does not end with a newline char, then it will keep going (or being read) until it overflows the variable I want to overwrite. It can still work but there is this line of code strcpy(&s[strlen(s) - 1], ".\n"); that puts a new line character at strlen(s) - 1. So, when I was naively giving an input that I would think should overwrite the variable, the last bit was always replaced by 2ea which is .\n. AH!!!!!!!!!!!! So, what we would want to do is at least have a newline char in the middle of the string so strcpy does not insert that .\n where the last bit is (this bit is still needed to be overwritten with some value to make the attack happen). ...

Description AUTHOR: MADSTACKS Description: I am once again asking for you to pwn this binary vuln libc.so.6 Makefile nc mercury.picoctf.net 1774 Hints: PWNTools has a lot of useful features for getting offsets. References https://faraz.faith/2019-10-12-picoctf-2019-heap-challs/ https://gitlab.com/WhatTheFuzz-CTFs/ctfs/-/tree/main/picoCTF/binary-exploitation/heres-a-libc https://ctf101.org/binary-exploitation/relocation-read-only/ https://heartburn.dev/picoctf-2021-binary-exploitation/#here-s-a-libc My Approach In challenges like this one, you are given an executable, a libc library, and a Makefile to work with. And the first thing I do is to find some information about the executable file. ...

Description While being super relevant with my meme references, I wrote a program to see how much you understand heap allocations. nc mercury.picoctf.net 31153 heapedit Makefile libc.so.6 Hints: It may be helpful to read a little bit on GLIBC’s tcache. My Approach Until this point, I had not done any binary exploits that are related to the heap. And this challenge gave me a better understanding of heap allocation/deallocation and how one can try to exploit the glibc heap. ...