Strings & Symbols

What strings actually does

The classic tool walks the file byte by byte and emits any run of at least four printable characters terminated by a non-printable byte. It is not parsing anything — no ELF structure is involved, so it works identically on a firmware image, a JPEG or a core dump. That is also its weakness: on a stripped Go or Rust binary you get enormous amounts of noise, and the useful signal (a build path, a hardcoded URL, an API hostname) is buried in it.

This implementation streams the file in 4 MiB chunks rather than reading it whole, so a multi-gigabyte core dump does not exhaust the tab's memory. Runs that straddle a chunk boundary are carried over instead of being silently truncated. The filter is applied as strings are found, not afterwards, which is what makes searching a large binary feel instant.

Symbol names are a different question

When you switch to symbol mode the tool takes a completely different path: it parses the ELF section headers, finds .symtab and .dynsym, and resolves names through the linked string table. This is the same data readelf -s prints, and unlike strings it tells you something structural: which symbols are exported (GLOBAL in .dynsym), which are local, and whether the binary was stripped at all.

A stripped release build has no .symtab, so symbol mode returns only the dynamic symbols — the ones the loader needs, typically a few dozen for an executable and a few thousand for a shared library. Absence of local symbols is normal and is not a sign of obfuscation; presence of no dynamic symbols on a dynamically linked executable is the unusual case worth investigating.