shinigami1 Зачем вам сайс? Юзайте WinDBG. Винду в режим отладки переводите и по COM-порту отлаживайте.
Я буду долго бить ногами за аппаратное отключение CR0.WP и уж тем более за запрет прерываний. Это совершенно некорректно, и мало того, что может вызвать бсод (см. пост клерка #2), так еще и попросту может перетереть кэш файловой системы, если будете таким макаром писать в спроецированные виды секций файлов. Ну что за пипец, когда один дурак написал неправильный код, а другие подхватили это, читая его статьи Повторяю в тыщапицотый раз, СБРАСЫВАТЬ CR0.WP НЕКОРРЕКТНО!
Clerk Грит верно пишет. Это все когда-то, с горем пополам, работало в одноядерных процах, на виндовых системах. Сейчас этот код уже не торт.
TermoSINteZ Грейт предлагает промапить нужную страницу есчо раз и в неё писать, либо разрешить запись в целевую страницу. Проблема в подкачке страниц, в остальном не имеет значения в какую из отображённых страниц производится запись(без учёта защиты страниц). Если обратится к целевой странице, после чего сразу замаскировать прерывания на текущем камне, то эта манипуляция полностью безопасна. Темболее что кодосекции ядра не выгружаемые.
Clerk Вот вы замаскировали на текущем камне, прерывания, а если там два? Будете второе маскировать? Или будете приоритеты выкручивать и привязывать потоки к процессорам\ядрам? А теперь посмотрите код, который привели тут. Который уже, наверно, каждый второй юзает, и тестирует на однопроцессорной варе, и радуется жизнью. Пока не огребет проблем с реальными системами которые нынче распространяются все сильнее и масштабнее. Грустно.
Вообще я имел в виду ситуации, когда запись производится в ЮЗЕРМОДНЫЕ виды секций файлов. Ведь находятся уникумы, которые и там юзают тот же код (вместо ZwProtectVirtualMemory). Да и даже для ядерных страниц рекомендуется использовать перемапирование через MDL. Во избежание потом "бсодов из ниоткуда" и прочих вещей.
Обработчик исключений __try/__except, кстати, лишний. Все равно при записи в АП ядра исключения у тебя не будет. Либо все будет ок, либо бсод ATTEMPTED_WRITE_TO_READONLY_MEMORY, либо бсод PAGE_FAULT_IN_NONPAGED_AREA.
Great Вот как видно некоторые неправильно понимают. TermoSINteZ авер, и как всякий авер: 1. Уровень знаний не достаточный(иначе не былбы авером по определению). 2. Соответственно решения тривиальны и за канчиваются на мсдн. Ресерч, полуприватные сурцы и пр. - они далеки от этого. 3. Личное мировозрение возведено в идеал, всё то, с чем они не согласны не тру и не должно применяться. TermoSINteZ Возникла бредовая мысль - ведь экспорт достаточно легко контролировать, а непосредственно железячные вещи проблемно - ведь в ваш прот будут писать, безо всякого внешнего функционала, негодуйте :P
Clerk Ну если вы так хотите, я вам скажу 1) Достаточный уровень для кого ? Я не всеведущ, я лишь искушен (С) Мефистофель. 2) Хех, скажете код со бросом CR0.WP это решение из MSDN. Нет? Тогда вы сами себе противоречите. 3) С чего вы взяли? Мне кажется это вы кипятком ссыте, как увидите живого авера. Будьте проще. Иначе сами попадете в свою же глупость. Мой прот? Вы о чем? Да и, если хотите обсудить мою личнось, создавайте тему на WASM.SITE возьмем мнения, обжалуем, обсудим, не проблема. Но в этом топике флейма больше не будет (а я как вижу, вы любитель пофлеймить). Я предупредил. Кстати я к вам, как и ко всем другим пользователям форуме, отношусь нейтрально. Даже как-то подсказки давал, помнится. Если будет что-то еще по теме "Сплайсинг ZwTerminateProcess" - прошу.
TermoSINteZ По мойму флудите тут вы, не поймите неправильно, изначально я утверждал что связка ACCESS_PAGE/CLEAR_IF/CLEAR_WP/ATOMIC_WRITE_PAGE абсолютно корректна и стабильна для ядра, хоть милиард раз вызывайте сбоя не будет. Вы же начали утверждать непонятно что.
Clerk Связка стабильна в данном случае, но есть случаи когда она ни разу не стабильна. И я как раз говорил, про общую ситуацию. Если вы не знаете таких случаев, это еще ни о чем не говорит. Такие ситуации бывают когда идет сброс IF флага (не обязательно для того, чтоб потом сбросить WP, возможно для целей, чтобы никто не прервал). Так вот я видел уже подобные коды. И они как правило в более чем 50 процентов случаев, бсодили на момент переключения потоков, когда второе ядро начинало исполнять код. Да, ситуация там была не только в этом, там был испорчен\затерт TRAP фрейм, но суть не в этом, а в том, что cli не дает гарантии. Меньше тестируйте гуан код на одноядерных машинах. Да и не путайте флейм с флудом.
TermoSINteZ IF сбрасывается именно для того, чтобы никто не прервал при отключенной защите страниц. Пока не будет вызван планировщик(HalEndSystemInterrupt()) поток не будет прерван и процессор отдан иному потоку. Это никогда не произойдёт, так как все прерывания замаскированы(IF = 0). Любой мой код исполняется на двуядерной машине.
