Как поделиться процессом?

Question

Как я могу прижаться к другому процессу? Например, поделитесь именем другого процесса? Так что, если мое приложение - griddemo.exe, и я хочу подключиться, скажем, explorer.exe, возможно? Просто прочитайте что-нибудь о CreateRemoteThread() из kernel32. Это в правильном направлении? Будут ли проблемы безопасности/ОАК?

Answer 1

Если вы имеете в виду инъекционного кода в другой процесс, то длл инъекции один метод:

http://en.wikipedia.org/wiki/DLL_injection

не сделали этого в течение многих лет, так что не уверен, как счастливы современные операционные системы MS Windows (т.е. post XP) будут с этим.

Answer 2

DLL-инъекция - традиционный способ этого. Это довольно сложно, особенно потому, что антивирусные сканеры смотрят на это с сомнением. Поэтому, даже если вы его заработаете, Norton/McAfee, скорее всего, заблокирует вас - или заблокирует вас в будущем.

Одним из простых способов инъекции DLL является AppInit_DLLs registry value. Обратите внимание, что Microsoft зарезервировала право просто удалить эту функциональность (и, вероятно, сделает это в будущем).

Утвержденный Microsoft способ достижения инъекции DLL является лицензированием Microsoft Detours.

Обратите внимание, что ваша DLL должна быть построена против версии CLR версии 4.0 или выше, чтобы безопасно выполнять инъекцию DLL, потому что это первая версия, поддерживающая in-proc бок о бок.

Answer 3

Прежде всего, извините, но мой ответ будет длиннее, чем другие ответы.

Я использую DLL-инъекцию с годами в другой версии операционной системы (от Windows NT 4.0 до Windows 7), и у меня не было никаких проблем с любым антивирусным сканером (включая Norton и McAfee в разных версиях). Поэтому я не согласен с Стивеном Клири (см. Его ответ) в этом аспекте.

Использование CreateRemoteThread() действительно является одним из способов. AppInit_DLLs - это еще один способ. Оба имеют свои преимущества и недостатки. Основным преимуществом AppInit_DLL является простота для вставки DLL в любой процесс. Основные недостатки AppInit_DLLs подхода являются следующими:

1. Все GUI приложение будет загружать DLL. Если вы хотите загрузить его только в одном процессе, например explorer.exe, вы не можете этого сделать. Таким образом, рабочее пространство всех графических интерфейсов будет увеличиваться вашей DLL. Ошибка в вашей DLL (особенно внутри DllMain или в любой DLL зависимости вашей DLL) может привести к сбою многих процессов, которые вы в настоящее время не знаете.
2. Вы не можете внедрить свою DLL в отношении подхода AppInit_DLLs в консольном приложении или в любом EXE, который не имеет зависимости от User32.dll.
3. Вы должны быть очень осторожны внутри своего DllMain, так как он будет называться до User32.dll будет полностью инициализирован. Таким образом, безопасная DLL-библиотека, которую вы можете использовать внутри DllMain, есть Kernel32.dll.

В отношении CreateRemoteThread() можно начать дополнительную нить в процессе.Основная проблема CreateRemoteThread() заключается в том, что его параметр lpStartAddress должен быть адресом удаленного процесса. Поэтому нужно использовать функции OpenProcess, VirtualAllocEx и WriteProcessMemory, чтобы записать некоторую информацию в память процесса назначения. Чтобы иметь возможность открывать процесс, нужно иметь привилегию отладки. Если вы хотите сделать только 2 + 2 внутри процесса назначения, вы можете скопировать соответствующий двоичный код непосредственно в целевой процесс. Вся реальная интересная работа может быть выполнена с использованием некоторых Windows API. Таким образом, в основном один не копирует код. Вместо этого один вызов LoadLibrary("MyPath\\MyDll.dll") внутри процесса назначения. Поскольку прототип LoadLibrary совпадает с прототипом ThreadProc от CreateThread, вы можете позвонить LoadLibrary в качестве ThreadProc из CreateRemoteThread(). Этот путь имеет имя DLL Injection.

Я рекомендую использовать эту DLL-инъекцию только в том случае, если это действительно необходимо. Если у вашего целевого приложения есть другой способ, например плагины для загрузки DLL внутри процесса, вы должны использовать этот путь вместо DLL Injection.

Некоторые общие проблемы, которые вам придется решать после того, как у вас есть рабочий пример DLL Injection. Это проблемы, которые вы можете не увидеть в первый раз, но после длительного использования вашего приложения вы увидите его значение:

1. Вы должны найти тот момент, когда процесс назначения уже работает, прежде чем вы можете использовать CreateRemoteThread() ,
2. Целевое приложение должно быть уже инициализировано перед вызовом CreateRemoteThread(). Поэтому вы не должны использовать CreateRemoteThread() слишком рано. В случае explorer.exe вы можете использовать запуск вашей небольшой триггерной программы из Запустить раздел реестра. В настоящий момент explorer.exe полностью подготовлен к инъекции DLL.
3. Вы должны учитывать 64-разрядную версию Windows.
4. Не забывайте о перемещении DLL внутри процесса назначения. Будьте осторожны: DLL может быть загружена в процессе назначения на другом адресе, как в вашем процессе. В основном неплохо выбрать хороший базовый адрес (вариант компоновщика) для вашей DLL, который вы будете вводить. Kernel32.dll может быть когда-то (очень редко) загружен на другом адресе, как в исходном процессе. Вы можете создать код инъекции DLL, свободный от этой проблемы.
5. Службы терминалов изолируют каждую терминальную сессию по дизайну. Поэтому CreateRemoteThread терпит неудачу, если целевой процесс находится в другом сеансе, чем вызывающий процесс. Проблема, которую вы можете увидеть на XP (которая не подключена к домену) или особенно на Vista или Windows 7, если вы попытаетесь сделать инъекцию DLL из службы Windows. Чтобы устранить проблему, вы должны сделать DLL Injection либо из процесса, выполняющегося на том же сеансе терминала, что и процесс назначения, либо вам нужно переключить текущий сеанс перед использованием CreateRemoteThread. В вашем процессе должно быть включено SE_TCB_NAME и использовать SetTokenInformation с параметром TokenSessionId. Чтобы получить идентификатор сеанса процесса назначения, вы можете использовать разные методы. Функции с префиксом WTS (например, WTSGetActiveConsoleSessionId) могут быть очень полезными.

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

Answer 4

Я не пробовал этого в последнее время, но другой способ сделать это было бы создать Hook DLL:

1. Создание библиотеки DLL, которая содержит подключаемую процедуру, как MessageProc.

2. Установите эту DLL в Windows \ System32.

3. Используйте FindWindows (Ex), чтобы найти окно вашего жертвы.

4. Используйте GetWindowThreadProcessId(), чтобы найти правку этого окна. Это необходимо, чтобы избежать инъекции вашей DLL в каждый процесс в системе.

5. Используйте SetWindowsHookEx, чтобы зацепить эту резьбу.

6. PostMessage сообщение WM_USER в окно - активация вашей Hook DLL, если она еще не активна.

Это, вероятно, вызвать новый Windows Vista/7 UIPI/UAC, если вы не достаточно привилегированным пользователем, но это зависит от многих факторов - ваш пробег может варьироваться.