В какой памяти находится PEB?

@rao · Регистрация: 02.04.2014

Author24 — интернет-сервис помощи студентам

В книжке Robert Custer "WinDbg. From A to Z!" на 26 странице изображена вот такая схема: (см. сложение). На ней структуры PEB и TEB размещены над чертой, разделяющей user- и kernel-режимы (в области адресного пространства процесса).

Для получения указателя PEB используется функция NtQueryInformationProcess. которая, судя по префиксу "Nt" должна вызываться из режима ядра.

ВОПРОС(ы): как функция ядра может работать с "пользовательской" памятью (она же выделяется из выгружаемого пула?) А как же возможные страничные ошибки на высоком IRQL? Или не любая функция в режиме ядра вызывается с повышением IRQL до уровня DPC/dispatch? На картинке все правильно?

P.S.: в WinDbg команда !peb показывает (для текущего процесса, т.е. для самого отладчика):

lkd> !peb
PEB at 000007fffffdf000

Запустил VMMap, он показывает, что этот адрес типа "Private Data". Вроде как действительно пользовательское пространство.

@rao · 18.03.2015, 09:10 **[ТС]**

Все правильно, Robert Custer не обманул. Недавно прочитал в книге М. Руссиновича "Внутреннее устройство Windows" (книга 1, стр. 424):

EPROCESS-структура и основная часть связанных с ней структур данных на-
ходятся в адресном пространстве системы. Единственным исключением является
блок переменных окружения процесса — process environment block (PEB), — кото-
рый находится в адресном пространстве процесса (в нем содержится информация,
доступная коду, выполняемому в режиме пользователя).

Убежденный · 18.03.2015, 09:31

Сообщение от rao

В книжке Robert Custer "WinDbg. From A to Z!" на 26 странице изображена вот такая схема: (см. сложение). На ней структуры PEB и TEB размещены над чертой, разделяющей user- и kernel-режимы (в области адресного пространства процесса).

Все верно, PEB и TEB - это юзермодные структуры.
Список модулей процесса, хранящийся в PEB, тоже размещается в user mode.

Сообщение от rao

Для получения указателя PEB используется функция NtQueryInformationProcess. которая, судя по префиксу "Nt" должна вызываться из режима ядра.

На самом деле префикс еще ни о чем не говорит.
В системе есть два набора Nt/Zw-функций, один пользовательский, в ntdll.dll,
для вызова обычными программами (не драйверами), второй ядерный, причем в
первом случае Nt- и Zw-функции - одно и то же, во втором - нет (разница в
проверках безопасности).

Сообщение от rao

ВОПРОС(ы): как функция ядра может работать с "пользовательской" памятью

Также, как обычно.

Сообщение от rao

А как же возможные страничные ошибки на высоком IRQL?
Или не любая функция в режиме ядра вызывается с повышением IRQL до уровня DPC/dispatch?

Большинство "нормальных" драйверных функций и калбэков работают на PASSIVE_LEVEL и
APC_LEVEL, где страничные сбои не страшны. В других случаях драйвер может залочить
нужную память, отобразить ее в в системный диапазон адресов и обращаться к ней
на любом IRQL и в контексте любого процесса...

@rao · 18.03.2015, 19:12 **[ТС]**

Подзапутался немного.
Возьмем к примеру функцию SetTimer. Лежит она в User32.dll

Ищем WinDbg'ом:

Assembler

1
2
3

lkd> x user32!*SetTimer*
00000000`777e6930 USER32!ZwUserSetTimer = <no type information>
00000000`777e6930 USER32!NtUserSetTimer = <no type information>

Нету!! Как так? В winuser.h она объявлена как:

C

WINUSERAPI UINT_PTR WINAPI SetTimer(
    __in_opt HWND hWnd,
    __in UINT_PTR nIDEvent,
    __in UINT uElapse,
    __in_opt TIMERPROC lpTimerFunc);

т.е. без всяких префиксов, а вызывается совсем другое имя. Где и кем осуществляется это перенаправление?

2) И еще: Руссинович о префиксе Zw пишет:

Зеркальная точка входа для системных служб (имена которых начинаются
с Nt), которая устанавливает предыдущий режим доступа к ядру, что ис-
ключает проверку параметров, поскольку системные службы Nt проверяют
параметры только в том случае, если предыдущий режим доступа был
пользовательским

находим в ntdll:

Assembler

lkd> x ntdll!*SetTimer*
...
00000000`77a418d0 ntdll!NtSetTimer = <no type information>
...
00000000`77a418d0 ntdll!ZwSetTimer = <no type information>
...

адреса одинаковые. (т.е. это одна и та же функция получается что ли?)

заглядываем в содержимое (просто из любопытства):

Assembler

lkd> u ntdll!ZwSetTimer
ntdll!NtSetTimer:
00000000`77a418d0 4c8bd1          mov     r10,rcx
00000000`77a418d3 b85f000000      mov     eax,5Fh
00000000`77a418d8 0f05            syscall
00000000`77a418da c3              ret

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

Убежденный · 18.03.2015, 19:37

