Здравствуйте! Не могли бы Вы подсказать мне методы отслеживания попыток набора номера модемом с возможностью запрета нежелательных звонков? Для этого я вижу 2 пути: 1 - перехват ZwCreateFile/ZwOpenFile для COM модема; 2 - написание драйвера модема (фильтра команд), выполняющего данные действия. В статьях Ms-rem'a хорошо описан механизм перехвата Native API, но конкретного примера ZwCreateFile/ZwOpenFile там, к сожалению, нет. Также, ограничениями являются следующие моменты: реализация в виде DLL, - не позволит (на сколько я знаю, может быть, я ошибаюсь) перехватывать модемное соединение, инициированное Ring0 драйвером, вызывающим Native функции напрямую из ntdll.dll; если модем имеет интерфейс USB, возникает проблема контроля доступа к данному порту. Если кто обладает такой информацией (гарантированного определения попытки доступа к модему), не сочтите за трудность - напишите, желательно с примерами. Заранее благодарен за помощь и внимание.
Здесь нужна гарантия перехвата ЛЮБОЙ попытки набора номера, а при перехвате RAS невозможно отследить код, использующий CreateFile/WriteFile т.д.
ЛЮБОЙ - никак не получится, можно, например, из ring0 минуя винду общаться с СОМ-ом (по крайней мере, я думаю, что можно)
драйвером, вызывающим Native функции напрямую из ntdll.dll Драйвер не имеет доступа к пользовательскому адресному пространству. Следовательно он не может вызывать какие либо функции из ntdll.dll,которая находится в пользовательском адресном пространстве.Драйвер вызывает функции из ntoskrnl.exe перехватывать модемное соединение, инициированное Ring0 драйверомЭто как? Мне кажется инициатором всегда является пользовательское приложение, а драйвер является механизмом реализации запроса в системе...
DESTROY_ru Говори, говори да не заговаривайса. Вызов из ядра функций ntdll.dll вполне реален см. Небета "Справочник по базовым функциям WinNT\2000"
DelExe Во-первых: вызывать функции ntdll из ядра можно, но не все, а только те, которые являются переходниками к соответствующим функциям ntoskrnl.exe Во-вторых: вызывать их можно только если ты напишешь свой аналог GetProcAddress и получишь адрес функции динамически. При статической линковке система просто откажется грузить твой драйвер. В-третьих: ntoskrnl.exe экспортирует функции с именами аналогичными ntdll (не все), и функции ntdll являются переходниками (через интерфейс системных вызовов) к функциям ntoskrnl. Те функции которые не экспортируются ntoskrnl, можно вызывать получив их адрес из sdt. В-четвертых: если ты все-таки извернешся и вызовешь функцию из ntdll, то необходимо передать ей параметры в юзермодном диапазоне адресов, так как в KiSystemService есть соответствующая проверка. Иначе функция завершиться с ошибкой. DESTROY_ru прав, изучай устройство системы, и тогда и к тебе придет понимание ее рабты. DESTROY_ru ntdll.dll - единственная dll, которая отображена на все адресные пространства (в том числе и процесса system), так что вызывать ее функции из ядра можно, но для этого еще через ж..у извратиться надо.
