我发现自己最近在陌生的领域玩耍，在我的舒适区之外冒险去测试一些理论。目前我想在True每次特定程序调用时返回IsDebuggerPresent，而不实际调试程序。
由于我不是软件开发人员，我真的宁愿避免编写代码来进行 API 挂钩。我的下一个想法是kernel32.dll在与程序相同的目录中使用修改过的，指望“DLL 加载顺序劫持”。所以...我修改了 dll 的副本，基本上IsDebuggerPresent用mov eax, 1
如果我在 IDA 中打开 DLL 并检查导出，它会准确显示我修补的代码，但是如果我运行可执行文件，当它调用IsDebuggerPresent我修改的相同地址时，会显示正确IsDebuggerPresent指令的 JMP 。
我正在尝试做的甚至是可行的，还是必须进行 API 挂钩才能使其工作？我真的在寻找一个简单的 POC，所以再说一次，我宁愿不必为了测试理论而找出 C++ 的度量标准。
Windows 有一个可信库的概念来阻止这样的攻击：
从搜索顺序引用：
如果 DLL 在运行应用程序的 Windows 版本的已知 DLL 列表中，系统将使用已知 DLL 的副本（以及已知 DLL 的依赖 DLL，如果有），而不是搜索 DLL。有关当前系统上已知 DLL 的列表，请参阅以下注册表项：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs。
因此，对于您的情况，我建议尝试使用 API 挂钩 ;) 这真的不是太难（Windows 可以满足您所有阴暗的需求）。
编辑：
您可以继续使用 Windows Hooking API
但是，直接做自己是安静的：
使用 GetProcAddress 在您的地址空间中查找 GetDebuggerPresent（Windows 不喜欢 ASLR）。您可以假设它位于另一个进程中的相同位置。
备份前几个字节 (ReadProcessMemory)，插入任何钩子 (WriteProcessMemory) 并编写代码 (VirtualProtectEx)。
侧节点：您可能需要先提升进程的权限（OpenProcessToken，...）。
编辑2：
我找到了一些我的旧代码。你可以在这里找到它。请注意，此代码是为避免沙盒检测的研究项目而编写的，而且我当时还是一名学生（即代码可能质量不高）。
如上所述，对于某些 Windows DLL，仅将 DLL 放在同一目录中是不够的，因为 Windows 会按照有关Dynamic-Link Library Search Order 的文档搜索特定路径中的那些。
但是，knownDlls 列表有一些潜在的技巧，您可以操纵它以成功替换 DLL：
您可以从列表中删除特定的 DLL，允许您自己（和其他人，从而使机器面临一些潜在风险）从应用程序的位置加载所述 DLL。
您可以替换存储为同一注册表路径中的键值的 DLL 名称。而不是 DLL 名称，只需放置一个完整路径，DLL 将从您指定的位置为所有进程加载。
尽管可能不建议这样做，因为存在恶意实体利用这些更改来劫持您机器上的 DLL 的风险，但这绝对是一种无需编写任何 API 挂钩代码即可测试您的努力的简单方法，如要求:)
另一种方法是搜索一些预制的 API 挂钩实用程序（有、有、很多）