Подскажите пожалуйста, есть ли какой нибудь метод указать lpParameter для уже созданного удаленного потока (CreateRemoteThread)?

Обычно мы его указывает когда создаем поток, а есть ли какой нибудь способ указать его когда поток уже создан, но еще не выполнен (создан SUSPENDED)? Кроме махинаций с GetThreadContext, получением rEsp и записыванием параметра напрямую в стек...

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

Какова цель? Если требуется множественные параметры , то можно сделать предварительно коллгэйт и передать все сразу, а потом уже запускать CreateRemoteThread с указателем на шеллкод ...

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

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

mak пишет:
Какова цель?

Цель - простая, передать параметры другому процессу, во время инжекта... Только сделать это красиво, и без лишнего кода.. Ты прав, создать еще один CreateRemoteThread и передать параметры из него - это выход, но хотелось бы все сделать без дополнительного потока.

Кстати, вот тут что нарыл. Когда поток создан с помощью CreateRemoteThread, по умолчанию, Eip у этого потока стоит на RtlUserThreadStart, которая (на вин 7 по крайней мере, для x32 процесса) принимает два параметра, но принимает их не через stdcall/стек, а через регистры EAX и EBX.
EAX - код с которого надо начать выполнение потока (твой код)
EBX - как раз тот параметр, который передается твоему коду.

Получается то что я спрашивал, можно сделать, установив необходимые значение регистров EAX и EBX контекста этого потока...
Но проблема в том что на XP функции RtlUserThreadStart нет.. надо будет разбираться...




Еще одна проблема... после создания процесса по ZwCreateUserProcess, до отпускания его основного потока по ZwResumeThread никак нельзя узнать все модули загруженные в этот процесс, CreateToolHelp32SnapShot возвращает ошибку PARTIAL_COPY... нет какого нибудь решения узнать список модулей...? Или хотя бы ImageBase от ntdll.dll?

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

Хытрые манипуляции с контекстом суспенженого потока могут не быть совместимыми с разными защитами, типа аверов/фаеров, не рекомендуется так делать.
ntdll не релоцируется, бери локальную базу.

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

Может поможет приложение внизу по мульти параметрам.

Enigma пишет:
Еще одна проблема... после создания процесса по ZwCreateUserProcess, до отпускания его основного потока по ZwResumeThread никак нельзя узнать все модули загруженные в этот процесс, CreateToolHelp32SnapShot возвращает ошибку PARTIAL_COPY... нет какого нибудь решения узнать список модулей...? Или хотя бы ImageBase от ntdll.dll?

На какой винде тест? 64 или 32? Пеб Лодер лист может?


4a07_11.03.2011_CRACKLAB.rU.tgz - createremotethreadex.zip

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

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

Список модулей в пеб не поможет, до инициализации первого потока он не заполнен.

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

Archer пишет:
Хытрые манипуляции с контекстом суспенженого потока могут не быть совместимыми с разными защитами, типа аверов/фаеров, не рекомендуется так делать.

Так а че же делать... если не манипулировать контекстом, то придется создавать свой удаленный поток. А для фаеров мне кажется пофиг, что ты контекстом манипулируешь, что удаленный поток создаешь, все равно как бы опасность и то и другое..

Как же тогда вообще в процесс инжектится, чтобы аверов не рассердить?

Archer пишет:
ntdll не релоцируется, бери локальную базу

Вообще в ntdll.dll есть релоки, Relocations are stripped не установлено, так что фактически, она может быть загружена куда угодно...

mak пишет:
Может поможет приложение внизу по мульти параметрам.

Это как бы не особо универсально

mak пишет:
На какой винде тест? 64 или 32?

x64

mak пишет:
Пеб Лодер лист может?

Точно, вот это в точку, спасибо!

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

Перечисление страниц памяти тогда ? И гетмодулфайлнэйм ?

Enigma пишет:
mak пишет:
На какой винде тест? 64 или 32?

