Hook and Replace Export Function in the Loaded ELF ( .so shared library )

Question

I'm writing some C code to hook some function of .so ELF (shared-library) loaded into memory.

My C code should be able to re-direct an export function of another .so library that was loaded into the app/program's memory.

Here's a bit of elaboration:

Android app will have multiple .so files loaded. My C code has to look through export function that belongs to another shared .so library (called target.so in this case)

This is not a regular dlsym approach because I don't just want address of a function but I want to replace it with my own fuction; in that: when another library makes the call to its own function then instead my hook_func gets called, and then from my hook_func I should call the original_func.

For import functions this can work. But for export functions I'm not sure how to do it. Import functions have the entries in the symbol table that have corresponding entry in relocation table that eventually gives the address of entry in global offset table (GOT). But for the export functions, the symbol's st_value element itself has address of the procedure and not GOT address (correct me if I'm wrong).

How do I perform the hooking for the export function?

Theoretically speaking, I should get the memory location of the st_value element of dynamic symbol table entry ( Elf32_Sym ) of export function. If I get that location then I should be able to replace the value in that location with my hook_func's address. However, I'm not able to write into this location so far. I have to assume the dynamic symbol table's memory is read-only. If that is true then what is the workaround in that case?

Thanks a lot for reading and helping me out.

Update: LD_PRELOAD can only replace the original functions with my own, but then I'm not sure if there any way to call the originals. In my case for example:

App initializes the audio engine by calling Audio_System_Create and passes a reference of AUDIO_SYSTEM object to Audio_System_Create(AUDIO_SYSTEM **); AUDIO API allocates this struct/object and function returns. Now if only I could access that AUDIO_SYSTEM object, I would easily attach a callback to this object and start receiving audio data. Hence, my ultimate goal is to get the reference to AUIOD_SYSTEM object; and in my understanding, I can only get that if I intercept the call where that object is first getting allocated through Audio_System_Create(AUIOD_SYSTEM **). Currently there is no straight way to grab the output audio at android. (all examples talk about recording audio that comes from microphone only)

Update2: As advised by Basile in his answer, I made use of dladdr() but strangely enough it gives me the same address as I pass to it.

void *pFunc=procedure_addr;  //procedure address calculated from the st_value of symbol from symbol table in ELF file (not from loaded file)

        int  nRet;

            // Lookup the name of the function given the function pointer
            if ((nRet = dladdr(pFunc, &DlInfo)) != 0)
            {
                LOGE("Symbol Name is: %s", DlInfo.dli_sname);
                if(DlInfo.dli_saddr==NULL)
                    LOGE("Symbol Address is: NULL");
                else
                    LOGE("Symbol Address is: 0x%x", DlInfo.dli_saddr);
            }
            else
                LOGE("dladdr failed");

Here's the result I get:

entry_addr =0x75a28cfc

entry_addr_through_dlysm =0x75a28cfc

Symbol Name is: AUDIO_System_Create

Symbol Address is: 0x75a28cfc

Here address obtained through dlysm or calculated through ELF file is the address of procedure; while I need the location where this address itself is; so that I can replace this address with my hook_func address. dladdr() didn't do what I thought it will do.

Answer 1

You should read in details Drepper's paper: how to write shared libraries - notably to understand why using LD_PRELOADis not enough. You may want to study the source code of the dynamic linker (ld-linux.so) inside your libc. You might try to change with mprotect(2) and/or mmap(2) and/or mremap(2) the relevant pages. You can query the memory mapping thru proc(5) using /proc/self/maps & /proc/self/smaps. Then you could, in an architecture-specific way, replace the starting bytes (perhaps using asmjit or GNU lightning) of the code of original_func by a jump to your hook_func function (which you might need to change its epilogue, to put the overwritten instructions -originally at original_func- there...)

Things might be slightly easier if original_func is well known and always the same. You could then study its source and assembler code, and write the patching function and your hook_func only for it.

Perhaps using dladdr(3) might be helpful too (but probably not).

Alternatively, hack your dynamic linker to change it for your needs. You might study the source code of musl-libc

Notice that you probably need to overwrite the machine code at the address of original_func (as given by dlsym on "original_func"). Alternatively, you'll need to relocate every occurrence of calls to that function in all the already loaded shared objects (I believe it is harder; if you insist see dl_iterate_phdr(3)).

If you want a generic solution (for an arbitrary original_func) you'll need to implement some binary code analyzer (or disassembler) to patch that function. If you just want to hack a particular original_func you should disassemble it, and patch its machine code, and have your hook_func do the part of original_func that you have overwritten.

Such horrible and time consuming hacks (you'll need weeks to make it work) make me prefer using free software (since then, it is much simpler to patch the source of the shared library and recompile it).

Of course, all this isn't easy. You need to understand in details what ELF shared objects are, see also elf(5) and read Levine's book: Linkers and Loaders

---

NB: Beware, if you are hacking against a proprietary library (e.g. unity3d), what you are trying to achieve might be illegal. Ask a lawyer. Technically, you are violating most abstractions provided by shared libraries. If possible, ask the author of the shared library to give help and perhaps implement some plugin machinery in it.