file-run2 picoCTF 2022 Solution

Description

1. Step 1

   Read the prompt carefully

   Observation

   I noticed the challenge description explicitly stated the required argument (Hello!), which suggested the only obstacle was passing it correctly to the binary without the shell misinterpreting the exclamation mark.

   The description literally tells you to pass Hello!. Without the argument the program just prompts you again.

   What didn't work first

   Tried: Running ./run Hello! in bash and getting an unexpected error or wrong-argument message.

   Bash treats ! as a history expansion character in interactive shells, so Hello! can silently expand to something else before the program ever sees it. Single-quoting the argument as ./run 'Hello!' prevents the shell from interpreting the exclamation mark.

   Tried: Running ./run with no arguments and waiting for the program to prompt for input.

   Command-line arguments are not the same as standard input. The program reads from argv[1] at startup, not from stdin, so typing at the prompt does nothing. The argument must be passed on the same line as the binary name.

   Learn more

   Command-line arguments are values passed to a program at launch, available inside the program via the argc / argv array in C, or sys.argv in Python. They are separate from environment variables and standard input - three distinct ways a program receives data from its caller.

   A binary that compares argv[1] against a fixed string is a basic form of input gating. Identifying what argument it wants is the same problem as the bbbbloat magic-constant challenge, just with a string instead of an integer.

   Worked ltrace example. Even with a wrong guess, ltrace leaks the expected string:

   $ ltrace ./run hello
   __libc_start_main(0x401136, 2, 0x7ffc..., 0x401200 <unfinished ...>
   strcmp("hello", "Hello!")        = -1
   puts("Wrong argument!")          = 16
   +++ exited (status 1) +++

   The second argument to strcmp is the expected value. That single line solves the challenge.

   The exclamation mark only matters in interactive shells. Bash (and zsh in some configurations) treats ! as history expansion when reading commands typed at the prompt - so ./run Hello! can become ./run HelloFOO if your history matches. The fix is single-quoting: ./run 'Hello!'. Inside scripts, in pipelines, in non-interactive shells (sh, dash), or when the command is not at a TTY prompt, history expansion is disabled and the unquoted form is fine.

   When the expected argument is unknown. Walk a recon ladder before reaching for the disassembler:

   1. strings run | head -40 - format strings, error messages, and the comparison constant itself often appear verbatim.
   2. ltrace ./run with no arg, or with a guess - hooks strcmp/strncmp/memcmp and prints both operands.
   3. ltrace ./run <guess> - if you suspect the argument value but want confirmation.
   4. strace -e trace=write ./run <guess> - shows what the program writes to stdout, including hint messages like "Wrong argument".
   5. Last resort: open in Ghidra, find main, read the comparison.

   Linux-side recon shortcuts are collected in Linux CLI for CTF.

2. Step 2

   Capture the flag

   Observation

   I noticed that the binary prints the flag embedded in a sentence, which suggested piping the output through grep -oE 'picoCTF\{[^}]+\}' to extract just the flag token reliably rather than copying it by hand.

   Use cut to isolate the fourth space-delimited field for a clean flag string.

   What didn't work first

   Tried: Manually copying the flag text from the terminal output by hand.

   This works for a single challenge but is error-prone with long flag strings that contain similar-looking characters. Piping to grep -oE 'picoCTF\{[^}]+\}' extracts just the flag token reliably and is faster when automating multiple challenges.

   Tried: Using cut -d ' ' -f4 and getting an empty or wrong field because the output sentence has a different word count.

   The field number passed to cut depends on the exact wording of the program's output line. If the output changes, the field index shifts. Using grep -oE 'picoCTF\{[^}]+\}' instead extracts the flag by pattern rather than position, making it robust to any surrounding text.

   Learn more

   Output parsing with shell tools like cut, awk, and grep is a fundamental skill for working efficiently in the terminal. Rather than reading the entire output and copying the flag by hand, piping to cut -d ' ' -f4 extracts precisely the token you need, which is useful when automating or when the flag is embedded in a longer sentence.

   As an alternative, awk '{print $4}' achieves the same result and handles variable amounts of whitespace between fields (unlike cut, which treats each delimiter character separately). Knowing both gives you flexibility depending on the structure of the output you're parsing.

   Shell pipelines chain commands so the output of one becomes the input of the next. This composability is one of the defining strengths of Unix-style tooling. Instead of writing a custom script to parse program output, you string together small, single-purpose utilities. The same pipeline pattern appears constantly in security work: capturing output from a scanner, filtering it for relevant entries, extracting fields, and writing results to a file - all in a single one-liner.

   tr, sort, uniq, and wc are other commonly paired tools. For example, strings binary | sort | uniq -c | sort -rn produces a frequency-ranked list of all printable strings in a binary, which can highlight repeated constants or likely passwords. Building fluency with pipeline composition will save significant time during time-pressured CTF events.

Flag

Introductory warm-up for command-line arguments.