Пардон, если боян.
KillSwitch и СIS последних модификаций, Win7 sp1 x86.
Убить процесс cfp.exe не получается, а вот при нажатии “delete” идет запрос на перезагрузку - и после нее Comodo больше нет, файла в папке тоже:
http://s017.radikal.ru/i416/1201/bd/d14b5dc62a76t.jpg
http://s018.radikal.ru/i508/1201/13/1e76d80587cet.jpg
ivaemon, вот ответ с небезызвестного нам с вами форума:
[QUOTE=ntoskrnl;]Здравствуйте. Изложу свои соображения. Никого не хочу обидеть, но, друзья, вы занимаетесь самой настоящей ерундистикой. Проверять самозащиту продуктов средствами, убивающими их с помощью драйвера, занятие абсолютно бесполезное и показывающее не столько дизайн и возможности защитного ПО, сколько дизайн и возможности драйвера, в данном случае PH и/или KS. Могу посоветовать использовать для этих целей IceSword, думаю, результаты всех сильно удивят. 
Сама проверка самозащиты АВ с помощью драйвера не имеет смысла, поскольку загрузка в нулевое кольцо недоверенного кода автоматически означает полный взлом системы и самая “высокая” точка, где имеет смысл проверять самозащиту - это граница третьего кольца, т.е. непосредственный вызов операционной системы через инструкцию syscall на Win64 или через sysenter ли прерывание 2Eh - на Win32. “Ниже” мы имеем все шансы “спалиться” на хуках в ntdll.dll, “выше” недоверенный код проникать не должен в принципе.
[/quote]
а так же:
[QUOTE=alexo2003;]Я, наконец, для себя вопрос с прохождением или нет тестов в PH прояснил блягодаря ответам wj32 :old: в английской части комодовского форума.
Если кратко, то получается так: от загрузившегося на уровень ядра драйвера спасения нет ни у кого и быть не может. У всех, у кого тест проходит, в окошке терминатора видны строчки “Not available” – это значит, что драйвер PH не был загружен, и теста не было.
Защитное ПО должно выдавать предупреждение о попытках загрузки драйвера. Если пользователь разрешил – всё, драйвер обязательно всех выгрузит. PH специально создавался так, чтобы обходить Comodo (он у него даже в доверенных, вроде), поэтому KProcessHacker может с Comodo делать всё. Но в мирных тестовых целях.
Ещё момент. То, что у некоторых продуктов самовосстанавливается защита – ничего не значит, выгрузка состоялась. Это PH такой добрый, а малварь может контролировать и блокировать повторную загрузку.
Вот тут https://forums.comodo.com/news-announcements-feedback-cis/mayday-mayday-this-is-not-a-joke-cis-processes-shutdown-t43832.165.html
есть ответы wj32.
Короче говоря, делать выводы о наличии/отсутствии защиты в каком либо ПО на основе PH – изначально неправильная затея. От загрузившегося драйвера не спрятаться. Можно только делать вывод о том, удалось ли загрузить KernelMode driver или нет.
[/quote]
Защитное ПО должно выдавать предупреждение о попытках загрузки драйвера.
Надо сказать, что CIS при запуске орал на KS дважды, ну и я ему дважды объяснил, что не надо волноваться. ;D
Не, ну мне интересно: везде пишут, что Комодо лекго проходит KS… ???
NIS или CIS?
Галочка стояла Блокировать все неизвестные запросы если приложение закрыто?
CIS, конечно. Исправил.
Галочки не было. Проверял KS после того, как PH не смог его убить без галки.
Проверил с галочкой: то же самое.
Я вообщем-то так и думал, поскольку
[b]от загрузившегося на уровень ядра драйвера спасения нет ни у кого и быть не может[/b]
Я думал, он сможет восстановиться. Там же есть резервная папка repair, вдруг какие-то механизмы предусмотрены. Но нет…
Проверил NIS - все один в один.
Это было бы неплохо.
В принципе, это не совсем катастрофа, поскольку решается настройкой продукта. Конечно, не совсем приятно для умолчальных настроек, но легко решаемо. У меня всё руки не доходят написать инструкцию (своё видение) по настройке [само]защиты CIS, чтобы было “как у всех”, а то уж очень часто этот вопрос поднимается. Может быть на этой неделе сделаю.
Чрезвычайно заинтересовало. Неужели в этой ситуации можно защитить продукт? Будем ждать ваших рекомендаций.
Микровопрос можно? Драйвер KProcessHacker предназначен в том числе и для поиска и выгрузки скрытых процессов (руткитов). Как он мог бы с ними разбираться не работая на уровне высших системных привилегий? Я лично считаю, что в данном споре спорщики заняли ошибочную позицию заключающуюся в том, что участники спора предполагают, что выгрузка работающих с высшими системными привилегиями процессов должна происходить по команде переданной через API. Похожая модель защиты ещё в конце 70-х - начале 80-х была использована в ОС IBM OS/370 VM и обходилась элементарно - выдавалась команда SVC 107 с определёнными бинарными параметрами, за ней LPSW с нужным словом состояния машины и выдавшая её задача получала режим супервизора и нулевой ключ защиты памяти и всё - доступны все привилегированные команды и вся оперативная память комплекса. Сам так делал для загрузки диагностических тестов оборудования.
Это было допустимо в той ситуации поскольку иного выхода у нас не было, и наше начальство об этом знало, но делало вид что ничего не видит - запрет на остановку комплексов на профилактику исходил лично от Брежнева. Тут не поспоришь, но в нормальных условиях эти действия могу привести к непредсказуемым последствиям и потому не допустимы.
Именно чтобы избежать отрицательных последствий и используются тщательно протестированные драйвера режима ядра. А вот то, что ошибка в программе приводит к потере данных абсолютно не допустимо и об этом нужно немедленно нужно немедленно извещать разработчика добиваясь от него её устранения.
