Quizploit picoCTF 2026 Solution

Description

1. Step 1Read the source code thoroughly

   Observation

   The quiz asks 13 specific questions about buffer sizes, function names, and constants, all of which only the source settles. Read vuln.c carefully before touching a tool.

   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.

   The tools give architecture, protections, and symbol addresses, and they cannot give you the exact buffer sizes or the name of the never-called function. The quiz wants the fgets size in decimal, which objdump shows as a hex immediate. Tools alone produce wrong answers on the source-level questions.

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

   Grepping for a bare 'buf' matches comments, format strings, and unrelated variables, which makes it easy to attribute a buffer to the wrong function. The question is about the buffer in the vulnerable function, not a global or another frame. Scope the grep to that function body, or pull surrounding context.

   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 2Answer all 13 questions about the binary

   Observation

   Some questions are source-level, like the exact fgets size argument, and some are binary-level, like the architecture, the protections, and the win address. Run file, checksec, and objdump alongside the source read and gather everything before connecting.

   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_bIn@4y_3xpl0it_fL@g_...}

   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 wants how many bytes the read exceeds the buffer by, in decimal. The hex read size and the buffer size are both wrong on their own. Subtract one from the other; the prompt wording asks for the overflow, not the total read.

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

   nm formats addresses differently and may list several entries, a PLT stub and the real function, leaving you unsure which to submit. Grepping the label in objdump output gives the virtual address from the disassembly header, which is what the quiz wants. A pwntools symbol lookup is the most reliable, reading the symbol table directly.

   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 char buf[64] reserves exactly 64 bytes, so a C string stored in it can hold at most 63 characters plus 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 3Receive the flag

   Observation

   The server prints the flag only after all 13 answers are accepted in sequence, so the last step is reconnecting with the answers ready.

   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.