каталог статей |
РџРѕРёСЃРє:
пример: сотовые телефоны расширенный поиск
Категории
АвтоМото
Бизнес и Финансы
Дом и семья
Знакомства, пикап
Интернет
Компьютеры
Культура и искусство
Медицина и здоровье
Наука и образование
Продукты питания
Производство
Развлечения и отдых
РЎРїРѕСЂС‚
Строительство
Туризм и путешествия
Главное меню
Главная страница
Последние статьи
Поиск по статьям
Наука и образование » Информатика » Вызов функции в другом процессе

Вызов функции в другом процессе

Сергей Холодилов 

I just called to say I love you,

And I mean it from the bottom of my heart.

Stevie Wonder

Внедрению DLL так или иначе (обычно в связи с перехватом API) посвящено достаточно большое количество статей. Но ни в одной из тех, которые я читал, не говорится, как извне заставить эту DLL сделать что-нибудь полезное. Обычно авторы ограничиваются перехватом необходимых API-функций где-нибудь в DllMain и последующей реакцией на вызовы этих самых функций. Между тем, взаимодействие с внедрённой DLL даёт возможность корректировать и направлять её работу и, тем самым, позволяет добиваться значительно большего эффекта.

Если внедрённая DLL создаёт свой поток, задача взаимодействия легко решается, так как в этом случае можно использовать любые методы IPC: сообщения, сокеты, именованные каналы, … , при желании можно даже COM-сервер сделать :)

ПРЕДУПРЕЖДЕНИЕ

В описании DllMain сказано, что некоторые функции, в том числе CreateThread, из неё вызывать нельзя. Объяснение «почему они говорят, что нельзя» можно найти у Рихтера (в русском четвёртом издании это глава «DLL: более сложные методы программирования», раздел «Как система упорядочивает вызовы DllMain»), у него же написано, что на самом деле можно, если осторожно. :) Просто при создании потока надо не забывать, что его выполнение начнётся не раньше, чем текущий поток покинет DllMain.

Но это всё более-менее очевидные и не очень красивые (на мой взгляд) способы. Мне кажется, я нашёл более интересный и элегантный метод. Ему и посвящена эта статья.

Идея

Идея тривиальна. Алгоритм состоит всего из четырёх шагов (плюс ещё один по желанию):

Так или иначе загрузить в адресное пространство процесса-жертвы DLL, содержащую нужную функцию.

ПРИМЕЧАНИЕ

«Так или иначе» означает, что DLL может быть загружена любым способом. Например, это может быть advapi32.DLL, которую процесс-жертва грузит сам. Если вы хотите, чтобы исполнялся ваш код, скорее всего, DLL придётся внедрять. Описание внедрения DLL смотрите в дополнительных источниках в конце статьи.

Получить адрес загрузки DLL.

Получить адрес функции.

Вызвать функцию при помощи CreateRemoteThread.

(опционально) Дождаться завершения потока и получить возвращаемое значение функции вызовом GetExitCodeThread.

А зачем нам DLL?

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

код будет расположен в случайном месте адресного пространства, так как вам вряд ли удастся выделить память по тому же адресу;

DLL могут быть загружены по другим адресам,

«само собой» ничего не получится. Чтобы добиться работоспособности кода, нужно модифицировать используемые вашим кодом адреса, то есть, фактически, выполнить задачу загрузчика. А зачем выполнять её вручную, если можно положиться на загрузчик :) ?

Ограничения

Использование CreateRemoteThread связано с очевидными ограничениями:

Поддерживается только линейка Windows NT/2000/XP.

ПРИМЕЧАНИЕ

Существует платная реализация CreateRemoteThread для Windows 9x, смотрите сайт http://www.apihooks.com раздел «PrcHelp».

Прототип вызываемой функции должен соответствовать прототипу функции потока.

Кроме того, нужно иметь солидные права доступа к процессу-жертве:

PROCESS_CREATE_THREAD для запуска потока.

PROCESS_VM_READ для определения адреса.

PROCESS_VM_OPERATION + PROCESS_VM_WRITE (разрешение на выделение памяти и запись в адресное пространство процесса) может пригодиться, если вы хотите передать вызываемой функции что-нибудь посущественнее, чем четыре байта.

