Static ain't always noise picoCTF 2021 Solution

Description

1. Step 1Run ltdis.sh on the binary

   Observation

   The challenge provides two downloads: a binary called static and a shell script called ltdis.sh. The script exists to extract readable data from that binary, so run it first.

   ltdis.sh runs strings -o static (or similar) on the binary and saves output to a .strings.txt file alongside it. Run it, then list the generated text files to find the output filename.

   bash

   bash ltdis.sh static

   Copied!

   bash

   ls *.txt

   Copied!

   Expected output

   picoCTF{d15a5m_t34s3r_...}

   What didn't work first

   Tried: Run strings directly on the binary without ltdis.sh and print to the terminal.

   Running strings on the binary prints thousands of lines to stdout and writes no file. You can pipe that into grep, but ltdis.sh exists to save the output to static.ltdis.strings.txt for repeat inspection. Skip the script and you lose that file, along with the intended workflow for finding the flag's offset.

   Tried: Run bash ltdis.sh without making it executable first.

   Invoke the script as ./ltdis.sh and the shell returns permission denied, because the download does not carry the execute bit. Either run it through bash directly, or chmod +x it first.

   Learn more

   The strings utility scans any binary file and extracts sequences of printable ASCII characters above a minimum length (default 4). This works because compiled programs often contain embedded text: error messages, URLs, version strings, author credits, and - in CTFs - flags. Even without source code, strings is one of the first tools any reverse engineer runs on an unknown binary.

   Shell scripts as wrappers: ltdis.sh is a bash script that wraps strings with specific options and redirects output to a predictably named file. Writing wrapper scripts around existing tools is a common Unix practice - it standardizes arguments, captures output for later analysis, and makes workflows repeatable. The name "ltdis" likely stands for "light disassembly" or similar.

   Static vs. dynamic analysis: The challenge title "Static Ain't Always Noise" plays on two meanings of "static." In reverse engineering, static analysis means examining a binary without executing it - reading its bytes, running strings, disassembling with objdump, or decompiling with Ghidra. Dynamic analysis means running the program and observing its behavior. Both are complementary and important skills.

2. Step 2Search for the flag

   Observation

   ltdis.sh writes the extracted strings to static.ltdis.strings.txt, which runs to thousands of lines. Grepping for the picoCTF{ prefix pulls the flag out of all that binary metadata in one step.

   Grep the output file for the picoCTF prefix. If nothing matches, lower the strings minimum length (default is 4) - the flag may be a short word in a longer transformation. Filter to lines starting with picoCTF{ if multiple matches appear.

   bash

   grep '^picoCTF{' static.ltdis.strings.txt

   Copied!

   bash

   # If no matches, re-run strings with a smaller minimum length:

   Copied!

   bash

   strings -n 3 static | grep -i pico

   Copied!

   What didn't work first

   Tried: Grep the binary file directly instead of the generated text file.

   Grepping the raw binary gives garbled output, because grep walks the bytes without the length filtering and offset alignment strings provides. The flag bytes are in the file but wrapped in nulls and non-printable characters, so the match either renders badly or triggers grep's binary-file-matches message with no text at all. Grep the strings output file, not the binary.

   Tried: Search for 'pico' case-sensitively and miss the flag.

   The prefix picoCTF{ has a capital C and T, so grepping for 'pico' matches while 'PICO' or 'PicoCTF' will not. The more common miss is anchoring with ^pico: the strings output puts an offset column at the start of each line, so the line never begins with 'pico'. Drop the caret anchor, or strip the offset column first.

   Learn more

   grep (Global Regular Expression Print) searches text for lines matching a pattern. It's an indispensable Unix tool for filtering large outputs. In CTF work, grepping for known patterns like picoCTF, flag, or FLAG quickly filters thousands of lines of binary output down to the one line you care about.

   A compiled binary can easily contain thousands of strings - library function names, debug symbols, format strings, linker metadata, and more. Without grep, manually scanning static.ltdis.strings.txt would take minutes. With it, the search takes milliseconds. Useful grep flags for CTF work:

   • -i - case-insensitive search (matches picoctf, PICOCTF, etc.)
   • -n - show line numbers so you can find context in the file
   • -A 2 -B 2 - show 2 lines of context around each match
   • -r - recurse into directories (useful when output is split across files)

   Why flags appear in binaries: Flag-checking programs typically compare user input against a stored value. The simplest approach stores the flag as a literal string, making it trivially extractable with strings. More sophisticated challenges encode, encrypt, or generate the flag at runtime to prevent this - but even then, static analysis often reveals key clues.

Flag

ltdis.sh runs strings on the binary and saves output; the flag is embedded as a plaintext string.