YimMenu中dynamic_hook调用原始函数异常问题解析

YimMenu中dynamic_hook调用原始函数异常问题解析

YimMenu YimMenu, a GTA V menu protecting against a wide ranges of the public crashes and improving the overall experience. 项目地址: https://gitcode.com/gh_mirrors/yi/YimMenu

问题背景

在YimMenu项目的Lua脚本开发中，使用dynamic_hook功能时遇到一个典型问题：当在detour函数中返回true以调用原始函数时，程序会抛出异常。这个问题在多个函数调用场景下都能复现，表现为当尝试执行原始函数时系统崩溃。

问题现象

开发者提供的示例代码展示了一个典型的使用场景：通过内存扫描获取函数地址后，使用dynamic_hook进行hook操作。在detour函数中，当对特定哈希值进行判断后修改参数值，并尝试通过返回true来调用原始函数时，程序会抛出异常。而如果返回false不调用原始函数，则能正常工作。

根本原因分析

经过深入排查，发现问题根源在于参数类型声明不准确。原始代码中使用的参数类型声明为：

{ "int", "int", "int", "bool" }

而实际上，这些参数应该对应更精确的类型：

{ "int64_t", "int", "uint16_t", "bool" }

技术原理详解

1. 类型系统差异：

   • Lua中的get_type_info_from_string函数会将所有整数类型(包括int64_t、uint16_t等)统一返回为type_info_t::integer_类型
   • 这种设计是为了简化Lua层面的类型处理，但在底层调用时仍需要精确的类型信息

2. 底层调用机制：

   • dynamic_hook的参数类型数组有两个关键作用：
     • 指导asmjit生成正确的汇编代码来调用原始函数
     • 确保生成的detour函数能正确处理传入参数
   • 当类型声明不匹配时，寄存器的高位数据可能被错误处理，导致调用异常

3. 寄存器使用问题：

   • 对于64位寄存器，如果实际只使用低16位(uint16_t)，但声明为int，可能导致高位数据被错误解释
   • 类似地，64位整型参数如果声明为32位int，会丢失高32位数据

解决方案

确保在dynamic_hook调用中准确声明参数类型。对于示例中的函数，正确的类型声明应为：

{ "int64_t", "int", "uint16_t", "bool" }

最佳实践建议

1. 精确类型声明：

   • 始终使用最精确的类型声明(int8_t, uint16_t, int32_t, int64_t等)
   • 避免使用泛化的"int"类型，除非确定参数确实是32位有符号整数

2. 参数分析技巧：

   • 通过反汇编分析原始函数的参数大小和符号特性
   • 注意指针参数应声明为"int64_t"而非"int"

3. 调试方法：

   • 当遇到调用异常时，首先检查类型声明是否准确
   • 可以尝试逐步调整类型声明来定位问题参数

总结

这个案例展示了在底层hook操作中类型精确性的重要性。YimMenu的dynamic_hook机制虽然提供了强大的功能，但也要求开发者对底层调用约定有清晰的理解。通过准确声明参数类型，可以避免类似异常问题，确保hook操作的正确性和稳定性。

YimMenu YimMenu, a GTA V menu protecting against a wide ranges of the public crashes and improving the overall experience. 项目地址: https://gitcode.com/gh_mirrors/yi/YimMenu