CallEvent::isCalled()替代方案：函数指针调用下的句柄泄漏检测

遇到这种通过模板参数传递关闭函数指针导致Call.isCalled()失效的情况确实挺头疼的——毕竟工具默认大多只追踪直接的符号调用，对间接的指针调用识别能力有限。结合我做类似句柄泄漏检测的经验，给你几个可行的替代思路：

1. 直接基于函数地址做调用匹配 #

绕过符号层面的isCalled()检查，直接比对调用的目标内存地址和CloseHandle的实际地址。不管是直接调用还是通过指针跳转，最终执行的都是CloseHandle的代码段，所以只要在CallEvent中拿到调用的目标地址（比如你的检测框架提供了getTargetAddr()这类API），和&CloseHandle的地址做对比，就能准确识别出所有调用场景，包括函数指针的情况。

这里要注意：如果开启了ASLR（地址空间布局随机化），不要硬编码地址，要在程序启动时动态获取CloseHandle的地址（比如通过GetProcAddress(GetModuleHandleA("kernel32.dll"), "CloseHandle")）。

2. 追踪函数指针的赋值与调用关联 #

针对模板类传递函数指针的场景，你可以在模板实例化的阶段做拦截：

• 当检测到模板类（比如HandleWrapper<CloseFunc>）以&CloseHandle作为模板参数实例化时，记录这个模板实例对应的函数指针成员（比如CloseFunc close_ptr）。
• 后续在检查器中，只要检测到这个成员被调用，就直接判定为CloseHandle已执行。

这种方法需要你的检测工具支持模板实例化的分析，能提取模板参数中的函数指针类型并关联到具体的函数。

3. 结合污点分析追踪句柄生命周期 #

把需要检测的句柄标记为"污点"，从它的创建点（比如CreateFile、OpenProcess等返回句柄的函数）开始追踪：

• 当任何函数调用的参数是这个污点句柄时，检查该调用的目标地址是否是CloseHandle（或其他对应类型的关闭函数，比如FindClose）。
• 只要匹配成功，就标记该句柄已被正确关闭，无需关心调用是直接还是通过指针发起的。

这种方式更聚焦于句柄本身的生命周期，能覆盖所有可能的关闭路径，包括那些非常间接的调用场景。

4. 增强模板场景的特殊处理 #

如果你的检测工具支持，可以专门针对模板类做规则适配：

• 识别出以"关闭函数指针"为模板参数的类结构，提取模板参数对应的函数（比如从decltype(&CloseHandle)解析出目标函数是CloseHandle）。
• 把这类模板类中调用函数指针的方法，直接映射为对应关闭函数的调用事件，这样后续用类似isCalled()的逻辑就能识别到。

额外注意事项 #

• 要处理函数指针的别名问题：同一个CloseHandle可能被多个指针变量引用，确保所有指向它的指针调用都能被识别。
• 如果是静态分析工具，可能需要更复杂的指针指向分析（比如基于SSA形式的数据流分析）；如果是动态插桩工具，拦截所有函数指针调用并检查目标地址会更直接。

内容的提问来源于stack exchange，提问作者Artem Razin