Решил я на досуге парочку АПИ перехватить с целью сокрытия некоторых файлов. Поскольку алгоритм обработчика такого перехвата довольно прост, то оптимальным решением, на мой взгляд, было размещение этого обработчика в межсекционном пространстве той библиотеки, функцию которой перехватываем - kernel32. Поскульку система была W2k \ Wxp, то первым делом я написал K_Mode-драйвер с целью открытия (и закрытия) доступа к определенным страницам Ke32, дабы записать туда тело обработчика и осуществить подмену первых байт исполняемого кода перехватываемой функции (Сплайсинг, кажется). Родной GPF появился когда произошло обращение к перехваченной функции из другого процесса (перехват велся из контекста Explorer.exe путем создания в нем удаленного потока, который и осуществлял все действия по установке перехвата - просто немного извращенства). Причина GPF была в том, что страница памяти с обработчиком перехвата имела другое содержание, и, ни какого обработчика там, естественно, не было. Эту разницу между w9х и wNT я уяснил быстро, НО измененная страница с оригинальным кодом перехватываемой функции проецировалась на все процессы ОДИНАКОВО. Собственно это и было причиной GPF. Эмпирическим путем я выяснил, что кроме страниц Ke32 с кодом, в другие процессы проецируется одна и та же страница - с заголовком библиотеки. Возможно есть еще какие-то страницы Ke32, имеющие одинаковый физический адрес во всех процессах. Но понять я не могу другое: когда я просматривал из нулевого цикла дескрипторы ПОСЛЕДНИХ ДВУХ страниц секции code, imports, exports (все в одной секции)- библиотеки Ke32, то все биты дескрипторов в таблице страниц были нулевыми, даже бит присутствия! НО при этом в страницу было чего-то убористо понаписано. (использование 4 mb страниц исключается, т.к. размер некоторых областей зарезервированной памяти меньше 4 mb, да и по документации Windows расширенные страницы использует только для размещения ядра по адресу 80000000h - 0А0000000h). Вопрос: куда указывают эти страницы (т.е. какой физический адрес информации в них) и как процессор адресуется к этой информации, если дескриптор страницы в таблице страниц полностью нулевой, а бит присутствия опущен. (Использование только каталога страниц исключается, т.к. страницы не расширенные). Использовалась совмещенная таблица страниц по VA = 0c0000000h.
Abnormal Хм, этот метод весьма хорош для 9х систем, поскольку там этот kernel32.dll находится в шаред памяти и один по всем процессам, к тому же в этих системах нет такого поняти как copyonwrite. Что касается NT систем, то для этого там NativeAPI придумали
