How Programs Work

Module 57 lessons · 2 labsAbout 10 hoursLab included

Programming Foundations taught us to read source code and reason about the behavior its author described. That is only one view of a program. A compiler can turn the source into an executable file, Linux can load that file into a process, and the processor can carry out machine instructions that look nothing like the original C.

Vulnerability research lives in the connections between those views. A length check in source becomes comparisons and branches. A local array occupies memory near other function state. A file on disk is divided into regions that Linux maps into a process. None of this is magic, although several layers have worked very hard to make it look that way.

Learning objectives

Module outcomes

• Distinguish source code, an executable file, and a running process.
• Explain what Linux contributes when it loads an executable.
• Identify the important parts of a Linux ELF file.
• Read a process memory map and connect mapped regions to their purpose.
• Explain machine instructions, registers, and addresses at a useful beginner level.
• Trace a C function call through arguments, local variables, the stack, and a return value.
• Contrast stack, heap, and static data without relying on misleading slogans.
• Recognize system calls as the boundary between a program and the Linux kernel.
• Use observed evidence to build a defensible model of an unfamiliar program.

Module sequence

1. From Executable to Process — Follow one executable file as Linux turns it into a running process.
2. Reading an ELF File — Inspect headers, sections, segments, symbols, and the entry point.
3. Virtual Memory and Process Maps — Learn what an address means inside a process and read /proc memory maps.
4. Executable Mapping Lab — Reconstruct how a supplied ELF file appears in memory and recover the first flag.
5. Machine Instructions and Registers — Connect simple C operations to x86-64 assembly and processor state.
6. Function Calls and the Stack — Trace arguments, local state, saved control flow, and returns.
7. The Heap and Data Lifetime — Follow dynamically allocated data and explain when it remains valid.
8. Programs Asking Linux for Help — Observe system calls for files, memory, and process termination.
9. Program Anatomy Lab — Investigate an unfamiliar executable and support each conclusion with evidence.

The module contains seven lessons and two labs. The labs appear where the required mental model becomes useful; there is no prize for hoarding all practical work until the end.

Prerequisites

Complete Linux Foundations and Programming Foundations first. In particular, you should be able to:

• navigate the filesystem and inspect files from the terminal;
• recognize a Linux process and record command output;
• read small Python and C programs;
• compile and run a C program;
• follow variables, conditions, loops, and functions;
• treat a crash or error message as evidence.

If one of those still feels shaky, revisit the relevant lesson. This module adds memory addresses, executable formats, and machine instructions. Quietly carrying an unresolved problem forward will not make the next layer friendlier.

The investigation pattern

For each target, we will move between four views:

View	Question
Source code	What behavior did the author describe?
Executable file	What did the toolchain place on disk?
Running process	What did Linux load, map, and manage?
Processor state	Which instructions and values exist right now?

No single view tells the complete story. The useful skill is connecting evidence across them without inventing details that the evidence did not establish.

Start with From Executable to Process.