REFERENCE GUIDE

Static analysis: strings, imports, and control-flow landmarks

Static analysis reconstructs behavior without running the program.

Also known as: decompilation triage

static-analysisreversing

Mechanism

Static analysis reconstructs behavior without running the program. Begin with structure rather than a complete decompilation: entry points, imports, strings, cross-references, and call graphs reveal likely input and validation paths. Decompiler output is an interpretation of machine code; ambiguous types and optimized expressions require confirmation in disassembly.

Practical method

Inspect headers, then identify input APIs and success or failure strings. Follow cross-references toward the comparison logic. Rename functions and variables according to observed behavior, recording uncertainty. Read the assembly for the decisive branch and trace where its operands originate.

strings -a -n 6 ./challenge
readelf -Ws ./challenge
objdump -d ./challenge

Interpreting evidence

A useful static result is a small dependency graph from input bytes to a decision. Annotate constants, loop bounds, and transformations so a later dynamic run can test that graph.

Pitfalls and limits

Unused strings and dead functions can mislead. Stripping symbols removes labels, not behavior. Inlining merges functions and changes apparent boundaries; do not infer original source structure from the decompiler alone.

Sources & further reading

  1. Ghidra documentation ↗ghidra
  2. objdump ↗binutils

Content license: CC-BY-4.0. Source-derived sections retain their cited licenses and redistribution notices. How this reference is compiled →