Как получить хендл библиотеки

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

Пытался через GetModuleHandle, но она возвращает базу либы в памяти, а не хендл. Соответственно VirtualProtectEx и WriteProcessMemory ругаются, что я им подставил "ERROR_INVALID_HANDLE" (00000006). LoadLibrary так-же возвращает базу, OpenProcess требует Pid и непонятно, от куда его взять. Если кто в курсе, поделитесь опытом..

Для экспериментов с GetModuleHandle пробовал сравнить её выхлоп, с логом WinDbg - оказалось, точно базу возвращает, а не хендл:

Код (ASM):

1. format   PE gui
2. include 'win32ax.inc'
3. ;---------
4. .data
5. capt     db   ' Инфо',0
6. text     db   ' База в памяти системных DLL',13,10
7.          db   ' ---------------------------',13,10
8. buff     db     128 dup(0)
9. prnFrmt  db   ' GDI32.dll.....: %08X',13,10
10.          db   ' Kernel32.dll..: %08X',13,10
11.          db   ' Ntdll.dll.....: %08X',13,10
12.          db   ' User32.dll....: %08X',0
13. ;---------
14. .code
15. start:   invoke  GetModuleHandle,<'user32.dll',0>
16.          push    eax
17.          invoke  GetModuleHandle,<'ntdll.dll',0>
18.          push    eax
19.          invoke  GetModuleHandle,<'kernel32.dll',0>
20.          push    eax
21.          invoke  GetModuleHandle,<'gdi32.dll',0>
22.          push    eax
23.  
24.          invoke  wsprintf, buff, prnFrmt
25.  
26.          invoke  MessageBox,0,text,capt,0
27.          invoke  ExitProcess, 0
28. .end start
29.  

 

Врайтпроцмемори нужен хэндл процесса, в адресное пространство которого производится запись. Нтдлл это не процесс

 

Примерно так же как kernel32(kernelbase), но на 1 инструкцию короче:

Код (ASM):

1. mov eax,DWORD[fs:0x30]
2. mov eax,DWORD[eax+0x0C]
3. mov eax,DWORD[eax+0x1C]
4. ;mov eax,[eax]
5. mov eax,DWORD[eax+8]

ЗЫ: по-моему если нету нужды работать до загрузки kernel32 все тупо берут ее, разматывают экспорт на предмет GetModuleHandle/LoadLibrary и GetProcAddress, и получают что хотят.
ЗЗЫ: если ты не сплайсишь апи ntdll нафиг тебе ее база? Функции приведены из kernel32

--- Сообщение объединено, 9 июн 2019 ---

Омг, вчитался и омг. У библиотек нету хендлов в привычном понимании (несмотря на то, что GetModuleHandle так называется), OpenProcess возвращает хендл процесса, а не либы в нем, VirtualProtectEx хочет хендл процесса (открытого - сюрприз - OpenProcess'ом или CreateProcess'ом) и адрес страницы, которой ты хочешь поменять атрибуты. Тебе желательней всего выделить память в целевом процессе, загрузить туда свой код и уже им устанавливать перехватчики (после того как найдешь базу kernel32, размотаешь ее экспорт и соберешь свой импорт динамически).

--- Сообщение объединено, 9 июн 2019 ---

И еще ЗЫ: CreateRemoteThread позволит запустить код, устанавливающий перехватчики в целевом процессе, а pid получается например через CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS,0)/Process32First/Process32Next

 

Коцит,

> WriteProcessMemory требует хендла Ntdll.dll

С чего вы это взяли ?

 

Почему бы не использовать хотпатч?

 

хорошо.. объясню иначе..
Допустим я хочу скрыть свой процесс от "Диспетчера задач" винды. Дизасм показал, что для перечисления процессов "taskmgr.exe" использует ZwQuerySystemInformation с классом(5), которая лежит в Ntdll.dll. Точку-входа в ZwQuery я нашёл, и даже чз rep.movsb считал от туда первые 5-байт. А вот при записи туда-же своего джумпа (тоже через movsb), получаю ошибку "Нет доступа на запись".. и это не удивительно. Тут дело в другом..

То-что я читаю/пишу - это операции с копией Ntdll.dll, которую система проецирует в моё пространство. Реальные байты остаются не тронутыми, и от моих телодвижений "Диспетчеру" не холодно, не жарко - он сам вызывает ZwQuery на прямую из Ntdll.dll (а не из моего процесса), и тоже получает проекцию этой либы в своё пространство.

Теперь, если я из своего процесса буду искать "Диспетчер задач" и обнаружив, дописывать себя в его процесс, то вполне может оказаться, что юзер вообще не планирует запускать диспетчер. То есть я буду заниматься не тем, что надо.. Хотя и тут непонятно, как мне получить доступ на запись в его Ntdll.dll (опять нужен хендл для VirtualProtectEx).

