Еще одна умозрительная тема, хотя потенциально не исключено и какое-то практическое применение (м.б. ядро ОС-независимого отладчика/руткита?).
Каким образом наш ринг0 код в абстрактном окружении (винда, линукс, фря и пр.) может получить контроль над структурами для управления пейджингом(PML4, PDPTE, PDE, PTE), не полагаясь на функции ОС? Проблема, очевидно, в том, что:
1)На указанные физические фреймы в конкретный момент времени может быть и не смапировано никаких линейных адресов, поэтому обратиться к этой памяти в принципе не получится (при включенном пейджинге)
2)Соответствие линейных адресов физическим известно только ОС.
Видится несколько потенциальных способов, но все они наталкиваются на похожие препятствия. Можно либо вообще на время отключить пейджинг, либо загрузить в CR3 адрес своей корневой таблички с известным маппингом лин.=>физ. В первом случае после mov cr0,xxx, отключающего пейджинг, наш код улетит хз куда. Вернее сказать, мы не знаем заранее какой код находится по физ.адресу=EIP. Во втором случае, сформировав где-то в памяти новую PDE, мы не будем знать ее физ.адрес для загрузки в CR3. В принципе есть способ выяснить физ. адрес, соответствующий конкретному линейному адресу, без обращения к функам ОС, но он крайне извратен. Было бы любопытно услышать соображения на этот счет, возможно я прохожу мимо чего-то весьма очевидного.
P.S. Можно писать в физ.память и напрямую, через DMA, но мне этот способ кажется некошерным, т.к. здесь зависим от чипсета.

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

> Каким образом наш ринг0 код в абстрактном окружении (винда, линукс, фря и пр.) может получить контроль над структурами для управления пейджингом(PML4, PDPTE, PDE, PTE), не полагаясь на функции ОС?

Да никак, так как абсолютно разная архитектура.

> Можно писать в физ.память и напрямую, через DMA

Я пробовал, ISA DMA. А ты пробовал ?

Знаешь что первые 0x10000 это юзермодная память и какой предел у дма - да видимо нет.

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

Dr0p пишет:
Да никак...
Это не так

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

spinz

Аналогичный вопрос - как запилить машкод, выполняющийся на любом камне.

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

Нечего сказать по существу, проходи мимо, почитай лучше маны, может наконец узнаешь про Local APIC, кого-нибудь удивишь потом

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

spinz пишет:
Соответствие линейных адресов физическим известно только ОС
Хук 14-ого прерывания и своя обработка pagefault, не? Можно еще 1-ое похучить, чтобы переключение контекстов ловить. Пока только вопрос как выделить память, чтобы собирать информацию о PML4, PDPTE, PDE, PTE...

Интересно на самом деле, как вы изначально попадаете на ring0. Драйвера в принципе не очень кросс-платформенная вещь. А запилить пару дефайнов для разруливания вопроса управления памяти не представляется сложным.

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

int пишет:
Интересно на самом деле, как вы изначально попадаете на ring0
Это не так важно, да и неинтересно.
int пишет:
Хук 14-ого прерывания и своя обработка pagefault, не?
Не понял, как это поможет. Давайте немного конкретизируем. Пусть мы хотим запилить свое отображение какого-то линейного адрес на физ.адрес. Например, нам нужно отобразить какие-то юзермодные адреса (<0x80000000) на физические страницы, содержащие код/данные ядра. Для этого нам, как минимум, надо знать линейный адрес текущей PDE (если для физ.адреса PDE вообще существует отображаемый на нее линейный адрес), чтобы внести туда свои изменения. Либо нам придется создавать свою PDE, чей линейный адрес нам конечно известен, но неизвестен ее физический адрес - а в CR3, как известно, хранится именно физ.адрес.

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

spinz пишет:
а в CR3, как известно, хранится именно физ.адрес
Вот тут я сфейлил, ага.

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

spinz,
а что делать, если в PDE элемент помечен как отсутствующий в памяти?




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

spinz
Ну тогда Dr0p прав. Вообще говоря нельзя. Можно организовать такой MemoryManager, который работает в странице, у которой физический адрес=линейному. Сделать там сразу на входе всех функций переход в физическое адресное пространство, код продолжит исполнение. В итоге вы заперты тем, что ваш код находится в странице у которой линейный адрес != физическому, то есть выключить страничную адресацию вы не можете, как сами же тут писали. В линейном адресном пространстве в таком MemoryManger'е нафиг не надо иметь какой-то доступ к этим структурам. Можно конечно добраться до памяти самого MemoryManager'а, но он может защищаться само-модифицируюмщемся кодом и рандомизацией выбора страницы, где он будет работать. ИМХО это архитектурно все-так задумано Intel, как элемент защиты.

Есть еще вариант обхода такого MemoryManger'а (да и любого) путем создания bootkit'а, который анализатором кода доберется до взвода страничной адресации при загрузке ОС.

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

int пишет:
...создание bootkit'а, который анализатором кода доберется до взвода страничной адресации при загрузке ОС.

-- , а это будет сверх-зависимая от OC реализация.
Когда-то придумывал примОчку, кторая, стартуя в V86 (как обычный DOS .COM-файл) в Win9x DOS-BOX'e, переползает на 32-bit ring0.
Переползать-то она переползает (и возвращается потом обратно в V86), только делать ей там на ring0 нечего - именно из-за страничной организации памяти. Нет информации.

Dr0p прав.



--ADD-- К следующему посту:
Согласен. Но всё равно это уже не то, что заявлено в шапке темы.
А вот вопрос о том, как код оказывается на ring0 - это ТО.
Пускай бы spinz вкратце описал, как это происходит, а то умозрительная тема висит в воздухе.

--ADD--
И, spinz, --> #9 <--




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

dosprog пишет:
а это будет сверх-зависимая от OC реализация.
Ну почему, надо всего-то найти код, который грузит в CR0 PG=1. Не так много способов это сделать, далее код этот должен иметь прямую трансляцию адресов страниц на физическую. Можно хукнуть, дойти до инструкции и сломать загрузочный код, который больше не нужен. Хук на любое прерывание и мы получаем управление сразу после того, как система прогрузиться дальше. В итоге имеем код, в котором не страшно выключать страничную память.

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

spinz

По существу есть что сказать. Вот только смысла нет. Вы вообще осознаёте что такое разные механизмы и архитектура ?

Ну а вопросы ваши про апики и прочий бред - бред. Накой надо разделять битмапы в селекторах не понятно. Да и контроллеры под нт кодить не нужно, ядро предоставляет весь нужный функционал. Имхо это была ваша попытка показаться умным, только для кого и зачем не понеятно.

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

dosprog пишет:
А вот вопрос о том, как код оказывается на ring0 - это ТО.
Пускай бы spinz вкратце описал, как это происходит, а то умозрительная тема висит в воздухе.
1)Как я уже говорил, это неважно - 0day будет для этой цели использоваться, какие-нибудь бут-биоскиты, легальные механизмы, либо еще хз что - меня это не интересует, моя задача разработать соответствующий функционал без участия ОС.
2)Было бы наивно думать, что знай я некий новый способ попасть из ринг3 в ноль, я бы тут же выложил его в паблик
Dr0p пишет:
Накой надо разделять битмапы в селекторах не понятно
У одного из нас проблемы с воприятием реальности. В каком посте шла речь о битмапах?

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

spinz

Битмапа есть массив бит, даже если их 1. А в селекторе их два или три не помню точно, три вроде(xx rpl & table_mask).

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