1) SetTimer - это exported name, а Nt(Zw)UserSetTimer - так называемое internal name.
При сборке dll можно указать (в DEF-файле, например), чтобы некоторая функция
имела в секции экспорта другое имя.

2)

Сообщение от rao

адреса одинаковые. (т.е. это одна и та же функция получается что ли?)

В режиме пользователя между Nt- и Zw-функциями нет никакой разницы,
каждая пара указывает на одну и ту же точку входа.

Сообщение от rao

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

Да. syscall/sysenter(/int0x2e на старых системах) вызовет переход в ядро, на
специальный обработчик, там он найдет адрес функции по индексу 0x5f и
вызовет его. Вот там и будут все необходимые проверки и вообще вся
настоящая работа SetTimer.

@rao 903 / 424 / 159 Регистрация: 02.04.2014 Сообщений: 1,206
		1
	В какой памяти находится PEB? 23.02.2015, 23:21. Показов 1769. Ответов 4 Метки нет (Все метки) В книжке Robert Custer "WinDbg. From A to Z!" на 26 странице изображена вот такая схема: (см. сложение). На ней структуры PEB и TEB размещены над чертой, разделяющей user- и kernel-режимы (в области адресного пространства процесса). Для получения указателя PEB используется функция NtQueryInformationProcess. которая, судя по префиксу "Nt" должна вызываться из режима ядра. ВОПРОС(ы): как функция ядра может работать с "пользовательской" памятью (она же выделяется из выгружаемого пула?) А как же возможные страничные ошибки на высоком IRQL? Или не любая функция в режиме ядра вызывается с повышением IRQL до уровня DPC/dispatch? На картинке все правильно? P.S.: в WinDbg команда !peb показывает (для текущего процесса, т.е. для самого отладчика): lkd> !peb PEB at 000007fffffdf000 Запустил VMMap, он показывает, что этот адрес типа "Private Data". Вроде как действительно пользовательское пространство. Миниатюры 0

@rao 903 / 424 / 159 Регистрация: 02.04.2014 Сообщений: 1,206
	18.03.2015, 09:10 [ТС]	2
	Все правильно, Robert Custer не обманул. Недавно прочитал в книге М. Руссиновича "Внутреннее устройство Windows" (книга 1, стр. 424): EPROCESS-структура и основная часть связанных с ней структур данных на- ходятся в адресном пространстве системы. Единственным исключением является блок переменных окружения процесса — process environment block (PEB), — кото- рый находится в адресном пространстве процесса (в нем содержится информация, доступная коду, выполняемому в режиме пользователя). 0

Убежденный Ушел с форума 16473 / 7436 / 1187 Регистрация: 02.05.2013 Сообщений: 11,617 Записей в блоге: 1
	18.03.2015, 09:31	3
	Сообщение от rao В книжке Robert Custer "WinDbg. From A to Z!" на 26 странице изображена вот такая схема: (см. сложение). На ней структуры PEB и TEB размещены над чертой, разделяющей user- и kernel-режимы (в области адресного пространства процесса). Все верно, PEB и TEB - это юзермодные структуры. Список модулей процесса, хранящийся в PEB, тоже размещается в user mode. Сообщение от rao Для получения указателя PEB используется функция NtQueryInformationProcess. которая, судя по префиксу "Nt" должна вызываться из режима ядра. На самом деле префикс еще ни о чем не говорит. В системе есть два набора Nt/Zw-функций, один пользовательский, в ntdll.dll, для вызова обычными программами (не драйверами), второй ядерный, причем в первом случае Nt- и Zw-функции - одно и то же, во втором - нет (разница в проверках безопасности). Сообщение от rao ВОПРОС(ы): как функция ядра может работать с "пользовательской" памятью Также, как обычно. Сообщение от rao А как же возможные страничные ошибки на высоком IRQL? Или не любая функция в режиме ядра вызывается с повышением IRQL до уровня DPC/dispatch? Большинство "нормальных" драйверных функций и калбэков работают на PASSIVE_LEVEL и APC_LEVEL, где страничные сбои не страшны. В других случаях драйвер может залочить нужную память, отобразить ее в в системный диапазон адресов и обращаться к ней на любом IRQL и в контексте любого процесса... 1

Убежденный Ушел с форума 16473 / 7436 / 1187 Регистрация: 02.05.2013 Сообщений: 11,617 Записей в блоге: 1
	18.03.2015, 19:37	5
	1) SetTimer - это exported name, а Nt(Zw)UserSetTimer - так называемое internal name. При сборке dll можно указать (в DEF-файле, например), чтобы некоторая функция имела в секции экспорта другое имя. 2) Сообщение от rao адреса одинаковые. (т.е. это одна и та же функция получается что ли?) В режиме пользователя между Nt- и Zw-функциями нет никакой разницы, каждая пара указывает на одну и ту же точку входа. Сообщение от rao чего то никаких обещанных проверок параметров совсем не видать. Или они будут выполняться в вызванной системной службе? Да. syscall/sysenter(/int0x2e на старых системах) вызовет переход в ядро, на специальный обработчик, там он найдет адрес функции по индексу 0x5f и вызовет его. Вот там и будут все необходимые проверки и вообще вся настоящая работа SetTimer. 1