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

Question

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

Чтобы установить некоторые границы. Файлы не зашифрованы и DRM отсутствует. Тип и формат файла зависят от автора программы (т. Е. Это не «стандартный файл», такой как * .tar, личность которого была утеряна). Там (вероятно) нет преднамеренного запутывания, но могут быть некоторые любительские усилия по экономии места. Мы можем предположить, что у нас есть общие знания о том, что представляют собой данные, и мы можем распознать некоторые, но, вероятно, не все поля и массивы.

Предположим, что большая часть данных является числовой, со скалярами и массивами (возможно, 1- и 2-мерными, а иногда нерегулярными или треугольными). Также будут некоторые строки символов, вероятно, имена людей, сайты, даты и, возможно, некоторые ключевые слова. В программе будет код, который читает двоичный файл, но у нас нет доступа к источнику или ассемблеру. Например, он может быть написан программой VAX Fortran или ранним Unix или Windows как объекты OLE. Числа могут быть с прямым или прямым порядком байтов (что неизвестно в начале), но, вероятно, они согласуются. Мы могут иметь разные версии на разных машинах (например, Cray).

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

Мы можем предположить два сценария:

1. Мы можем перезапустить программу с разными входами, чтобы мы могли проводить эксперименты.
2. Мы не можем перезапустить программу - у нас есть фиксированный набор документов. Это имеет небольшое сходство с расшифровкой исторических документов на неизвестном языке (например, Линейный B).

Частичное решение может быть приемлемым, т. Е. Могут существовать некоторые области, которые ни один живой человек сейчас не понимает, но большинство других интерпретируются.

Меня интересуют только подходы с открытым исходным кодом.

ОБНОВЛЕНИЕ Есть связанный вопрос SO ( Как выполнить обратный инжиниринг форматов двоичных файлов для целей совместимости ), но акцент несколько иной. ОБНОВЛЕНИЕ Умное предложение от @brianegge по адресу (1). Используйте truss (или, возможно, strace в Linux), чтобы сбросить все вызовы write () и аналогичные вызовы в программе. Это должно позволить как минимум сбор записей, записанных на диск.

Answer 1

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

Общие части между двумя заголовками могут рассматриваться как общие подписи, и я думаю, вы можете их игнорировать

Answer 2

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

$ truss -t write echo foo
foowrite(1, " f o o", 3)                                = 3
write(1, "\n", 1)                               = 1

Также может иметь смысл взглянуть на двоичный файл. В системах Unix вы можете использовать objdump для просмотра макета двоичного файла. Это будет указывать на разделы кода и данных. Затем вы можете открыть двоичный файл в шестнадцатеричном редакторе и перейти к определенным смещениям. Возможно, вас заинтересуют мои советы для двоичных файлов Solaris .

Answer 3

• Различайте 2 или более файлов, чтобы найти сходство. Это часто помогает вам идентифицировать блоки заголовка и различные разделы файла.

• Вычисление порядка байтов обычно довольно легко - более значимые байты, как правило, равны нулю гораздо чаще, чем менее значимые, поэтому, если вы видите шаблон типа «00 78» или «78 00», вы может сделать хорошее предположение о том, какой байт является msb. Тем не менее, это поможет вам только тогда, когда вы (примерно) разобрались с предыдущими данными, чтобы знать, как выровнены данные.

• Ищите легко идентифицируемые данные - строки - это первое место для начала, потому что вы можете легко их обнаружить. Они часто дают вам подсказки, так как они обычно встраиваются рядом со связанными данными, используются в качестве стандартных элементов в заголовках и т. Д. Если строки в кодировке Unicode, вы обычно будете видеть буквы текста, разделенные нулевыми байтами, что поможет вам определить порядковый номер и выравнивание данных в этой точке данных.

• Подход общего формата (например, IFF) заключается в хранении порций данных, каждый из которых имеет небольшой заголовок (например, 2 или 4-байтовый идентификатор, затем размер 2 или 4 байта для блока, затем данные блок). Обычно люди используют значимые (для них) идентификаторы чанков, поэтому их легко обнаружить. Если вы найдете то, что выглядит как тег, проверьте следующие данные, чтобы увидеть, выглядит ли он как длина (посмотрите, сколько байтов в данных чтобы увидеть, если это выглядит, как есть другой заголовок). Если вы можете определить такой формат, вы разбиваете проблему «одного большого файла» на проблему «множества маленьких файлов», которая делает ее намного проще. (Тем не менее, многие данные устройства имеют тенденцию быть «оптимизированными», чтобы сделать их компактными, и в этом случае программисты часто выбрасывают удобные расширяемые форматы и собирают все воедино, упаковывая биты и в целом делая вещи намного более сложными для вас)

• Поиск известных значений. Если ваше устройство отображает «температура: 40», то, возможно, вы найдете это значение непосредственно в файле. (Также распространено использование масштабных коэффициентов или значений с фиксированной запятой, поэтому 40 может быть представлено как (например, 40 * 10 = 400 или 40 * 256 = 10240) *

• Если вы можете управлять устройством достаточно: создайте несколько простых файлов. То, чего вы пытаетесь достичь, - это наименьшее количество файлов, которые вы можете извлечь из устройства, чтобы минимизировать данные, которые вы должны исследовать. Затем внесите изменения в устройство, которое приводит к изменению файла - попытайтесь свести к минимуму количество изменений - и снова захватите файл. Если формат файла «открытый» (не сжатый и не зашифрованный), то вы сможете определить байты, которые изменились.

• Если вы можете «загрузить» файлы обратно на устройство, вы также сможете создавать свои собственные файлы, просто изменив одно значение, чтобы увидеть, можете ли вы заметить какое-либо изменение поведения на устройстве. Если вам удастся набрать простые значения, это может работать хорошо, но часто вы можете обнаружить, что просто нарушаете формат файла, и устройство вообще не сможет читать данные.

Answer 4

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

Одним из инструментов является WinOLS , который предназначен для интерпретации и редактирования двоичных изображений компьютера управления двигателем транспортного средства (в основном числовых данных в их справочных таблицах). Он поддерживает различные форматы байтов (хотя я думаю, что не PDP) и позволяет просматривать данные с различной шириной и смещением, определять области массива (карты) и визуализировать их в 2D или 3D со всеми видами масштабирования и смещения. Он также имеет эвристический / статистический автоматический поиск карт, который может работать для вас.

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

Answer 5

Я надеялся, что найдется волшебная утилита, которая сможет вырабатывать шаблоны, пробовать разные порядки байтов и т. Д. Но этого, похоже, нет!