Я вижу три возможных решения этого. Насколько мне известно, не существует Windows API, позволяющего получить адрес функции для модуля в другом процессе.
Решение 1.
Самое простое решение, IMO, - это внедрить DLL в целевой процесс и получить всю необходимую информацию из самого целевого процесса. Есть много разных способов включить вашу DLL в целевой процесс, мой любимый - Reflective DLL Injection.
Решение 2:
Решение 2 использует EnumProcessModules (Использование ), чтобы получить HMODULE
ссылку из другого процесса. Вы не можете использовать их при обращении к GetProcAddress
напрямую. Чтобы решить эту проблему, загрузите DLL в свой процесс с помощью LoadLibraryEx ( "MODULE_NAME", NULL, DONT_RESOLVE_DLL_REFERENCES )
. Это при успешной загрузке модуля предоставит вам экземпляр HMODULE
, который вы можете передать GetProcAddress
.
Адрес, возвращаемый из GetProcAddress
, действителен только для вашего адресного пространства, но, к счастью, он также относится к базе модуля. Вычтя вашу HMODULE
ссылку из адреса и затем добавив ее к HMODULE
ссылке в целевом процессе, вы получите адрес функции в целевом процессе.
Пример: targetProc = myProc - myModule + targetModule;
, где myProc - это char *
, а myModule и targetModule - это HMODULE
.
Решение 3:
Решение 3 является самым сложным для реализации ИМО. Это решение требует, чтобы вы прочитали память целевого процесса, чтобы найти необходимые модули, а затем проанализировать модули, чтобы найти адреса функций.
Ресурсы для этого решения можно найти здесь и здесь.
Я лично не тестировал ни решение 2, ни решение 3, но теоретически они должны работать. Я лично использовал решение 1 и рекомендую его как способ достижения этой цели. Два других решения требуют большого количества шаблонного кода для имитации существующих методов Windows API.
person
Smith_61
schedule
16.10.2014
GetModuleHandle
. В любом случае возвращаемый вами дескриптор имеет смысл только в контексте этого процесса. - person Jonathan Potter   schedule 16.10.2014