Analyze Dynamic Dispatch with dlopen and dlsym

Dynamic Dispatch with dlopen and dlsym

Linux supports loading shared libraries at runtime through dlopen, dlsym, and dlclose. Legitimate software uses these for plugin architectures; malware abuses them to hide API imports from static analysis.

API Usage

Open a library and resolve symbols:

cCopy
Loading…

RTLD_LAZY resolves symbols on first call; RTLD_NOW resolves everything immediately. If the symbol does not exist, dlsym returns NULL.

Plugin architectures load .so files, resolve entry points via dlsym, and call init/process/cleanup functions through function pointers.

For This Exercise

You will document how dlopen and dlsym enable runtime library loading. Malware uses this to hide imports from objdump -T and to load encrypted payloads only at runtime, which is why dynamic analysis with ltrace is necessary.

Detecting Runtime Loading

Static analysis of the import table misses dlsym-resolved functions. Use ltrace to see library calls at runtime, or set GDB breakpoints on dlopen and dlsym to capture which libraries and symbols the program loads. Malware packs its payload as an encrypted blob, decrypts it to disk or memory, then loads it with dlopen to evade static scanners that only examine the on-disk image.