strings it picoCTF 2019 Solution

Published: April 2, 2026

Description

Can you find the flag in file without running it?

Download the binary named 'strings' from the challenge page.

Solution

Want to try it yourself first?

The guided walkthrough reveals hints one step at a time.

Walk me through it
  1. Step 1
    Extract printable strings and grep for the flag
    Observation
    I noticed the challenge title is literally 'strings' and the task asks to find the flag without running the binary, which suggested that the strings utility would extract hardcoded text from the binary's data section, and piping its output through grep with the 'picoCTF' prefix would isolate the flag immediately.
    The strings utility scans any file and prints sequences of consecutive printable characters (default minimum length: 4). Piping the output through grep narrows it to the flag line immediately.
    bash
    strings strings | grep picoCTF

    Expected output

    picoCTF{...}
    What didn't work first

    Tried: Run the binary directly to see if it prints the flag.

    Executing an untrusted binary from a CTF challenge is risky and unnecessary here. The challenge explicitly asks you to find the flag without running it. The strings utility extracts embedded text from the raw bytes without executing any code, which is both safer and sufficient for a hardcoded flag.

    Tried: Run strings without piping to grep and scan the output manually.

    A typical ELF binary produces hundreds or thousands of string fragments - library names, error messages, compiler metadata, and section labels - making it impractical to spot the flag by eye. Piping to grep with the known prefix (picoCTF) filters the output to exactly the lines that match, so the flag appears immediately rather than being buried in noise.

    Learn more

    The strings command scans any binary file - executables, object files, firmware images, documents - and prints every sequence of consecutive printable ASCII characters that meets a minimum length threshold (default: 4 characters). It works by reading raw bytes and outputting runs of printable characters followed by a null byte or non-printable byte.

    This is powerful for reverse engineering because compiled programs still contain their string literals in plain form in the binary. Error messages, hardcoded URLs, passwords, flag values, and format strings all appear verbatim in the binary's data section. Running strings on an unknown binary is often the very first step in any CTF binary challenge or malware analysis session.

    Useful strings flags to know:

    • -n 8 - raise minimum length to 8 (reduces noise)
    • -e l - scan for 16-bit little-endian strings (Windows executables)
    • -t x - print the file offset (in hex) of each string
    • -a - scan the entire file, not just loadable sections

    In real-world malware analysis, strings quickly reveals C2 (command-and-control) server hostnames, mutex names, registry keys, and embedded commands. Security tools like FLOSS (FireEye Labs Obfuscated String Solver) extend the concept to also decode obfuscated and dynamically constructed strings that simple strings would miss.

    Where strings live in an ELF binary: compiled C and C++ programs store string literals in the .rodata (read-only data) section or the .data section of the binary. Error messages, help text, version strings, and format strings for printf all end up there verbatim. The strings command does not parse the binary format - it simply scans raw bytes - so it finds text in every section including the stack, BSS, and even the ELF headers themselves.

    Limitations of the strings approach: sophisticated malware and obfuscated binaries can evade strings by XOR-encoding their string constants and decoding them only at runtime. In such cases, the binary will contain no readable C2 addresses or obvious indicators - just garbage bytes. This is why dynamic analysis (running the binary in a sandbox and observing its network traffic and system calls) complements static analysis. Tools like Ghidra, IDA Pro, and Binary Ninja can identify decryption routines and recover the decoded strings through emulation or code analysis.

    Combining strings with other tools multiplies its value. Piping to sort -u deduplicates repeated strings. Piping to wc -l gives a quick count of how many strings were found. Using strings -t x file and then navigating to those offsets in a hex editor (like xxd or hexedit) lets you examine what surrounds each string - sometimes the context bytes reveal the purpose of a string even when the string itself is ambiguous. In CTF competitions, always run strings as one of the first steps on any unknown binary challenge file before attempting disassembly.

Interactive tools
  • Strings ExtractorPull printable text from any binary, library, or image. ASCII and UTF-16 detection, configurable minimum length, flag-like highlight, no command line needed.

Flag

Reveal flag

picoCTF{5tRIng5_1T_...}

The strings utility finds sequences of printable characters in any binary - flags and other secrets embedded in executables are often immediately visible.

Key takeaway

Compiled binaries retain their string literals verbatim in the data section because the compiler has no reason to obscure them. Hardcoded credentials, API keys, internal URLs, and flags all survive compilation and are recoverable without executing the program or disassembling a single instruction. This is why security guidance prohibits hardcoding secrets in source code, and why static analysis tools and secret-scanning CI checks are standard practice in secure development pipelines.

Related reading

Want more picoCTF 2019 writeups?

Useful tools for General Skills

What to try next