MmMapLockedPagesSpecifyCache + CoW

Искомая задача - менять ридонли-память из ядра в чужих процессах. Так, чтобы это не ломало другие процессы и не требовало ансейф-кода (типа поиска функций по сигнатурам).
Минимальная поддерживаемая версия - Win7, в идеале XP.

 

а аналоги искал?

 

Блэкбон меняет через VAD'ы, но это в моём понимании ансейф - нельзя гарантировать, что следующий апдейт не изменит их структуру. VAD'ы в продакшн нельзя.

 

не могу согласиться с твоим виденьем проблемы == Тебе-то акая разница изменится аль нет??? изменится, значит получишь заказ на допилку.. Да, и любой вариант может убиться АПЪ стенку следующего апдейта. ща, мокрых вообще сильно прёт == юзверы ужо нервно сглатывают и хватаются за сердце, когда обновка приходит

 

Ну нет, так дела не делаются...
Я сторонник максимально надёжных способов, иначе я сам бы не захотел пользоваться своим же софтом, когда каждый запуск сродни лотерее.
Имхо, ядерные компоненты (впрочем, юзермодные тоже) должны быть максимально надёжными, даже если делают ненадёжные вещи.

 

HoShiMin, приведу простой пример.. вот пишешь ты цикл и в нём прописываешь обработчики всяческих ошибок (ведь, ты борешься за надёжность ). Но имеется МАЛЮСЕНЬКАЯ ТАКАЯ ЗАПАРОЧКА == каждый хэндлер увеличивает тормознутость твоего цикла + на тех же лэптопах твой надёжный цикл сжирает батарею. И в итоге твоё надёжное решение становиться фактически неприемлемым. короче, хороший код есмь разумный компромисс. а перфекционизм до перфекта почему-то не доводит

 

Но речь же не о параноидальных проверках каждого чиха, а о таких функциях:

Код (C):

1.  
2. ULONG GetUndocFieldOffset() {
3.     switch (WindowsVersion) {
4.         case XP: return 0x123;
5.         case Seven: return 0x345;
6.         case SevenSP1: retutn 0x567;
7.         case Blue: return 0x12345;
8.         case BlueOne: return 0; // Unapplicable
9.         case X_1503: return 0; // Unapplicable too
10.         case X_1607: return 0x45678;
11.     }
12. }
13.  
14. PVOID FieldAddr = StructBase + GetUndocFieldOffset();
15.  

Согласись, что такой код за рамками добра и зла, и уже не имеет ничего общего с рассуждениями об излишних или недостаточных проверках (да и вообще проверках).
Это просто нецензурный булщит!
А именно такой код и используется в блэкбоне для поиска VAD'ов (и не только их).

Но! Подобный подход имеет место, если ты используешь его совместно с парсером символов, который в рантайме качает символы для текущего ядра и ты гарантированно получишь валидные оффсеты.
Но это сразу накладывает ограничения на необходимость инета и зависимость от нескольких дополнительных дллок.

 

ну, вот и Молодец == весьма годное решение

так это дажЬ хорошо + ядро-то не каждый день обновляют

фиии, да-хоть 10

 

Всё ещё не решение(
Не верю, что нет способов заставить сработать CoW...

 

сделай промежуточный РАБОЧИЙ вариант, а там ужо в тиши и спокойствие будешь лабать нечто более фундаментальное. Но у меня така пИИИдозра, что нечто особо фундаментальное получить вряд ли возможно == нужно использовать либо некие скрытые функи ядра, либо патчить маздая. Очевидно, что оба варианта костыльные и с апдейтом не дружат стало быть.

 

Есть один вариант.
В PTE три бита AVL, один из которых отвечает за Copy-On-Write. Взводим этот бит, взводим бит Writeable, делая страницу записываемой, делаем нечто подобное: *(PBYTE)Page = *(PBYTE)Page; - срабатывает CoW, его ловит винда и подгружает страничку в целевой процесс.
Сейчас делаю поддержку всех возможных трансляций для х86, х86+PAE и x64.

 

то есть опять же имеется прямая зависимость от ядра.

 

Нет здесь зависимостей, ведь PTE - это структура из процессорной технологии страничной памяти, а не виндовая структурка. PTE не может измениться, и будет работать и на винде, и на линуксе, и вообще на всём, что работает на х86/x64 - причём, гарантированно для всех процессоров, прошлых, существующих и будущих. И все возможные режимы трансляции придумывает не винда, а все они - строго документированная часть процессорной архитектуры.

 

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

 

Нет, это слишком фундаментальные вещи, и MS'ы здесь ничего не решают - не от них зависит, что и как лежит в PTE, порядок полей строго определён, и никакие мельтдауны\спектры не заставят эти структуры поменяться

 

в любом случае ты получил рабочий результат на данный момент, а дальше видно будет

 

Вот и стало видно - закончил, проверил, оно работает, прикрепил решение в шапку

 

Молодец.
HoShiMin, ты коды из этой темы продаёшь иль их на гите глянуть можно?

 

Они и так на гите, всё в опенсурсе, в первом сообщении смотри)

 

HoShiMin, Отлично ещё такой вопрос == акь ты видишь решение гонки за пте: ядро вс дравер иль дравер вс дравер? особенно любопытно про ядро.