ПРИМЕЧАНИЕ

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

Получение адреса загрузки DLL

В общем случае, при помощи функций EnumProcessModules и GetModuleFileNameEx можно перебрать все загруженные в процесс-жертву модули, найти среди них нужный и получить адрес его загрузки.

ПРИМЕЧАНИЕ

Эти функции являются частью Process Status API (PSAPI), поэтому будут работать только в линейке Windows NT/2000/XP. Но поскольку мы уже и так используем CreateRemoteThread, терять нам нечего.

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

ПРЕДУПРЕЖДЕНИЕ

Вообще-то, как показывает практика, возвращаемое значение LoadLibrary – это не совсем адрес загрузки DLL. В некоторых случаях в младших битах находятся какие-то флаги. Например, при вызове функции LoadLibraryEx с флагом LOAD_LIBRARY_AS_DATAFILE младший бит возвращаемого значения всегда будет установлен в 1.

Выход достаточно прост: поскольку при загрузке модуля в адресном пространстве создаётся регион, а адреса начала регионов должны быть кратны 64К, для получения «настоящего» адреса загрузки нужно просто обнулить два младших байта.

Получение адреса функции

Есть два способа получить адрес функции: простой и для настоящих программистов. :)

Простой способ

Простой способ основан на том, что смещение начала функции от начала DLL – величина постоянная, от процесса не зависящая. Это значит, что если:

загрузить в свой процесс ту же DLL;

получить адрес нужной функции;

вычесть из адреса функции адрес загрузки DLL;

прибавить к получившемуся смещению адрес загрузки DLL в процессе-жертве,

то получится адрес функции в процессе-жертве.

ПРИМЕЧАНИЕ

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

Именно на этом основана технология внедрения DLL через вызов LoadLibrary в другом процессе.

Если по каким-то причинам DLL уже загружена в процесс, то, наверное, этот способ можно рекомендовать даже самым-самым настоящим программистам. А вот если DLL нужно специально грузить, то, по-моему, опять получается некрасиво. :)

Способ для настоящих программистов

Реализовать функцию GetProcAddressInOtherProcess, принимающую в первом параметре описатель процесса. Она будет разбирать таблицу экспорта указанной DLL из указанного процесса, находить там нужную функцию и возвращать её адрес.

Если добавить функции LoadLibararyInOtherProcess и FreeLibraryInOtherProcess (которые несложно написать), получится совсем красиво, так как с чужим процессом можно будет работать почти так же, как и со своим.

Именно этот способ кажется мне интересным и элегантным, и именно его реализации посвящена статья.

Поиск экспортируемой функции в PE-файле

Как вы, наверное, знаете, формат всех исполняемых файлов в Windows (включая DLL, ocx, sys, и прочие) называется PE (расшифровывается как Portable Executable, но большого смысла не несёт, просто название, ничем не хуже других) форматом, а сами файлы, соответственно, PE-файлами. Чтобы отыскать адрес нужной функции в DLL, придётся разобраться с той частью PE-формата, которая отвечает за экспорт.

ПРИМЕЧАНИЕ

PE-формат достаточно сложен, но, к счастью, полностью он нам и не нужен. Если вас интересует более подробное описание, смотрите дополнительные источники в конце статьи.

Как в PE-файле добраться до секции экспорта

Любой PE-файл начинается с заголовка DOS, формат которого отражён в структуре IMAGE_DOS_HEADER.

typedef struct _IMAGE_DOS_HEADER {В В  // DOS .EXE header

В  ...

В  LONGВ  e_lfanew;В В В В В В В В В  // File address of new exe header

В } IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

Из всех полей этой структуры для нас интерес представляет только поле e_lfanew, которое является смещением от начала файла (в терминологии PE-формата такие смещения называются RVA – Relative Virtual Address) до PE-заголовка.

Формат PE-заголовка представлен структурой IMAGE_NT_HEADERS (она определена с использованием препроцессора и, на данный момент, соответствует структуре IMAGE_NT_HEADERS32):

