0

I have a proprietary ELF binary that I am trying to run. It is dynamically linked, but only against the normal libc stuff:

$ file binary
binary: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=e02a29757b79db68a7bd41a731c6eb7d3e2a0382, with debug_info, not stripped
$ ldd binary
    linux-vdso.so.1 (0x00007f5556bc1000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5556b7f000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f5556a9e000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f5556a99000)
    librt.so.1 => /lib64/librt.so.1 (0x00007f5556a94000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f55568b2000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f5556bc3000)

The part I care about is the SDL2 library, which has been statically linked in:

$ nm binary | grep SDL
...
0000000000482610 T SDL_VideoInit
0000000000478110 t SDL_VideoInit_DEFAULT
00000000004b61a0 T SDL_VideoInit_REAL
0000000000482620 T SDL_VideoQuit
000000000047d400 t SDL_VideoQuit_DEFAULT
00000000004b5f80 T SDL_VideoQuit_REAL
0000000000480de0 T SDL_WaitEvent
0000000000480df0 T SDL_WaitEventTimeout
000000000047bab0 t SDL_WaitEventTimeout_DEFAULT
00000000004845e0 T SDL_WaitEventTimeout_REAL
000000000047bae0 t SDL_WaitEvent_DEFAULT
00000000004842f0 T SDL_WaitEvent_REAL
00000000004824d0 T SDL_WaitThread
00000000004782a0 t SDL_WaitThread_DEFAULT
00000000004a6760 T SDL_WaitThread_REAL
...

(SDL is LGPL, so AFAIK it should not be statically linked, but it has been.) Actually SDL2 is no longer LGPL.

In order to get this to run on my system I want to replace the SDL library that was statically linked. The binary is not stripped, and the debug symbols are clearly in place, so I have some hope that this is possible.

Is there some tool that I can use to remove these symbols and replace them with a dynamic reference to an SDL .so file?

I know that there is no guarantee of success (for instance some functions may have been inlined), but is there a reasonable way to try?

bonus question: Why are the symbols duplicated with _REAL and _DEFUALT suffixes? I thought those were for versioning with .so files. What would they be doing when statically linked?

Improve this question
4
  • wrt symbols, "t" vs "T" just represents the scope of the symbols (global-binding vs local-binding). unless the binary is being tricky, only the "T" ones should be relevant (outside their module). some minor search-engine'ing says SDL defines a preprocessor macro to change the entrypoint of some of its functionality, and it's documented in README-dynapi.md.
    – Ali Rizvi-Santiago
    Commented Aug 9 at 16:25
  • 1
    actually, skimming that documentation says that it's specifically for patching SDL similar to preloading with the runtime linker. essentially it's something like a function table that you can use to hijack SDL entrypoints (or something). perhaps this supports whatever it is you're trying to do with said game.
    – Ali Rizvi-Santiago
    Commented Aug 9 at 16:26
  • @AliRizvi-Santiago Wow! I didn't know about that. That looks like it could do just what I need.
    – Sudo Bash
    Commented Aug 9 at 16:54
  • don't forget to select the answer before you leave.
    – Ali Rizvi-Santiago
    Commented Aug 10 at 2:35

1 Answer 1

Reset to default
1

I don't think there is an easy way for doing this. What I would do myself is the following:

  • Create your own library in C or C++ that does dlopen("your_new_sdl_lib.so").
  • Inject the library into your binary or patch it so it loads this library at startup.
  • Hook every single SDL_XXX() call and forward the call to your new SDL library (or, alternatively, patch every SDL_XXX() function so that they call into your new library).

While I am sure you can get it to work, consider it's not guaranteed it will without a hard to measure amount of work. Not only because some functions might be in-lined, but because you might also have the problem of global variables being used outside of the SDL_XXX() functions.

In the case of some functions being in-lined, you would need to patch these calls to forward to your new functions (finding which registers or memory positions contain whatever is required for the appropriate call), or cross your fingers and hope the function versions are still compatible (my experience says that in so many cases they are).

Hope it helps.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.