Debug process with non-standard LD path.

[TommyJerryMairo]

I'm doing a challenge from a CTF, which provides an ELF executable and a libc.so like Cache Me Outside on pico. I've placed the libc.so and the executable in the same directory where the provided libc could be correctly recognized while running via commandline. However, when imported into Ghidra(both the executable and the libc.so), the debugger attempted to use /usr/lib/libc.so.6 which is different from the provided. By any chance could I force Ghidra to employ the imported libc when debugging the executable, instead of the system default one?

[TommyJerryMairo]

The error yield by Ghidra is Inconsistency detected by ld.so: dl-call-libc-early-init.c: 37: _dl_call_libc_early_init: Assertion sym != NULL' failed!`

[d-millar]

@TommyJerryMairo So the basic issue here is that gdb needs to be directed to the correct libc. I think (and let me know if I'm wrong) following the standard procedure for doing this via the LD_PRELOAD environment variable should work (see, for example, http://truthbk.github.io/gdb-ld_preload-and-libc). That said, Ghidra might complicate that. You might need to add LD_PRELOAD via -D to the ghidraRun/ghidraDebug scripts.

[nsadeveloper789]

I don't think Ghidra will complicate this too much. You won't be able to use the quick-launch menus from the main toolbar, for sure. Instead, connect manually using the buttons in the Targets window. That should get you a GDB session without launching your target. You can then follow the instructions @d-millar linked. Use the exec-wrapper method. Then, from the Objects window, you can use "Quick Launch."