Given a Windows environment...
I know it is possible to use DLL or reflective DLL injection to load shared libraries (DLLs in the case of Windows) at runtime. As stated quite clearly here;
http://blog.opensecurityresearch.com/2013/01/windows-dll-injection-basics.html?m=1
But what about statically linked .lib or .a files?
Where do .lib or .a files go in the PE file when they've been statically linked at compile time? Is it possible to "link" them at runtime like common DLL injection? Should I be looking at the format of a .lib or .a file for clues?
You cannot static link at runtime.
To solve your problem, convert the lib to a DLL and inject it.
Related
We know that when linking a static library, the linker copies the relevant code from .a file to the executable binary file. And when linking a dynamic library, the linker just copies the addresses of functions it found in .lib file (under Windows) into the binary file, and the functions themselves are not copied. At runtime, the OS loads the dll, and the program runs the code according to the addresses. The question is, could I use the .lib file and dll to link the dynamic library statically? The linker reads addresses from the .lib, and then copies relevant code from the dll to binary file. It should work, right?
I have no clue whether your idea could work, but do note that -- on Windows, with Visual Studio at least -- a static library is something very different from a DLL.
With VS, a static library is basically just an object file container, that is, you have a .lib file, but that .lib file is just a container for all the .obj files that the compiler produced for the project.
The important thing here is that the .objcode in the static library hasn't gone through the linking stage yet, no linker has been involved.
Whereas the DLL is (finally) produced by the linker (from object files).
So the question here is really one of toolchain support, since the DLL is already a linker output, I doubt you could get the linker to re-link its PE code directly into the executable.
If you want to link the .dll at build time instead of run time yes, it can be done using the .lib file that corresponds to the .dll. The exact method depends on what you are using to build your application.
In Visual Studio you start by adding the .lib file in Linker->Input on the project properties.
While this is static linking it does not copy the .dll code into your executable; you still need the .dll to run the application.
Additionally, if the .dll is something you developed and/or have the source code, it can be modified/rebuild as a static library and linked into your executable (so you will not have a separate .dll file).
The background is following: there is 3'rd party provider that provides us with a libveryfancylib.so, in 32b. Softaware that uses the library has quite a load of other linux library dependencies (like QT) also, but they are open source, so no problem for statical linking. The target platform is 64b and running Debian 7.
We can ship the program with binary + dynamical libraries, no problem, but i would rather see single static binary with no dependencies.
So my question is: why i cannot link the dynamical library into static binary? I mean what bit of information is there missing, or is it just feature that is rarely needed -> not implemented.
We can ship the program with binary + dynamical libraries, no problem, but i would rather see single static binary with no dependencies.
What is the problem you are trying to solve?
You can follow the model most commercial applications on Linux do: put your executable, shared libraries and other resources in one directory (possibly with subdirectories). When linking your executable against those shared libraries pass -Wl,-rpath,'$ORIGIN' (in make use -Wl,-rpath,'$$ORIGIN') to the linker, so that when starting your application the runtime linker looks for required shared libraries in the same directory where executable is.
Then archive that directory and give it to your users.
There are programs for MS Windows that can do so, eg DLL to Lib and DLL to Static Lib.
In the open source world, there isn't really much of an incentive to develop such a tool as you can always recompile from source (but of course it's possible that someone somewhere did it anyway).
It's because dynamic libraries and static libraries are two different things. A static library is just an archive of object files (much like a zip archive). A dynamic library is more like an executable program.
So you can't really link anything into a static library, you can only add more object files.
Suppose I have some code written in C with some data structures defined and some functions to work with those structures and all that is in a directory called src1. Suppose now I want to distribute this code.
If I want to use the external code in src1 in a project what should I do? Should I compile the code in src1 to an .a archive and then include that archive in the other projects I want to use?
Basically what I need to know is the correct conventions to use external code in a project.
Thanks in advance.
To distribute the code in the form of libraries you need follow the below steps:
List down the set of structure, functions, macros etc which you want to expose to other projects.
Group the set of data listed in Point-1 into a set of header files. Rest of your internal stuff can be in other header files.
Compile your code into a static(It will .a for linux based systems or .lib for windows) or dynamic library (It will be a .so/.sl for linux based systems or .dll for windows)
Provide your library and the set of exposed header files (as decided in point-2 above) to the other projects.
Link for creating static or shared libraries using gcc is here
Link for creating static or dynamic libraries in Windows using MSVC is here
Yes, you can use a static library, which is an .a file in Linux, and typically a .lib in Windows. This also requires that you share the header of course, so the code that uses the library can have the proper data structure definitions.
You can use any format (.a or .so) to distribute your library. The first one is static ally Inked and the second one is dynamically linked. To know more see this answer Difference between static and shared libraries?
Which ever you use you always link it in the same way.
gcc -L/path/to/lib -lsrc1 source.c -o source.o
Here, /path/to/lib can contain any of your previously compiled libsrc1.so or libsrc1.a
Why isn't it possible* to "re-link" a native shared library (DLL) into an executable file, as if they had been statically linked? Is the DLL missing any required information?
*Note: Or is it actually posible? If it is, please let me know, but through searches I've come to the conclustion that it's not possible.
It isn't directly possible.
When an EXE loads a DLL (via LoadLibrary) there's a lot of work done by the DLL loader to patch adresses. You can't just combine a DLL as is with an exe, because its adresses are wrong if it's not dynamically loaded.
On the other hand, a LIB is statically linked: no loading involved, no adress fixing, everything works without further job when you launch the program.
What is possible to do is to convert a DLL and EXE back to OBJ and link them together statically.
I just downloaded curl and managed to build a programe with it.
What I don't understand is why it requires both curllib.lib and curllib.dll ?
In my opinion either curllib.lib or curllib.dll should be enough, why both?
Also I've searched through the source but doesn't find anywhere it uses dlopen to load curllib.dll, so why is curllib.dll required to run?
curllib.lib is the import library. It contains stubs for all the functions whose actual code is in the DLL, and it contains code to load the DLL. The .lib is automatically generated by the build system (e.g. Visual Studio), which is why you won't find any references in the code. You will find, however, some directives that tell the compiler/linker to export certain functions:
__declspec(dllexport) on a function declaration will export that function. This is convenient, but Microsoft-specific. For example:
void __declspec(dllexport) foobar(int qux);
More information here.
Alternatively, a .def file can be used, that explicitly lists all functions that are exported. For example:
LIBRARY MYFOO
EXPORTS
foobar #1
More information here.
You can do without the .lib if you really want to, but you'll have to manually use LoadLibrary, GetProcAddress and friends to call the function in the DLL.
The .dll is required to run. The .lib exists so the linker can resolve the ordinals and addresses from function names, and is only required at link time.
Other systems (such as Linux) maintain full linkage information in shared libraries and would not require this.
When you use a DLL on Windows, you typically use it with a .lib file that tells the linker enough to be able to create an executable. The executable then uses the .dll file at run time.
OTOH, dlopen is a UNIX/Linux/POSIX kind of thing -- the equivalent on Windows would be LoadLibrary. You'd normally use dlopen with a .so file.