I had dynamically load a shared library for target process. Target process has a function
void printNum(). Is it possible to get it address in shred library?
actually i need start address of .text segment + function offset, but in target process i can get it with &printNum, is it posiible to do the same but in shared librarry?
Is it possible to get it address in shred library?
Maybe.
It's easy if the main executable exports the symbol in its dynamic symbol table. If so, you can access its address using the same &printNum syntax.
To see whether the main executable exports the symbol, use nm -D a.out | grep ' printNum'.
If the main executable doesn't export the symbol, and you try to access it from the foo.so with &printNum, your dlopen("foo.so", ...) will fail with "printNum: unresolved symbol" or a similar error.
If you can't rebuild the main executable with e.g. -rdynamic flag, things get trickier.
If the main executable has symbol table (i.e. it is no stripped), the function will be visible in the output from nm a.out. You can read the symbol table using this code, and obtain the address of printNum from it. If a.out is position-independent, you will also need to find the address where it is loaded, using e.g. dl_iterate_phdr().
If the main executable doesn't have symbol table (i.e. it is stripped), then there is no way to find where printNum actually is, and the answer in that case is "no".
Related
I work on a MC68360 platform using GNU development tools.
What I need is a relocatable execution module that can make calls to absolute addresses,
i.e to functions that are already in memory (ROM).
I can't get the GNU linker to do so.
The place of the function call in the application is a relocatable address
and the provided function address is an absolute address.
The end result is a relocatable address.
How did I do it so far:
I extract the Global Functions from the rom-image and make a file out of this, say rom_functions.S. This file looks like this:
.text
.globl sqrt
.equ sqrt, 0x<abs addr>
A check with readelf on rom_functions.o confirms all symbols are absolute addresses, there is no relocation table either.
rom_functions.o is used to link with the application into a relocatable module with the following command line:
ld -d -r -Rrom_functions.o -uappl_start -Tmyscript #$objs -o appl.rel appl.o
The -R is used to include and preserve absolute addresses as is the purpose of this option I guess. Possibly I have mis-interpreted the -R option. I have tried -R<rom.img> but yields similar result , the called function address is made relocatable in the output and is thus - when loading - modified with the loadaddress; eventulally a the call will nog enter the desired function.
Is there a solution to achieve what I want: a relocatable module with calls to absolute addresses?
I'm learning ELF, and was given a task to create a custom READELF program in C 32bit linux.
As part of my task, I created pointers to the '.symtab' and the '.strtab' tables, so I could print each symbol name. However, when comparing my output to the original READELF output, I noticed that I'm missing the "#..." part after some of the symbol names.
Where can I find this data?
I need to change the symbol visibility in an object file or library. For example, a particular shared object has a symbol name present, but its local so I can't bind to it (the lower t indicates local in the TEXT section):
$ nm /usr/local/ssl/lib/libcrypto.so | grep -i OPENSSL_cpuid_setup
00000000000c3f80 t OPENSSL_cpuid_setup
000000000008a360 t fips_openssl_cpuid_setup
The same symbol is present in the archive, but the archive not being used in this project (the upper T indicates global in the TEXT section):
$ nm /usr/local/ssl/lib/libcrypto.a | grep -i OPENSSL_cpuid_setup
0000000000000310 T OPENSSL_cpuid_setup
000000000000f8e0 T fips_openssl_cpuid_setup
I'd like the visibility of OPENSSL_cpuid_setup to be global rather than local.
Is there a way to change the symbol visibility in a object file or library? I've been through Binutil tools, and it does not look like there's a suitable tool.
And for completeness, the 'easiest' methods are not available because the source code is sequestered and cannot be changed. The easiest methods include (1) removing static from the declaration; and (2) using GCC's visibility attributes.
You could try (untested) objcopy with the --globalize-symbol option. However, this is only going to work with the archive, not the dynamic library, as you can modify the normal symbol table and not the (hashed) dynamic symbol table.
A disgusting hack would be to determine the offset of the routine from a global (using objdump and writing it to a file from your makefile), then create a function pointer, then jump to that (yuck).
My question is fairly OS X on x86-64 specific but a universal solution that works on other POSIX OSes is even more appreciated.
Given a list of symbol names of some shared library (called original library in the following) and I want my shared library to re-export these symbols. Re-export as in if someone tries to resolve the symbol against my library I either provide my version of this symbol or (if my library doesn't have this symbol) forward to the original library's symbol.
I don't know the types of the symbols, I only know whether they are functions (type T in nm output) or other symbols (type S in nm output).
For functions, I already have a solution: For every function I want to re-export I generate an assembly stub that does dynamically resolve the symbol (using dlsym()) and then jumps into the resolved function with the very same environment (registers rdi, rsi, rdx, rcx, r8, r9, stack pointer, ...). I'm basically generating universal proxy functions. Using some macro trickery that can be generated fairly easy without writing code for each and every symbol.
For non-function symbols the problem seems to be harder because I cannot generate this universal proxy function, because the resolving party does never call a function.
Using a constructor function static void init(void) __attribute__((constructor)); I can execute code whenever someone loads my library, that would be a good point to resolve and re-export all non-function symbols if that's possible.
In other words, I'd like to write the symbol table of my library to point to the respective symbols of another shared library. Doing the rewriting at compile or run time is okay (run time preferred). Or put yet another way, the behaviour of DYLD_INSERT_LIBRARIES (LD_PRELOAD) is exactly what I need but I don't want to insert a new library, I want to replace one (in the file system). EDIT: The reason I don't want/can't use DYLD_INSERT_LIBRARIES or any other environment variable of the DYLD_* family is that they are ignored for code signed, restricted, ... binaries.
I'm aware of the -reexport-l, -reexport_library and -reexported_symbols_list linker flags but I could not get them to work, especially when my library is a "replacement" for frameworks that are part of umbrella frameworks (example: /System/Library/Frameworks/CoreServices.framework/Frameworks/SearchKit.framework/SearchKit) because ld forbids to link directly against parts of umbrella frameworks.
EDIT: Because I explained it somewhat ambiguously: I can't change the way the actual program is linked. The goal is to produce a shared library that is a replacement for the original library. (Apparently called filter library.)
Found it out now (OS X specific): clang -o replacement-lib.dylib ... -Xlinker -reexport_library PATH_TO_ORIGINAL_LIB does the trick. PATH_TO_ORIGINAL_LIB could for example be /System/Library/Frameworks/CoreServices.framework/Frameworks/SearchKit.framework/Versions/Current/SearchKit.
If PATH_TO_ORIGINAL_LIB is a library that is part of an umbrella framework (as in the example above), then replace PATH_TO_ORIGINAL_LIB by the path of some other lib (I created a lib empty.dylib for that) and as a second step do
install_name_tool -change /usr/local/lib/empty.dylib PATH_TO_ORIGINAL_LIB replacement-lib.dylib
To see if the actual reexporting worked use:
otool -l replacement-lib.dylib | grep -A2 LC_REEXPORT_DYLIB
The output should look like
cmd LC_REEXPORT_DYLIB
cmdsize XX
name empty.dylib (offset YY)
After launching the install_name_tool it could be
cmd LC_REEXPORT_DYLIB
cmdsize XX
name /System/Library/Frameworks/CoreServices.framework/Frameworks/SearchKit.framework/Versions/Current/SearchKit (offset YY)
You could link against both libraries and use the link order to make sure to link against the right symbols. This works on both OS X and Linux:
cc -o executable -lmylib -loriglib
Where origlib is the original library and mylib contains symbols that are supposed to overwrite symbols in origlib. Then the executable will be linked against your symbols from mylib first and all unresolved symbols will be linked against origlib.
This works in the same way when linking against OS X frameworks. Just link against your library that replaces symbols first and against the framework after.
cc -o executable -lmylib -framework SomeFramework
Edit: If you just want to replace symbols at runtime then you can use LD_PRELOAD in the same way:
cc -o executable -framework SomeFramework
LD_PRELOAD=libmylib.dylib ./executable
A little similar with Where are static variables stored (data segment or heap or BSS)?,but not the same one.
Now I get a other process's variable's address like:0x10fb90,where is this variable stored(data segment or heap or BSS), could i get the location just from the process's pid and the variable's address?
I am working on osx using obj-c and c.
You have 2 options.
1. Use objdump
Something like
objdump -x a.out | grep YOUR_VARIABLE_ADDRESS
2. Use gcc's map option to generate a map file
Compile something like this in gcc
$ gcc -o foo.exe -Wl,-Map,foo.map foo.c
and now
$ grep YOUR_VARIABLE_ADDRESS foo.map
Both these methods will show your variable's location, if at all the address you supplied exits.
PS: The link I've added for the map file shows an example map file generated by Visual Studio linkers, but the format is typically similar in most of the map file formats generated by various linkers