Из своей программы, получаю адресс загрузки NTDLL.DLL и хочу анализировать PE-заголовок, но при попытки проверки MZ-сигнатуры выдается сообщение об ошибки, ошибка доступа к памяти, доступ к памяти запрешен!
VirtualProtect на весь SizeOfImage из NTDLL.DLL тоже не помогает, хотя функция возвращает не ноль.
При просмотре программы через ollyDBG, моя программа анализирует загловок NTDLL.DLL и выполняет то, что запланировано без ошибок.

Как я понел: При выполнении моей проги в контексте отладчика (т.е. при просмотре в ольке) ошибок при обращении к адрессному пространству NTDLL.DLL - НЕТ, как добиться нормальной работы, в чем тут проблема???

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

Код в студию

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

mov edx, [esp+004h] ; Адресс в модуль ntdll
xor dx, dx
@@:
cmp word ptr[edx], 5A4Dh ; cmp 'MZ'
jz @F
sub edx, 10000h
jmp @B
@@:
mov eax, edx ; Сохраняем ImageBase

Т.е. веду поиск адреса загрузки модуля в по сигнатуре в памяти.

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

vx.netlux.org/lib/vbp01.html#c15

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

GlOFF
проблема в том, что нужно внимательно изучать формат PE:
mov edx, [esp+004h] ; Адресс в модуль ntdll
не выравнен на страницу. поэтому при обратном поиске банально "проскакивает" MZ-сигнатуру.
обычно это делается так:
and edx, 0FFF00000h
а уж потом цикл с вычитанием....

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

Paxan Спасибо за ссылку!
DMD xor dx, dx - это вроде и есть выравнивание на 64 кб границу. Аналогочно and edx, 0FFFF0000h,
а and edx, 0FFF00000h чуть меньше в цикле болтаться.

Странный факт! Заходим в ОЛЮ, при загрузке модуля на вершине стека [esp] лежит адресс в kernel32 , а на [esp+4] адресс в ntdll.
А при запуске вне отладчика, по [esp+4] совсем другой адресс. (Проверял через вывод в MessageBox) Вот я и оперался на [esp+4].

Может здесь ошибка. Потому, что в отладчике и вне его структура стека различна?

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

GlOFF пишет:
Может здесь ошибка. Потому, что в отладчике и вне его структура стека различна?
только что проверил, так и есть. Правда я думаю DebugApi здесь ни при чем, скорее всего это зависит от параметров CreateProcess.

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

GlOFF пишет:
xor dx, dx - это вроде и есть выравнивание на 64 кб границу
не правильно.. надо например так: and DX,0F000h

-----
invoke OpenFire

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

mov EDX,[esp+004h]
and DX,0F000h

@@:
cmp word[EDX],'MZ'
je @F
sub EDX,01000h
jmp @B

@@:

вапще с каких пор размер страницы стал 10000 ??? опкурились чтоле...

-----
invoke OpenFire

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

Да что спорить:
( xor dx, dx ) == ( and edx, 0FFFF0000h ).
И работает как в одном, так и в другом способе!

seeq пишет:
только что проверил, так и есть. Правда я думаю DebugApi здесь ни при чем, скорее всего это зависит от параметров CreateProcess.
Вот, вот, наверное так и есть...

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

бля вы чо тупите-то?

GlOFF пишет:
( xor dx, dx ) == ( and edx, 0FFFF0000h ) но это совсем не равно and DX,0F000h !!!

у вас получаецо размер страницы 010000h == 65536 == 64кб !!!!!!! а она равна 4кб == 4096 == 01000h

-----
invoke OpenFire

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

Ice-T пишет:
бля вы чо тупите-то?

