Здрасти,как вам известно для юзермода есть функции для чтения и записи в память процесса(Read\WriteProcessMemory),так возникает вопрос,может ли загруженный драйвер читать и записывать память других драйверов ? очень интересно будет рассмотреть реализацию этого
Ты путаешь процессы и ядро, у каждого процесса своя виртуальная память, память ядра образно одна, драйвер может писать что угодно, куда угодно, главное в бсод систему не уронить.
то есть надо отследить адрес куда загружен драйвер ? --- Сообщение объединено, 9 мар 2021 --- но также нужно учитывать атрибуты памяти
Rel, > память ядра образно одна На самом деле это не так, есть сессии где память ядра не общая. Изменяются таблицы адресной трансляции MiAttachSession() etc. Адрес может одинаковым быть, а значение по нему разное. Так отображается гуй в ядро каждой сессии. Entropy, > отследить адрес куда загружен драйвер ? Есть такая интернал функция MmEnumerateSystemImages(). Подключается к сессии, получает инфу про образ, дальше перечисляет сессии и образы. > может ли загруженный драйвер читать и записывать память других драйверов ? В юзер манипуляции адресами проходят через VAD, в ядре через MDL. Что это такое можешь почитать у Рихтера или есчо где то тут например.
На самом деле это не так, если работает Hyper-V с включенным VBS то будут два ядра ntoskrnl.exe и securekernel.exe securekernel.exe будет в защищенном мире VTL1 доступ к нему блокируется гипервизором на уровне SLAT, но адресное пространство - общее
откуда такая инфа ? сурки wrk или таблица экспорта ? --- Сообщение объединено, 12 мар 2021 --- нет,меня интересует чтение памяти --- Сообщение объединено, 12 мар 2021 --- пачгард это совсем другое,он не контролирует целостность загруженных драйверов
Entropy, > откуда такая инфа ? Так дебаг символы любой диз обрабатывает, идой открыл да посмотрел. Это в несколько кликов мышем конечно, наверно вопрос как это найти - я не первый месяц в кернел там неплохо ориентируюсь. Без аттача к сессиям образу ты не перечислишь. Если большое количество экспортных апи, в юзер например я предпочтительно использовал RtlWalkFrameChain() тк это табличные решения не блокирующие поток, в ядре вариков больше. Там всё упирается как ты сможешь найти символьную апи, тоесть там есть всё но оно не паблик что значит не внесено в экспорт. --- Сообщение объединено, 12 мар 2021 --- > нет,меня интересует чтение памяти Ты не описал проблему с чтением, рано походу тебе в ядро лезть покури архитектуру пару лет(ты можешь тупо что то копипастить сбилдить оно упадёт но отладить ты это не сможешь, затем тупо кинешь потратив очень много времени, так у всех было новичков)
уже не успею,нельзя исключать что архитектура с течением времени будет усложняться,думаю для ознакомления эти пару лет подойдут
если отрубить "защитные" рюшечки, то дравер обретает силу былых времён. к тому же, скорость софта заметно растёт
