Universal Virus Sniffer (uVS), Вопросы разработчику

[goover 37]

И почему-то этот NTSD.EXE имеет статус ПРОВЕРЕННЫЙ одновременно с ПОДОЗРИТЕЛЬНЫЙ.

Соответственно файл исчезает из списка "Подозрительные и вирусы" при установленной галке "Скрыть проверенные".

[goover 37]

Разобрался. Смутил статус: Цифровая подпись - "Отсутствует, что необычно для известного файла этого типа [ВОЗМОЖНО поврежден/заражен]". У него, видимо, изначально нет цифровой подписи.

[santy 153]

Да, для снятия блокировки запуска этого хватит.

ок, delref нормально все зачистил

В образе все в обломках... видать антивирусом прошлись

похоже,

предварительно смотрел по логу AVZ, разбор в логе, если кому то будет интересно

http://exfile.ru/201551

И глюк uVS есть, неправильно путь разобрал для twext.exe

а что означает эта запись \s в ключе? ошибка вирусописателя, или умышленное добавление чтобы затруднить разбор параметра антивирусным утилитам?

Ссылки на объект

Ссылка HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit

Userinit c:\windows\system32\userinit.exe,\s,C:\WINDOWS\system32\twext.exe

[demkd 638]

И почему-то этот NTSD.EXE имеет статус ПРОВЕРЕННЫЙ одновременно с ПОДОЗРИТЕЛЬНЫЙ.

Потому что в данном случае он блокирует запуск в свойствах: Отладчик приложения [может быть исп. для блокировки запуска]

Соответственно файл исчезает из списка "Подозрительные и вирусы" при установленной галке "Скрыть проверенные".

Надо бы поправить, файл действительно может быть проверенным, однако и проверенный файл можно использовать со злым умыслом как в данном случае.

а что означает эта запись \s в ключе?

Что угодно, в любом случае надо это дело исправить Функция разбора путей мне почему-то дается с трудом, никак не могу выгрести все глюки.

[Sergey Dindikov 10]

UVS 3.69

OS: Win7 [uAC=OFF], xpsp3

учётка - админ

установлен Winrar 4.01

uvs запускается отсюда:

"C:\UTILITY\AV\UNIVERSAL VIRUS SNIFFER\start.exe"

если пытаться отрыть образ C:\dindikov_2011-08-15_09-15-53.rar

он ошибочно распаковывается в каталог UVS "C:\UTILITY\AV\UNIVERSAL VIRUS SNIFFER\dindikov_2011-08-15_09-15-53.txt" а не на диск C

uvs сообщает после этого:

---------------------------

Ошибка

---------------------------

C:\DINDIKOV_2011-08-15_09-15-53.TXT

Не удается найти указанный файл.

---------------------------

ОК

---------------------------

100% воспроизводимость.

!!!!!!!!!!!!!!!!!!проблема только с корнем диска C!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

если использовать в системе 7Zip 9.23 то такой проблемы тоже нет.

пока не разобрался проблема Winrar или Uvs

[demkd 638]

установлен Winrar 4.01

проверю, с 4-й версией не тестировал.

[g0dl1ke 26]

кстати да, стоит 7зип и винрар 4 - зазипованные слепки системы не открывает, только если сам распакую.

[demkd 638]

g0dl1ke

Имя архива должно полностью совпадать с именем файла внутри, а если скажем часть "-" в имени архива зачем-то заменена на "_" то будет ошибка.

[demkd 638]

установлен Winrar 4.01

проверил, это глюк uVS, передавался путь для распаковки "C:" что означает в тек. каталог на диске C, а не в корень C, в след. версии будет исправлено, а пока можно установить 9-й 7-zip даже без ассоциаций файлов, мешать он не будет и все будет работать, поскольку uVS отдает приоритет 7-zip.

[g0dl1ke 26]

да, 7-зип давно заменяет винрар

спасибо за пояснения

[PR55.RP55 83]

Имя архива должно полностью совпадать с именем файла внутри, а если скажем часть "-" в имени архива зачем-то заменена на "_" то будет ошибка.

Я эту штуку тоже заметил да всё забывал сделать предложение.

