Из своей программы, получаю адресс загрузки 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

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

http://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,


-----
http://fbi.cih.ms