CreateRemoteThread 32-> 64和/或64-> 32

时间:2009-01-30 02:22:05

标签: multithreading winapi

我需要一种方法将x64窗口中的CreateRemoteThread同时转换为64位和32位进程。我已经找到了如何找到目标进程的指令集,如何在程序集sled的目标进程中分配内存,我几乎已经找到了解决地址空间随机化的方法。

我不知道当它是错误的指令集时,如何在远程进程上实际启动线程。

注意:我不关心你解决的两个问题中的哪一个。我自己的exe可以是32位或64位(但我真的必须在知道目标进程的位数之前选择)。

在有人抱怨我真的不应该这样做之前,请问Microsoft为什么我必须在所有打开的句柄上设置FILE_SHARE_DELETE才能删除正在使用的文件。不,没有必要删除其他进程已打开的文件。

3 个答案:

答案 0 :(得分:6)

以下源代码执行正常以及X86-> X64和X64-> X86注入,具有您需要的所有详细信息:https://dev.metasploit.com/redmine/projects/framework/repository/revisions/master/entry/external/source/meterpreter/source/common/arch/win/i386/base_inject.c

简短的故事是它涉及许多特定于体系结构的“未记录”功能,因为您必须在32位WoW进程中执行64位代码才能执行X86-X64。

但该代码在许多Windows版本中都运行良好。

答案 1 :(得分:4)

CreateRemoteThread 32-> 64不起作用。

CreateRemoteThread 64-> 32可以使用。

答案 2 :(得分:2)

如果您需要删除其他进程正在使用的文件,并且其他进程尚未打开它们,那么您可以并且可能应该使用操作系统提供的重新启动功能延迟删除对于FILE_SHARE_DELETE。它可能比使用线程注入修改外部进程中的现有文件句柄更具潜在危险,更不用说可能需要较少的权限。只是一个想法。

如果您设置远程线程注入,请参阅MSDN page上的变通办法;也许那里有一些灵感。您还可以考虑使用暴力破坏其他进程(首先,必要时强制执行),因为您无论如何都需要管理员访问权限,并且使用其内部句柄进行混乱可能不会使其处于良好状态。这就是安装程序在需要更换打开文件而不重新启动时所做的事情(或要求用户做)。