Для возможности записи в АП юзермодного приложения из калбэка PsSetLoadImageNotifyRoutine без шаманских плясок с ZwProtectVirtualMemory в отдельном треде, использовал сброс WP бита в cr0. Насколько корректен такой шаг и какие могут быть косяки?
Абсолютно некорректен по одной простой причине. Маппинг всех юзермодных образов производится через секции, - это ты знаешь. У секций есть поддерживающий файл на диске. Когда образ, допустим, спроецирован только на чтение, Windows не заморачивается выделением отдельных личных страниц этому процессу. Он прямо указывает на буффера менеджера кеша. Все равно же только читать собирались. И тут ты прилетаешь, сбрасываешь WP бит и через юзермодные адреса, фактически, начинаешь напрямую писать в менеджер кеша! Что же происходит? А происходит такое - менеджер кеша отмечает, что страницы были модифицированы, и потом просто скидывает твои изменения НА ДИСК. Подобный вопрос неоднократно поднимался - почему при сбрасывании WP для записи в образы изменения отражаюся на диске. Представь так же ситуацию, когда длл используется несколькими процессами. Еще хуже, если это системная длл типа ntdll.dll или kernel32.dll. Ты возьмешь, и запишешь в общую кодовую для всех процессов страницу. Результат - изменения отразятся на всех процессах. ZwProtectVirtualMemory как раз-таки и нужна для того, что если она обнаруживает, что новые атрибуты страницы на запись, то она выделяет на этом месте частную копию страниц. И туда уже можно писать безо всяких побочных действий. А сбрасыванием WP-бита, увы, нет