typedef struct _IMAGE_NT_HEADERS {

В  ...

В  IMAGE_OPTIONAL_HEADER32 OptionalHeader;

} IMAGE_NT_HEADERS32, *PIMAGE_NT_HEADERS32;

Из неё нас интересует только поле OptionalHeader, которое разворачивается в ещё одну структуру:

typedef struct _IMAGE_OPTIONAL_HEADER {

В  ...

В  IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];

} IMAGE_OPTIONAL_HEADER32, *PIMAGE_OPTIONAL_HEADER32;

И опять, нам нужно только одно поле – DataDirectory, а, точнее, только элемент DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].

Структура IMAGE_DATA_DIRECTORY описывает расположение в памяти одной из секций PE-файла. Она определёна следующим образом:

typedef struct _IMAGE_DATA_DIRECTORY {

  DWORD  VirtualAddress; // RVA (смещение от начала файла) секции

  DWORD  Size;      // Размер секции

} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;

Элемент DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT] относится к секции экспорта.

Итого:

В начале файла расположен IMAGE_DOS_HEADER.

По смещению IMAGE_DOS_HEADER::e_lfanew находится IMAGE_NT_HEADERS.

IMAGE_NT_HEADERS::OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT] описывает секцию экспорта. Он содержит RVA и размер секции.

Как в секции экспорта найти адрес функции

Секция экспорта начинается со структуры IMAGE_EXPORT_DIRECTORY.

typedef struct _IMAGE_EXPORT_DIRECTORY {

В  ...

В  DWORDВ  Base;

В  DWORDВ  NumberOfFunctions;

В  DWORDВ  NumberOfNames;

В  DWORDВ  AddressOfFunctions;В В  // RVA from base of image

В  DWORDВ  AddressOfNames;В В В В  // RVA from base of image

В  DWORDВ  AddressOfNameOrdinals; // RVA from base of image

} IMAGE_EXPORT_DIRECTORY, *PIMAGE_EXPORT_DIRECTORY;

Здесь:

AddressOfFunctions – RVA (смещение от начала файла) массива, содержащего RVA функций.

AddressOfNames – RVA массива, содержащего RVA имён функций.

AddressOfNameOrdinals – RVA массива индексов функций. Элемент n этого массива содержит индекс в массиве адресов функций, соответствующей n-ному элементу в массиве имён функций.

ПРЕДУПРЕЖДЕНИЕ

Во-первых, элементы этого массива имеют тип WORD и размер 2 байта.

Во-вторых, MSDN и статья Мэтта Питрека «Форматы PE и COFF объектных файлов» содержат одну и туже ошибку, относящуюся к интерпретации содержимого этого массива. Правильно написано в статье Максима М. Гумерова «Загрузчик PE-файлов» и здесь :)

NumberOfFunctions – количество элементов массива адресов функций.

NumberOfNames – количество элементов массива имён функций и массива индексов функций.

Base – базовое значение ординала экспортируемых функций. Для получения индекса функции, экспортируемой по ординалу, надо вычесть из её ординала значение Base.

В результате, для поиска адреса функции, экспортируемой по имени, нужно сделать примерно следующее (в псевдокоде):

// Ищем в массиве имён функций совпадающее имя

intВ  nameIndex = FindFunctionName(AddressOfNames, NumberOfNames, name);

// Получаем соответствующий имени индекс функции

WORD funcIndex = AddressOfNameOrdinals[nameIndex];

// Получаем RVA функции

DWORD funcRVA = AddressOfFunctions[funcIndex];

ПРЕДУПРЕЖДЕНИЕ

По MSDN и Питреку, последняя строчка алгоритма должна выглядеть так:

DWORD funcRVA = AddressOfFunctions[funcIndex - Base];

Где Base – базовое значение ординала. Как показывает практика, Base вычитать не надо.

РљРѕРґ

В конце концов у меня получилось три функции. Первая находит секцию экспорта:

// Определяет RVA секции экспорта

int GetExportSectionRVA(HANDLE hProcess, const void* baseAddress)

