Подтвердить что ты не робот

Программный подход в Java для сравнения файлов

Каким будет наилучший подход для сравнения двух шестнадцатеричных сигнатур файлов друг с другом для сходства.

В частности, я бы хотел сделать шестнадцатеричное представление файла .exe и сравнить его с серией вирусных сигнатур. Для этого подхода я планирую разбить шестнадцатеричное представление файла (exe) на отдельные группы из N символов (т.е. 10 шестнадцатеричных символов) и сделать то же самое с сигнатурой вируса. Я пытаюсь выполнить какую-то эвристику и, следовательно, статистически проверить, имеет ли этот файл exe X% сходства с известной сигнатурой вируса.

Простейший и, вероятно, очень неправильный способ, которым я думал об этом, - сравнить exe [n, n-1] с вирусом [n, n-1], где каждый элемент в массиве является вспомогательным массивом, и поэтому exe1 [0,9] против вируса1 [0,9]. Каждое подмножество будет классифицироваться статистически.

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

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


Определение. Полиморфное вредоносное ПО (вирус, червь,...) поддерживает ту же функциональность и полезную нагрузку, что и их "оригинальная" версия, имея по-видимому разные структуры (варианты). Они достигают этого путем обфускации кода и, таким образом, изменяя свою шестую подпись. Некоторые из методов, используемых для полиморфизма; изменение формата (вставить удаление пробелов), переименование переменной, перестановку операторов, добавление младшего кода, замену оператора (x = 1 изменяется на x = y/5, где y = 5), свопинг управляющих операторов. Так как вирус гриппа мутирует, и поэтому вакцинация не эффективна, полиморфные вредоносные программы мутируют, чтобы избежать обнаружения.


Обновление: После того, как вы посоветуете, вы, ребята, дали мне то, что читаете; Я сделал это, но это несколько смутило меня. Я нашел несколько алгоритмов расстояний, которые могут применяться к моей проблеме, например:

  • Самая длинная общая подпоследовательность
  • алгоритм Левенштейна
  • Алгоритм Needleman-Wunsch
  • Смит-Уотерман алгоритм
  • алгоритм Бойера Мура
  • Алгоритм Aho Corasick

Но теперь я не знаю, что использовать, все они, похоже, делают то же самое по-разному. Я продолжу заниматься исследованиями, чтобы лучше понять каждую из них; но в то же время вы могли бы высказать свое мнение по поводу which might be more suitable, чтобы я мог придать ему приоритет во время моих исследований и изучить его глубже.


Обновление 2: Я закончил использование объединения LCSubsequence, LCSubstring и Levenshtein Distance. Спасибо всем за предложения.

Существует копия готовой бумаги на GitHub

4b9b3361

Ответ 1

Для таких алгоритмов я предлагаю вам изучить область биоинформатики. Аналогичная проблема возникает там, когда у вас большие файлы (последовательности геномов), в которых вы ищете определенные подписи (гены, специальные известные короткие базовые последовательности и т.д.).

Также для рассмотрения полиморфных вредоносных программ этот сектор должен предложить вам много, потому что в биологии, похоже, сложно получить точные соответствия. (К сожалению, я не знаю подходящих аппроксимативных алгоритмов поиска/сопоставления, чтобы указать вам.)

Одним из примеров этого направления было бы адаптировать что-то вроде алгоритма Aho Corasick для одновременного поиска нескольких сигнатур вредоносного ПО.

Аналогично, алгоритмы, подобные алгоритму Boyer Moore, дают вам фантастические поисковые запросы, особенно для более длинных последовательностей (средний случай O (N/M) для текст размера N, в котором вы ищете шаблон размера M, то есть сублинейное время поиска).

Ответ 2

Опубликован ряд статей о поиске близлежащих дубликатов документов в большом корпусе документов в контексте веб-поиска. Я думаю, вы найдете их полезными. Например, см. это презентация.

Ответ 3

Недавно было проведено большое количество исследований для автоматизации обнаружения дублированных отчетов об ошибках в репозиториях ошибок. Это по существу та же самая проблема, с которой вы сталкиваетесь. Разница в том, что вы используете двоичные данные. Они похожи на проблемы, потому что вы будете искать строки, которые имеют один и тот же базовый шаблон, хотя шаблоны могут иметь некоторые незначительные отличия. Прямолинейный алгоритм, вероятно, не поможет вам здесь.

В этой статье дается хорошее резюме проблемы, а также некоторые подходы в ее цитируемых цитатах.

ftp://ftp.computer.org/press/outgoing/proceedings/Patrick/apsec10/data/4266a366.pdf

Ответ 4

Как заметил кто-то, сходство с известной проблемой струны и биоинформатики может помочь. Самая длинная общая подстрока очень хрупкая, что означает, что одна разница может вдвое уменьшить длину такой строки. Вам нужна форма выравнивания строк, но более эффективная, чем Smith-Waterman. Я попытался бы посмотреть на такие программы, как BLAST, BLAT или MUMMER3, чтобы узнать, могут ли они соответствовать вашим потребностям. Помните, что параметры по умолчанию для этих программ основаны на приложении для биологии (сколько для штрафа за вставку или подстановку, например), поэтому вам следует, вероятно, взглянуть на переоценку параметров на основе вашего домена приложения, возможно, на основе Обучающий набор. Это известная проблема, потому что даже в биологии разные приложения требуют разных параметров (основанных, например, на эволюционном расстоянии двух сравниваемых геномов). Возможно, однако, что даже при дефолте один из этих алгоритмов может привести к полезным результатам. Лучше всего было бы создать генеративную модель изменения вирусов, которая могла бы помочь вам в оптимальном выборе для алгоритма дистанции и сравнения.