After this lesson, you will be able to: Perform static analysis with file, strings, and hexdump, and understand the PE (Windows) and ELF (Linux) executable formats.
Static analysis examines a binary without running it, the safe first step. This lesson covers quick triage tools (file, strings, hexdump), and the structure of the two main executable formats: PE for Windows and ELF for Linux.
Before disassembly, a few tools tell you a lot fast. file identifies what a binary actually is (architecture, format, whether it is packed). strings extracts human-readable text, often revealing URLs, file paths, error messages, registry keys, or even hints about behavior. hexdump (or xxd) shows raw bytes, useful for spotting magic numbers and embedded data. These cost seconds and frequently answer 'what is this and roughly what does it touch' before any deep analysis.
Portable Executable is the format for Windows .exe and .dll files. Key parts: the headers (which describe the file and where things live), sections (.text for code, .data for data, .rsrc for resources), the import table (which external functions/DLLs it calls, a huge behavioral hint), and the export table (functions it provides). Reading the imports of a PE often reveals capability: networking, file manipulation, crypto, process injection.
Executable and Linkable Format is the Linux/Unix counterpart. It has an ELF header, program headers (how to load it into memory), and section headers (.text, .data, .symtab, and so on). Like PE imports, ELF's dynamic symbol table and linked libraries hint at behavior. Understanding both formats means you can orient yourself in a binary on either platform before disassembling.
Use any benign program (e.g. a small open-source utility), never malware.
1. Run file on the binary and note the format and architecture (PE/ELF, 32/64-bit).
2. Run strings and skim for URLs, paths, messages, and library names.
3. Inspect the headers/imports: on Linux use readelf -a or objdump; for PE use a PE viewer.
4. From the imports/strings alone, write a hypothesis of what the program does.
5. You will confirm or revise that hypothesis with Ghidra in the next lesson.
Pick the best answer.
Skipping triage and jumping straight to disassembly (strings often answers the question). Trusting strings from a packed/obfuscated binary (they may be hidden until runtime). Running the binary 'just to see' on a real machine. Ignoring the import table. Confusing PE and ELF tooling. Forgetting that static analysis alone misses behavior that only appears at runtime, which is why dynamic analysis follows.
Sign in and purchase access to unlock this lesson.