最近我研究了一个 Linux 程序，它的所有符号都被剥离了。用 IDA 打开它导致没有识别出它的任何功能。
因此，我尝试使用strings和file命令从可执行文件中提取任何可用信息，但遗憾的是这些信息一无所获。
我知道 IDA 中的 FLIRT 技术，但它基于了解静态库的版本，因此它可以使用正确的签名文件。在这种情况下，我们似乎没有使用glibc或其他库的任何版本信息，那么我们现在该怎么办？
$ file stripped
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, stripped
有了file如上所示的输出，我可以从中检索更多详细信息吗？还是我们只能通过我们的经验来识别它的解决方案？
简短回答 - 不，没有简单的方法可以识别可执行文件中的静态链接函数，除了手动对 API 进行逆向工程或找出确切使用 glibc 的版本。
不幸的是，即使您确定了确切的 glibc 版本，使用 FLIRT 也可能没有用。这是因为实际指令将在静态链接过程中被改变。例如，如果很少使用或相对较短，则某些函数可能会被内联。高级优化可能会让事情变得更糟。
但是，您可以很容易地找到SYSENTER（或者int 0x80如果使用旧版本的 glibc/linux）指令并将它们映射到内核回调。显然，许多 API 功能是在从未访问内核的情况下实现的，您需要更加努力地恢复。其他 glibc 函数可能会在内存方面相邻（取决于编译可执行文件时链接器的配置），因此找到一些静态链接的 API 可以帮助您恢复其他函数。
我可以给您的最后一点建议是，适当地重命名您确定为 glibc 一部分的所有函数，即使没有实际确定它们的功能glibcsub_*或类似的易于识别的模式。我想你会发现这很有用。
但是有统计数据，可用于查找基本库函数，您可以从中找到其他函数。例如，代码不分配任何内存并且不进行任何字符串操作的可能性几乎为零。因此，您可以将 XREFS 计入所有函数，并确保调用最多（并从二进制文件的所有部分调用）的函数是库函数。知道malloc在哪里后，就可以找到free，有了malloc和free之后，就可以找到其他使用malloc/free的库函数。所以，如果你准备好花时间，你可以自己找到库函数。