How to patch 3rd party .so file, to access non-exported symbol (C++)

Question

I have some binary .fic files in a proprietary format , I have a wd250hf64.so from this vendor that contains a C++ method CComposanteHyperFile::HExporteXML(wchar_t* const path)

that I can see using nm

$ nm  --demangle   wd250hf64.so  --defined-only 


0000000000118c90 t CComposanteHyperFile::HExporteXML(wchar_t const*)

the unmangled version _ZN20CComposanteHyperFile11HExporteXMLEPKw is identical to what I have using my local g++ version

readelf gives

readelf -Ws wd250hf64.so  | grep _ZN20CComposanteHyperFile11HExporteXMLEPK

 19684: 0000000000118c90   119 FUNC    LOCAL  DEFAULT   11 _ZN20CComposanteHyperFile11HExporteXMLEPKw

now I try writing a very simple program

class CComposanteHyperFile {
    public:
    static void  HExporteXML(wchar_t const*);
};



int main() {
    CComposanteHyperFile::HExporteXML(L"file.fic");
    return 0;
}

but when I compile it with g++ toto.cpp -L. -l:wd250hf64.so

I got toto.cpp:(.text+0x10): undefined reference to 'CComposanteHyperFile::HExporteXML(wchar_t const*)'

I don't have more luck with dlopen

#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>

int
main(int argc, char **argv)
{
    void *handle;
    void (*exportXML)(wchar_t const*);
    char *error;

   handle = dlopen("wd250hf64.so", RTLD_LAZY);
   *(void **) (&exportXML) = dlsym(handle, "_ZN20CComposanteHyperFile11HExporteXMLEPKw");

   if ((error = dlerror()) != NULL)  {
        fprintf(stderr, "%s\n", error);
        exit(EXIT_FAILURE);
    }

    dlclose(handle);
    exit(EXIT_SUCCESS);
}

gcc -rdynamic -o foo toto.c -ldl
./foo
wd250hf64.so: undefined symbol: _ZN20CComposanteHyperFile11HExporteXMLEPKw

I understand that as it is not shown by nm with --extern-only it may be that this symbol is not "exported" and so it's not supposed to work normally

my question is

What is the hackish way of making the program to compile, by all means, even if it means manually patching the .so file ?

You usually do not specify the library file directly as ordinary input to gcc but rather via the [`-l` flag](https://stackoverflow.com/q/15727211/3740047). I.e. it should be `g++ toto.cpp -L. -l:wd250hf64.so`. Does this solve the problem? Otherwise, you could always try to load the library [dynamically via `dlopen`](https://stackoverflow.com/q/4651803/3740047). — Sedenion, Jun 26 '22 at 10:17
@Sedenion thanks for your help , however `g++ toto.cpp -L. -l:wd250hf64.so` returns the same error — allan.simon, Jun 30 '22 at 09:57
@Sedenion I tried with dlopen, but same issue (I edited my question to put the code i used for dlopen ) — allan.simon, Jun 30 '22 at 10:14
I'd try producing my own dummy shared library, then comparing the two. — HolyBlackCat, Jun 30 '22 at 10:15
See this [answer](https://stackoverflow.com/a/37534357/6752050). I think it explains why you can't bind the app to that symbol. I think this symbol will disappear after `strip`. — 273K, Jul 01 '22 at 02:55
Does `LD_LIBRARY_PATH` contains the path to your library `wd250hf64.so`? Also, why do you specify a colon `:` in the command `-l:wd250hf64.so`? — kiner_shah, Jul 01 '22 at 07:06
@kiner_shah not specifying `:` i.e" g++ toto.cpp -L. -l wd250hf64.so" (with or without the space after the `-l` cause a `/usr/bin/ld: cannot find -lwd250hf64.so` — allan.simon, Jul 01 '22 at 07:21
@allan.simon, is the path to the library present in `LD_LIBRARY_PATH`? — kiner_shah, Jul 01 '22 at 07:22
@kiner_shah I put the `.so` in my current directory, and normally -L. is here for that, in any case, I added also the absolute path by re-exporting `export LD_LIBRARY_PATH=$(pwd):$LD_LIBRARY_PATH` but still the same issue — allan.simon, Jul 01 '22 at 07:27
@273K thanks, unfortunately I did know that, and it's more about "but then how to workaround that" , as the symbol is there , the code is there in the file, so what is the hack to do to make it visible . I've edited my question to make it clearer that I know there will be no 'clean' solution — allan.simon, Jul 01 '22 at 07:29
In this case the first answer to your question is worth to attempt. Why do you think the method is static and returning void? It can be non-static and return a smart pointer. — 273K, Jul 01 '22 at 07:43
@273K , indeed the answer seems worth trying , it's in my todo for today :) regarding static and return type, actually I don't know , my knowledge are very limited , so i assumed that if there was no return type it was void, so you mean there's no way for me to know purely based on the symbol, to know the return type and static/not static ? — allan.simon, Jul 01 '22 at 08:18
Yes, there is no way to know the return type and static or not static method. — 273K, Jul 01 '22 at 14:55
@273K ok so if it's not static or it return something else, at worse it will segfault , because the linked itself can not know that i'm wrong, right ? — allan.simon, Jul 01 '22 at 15:17

Mona the Monad · Accepted Answer · 2022-06-30T19:40:21.233

2

If you really want to be able to get at that symbol in any way possible, you could try to get its address relative to that of a known exported symbol, assuming that they're in the same section. For example, I made a simple dummy library with one exported function and one non-exported function.

0x0000000000003890    12 FUNC    GLOBAL DEFAULT    16 function_we_exported
0x00000000000038a0    12 FUNC    LOCAL  HIDDEN     16 function_we_forgot_to_export

Because this library was contrived just for this answer, the non-exported function happens to be right next to it, 0x10 after function_we_exported. Using this information, we can hackily do this.

const auto address = reinterpret_cast<char*>(dlsym(library, "function_we_exported"));
reinterpret_cast<your_function_type>(address + 0x10)(...);

As you can probably tell, this is pretty hacky, but if you have no other choice, I suppose this can be a way. Another way may be to patch the library and forcibly export it. Considering that they show up as GLOBAL/LOCAL and DEFAULT/HIDDEN, it's probably a flip of a flag or something, but I don't know how to do that at the moment. I'll update this answer if I do.

edited Jun 30 '22 at 19:40

answered Jun 30 '22 at 18:52

Mona the Monad

2,265
3
19
30

thanks, yes I know that i will have to resort to a hackish solution, as I don't own the source of the `.so` :) I think the patching thing may be do-able with https://lief-project.github.io/doc/latest/tutorials/03_elf_change_symbols.html# but It's not my area of expertise, so maybe that can help you helping me haha – allan.simon Jul 01 '22 at 07:18
ok so I wasn't able to go much further but i was able to change from "LOCAL" to global by using lief and doing ` x = lief.parse('wd250hf64.so') ; w = x.get_symbol('_ZN20CComposanteHyperFile11HExporteXMLEPKw') ; w.exported = true ; x.write('newlib.so') ` and now newlib.so contains the symbol with local changed to global – allan.simon Jul 01 '22 at 12:29
import lief x = lief.parse('newstuff.so') x.add_exported_function(0x118c90, '_ZN20CComposanteHyperFile11HExporteXMLEPKw') x.write('newstuff.so') and now it works :) 0x118c90 being the address I saw with `nm` – allan.simon Jul 02 '22 at 10:54

How to patch 3rd party .so file, to access non-exported symbol (C++)

1 Answers1