Обнаружение сжатия файлов - PullRequest
3 голосов
/ 15 сентября 2009

Мне нужно прочитать некоторые данные, сохраненные сторонним приложением в базе данных Acess 2000. Продавец больше не собирается задавать вопросы.

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

Я извлек содержимое записи, используя ADO и Delphi (TADOBlobStream), сохранил его на диск и открыл с помощью шестнадцатеричного редактора.

Первые 100 символов в шестнадцатеричном формате следующие:

F8 1B 00 00 07 C0 24 27 01 40 7F 20 EC 5D 24 2D 88 5C F0 A7 49 91 4A C4 EA 85 D2 98 6A B5 79 D7 B7 2B D5 48 F8 1B 00 00 07 C0 24 27 01 40 7F 20 EC 5D 24 2D 88 5C F0 A7 49 91 4A C4 EA 85 D2 98 6A B5 79 D7 B7 2B D5 48 1A 9A C8 D3 54 E3 A3 E4 F5 29 C6 97 22 95 6A 8E 10 BD 3E 4B 0B 11 AA 6D A8 С6 87 92

Может кто-нибудь сказать мне, если это соответствует обычно используемому алгоритму сжатия. Стороннее приложение, похоже, использует метод кодирования zlib из-за присутствия в его каталоге bin кодировки dll. Но использование zlib для распаковки не дает PNG. К вашему сведению, сохраненный файл составляет около 20% от размера файла PNG, встроенного в XLS.

Спасибо

Ответы [ 5 ]

5 голосов
/ 16 сентября 2009

Попробуйте разностную атаку.

  1. Извлечение двух изображений из базы данных с использованием отчета / программы, как описано.
  2. Выполнить двоичную разницу в файлах PNG.
  3. Выполнить двоичное различие с исходными BLOB-объектами в базе данных.

Сравните различия между файлами в формате BLOB и PNG. Это должно помочь определить, является ли данные BLOB-объекта совершенно другим форматом или просто оболочкой.

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

0 голосов
/ 16 сентября 2009

Мне было любопытно, поэтому я решил посмотреть. Мне нужно было перевести его в двоичную форму, поэтому, чтобы спасти следующего парня от работы, я сделал это на python Надеюсь, это поможет:

#!/usr/bin/python
from zlib import decompress; 

f = open('/tmp/data', 'w+'); 
s = "";
for b in [int(x, 16) for x in ("F8 1B 00 00 07 C0 24 27 01 40 7F 20 " +
 "EC 5D 24 2D 88 5C F0 A7 49 91 4A C4 EA 85 D2 98 6A B5 79 D7 B7 2B " +
 "D5 48 F8 1B 00 00 07 C0 24 27 01 40 7F 20 EC 5D 24 2D 88 5C F0 A7 " +
 "49 91 4A C4 EA 85 D2 98 6A B5 79 D7 B7 2B D5 48 1A 9A C8 D3 54 E3 " +
 "A3 E4 F5 29 C6 97 22 95 6A 8E 10 BD 3E 4B 0B 11 AA 6D A8 C6 87 92".split(" ")]:
  s += chr(b);

s = decompress(s);
f.write(s);
f.close();
0 голосов
/ 15 сентября 2009

Вы сказали, когда использовали zlib для распаковки, что это не PNG. Вы проверили, есть ли другой формат изображения? Может быть, JPEG или GIF - может быть, даже растровое изображение?

0 голосов
/ 16 сентября 2009

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

Я бы попробовал подать ваш поток данных на их декомпрессоры (мне известны две очень разные версии) и посмотреть, выплевывает ли они что-то более разумное.

Их SDK здесь: http://www.pkware.com/software-developer-tools-margin/software-developer-kits

Я использовал старую дос-эру, версия для Windows была слишком дорогой, и я никогда не имел с ней дело.

0 голосов
/ 15 сентября 2009

Универсальный экстрактор может дать вам несколько ответов. Это с открытым исходным кодом. http://legroom.net/software/uniextract

...