【发布时间】：2023-03-19 14:10:01
【问题描述】：
我有一个文件，其中丢失了非常重要的 java 项目源代码。 这是一个精灵文件。当我用编辑器打开它时，大部分内容是不可读的，但完整的 java 项目似乎作为未压缩的 zip 文件夹嵌入到具有文件夹结构和所有内容的文件中（不要问我为什么。我只是试图取回信息我不是负责）。
elf 文件中的相关信息片段如下所示：
PK
Üi‰L§½kQ Q 9 file/path/i/cant/show/contenttext
content
content
因为我不知道 zip 文件夹从哪里开始以及在哪里结束，并且因为所有内容都未压缩，所以我的想法是编写一个小脚本来从 elf 文件中抓取并创建完整的 javaproject。
为此，我想要标题中的文件名长度，以便轻松知道文件名结束的位置 end filecontent 开始。
ThisPK Üi‰L§½kQ Q 9 似乎是 zipfile 的文件头。我将它转换为十六进制，它看起来像这样：504B03040A2020082020DC69894CA71E BD6B512020205120202039202020
我尝试使用来自wikipedia 的信息对其进行格式化：
504B0304 //sig (this showed me i did something right)
0A20 // version
2008 // generalpurpose flag
2020 // compression method
DC69 // File last modification time
894C // File last modification date
A71EBD6B //CRC-32 of uncompressed data
51202020 //Compressed size (or 0xffffffff for ZIP64)
51202020 //Uncompressed size (or 0xffffffff for ZIP64)
3920 //File name length (n)
2020 //Extra field length (m)
和字节序切换：
04034B50 //sig
200A // version
0820 // generalpurpose flag
2020 // compression method
69DC // File last modification time
4C89 // File last modification date
6BBD1EA7 //CRC-32 of uncompressed data
20202051 //Compressed size (or 0xffffffff for ZIP64)
20202051 //Uncompressed size (or 0xffffffff for ZIP64)
2039 //File name length (n)
2020 //Extra field length (m)
但似乎有些不对劲。文件头的长度是正确的（30 个字节加上文件名），数字似乎在正确的位置有信息，但 2020 应该是 0000 用于压缩。对我来说，转换为十六进制似乎只对了一半。
我必须改变什么才能获得正确的数字？
【问题讨论】：
-
这可能很明显，但是您是否尝试过使用您选择的 ZIP 工具打开它？ ZIP 文件很奇怪，因为它们不一定需要在文件的开头有它们的标题（由于文件格式的构造方式）。这使得它们非常擅长附加/嵌入到其他文件格式（例如此处的 ELF）中，并且仍然可以作为“普通”ZIP 文件打开。所以像
unzip -t yourfile这样的东西可以工作。如果这不起作用，那么 Info-ZIP 的-F或-FF标志（许多 Linux 发行版附带，因此您可能已经拥有它）可能有助于恢复 ZIP。 -
是的，我试过了（现在又试了一次以确保）。对我来说，zip 文件似乎嵌入在 elf 文件的 .text 部分中，很难看出它的开始和结束位置。