Проблемы с хукингом LdrInitializeThunk в NtResumeThread

P.S.:
XLdrLoadDll - основана на моей функции GetProcedureAddressEx. Там по хэшам вычисляется адрес функции, которую нужно получить. 100% всё работает. При этом вызываются функции только из ntdll.dll

 

Это уже переходит всяческие границы.
Ставлю INT 3 перед XLdrLoadDll, чтобы посмотреть в чём дело - и отладчик не вызывается (Olly). Просто приложение висит и всё. Снимаю коммент с XLdrLoadDll - всё работает.
Я в шоке. Как это можно отладить? =)

P.S.: Люди, неужели никто подобные usermode'ные руткиты не писал? Или у вас таких подобных проблем не возникало?

 

Тэкс... Сейчас посмотрел в ProcessExplorer'е - когда выполняется INT 3 и пытается запуститься Olly, то его родитель - это приложение, которое и выполнило INT 3.
Так NtResumeThread-же, коряво работает у приложения, которое мне нужно отладить. o0 Вот,походу Olly и стартовать из-за этого не может.
Значит, нужно сделать что? Изначально запустить Olly, приаттачиться к процессу,который мне нужно отладить ... вручную найти место вызова LdrLoadDll и поставить breakpoint?

Я ещё нашел некторую инфу тут: http://forum.sources.ru/index.php?showtopic=177691&view=showall&hl=

Код (Text):

1. Когда процесс создается с CREATE_SUSPENDED, то он останавливается до того как начнет грузить необходимые ему для работы (записанные в секции импорта) длл.[b] Если же в этот момент попробовать создать поток, который грузит какие-либо ДЛЛ, то список загрузки ДЛЛ в приложении портится[/b] (подробнее можно об этом прочитать в МСДН на DllMain), и некоторые ДЛЛ начинают работать до того как они инициализированы. Что из этого получается - можно представить... Приложения либо падают, либо делают что попало.

И вот сейчас я думаю - не мой ли это случай?
Т.е., в итоге, что нужно делать? Не использовать LoadLibrary (LdrLoadDll) для получения хэндла dll-ки и вручную искать эти хэндлы через PEB процесса?

 

Однако в статье "Как стать невидимым в Windows NT", говорится, что мы всё-таки можем использовать LoadLibrary, чтобы сравнить хэндлы библиотек:

Может, посоветуете что-нибудь?

 

Сейчас читаю исходники. К примеру: http://www.hxhonk.com/2/3.htm

Код (Text):

1.     CreateRemoteThread(hProcess,
2.                        NULL,
3.                        0,    
4.                        pfnThreadRtn,
5.                        pszLibFileRemote,
6.                        0,
7.                        NULL);
8. }

Т.е. тут нет никакого WaitForSingleObject. И сразу же после этого кода вызывается оригинальная NtResumeThread.
Почему так? Кто-нибудь может это объяснить? Действительно ли это связано с тем, что при использовании WaitForSingleObject возникают баги?

 

А зачем тут вобще WaitForSingleObject()?

 

Я же говорил об этом уже.
WaitForSingleObject я вызываю после CreateRemoteThread в хукнутой NtResumeThread, чтобы хукнуть нужные функции до выполнения первых инструкций инфицируемого процесса.
Если не вызывать WaitForSingleObject , то запустится поток, хукающий функции, и, одновременно с ним запустится основная нить процессса, что не есть гут.
Так вот - парадокс в том, что если вызывать WaitForSingleObject - нихрена не работает. =)

 

Кто-нибудь, подкиньте код как вы хукали LdrInitializeThunk. Я запарился уже.

 

Для наглядности:
win2k sp3. запуск ie. родитель - зараженный explorer:

 

Сейчас поставил

Код (Text):

1. return 0;

прямо в начале функции Inject и оставил WaitForSingleObject. Работает.
А это значит, что перехват работает ... слишком долго что-ли? Настолько долго, что прям пе**ец ie не может запуститься?

 

Нет. Это не так. Я гоню.
return 0 ничего не меняет.

 

Нет. Всё-таки меняет.
Для диспетчера задач наконец-то вызывается отладчик и показывает Access Violation непонятно где:

 

Если заменить WaitForSingleObject на Sleep, то ничего не меняется.

 

Кто-нибудь хукал NtCreateThread ?
Отпишитесь о результатах плз.

 

Тут ( http://69.10.233.10/KB/system/InterceptWinAPICalls.aspx?display=PrintAll ) говорится что ...

Т.е. можно сплайснуть точку входа в процесс, по идее?
Это нормально будет работать?

 

Сейчас попробовал создать удалённый поток с помощью функции RtlCreateUserThread.
На winxp тестирую - при вызове ZwCreateThread (внутри RtlCreateUserThread) процесс, в котором создаётся этот удалённый thread начинает жрать 100% ресурсов CPU. То же самое в win2k. В win7 - всё ок.

Any ideas?

 

Причём я ставил INT3 в самое начало функции удалённого потока и исключения не произошло, значит ... не туда передаётся управление что-ли? Хотя, через CreateRemoteThread передавал тот же адрес точки входа потока - всё ок.

 

RtlCreateUserThread не региться в csrss и поэтому не может юзать wait-функции и т.д.

А вообще код ужасный, не обрабатывается множество ситуации, которые могут возникнуть. И вообще нужно создавать свои потоки в такой моде (зачем их два то? ) в момент, когда kernel32 готов передать управление ep главного модуля. Т.к. после resumeThread, в новом потоке нового процесса проходит еше куча всяких мега манипуляций(глядим eip), и поток(или процесс) еше не готов к полноценной работе в юзермоде, вероятно из-за чего и возникают ваши анамалии.

 

Так. С ntdll!RtlCreateUserThread вроде понятно. Надо было вызывать kernel32!ExitThread при выходе из функции потока.
Я вот ещё подумал - я же нахожусь в NtResumeThread и хэндл потока мне известен. Может, всё-таки сплайснуть context.Eip, чем новые потоки создавать?

 

Wow. o0

Its under development. Когда будет релиз - приведу его в порядок.

Т.е. в итоге что нужно делать?
Т.е. как отловить этот момент: "когда kernel32 готов передать управление ep главного модуля" ?

Respect.