strings

Overview

When you first receive an unknown binary in a reverse engineering challenge, the fastest and safest thing to do is look at the readable text embedded inside it. The classic tool for this is strings, which extracts sequences of printable characters from any file. It is often the very first step of triage — sometimes it even reveals the flag outright. This lesson explains how strings works and how to use it as a first-pass reconnaissance tool on binaries provided for authorized practice.

Learning objectives

• Explain what the strings tool does and how it decides what to print.
• Use strings as a first triage step on an unknown binary.
• Interpret common findings: messages, file paths, library names, and hints.
• Understand the limits of static string extraction.

Core concept

strings scans a file byte by byte and prints runs of printable characters that are at least a certain length (commonly four characters by default). Because compilation preserves literal text — error messages, prompts, file paths, format strings, embedded URLs, and the names of imported functions — a compiled program is full of readable fragments even though the code itself is machine instructions. Extracting these gives you an immediate, low-effort overview of what the program might do, without ever running it.

This is static inspection: you are reading the file, not executing it. That makes it both safe and fast, which is exactly why it comes first.

How it works

Conceptually, strings does the following:

1. Read the file's bytes in order.
2. Track consecutive bytes that fall in the printable range (letters, digits, punctuation, spaces).
3. When a run reaches the minimum length, remember it; when a non-printable byte breaks the run, output the collected string.

A typical invocation looks like:

strings suspicious_binary

You can narrow the results — for example, requiring longer runs to cut noise, or searching the output for keywords:

strings suspicious_binary | grep -i pass

What you commonly find in a binary's strings:

• User-facing messages — Enter password:, Access granted, Wrong!
• Format strings — %s, %d, and templates used for output.
• File paths and filenames — configuration paths, log locations.
• Library and function names — imported symbols hinting at behavior (e.g. networking or crypto calls).
• Embedded literals — sometimes even a hard-coded secret or flag left in for a beginner challenge.

Practical example

Suppose an authorized CTF gives you a small binary that asks for a password. Running strings on it might reveal, among other output:

Enter the password:
Access granted!
Access denied.
S3cr3t_P4ss

The presence of S3cr3t_P4ss right next to the success and failure messages is a strong hint that it is the value the program compares your input against. In an easy challenge, typing it in yields the flag. Even when the secret is not sitting in plain sight, the messages tell you the program's structure: it prompts, compares, and branches to a success or failure path — which guides the deeper analysis in later lessons.

Note that strings only shows literal text. If the password were computed or decoded at runtime rather than stored as plain text, it would not appear directly, and you would move on to other techniques.

Cybersecurity relevance

strings is a staple of real malware triage and file analysis. Analysts run it early to spot embedded URLs, command-and-control indicators, suspicious file paths, or telltale library usage — quick indicators that shape the rest of an investigation. Because it is purely static (no execution), it is safe to run even on samples you have not yet sandboxed. The same habit that finds a beginner CTF flag also surfaces indicators of compromise in incident response. It is a reminder to defenders, too: secrets embedded as literals in a binary are trivially recoverable and should never be relied on as a security control.

Common mistakes

• Skipping strings and jumping straight to a disassembler. You may waste time analyzing code when the answer was sitting in plain text.
• Assuming a found string is the answer. A literal like a password candidate is a hint; confirm how the program uses it.
• Forgetting that computed or encoded values will not appear. Absence of a string does not mean absence of the secret.
• Not filtering the output. Large binaries produce huge amounts of noise; pipe through grep or require longer runs.

Key takeaways

• strings extracts runs of printable characters from a file, exposing embedded literal text without running the program.
• It is the standard first triage step: fast, safe, and static.
• Common finds include prompts, error messages, file paths, imported function names, and sometimes hard-coded secrets.
• It only reveals literal text; computed or decoded values require deeper analysis, and hard-coded secrets are never a real security control.

Check your understanding

• Why is strings considered a safe first step even on an unknown or suspicious binary?
• If strings shows no obvious password but the program clearly checks one, what does that tell you about how the secret is handled?