Перехват API у создаваемого процесса и его статические dll

Тема в разделе "WASM.BEGINNERS", создана пользователем masharabinovich, 12 ноя 2007.

  1. masharabinovich

    masharabinovich New Member

    Публикаций:
    0
    Регистрация:
    12 ноя 2007
    Сообщения:
    3
    Делаем всё, как доктор в умных статьях прописал:

    Cоздаём процесс: CreateProcess(...., CREATE_SUSPENDED, ..)
    выделяем там память: VirtualAllocEx(...)
    Инжектим туда наш код: WriteProcessMemory(...)
    Меняем context.Eip на его адрес: GetThreadContext(...)/SetThreadContext(...)
    Запускаем процесс работать дальше: ResumeThread(...)

    Всё вроде хорошо.

    Кроме одного: у процесса есть DLL, которые грузятся вместе с ним.
    Не системные DLL, вроде kernel32.dll и user32.dll, а его DLL, но они такие же статические, их имена есть в exe-файле.
    И получается так, что их DllMain()'ы выполняются хоть и после нашего ResumeThread(...), но до того, как начнёт работать заинжекченый код.
    Всё, что делается в этих DllMain()'ах получается непохуканным нашим кодом.
    А это плохо, т.к. там много чего делается такого, что надо перехватить :dntknw:

    Что тут можно сделать?
     
  2. Aspire

    Aspire New Member

    Публикаций:
    0
    Регистрация:
    19 май 2007
    Сообщения:
    1.028
    А креаттред ты перехватываешь? Проверяешь треды на перехват?
     
  3. Asterix

    Asterix New Member

    Публикаций:
    0
    Регистрация:
    25 фев 2003
    Сообщения:
    3.576
    дебаг лоадер перехватит все что угодно, ибо загрузка длл это тоже отладочное событие

    правда фраза
    несколько смутила,
    это какие такие?
     
  4. MagnumGT

    MagnumGT New Member

    Публикаций:
    0
    Регистрация:
    9 ноя 2007
    Сообщения:
    122
    Asterix
    Человек имел ввиду, что либы прописаны в импорт, а не загружаются через LoadLibrayA


    masharabinovich
    На будущее - статические, это либы статической линковки .lib
     
  5. z0mailbox

    z0mailbox z0

    Публикаций:
    0
    Регистрация:
    3 фев 2005
    Сообщения:
    635
    Адрес:
    Russia СПБ
    masharabinovich
    не "получается так" а "как и должно быть"
    Сначала выполняются дллмайны для всех импортных и депенденсных дллек
    И только потом - ентри пойнт
    Это надо понимать. Хочешь по-другому? пиши свою винду :)
    варианты: патчи через вритепроцессмемори тут же где инжект делаешь
    или воткни свой код где-нить на выходе из дллмайна кернел32
    везде будут грабли на обращениях к еще не инициализированным/не загруженным дллкам
     
  6. masharabinovich

    masharabinovich New Member

    Публикаций:
    0
    Регистрация:
    12 ноя 2007
    Сообщения:
    3
    Не возражаю :)
    Прикол в том, что они выполняются еще раньше - до context.Eip (а это адрес в kernel32.dll).
    Ентри поинт самого exe будет уже потом, это всё происходит до попадания на entry point.
    вот это не понятно, "тут же" - это где ?
    Для меня было "тут же" - это по адресу context.Eip полученному в GetThreadContext(), но оказалось что это неправильно.
    Как-то можно получить EIP с которого реально старнует тред ? То есть до DllMain'ов.
    Вот это интереснее, попробую.

    Еще один вариант нашёлся в Detours - там патчицца в памяти таблица импорта запускаемого exe, и первой в список ставится detours.dll, но он предполагает наличие своей dll.
     
  7. z0mailbox

    z0mailbox z0

    Публикаций:
    0
    Регистрация:
    3 фев 2005
    Сообщения:
    635
    Адрес:
    Russia СПБ
    masharabinovich
     
  8. z0mailbox

    z0mailbox z0

    Публикаций:
    0
    Регистрация:
    3 фев 2005
    Сообщения:
    635
    Адрес:
    Russia СПБ
    masharabinovich
    там один call до ентри пойнта :)
    context.Eip - это BaseProcessStartThunk
    все импортные DllEntry отрабатывают DLL_PROCESS_ATTACH раньше