{

  // Читаем DOS-заголовок

В  IMAGE_DOS_HEADER dos_header;

В В В В В  ReadProcessMemory(

В В В В В  hProcess,

В В В В В  baseAddress,

В В В В В  &dos_header,

В В В В В  sizeof(dos_header),

В В В В В  NULL);

  // Читаем PE-заголовок

В  IMAGE_NT_HEADERS pe_header;

В  ReadProcessMemory(

В В В В В  hProcess,

В В В В В  reinterpret_cast(baseAddress) + dos_header.e_lfanew,

В В В В В  &pe_header,

В В В В В  sizeof(pe_header),

В В В В В  NULL);

  // Смещение секции экспорта

В  return pe_header.OptionalHeader.DataDirectory

В В В В В В В В В В В В  [IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress;

}

Вторая перебирает массив имён функций в поиске заданного имени:

// Ищет в массиве имён функций заданное имя, возвращает индекс или –1

int FindName(

В В В  HANDLE hProcess,

В В В  const void* baseAddress,

В В В  DWORD AddressOfNames,

В В В  DWORD count,

В В В  const char* name)

{

  // Для сравнения имени его нужно прочитать, для этого нужно знать размер

В  int size = lstrlenA(name) + 1;

В  std::auto_ptr candidate(new char[size]);

  // Перебираем имена в массиве имён функций

В  for (int index = 0; index

В  {

В В В  DWORD nameRVA;

    // Читаем адрес начала строки

В В В  ReadProcessMemory(

В В В В В В В  hProcess,

В В В В В В В  reinterpret_cast(baseAddress)

В В В В В В В В  + AddressOfNames + index * sizeof(DWORD),

В В В В В В В  &nameRVA,

В В В В В В В  sizeof(nameRVA),

В В В В В В В  NULL);

    // Читаем строку

В В В  ReadProcessMemory(

В В В В В В В  hProcess,

В В В В В В В  reinterpret_cast(baseAddress) + nameRVA,

В В В В В В В  candidate.get(),

В В В В В В В  size,

В В В В В В В  NULL);

В В В  if (strcmp(name, candidate.get()) == 0)

В В В  {

      // Она! Сваливаем :)

В В В В В  return index;

В В В  }

В  }

  // Такой функции нет

В  return -1;

}

Третья функция использует первые две и находит нужную функцию в указанной DLL в указанном процессе:

// Находит нужную функцию в указанной DLL в указанном процессе.

void* GetProcAddress(HANDLE hProcess, HMODULE hLib, const char* name)

{

  // Нам нужен именно адрес загрузки! А результат работы

  // LoadLibrary бывает иногда неожиданным..

В  char* baseAddress = reinterpret_cast

В В В  (reinterpret_cast(hLib) & 0xFFFF0000);

  // Смещение секции экспорта

В  int export_offset = GetExportSectionRVA(hProcess, baseAddress);

В  if (export_offset

В  {

    // Какие-то проблемы с экспортом

В В В  return NULL;

В  }

  // Читаем заголовок секции экспорта

В  IMAGE_EXPORT_DIRECTORY export;

В  ReadProcessMemory(

В В В В В  hProcess,

В В В В В  baseAddress + export_offset,

В В В В В  &export,

В В В В В  sizeof(export),

В В В В В  NULL);

  // Индекс в массиве функций

В  WORD funcIndex = -1;

В  if (reinterpret_cast(name) > 0x0000ffff)

В  {

    // Функция экспортируется по имени. Ищем имя

В В В  int nameIndex = FindName(

В В В В В  hProcess,

В В В В В  baseAddress,

В В В В В  export.AddressOfNames,

В В В В В  export.NumberOfNames,

В В В В В  name);

В В В  if (nameIndex

В В В  {

      // Такой функции нет

В В В В В  return NULL;

В В В  }

    // Читаем индекс (они двухбайтные!!!)

В В В  ReadProcessMemory(

В В В В В  hProcess,

В В В В В  baseAddress + export.AddressOfNameOrdinals

В В В В В В В  + nameIndex * sizeof(WORD),

В В В В В  &funcIndex,

В В В В В  sizeof(funcIndex),

В В В В В  NULL);

В  }

В  else

В  {

    // Функция экспортируется по ординалу

В В В  WORD funcOrdinal = reinterpret_cast(name);

В В В  if ((funcOrdinal

В В В В  || (funcOrdinal >= export.Base + export.NumberOfFunctions))

В В В  {

      // Такой функции нет

В В В В В  return NULL;

В В В  }

    // Индекс это ординал минус база

В В В  funcIndex = funcOrdinal - export.Base;

В  }

В  if ((funcIndex = export.NumberOfFunctions))

В  {

    // Такой функции нет

В В В  return NULL;

В  }

  // Читаем адрес

В  DWORD funcRVA;

В  ReadProcessMemory(

В В В  hProcess,

В В В  baseAddress + export.AddressOfFunctions + funcIndex * sizeof(DWORD),

В В В  &funcRVA,

В В В  sizeof(funcRVA),

В В В  NULL);

  // Результат это базовый адрес + RVA

В  return (baseAddress + funcRVA);

}

ПРИМЕЧАНИЕ

Для оптимизации можно было бы сначала скопировать в свой процесс всю секцию экспорта (размер секции хранится в IMAGE_NT_HEADERS::OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].Size), а потом уже её разбирать. Но, поскольку заметных глазу задержек не возникает, я остановился на текущей реализации.

Пример

В качестве примера я написал три приложения: aggressor.exe, victim.exe и insider.dll. Victim и insider абсолютно пассивны, все действия выполняются aggressor-ом. Aggressor:

запускает victim.exe;

загружает в него insider.dll;

получает адреса трёх экспортируемых функций;

вызывает эти функции;

выгружает insider.dll из victim.exe .

ПРИМЕЧАНИЕ

Чтобы это действительно работало, надо положить все три исполняемых модуля в один каталог.

Для реализации перечисленных действий, да и вообще на будущее, в aggressor реализованы следующие полезные функции:

namespace OtherProcess

{

В  //

  // Вызывает функцию из заданного процесса, возвращает

  // описатель потока, который эту функцию выполняет

В  HANDLE AsynchronousCall(

В В В  HANDLE hProcess,

В В В  void* address,

В В В  void* parameter,

В В В  DWORD* pid);

В  //

  // Вызывает функцию из заданного процесса, дожидается завершения её работы

В  bool SynchronousCall(

В В В  HANDLE hProcess,

В В В  void* address,

В В В  void* parameter,

В В В  DWORD* result);

В  //

  // Загружает DLL в указанный процесс

В  HMODULE LoadLibrary(HANDLE hProcess, const TCHAR* path);

В  //

  // Выгружает DLL в указанном процессе

В  void FreeLibrary(HANDLE hProcess, HMODULE hLib);

В  //

  // Находит нужную функцию в указанной DLL в указанном процессе

В  void* GetProcAddress(HANDLE hProcess, HMODULE hLib, const char* name);

};

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

Список литературы

Джеффри Рихтер, «Programming Application for Microsoft Windows», четвёртое издание.

Тихомиров В.А. «Перехват API-функций в Windows NT/2000/XP».

Мэтт Питрек «Форматы PE и COFF объектных файлов»

Максим М. Гумеров «Загрузчик PE-файлов»

Для подготовки данной работы были использованы материалы с сайта http://www.rsdn.ru/




Похожие статьи

Простая программа, использующая MDI интерфейс
В этом разделе рассматривается программа использующая MDI ( интерфейс многих документов )Мы создадим программу, в которой документом является графическое изображение - круг. В ToolBar будет создана ...

Позиционирование: всему свое место
Михаил Дубаков Позиционирование с помощью таблиц. Как вы знаете, верстка состоит из создания блоков и их позиционирования. Получается, что позиционирование является последней преградой на пути к пол...

Бизнес-планирование для Интернет-проекта
Кирилл КузнецовБизнес-планирование является одним из первых и ключевых элементов проекта. В ходе работы над бизнес-планом исследуется рынок, потребительские свойства и преимущества создаваемого биз...


Copyright В© 2006-2007 ExcelioN
Правовая информация
Все права защищены
.
Время генерации страницы: 0.033338069915771 сек.