The Secret Life of DLLs: Memory, Modules, and Address Resolution

In our last post, we looked at the difference between an EXE (the brain) and a DLL (the helper). We established that while an EXE starts the program, it often relies on external Dynamic Link Libraries (DLLs) to do the heavy lifting.

But how do these two files actually talk to each other once the program is running? To understand cybersecurity and system internals, you have to go one level deeper into the core mechanism of the Windows operating system.

What Happens When You Run an EXE?

When you double-click an executable, a lot happens before you see a single pixel on the screen. The Operating System (OS) doesn’t just run your code; it orchestrates a complex setup:

1. Memory Mapping: The OS loads the EXE file into a fresh area of RAM.
2. Dependency Check: The OS looks at the EXE’s “Import Table” to see which DLLs are required (e.g., kernel32.dll or user32.dll).
3. Loading DLLs: The OS finds those DLL files on the disk and maps them into the same memory space as the EXE.
4. Address Resolution: This is the most critical step. The OS “connects” the EXE to the functions inside the DLL.
5. Execution: Once the connections are made, the CPU begins running the code.

The Concept of Address Resolution

When you write code that uses printf(), your EXE doesn’t actually know where that function lives. It essentially says to Windows: "I need the 'printf' function from the library msvcrt.dll."

Windows responds by loading msvcrt.dll, finding the exact memory address where printf starts (for example, 0x7FF...), and handing that address to the EXE. Now, whenever the EXE calls printf, it knows exactly where to "jump" in memory.

The Memory View: Everything is One

A key realization for any developer or researcher is that at runtime, a DLL is not separate from the program.

Once loaded, the DLL code sits inside the same process memory as the EXE. If you were to look at the memory of a running process, you would see sections for the EXE code, sections for the various DLLs it loaded, and shared areas like the Heap and the Stack.

Because they share the same memory space, the EXE can call DLL functions as if they were its own. This is a “jump and return” mechanism:

1. EXE calls a function.
2. CPU jumps to the memory address inside the DLL.
3. DLL executes the code.
4. CPU returns back to the EXE to continue.

How Modern Applications Use DLLs

Almost everything an application does in Windows is a series of DLL calls. By using libraries, developers don’t have to reinvent the wheel for every program.

Common Examples:

• Networking: If an app needs to connect to the internet, it calls functions inside ws2_32.dll.
• Filesystem: To create or delete a file, it uses kernel32.dll.
• User Interface: To show a pop-up “Message Box,” it calls user32.dll.

Modular Design

Large applications — like modern video games or web browsers — are built as a collection of modules. Instead of one giant, unmanageable EXE, the developers create a small EXE that acts as a coordinator for several DLLs:

• physics.dll handles the movement logic.
• graphics.dll handles the rendering.
• audio.dll handles the sound.

This modularity allows companies to update the graphics engine by simply replacing one DLL file without having to touch the rest of the application code.

Plugin Architectures

DLLs also allow for “Dynamic Loading.” An application can choose to load a DLL after it has already started using a command like LoadLibrary. This is how "Plugins" or game "Mods" work. The main program looks in a folder, sees a new .dll file, and brings it into memory to extend its own functionality.

Why This is the Foundation of Cybersecurity

Now we connect the dots. Because a DLL runs inside the same memory space as the EXE, it has the same permissions and privileges as that EXE.

The Key Security Realization: If an EXE calls a DLL, and that DLL runs code, then whoever controls the DLL controls the execution of the process.

This is the fundamental logic behind many common attack vectors:

Vishwas S Adhikari Espress0