用于跟踪 CreateFile 调用的 Pin 工具

Posted 2023-02-14

【中文标题】用于跟踪 CreateFile 调用的 Pin 工具

【英文标题】：Pin tool for tracking CreateFile calls

【发布时间】：2012-12-15 03:52:43

【问题描述】：

我制作了一个 pin 工具来转储 CreatFile win32 调用（在我的例子中为 CreateFileW）及其返回值。它看起来像这样：

/* ... */

VOID Image(IMG img, VOID *v)

    RTN cfwRtn = RTN_FindByName(img, "CreateFileW");
    if (RTN_Valid(cfwRtn))
    
        RTN_Open(cfwRtn);

        RTN_InsertCall(cfwRtn, IPOINT_BEFORE, (AFUNPTR)CreateFileWArg,
        IARG_ADDRINT, "CreateFileW",
        IARG_FUNCARG_ENTRYPOINT_VALUE, 0,
        IARG_END);
        RTN_InsertCall(cfwRtn, IPOINT_AFTER, (AFUNPTR)CreateFileWafter,
        IARG_FUNCRET_EXITPOINT_VALUE, IARG_END);

        RTN_Close(cfwRtn);
    


/* ... */

VOID CreateFileWArg(CHAR * name, wchar_t * filename)

    TraceFile << name << "(" << filename << ")" << endl;


VOID CreateFileWafter(ADDRINT ret)

    TraceFile << "\tReturned handle: " << ret << endl;

它给出了有趣的结果。例如，在一个只打开一个现有文件并且什么都不做的小程序上，它给出：

CreateFileW(file.txt)
    Returned handle: 0
CreateFileW(file.txt)
    Returned handle: 0x74
    Returned handle: 0x74

很多异常。 1.) 为什么有两个实际调用？ 2.) 如果我没记错的话，CreateFile 永远不应该返回 0。 3.) 在第二次调用之后，它会返回两次 (?)

我还尝试了一个简单的 c++ 程序，直接调用 CreateFileW 一次，结果：

CreateFileW(file.txt)
    Returned handle: 0
CreateFileW(file.txt)
    Returned handle: 0xffffffff
    Returned handle: 0xffffffff

我试图打开的文件不存在，所以返回值（-1 == INVALID_HANDLE_VALUE）至少是正确的。

有什么想法吗？提前致谢！

【参考方案1】：

我会建议在系统调用级别捕获它，而不是在其中一个不确定的中间级别（无论它托管在哪个库中）。在windows上，系统调用号和接口都不是官方公开的，但无论如何都可以很容易地找到。

【讨论】：

但是我们如何区分来自主应用程序的系统调用和不是来自主应用程序的系统调用？

看看Nt和Zw函数docs.microsoft.com/en-us/windows-hardware/drivers/kernel/…

@Maysara Alhindi：这是一个很好的观点。虽然这取决于主要应用程序。我会尝试通过他们的论点来过滤它们。您应该对来自主应用程序的系统调用参数有提示。如果不是，这确实不是正确的解决方案。

【参考方案2】：

好的，经过一段时间我终于弄清楚了这些问题的原因。

关于返回值显示为0：

好吧，PIN 文档说：

注意：IPOINT_AFTER 是通过在例程中检测每个返回指令来实现的。 Pin 尝试查找所有返回指令，但不保证成功

如果你在返回时转储函数的地址，结果是 0 不是从 CreateFileW 返回的。它是从 CreateFileW 调用的另一个函数返回的。 PIN 的这种错误行为可以通过在您自己的版本中包装 CreateFileW 方法来修复（转储参数、调用原始函数、转储返回值）。

关于两个函数调用，而不是只有一个：

原来在我的系统上，CreateFileW 调用了同名的 Kernelbase.dll 函数。由于我按其名称检测例程，因此这是正确的行为。根据 kernel32.dll 检查图像名称解决了这个问题。

【讨论】：

感谢您提供有关尝试检测此类功能时可能遇到的经典（但不可预测）陷阱的宝贵信息。