Bionic and libc’s stub implementations

Issue

I’d like to run an x86 shared library that I grabbed from an apk on a non-android linux machine.

It’s linked against android libc, so I grabbed the libc.so from the android ndk. After debugging segfaults for a while, I figured that libc.so is “cheating” and contains only nop implementations of many library functions:

$ objdump -d libc.so | grep memalign -A 8
0000bf82 <memalign>:
    bf82:       55                      push   %ebp
    bf83:       89 e5                   mov    %esp,%ebp
    bf85:       5d                      pop    %ebp
    bf86:       c3                      ret    

Now the ndk also contains a libc.a that contains actual implementations of these functions, but how do I get my process to load these and override the nop functions of libc.so? Would also be interested on some more context on why android is doing this trick and how the overriding works there.

Solution

As you see libc.so that is taken from NDK contains only stubs, since its purpose it to provide necessary information to linker during creation of your own shared library or executable. Here is nice explanation of why we need stub libraries.

So if you need a real libc.so binary - there are two alternatives:

1. grab it directly from Android device:

   $ adb pull /system/lib/libc.so <local_destination>
   

2. Download factory ROM image for your device, unpack it, mount system.img to your local filesystem, and then again copy it from /system/lib of that mounted partition.

But even if you get proper binary it is a really painful exersize - to make it working on your desktop Linux. There are at least two reasons:

1. Android and desktop Linux ELFs require different interpreters. You can check it with readelf:

   $ readelf --all <android_binary> | grep interpreter
   [Requesting program interpreter: /system/bin/linker]
   $ readelf --all <linux_x64_binary> | grep interpreter
   [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
   

   (Interpreter is a small program that performs actual loading of your binary and is loaded by kernel) Obviously your Linux system has no /system/bin/linker and kernel will reject loading of such binary. So you must somehow load sections properly and resolve all dependencies by yourself.

2. Android kernel is not the same as desktop one, it has some extra features that libc.so depends on, so even if you load ELF somehow it is still incompatible with your kernel and surely you'll get problems at some moment.

To top it off: it is practically impossible to reuse android binaries on desktop GNU/Linux even if they are targeted with the same hardware architecture.

Answered By - Sergio