x64

ууу , тогда так и чувствовал , там есть замут какой то с CreateToolHelp32SnapShot и партиал копи , это описано в МСДНе , нужно полистать .. хз тогда

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

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

mak пишет:
Перечисление страниц памяти тогда ? И гетмодулфайлнэйм ?

Да, получается что без перечисления никуда... про CreateToolHelp32SnapShot и x64 тоже читал, но думал это происходит только когда вызываешь CreateToolHelp32SnapShot из x86 процесса для x64.

Хотя заметил одну итересную штуку, если после ZwCreateUserProcess приаттачится к новому процессу со второй олькой (первая даже процесса на этой стадии не видит), Alt + M - показывает все модули. Там наверное как раз и идет перечисление страниц.

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

Дело не в том, что фаерам/аверам не понравится твой код, это само собой. А в том, что некоторые сами так делают, и твой код тупо не будет работать, если игрища с контекстом будут.
Ты плохо слушаешь, нтдлл НЕ релоцируется. И не в релоках дело, а в концепте ос, туда коллбеки из ядра приходят.
З.Ы. гетмодулфайлнэйм, который тут посоветовали, тоже ходит по пебу, тогда уж GetMappedFileName

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

Enigma вот я сорс выкладывал с поиском модуля через перечисление страниц

https://ssl.cracklab.ru/f/action=vthread&forum=6&topic=17825&page=0#30

как бы для основы.

-----
Yann Tiersen best and do not fuck

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

Enigma
При создании потока адрес, с которого каждый поток начинает выполнение, заносится в структуру ETHREAD, точные смещения для конкретной версии ОС можно из отладочных символов узнать, так вот подменив его, можно не выполнять игры с контекстом и (в теории) добиться желаемого. Но сам я этого не проверял. Эти поля описаны у Руссиновича, под рукой щас инфы нет, если есть интерес, то позже могу глянуть.

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

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

Это информационные поля, которые можно получить либо изменить через NtSetInformationThread. На выполнение они дальше после KeInitThread влияния не оказывают.

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

Alchemistry пишет:
Это информационные поля, которые можно получить либо изменить через NtSetInformationThread. На выполнение они дальше после KeInitThread влияния не оказывают.

А какой именно класс для NtSetInformationThread? Я пролазил, но вроде ничего такого не нашел...?

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

ThreadQuerySetWin32StartAddress

соотв. NtQueryInformationThread для получения и
NtSetInformationThread для установки

Поле ETHREAD->Win32StartAddress, см в отладчике.
Опять же ничего кроме информации из этого вытянуть врядли выйдет.

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

Alchemistry пишет:
ThreadQuerySetWin32StartAddressсоотв. NtQueryInformationThread для получения и NtSetInformationThread для установки

Но это все равно малость не то. Тут мы можем поменять адрес с которого поток начнется (хотя мне и это тоже надо, спасибо), а мне бы хотелось поменять еще и парамерт, который передается функции обработки потока...

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

Enigma По поводу lpParameter , а что если использовать указатель на структуру с параметрами?!
Мутили еще с передачей параметров над RtlRemoteCall , там тоже есть ограничение на параметры вроде , но эту функцию рипали и переделывали ...

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

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

Все что делает ваша RtlRemoteCall это последовательность NtSuspendThread->NtGetThreadContext->NtWriteVirtualMemory->NtSetThreadContext->NtResumeThread.

Предварительно поток и процесс еще надо открыть с правами на суспенд и запись в память.
Сосредоточьтесь

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

Хотелось бы подвести точку в этой теме, может кому пригодится...

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

Единственное как можно все это сделать, перехватить ZwResumeThread для этого потока и поменять регистры контекста Eax и Ebx.
Eax - должен содержать адрес обработчика потока
Ebx - как раз тот парамерт для потока

Но тут тоже не все гладко.. в Виндовз 2000, парамерт Ebx игнорируется, и его (парамерт для потока) установить нельзя...

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

