Домохозяйка нет, а вот некоторые программы при инсталяции используют. В результате получаем кривую инсталяцию, которую потом замучаешся вычищть ручками(потому что она упала в середине и деинсталятор не создался).Сообщение от rav
Домохозяйка нет, а вот некоторые программы при инсталяции используют. В результате получаем кривую инсталяцию, которую потом замучаешся вычищть ручками(потому что она упала в середине и деинсталятор не создался).
Надоело быть жертвой? Стань профи по информационной безопасности, получай самую свежую информацию об угрозах и средствах защиты от ведущего российского аналитического центра Anti-Malware.ru:
Ох, и мечтатель же ты! А лапшу с ушей уже можно снимать?
Ну, а если серьёзно, то, слава богу, дискуссия хотя бы немного позволила вырулить в нужном направлении - по крайней мере, даже такое решение - это намного лучше того, что мы имеем сейчас!
Последний раз редактировалось aintrust; 03.03.2006 в 08:32.
Не много не в тему но:
6. Поиск открытых портов TCP/UDP, используемых вредоносными программами
В базе 319 описаний портов
На данном ПК открыто 1 TCP портов и 2 UDP портов
Проверка завершена, подозрительные порты не обнаружены
теперь это сообщение просто радует глаза ни каких сообщений об ошибке ни при каких условиях!!!!!!
Да нет, ошибка эта осталась (о чём я уже тут умоминал).
Код:Протокол антивирусной утилиты AVZ версии 4.15 Сканирование запущено в 04.03.2006 2:05:44 Загружена база: 20554 сигнатуры, 2 нейропрофиля, 55 микропрограмм лечения, база от 22.02.2006 10:42 ...SKIP... 6. Поиск открытых портов TCP/UDP, используемых вредоносными программами В базе 319 описаний портов В ходе проверки возникла ошибка. Проверка не производилась
2 замечания и вопрос:
1. Проверка только указанной папки так и не реализована.Avz рвется проверять все в направлении корня.
2. Неверный вывод при проверке зараженных архивов:3. Олег, ты смотришь внимательно файлы, которые проверяются в онлайн с этого сайта? (Проверка файлов антивирусами AVZ и VBA в режиме on-line)Код:C:\tmp1\socks5.rar - чист, в базе безопасных НЕ значится C:\tmp1\socks5.rar/{RAR}/socks5.#xe >>>>> Trojan-Proxy.Win32.Small.cf
смотрит, когда они к нему попадают. а попадают они кучками. что там не так с этими файлами?
Вопрос вообще-то к Олегу, интересует степень внимания к файлам, полученным из онлайн-проверки по сравнению с присланным ему на e-mail.
Последний раз редактировалось userr; 05.03.2006 в 19:55.
а ответ все равно будет от меня, ибо за онлайн-проверку я отвечаю.Вопрос вообще-то к Олегу
если хотите быстрого внесения в базу - пишите напрямую Олегу. если просто хочется убедиться в чистоте и текущем присутствии/отсутствии в базе - то через сайт. а степень внимания ко всем одинаковая.
Последний раз редактировалось MOCT; 05.03.2006 в 20:09.
Я вдруг подумал, что зря написал здесь мейл Олега в чистом виде.
я думаю, что его тут уже столько раз написали, что плюс-минус один раз уже не повредит ;-)
поиск по сайту показывает 157 тем с указанием этого адреса
Ничего страшного - мой email пробит в хелпе и еще тысяче мест ... Насчет добавления проверяемых в on-line файлов - MOCT периодически скидывает мне подозреваемые/недетектироемые для анализа и включения в базы. Хотя быстрый путь включения файла в базу - это его отправка на [email protected]
Программа IMsecure ( ZONE LABS, INC.)
Анализатор - изучается файл D:\Program Files\IMsecure\IMsecure.exe
[ES]:Может работать с сетью
[ES]:Приложение не имеет видимых окон
[ES]:Записан в автозапуск !!
[ES]:Загружает DLL RASAPI - возможно, может работать с дозвонкой ?
D:\Program Files\IMsecure\IMsecure.exe
D:\Program Files\IMsecure\imfrmwk.dll
D:\Program Files\IMsecure\IMUTIL.dll
D:\Program Files\IMsecure\IMINIT.dll
D:\Program Files\IMsecure\IMPUBAPI.dll
C:\WINDOWS\System32\lockbox.dll
D:\Program Files\IMsecure\policymgr.dll
C:\WINDOWS\System32\imslsp.dll
D:\Program Files\IMsecure\imdata.dll
D:\Program Files\IMsecure\immonapi.dll
Некоторые загружаются в Outpost Firewall это
C:\WINDOWS\System32\imslsp.dll
C:\WINDOWS\System32\lockbox.dll
И ещё в оба svchost.exe
C:\WINDOWS\System32\imslsp.dll
C:\WINDOWS\System32\LIBEAY32_0.9.6l.dll
C:\WINDOWS\System32\lockbox.dll
Поставщики транспортных протоколов (TSP, LSP) Поставщик Исп. файл Описание (ДОБАВИЛИСЬ)
imslsp/1140897371 over [MSAFD Tcpip [TCP/IP]] C:\WINDOWS\System32\imslsp.dll Copyright © 1998-2004, Zone Labs, Inc.(1, 5, 0, 39)
imslsp/1140897371 over [MSAFD Tcpip [UDP/IP]] C:\WINDOWS\System32\imslsp.dll Copyright © 1998-2004, Zone Labs, Inc.(1, 5, 0, 39)
imslsp/1140897371 over [MSAFD Tcpip [RAW/IP]] C:\WINDOWS\System32\imslsp.dll Copyright © 1998-2004, Zone Labs, Inc.(1, 5, 0, 39)
imslsp/1140897371 C:\WINDOWS\System32\imslsp.dll Copyright © 1998-2004, Zone Labs, Inc.(1, 5, 0, 39)
Для справки:
Программа повышает безопасность использования ICQ MSN и др. аналогичных программ для обмена сообщениями.
Защищяет от спамеров похищения паролей и утечки личной информации.
Может чтото надо изучить? (Файлы вроде неизвесные для AVZ)
AVZ после тестирования нашла такой файл :
E:\Documents and Settings\ALEXANDER\Datos de programa\Sun\Java\Deployment\cache\javapi\v1.0\jar \jts.jar-510faa1-3d0211bc.zip Invalid file - not a PKZip file
Этот файл вижу в папке (скрин прилагаю).Найти его и упаковать через поиск файла в AVZ не могу. Задаю имя в поиске,без результата.
Удалил бы его сразу,только может послужит как добавление в базу "гадостей".
Подскажите что можно сделать для упаковки и отправки.
Последний раз редактировалось kozakoff; 21.03.2006 в 00:35.
присылать не нужно - гадостью не является
Спасибо.Код HTML:гадостью не является
После включения AVZGuard и перезагрузки компьютера система находит новое оборудование. Так как драйвера нет, оно не устанавливается, а в свойствах вижу:ROOT\LEGACY_AVZ\000 .Подскажите, пожалуйста, что всё это значит?
Это и есть AVZ Guard. А вот почему система не находит драйвера - это большой вопрос. Должен быть.
Я несколько раз получал отчеты о таком баге, причны его проявления неизвестны и симулировать его мне пока не удалось. Решение простое - прибить это "устройство", чтобы не появлялось сообщение о обнаруженном оборудовании.
Прибивать приходиться после каждого запуска AVZGuard, но после добавления файла avz_thebat проблема, вроде, исчезла.
Как известно, наличие собственного "белого" списка программ/модулей выгодно отличает AVZ от многих анти-троянских программ и является, наряду с возможностью получения файлов 'Исследования системы', несомненным достоинством AVZ, отмечаемым многими пользователями программы. Однако, при более пристальном рассмотрении оказалось, что при определенных обстоятельствах эти достоинства могут легко превратиться в серьезные недостатки. Итак, ближе к делу...
Несколько дней назад, при обсуждении в соседнем разделе программ, динамически устанавливающих свои драйверы путем создания временного файла-драйвера, активации драйвера и последущего удаления файла-драйвера (так, как известно, поступают многие программы, в частности - утилиты от Sysinternals, F-Secure BlackLight, некоторые анти-троянские программы и т.д.), МОСТ выдвинул предложение о том, что было бы неплохо такие временные файлы помещать в базы "чистых" файлов AVZ с тем, чтобы они при анализе (в частности, в 'Исследовании системы') не попадали в "черные" списки:
Не будем сейчас останавливаться на том, как это лучше сделать - путем ли "выдирания" этих файлов из ресурсов, посредством программ восстановления файлов на диске или еще как-то с последующим добавлением в базу "чистых" - это не важно, т.к. "проблему" попадания таких файлов в "черные" списки, как оказалось, это вообще не решает! Связано это с тем, что AVZ, чтобы принять решение о том, поместить ли файл, соответствующий некоторому процессу/модулю, в "белый" список или нет, должен "увидеть" этот файл на диске, т.е. соответствующий процессу/модулю проверяемый файл банально должен существовать - иначе, казалось бы, как сравнить сигнатуру и ее объект? Отсюда простой вывод #1: "соответствующий" процессу/модулю, но не существующий на диске файл AVZ 100%-но помещает в "черный" список. Для проверки этого обстоятельства я провел простой эксперимент. AVZ, как известно, помещает свой основной драйвер, avz.sys, в "белый" список (см. скриншот #1). Я загрузил AVZ, потом "на лету" переименовал этот файл, avz.sys, в _avz.sys (т.е. файл для AVZ как бы исчез!) - и AVZ сразу же поместил его в "черный" список (см. скриншот #2). Тогда я пошел дальше: вместо оригинального avz.sys, который так и остался пока что переименованным, я сделал копию avz.exe и переименовал ее в avz.sys - AVZ, само собой, подлога не заметил и сразу же стал считать avz.sys "чистым" (см. скриншот #3 - обратите внимание на длину файла avz.sys в папке AVZ).однозначно.
а по поводу безопасности - пусть даже и безопасная, так все равно не помешает в базу чистых добавить, чтобы больше такие записи нас не смущали
Ладно, подумал я, а что будет, если начать "подменять" ("сплайсить") файлы на диске (т.е. после запуска "грязного" файла-оригинала его тут же переименовать (не важно, в какое имя!), а в каталог, где он лежит, переписать заведомо "чистый", например, системный, файл, дав ему старое имя "грязного" файла-оригинала)? И - о чудо!
Отсюда простой вывод #3: существующую в AVZ методику определения "чистых" файлов нужно менять, и чем скорее - тем лучше, т.к. в указанных выше обстоятельствах она не только не помогает, а даже наоборот - вводит в полное заблуждение! Как известно, во время формирования базы "чистых" объектов имя объекта не учитывается, а при анализе же на "чистоту" AVZ ищет объект в файловой системе только по имени (плюс полный путь) - никакие другие "признаки"/атрибуты в расчет не берутся! Даже в этом налицо некоторое противоречие!
Что же нужно сделать? Казалось бы, простую вещь: при проверке процесса на "чистоту" проверять не файл на диске, ему "соответствующий", а его образ в памяти, учитывая при этом только те атрибуты, которые остаются неизменными при загрузке файла в память (ведь изначально база "чистых" формируется из файлов, а не из их образов в памяти!). Это, кстати, решило бы проблему и временных файлов-драйверов, а также прочих похожих объектов - ведь в памяти компьютера все эти объекты практически постоянно присутствуют! Казалось бы простую вещь...
Такие вот дела...
[edit]
PS. Я сделал необходимые правки в описании (особенно это касается вывода #2), т.к. из моего описания не совсем было понятно, что во время всех манипуляций с файлами "грязный" процесс уже должен быть запущен. Насколько я понимаю, именно из-за этой моей "невнятности" сразу же последовал вопрос от HATTIFNATTOR-а.
Последний раз редактировалось aintrust; 12.03.2006 в 22:48.
Ваши права в разделе
