I have a dylib file a2.dylib I disassembled in IDA pro which is stripped of symbols. I have used a1.dylib which has symbols albeit older version of a2.dylib with Bindiff to diff out function names to match a2.dylib. I need these derived function names to be exported for use in debugging a2.dylib inside GDB; something like a equivalent of a windows PDB file for use inside GDB. How could I go about doing it in IDA pro 6.4? thanks.
You can easily create a symbol table with SymTabCreator. All you need is a list of address ↔ symbol mapping.
Note that the README says it works for main executables only, so you may need to adjust the imageBase offset for a dylib.
Related
I have a piece of software that is compiled with several shared libraries. My code is calling a function inside the shared object and crashing inside. I believe my problem is how the parameters are being constructed for this function. I want to validate this by viewing what is happening inside the .so such that I can make the correct changes for how I am constructing the parameters.
The problem I a am running into is not being able to resolve local variables within the shared object. For instance gdb will print out:
0x<addr> in <function>(int const* , int, int const*)
Based on this I know where I am inside the .so. When I navigate here and try to find what different variables are being set to gdb complains with:
No symbol <var> in current context.
Now I know for a fact where I am within the code. Additionally, I have checked to make sure the .so was compiled with symbols on and I have also made sure gdb is loading these symbols.
Can anyone inform me on why gdb is unable to see these local variables?
As a note - I haven't used gdb in a while and not to this level of debugging so I am sorry in advance is this is just a limitation of gdb that I am unaware of.
GDB Version: 7.7.1
Edit for comment:
Yes the .so was compile with symbols. I have verified this with:
file <.so>
This tells me it was dynamically linked and not stripped.
As for commands, I simply trying to print variables.
Overall I am not sure why gdb is unable to resolve the source/exact function of the .so when I explicitly loaded it and made sure the .so was compiled with symbols.
I have checked to make sure the .so was compiled with symbols on
Every .so is compiled with symbols on -- it would be useless without symbols.
It's the debugging info that you are compiling without. Add -g flag to your compile lines, and make sure to not have -s or --strip anywhere on your link line.
and I have also made sure gdb is loading these symbols.
Yes, this output <function>(int const* , int, int const*) tells us that GDB has read symbols, and also that it did not load debugging info (these are two completely separate things).
I have built a dll using MinGW gcc on windows. I used .def to specified exported functions and generated .lib import lib. Then I used strip.exe to strip out the symbols table. I tried objdump and it prints out empty symbol table. But when I use strings.exe, it can still print a bunch of function and class names. Is this a problem? Would others be able to query functions according to the names from the dll?
Read about PE, it has address and name tables. If you clean up name table, no process will be able to locate exported function by name, only by address, that's done by linker, but not dynamically:
http://msdn.microsoft.com/en-us/magazine/cc301808.aspx
There are many ways to secure exported functions from dll,but all of them have published exploits. If you really want to secure your function - create custom calling convention or signature verification at all exported functions.
All that stripping does to the dll is to remove the debugging symbols. It does NOT remove the functions from the dll. In other words, if someone imports your dll or uses it, they can access only whatever you exported. If you do not want them to be able to access it, simply do not export it.
Also, when you do a release build, it should strip it if you have -s option enabled.
I am building/using the python module for LAMMPS, which is the open source Molecular Dynamics simulator (project home, source).
The python module works by compiling the C++ application as a library, and using CDLL/ctypes to call a C function interface. When you call the CDLL() function in python, the load fails if there are any missing symbols that the OS doesn't find in the library itself, and can't load from other available libraries.
The particular symbol I'm getting as missing is a C++ mangled name __ZN3MPI3Win14Set_errhandlerERKNS_10ErrhandlerE, which is probably MPI_Win_set_errhandler (or some namespaced/object oriented equivilent with a similar name). For context, I've compiled it using the python/setup_serial.py file, which should build with a dummy MPI interface, and shouldn't reference any real MPI symbols at all; so this is a rogue reference that's crept in somewhere. I've also made some modifications to the source, but I get the same error when I disable all my changes.
My question is, what is the best debugging strategy for finding out where a symbol is referenced in a dynamic library giving this sort of error? So far, I've tried searching the source for references to this symbol (or parts of the name,) but I'm not finding any instances (in fact, the only results are the binary files from the python build process, of the library I'm having trouble importing.)
My next step is to search inside the binary somehow, I guess, but I have no idea where to begin that (or some other strategy).
c++filt is your friend
$ c++filt __ZN3MPI3Win14Set_errhandlerERKNS_10ErrhandlerE
MPI::Win::Set_errhandler(MPI::Errhandler const&)
Now do a quick google search on that library
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512616
Looks like there is a case where parts are upgraded but not recompiled. The second thing is to look at the link line for the complier and see what libraries it includes.
Final last resort is to do something like:
readelf -s /path/to/libfoo.so
And start grepping around to see if it's defined somewhere.
I'll divide this questions in 3 parts:
I would like to produce a static library and strip off its symbols. (Debug info is already not included)
Similar to the strip command in linux. Can it be done?
Is there an equivalent tool in windows env, to the nm tool in linux?
When creating a static library using VS2008. Is it possible to define a script that will exclude some of the produced .obj files out of the build and out of the static lib?
Can it be dynamic? I mean I'd define a compilation mode in the script and this would result in specific object files being excluded from the build
If anything is visible that you feel should not be, try declaring it with the "static" keyword. This tells the compiler that it is accessible only to the current module.
There are cases where it would be convenient to be able to strip out all but a small number of "exported" public symbols, but it's not really feasible.
A static library is little more than a collection of .obj files. The internal dependencies haven't been resolved yet, and they won't be resolved until link time.
For example, if your .lib consists of foo.obj and bar.obj, and there's a call in foo.obj to a function defined in bar.obj, then that symbol must be available at link time, even if nothing outside of the library should be able to see it.
For that reason, you cannot strip the symbols (with the possible exception of file-scope static symbols). Even class methods that are protected or private (in the C++-sense) will exist in the symbol table, since the enforcement of the visibility is a compile-time issue, not a link-time one.
In contrast, a dynamic library is a standalone binary that has already been linked. References from foo.obj to bar.obj have already been resolved. Thus a DLL can be stripped of symbols except for the ones that must be exported (and even those can be renamed or replaced by ordinals).
If your DLL exposes a simple C API, then you're all set. But if you want to expose a C++ class, you're probably going to end up exporting all of its methods, even the protected and private ones (since inlining in the external application might result in direct calls to private methods).
No, how do you think the users of the static library would link to it without knowing where are the symbols they use defined?
Yes, try the DUMPBIN utility.
Well, yes. You can run the LIB utility with /REMOVE:foo.
That said, I think you are doing something that either is not worth doing or could be done a lot simpler than with removing library members.
I kept finding the names of certain (but not all) static functions in .obj files produced by VS2010. Interestingly, they were visible in my Release .obj files but not the Debug .obj files. I just used cygwin strings to perform the search:
$ strings myObjectFile.obj | grep myStaticFunctionName
I tracked it down to the "Whole Program Optimization = Yes" setting ("/GL"). When I switched this to "No" the function names no longer appear.
Update: As a followup test I opened the "cleansed" myObjectFile.obj in vim and I can still find them (with either :set encoding=utf-8 or :set encoding=latin1). I'm not sure why strings was missing the matches. Oh well.
I am building a shared library on Ubuntu 9.10. I want to export only a subset of my functions from the library. On the Windows platform, this would be done using a module definition (.def) file which would contain a list of the external and internal names of the functions exported from the library.
I have the following questions:
How can I restrict the exported functions of a shared library to those I want (i.e. a .def file equivalent)
Using .def files as an example, you can give a function an external name that is different from its internal name (useful for prevent name collisions and also redecorating mangled names etc)
On windows I can use the EXPORT command (IIRC) to check the list of exported functions and addresses, what is the equivalent way to do this on Linux?
The most common way to only make certain symbols visible in a shared object on linux is to pass the -fvisibility=hidden to gcc and then decorate the symbols that you want to be visible with __attribute__((visibility("default"))).
If your looking for an export file like solution you might want to look at the linker option --retain-symbols-file=FILENAME which may do what you are looking for.
I don't know an easy way of exporting a function with a different name from its function name, but it is probably possible with an elf editor. Edit: I think you can use a linker script (have a look at the man page for ld) to assign values to symbols in the link step, hence giving an alternative name to a given function. Note, I haven't ever actually tried this.
To view the visible symbols in a shared object you can use the readelf command. readelf -Ds if I remember correctly.
How can I restrict the exported functions of a shared library to those I want (i.e. a .def file equivalent)
Perhaps you're looking for GNU Export Maps or Symbol Versioning
g++ -shared spaceship.cpp -o libspaceship.so.1
-Wl,-soname=libspaceship.so.1 -Wl,
--version-script=spaceship.expmap
gcc also supports the VC syntax of __declspec(dllexport). See this.
Another option is to use the strip command with this way:
strip --keep-symbol=symbol_to_export1 --keep-symbol=symbol_to_export2 ... \
libtotrip.so -o libout.so