Quizploit picoCTF 2026 Solution

Description

1. Step 1

   Read the source code thoroughly

   Observation

   I noticed the quiz poses 13 specific questions about buffer sizes, function names, and constants that are only verifiable in the source, which suggested a careful, checklist-driven read of vuln.c was the essential first step before touching any tools.

   The 13 prompts test binary analysis skills: architecture, linking type, stripped status, buffer and read sizes, whether a buffer overflow exists, the C function that causes it, the name of the never-called function, the overflow byte count, which protection is enabled (NX), the technique to bypass it (ROP), and the address of the win() function. Most answers come from running file, checksec, and objdump/nm on the binary; the C source confirms the buffer and read sizes.

   bash

   cat vuln.c

   Copied!

   What didn't work first

   Tried: Skip reading vuln.c and jump straight to running checksec and objdump on the binary to answer every question.

   Binary tools reveal architecture, protections, and symbol addresses but cannot tell you the exact C buffer sizes or the name of the never-called function without also reading the source. The quiz asks for values like the fgets size argument in decimal, which objdump shows as a hex immediate - you still need vuln.c to confirm the mapping. Starting with tools alone causes wrong answers on source-level questions.

   Tried: Use grep with a broad pattern like 'grep buf vuln.c' hoping to find all relevant values at once.

   A bare 'buf' match returns every line containing the substring including comments, format strings, and unrelated variable names, making it easy to misread which buffer belongs to which function. The overflow question asks specifically about the buffer in the vulnerable function, not a global or unrelated stack frame. Scoping the grep to the function body (or using grep -A lines for context) avoids picking the wrong size.

   Learn more

   Run a checklist while reading vuln.c:

   • Function signatures: name, return type, argument count, argument types. Number them in order of definition.
   • Global and stack buffer sizes: every char buf[N], int arr[M], every malloc(SIZE).
   • Constants and macros: #defines, const ints, sentinel values. Note the literal value, not the symbol.
   • String literals: prompts, error messages, format strings. The wording may match a quiz question verbatim.
   • Loop bounds and conditions: for (i = 0; i < N; i++) - is the comparison < or <=?

   grep -n '#define\\|^[a-z].*(\\|buf\\[' vuln.c finds most of the question targets in one pass. Linux CLI for CTF covers the broader text-search toolkit; if the binary itself were the only source, Ghidra for reversing would replace this read.

   The reading habit pays compounding returns. Auditors who pull the same checklist on real code spot signed-vs-unsigned comparisons, off-by-one bounds, format-string sinks, and command-injection paths in production binaries.

2. Step 2

   Answer all 13 questions about the binary

   Observation

   I noticed the questions cover both source-level facts (exact fgets size argument, buffer declarations) and binary-level properties (architecture, stripped status, NX protection, win function address), which suggested running file, checksec, and objdump alongside reading vuln.c to gather every required value before connecting to the server.

   Connect with netcat and answer each prompt. The questions are about the binary's properties: architecture (64-bit), stripped status, buffer sizes, function names, vulnerability type, overflow size, protections enabled, and win function address.

   bash

   nc <HOST> <PORT_FROM_INSTANCE>

   Copied!

   bash

   # Typical answers include:

   Copied!

   bash

   # - Architecture: '64 bits' or '64-bit'

   Copied!

   bash

   # - Is it stripped: 'not stripped'

   Copied!

   bash

   # - Buffer size from vuln function: look at the sub esp/rsp instruction

   Copied!

   bash

   # - How many bytes read: look at the fgets/read size argument (e.g. 0x90)

   Copied!

   bash

   # - Is there a buffer overflow: 'yes'

   Copied!

   bash

   # - Standard C function causing overflow: 'fgets'

   Copied!

   bash

   # - Function not called anywhere: 'win'

   Copied!

   bash

   # - Type of attack: 'buffer overflow'

   Copied!

   bash

   # - Overflow bytes possible: 0x90 - 0x15 = decimal answer

   Copied!

   bash

   # - What protection is enabled: run 'checksec vuln' first

   Copied!

   bash

   # - Exploitation technique for NX: 'ROP' (return-oriented programming)

   Copied!

   bash

   # - Address of win: from objdump or pwntools ELF

   Copied!

   bash

   file vuln

   Copied!

   bash

   checksec --file=vuln

   Copied!

   bash

   objdump -d vuln | grep '<win>'

   Copied!

   python

   python3 -c "from pwn import *; e=ELF('./vuln'); print(hex(e.sym['win']))"

   Copied!

   Expected output

   picoCTF{my_b1n4ry_3xpl01t_...}

   What didn't work first

   Tried: Answer the overflow byte count question using the raw hex read size (e.g. 0x90) instead of converting to decimal and subtracting the buffer size.

   The quiz expects the number of bytes by which the read exceeds the buffer, expressed in decimal. Submitting the hex read size directly (144) or the buffer size alone both produce wrong answers. The correct value is read_size_decimal minus buffer_size_decimal, and the quiz prompt wording usually makes clear it wants the overflow delta, not the total read amount.

   Tried: Run 'nm vuln' instead of 'objdump -d vuln | grep win' to find the win function address.

   nm lists symbol addresses in a different format and may show multiple entries (PLT stub, actual function) causing confusion about which address to submit. objdump -d with grep on the label name '<win>' gives the exact virtual address from the disassembly header, which matches what the quiz expects. pwntools ELF e.sym['win'] is the most reliable method as it reads the ELF symbol table directly and prints the canonical address.

   Learn more

   Quiz-style challenges that test code comprehension are a clever teaching tool: they ensure you actually read and understand the provided source rather than jumping straight to tools. In real security work, understanding what code does before trying to exploit it saves enormous time and prevents wasted effort on the wrong attack vector.

   When answering questions about buffer sizes in C, remember that arrays are zero-indexed and char buf[64] holds exactly 64 bytes including the null terminator. Function counts, loop bounds, and constant values are all best found with a text editor's search function rather than reading line by line. grep -n "function_name\|CONST_NAME\|buf\[" vuln.c quickly locates relevant lines.

   If you get a question wrong and the program exits, reconnect and try again - there is no lockout. Taking notes while reading (writing down buffer sizes, function names, and key constants) speeds up subsequent attempts and is good practice for systematic code review.

3. Step 3

   Receive the flag

   Observation

   I noticed the server only prints the flag once all 13 answers are accepted in sequence, which meant the final step was simply reconnecting after compiling correct answers and collecting the output.

   After answering all questions correctly, the server prints the flag. If you get one wrong, restart and try again - re-read vuln.c for the exact values.

   Learn more

   The name "Quizploit" is a play on "exploit" - the challenge is exploiting your ability to read and understand source code rather than exploiting a software vulnerability. This is a meta-commentary on the fact that code comprehension is prerequisite to exploitation: you can't exploit what you don't understand.

   This type of challenge builds the foundational skill needed for more advanced binary exploitation: understanding how the compiler lays out stack frames, how C handles strings and arrays, and how program structure (function calls, loops, conditionals) relates to assembly-level behavior. Answering "what is the buffer size in main?" is practice for answering "what is the overflow offset?" in a real pwn challenge.

   A practical tip: connect the challenge binary with ltrace or strace to see what library calls and system calls it makes - this sometimes reveals expected answers as arguments to strcmp() or strncmp() calls without reading the source at all. But reading the source is the intended and more educational approach.

Flag

Answer 13 binary analysis questions: architecture, stripped status, buffer sizes, function names, overflow size, protections (NX), exploitation technique (ROP), and win function address.