fix(user/module): read version from libcrypto.so

[xxxxxliil]

Since OpenSSL 3.0, in the built dynamic link library product, the symbols in libssl.so no longer contain the OPENSSL_VERSION_TEXT string, causing eCapture to be unable to accurately identify the version of OpenSSL, causing it to fail to work properly.

For more information please refer to: #675

fix: #609

original info

openssl 3+（尚未排查出是哪个 commit 导致）不再把版本号放入 libssl.so 的 .rodata 段中，导致自动检测失败从而回落到 openssl 3.0.0。 幸运的是 libcrypto.so 的 .rodata 段中有期望的版本号字符串且 libssl.so 链接到 libcrypto.so，自动获取 libssl 路径时从 libcrypto.so 读取是一个低成本的解决方案。 debian 的 libssl3 包 与 fedora 的 openssl-libs 包会把 libcrypto.so 和 libssl.so 打包在一起，没有查看 alpine 这类更小的发行版是否发生拆分。只能乐观地假设 libssl.so 存在但 libcrypto.so 不存在是不可接受的（环境损坏）。

[xxxxxliil]

我需要提供什么额外的说明吗？

[cfc4n]

尽量解析openssl 3.x so文件内的版本号，实现精确匹配吧。

[xxxxxliil]

尽量解析openssl 3.x so文件内的版本号，实现精确匹配吧。

我用 cutter 看过字符串， libssl.so dynstr 段里只有多个 0 结尾且不能精确表达版本信息的版本号，而且这样版本号不能匹配 openssl 3.2.3 和 openssl 3.3.2。

[cfc4n]

能否尝试找其他特征？ 当前PR的修复方式，很不准确，我不赞成这个方格式。

[xxxxxliil]

抱歉，我目前只能想到这种依赖 libcrypto.so 但是相对更精确的方式。除非可以从没有调试信息的 libssl.so 搜索各种偏移

[cfc4n]

嗯，晚点我看看吧。

[blaisewang]

@cfc4n 有个想法是通过猜测来判断当前 libssl 的版本，例如 ssl_connection_st->version 的值只可能是 SSL2_VERSION / SSL3_VERSION / TLS1_VERSION / DTLS1_VERSION，version 的 offset 固定是 ssl_st_ptr + 0x40

这样可以区分新旧版本。更细的话需要分析各个结构体可能存在什么值，尝试去读以判断属于某个版本。

或者更暴力一点，在 key log 模式下 + OpenSSL 3.0 下直接尝试读取对应内存的所有可能偏移的值，终究会命中一个？

[cfc4n]

准确性太差了吧。 一段字节流，映射成ssl结构体时，没法简单的从ssl_connection_st->version的值判断映射是否正确，说不定偏移到ssl_connection_st->unknow上，得到的也是SSL2_VERSION / SSL3_VERSION / TLS1_VERSION / DTLS1_VERSION的一种。

[blaisewang]

再寻找一下其它位置的常量或者有限变量，不过确实很难 100% 准确

[xxxxxliil]

当前PR的修复方式，很不准确，我不赞成这个方格式。

有一个问题：这里说的”不准确“指的是什么方面的不准确？是说会碰到 ssl.so 与 crypto.so 不匹配的现象？还是担心输入路径的 ssl.so 不会依赖 crypto.so 这种比较特殊的情况

[cfc4n]

是的，我对crypto.so跟libssl.so.3 的对应关系有担忧，不能用crypto.so使用的依赖情况，反向推论libssl.so.3 的版本。

这需要一些真实的样本来论证，能否提供一些呢？

[blaisewang]

OpenSSL 这个二进制程序可以动态链接不同的 libssl.so 和 libcrypto.so，虽然正常情况下应该是一致的，但是实际上不一定保证完全一致。

[xxxxxliil]

那么我们要验证的就是 ssl.so 是否必须要用特定版本的 crypto.so 了？
目前可以确定的是 OpenSSL_version() 是 crypto.so 提供的

[cfc4n]

那么我们要验证的就是 ssl.so 是否必须要用特定版本的 crypto.so 了？ 目前可以确定的是 OpenSSL_version() 是 crypto.so 提供的

没错，在3.0里，确实是使用了libctypto.so内的导出符号OpenSSL_version()函数。

一些进展：

在2019年，OPENSSL_VERSION_TEXT信息存放于 include/openssl/opensslv.h (Generated by build.info )

refer:
openssl/openssl@f386632
openssl/openssl#10203

之后OpenSSL 1.1.x的版本会构建libssl.so\libcrypto.so，两个链接库文件中的.rodata段中，都包含了OPENSSL_VERSION_TEXT信息。

• 1.1.x : opensslv.h--> crypto.h --> ssl_init.h
• 3.x : opensslv.h--> crypto.h --> ???

OpenSSL 3.0后，更改了头文件的引入，在libssl.so的相关代码中，不再引用关于OPENSSL_VERSION相关字符串，所以3.0的libssl.so版本中，不再包含OPENSSL_VERSION_TEXT信息。

未完待续

[blaisewang]

libssl.zip

我提供了从 OpenSSL 3.0.0 到 OpenSSL 3.4.0 所有正式版本构建的 libssl.so 文件，供有兴趣的朋友研究一下 binary diff

构建命令
git submodule update --init --recursive && ./config && make -j$(nproc)