【问题标题】:Database file with 78 9C header?带有 78 9C 标头的数据库文件?
【发布时间】:2016-07-22 07:37:51
【问题描述】:

我开始使用一种奇怪的数据库文件格式。 每个DB自带两个文件:一个是“database.db”,另一个是“database.key”。

“.db”文件始终以 0x78 0x9C 二进制标头开头,而“.key”始终在文件的随机部分中包含字符串“1.00 Peter's B Tree”。

在网上看了一下,发现header 0x78 0x9C 可以指压缩Zlib,但是没有找到任何查看数据库内容的方法。

这里有没有人知道可以帮助我使用这种格式的东西?谢谢 :)

编辑 1: 似乎“.db”文件包含多个 zlib 压缩流: 签名 0x78 0x9C 不仅出现在文件的开头,而且出现在文件的不同部分。 例如,这是我可以在一个文件中找到的一些流:

78 9C CB 63 40 07 33 76 5B 6A AF 78 DD 54 23 CE C9 90 C4 78 89 81 89 81 F1 22 86 9A ED 6A D7 44 F6 03 D5 B0 31 30 94 60 91 F6 D4 2A 76 3B 0C 94 E6 63 60 2C 51 B6 63 00 00 22 13 11 57
78 9C CB 63 40 07 2F 53 D7 B8 9F EC 8B B2 E1 7A F1 32 87 F1 12 03 23 03 E3 45 0C 35 4B B7 68 5B CD 90 2E E7 65 67 60 2A 51 B6 63 00 00 A6 E8 0C 5D

通过膨胀这 2 个流,我得到 2 个新的未压缩流。

然后我所做的是一个 C# 程序,它加载了一个“.db”文件并创建了一个字节数组列表;字节数组是一个放气的流。 为此,我只需在每 78 9C 处拆分文件。

这似乎适用于某些“.db”文件,但在其他情况下,它给了我一些错误,例如“无效的距离代码”,这个流

78 9C E2 13 FD 2F 14 9F CD 9B 29 3E 65 9F A0 F8 BC 7C 92 E2 93 EF 29 8A CF B0 A7 29 3E 8D FE 4A F1 B9 F2 0C C5 27 C4 B3 14 EF F5 5B 28 DE B5 B7 52 BC FF 6E A3 78 27 DD 4E F1 9E B8 83 E2 DD 6D 27 C5 FB D4 2E FA F0 6A EE A6 78 EF 78 EE EA 2F AA D3 91 FE 1F 2F 94 78 6C

或“无效的存储块长度”,使用此流

78 9C 90 35 CE 34 2F 0C 7D FE A5 57 C9 FF D5 2B 47 5B B7 C4 7F 69 EA 3F 0F AC 25 F4 45 49 3D CC FF 00 E5 AE 30 40

也许简单地在每个 78 9C 处拆分文件并不是正确的做法......

至于“.key”文件:我可以使用 Peter Graf 的库“PBL”打开它们。 通过“pblKfGetAbs ()”(http://www.mission-base.com/peter/source/pbl/doc/keyfile.html),我设法获取了与文件中每个键相关的所有记录。这些记录是 4 字节的值。 使用十六进制编辑器在解压缩的“.db”文件(在膨胀过程中没有给我错误的文件中)搜索这些值,我能够得到一些结果,但仅此而已。我不明白密钥文件上的那些记录意味着......

感谢您的帮助!

【问题讨论】:

标签: database binary zlib b-tree


【解决方案1】:

是的,这些很可能是存储在数据库中的zlib 流。

没有什么可以阻止78 9c 出现在压缩数据中,因此简单地搜索它并不是提取文件内容的好方法。 78 9c 也不是唯一有效的 zlib 标头。找到有效 zlib 流的最简单方法是简单地从每个字节开始解压缩。 zlib 将很快排除大多数没有有效的 zlib 标头。其余的你可以解压,直到它完成或失败。如果它以良好的完整性检查完成(返回Z_STREAM_END),那么极有可能是故意压缩的 zlib 流。

您正在尝试对数据库格式进行逆向工程,而该格式似乎相对较少。这是 stackoverflow 无法帮助的侦探工作,除非这里有人知道格式并识别它。

【讨论】:

  • 抱歉回复晚了。现在语言或环境并不重要。这些是“旧”数据库文件,由我公司内部的某个人创建,现在不再在这里工作,我们必须打开它们。我尝试在 Windows 中使用 java 解压缩 zlib 流,但输出并没有那么令人困惑..
  • 你尝试解压的时候,成功了吗?成功将没有错误代码。
  • 你是对的,出现了错误代码。然而,.db 文件似乎由更压缩的数据流组成。我可以在文件中找到多个 0x789C。我编写了一个程序,在每次出现 0x789C 时拆分二进制文件,然后对这些数据流中的每一个进行膨胀。然而,这似乎并不完全有效......
  • 请用您尝试过的方法以及似乎没有完全奏效的方式扩展您的问题。
【解决方案2】:

这些是zlib magic headers,被不同的实用程序(例如Git、Memcached 等)广泛使用。

要解压文件,可以使用以下命令:

printf "\x1f\x8b\x08\x00\x00\x00\x00\x00" | cat - zlib-file.dump | gunzip

要跳过之前的一些字节,请使用dd,例如

cat <(printf "\x1f\x8b\x08\x00\x00\x00\x00\x00") <(dd skip=100 if=zlib-file.dump bs=1 of=/dev/stdout) | gunzip

如果数据有crc/length错误,则认为是错误的。

【讨论】:

    【解决方案3】:

    .db 文件是压缩数据,.key 文件是 key_informations 用于在打开它们后在那些 .db(如索引文件)中找到想要的数据,您可能在这些 .db 文件中找不到字符串数据,因为它们是运行时数据库,这些 .db 文件包含像“数据包”这样的十六进制数据,并且按照他的说法进行了压缩

    【讨论】:

      【解决方案4】:

      78 9C 是具有 默认压缩的 zlib 魔术头

      尝试Aluigi's offzip命令行工具提取数据。

      【讨论】:

        猜你喜欢
        • 2021-12-17
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2018-07-07
        • 1970-01-01
        • 1970-01-01
        • 2016-05-03
        相关资源
        最近更新 更多