How Programs Work

Module 57 lessons · 1 labAbout 10¾ hoursModule overview

Programming Foundations taught us to read source code and reason about the behavior its author was describing. That’s one view of a program; it doesn’t show us the instructions a particular build produced. A compiler turns that source into an executable file, Linux loads the file into a process, and the processor then carries out machine instructions looking nothing whatsoever like the original C.

Understanding program execution means connecting those views. A length check in the source becomes comparisons and branches. An address belongs to a running process, not just a line in a source file. A file on disk supplies regions that Linux maps into memory. We need to know which view can answer the question we’re asking.

That connection will matter in the next module, Debugging Foundations, when we pause these small programs and inspect their state. A register value or memory address is useful evidence only if you understand what it represents. Here we’ll build that model with source we can read; then we’ll test it against live execution before moving on to security-focused investigation in the next course.

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 the headers, sections, segments, symbols, and entry point.
3. Virtual Memory and Process Maps. Work out 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 check the segment count and entry point.
5. Machine Instructions and Registers. Connect simple C operations to x86-64 assembly and to 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’s still valid.
8. Programs Asking Linux for Help. Watch system calls for files, memory, and process termination.

After this module, continue to Debugging Foundations. The Program Investigation Capstone follows debugging and combines both modules’ tools in one investigation.

Prerequisites

Finish Linux Foundations and Programming Foundations first. You should be able to do all of the following:

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

If any of those still feels shaky, go back to the relevant lesson first. This module piles memory addresses, executable formats, and machine instructions on top of everything so far, so it helps to resolve earlier questions before adding those new concepts.

The investigation pattern

For every target, we’ll be moving between four different views of the same program:

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?
Instruction view	Which compiler-produced instructions implement a named source function?

No single one of those views tells the complete story. The skill worth having is connecting evidence across all four of them, without inventing details none of the evidence actually established.

Start with From Executable to Process, which follows a single file all the way into a running process.