Master the fundamental concepts of reverse engineering through this focused micro-challenge.
You have read the whole brief, and the concepts above stay free on every task. Writing and running the code needs a plan.
Three hints are available for this task, revealed one at a time inside the code workspace so you can struggle productively before seeing them.
Every task includes starter code, theory, and hidden tests so you can implement and verify locally in the browser.
How it worksLinux 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.
Open a library and resolve symbols:
cLoading…
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.
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.
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.
Write a C program that emulates the address arithmetic dlsym performs: the resolved address of a symbol is the library's load base plus the symbol's table offset.
Input:
For each query, print exactly one line: <name> -> 0x<hex address> when the name is in the symbol table <name> -> NULL (symbol not found) otherwise, like dlsym returning NULL
Addresses are lowercase hex, no leading zeros beyond the value itself.
Success Criteria: