Возможно "не-в-тему" вопрос.
Имеются 2 бин.файла. Их длина может не совпадать.
(конкретно - это "прошивки" для MSP430. Не формат .txt, а образ памяти, .bin).

(?) Есть ли утилита из готового, или другие средства, или матем. метод, который позволял бы,
сравнив 2 файла, выдало бы результат в виде "файлы имеют сходство на 85 %".

Можно оценить сходство, скормив файлы любому компрессору.

Затея неудачная или в лоб не решается. Переписав сырцы и перекомпилировав, но сохранив общий функционал - получим несовпадения bin, а на деле - функция та же.

Если это тест (в том числе и программные листинги), то есть такие программы "лексического анализа", которые плагиат выявляют . Но если это прошивка МК в кодах процессора, то тут надежды на получение процента сходства, имеющего реальный смысл, практически нет.

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

Мне по делу службы , довольно часто приходится делать кря... фиксы, то бишь лекарства от жадности . И в этом деле сильно востребована возможность найти, куда участок кода из старой версии переместился в новой. Догадываетесь зачем? В таких случаях я использую рукописную программу, обнуляющую числовые константы в инструкциях загрузки констант в регистры и адресных переходов по JMP и CALL. Конечно, это очень грубо, но зато после этого бинарники можно сравнивать, как тесты (например, в виде дампа hex-кода). При этом находится иного лишнего, но круг поиска уже сильно сужается. Особенно, когда точно знаешь, что ищешь.

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

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

А такой задачи аффтар пока и не ставил.

А это почти одно и тоже.

Аффтар просил сравнить файлы, а не что-либо "доказать", это две большие разницы.

Я догадываюсь, почему так.
В каком-то законе есть цифра то ли 70% совпадения, то ли около того, после чего бинарник считается сплагиаченным.
И аффтора интересует только то, пролазит он мимо этого закона или нет.
Чисто по формальным признакам. Да иначе и быть не может.

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

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

Простой пример. Двое программистов независимо друг от друга написали консольные утилиты для очистки содержимого текстового файла, причем использованы одни и те же среды программирования и стандартные библиотеки. Как думаете, какая вероятность корреляционного совпадения exe? Большая.

Это всё понятно. Но не относится к делу.
К тому же, речь не о да/нет, а о %.

ТС-ру я уже сообщил свое мнение в постах #3 и #6.

Это именно бинарник, а не листинг.
Я в смысле, что, например, вызов сишной ф-ии имеет типовую сигнатуру (по крайней мере - кол-во параметров), и наличие таких сигнатур - уже некий "отпечаток" на бинарном коде, соответствующий исходному тексту. Влияние оптимизации, опций компилятора, включения inline - это все понятно.
Но. Все исходники и бинарники - мои родные. Просто их достаточно много, и надо найти "максимально" похожий в имеющемся наборе (вроде библиотеки).
А если будет похожа хотябы основная часть - то скорее всего опиции компилятора теже, и отличие только в тексте исходника (добавелно или удалено).
Думаю, в моем случае нужен гибрид дизассемблера + утилита подобная WinDiff


пардон, под компрессором я понял архиватор. Типа свертка ?




Ok - спасибо. Ближние переходы обычно относительные. Даже если будут сдвиги - код останется темже.

Архиватор, да. Степень сходства можно оценить по разнице в размере двух архивов, первый из которых содержит только один файл, а второй - оба. Экспресс-метод.

если прикомпоновавны статически библиотеки



То, что ОНО нетривиально, я понимаю. Но вполне решаемая. И я предполагал, что это уже раз 100 решено до меня, и математиками и программистами
Сравнение фотографий с фейсами, например. Специфика - лица.
А у нас - специфика - тип процессора. MSP430.
..... я так думаю.



Всем спасибо !
Надо "перекурить" инф.

Не в тему вопрос. Например,программа из 10 строк. в одной а+б в другой 3-4
Откуда эти БИНы? Например,разные калибровочные таблицы по 1кБ каждая. Или архив значений счётчика на 2кБ

Это не про корреляцию, а про поиск минимальной длины вставок и замен в строке. На практике можете посмотреть на утилиту bsdiff
http://www.daemonology.net/bsdiff/

Процентики можно будет посчитать самому по получившемуся патчу.

Спасибо за линк.