Linux cheating: executables and dependent libraries via LD_PRELOAD

Sorry for the title, could not think of anything else to describe the problem :)

So, like this: I'm trying to use a private free application for Linux (and therefore the problem is, if I had the source, I could rebuild it). In addition, I try to run it on an unsupported taste of Linux, and almost all components of the application work individually, but not together (as it should be if the application works completely).

Let me explain a little. There is a GUI that runs fine on an unsupported OS. Then from this GUI, you can invoke the command-line toolkit - it is useful that the GUI also spits out the command line that is invoked in each case.

Now, called from the GUI, some of these commands fail - however, since I have the actual command line (let them say: " extprogram -arg1 1 -arg2 2 ... "), I can repeat them from the terminal. So, I found that the application as a whole has its own libc libraries; and using these libraries (some of) the commands (running from the terminal) tend to crash - however, I found that from the command line this usually works for those that fail:

 LD_PRELOAD=/usr/lib/libstdc++.so.6 extprogram -arg1 1 -arg2 2 ... # or alternatively, this works too: # LD_LIBRARY_PATH=/usr/lib extprogram -arg1 1 -arg2 2 ... 

(in other words, using the libstdC ++ system instead of the supplied application usually fixes it)

So, now, if I could convince the GUI to call these tools " LD_PRELOAD " / " LD_LIBRARY_PATH " - I think everything will work fine ...

Unfortunately, the GUI does not call a script that would further invoke these executables, which I could modify directly (as far as I could see through grep ping) - it would seem to be an executable GUI file that creates system calls; I tried ' strace ' - ing, but I can not find something like a temporary script or anything I could change ...

So, I thought, maybe I could “trick” the creation of the bash script executable; so I move the executable - and create a script that should call the moved executable with LD_ prepended:

 mv extprogram extprogram.old cat > extprogram <<EOF LD_LIBRARY_PATH=/usr/lib extprogram $@ EOF 

... but it fails; obviously, the GUI application recognizes that something is wrong.

So, I thought: is it possible, somehow, to have a “wrapper” of C / C ++ code that somehow “loaded” this executable file, but in an “environment” that has “ LD_LIBRARY_PATH=/usr/lib ", and pass it your arguments (and also return the return value)? Then I could build this “wrapper” initially on the OS with the same name as the original executable, and all this works without touching the original executable (except for renaming).

Thanks a lot in advance for any answers,
Hooray!

+4
source share
2 answers

You're close You forgot shebang and made the script executable. You also called the wrong external program. Finally, I would use the absolute path to the old script, because you do not know what the CWD for the GUI will be.

 mv extprogram extprogram.old cat > extprogram <<EOF #!/bin/sh LD_LIBRARY_PATH=/usr/lib exec /psth/to/extprogram.old " $@ " EOF chmod +x extprogram 
+9
source

using the libstdc ++ system instead of the supplied application tends to fix things

I would be interested to know what problems arise with the help of the libstdc++.so.6 , but if the system fixes everything, then a much simpler solution is to delete (rename) the problem library and not make all shell shells.

If the application cannot find the "bad" library, there is a good chance that it will find the system one.

+1
source

Source: https://habr.com/ru/post/1379396/


All Articles