Debugging Souce Code with Assembly If we compile C program with -g flag, it tells GCC to include debugging symbols inside the resulting binary (a.out by default). These symbols live in a special section of the ELF file (like .debug_info, .debug_line, .debug_str, etc.) and contain metadata that maps machine instructions back to your original source code. This allows us to see corresponding source along with assembly while debugging with GDB. ...

Examining Memory with x Command The x (examine) command is more powerful for raw memory: x/[count][format][size] address Size Modifiers b = byte (1 byte) h = halfword (2 bytes) w = word (4 bytes) g = giant word (8 bytes) Format Modifiers x = hexadecimal d = decimal u = unsigned decimal o = octal t = binary c = character s = string i = instruction (disassembly) count: how many units to display ...

Reverse Engineering with Radare2 A powerful framework for reverse engineering. Core Analysis Commands r2 Command Description r2 ./binary Open the binary for analysis. aaa Analyze All Automatically. Finds functions, symbols, etc. afl Analyze Function List. Shows all identified functions. s <address/name> Seek to a specific address or function name (e.g., s main). pdf Print Disassembled Function. Shows assembly code. pdg Print Decompiled Ghidra. Shows decompiled C-like code. afv Analyze Function Variables. Shows local variables, arguments, and their stack offsets. Additional Useful Commands r2 Command Description i Show general information about the binary (imports, exports, strings). ps Print a summary of the binary’s sections. V Enter visual mode for interactive navigation. VV Enter visual graph mode to see the control flow graph. ? / ?? Get help on commands.

Reverse Engineering and CTF Challenge Notes Reverse engineering is the process of understanding how software works without access to its original source code. In security challenges (CTFs), the goal is often to recover hidden data or logic by dissecting a binary. This walkthrough documents my first attempt at such a challenge, focusing on ELF-based reverse engineering and the reasoning process behind each step. 1. Static Analysis Static analysis means inspecting the binary without running it. ...

ELF Format: Sections and Section Header Table In the previous post, we explored Program Headers and Segments - the runtime view of an ELF file. Now we’ll look at Section Headers and Sections - the link-time and debugging view. What Are Sections? Sections are the link-time view of an ELF file. While segments tell the operating system how to load and execute a program, sections organize the file’s contents for: ...

ELF Format: Segments and Program Header Table After understanding the ELF Header, the next critical component is the Program Header Table. This table describes segments - the portions of the file that will be loaded into memory when the program executes. What Are Segments? Segments are the runtime view of an ELF file. While sections (which we’ll cover later) are used during linking and debugging, segments are what the operating system cares about when loading and executing a program. ...

ELF Format: ELF Header What is ELF? ELF (Executable and Linkable Format) is the standard binary format used by Unix-like systems (Linux, BSD, etc.) for: Executable files (a.out, /bin/ls) Object files (.o) Shared libraries (.so) Core dumps It’s a container format that describes: What parts of the file get loaded into memory, Where execution starts, How relocations and dynamic linking are handled. Contains useful information for the debuggers. General Structure of an ELF File An ELF file is organized into several key components that serve different purposes during compilation, linking, and execution. ...

When learning assembly, it’s easy to get lost in the “why” of CPU design, but this blog will stay focused on the x86 instruction set itself. The goal here isn’t to study computer architecture or dive into microarchitectural details — instead, we’ll build a working reference for how to write and understand x86 assembly code. Everything that follows is about the x86 family of processors, starting from the registers that form the foundation of all instructions. ...

When your x86 computer first starts up, it’s in a surprisingly primitive state: No operating system - Obviously, since we haven’t loaded one yet No memory management - No virtual memory, no protection between processes No file system - Can’t open files, no directories, no abstraction layer No network stack - No TCP/IP, no internet connectivity No device drivers - No USB drivers, no graphics drivers, nothing What Services Are Available at Boot Time? Despite the barren landscape, the BIOS (Basic Input/Output System) gives us a few essential tools: ...

Introduction: The Communication Challenges At its core, a CPU is designed for one primary task: processing data and executing instructions at incredible speed. But this processing power becomes meaningful only when it can interact with the rich ecosystem of peripheral devices that extend its capabilities. Why CPUs Need to Talk to Many Different Devices? Your CPU must read input from your mouse or keyboard, process that input to understand your intent, communicate with memory to load the browser application, send rendering commands to your graphics card, request data from your network interface to load the webpage, and potentially write temporary files to your storage device. Each of these interactions involves a different type of peripheral device, each with its own communication requirements, data formats, and timing constraints. ...