В общем, стоит сделать корректировку для символа "-" "_"

Т.е. открывать архив с учётом того, что имена файла в архиве и сам архив имеют ( могут иметь подобное расхождение ).

*Я ещё раньше писал, что иногда в 7-zip архивы не распаковываются.

Потом понял, что дело в "-" но предлагать не стал и решил ( забыть ).

Но коли уж тему подняли - то предлагаю.

** В теме по функционалу uVS сделаю копию предложения.

[demkd 638]

Релиз v3.70

Исправлены мелкие ошибки.

[Severnyj 0]

В теме http://forum.oszone.net/thread-213731.html не получилось исправить хост-файл твиком из uVS даже из-под LocalSystem

Кусочек лога uVS:

regt 14--------------------------------------------------------Очистка HOSTS...(!) Не удалось открыть файл HOSTS для модификации [Отказано в доступе. ]Операция успешно завершена.

к тому же опять по-моему глюки в разборе путей:

C:\PROGRAM FILES\COMMON FILES\NERO\NEROSHELLEXT\\NEROSHELLEXT.DLLC:\PROGRAM FILES\SKYPE\\PHONE\SKYPE.EXE

[santy 153]

В теме http://forum.oszone.net/thread-213731.html не получилось исправить хост-файл твиком из uVS даже из-под LocalSystem

обычно такой расклад в hosts бывает если в автозапуске прописался левый lsass,

имхо, здесь, скорее всего DrWeb активен, и "грудью прикрыл" файл hosts, не давая uVS внести полезные изменения.

[demkd 638]

не получилось исправить хост-файл твиком из uVS даже из-под LocalSystem

Кто-то скрытый его действительно прикрыл и тут правильный способ сперва прибить зловреда... или не зловреда, а потом уже использовать твики, т.е. в данном случае стоит грузиться с дикса делать образ или сверку или для начала в safe mode.

C:\PROGRAM FILES\COMMON FILES\NERO\NEROSHELLEXT\\NEROSHELLEXT.DLL

C:\PROGRAM FILES\SKYPE\\PHONE\SKYPE.EXE

Это не мой глюк, это проблемы скайпа и негры, такие пути рекомендуется править ручками.

В данном случае в планировщике задач и в

HKLM\Software\Classes\CLSID\{F764812A-132C-4013-9960-5CBBEB408A0E}\InprocServer32\

[Vvvyg 12]

Кто-то скрытый его действительно прикрыл и тут правильный способ сперва прибить зловреда... или не зловреда, а потом уже использовать твики, т.е. в данном случае стоит грузиться с дикса делать образ или сверку или для начала в safe mode.

Вот здесь хватило бы команды скрипта - аналога TerminateProcessByName в AVZ. Hosts часто блокируют и не зловреды, у Яндекса есть приблуда fixhosts.exe, которая тоже пытается hosts держать, несмотря на то, что зловреды туда уже нагадили . Приходится прибивать процесс, а потом уже сброс hosts делать.

[demkd 638]

Vvvyg

Возможно иногда бы и пригодилось... хотя... для fixhosts самая правильная команда delall как и для остальных обаятельных программ. А вот тот же dr.web "уговорить" странно себя вести при записи в hosts скриптом никак не выйдет... его конечно можно легко снести с перезагрузкой, но это уже радикальная и довольно сомнительная форма лечения будет

[Vitokhv 0]

Помогите пожалуйста разобраться, может я чего не замечаю..

Прикрепил лог.

Пользователь утверждает, что присутствуют вирусы:

TR/Spy.Ranbyus.G.17

TR/Kazy.16530

TR/Ransom.DF.148

C:\Documents and Settings\All Users\Application Data\22CC6C32.exe.VIR

Возможно, пользователь сделал лог того компьютера, с которого пишет, но не с зараженного.

MICROSOF_07574A_2011_08_22_14_48_03.rar

MICROSOF_07574A_2011_08_22_14_48_03.rar

[santy 153]

Помогите пожалуйста разобраться, может я чего не замечаю..

возможно, эти файлы не входят в автозапуск, а находятся сканером, почему бы и нет

