在流放路径客户端中 NOPed 加密/解密功能,现在它在没有消息的情况下崩溃。下一步?

逆向工程 艾达 视窗 加密 联网
2021-06-27 14:54:16

我正在反转一个旧的流放之路客户端,目的是构建一个模拟器。我设法在较新的 64 位客户端中进入角色选择屏幕,但我正在努力在较旧的 32 位客户端中取得相同的进展。FWIW 他们使用相同的加密设置、CryptoPP 库和带有公钥加密的 Salsa20。我只是想 NOP 加密功能,所以我可以忽略它。

我发现Call EDX在之前send和之后不久recv都调用了函数,这些是唯一可能与 crypt 相关的函数调用。在NOPing这两个函数之后,我确实确认了第一个登录数据包以明文形式发送了用户名,所以我认为我的加密跳过是好的。但是客户端在收到我的第二个服务器数据包时崩溃了。未修改的客户端此时抱怨无法反序列化我发送的数据包。

我引用了一个巨大(600MB)的解密数据包集合,有人非常慷慨地与我分享,以制作我的服务器响应。

我的问题是 - 我接下来应该看哪里? 我正在考虑将 API Monitor 设置为仅监视 exe 发出的每个调用,以查看发生的最后几件事,到目前为止我只监视与网络相关的调用。或者我应该首先确认我 NOPing 的调用是唯一与 crypt 相关的函数?我对此还是个新手,不确定我的时间最好花在哪里。感谢您提供的任何一般见解!

2个回答

根据调用约定,您取消的间接调用可能以“RET nn”结尾。IIRC 这实际上是 Microsoft 的 x86thiscall约定变体中的情况如果你 NOP 的呼出,ESP是错误的呼出。如果ESP不再在该函数中使用,这是无害的,它以使用LEAVEor的标准结尾结尾MOV ESP, EBP,但它也可能导致非常奇怪的崩溃。

另一种可能性是您不再调用的函数返回一个 C++ 对象。这种情况下的调用约定是被调用函数构造对象,但被调用者稍后必须销毁它。如果你 NOP out 构造,它会导致破坏未初始化的内存,这也很可能会崩溃。

在你的情况下,我不认为它是第二个问题,因为这会在 x64 和 x86 上出现,而不仅仅是在 32 位二进制文​​件上——但我不会做出任何硬性声明,因为幸运的是,破坏未初始化的对象可能不会偶然坠毁。

结果我看错了等式的部分。加密/解密实际上被正确绕过,但我仍然将密钥作为第一个数据包发送,因为这在以后的版本中有效。在这个特定的客户端中,我不得不完全跳过发送密钥,而只是从“登录成功!”开始。包。一旦我这样做了,我就进入了角色选择。感谢您的回复! 算我一个! 只需再走 10 亿步……