Поэтому я решил рассмотреть вариант, когда перехватывается не процесс-жертва (в данном случае taskmgr.exe), а сразу Ntdll.dll на нижнем уровне. В этом и суть того, что я не подгружаю её в своё пространство (получится опять проекция), а пытаюсь взять её хендл на прямую. В этом случае, пока мой процесс будет в памяти - мне без разницы, кто будет вызывать ZwQuerySystemInformation с параметром(5), поскольку я выделю в нём память и расположив там свой код, буду заниматься своими делами.

Думаю, что тут TrashGen, прав, и нужно попробовать получить доступ на запись хотя-бы по хендлу своего процесса, в область памяти Ntdll.dll 0х7с900000. Но тогда мой план с перехватом самой Ntdll.dll оказывается нереализуем? Ведь эта либа помоему считается частью исполняющего процесса Ntoskrnl.exe (Executive), а добраться до него из юзера не так просто, как хотелось-бы. Значит остаётся только искать процесс диспетчера чтоли? Имхо это вообще ламерский вариант, и должно быть что-то покруче..

--- Сообщение объединено, 9 июн 2019 ---

спасибо, почитаю..

Код (Text):

1. BOOL WriteProcessMemory(
2.     HANDLE hProcess,             // handle to process whose memory is written to
3.     LPVOID lpBaseAddress,        // address to start writing to
4.     LPVOID lpBuffer,             // pointer to buffer to write data to
5.     DWORD nSize,                 // number of bytes to write
6.     LPDWORD lpNumberOfBytesWritten     // actual number of bytes written
7.    );
8.  

 

ntdll.dll это не кернел, а юзермод. В каждом процессе своя копия ее образа. Хендла у нее нету, то, что называется хендлом библиотеки - ее базовый адрес. Ты не подгружаешь нтдлл в свой процесс, по секрету сообщаю, что это нтдлл загружает все что грузится в процесс, это загрузчик. Еще один секрет "хендл своего процесса" это -1 (0xFFFFFFFF), любая функция, принимающая хендл процесса поймет, что -1 свой процесс. Можешь попытаться застелсить что-нибудь в своем процессе, будет очень познавательно.

 

Коцит,

> пытаюсь взять её хендл на прямую.

Какой есчо хэндл". Ну у тебя и каша в голове, просто жесть. У каждого процесса своё адресное пространство и список описателей(хэндлов"). У каждого процесса своя копия проекции ntdll, файловая секция отображена в ядро и проецируется ядром в процесс при его создании. Процесс к ядерным ресурсам доступа не имеет, для этого режим должен быть ядерным.

 

ну эта тема должна быть глубоко в разделе бегиннерз...

 

Нет, мы присутствуем при рождении абсолютно недетектируемого руткита, который не возьмет ни одна проактивка. И который поставит под сомнение само существование винды. Разве ты не чувствуешь этот волнующий возвышенный момент?

 

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

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

--- Сообщение объединено, 9 июн 2019 ---

один хоть более вразумительный ответ

 

WriteProcessMemory принтмает хендл процесса, в виртуальную память которого нужно произвести запись, при чем тут ntdll? у динамических библиотек нет хендлов...

 

Rel,
Он думает что ntdll и ntoskrnl etc это всё процессы:

> WriteProcessMemory требует хендла Ntdll.dll
>> С чего вы это взяли ?
>>> HANDLE hProcess

 

Вы не отвечаете на ответ! Вопрос задайте сначала

 

На самом деле хендл библиотеки тоже для ламеров, вот взять хендл функции и с помощью WriteProcessMemory в него джумп вставить, вот правильный стратегический размах. Или взять хендл имени процесса и CloseHandle на него кастануть.

 

Тс, Вы бы хоть в msdn заглянули для начала...
Насколько я понял, Тс хочет разместить глобальный хук, дабы во все подряд процессы не инжектиться. Сделать у него это не выйдет из юзермода, потому что существует CoW. Есть конечно документированный дедовский трюк с NtUserSetWindowsHookEx, но про него каждый ав должен знать. Да и сплайсить так себе затея, хотя бы хардбряки нужно пробовать.

 

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

 

как вариант, перехватить NtCreateProcess во всех процессах (ну или хотябы в эксплорере, для начала) и ловить этим перехватом запуск taskmgr.exe
А круче только с патчем нтдлл внутри своего процесса и ожидания чего то от taskmgr при этом^^

 

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

--- Сообщение объединено, 9 июн 2019 ---

https://blogs.msdn.microsoft.com/mithuns/2010/03/24/image-file-execution-options-ifeo/

 

Патчите дллку на диске.

Если серьезно, то надо открыть процесс taskmgr и там уже патчить , а не у себя.