Three operating systems, one execution decision
A dynamic loader locates the libraries required by a program, maps them into its address space, resolves imported symbols, and prepares the program to execute. Windows performs this with PE files and DLLs, macOS with Mach-O files and dylibs through dyld, and Linux with ELF files and shared objects through its ELF interpreter.
Library hijacking occurs when an attacker influences which library the loader selects. Although the implementation differs, the defensive chokepoint is the same: a process loading code from an unexpected location or trust context.
Parallel operating-system views. One shared decision boundary.
Windows loader
Windows
A trusted executable resolves an attacker-controlled library through side-loading, search-order abuse, or redirection.
Resolution surface
- DLL search order
- Application directory
- Side-by-side loading
Evidence to carry forward
- Process execution
- Image/module load
- File creation + signer
dyld
macOS
A Mach-O process resolves an unexpected dylib through loader paths, embedded runtime paths, or unsafe bundle placement.
Resolution surface
- @rpath resolution
- Framework paths
- DYLD_* context
Evidence to carry forward
- Process execution
- Dylib path + identity
- File and code-sign events
ld.so
Linux
An ELF process maps an attacker-controlled shared object through preload configuration or manipulated search paths.
Resolution surface
- RPATH / RUNPATH
- LD_LIBRARY_PATH
- LD_PRELOAD
Evidence to carry forward
- execve context
- Mapped shared object
- File + configuration change
04 / convergence
The Loader Chokepoint
Did a trusted process load an unexpected library from a suspicious path—and what influenced the loader's choice?
Which executable started, and under what parent and identity?
Which module was selected, and had it just been created or changed?
Was the source writable, unexpected, unsigned, or outside its baseline?
Executable declares dependency
│
▼
Loader interprets name + search rules
│
▼
Library is selected
│
▼
Map → relocate → resolve symbols → execute
│
▼
Detection: Was this the expected library
from the expected location
for this process?
This is a collaborative research page and will evolve as each platform study develops. It is deliberately organized by loader behavior, not by file extension, so the final detections can be compared against one shared model.
The shared detection question
Did a trusted process load an unexpected library from a suspicious path—and what influenced the loader's choice?
The completed article will follow that question through five chokepoints:
- Loader configuration and search-path context
- Library writes into searchable or user-writable locations
- Process execution and parent context
- Module-load or memory-map observation
- Path, signer, hash, and baseline validation
Platform translation
| Detection concept | Windows | macOS | Linux |
|---|---|---|---|
| Library | .dll | .dylib / framework | .so |
| Loader | Windows loader | dyld | ld.so |
| Resolution influence | DLL search order | @rpath, DYLD_* | RPATH/RUNPATH, LD_* |
| Defender focus | image load + path | process + dylib path | exec context + mapped object |
The three paths converge because detection is ultimately about unexpected dependency resolution, not the suffix of the library file.