Может кто еще подскажет, надо выполнить инжект exe файла в другой процесс, при это образ
оригинального файла надо удалить... Процесс выглядит так:

1. создаем процесс ZwCreateUserProcess('process.exe');
2. удаляем образ process.exe в процессе через ZwUnmapViewOfSection
3. делаем инжект своего inject.exe
4. корректируем PEB.ImageBase в удаленном процессе
5. перехватом ZwResumeThread корректируем начало исполнения кода на свой inject.exe

но вот потом, при вызове ZwResumeThread этот процесс падает с ошибкой... Если не делать #2 то все нормально, наш процесс запускается нормально.. В чем тут может быть дело...?

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

Для DLL надо еще править EntryPoint в списке модулей в PEB, возможно в данном случае это тоже нужно делать.

-----
Yann Tiersen best and do not fuck

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

PE_Kill пишет:
Для DLL надо еще править EntryPoint в списке модулей в PEB, возможно в данном случае это тоже нужно делать.

Для длл - понятно, а вот если инжектить не длл а главный образ exe...?

Тем более что тут задача еще усложняется тем что:
1. списки всех модулей в пеб еще не инициализированы, они просто пустые.. Они заполняются только после ZwResumeThread а там надо до него все сделать..
2. Оля не аттачится к процессу после его создания с ZwCreateUserProcess.. вываливает ошибку.. аттачится только после ZwResumeThread.. т.е. тяжко отследить где именно падает..

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

Enigma пишет:
1. списки всех модулей в пеб еще не инициализированы, они просто пустые.. Они заполняются только после ZwResumeThread а там надо до него все сделать..
-- на сколько помнится про сам exe + ntdll + kernel(base) там уже есть инфо.
Enigma
- вообще по запуску exe из памяти куча примеров в сети.
1. создаем процесс ZwCreateUserProcess('process.exe');
-suspend + читаем контекст осн. потока
2. удаляем образ process.exe в процессе через ZwUnmapViewOfSection
-- после чего выделяем память по адресу ep, если возможно
3. делаем инжект своего inject.exe
--пишем в выделенную память
4. корректируем PEB.ImageBase в удаленном процессе
--не надо, если по EP память удалось выделить, если нет - релоки обрабатываем
5. перехватом ZwResumeThread корректируем начало исполнения кода на свой inject.exe
-- просто пишем контекст и resume

-----
продавец резиновых утёнков

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

HiEndsoft пишет:
-- на сколько помнится про сам exe + ntdll + kernel(base) там уже есть инфо.
В разных виндах по разному, но в основном указатель на список модулей на тот момент вообще равен нулю.

-----
Yann Tiersen best and do not fuck

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

HiEndsoft пишет:
4. корректируем PEB.ImageBase в удаленном процессе--не надо, если по EP память удалось выделить, если нет - релоки обрабатываем

Если удалось выделить - то конечно не надо, а во всех остальных случаях - обязательно. Потому что GetModuleHandle(nil) берет значение как раз из пеб..

HiEndsoft пишет:
5. перехватом ZwResumeThread корректируем начало исполнения кода на свой inject.exe-- просто пишем контекст и resume

И процесс вываливается с ошибкой...

Делая все тоже самое, но без ZwUnmapViewOfSection - все работает как часы, если с ZwUnmapViewOfSection - то валимся в ошибке черт знает где и никак эту гадость не отладить, дебагеры не аттачатся к процессу в это время...

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

Отлаживай через ринг0. Или попробуй 2 ольку, она пораньше цепляться к процессу может, вроде.

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

Archer пишет:
Отлаживай через ринг0.

Так и придется через неудобный WinDbg...


Archer пишет:
Или попробуй 2 ольку, она пораньше цепляться к процессу может, вроде.

Она тоже не аттачится. Первая олька даже процесса не видит, созданного после ZwCreateUserProcess, вторая процесс видит, а приаттачится не может.

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