User писал(а):
По идее, количество распознаваемых вирусов ограничено лишь объемом жесткого диска, так что можно легко сделать программу добавляющую в файл hash.vdb новые хеш суммы.Главный тормоз - вычисление хэша. Это очень медленно. И бессмысленно.
Где ты видел, чтобы вирусы искали по хэшам?
По хэшам можно найти разве что разные винлокеры, трояны и скрипты - то, что входит на твой комп как партизан, прячется, но файлы не трогает.
Они имеют свои exe файлы, потому легко вычисляются. Что ты и ищешь. Но также легко они могут противодействовать такому поиску.
Есть еще вирусы, которые изменяют чужие файлы, прописываясь в них. Их по хэшу нельзя найти, т.к. он меняется при каждом заражении.
Есть еще полиморфы - настоящие призраки во плоти.
Они имеют свои exe файлы, потому легко вычисляются. Что ты и ищешь. Но также легко они могут противодействовать такому поиску.
Есть еще вирусы, которые изменяют чужие файлы, прописываясь в них. Их по хэшу нельзя найти, т.к. он меняется при каждом заражении.
Есть еще полиморфы - настоящие призраки во плоти.
Второй потенциальный тормоз: В огромных массивах никто не ищет данные. К ним обращаются по индексам.
Почему?Сравни: Один и тот же процессор за одну секунду может либо перебрать и сравнить около 150 000 элементов массива (при поиске), либо выдать около 150 000 элементов по индексам (при обращении по индексам).
Число вроде одно и тоже, но разница вот в чем:
В первом случае он перебирает, а во втором выдает результат!
Т.е. в первом случае он переберет один массив в 150000 элементов в секунду и выдаст один найденный элемент, или же переберет 15 массивов по 10000 элементов, и выдаст 15 найденных элементов.
А во втором случае он за то же время выдаст 150000 найденных элементов, причем из массива любого размера: и 10000, и 150000, и 100000000000000 - все равно будет 150 000 успешных поисков в секунду!
Сравни разницу:
Массив 10 000, перебор выдаст 1 результат за 0.07 секунды работы, а индексы 10 000 результатов за те же 0.07 секунд.
Массив 150 000, перебор выдаст 1 результат за 1 секунду работы, а индексы 150 000 результатов за ту же 1 секунду.
Массив 1 500 000, перебор выдаст 1 результат за 10 секунд работы, а индексы 1 500 000 за те же 10 секунд.
Число вроде одно и тоже, но разница вот в чем:
В первом случае он перебирает, а во втором выдает результат!
Т.е. в первом случае он переберет один массив в 150000 элементов в секунду и выдаст один найденный элемент, или же переберет 15 массивов по 10000 элементов, и выдаст 15 найденных элементов.
А во втором случае он за то же время выдаст 150000 найденных элементов, причем из массива любого размера: и 10000, и 150000, и 100000000000000 - все равно будет 150 000 успешных поисков в секунду!
Сравни разницу:
Массив 10 000, перебор выдаст 1 результат за 0.07 секунды работы, а индексы 10 000 результатов за те же 0.07 секунд.
Массив 150 000, перебор выдаст 1 результат за 1 секунду работы, а индексы 150 000 результатов за ту же 1 секунду.
Массив 1 500 000, перебор выдаст 1 результат за 10 секунд работы, а индексы 1 500 000 за те же 10 секунд.
Схему можно переквалифицировать в менеджер хэшей - проверять хеши файлол на hdd и dvd и сравнивать их со списком хэшей оттуда же, чтобы найти поврежденные (диски имеют свойство повреждать инфу, даже hdd - не по времени, так по сбоям системы).
Или еще интереснее - более надежный антивирус:
просканировать все exe и dll, добавить их в базу.
При проверке сравнивать хеши.
Если они изменились - это либо обновление, либо вирус, либо сбой.
Спросить у пользователя - если он не менял эти файлы и не обновлял, тогда это почти наверняка сделал вирус или же они повреждены сбоем системы или диска. В любом случае эти файлы уже не годятся - их либо восстанавливать, либо удалять.
еще кручеИли еще более интересный менеджер хешей:
Записывать в базу при сканировании не только хэши, но и инфу для восстановления.
Если хэш изменился и пользователь подтвердил, что это он сделал - тогда обновить хэш и инфу для восстановления в базе.
Если пользователь не менял файлы, спрашиваем: пропустить, восстановить или удалить?
Если восстановление не возможно, спрашиваем: пропустить или удалить?
Если пропустили - отмечаем их в базе как зараженные.
Если удалили - удаляем их из базы.
В базе хэшей, желательно, хранить побольше информации - хэш, путь, имя файла, расширение, размер, заражен ли, дата добавления, дата последней проверки, дата заражения, инфа для восстановления, и т.п.
При этом никто не запрещает одновременно с проверкой совпадения хэшей вести и проверку хэшей на вирусы - если есть такое совпадение, почти наверняка это означает, что файл заменил собой один из вирусов.
Базу вирусов пользователи могут пополнять самостоятельно. И в ней тоже, желательно, хранить побольше информации - хэш, оригинальное имя файла вируса, расширение, размер, тип вируса, имя вируса, подробности о работе, дата обнаружения сообществом, количество заражений в сообществе, инфа для восстановления (инструкции для удаления), и т.п.
Некоторые вирусы при таком раскладе можно даже автоматически удалять, т.е. лечить комп! Прогой, сделанной на коленке!
Обязательно следить за реестром и блокировать попытки винлокеров там прописаться. В случае обнаружения - сразу же восстанавливать оригинальные ветки. Тогда после перезагрузки винлокер не сможет вылезти. Также автоматически восстанавливать критичные системные файлы - если вдруг винлокер не станет трогать реестр, а попытается подменить системный файл.
Базы ни в коем случае не грузить в память - память достаточно драгоценный ресурс, да и нет смысла ее использовать для ускорения перебора: подсчет хэша все-равно тормозит собой весь перебор.
Лучше маппить файлы баз в память и парсить налету. А еще лучше - использовать sql3: более универсальна, многократно оптимизирована, легко редактируется, стандартна.
Лучше понизить приоритет процессу до минимального и пустить сканирование в фоне - хэши будут перебираться почти тек-же медленно, зато никому не мешая.
Сканирование не прерывать при обнаружении конфликтов или заражений - просто добавлять их в список, и помечать файлы в базе. Этот список пользователь может редактировать во время сканирования, либо же просмотреть один раз после сканирования, если занят.
Причем не обязательно сразу после сканирования. Пользователь может посмотреть все конфликты и заражения через день, или через неделю.
Просто при наличии конфликтов помаргивать иконкой и все - пользователь сам займется ими, когда найдет время.
Также добавить небольшой планировщик - когда производить сканирование, формировать ли логи, отчеты и т.п.
Прикрутить тесты, настройки скорости, распределения по ядрам и многопоточности - если скорость винта и юзер позволит, можно пустить несколько потоков, забив винт на определенный % потоками чтения.
Если нет - даже одного потока будет много. Рассчет хэша 600мб/с, скорость винта 60мб/с.
В этом случае можно расчет хэша прерывать несколько раз в секунду (алгоритм блочный - реализуется элементарно), чтобы поток чтения не превышал определенной юзером скорости. Точнее не прерывать, а считать несколько блоков, и после отдавать управление, вместо потокового чтения (блок за блоком, пока файл не закончится).
Большинство вирусов не смогут распознать, что их файл сканируют для подсчета хэша (мы же сами его считаем). Только более-менее нормальные при попытке доступа к их файлу либо попытаются распознать зачем он нам (хеширование можно распознать по блочному чтению, но у нас это сведено к минимуму - слишком редко запрашиваем блоки), либо тупо подсунут нам оригинальный файл. Распознать такое хэширование сможет только тот вирус, который ведет таблицу - кто, когда, сколько раз и к каким частям файла обращался.
Т.к. большинство вирусов сделаны для обогащения (те же винлокеры и угонщики паролей), они примитивны, и никаких анализаторов не содерджат.
Также следует предусмотреть склейку файлов. Многие угонщики паролей приклеиваются в начало жертвы, и при запуске удаляют себя, восстанавливая оригинал жертвы, или же не удаляют себя, а копируют жертву во временную папку и запускают оттуда.
Для них имеет смысл перед сканированием упорядочить базу вирусов по размерам файлов и хэшировать файлы несколько раз - сначала кусок с наименьшим размером в базе, потом кусок с размером побольше, и т.д. пока не будут перебраны все вирусы с размерами меньше размера сканируемого файла.
Это значительно увеличит время сканирования, но позволит поймать таких пиявок.
Уйдут только более сложные - которые редактируют PE-заголовок файла-жертвы, прописываясь в новых секциях, или же те, кто шифрует себя после склейки (даже простейшим upx)/ Их можно было бы перехватить при распаковке. Но не стоит - это уже внедрение антивируса в систему, так недалеко и до настоящего антивируса.
Также в базы внести поле исключений, где будет помечаться (с символами подстановки *,?,[|] и т.п.), что файл исключен - т.е. даже если он заражен или имеет конфликт, в список конфликтов не попадет и иконку мигать не заставит.
Также завести отдельную базу исключений, куда заносить пути исключения, имена файлов для исключения, расширения. Т.е. Если путь проверяемого файла совпадает с путем в базе исключений - пропустить файл. Также и имя, или расширение.
Инфу для восстановления, желательно, получать по алгоритму ICEECC. Либо, что проще - делать полную, но сжатую, копию файла в базу или в папку бекапов в папке менеджера.
Для централизованного обновления базы, нужен сайт или форум, где пользователи смогут выкладывать новые хэши вирусов, прикладывая зараженные файлы.
Эту функцию даже можно встроить в программу: Отправить зараженный файл для проверки в лабораторию?
При проверке тупо скриптом отсылать на virustotal и смотреть результат (также скриптом). Если вирус - добавляем хэш в базу обновления, если не вирус - помечаем хэш как безопасный и добавляем в базу обновления.
С этого же сайта раздавать обновления базы вирусов.
При обновлении локальную базу не заменять целиком, а дополнять из базы обновления. Если в локальной базе есть хэши, которые в базе обновлений помечены как безопасные - спрашивать: Данный хэш был отнесен к безопасной категории, это не вирус, а системная программа (чит/патчер). Хотите его пометить как безопасный, пропустить или удалить из базы вирусов?
Это тянет даже на коммерческую реализацию. Интересная получилась штука.
Простая как кирпич - никаких тебе сервисов, драйверов, анализов сигнатур, распаковщиков, слежки за процессами, анализа трафика.
И надежная - наблюдаем только за потенциальными жертвами большинства вирусов, exe/dll-файлами. Заодно защищаем их от повреждений.
И portable - настройки можно хранить в ini, в систему никак не внедрялись, ни драйверов, ни сервисов.
Можно позиционировать как легкий защитник exe/dll с функциями восстановления и простейшим антивирусом.
От серьезных вирусов не спасает, зато предупредит о повреждении или заражении файла, и даже может их восстановить.
Записывать в базу при сканировании не только хэши, но и инфу для восстановления.
Если хэш изменился и пользователь подтвердил, что это он сделал - тогда обновить хэш и инфу для восстановления в базе.
Если пользователь не менял файлы, спрашиваем: пропустить, восстановить или удалить?
Если восстановление не возможно, спрашиваем: пропустить или удалить?
Если пропустили - отмечаем их в базе как зараженные.
Если удалили - удаляем их из базы.
В базе хэшей, желательно, хранить побольше информации - хэш, путь, имя файла, расширение, размер, заражен ли, дата добавления, дата последней проверки, дата заражения, инфа для восстановления, и т.п.
При этом никто не запрещает одновременно с проверкой совпадения хэшей вести и проверку хэшей на вирусы - если есть такое совпадение, почти наверняка это означает, что файл заменил собой один из вирусов.
Базу вирусов пользователи могут пополнять самостоятельно. И в ней тоже, желательно, хранить побольше информации - хэш, оригинальное имя файла вируса, расширение, размер, тип вируса, имя вируса, подробности о работе, дата обнаружения сообществом, количество заражений в сообществе, инфа для восстановления (инструкции для удаления), и т.п.
Некоторые вирусы при таком раскладе можно даже автоматически удалять, т.е. лечить комп! Прогой, сделанной на коленке!
Обязательно следить за реестром и блокировать попытки винлокеров там прописаться. В случае обнаружения - сразу же восстанавливать оригинальные ветки. Тогда после перезагрузки винлокер не сможет вылезти. Также автоматически восстанавливать критичные системные файлы - если вдруг винлокер не станет трогать реестр, а попытается подменить системный файл.
Базы ни в коем случае не грузить в память - память достаточно драгоценный ресурс, да и нет смысла ее использовать для ускорения перебора: подсчет хэша все-равно тормозит собой весь перебор.
Лучше маппить файлы баз в память и парсить налету. А еще лучше - использовать sql3: более универсальна, многократно оптимизирована, легко редактируется, стандартна.
Лучше понизить приоритет процессу до минимального и пустить сканирование в фоне - хэши будут перебираться почти тек-же медленно, зато никому не мешая.
Сканирование не прерывать при обнаружении конфликтов или заражений - просто добавлять их в список, и помечать файлы в базе. Этот список пользователь может редактировать во время сканирования, либо же просмотреть один раз после сканирования, если занят.
Причем не обязательно сразу после сканирования. Пользователь может посмотреть все конфликты и заражения через день, или через неделю.
Просто при наличии конфликтов помаргивать иконкой и все - пользователь сам займется ими, когда найдет время.
Также добавить небольшой планировщик - когда производить сканирование, формировать ли логи, отчеты и т.п.
Прикрутить тесты, настройки скорости, распределения по ядрам и многопоточности - если скорость винта и юзер позволит, можно пустить несколько потоков, забив винт на определенный % потоками чтения.
Если нет - даже одного потока будет много. Рассчет хэша 600мб/с, скорость винта 60мб/с.
В этом случае можно расчет хэша прерывать несколько раз в секунду (алгоритм блочный - реализуется элементарно), чтобы поток чтения не превышал определенной юзером скорости. Точнее не прерывать, а считать несколько блоков, и после отдавать управление, вместо потокового чтения (блок за блоком, пока файл не закончится).
Большинство вирусов не смогут распознать, что их файл сканируют для подсчета хэша (мы же сами его считаем). Только более-менее нормальные при попытке доступа к их файлу либо попытаются распознать зачем он нам (хеширование можно распознать по блочному чтению, но у нас это сведено к минимуму - слишком редко запрашиваем блоки), либо тупо подсунут нам оригинальный файл. Распознать такое хэширование сможет только тот вирус, который ведет таблицу - кто, когда, сколько раз и к каким частям файла обращался.
Т.к. большинство вирусов сделаны для обогащения (те же винлокеры и угонщики паролей), они примитивны, и никаких анализаторов не содерджат.
Также следует предусмотреть склейку файлов. Многие угонщики паролей приклеиваются в начало жертвы, и при запуске удаляют себя, восстанавливая оригинал жертвы, или же не удаляют себя, а копируют жертву во временную папку и запускают оттуда.
Для них имеет смысл перед сканированием упорядочить базу вирусов по размерам файлов и хэшировать файлы несколько раз - сначала кусок с наименьшим размером в базе, потом кусок с размером побольше, и т.д. пока не будут перебраны все вирусы с размерами меньше размера сканируемого файла.
Это значительно увеличит время сканирования, но позволит поймать таких пиявок.
Уйдут только более сложные - которые редактируют PE-заголовок файла-жертвы, прописываясь в новых секциях, или же те, кто шифрует себя после склейки (даже простейшим upx)/ Их можно было бы перехватить при распаковке. Но не стоит - это уже внедрение антивируса в систему, так недалеко и до настоящего антивируса.
Также в базы внести поле исключений, где будет помечаться (с символами подстановки *,?,[|] и т.п.), что файл исключен - т.е. даже если он заражен или имеет конфликт, в список конфликтов не попадет и иконку мигать не заставит.
Также завести отдельную базу исключений, куда заносить пути исключения, имена файлов для исключения, расширения. Т.е. Если путь проверяемого файла совпадает с путем в базе исключений - пропустить файл. Также и имя, или расширение.
Инфу для восстановления, желательно, получать по алгоритму ICEECC. Либо, что проще - делать полную, но сжатую, копию файла в базу или в папку бекапов в папке менеджера.
Для централизованного обновления базы, нужен сайт или форум, где пользователи смогут выкладывать новые хэши вирусов, прикладывая зараженные файлы.
Эту функцию даже можно встроить в программу: Отправить зараженный файл для проверки в лабораторию?
При проверке тупо скриптом отсылать на virustotal и смотреть результат (также скриптом). Если вирус - добавляем хэш в базу обновления, если не вирус - помечаем хэш как безопасный и добавляем в базу обновления.
С этого же сайта раздавать обновления базы вирусов.
При обновлении локальную базу не заменять целиком, а дополнять из базы обновления. Если в локальной базе есть хэши, которые в базе обновлений помечены как безопасные - спрашивать: Данный хэш был отнесен к безопасной категории, это не вирус, а системная программа (чит/патчер). Хотите его пометить как безопасный, пропустить или удалить из базы вирусов?
Это тянет даже на коммерческую реализацию. Интересная получилась штука.
Простая как кирпич - никаких тебе сервисов, драйверов, анализов сигнатур, распаковщиков, слежки за процессами, анализа трафика.
И надежная - наблюдаем только за потенциальными жертвами большинства вирусов, exe/dll-файлами. Заодно защищаем их от повреждений.
И portable - настройки можно хранить в ini, в систему никак не внедрялись, ни драйверов, ни сервисов.
Можно позиционировать как легкий защитник exe/dll с функциями восстановления и простейшим антивирусом.
От серьезных вирусов не спасает, зато предупредит о повреждении или заражении файла, и даже может их восстановить.
Поиск
Друзья
Администрация