检测文件压缩

发布于 2024-08-05 04:48:05 字数 672 浏览 13 评论 0原文

我必须读取第三方应用程序存储在 Acess 2000 数据库中的一些数据。供应商不再提问。

一张表包含似乎被压缩的图像数据 - 因为原始应用程序可以将 blob 字段的内容导出到 xls 导出文件中的嵌入 png 图像。

我使用 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 10BD 3E 4B 0B 11 AA 6D A8 C6 87 92

谁能告诉我这是否符合常用的压缩算法。 3rd 方应用程序似乎使用 zlib 编码方法,因为其 bin 目录中存在编码 dll。但使用 zlib 解压并不会产生 PNG。仅供参考,保存的文件大小约为嵌入 XLS 的 PNG 文件大小的 20%。

谢谢

I have to read some data stored by a third party application in an Acess 2000 database. The vendor is no longer around to ask questions.

One table contains image data that appears to be compressed - because the original application can export the contents of the blob field to an embedded png image in a xls export file.

I have extracted the contents of the record using ADO and Delphi (TADOBlobStream), saved it to disk and opened it with a hex editor.

The first 100 characters in hex are as follows

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

Can anyone tell me if this conforms to a commonly used compression algorithm. The 3rd party application would seems to use the zlib encoding method because of the presence of an encoding dll in its bin directory. But using zlib to decompress does not yield a PNG. FYI, the saved file is about 20% of the size of the PNG file embedded into the XLS.

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

遮了一弯 2024-08-12 04:48:05

尝试差异攻击。

  1. 使用所述报告/程序从数据库中提取两个图像。
  2. 对 PNG 文件执行二进制差异。
  3. 对数据库中的源 blob 执行二进制差异。

比较 blob 格式和 PNG 格式文件之间的差异。这应该有助于确定 blob 数据是完全不同的格式还是只是一个包装器。

还可以尝试相互比较两个不同的图像斑点 - 看看哪些变化以及哪些(如果有的话)保持不变。

Try a differencing attack.

  1. Extract two images from the database using the report / program as described.
  2. Perform a binary difference on the PNG files.
  3. Perform a binary difference on the source blobs in the database.

Compare the differences between the files in blob format and PNG format. This should help in determining if the blob data is a completely different format or just a wrapper.

Also try comparing two different image blobs to each other - see what changes and what (if anything) stays the same.

苍风燃霜 2024-08-12 04:48:05

通用提取器可以给你一些答案。它是开源的。
http://legroom.net/software/uniextract

Universal Extractor can give you some answers. It is open source.
http://legroom.net/software/uniextract

短暂陪伴 2024-08-12 04:48:05

你说当你使用zlib解压它时它不是PNG。您是否检查过是否是其他图像格式?也许是 JPEG 或 GIF - 甚至可能是位图?

You said when you used zlib to decompress it that it wasn't a PNG. Have you checked to see if its some other image format? Maybe JPEG or GIF - maybe even a bitmap?

铁轨上的流浪者 2024-08-12 04:48:05

我不知道如何测试它,但 Pkware 至少曾经在市场上销售过(大概他们仍然这样做,但我已经很久没有看过了)一个用于合并到程序中的压缩器。它设计用于处理内存中的原始数据流,因此不会在其压缩的数据上留下任何明显的签名。

我会尝试将您的数据流提供给他们的解压缩器(我知道有两个非常不同的版本),看看他们是否吐出一些看起来更合理的东西。

他们的 SDK 在这里: http://www.pkware.com /software-developer-tools-margin/software-developer-kits

我用的是旧的 dos 时代的工具,Windows 版本太贵了,我从来没有处理过它。

I'm not sure how to test it but Pkware at least used to market (presumably they still do but I haven't looked in ages) a compressor meant for incorporation into a program. It is designed to work on a raw stream of data in memory and thus it won't leave any obvious signature on the data it compresses.

I would try feeding your data stream to their decompressors (I'm aware of two very different versions) and see if they spit out something that looks more reasonable.

Their SDK's are here: http://www.pkware.com/software-developer-tools-margin/software-developer-kits

I used the old dos-era one, the Windows version was too expensive and I never dealt with it.

早茶月光 2024-08-12 04:48:05

我对此很好奇,所以我决定去看看。我需要将其转换为二进制形式,因此为了节省下一个人的工作量,我在 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();

I was curious about this so I decided to take a look. I needed to get it into binary form, so to save the next guy some work, I did this in python. Hope it helps:

#!/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();
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文