加密例程不太可能在您的调用堆栈中，因为它实际上不会直接调用发送函数。

我建议您在缓冲区内设置一个观察点，以便在写入缓冲区时进行捕获。写入缓冲区的例程可能会从某个输入缓冲区读取。添加标头/校验和可能需要几个步骤，但如果您继续向后前进，您可能会发现一个读取未加密数据并写入加密数据的函数。

在一些游戏中，我发现加密是在发送调用之前，例如调用发送有时会调用 2-3 次的函数。

对于 recv，它是在解密之后解密的，但首先解密了它的一部分，以便用于查找大小/id 的标头。

其他人有压缩包（zlib），这需要一些计算。

查看是否可能被压缩或加密良好的一个技巧是尝试压缩数据（如果足够大），如果它没有得到任何有意义的压缩，那么它已经被压缩或加密到足以看起来随机。

因此，应用程序可能会调用 recv 或其他一些函数来获取数据。然后它可能会解密某些标识符或长度，例如数据包 ID 查找大小或标头中的大小。

第一次尝试发送 20 个 A 字符重新启动应用程序并发送 23 个 A 字符

逐个字节地做差异，看看有什么不同。

有时加密密钥可能首先由服务器发送，在这种情况下，查找单个字节、字节块等，这些字节在第一次接收时复制到某处，找到对该或内存的引用（在其上添加读取断点），您可能会找到您的加密和/或解密例程。

具有相同输入数据的多个连接是否在线路上发送了相同的数据？

你能发送一些可靠的信息并嗅探它以查看它的样子吗？

例如，如果它的第一个数据包登录，并且在连接后直接发送。

发送一长串 AAAAAAAAAAAAAAAAAAAAAA 并观察数据。

看起来像吗

10 00 01 00 C9 C9 C9 C9 C9 C9 C9 C9 C9 C9 C9 C9 C9 C9 C9 C9

例如，这将表明类似异或的东西。如果 xor 观察许多数据包并查找您经常看到的字节，例如 00 xor by something 就是值。

也可能看起来更混乱或 4 个字节或某个长度的块。例如，如果您看到重复序列，例如 C9 EF AD CC C9 EF AD CC，并且您知道输入数据是一长串“A”，那么它就是一个模式。

我见过一些实现，其中使用了像河豚这样的东西，最初是种子但他们没有处理将数据包完全填充到块长度的倍数，因此奇数字节显示为纯文本。

如果数据从第一次发送时每次都不同而没有其他接收，则可能是基于时间的加密基于您的连接时间，或者客户端只是选择随机密钥并告诉服务器它。

例如，如果从客户端发送到服务器的第一个数据包是 32 字节的乱码，它可能是一个密钥或初始化向量来播种块密码或其他东西......

一个软件是这样的。自定义发送（数据，长度）

将字节复制到缓冲区，由数据包头偏移。用长度填充标题。使用另一个函数加密整个内容（在发送之前查找循环或在发送之前调用的包含循环的函数可能更高或更深，但您应该跟踪数据缓冲区发生的情况，您需要向后执行此操作。

向后跟踪代码有时会很棘手，我发现如果您能找到一些您知道会提交一些已知数据以发送到此套接字操作/数据包的内容，则前进会更容易。有时这是在连接之后或第一次接收之后。或者在聊天框中按 Enter 键后。

也不保证加密和解密使用相同的加密或密钥。

它也可以是某种非对称加密，例如一个密钥进行加密但另一个解密，每一端只知道与另一端发送或接收数据所需的密钥。

或者他们可以狡猾地对前几个数据包以一种方式加密数据，并在协商使用密钥后将其切换。

如果您碰巧使用 IDA 或者 Ghidra https://github.com/d3v1l401/FindCrypt-Ghidra 或其他工具上有替代方案 ？您可以使用 FindCrypt 之类的东西来查找已知的加密算法 https://www.hex-rays.com/blog/findcrypt/，通过查看使用/引用它们的内容，您可能会以这种方式找到加密/解密。

听起来很有趣，希望你能在这方面取得一些进展。