Трансляция адресов, x86, без PAE.

Почему? Код же находится выше 2гб, почему на него будут влиять изменение cr3?

Меня давно интересует такой вопрос - 0x401000 - Это виртуальный адрес, справедливый для какого-то процесса. Если я набираю !pte 0x401000, то для какого процесса он мне выдаст pte?

PAE меня пока не интересует, так что можно было бы.. но опять я криворукий =( Я эту функцию пробовал самой первой до того, как задал тут вопрос. Делал так

Код (Text):

1. dirBase = (unsigned int *) MmGetVirtualForPhysical( RtlConvertLongToLargeInteger(eproc->DirBase) );

Получал виртуальный адрес, но при попытке обратться по нему получал бсод(

 

rei3er

имхо, нет
Ихмо да...

пространство ядра идентично для каждого процесса (т. е 512 (256) элементов PDE в каталоге страниц каждого процесса должны содержать одинаковые значения)

Ет-то хорошо, вот только как добраться до директорий зная только CR3, тобишь физический адрес, а вот перевести его в виртуальный с PAE уже не так то просто. Т.е. Чтобы было понятно Поменять то мы CR3 можем, но вот только та новая таблица на которую он будет указывать ДОЛЖНА СОДЕРЖАТЬ СТАРЫЕ ЗАПИСИ, иначе мы в ауте.

КОРОЧЕ при грамотно спроектированной системе со включеной Page Address Extension менять CR3 невозможно. (вот если PAE будет выключен, то есть способ поиска логического CR3).

 

lews
Что-такое eproc->DirBase.
Вот код который работает без РАЕ

Код (Text):

1. ; PAE режим должен быть отключен
2.         mov eax,cr3
3.         xor al,al
4.         and ah,0FCh
5.  
6.                           push eax
7.  
8.         push L 0
9.         push eax
10.         call MmGetVirtualForPhysical
11.  
12.         push eax
13.         call dmes3
14.         db "STEALTH: CR3 = %.8X логический и %.8X физический",0
15. dmes3:      call DbgPrint
16.  
17.         pop eax
18.         pop eax
19.         pop eax

 

так а я что написал?

наш код выполняется в режиме ядра
если предположить, что устанавливаемое значение CR3 валидно (взято у реально существующего процесса), то все будет нормально
а не содержать старые записи каталог страниц с адресом, который мы устанавливаем в CR3, просто не может
иначе как при переключении контекста на процесс с данным CR3 он сможет работать с нашим кодом (который априорно должен быть доступен всем процессам)

 

Код (Text):

1. struct _EPROCESS{
2.   UCHAR shift[0x18];
3.   unsigned int DirBase;
4. };
5.  
6. _EPROCESS *eproc;
7.  
8. PsGetProcessByProcessId(int pid, (PEPROCESS *)&eproc);

 

lews


Пытаюсь руками транслировать вирт. адрес в физический(или установить, что он недействителен) для заданного процесса в системе
Вот уж этот СИ блин Но примерно так

Код (Text):

1.     ULONG sizeSearch = 0xFFFFF000;
2.  
3.     while (sizeSearch)
4.     {
5.  
6.         if (MmIsAddressValid(pAddress))     // суть минимальная единица выделения памяти - страница
7.  
8. /// Тут заносим этот адрес в наш массив валидных адресов
9.         {
10.         } //if (MmIsAddressValid(pAddress))
11.         pAddress += pageSize;
12.         sizeSearch -= 0x1000;
13.     } //while

Поскольку шаг одна страница, то это работает быстро

 

После долгих мучений остановился на варианте с подменой Cr3 - адреса прекрасно процессором транслируются, без всяких мучений
Однако есть одно но...
Перед подменой регистра я хватаю спин-блокировку..а она. как известно, повышает IRQL до уровня DPC.
Это как раз то, что мне надо - никакой пользовательский поток не сможет переключиться на процессор и не сменится CR3.
Однако есть но - я ведь прохожусь потом по всем таблицам страниц...а они в страничной памяти, ну и в итоге БСОД )

Собственно вопрос - достаточно ли будет повысить IRQL только до уровня APC? Или есть другие варианты?

 

оО разве?

 

Да =(

 

lews

KeAttachProcess ( PRKPROCESS pAttachedProcess);
Тебя спасет, ибо делает то же что и ты
Да pAttachedProcess - процесс нужно подбирать тот который подходт к поставленной задаче.