如何解决如果注入器被特定应用程序启动，PE 注入会失败？
简短免责声明：由于此问题包含有关黑客/渗透测试的主题，因此我想说明此问题仅作为学校项目的一部分用于教育目的。为了防止可能的滥用，我只会发布理解问题所必需的代码。
为了演示 Windows 10 的危险和漏洞，我目前正在编写一个使用两种常用技术的小型 C++/WinAPI 应用程序：
- 使用“fodhelper technique”绕过 UAC（只需将特定的注册表值设置为应该提升的可执行文件的路径，然后启动一个名为“{{1”的自动提升的 Windows 可执行文件}}"，然后它将读取注册表值并将其作为命令执行/启动指定的应用程序）。
- 执行PE注入，即从当前进程的地址空间运行一个PE文件（基于this example from github）。在我的程序中注入的 PE 是一个简单的 C++ 控制台应用程序 (x86)，它打印一个消息框。 shellcode 硬编码在注入器二进制文件 (x86) 中。
我设法在独立文件中成功地执行了这两种技术。但是，一旦我将这两种方法结合起来（即先提升，然后注入），就会出现一个奇怪的错误。
问题描述
当注入器手动启动（通过双击）时，一切正常，但是当注入器由于 UAC 绕过而由 fodhelper.exe (x64) 启动时，会发生以下情况：注入完成后完成后，注入的应用程序的控制台窗口出现，但我没有继续执行，而是收到一堆错误消息，指出“System32\fodhelper.exe”。这表明偏移量出了问题，Windows 加载程序正试图在错误的位置读取导入。
总结：代码注入工作正常，除非注入器是由 The code execution cannot proceed because [garbage characters].dll was not found 启动的。在这种情况下，注入的PE文件无法运行。
到目前为止我已经尝试过的事情来找到问题的根源
- 使用
fodhelper.exe调试注入并打印注入期间使用的各种内存地址。如果文件是手动启动的（并且注入成功），或者它是由GetLastError启动的（并且注入失败），则没有区别。 - 将
fodhelper.exe调用替换为WriteProcessMemory，以在注入器手动启动或通过WriteFile启动时比较输出文件。两个输出文件完全相同且可运行。这表明注入本身不是问题，但 Windows 加载程序的行为似乎有所不同。 - 使用 UAC 或使用提升的命令提示符手动提升注入器。在这两种情况下，注入都是成功的。
- 将
fodhelper.exe复制到另一个位置（例如桌面）并启动此副本。在这种情况下，注入成功。仅当注入器由fodhelper.exe文件夹中的原始fodhelper.exe启动时，注入才会失败。
似乎注入的行为完全相同，但指标显示，由于传递给注入器的 fodhelper.exe 的某些未知影响，Windows 加载程序的行为似乎有所不同。
我感谢任何解释或假设！如果您需要更多信息，请随时询问。
最小可重现示例
（带有有限的调试信息和评论）： https://0bin.net/paste/UPRIg12n#6nJvBok72UcDvIa56c-XEss7AibIh1Zrs+c3sUzvQMj
注意：如果排除 System32 函数或使用 UAC 手动提升 exe，请查看注入如何工作，以及在包含所述函数时如何失败。
编辑
根据用户 RbMm 的回答，此错误是特定漏洞利用保护属性（elevateProcess 具有 PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY 值）的结果，该属性自动应用于 EnableModuleTamperingProtection 并看似获得由所有子进程继承。据此，在启动目标进程时删除/重置此属性应该可以修复错误。到目前为止，我已经尝试了以下方法，但结果没有任何改变：
fodhelper.exe解决方法
当通过 RunAs 创建进程并提升时 - appinfo.dll 调用 RAiLaunchAdminProcess 函数（这是在某些 svchost.exe ) 和这个函数，将 STARTUPINFOEX（和 EXTENDED_STARTUPINFO_PRESENT 标志）传递给 CreateProcessAsUser。在这里 - lpAttributeList，特别是 PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY 属性键用于为子进程设置多个漏洞利用缓解策略（在您的情况下为 fodhelper.exe）。此处 EnableModuleTamperingProtection 设置为子进程树。效果 - 当系统解析导入描述符时，它会检查（在 LdrpGetImportDescriptorForSnap 内部）这个缓解标志，如果启用 - 调用 LdrpCheckPagesForTampering api，它返回true，如果 SharedOriginal 为 0，这意味着这是 EXE/IAT 的写时复制私有副本——因此被“篡改”。
在这个 LdrpMapCleanModuleView 被调用之后。此时你的尝试开始失败
可能的第一个公开信息，来自 Alex Ionescu -
LdrpCheckPagesForTampering/LdrpMapCleanModuleView (RS3) 很漂亮 很酷的防空洞缓解措施 (EPROCESS.EnableModuleTamperingProtection)
如果您自行启动新进程，您当然不会为集合 UpdateProcThreadAttribute 调用 PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY，在这种情况下，您的代码有时可以工作。真的只是随机的，有时 - 这里存在许多其他错误和糟糕的编码
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。