On windows I map a PE file to memory, fix the import table, and call the entry-point in a new thread to turn an exe into a "DLL". I need to do the same on linux, but I am not familiar with library and executable loading. What would be the best method to achieve this, what should I look into? Thank you
Related
I have a program written in C that uses dlopen for loading plug-in modules. When the library is dynamically loaded, it runs constructor code which register pointer to structure with function implementations with the main application by use of exported function. I want to use absolute path for specifying the file to dlopen.
Then I have other part of the program with takes file, determine if it is ELF, then looks into the ELF header for specific ELF section, read this section and extract from it pertinent information. This way it filters only shared libraries which I have previously tagged as a plug-in module.
However, I am solving a problem how to discover them on the fly (in portable Linux way, i.e. it will run on Debian and on Fedora too and so on) from the main program. I have been thinking about using ldconfig for this. (As the modules will be installed by way of distro packaging system, APT for example.) Is there any way how to programmatically get the string list of known libraries from C program other than directly reading the /etc/ld.co.cache file? I was thinking that maybe there is some header library which will give char** when I ask.
Or, maybe is there any better solution to my problem?
(I am proponent of using standard system components that programming one-off solutions which will need support in the future.)
Here's my predicament: I am using PhysFS, which allows me to treat multiple directories and archives as one virtual directory. This is for a video game in the future, which I intend to make modder-friendly. PhysFS is the best way to make it modding-friendly.
At the same time, I also intend to use a script-extender of a sort that dnyamically loads libraries and registers them in Lua. I already created a crude, makeshift, largerly proof-of-concept Lua script extender.
So what is my issue? My issue is that dlopen / LoadLibrary only works with files on a real filesystem. And I want to load via PhysFS. I load the file via PHYSFS_openRead, then use PHYSFS_read to load the file's full content into a memory buffer.
Some people suggested loading the .so / .dll file into the memory from PhysFS, and then writing it out to /tmp in Linux, or C:\temp in Windows, and then dlopen-ing it. But I don't think that's a very elegant way to do it.
So... any other ideas? I did look into mmap and thought maybe I could manually load the ELF file (on Linux) and somehow manually extract the functions, and finally register them for Lua, but so far, all I could produce was a program that gave me information about the elf.
People said that I should look into LibJIT, but I'm not exactly sure how that would help me.
So what should I do? How do I load a library into memory via PhysFS, and use an alternative to dlopen to... dlsym the functions out of it?
Please don't suggest dlopen, unless you genuinely suggest that I write out the file temporarily.
My question is largerly: how do I link? How do I get the functions out of the library which I already have in memory? And why do some people suggest LibJIT to me?
I'm looking into why Warframe does not work on WINE in Linux, and I suspect that it is due to missing system or library calls. I'd like to determine what calls it makes, and compare them to calls supported directly or indirectly by WINE.
There is a tool called EXE Import Viewer it doesn't continuously list the function calls but it does reveal the dependencies of the the exe.
From the site:
EXE Import Viewer shows the information about linked libraries and functions, the list of function that an executable file imports, and the DLL's from which the program imports these functions.
This might be a good place to start for your problem.
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 have an application (for which I do not have the source code).
I know that it is designed to dynamically load a shared library, depending on the command line parameters.
I know which library it should be loading and I've set up LD_LIBRARY_PATH to the appropriate directory.
The application works on one server without any problems, but does not work on another.
I'm trying to figure out why and it would be helpful if I could confirm that the script is looking for the library that I think it is and if I could track where it is looking.
Are there any tools that could help me? I've been googling, but most of the information I'm finding is about ldd which really only tells you about statically linked libraries.
This is in a Linux environment and the application and library are both written in C
Thanks
Use strace. You will see the libraries being searched etc., which will help you figure out what is happening.
As every shared library is memory-mapped into the process's address space, you can also inspect the /proc/[PID]/maps file.