никто не тупит:
у тебя будет 16 циклов поиска на один цикл по коду GlOFF`а

для системных длл такое "упрощение" допустимо.

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

DMD а есле я пропишу ImageBase у ntdll.dll руками?

и вообще базу нтдлл проще взять из списка загруженных длл, адрес которой лежит в PEB, в свою очередь адрес которой лежит по адресу fs:[30]..

-----
invoke OpenFire

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

Ice-T пишет:
а есле я пропишу ImageBase у ntdll.dll руками
Ну пропиши и скажи винде: прощай Эту либу нельзя в памяти перемещать.

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

черт..

Archer опередил....

Ice-T
проще GetModuleHandle чем перебирать списки.. тем более, что основная цель GlOFF - не известна.

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

Вроде xor dx,dx здесь допустимо.
или может быть у кого-то получилось создать файлик с ImageBase = 401000?
а вот с sub edx, 10000h точно промахнулся =)

ps: про ntdll base через PEB уже была тема

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

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

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

-----
invoke OpenFire

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

Ice-T пишет:
есле адрес GetModuleHandle уже известен, то да.. а так, исходя из того, что автору понадобилась база нтдлл и того, что он не пошел стандартным путем, что-то подсказывает мне, что в импорте GetModuleHandle и GetProcAddress нету.. тогда их придецо искать в экспорте kernel32 предварительно получив его базу, а это буит проблемнее..

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

ну ты и загнул!
это же его собственное приложение!

GlOFF пишет:
Из своей программы, получаю адресс загрузки NTDLL.DLL и хочу анализировать PE-заголовок

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

Ладно, все по разу лопухнулись - внимательнее будем на будующее

а GlOFF истоки проблемы озвучил: нужно правильно найти какой-нибуть адрес из пространства NTDLL для поиска MZ-сигнатуры через листание страниц sub EDX,01000h
или в лоб получить базу через GetModuleHandle.
и, похоже, свою проблему уже решил.

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

DMD пишет:
это же его собственное приложение!
ну и что? =) мб суть в том, чтобы в импорте небыло этих функций =)

-----
invoke OpenFire

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

Ice-T пишет:
GlOFF пишет:
( xor dx, dx ) == ( and edx, 0FFFF0000h ) но это совсем не равно and DX,0F000h !!!
у вас получаецо размер страницы 010000h == 65536 == 64кб !!!!!!! а она равна 4кб == 4096 == 01000h

Я понимаю, что мой способ не пойдет для обычных файликов, но для системных библиотек, как сказал

DMD пишет:
для системных длл такое "упрощение" допустимо.

// Использую только динамический импорт (GetModuleHandle, GetProcAddress, .. не предлогать ).
Про PEB слышал, что недокументировано и может измениться в любой момент. Или какая разница?

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

Ice-T пишет:
у вас получаецо размер страницы 010000h == 65536 == 64кб !!!!!!! а она равна 4кб == 4096 == 01000h

Хм, аллокация адресного пространства происходит 64k блоками. Соответственно отображение DLL не может быть не выравненно на 64k. И собственно нафига искать сигнатуру там где её нет?!?!

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

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

GlOFF пишет:
для системных длл такое "упрощение" допустимо.
это имхо, но я бы не рисковал, ибо например в висте много что изменилось, что было допустимо в ранних виндах.. ну а отнимать по 64кб вообще не стОит..

-----
invoke OpenFire

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

Про грануляцию в 64К можно прочитать в документации к ZwMapViewOfSection.

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

S_T_A_S_ пишет:
Про грануляцию в 64К можно прочитать в документации к ZwMapViewOfSection.
Подскажи где взять эту документацию.

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

наверное тут:

MSDN Library - January 2005
Kernel-Mode Driver Architecture: Windows DDK
ZwMapViewOfSection

Parameters
BaseAddress
Pointer to a variable that receives the base address of the view. If the value of this parameter is not NULL, the view is allocated starting at the specified virtual address rounded down to the next 64-kilobyte address boundary.

-----
HOW MUCH BLOOD WOULD YOU SHED TO STAY ALIVE

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

GlOFF,


-----
Shalom ebanats!

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