Цель.
Есть программа, с защитой в статически прилинкованной длл
(защита срабатывает до точки входа запуска основного ехе).
Для обхода защиты написана своя длл с хуками (со своим статик импортом).

Для инжекта используется лоадер типа:
1. создание процесса нужного ехе с флагом CREATE_SUSPENDED.
2. создание удаленного потока на LoadLibrary с именем нашей длл.
3. ResumeThread основного потока программы.

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

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

| Сообщение посчитали полезным:

Tolkin
Есть способ. В ехе обнуляем ссылку на таблицу импорта, потом грузим свою библиотеку, а потом она (библиотека) сама проходится по таблице импорта и вручную (через LoadLibrary и GetProcAddress) заполняет её.

Под ссылкой на таблицу импорта здесь понимается значение Import directory. Причём патчить не обязательно на диске, а то проверку контрольной суммы может не пройти. Поэтому модифицировать это значение надо в памяти.

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

Tolkin
Есть способ. Не грузить длл через CreateRemoteThread, а написать небольшой шел который вызовет LoadLibrary

| Сообщение посчитали полезным:

Есть еще важный момент. При загрузке процесса с CREATE_SUSPENDED в памяти есть только ntdll. И, если не хочешь, чтобы подгрузились остальные либы, а в них может быть код запрета сторонних длл, грузить надо именно через ntdll.
Кстати ситуация что ты описываешь используется в протекторе Frost.

| Сообщение посчитали полезным:

спасибо всем за ответ, проверить варианты пока времени небыло.

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

По поводу загрузки длл не через создание потока, тут я не совсем понял.
Если поток проги в состоянии CREATE_SUSPENDED, если выделим место и загрузим туда шеллкод, как его запустить на выполнение, все равно же придется запустить поток?

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

| Сообщение посчитали полезным:

Tolkin пишет:
Если поток проги в состоянии CREATE_SUSPENDED, если выделим место и загрузим туда шеллкод, как его запустить на выполнение, все равно же придется запустить поток?
GetThreadContext/SetThreadContext
Метод рабочий, заюзал его в проекте лет 5 назад.
И, кстати, kernel32.dll вроде бы в тот момент уже доступен.

| Сообщение посчитали полезным:

по сути тема как --> Link <--

-----
От многой мудрости много скорби, и умножающий знание умножает печаль

| Сообщение посчитали полезным:

И да, кстати, если шеллкод делать сложно, можно копировать в адресное пространство целевог процесса свой текущий PE и уже там перенастраивать reloc-и.

| Сообщение посчитали полезным:

Tolkin
посмотрите как Strong на EP инжектирует dll, ничего сложного там нет

| Сообщение посчитали полезным:

С написанием шеллкода никогда не сталкивался, при CREATE_SUSPENDED подгружена только ntdll.dll и работать выходит надо с ней только, + не знаю будет ли решение такое универсально для 32(64) и линейки ОС, или под каждую ось свои шеллы (на даный момент задача 64).

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

еще раз всем спасибо за помощь.

| Сообщение посчитали полезным:

Tolkin пишет:
Замечено, что порядок статики прямо зависит от того как он записан в импорте, т.е. если подкорректировать таблицу и первой указать свою длл, именно она первой и будет загружена.

Этот какой-то черезжопный способ. Если RVA таблицы импорта равно 0, то статического импорта как бы нет, и ничего вообще не грузится. Ну, только то, что грузится всегда (kernel32.dll, ntdll.dll, kernelbase.dll). И это просто чудесно, т.к. раз грузиться kernel32.dll, то рабтает способ инжекта dll с помощью удалённых потоков, и адрес загрузки этой самой kernel32.dll в пределах одного сеанса одинаковый. И это значит, что инжектируемая библиотека будет грузиться раньше остальных dll, а потом сама может загружать их в любом удобной ей порядке.

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

ARCHANGEL пишет:
Этот какой-то черезжопный способ
просто ребилд таблички. если прот не заругается на измененность - все может быть ок. а с занулением статики - kernel32 всегда нужен для win2k, про user32 не помню (пример - табличка после обсидиума). без него проги валятся при старте, где-то это (и не только) было описано еще N лет назад. не исключу подобный epic fail на типа xp64

-----
От многой мудрости много скорби, и умножающий знание умножает печаль

| Сообщение посчитали полезным:

ajax пишет:
просто ребилд таблички
Все верно, тем же CFF Explorer это можно сделать, меняя расположение полей в статике. Если прот позволяет, то все работает как надо (если моя длл выше протектной хуки отрабатывают, если наоборот - не успевают). если прот не позволяет то эту операцию думаю можно сделать на лету, при CREATE_SUSPENDED, пока проверить не успел, но думаю все будет работать.

| Сообщение посчитали полезным: