связь страниц памяти с ядром и hal.dll в win7

Доброго времени суток, разбираюсь с расположением ядра и Hal в озу. в хрюше они лежали в 1й 4мбной странице, а эта страница лежала по одному и тому же адресу. а что происходит в вин7? мои эксперименты показали что как минимум они расположены по разным адресам (в принципе это и так известно) и хал меняет свое расположение относительно ядра, он расположен, то по меньшим, то по большим адресам. размер ядра 3,71мб, то есть ему нужна своя страница в 4мб. может кто то разбирался с данным вопросом, и может дать информации для размышления? windows seven x32 без сервис паков

 

drem1lin
В Vista и Seven одинаково происходит выбор адресов для ядра и hal.dll. В принципе, у меня в планах было написать статью, в которой эта мелочь была бы упомянута, но раз уж вопрос прямо задан на форуме, а я уже более полугода, как не выделю время для написания статьи... В общем, псевдокод (из winload!OslpLoadAllModules) для выбора адресов выглядит так:

Код (Text):

1. ImageBufferBase = BlImgAllocateImageBuffer(KernelImageSize+HalImageSize+0x21000);
2. Rnd5bit = (RDTSC() >> 4) & 0x1F;
3. if (RDTSC() & 0x10)
4. {
5.   RandomizedKernelImageBase = ImageBufferBase + ((Rnd5bit + (HalImageSize >> 12)) << 12);
6.   RandomizedHalImageBase = RandomizedKernelImageBase - HalImageSize;
7. }
8. else
9. {
10.   RandomizedKernelImageBase = ImageBufferBase + (Rnd5bit << 12);
11.   RandomizedHalImageBase = KernelImageSize + RandomizedKernelImageBase;
12. }

Причём BlImgAllocateImageBuffer возвращает адреса довольно стабильно (на одном и том же железе всегда одинаково). Чаще всего (в моих тестах) на живом железе наблюдаются следующие значения:
Vista: 0x83600000 (0xe3600000 в случае, если increaseuserva установлен, причём независимо от его значения)
Seven: 0x82600000 (0xe2600000 в случае, если increaseuserva установлен, причём независимо от его значения)

Кстати, в Vista у меня ядро грузится в большие страницы, а в Seven в 4KB-страницы. Но почему так и насколько это стабильно, я не разбирался.

 

l_inc
на счет 4мегабайтных страниц у меня была только гипотеза. просто у меня есть физические адреса 2х функций, одна из ядра, другая их хала. и надо найти базовые адреса самих модулей. вот как тогда это сделать? не повлияют на это маленькие страницы? просто раньше я хоть был уверен что они лежат последовательно в памяти.

 

drem1lin
Есть физические адреса, а найти надо базовые физические или виртуальные?

Кто "они"? Модули? Страницы? В какой памяти? Физической? Виртуальной?
На все вопросы: они лежат последовательно в памяти.

 

надо найти базовые физические адреса модулей, зная физический адрес какой либо функции внутри него. то есть можно тупо уменьшать адрес пока на mz не натолкнешься?

 

drem1lin
Можно (4KB интервалами). Если, конечно, у Вас прямой доступ к физической памяти.

 

l_incдоступ у меня прямой, в смысле интервалами по 4 кб? можете поподробнее расписать вашу мысль, пожалуйста.

 

drem1lin
Ну стандартный scandown. Не каждый же байт на PE-сигнатуру проверять? Так как (очевидно, исходя даже из выше приведенного псевдокода) база образа выравнена на 4KB, значит можно scandown делать так:

Код (Text):

1. BYTE *nextAddress = startAddress & ~(0x1000 - 1);
2. while (!IsPeHere(nextAddress)) nextAddress-=0x1000;

 

Спасибо, я смог найти и ядро и хал в памяти, теперь осталась пара технических вопросов.