发现共享库的公共方法(Discover the public methods of a shared library)

发现共享库的公共方法(Discover the public methods of a shared library)

除了扩展动态链接共享库之外？ 我想知道如何获得具有封闭源的共享库的所有公共方法的列表。

我努力了

nm -D libfoo.so readelf -s libfoo.so

但在那里我遗漏了诸如返回类型，参数等信息。

作为这个领域的初学者，我甚至无法弄清楚这些方法对于我的应用程序是可调用的。

有人有更有用的工具吗？

编辑：

举个简单的例子，我有以下几点：

libtest1.c：

int puts(char const *); void libtest1() { puts("libtest1: called puts()"); }

然后我将libtest1.c编译为libtest1.so：

gcc -fPIC -shared -o libtest1.so libtest1.c

在我的“程序”（test.c）中，我使用共享库如下：

void libtest1(); //from libtest1.so int main() { libtest1(); }

并编译test.c来测试：

gcc -o test test.c -ltest1 -ldl

这将工作，虽然我没有libtest1.h包括。 它只是“正常”，因为我知道可能有一个libtest1（） - 方法来调用。

现在想想我丢失了libtest1.c并且只掌握了libtest1.so并且不记得方法有什么以及它们需要什么样的参数。

这是一个愚蠢的例子，我知道:)

或者作为另一个例子（可能更好）：

让我们假设我在我的系统中的某个地方找到了一个“libstone2goldconverter.so”并且想“我的上帝，我会用它”但是怎么样？

In addition to Extend a dynamic linked shared library? I would like to find out, how I can get a list of all public methods of a shared library with closed source.

I have tried

nm -D libfoo.so readelf -s libfoo.so

but there I'm missing informations like return type, arguments etc.

As a beginner in this area, I can't even figure out what of those methods would be callable for my application.

Has anyone a more helpful tool?

EDIT:

For a very simple example, I have following:

libtest1.c:

int puts(char const *); void libtest1() { puts("libtest1: called puts()"); }

Then I compiled libtest1.c to libtest1.so:

gcc -fPIC -shared -o libtest1.so libtest1.c

In my "program" (test.c) I use the shared library as following:

void libtest1(); //from libtest1.so int main() { libtest1(); }

And compile test.c to test:

gcc -o test test.c -ltest1 -ldl

This will work although I have NO libtest1.h to include. It works "just" because I know that there might be a libtest1()-method to call.

Now think of I lost libtest1.c and just have the libtest1.so in my hands and don't remember what there are for methods and what params do they need.

That's a stupid example, I know :)

Or as an other example (maybe better):

Let's assume I found a "libstone2goldconverter.so" somewhere in my system and think "oh my god, I will use it".. but how?

最满意答案

共享库通常（如果不总是）提供包含公共API的头文件。

因此，您应该尝试找到这些头文件，而不是尝试直接从库中获取（公共）函数，因为它们：

是编译您的应用程序所必需的 可能包含文档 包含开发人员预期的公共API

---

编辑 在您的示例中，您定义

void libtest1();

这应该通常进入属于库的头文件。 而不是你应该使用的定义：

#include "libtest1/public_api.h"

（或类似的东西，取决于您的库/标题名称）

如果你“失去”标题，那么图书馆变得“毫无价值”，因为你不再需要公共API并且需要猜测（这显然是不受欢迎的）。

之所以，不使用头文件，“只是”有效，是因为你实际上知道函数的定义。 编译器信任您的定义（因为它不知道您是否猜对了）并接受它。 当您要将目标文件链接到可执行文件时，链接器会尝试在库中查找对未定义函数的所有引用。 在此阶段，链接器会发现您的函数是否确实存在（使用正确的参数和返回类型），否则会生成错误。

对于libstone2goldconverter.so您应该很难找到随附的头文件（在您的系统上，支持网站，通过电子邮件发送作者等）。 因为没有头文件，你无法使用库（正确）。

这不仅适用于您（开发人员），也适用于库的所有者。 因此，您可以确定头文件确实存在于某处。 唯一的问题是：你的libstone2goldconverter.so库看起来是专有的，库的作者/公司不太可能给你他们的头文件，因为它严重损害了他们的营销地位......;）

A shared library usually (if not always) provides header files containing the public API.

So, instead of trying to grab (public) function directly from the library, you should try to find these header files, because they:

are required for compiling your application might contain documentation contain the public API as intended by the developer

---

EDIT In you example you define

void libtest1();

This should typically go into the header files belonging to the library. And instead of the definition you should use:

#include "libtest1/public_api.h"

(or something similar, depending on your library/header names)

If you 'lose' the header then the library becomes 'worthless', as you do not know the public API anymore and need to guess (which is obviously undesired).

The reason why, not using a header file, 'just' works, is because you actually know the definition of the function. The compiler trusts your definition (as it does not know whether you guessed it or not) and accepts it. When you are going to link your object files into the executable, the linker tries to find all references to undefined function in libraries. During this stage the linker finds out whether your function actually exists (with the correct parameters and return type), if not it will generate an error.

In the case of libstone2goldconverter.so you should look really hard to find the accompanying header files (on your system, supporting website, by emailing the author, etc.). As there is no way you can use the library (properly) without the header files.

This goes not only for you (the developer), but also for the owner of the library. So, you can be certain that the header files do exists somewhere. Only thing is: your libstone2goldconverter.so library look proprietary and the author/company of the library is not likely to give you their header files, as it severely compromises their marketing position... ;)