Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
1. Ну начну с того, что статья неактуальна. Заниматься... 15.01.07 19:03 Число просмотров: 2384
Автор: amirul <Serge> Статус: The Elderman
Отредактировано 16.01.07 05:10 Количество правок: 1
|
1. Ну начну с того, что статья неактуальна. Заниматься поиском hook-овых кейлоггеров это сейчас примерно то же, что заниматься поиском ms-dos вирусов. Встречаются, конечно, но рынок сейчас забит "настоящими" (драйверными) кейлоггерами и там перехват системных сервисов вообще не поможет (большинство из них вообще общаются с user-mode только при просмотре лога).
2. Второе, что резануло глаз: "Привожу вам ее описание прямо из исходников (private\ntos\inc\ke.h)" (ну и второй пункт списка источников). А товарищ вообще знает, что это как бы незаконно (независимо от его личного отношения к этому закону)? Приведенная фраза примерно соответствует выкладыванию в публичный доступ на ресурсе с высокой посещаемостью видео со своим преступлением и при этом сообщив свои личные данные (насколько я помню подобные идиоты встречаются).
3. Технические огрехи: нежелание хардкодить номер сервиса, но при этом захардкоженное смещение на "теневую" таблицу дескрипторов. Зачем то для патча сессионной памяти используются APC (хотя достаточно просто приаттачиться к адресному пространству того же winlogon-а KeAttachProcess), да и вообще вся эта возня с хуками, когда можно просто генерировать нажатия при помощи keybd_event (SendInput).
4. Предложенная схема обнаружения кейлоггеров работать не будет. Мало того, что будет просто невероятное количество false positives (работаем в Word-е - произошло автосохранение; работаем в Instant Messenger-е - произошла запись в лог - они ведь ведут логи разговоров; да мало ли еще примеров), но все эти жертвы будут напрасными, ибо схема страдает от false negatives: достаточно сжать лог (а большинство кейлоггеров еще и шифруют) и/или писать в него не только клавиши (а например еще и скриншоты) и содержимое не будет ни пропорционально по размеру ни похожим по содержимому.
5. Patch guard. Ну это смешно. Честно говоря, исходя из технического уровня основной статьи фразы типа "зайусь Patch Guard-ом на досуге" вызывают умиление. Ничего не выйдет. Почитать как там все устроено можно например в статье более чем годичной давности http://www.uninformed.org/?v=3&a=3
Вряд ли у автора хватило бы квалификации провести подобный анализ (сомневаюсь, что квалификации хватило бы у меня, хотя смею предположить, что у меня ее поболе будет).
В общем статья - пустое сотрясание воздуха по неактуальной проблеме. И сколько ставить такой статье?
А вот статья про пароли мне понравилось и как раз тем, что она: 1) Актуальна 2) Я считаю себя достаточно искушенным в вопросах безопасности (и в частности в вопросах выбора и управления паролями), но я таки нашел одну новую для себя утилиту - apg. Просто генераторов паролей я знал с десяток, возможно потому и прекратил поиск, но вот эта утилита реально удобна. Если бы еще где нибудь найти анализ того, насколько "произносимость" пароля влияет на его стойкость. Естественно пространство ключей сокращается, вопрос в том, достаточно ли большим оно остается (хотя если верить сопровождающей документации, то на авторитет NIST-а вполне можно положиться).
|
|
|
подробно о проекте
Анализ криптографических сетевых...
