Как перенаправить вызовы ole32.dll в мою собственную DLL прокси? - PullRequest
Новая
       37

Как перенаправить вызовы ole32.dll в мою собственную DLL прокси?

10 голосов
/ 03 мая 2011

Я пытаюсь обнаружить все вызовы CoCreateInstance в каком-то процессе, который я запускаю (в идеале, я могу также обнаружить вызовы в дочерних процессах).

Чтобы добиться этого, используя Microsoft Visual Studio 2008 в Windows 7, я создаю прокси-библиотеку DLL, которая перенаправляет все вызовы, кроме одного, в стандартную библиотеку ole32.dll, как описано в различных статьях, например, Перехват: взлом Windows через перенаправление DLL . Получающаяся DLL выглядит нормально, но я просто не могу заставить существующие программы (я использую стандартный Контроллер управления ActiveX (tstcon32.exe) в качестве тестового приложения) забрать мою прокси DLL. Независимо от того, что я делаю, программы всегда, кажется, получают C:\Windows\SysWow64\ole32.dll в соответствии с Process Explorer . Я попробовал несколько вещей:

  1. Добавить каталог, содержащий мою прокси-библиотеку DLL, к PATH, а затем вызвать программу; похоже, не имеет никакого эффекта.
  2. Скопируйте мою прокси DLL в тот же каталог, что и вызываемая программа; не повезло.
  3. Создайте файл .local в том же каталоге, что и вызываемая программа, как описано в статье Redire-Link Redirection , и поместите мою прокси-библиотеку DLL в тот же каталог - тоже не сработало. Но потом я прочитал, что это перестало работать на более поздних версиях Windows. Кроме того, ole32.dll является «известной DLL» в соответствии с параметром реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs, поэтому перенаправление на основе .local, вероятно, не будет работать в любом случае.
  4. Используйте перенаправление на основе манифеста, как описано, например, в перенаправлении DLL с использованием манифеста вопрос, но это, похоже, тоже не дало результата. Однако такой подход кажется нетривиальным, поэтому, скорее всего, я сделал что-то не так.

Есть ли у кого-нибудь опыт перенаправления вызовов на стандартные библиотеки DLL, такие как ole32.dll, с использованием заглушки DLL? Как вы заставили приложения забрать заглушку DLL?

Ответы [ 2 ]

5 голосов
/ 22 октября 2012

Я понимаю, что это немного поздно примерно на 6 месяцев, но я пытался сделать то же самое, и у меня есть некоторые дополнительные примечания:

  1. Вы можете вступить во владение и удалить ole32.dll из HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs. Это позволяет обойти тот факт, что Windows заблокировала эти ключи.
  2. Создание ключа SafeDllSearch со значением 0 в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager равно , которое должно изменить путь поиска .

Применив оба эти метода и перезагрузившись, перехват по-прежнему не работал. Я пошел еще дальше, загрузил виртуальную машину с одним из наших аварийных компакт-дисков (среда на основе Windows PE) и переписал один в system32. Windows не загружается в результате - никаких ошибок символов, но я никогда не получаю до LogonUI.exe. Возможно, мои подключенные функции нарушены, поэтому это может быть причиной.

В любом случае, это произвело реальный, ощутимый эффект крючка - хотя тот, который кричит «сломан» !. К сожалению, его очень сложно отладить, и я могу прибегнуть к другому методу перехвата, а именно: IAT patching .

Редактировать Другой эксперимент, который я провел, состоял в том, чтобы явно загрузить саму Dll в адресное пространство целевого процесса. Фрагмент кода, который делает это, выглядит следующим образом: 

wchar_t* TargetPath = argv[1];
wchar_t DllPath[] = L"N:\\experiments\\ole32.dll";
STARTUPINFOW si;
PROCESS_INFORMATION pi;
memset(&si, 0, sizeof(STARTUPINFOW));
memset(&pi, 0, sizeof(PROCESS_INFORMATION));

// create process suspended
BOOL bResult = CreateProcess(NULL, TargetPath, NULL, NULL, FALSE, 
    CREATE_SUSPENDED, NULL, NULL, &si, &pi);

// write DLL name to remote process
void* RemoteAddr = VirtualAllocEx(pi.hProcess, NULL, sizeof(DllPath)+1, 
    MEM_RESERVE | MEM_COMMIT, PAGE_READONLY);
WriteProcessMemory(pi.hProcess, RemoteAddr, DllPath, sizeof(DllPath), &BytesWritten);

// get handle to LoadLibraryW
PTHREAD_START_ROUTINE pfLoadLibrary = (PTHREAD_START_ROUTINE) 
    GetProcAddress(GetModuleHandle(L"kernel32.dll"), "LoadLibraryW");

// create remote thread calling LoadLibraryW
HANDLE hThread = CreateRemoteThread(pi.hProcess, NULL, 
    0, pfLoadLibrary, RemoteAddr, 0, NULL);

// start remote process
ResumeThread(pi.hThread);

Для краткости устранена обработка ошибок.

По сути, цель состояла в том, чтобы принудительно загрузить мой ole32.dll в адресное пространство цели, прежде чем он успел загрузить ole32.dll из system32. В моем случае ole32.dll загружался позже в подпрограмме загрузки приложения, так что теоретически это должно было сработать. На практике это не так. Я не уверен почему.

Обновление Мой исходный код не удался, потому что DLL имела неразрешенные предупреждения о символах во время выполнения. Этот метод работает Так что, очевидно, он загружает и мой ole32.dll, и тот, что из system32. Чтобы библиотека загружалась успешно, я добавил вызов LoadLibrary(DllPath) к приведенному выше коду.

2 голосов
/ 04 мая 2011

Возможно winapioverride может помочь вам. Он может записывать все вызовы Win API, не программируя ничего. Поэтому он внедряет dll-процессы в процесс ведения журнала. Если я правильно его запомнил, можно также ввести собственные пользовательские библиотеки - даже до того, как процесс фактически выполнит какой-либо код. В документации есть некоторая информация о шпионских ком объектах.

...