CreateRemoteThread 32-> 64 и / или 64-> 32

Question

Мне нужен способ CreateRemoteThread в 64-разрядных окнах в 64-разрядных и 32-разрядных процессах. Я разобрался, как найти набор команд целевого процесса, как выделить память в целевом процессе для салазок сборки, и я почти разобрался, что делать с рандомизацией адресного пространства.

Я не знаю, как на самом деле запустить поток в удаленном процессе, если он имеет неправильный набор команд.

Обратите внимание: мне все равно, какую из двух проблем вы решите. Мой собственный exe-файл может быть 32- или 64-битным (но мне действительно нужно выбрать, прежде чем я узнаю количество битов целевого процесса).

Прежде чем кто-то пожалуется, что мне действительно не нужно этого делать, спросите Microsoft, почему я должен установить FILE_SHARE_DELETE на всех открытых дескрипторах, прежде чем я смогу удалить файл, который используется. Нет, нет необходимости удалять файлы, открытые другим процессом.

Answer 1

Следующий исходный код, который выполняет обычную, а также инъекцию 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

Короткий рассказ состоит в том, что он включает в себя множество специфических для архитектуры «недокументированных» функций, поскольку для выполнения X86-X64 необходимо выполнить 64-разрядный код в 32-разрядном процессе WoW.

Но этот код хорошо работал для многих версий Windows.

Answer 2

CreateRemoteThread 32-> 64 не работает.

CreateRemoteThread 64-> 32 работает.

Answer 3

В качестве обходного пути для вашей заявленной проблемы вы можете и, вероятно, должны использовать функцию отложенного удаления при перезагрузке, предоставляемую операционной системой, если вам нужно удалить файлы, используемые другими процессами, а другие процессы не открыли их для FILE_SHARE_DELETE. Вероятно, это гораздо менее потенциально опасно, чем изменение существующих дескрипторов файлов во внешних процессах с помощью внедрения потоков, не говоря уже о том, что они требуют меньших привилегий. Просто мысль.

Если вы настроили удаленное внедрение потока, см. Обходные пути на странице MSDN ; может быть, там есть какое-то вдохновение. Вы также можете подумать о том, чтобы просто убить другими процессами грубой силой (во-первых, хорошо, по необходимости, принудительно), так как вы в любом случае нуждаетесь в административном доступе, а перебор с их внутренними дескрипторами может не оставить их в хорошем состоянии. Это то, что делают установщики (или просят пользователя), когда им нужно заменить открытые файлы без перезагрузки.