How can I call libc functions from positionally independent shellcode

The best I've come up with is to read /usr/lib/libdl.so into memory, perform the relocations, and find it within there. I have some POC but it's not positionally independent and it even uses dlopen.

At this point, I'd settle for finding the base address of libc or libdl (preferably without reading /proc/[pid]/mem)

>>59626248
Nobody here understands a word of what you said.

Make a thread about phones.

>>59626368
Someone knows. Any basic windows malware dev/analyst should know exactly what I'm talking about with the windows section. I'm just hoping one of those people also know a bit about Linux...

>>59626393
Not a malware dev but I'm a software developer people here are on entry level shit p much they wouldn't be able to tell u how to make a 2D dynamic string array in C LEL

Maybe scan memory for byte match.. Get first n bytes of some known function from compiled kernel source, scan for it and later use is as an offset.

>>59626499
ive meant libc not kernel

>>59626499
Neat concept. Not a terrible idea, but it may be somewhat unreliable since I'm not sure how often certain functions change. I assume not very often, but still.

I'm also curious as to what the FS and GS registers are used for in linux.

This SO answer is pretty interesting, but can't really find a ton of information on it:
http://stackoverflow.com/questions/6611346/how-are-the-fs-gs-registers-used-in-linux-amd64

>>59626560
https://github.com/lattera/glibc/blob/master/dlfcn/dlopen.c
For example dlopen looks really old. License has 2005 as last date. That code probably hasnt changed much for long time.

FS GS - Idk what they are for but you could try read them from your test program and see what values they hold. See if they are pointing somewhere in loaded libc range.. Any stable pointer to libc code can be useful.