Уровень «Бог», это когда продавец запчастей совершенно спокойно и безошибочно работает в каталоге запчастей на японском языке :) с таким покерфейсом. Там кнопок немного больше.
Байда качается обычно с файлопомоек наподобие download.com, но скачал говносборку — сам себе злобный Буратино. Интересно, есть ли хоть одна русскоязычная софтина, взятая с официального сайта, с таким довеском?
Интересно было бы увидеть тест этого антивиря. Все-таки Baidu для Китая то же самое, что Яндекс для нас и Гугл — для Запада, так что вдруг у них получилось что-то получше, чем упоминавшийся вчера Cezurity.
У меня есть небольшой опыт по удалению творений Байду. Я отключал его с помощью утилиты AntiSMS. Она отключает из автозапуска все что имеет подпись Байду, включая драйвера и прочее.
Я убивал этот антивирус следующим образом.
1. Нашёл проводником в Program Files его файлы
2. На всю его папку (но не рекурсивно!) поставил права доступа: «всем» — «ничего». Рекурсивно не получится, потому что антивирус запрещает изменять права доступа своим файлам, бережёт себя. А папку уберечь не может.
3. Перезагрузился.
Система не позволила сама себе прочитать экзешники антивируса для старта его служб.
4. Восстановил права доступа на папку и удалил её к чертям.
5. Запустил CCleaner и почистил реестр — убрать записи о службах, автозагрузке и деинсталляции.
Таким же способом удалось ликвидировать экземпляр Guard.MailRu — какая-то его версия, отличавшаяся повышенной паранойей и одновременно со сломанным деинсталлятором, тоже себя берегла.
Зря ты удалил папку. Надо было установить на неё запрет на запись после очистки содержимого, после этого даже последующие попытки установить сразу же заканчиваются обломом.
То же самое можно проделать с правами доступа к веткам реестра…
Нежелательный софт просто на этапе установки сразу же получает облом.
Многократно. Главное права забирать у всех даже System, а не только у того пользователя под которым работаешь. И не забыть оставить право изменять права для администратора, иначе навсегда папка останется мертвой, её даже не удалить.
Правила «deny» имеют приоритет перед разрешающими правилами.
Я ставил всем Deny Full на каталоги. После перезагрузки права доступа возвращались к чистым наследованным.
Подсказка: замену владельца запретить невозможно, именно через замену владельца при необходимости можно удалить мусор, оставляемый каким-то обновлениями Microsoft (там каталоги с владельцем «Localsystem» и правами Localsystem F)
Странная система безопасности. Вы ей говорите «запретить» а она «ты чего это, я лучше знаю что это надо разрешать».
Даже чтобы сменить владельца нужны права на смену владельца, а эти права точно так же запрещаются для всех…
То что у вас права доступа возвращаются, это ненормально. Надо искать в системе троянца или руткит. Я бы в таком случае заподозрил именно это.
В таком случае, не намного ли проще создать запись в gpedit.msc с блокировкой выполнения по маске имени. Всегда делаю запрет выполнения на *mail* — полет пока нормальный, инсталлятор тоже блокируется.
Не всегда. Могут выйти накладочки и долго будешь думать почему что-то не работает, а окажется что в имя этого чего-то совпадает с маской которая блокируется. Троянцы, к примеру будут маскироваться под популярные приложения, на которые можно будет задать только конкретную маску с точностью до символа, а это путь в никуда вплоть до введения белых списков что есть еще большее неудобство.
Я пробовал и такой метод, в 64-битной Windows 7 запрет доступа не помогает.
Судя по фразе «Нашёл проводником в Program Files его файлы» в 32-битной Windows (XP?) это срабатывает.
В 64-битной. Главное, отбирать права абсолютно у всех. После чего папка становится АБСОЛЮТНО невменяемой, так, что даже с администратором надо попрыгать, чтобы всучить ей права обратно.
В 64-битной Windows Байда записывает себя в «Program Files (x86)»
Поясните про «отбирать права абсолютно у всех» — выполняет ли требуемое команда «cacls /D Все» (эквивалент назначению запрета всем в графической оснастке)? Я так делал, не помогает.
Полагаю, что под словами «надо попрыгать» подразумевается «сменить владельца на пользователя или группу администраторов, затем назначить нужные права». IMHO это тривиально.
Добавлю: я просто запрещал доступ всем, я не менял владельца. Возможно, что смена владельца могла помочь.
1. Я описал общий метод, для любой мыловари — хоть она в (x86), хоть вообще в AppData себя засунет. Когда лечил байду, не особо запоминал, в какую именно ветку програм-файлз она легла.
2. Про команду cacls что-то даже и не догадался. Сходу не могу сказать, насколько корректно и тотально она работает. Хватает ли ей запускаться из-под админа, чтобы перебить всех.
3. В проводнике же это делается наглядно и гарантированно. Контекстное меню — свойства — безопасность — изменить, и всем пользователям и всем группам поустанавливать deny нерекурсивно (каждой группе пришлось отдельно делать). Для пущей гарантии — удалить владельца.
4. Чтобы вернуть права, для начала взял и папке верхнего уровня установил рекурсивно allow «читать папку» и назначил владельца.
Тут мне кажется есть тонкость. Права есть разрешающие и запрещающие. Неправильно было бы удалять права, поскольку объект без назначенных прав наследует права от родительского объекта, а там скорей всего будет «разрешить всем всё». Тут надо установить именно права запрета.
Кстати команда CACLS является устаревшей, взамен ей использовать надо ICACLS она более универсальная.
Внимательно читайте текст.
Повторяю:
1. Драйверы уровня ядра блокируют доступ к файлам и веткам реестра байды.
2. Служба bd0004 не удаляется — выводится сообщение об ошибке “Служба не установлена”, поэтому редактором реестра или программой reg удаляем ветку реестра этой службы. Другими словами: в реестре приходится удалять то, что невозможно удалить системным вызовом (IMHO причина в кривости программы деинсталляции).
Процедура удаления «антивирусного» ПО Baidu