Вообщем создаю обычный удаленный трэд в чужом процессе - x64 (Win7):


Любой трэд начинает стартовать с недр, и так далее с потрохов ntdll.dll[2B810] |
".text":0000000076F9B810 <RtlUserThreadStart>:


В случае с обычной загрузкой такого же обычного exe - BaseThreadInitThunk предварительно вызывает эту обвертку-функу, которая на автомате завершит главный трэд:


В случае же создания удаленного потока, стартуем оттуда-же с RtlUserThreadStart, однако: BaseThreadInitThunk = (LPTHREAD_START_ROUTINE)Start_Thread_Addr; Отсюда следует, что поток нужно завершать своими силами

Очевидный вопрос: а нельзя ли в случае удаленного трэда как-то хитро положить на плечи системы "разгребание этого говна" (ExitThread), когда последний RET отправит RIP обратно в кишки ntdll

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

Во-первых, почему CreateRemoteThreadEx, а не CreateRemoteThread?
Во-вторых, достаточно вернуть из Start_Thread_Addr значение, оно и будет ExitCode.

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

Archer пишет:
Во-первых, почему CreateRemoteThreadEx, а не CreateRemoteThread?
Во-вторых, достаточно вернуть из Start_Thread_Addr значение, оно и будет ExitCode.
не-не-не! Вы меня не поняли.
В другом процессе - создаю удаленный поток. Его ведь нужно завершить потом - надо вызвать ExitProcess. Но, теоретически, завершить за меня его может и система (как в случае порождения main трэда системой)?
ExitCode - эт я лишнее написал, типа нечаяно

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

ELF_7719116 пишет:
В другом процессе - создаю удаленный поток. Его ведь нужно завершить потом - надо вызвать ExitProcess. Но, теоретически, завершить за меня его может и система (как в случае порождения main трэда системой)?
ExitCode - эт я лишнее написал, типа нечаяно
Наверное не ExitProcess а ExitThread?

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

ELF_7719116 пишет:
Его ведь нужно завершить потом
Завершить ЕГО-это процесс или поток? Если процесс, то при завершении main thread ничего не случится, он не отличается от других потоков, и процесс помрёт, когда последний поток завершится. Если про поток, то верни управление из Start_Thread_Addr, он и помрёт.

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

ExitThread. Поток. Всё танцует вокруг удаленного потока.

Пытаюсь обьяснить, просто не совсем удачно написал (ExitCode и вызод из процесса не при делах): возвращаю управление из Start_Thread_Addr, оказываюсь в RtlUserThreadStart тут:


а RET в RtlUserThreadStart ведёт вникуда! Там ноль в стеке по адресу возврата. т.е. в ring-3 тупо выполнился RtlUserThreadStart и всё. На этом поток, ес-но, рушится c ACCESS_VIOLATION

Добавлено спустя 1 час 42 минуты
Всё, я наконец-то понял, почему писал весь этот бред
Да, действительно для всех потоков сначала: ntdll.RtlExitUserThread -> потом kernel32.BaseThreadInitThunk

СТУПОР НАСТУПИЛ ВОТ ИЗ-ЗА ЧЕГО:
CreateRemoteThreadEx выполняет следующий банальный код:

по аналогии с x86, я думал, что RCX - как один агрумент, и пихать в стек ничего не надо! ... и, вконце концов, понял, что LoadLibraryW затирает мой kernel32.BaseThreadInitThunk, в результате я вижу только в стеке оставшейся ntdll.RtlExitUserThread. Я сначала, ОХФИГЕЛ!!! Какого хера ВООБЩЕ, WinAPI что-то затирает в стеке?! WTF???

вообщем, перенес всё внимание в WinAPI и понял, что ей нужна выше адреса возврата еще какая-то структура (0x60?). Вследствие чего, код дополнился двумя командами и стал стабильно-рабочим без всяких фокусов:


Как эт понять?? Капитан очевидность в замешательстве!

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

Почитать мсдн/любой другой ресурс по поводу конвенции о вызове функций в х64.

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