True时都返回IsDebuggerPresent，而无需实际调试程序。由于我不是软件开发人员，所以我宁愿避免编写代码来进行API挂钩。我的下一个想法是，在与该程序相同的目录中使用经过修改的
kernel32.dll，指望“ DLL加载顺序劫持”。所以...我修改了dll的副本，从本质上用IsDebuggerPresent替换了mov eax, 1的导出如果我在IDA中打开DLL并检查了导出，它会准确显示我修补的代码，但是如果我运行该可执行文件，则当它使对
IsDebuggerPresent的调用与我修改的地址相同时，它会显示对正确的IsDebuggerPresent指令的JMP。我正在尝试甚至可行的是必须进行API挂钩才能使其正常工作？我真的是在寻找一个简单的POC，因此，我再次希望不必为了测试一个理论而计算出C ++的度量标准。
#1 楼
Windows具有受信任库的概念来阻止此类攻击：动态链接库搜索顺序
从搜索顺序中引用：
如果DLL在运行该应用程序的Windows版本的已知DLL列表中，则系统将使用其已知DLL（和已知DLL的从属DLL，如果有）的副本，而不是搜索DLL。 DLL。有关当前系统上已知DLL的列表，请参见以下注册表项：HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ KnownDLLs。
因此，我建议尝试尝试API挂钩；）确实不是太难（Windows可以满足您所有阴暗的需求）。
edit：
一些挂钩的指针
/>
您可以继续使用Windows Hooking API。
但是，直接进行以下操作很安静：
使用GetProcAddress查找地址空间中的GetDebuggerPresent（Windows不喜欢ASLR）。您可以假定它在其他进程中位于同一位置。
备份前几个字节（ReadProcessMemory），插入任何钩子（WriteProcessMemory），然后编码（VirtualProtectEx）。
侧节点：您可能需要首先提升进程的权限（OpenProcessToken，...）。
编辑2：
我发现了一些旧代码。你可以在这里找到它。请注意，此代码是为研究项目编写的，目的是避免检测沙箱，并且我当时是学生（即，该代码可能不是很高的水平）。
#2 楼
如上所述，对于某些Windows DLL，仅将DLL放在同一目录中是不够的，因为Windows会搜索有关Dynamic-Link库搜索顺序的文档中的特定路径中的路径。已知的Dlls列表有一些潜在的技巧，您可以对其进行操作以成功完成DLL替换尝试：
您可以从列表中删除特定的DLL，从而使您自己（和其他人）可以暴露计算机可能会带来一些潜在的风险），以便从应用程序的位置加载该DLL。
您可以替换存储为同一注册表路径中键值的DLL名称。代替DLL名称，只需放置一个完整路径，然后DLL将从所有进程的指定位置加载。
尽管不建议这样做，因为存在恶意实体利用这些更改的风险劫持计算机上的DLL，这绝对是一种无需编写任何API挂钩代码即可测试您的努力的简单方法，可按要求:)
另一种方法是搜索一些预制的API挂钩实用程序（ ，很多）
评论
是的，但是（1）和（2）是丑陋的骇客，它们牵涉到整个系统，例如探访某人的房屋并更换地毯。更改应仅限于当前过程。
–彼得·弗里
17年2月10日在20:03
是。我在原始答案中提到了这一点。这些方法满足了OP的原始要求：这是一种不需要钩子的简单方法，我认为在VM中完成或作为一次限时测试的一部分时，这是完全可以的（这由OP POC注释暗示）。
– NirIzr
17年2月10日在20:10
评论
很公平。您是否有机会向我介绍一个不错的教程？当我说我不懂C ++时，请理解，在少数情况下，我用C ++编写过任何东西，我都必须对它们进行反汇编以了解他们在做什么，以及他们是否会按照我的意愿去做。高级语言对我从来没有真正意义。
–BjørnUlfson
17年2月7日在17:31
见我的第二次编辑;）其干净的C代码。
–诺德瓦尔德
17年2月8日在7:33