3

I am trying to solve a challenge by using LD_PRELOAD to load my own strcmp library.
I first tried to compile my library with gcc -shared -fPIC strcmp.c -o strcmp.so, but when I tried to execute my file with LD_PRELOAD=/path/to/lib/strcmp.so ltrace ./exec, I had a the error : 

object '/path/strcmp.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored

By comparing file /path/to/strcmp.so and file exec, I found out that my exec file was a ELF 32-bit LSB executable and that my lib was a ELF 64-bit LSB shared object.

Then I tried to compile my lib with gcc -m32 -shared -fPIC strcmp.c -o strcmp.so, but when executing I have the same error (but this time with ELFCLASS32) : 

object '/path/strcmp.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored

Any suggestions? How can I have the same error with both 32 and 64 bits version of my lib?

Improve this question
2
  • What kind of executable is ltrace? Perhaps it can't be linked against the 32-bit preload? If so, you might have to trace env LD_PRELOAD=/path/to/lib/strcmp.so ./exec instead (assuming that ltrace will work across the exec()). Or just accept that ltrace can ignore the preload. Commented May 24, 2017 at 8:08
  • Could it be that ltrace is 64bit and can't "handle" 32bit process (you could check that by ltrace .exec - without LD_PRELOAD). If so, you need to rebuild exec and strcmp.so for 64bit and try again. Or (if possible) install 32bit ltrace? Commented May 24, 2017 at 15:38

2 Answers 2

Reset to default
4

As you noticed, if you have a single 32-bit shared library, you will get that warning when 64-bit programs are run. If you have a single 64-bit library, you get that warning when you run 32-binaries. We need your system to have both 32- and 64-bit versions of your libraries, and to allow the system to choose which one to use as needed. You can accomplish that with the following changes:

  • Compile both a 32-bit and 64-bit version of your library, and put them in /usr/lib and /usr/lib64 respectively on RedHat-based systems. Debian uses a different library naming scheme which unfortunately is not very consistent, so I'll leave it an exercise for the reader to determine the right place to put the two libraries on Debian systems.
  • Change your preload to remove all paths, like so: export LD_PRELOAD=strcmp.so This will allow the system to search only the correct library directory when it looks for a 32-bit or 64-bit library.
  • If you want to patch only one architecture, say 32-bit, then compile a 32-bit version of your library, and then compile an empty file into a 64-bit shared library of the same name. Place them both as described above.

Note that this only works if you use the system library directories. Even /usr/local/lib and /usr/local/lib64 are not allowed.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

How do I specify both a 32- and 64-bit version without putting it in the system directory?
@flarn2006 I haven't looked at it in a few years, but at the time, putting it in a system directory seemed to be the only way to make it work. Hence the last sentence of the answer.
Kind of weird IMO that there isn't an alternative method which doesn't require root privileges.
0

You should run 32-bit dynamic linker directly:

ltrace /lib/ld-linux.so.2 --preload /path/to/lib/strcmp.so ./exec
Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.