I am looking for the modify_ldt function (or constant for syscall) on ubuntu, but I can't find it's declaration anywhere. It's not in sys/types.h (as the man page suggests), nor in linux/ldt.h (doesn't exist) or linux/unistd.h as says here.
Where is it located?
Try using __NR_modify_ldt for the syscall constant. On my system it's defined in asm/unistd_64.h, which is included from unistd.h
As Karl already said, call system call directly. See here
Related
You can find a mention of it here: https://code.visualstudio.com/api/language-extensions/language-server-extension-guide
however without any explanation. I couldn't find information about it by googling.
What is the purpose of a .clientrc file?
As mentioned in the comments, ".clientrc" was just chosen as an example file name.
If you google site:code.visualstudio.com clientrc, that page is the only search result. And googling site:github.com/microsoft/vscode "clientrc", all the results are about example code (and most are about that example code specifically).
The .*rc file name pattern is a common convention for application-specific configuration files. There's a baeldung article on it:
Names including rc often signify files or directories of files with code. Specifically, this code consists of commands that are meant to run when a program is executed. Indeed, that program can be an application, but it can also be a whole operating system.
Because of this, the original rc affix and extension both meant “run commands”. In particular, a widely accepted source of the term is the Compatible Time-Sharing System (CTSS)
I'm trying to hook the fopen syscall in linux using Go.
Normally I would use C for something like this (Example: https://stackoverflow.com/a/880278/5572976) but the CTF states that the solution needs to be written in Go.
I've looked at the syscall package and basically what I'm looking for is using the following in Go.
dlsym(RTLD_NEXT, "open");
EDIT: That's open, not fopen.
try this Runtime dynamic library loader (dlopen / dlsym) for Go (golang)
I have some non-accessible code that I call, that does dlopen("lib.so", RTLD_LOCAL).
The problem is that I need to control the search path of dlopen(). The answer to this problem is quite typically "set LD_LIBRARY_PATH", but I don't know the actual path to set until after application startup, so I can't put a wrapper script that sets it and then invokes my application.
According to the documentation of ld.so and of dlopen, LD_LIBRARY_PATH is only examined at application startup. If you change it afterwards inside the application with setenv, it won't change the lookup list of dlopen().
I know that specifying the full path to dlopen() would be a strategy, but I don't have access to that dlopen call, so this option is also not possible.
Am I out of options or is there some magic strategy I can't find?
I believe it is not easily possible.
However, if you are crazy enough to patch ld.so from its source code, you might do something.
Maybe you could use some LD_PRELOAD trick.
But if it is a matter of finding which exact file is dlopen-ed, why don't you strace(1) your program to understand which files are mmap-ed?
You can also use pmap or simply cat /proc/$(pidof your-program)/maps
If you can change some lines of source code, consider dladdr(3) to find out where is some dlsym-ed function... And you might also use dl_iterate_phdr(3)
If your LD_LIBRARY_PATH is relative to your application root - you can use wrapper script, which will extract path to itself using $(dirname $0) and set up correct LD_LIBRARY_PATH.
Another trick (but it's not a good idea to do so) is to provide your own lib.so that will be just a proxy to actual lib.so. You can initialize all references on your proxy library load using library init functionality. Please refer to this question.
Same as Win32:
GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS, (LPCTSTR)(void*)(myFunc), &h);
http://www.kernel.org/doc/man-pages/online/pages/man3/dlsym.3.html is not helpful.
Use dladdr. Documentation here.
Not per se, no; if the symbol was compiled in instead of accessed via dlopen()/dlsym(), then there is no handle to be returned. (The handle abstraction only exists to enable dlsym() fine control over where it loads symbols from; there is no such control over the original link, except via linker scripts.) In the normal course of events, an object is simply open()ed and mmap()ed, other details being hidden within ld.so and only accessible indirectly via RTLD_DEFAULT and RTLD_NEXT parameters to dlsym(). If you are using dlopen(), you are expected to keep track of your handles.
The only method I am aware of is to parse the contents of /proc/self/maps (and/or perhaps smaps) and then use the symbol address to calculate from the boundaries of the mapped .so (start and its size) within which mapped module the function lies.
Note: /proc/self is a symlink (on Linux) to the current process's (with ID <pid>) meta-information, i.e. /proc/<pid>.
It's possible there is some programming interface to this very information that you could use.
Edit: Ah, so dladdr() would be that interface.
I am just wondering if there is an Linux equivalent to Novels nlist(). nlist()
does the following:
Privileged processes calling nlist() should beware of the possibility of an unexpected file being substituted as the operand.
The nlist() function returns symbol table information for the specified symbol names, for the executable file whose name is supplied as an argument.
Thanks,
Rob
The function that comes closest that I know about is dlinfo. It is completely undocumented in glibc (no man page, nothing in the info files), but is apparently a clone of a Solaris interface, which is documented:
http://docs.oracle.com/cd/E23824_01/html/821-1465/dlinfo-3c.html#scrolltoc
You can find it declared on Linux in dlfcn.h