@Writeups_Archive
/October 22, 2025/
X Sixty What
Opening the provided vuln.c source code for this challenge we see that there is a vuln function which gets called by the main, we can deduce that all we gotta do is just change the flow of control from vuln to flag. Also as the code in flag follows, we create a flag.txt as a prereqesite. Running checksec on the given binary we get : [*] '.../x-sixty-what/vuln' Arch: amd64-64-little RELRO: Partial RELRO Stack: No canary found NX: NX enabled PIE: No PIE (0x400000) SHSTK: Enabled IBT: Enabled Stripped: No We can see no PIE enable....
/October 21, 2025/
Ropfu
When I first cracked open the source for ROPfu, I was greeted with almost nothing. The binary was basically a single gets() call. That’s already a giant red flag: gets() is one of the classic unsafe functions in C, and here it’s basically handing us a buffer overflow on a silver platter. Step 1: Finding the Offset Since the binary didn’t have any helper functions to directly leak flag.txt, the plan was clear: exploit the overflow and craft our own control flow....
/October 20, 2025/
Buffer Overflow 3
As usual, we are given compiled binary, its source and the host and port where challenge is hosted. This given challenge simulates a stack canary which we have to bypass. Well we could leak the canary code, but here we will take the bruteforce approach.First we need to create flag.txt with a flag and canary.txt file with 4 byte canary string. I chose the word CANA as the canary string for testing locally....
/October 19, 2025/
Buffer Overflow 2
This challenge was a classic example of how control flow can be hijacked when proper bounds checking is absent. Let’s break down the approach I used to solve it. Initial Analysis After making the binary executable and reviewing the source, I found that it contained three key functions: main() – program entry point. vuln() – the vulnerable function that relies on unsafe input. win() – the interesting one. It checks if two arguments equal 0xCAFEF00D and 0xF00DF00D....
/August 7, 2025/
Crackme100
link to the binary Started off with the usual recon — readelf revealed the presence of a main function. Dumped it into Ghidra and ran into a weird-looking keygen algorithm. After cleaning things up, the code looked like this: #include <stdio.h> #include <string.h> int main(void) { int addened; int adder; char input[51]; char output[51]; int random2; int random1; char fix; int secret3; int secret2; int secret1; strncpy(output,"mpknnphjngbhgzydttvkahppevhkmpwgdzxsykkokriepfnrdm",51); printf("Enter the secret password: "); scanf("%s", &input[51]); int len = strlen(output); for (int i = 0; i < 3; i++) { for (int j = 0; j < len; j++) { adder = (j % 0xff >> 1 & 0x55) + (j % 0xff & 0x55); adder = (adder >> 2 & 0x33U) + (adder & 0x33); int key = (adder >> 4) + (adder & 0xf); addened = (input[j] - 97) + key; //(convert alphabets to a index based position like 'a' -> 0, and adds the key ) input[j] = addened + (addened / 26) * -26; //Basically iVar2 % 26, even for negative values input[j] = input[j] + 'a'; //Converts the 0–25 range back to alphabets } } printf("%s\n", input); int chk = memcmp(input,output,(long)(int)len); if (chk == 0) { printf("SUCCESS!...
/August 7, 2025/
Bbbbloat
link to the binary This one’s similar to picoCTF’s packer, except it comes unpacked. Straightforward overall — standard binary reverse engineering flow gets the job done. readelf -a bbbbloat didn’t show anything unusual, just a large number of functions. strings also returned nothing revealing. Loading the binary into Ghidra showed an overwhelming number of functions. Digging into FUN_00101307, we see it takes input, stores it in local_48, and compares it to the hex value 0x86187....
/August 2, 2025/
Packer
packer picoCTF link This wasn’t my first time doing reverse engineering challenges, but it was my first rodeo with picoCTF. Pretty easy overall — I could’ve solved it with my own analysis toolkit (nyxelf), but I decided to use Ghidra this time for a change of pace. Running readelf -S out showed no symbol table, and the headers confirmed the binary was stripped. Given the name packer, I suspected it was packed....