---

или присутствовали но были удалены, вот один из них, которого нет

Полное имя C:\WINDOWS\SYSTEM32\WINDEBUG32.EXE

Имя файла WINDEBUG32.EXE

Тек. статус в автозапуске

Сохраненная информация на момент создания образа

Статус в автозапуске

Инф. о файле Не удается найти указанный файл.

Цифр. подпись проверка не производилась

Ссылки на объект

Ссылка HKEY_USERS\S-1-5-21-1275210071-2052111302-1177238915-500\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run\Windows Debugger 32

Windows Debugger 32 C:\WINDOWS\system32\windebug32.exe

[demkd 638]

Пользователь утверждает, что присутствуют вирусы

стоит обратит внимание на

C:\PROGRAM FILES\VSO\FIREHEART.EXE с аннулированным сертификатом.

Возможно, пользователь сделал лог того компьютера, с которого пишет, но не с зараженного.

А о чем тогда разговор? Этот образ сделан в активной системе если система не та то и смысла смореть нет.

И to ALL обнаружилась нехорошая странность с HOSTS, как известно путь до файла можно изменить в известном месте, однако все тесты показывают на то что путь не имеет значения как минимум в обновленном до актуального состояния XP SP3 и Windows 7 SP1 и получается что при изменении пути uVS показывает HOSTS который не используется системой, поскольку всегда используется HOSTS по дефолтному пути, может кто-то знает почему или есть в наличии зловред который меняет путь... и это работает?

[demkd 638]

В след. версии будет модифицирована работа с HOSTS с учетом вышеуказанных странностей его обработки в актуальных версиях Windows, твик очистки будет модифицирован будет сохраняться host всегда по стандартному пути, путь в реестре будет изменен на стандартный.

Тестирование реакции известных антивирусов на модификацию hosts показало, что некоторые пытаются БЕЗ спроса пользователя и уведомления о своих действиях "защищать" HOSTS, помещать программу в карантин, пытаться наложить ограничения... однако HOSTS уже изувечен троянами в обоход их "защиты".

Сама защита фиктивная, один хорошо известный антивирус... своей неторопливостью, обходится детским способом с использованием стандартного API, второй известный уже своей глючностью в некоторых случаях может просто вызвать своими безумными действиями исключение при доступе к памяти со всеми вытекающими... я не ожидал что все так запущено, давно не пользуюсь этими продуктами и как оказалось правильно не пользуюсь.

Что касается действий uVS в условиях такой "заботы" - при отказе в модификации hosts _обычным способом будет выдаваться предупреждение пользователю (в т.ч. и при исполнении скрипта) c рекомендацией отключения защитного софта. Обход защиты для каждого такого... продукта делать не буду, не моя это проблема.

[Vitokhv 0]

Как определить, что путь до Hosts изменен?

Так смогу определить какой из вирусов его меняет.

[demkd 638]

Как определить, что путь до Hosts изменен?

В логе uVS указан путь до HOSTS.

--------------------------------------------------------

HOSTS:

C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS

127.0.0.1 localhost

Всего: 1

[Vitokhv 0]

Здравствуйте. Не могли бы Вы помочь с кустом реестра software

На Dr.Web его почистили но теперь нет диска D:\

http://rghost.ru/19462201 (это начальный без вмешательств)

[demkd 638]

Не могли бы Вы помочь с кустом реестра software

На Dr.Web его почистили но теперь нет диска D:\

software тут ни разу не нужен.

Почистили реестр? Или от вирусов сканером?

Какой диск был, логический раздел, виртуальный pgp, ramdisk, сетевой, subst...?

Если логический раздел то стоит сперва сделать uVS->Реестр->[HKLM] Очистить System\MountedDevices и перезагрузить затем смотреть в Управлении дисками есть ли вообще раздел, если раздела нет то воспользоваться какой-нибудь утилитой для восстановления данных, testdisk (для продвинутых), r-studio, easy recovery и т.п. для обычных. Если раздел есть, но нет буквы - попробовать присвоить букву диска руками в том же "Управлении дисками". Если буква появилась но система RAW то опять же testdisk и т.п.