-
Суть:
1. Работает кернел-драйвер, использующий PsSetCreateProcessNotifyRoutine для извещения приложения о старте процессов
2. При получении извещения о старте интересующего процесса приложение пытается с использованием CreateRemoteThread как можно раньше инжектировать в его АП dll-модуль, на что получает вполне объяснимый отлуп в виде ERROR_NOT_ENOUGH_MEMORY.
Вопрос:
А как грамотно подождать пока произвольный процесс-жертва будет готова к инъекции, но не опоздать при этом ?
Кривоватое решение у меня есть, но на то оно и кривоватое что я в нем не уверен ..
-
И тишина)... будто никто и никогда не заморачивался такой задачей.. Привожу свое кривое решение:
function WaitForJnjectable(ProcessID: Cardinal; WaitTimeout: Cardinal): Boolean;
var
hProcess: THandle;
BytesNeeded: DWORD;
begin
Result := False;
hProcess := OpenProcess(PROCESS_QUERY_INFORMATION or PROCESS_VM_READ, False, ProcessID);
if hProcess = 0 then Exit;
while True do begin
if EnumProcessModules(hProcess, nil, 0, BytesNeeded) then
if BytesNeeded >= (SizeOf(THandle)*3) then begin Result := True;
Break;
end;
if WaitTimeout < INFINITE then begin
Dec(WaitTimeout);
if WaitTimeout = 0 then begin
CloseHandle(hProcess);
SetLastError(ERROR_TIMEOUT);
Exit;
end;
end;
Sleep(1);
end;
CloseHandle(hProcess);
end;
Оно действительно кривое ?
-
PsSetLoadImageNotifyRoutine и ждать ntdll32, kenel32 and user32 must be loaded at least
-
> Slym © (27.10.10 13:36) [2]
предположим, переделка KMD для задействования в нем PsSetLoadImageNotifyRoutine исключена
меня интересует прикладное кольцо ..
-
Чем AppInit_Dlls не устраивает ?
-
> Чем AppInit_Dlls не устраивает ?
Игорь, мы эту тему уже обсасывали) Не всякую дельфийскую либу можно приспособить под использование этой фичи.
-
> Slym © (27.10.10 13:36) [2]
Да и не факт что инжект обязан пройти успешно при факте успешной загрузки и инициализации эти 3-х либ .. Это я лишь сделал предположение что этого будет достаточно .. Но насколько оно оправдано ?
-
А если притвориться отладчиком? OpenProcess + DebugActiveProcess и вперед, тут тебе и подгрузка библиотек и все что угодно...
-
> Rouse_
Можно, конечно, и притвориться, но это, полагаю, ощутимо усложнит задачу ..
-
Ну кода пописать конечно придется, зато будет полный контроль над процессом и изначальная задача решается...
-
Собственно даже кода много не потребуется - всего лишь дождаться выхода на OEP (пара десятков циклов) ну или на крайний случай LOAD_DLL_DEBUG_EVENT с отлавливанием подгрузки требуемых библиотек, все остальное пропускать по ContinueDebugEvent
-
Факт выхода на OEP - это, конечно, идеальный вариант, в этом случае, я полагаю, даже нет повода заморачиваться состоянием загруженности ключевых сист.модулей.. ежу понятно что на этот момент они уже загружены...
Просто я подумал что, возможно, существуют и иные потайные ходы (нежели дабаг-контроль процесса), позволяющие оперативно отследить момент прохождения OEP.
Тут еще возникает такой попутный вопрос: отсутствие (или неполная инициализация) какой конкретно либы в АП жертвы приводит к отказу вызова CreateRemoteThread() с кодом, говорящим якобы NOT ENOUGH MEMORY..
-
-
Ибо если смотреть исходники CreateRemoteThread, то там наблюдается следующий код:
Status = BaseCreateStack(
hProcess,
dwStackSize,
0L,
&InitialTeb
);
if ( !NT_SUCCESS(Status) ) Здается мне что именно это и приводит к ошибке NOT ENOUGH MEMORY...
-
-
Удалено модератором
-
Кстати, а если отлавливаемый процесс всегда известен, то мошт ну его эту драйверную прослойку и инжект с третьего кольца? Не проще ли в секцию импорта добавить свою библиотеку?
-
> Leonid Troyanovsky © (27.10.10 18:31) [14]
Спасибо !
Все бы ничего, но успею ли я гарантированно "затормозить" жертву ДО того как она пройдет OEP ? Не я же стартую жертву ..
> Rouse_ © (27.10.10 20:05) [16]
Нет, жертва может быть произвольной и заренее неизвестна.
-
> Сергей М. © (27.10.10 10:16) [1]
Отличное вполне решение, я так издевался над Касперским, сможет он при запуске сервиса или gui что либо сделать, нет не смог, вредосная dll успешна внедрена, только потом плакать начинает когда уже поздно брыкатся
-
Делал кстати в User Mode по таймеру 1ms и ни один процес не устоял, кого бы не мучил
-
-
> Leonid Troyanovsky © (27.10.10 18:31) [14]
косяк исправлен, спасибо за подсказку
-
> xayam © (04.05.11 17:19) [21]
> косяк исправлен, спасибо за подсказку
Воспринял.
Пожалуйста, всегда готов.
-- Regards, LVT.
-
> xayam © (04.05.11 17:19) [21]
> косяк исправлен, спасибо за подсказку
Воспринял.
Пожалуйста, всегда готов.
-- Regards, LVT.
-
Здравствуйте
В продолжении темы
Написал драйвер, ставлю callback на PsSetLoadImageNotifyRoutine для отслеживания загрузки kernel32.dll, в 32 битных ОС все работает отлично, но в x64 начиная с Vista для драйверов без цифровой подписи сделали облом, в тоже время начиная с Vista появилась LdrRegisterDllNotification которая вроде позволяет обойтись без PsSetLoadImageNotifyRoutine, собственно вопрос следующий, будет ли работать неподписанный драйвер в XP 64 бит?
-
Если будет то в Windows 2000...XP x32/x64 можно использовать неподписанный драйвер, а в Vista...7 LdrRegisterDllNotification
-
> будет ли работать неподписанный драйвер в XP 64 бит?
нет
-
Попробовал запустить в XP 64 SP2, работает, правда странности какие то наблюдаются, если .sys на рабочем столе сервис стартует, если в папке system32/drivers запускаться не хочет
-
> если .sys на рабочем столе
имхо, туда доступ пользователю полный
> если в папке system32/drivers запускаться не хочет
имхо, нет соотв. прав пользователя...
-
> p © (09.04.12 20:39) [25]
LdrRegisterDllNotification фигня - только для своего процесса Полюбому делать цифровую подпись для какого то конечного продукта, а тестировать драйвера bcdedit.exe -set TESTSIGNING ON + самопальный сертификат
|