这是经过得力伯格进一步研究后的“还原”图像：
如预期的那样，每大约0x4020字节有一个5字节的块标记。格式如下所示：
struct marker {
uint8_t tag; /* 1 if this is the last marker in the file, 0 otherwise */
uint16_t len; /* size of the following block (little-endian) */
uint16_t notlen; /* 0xffff - len */
};
读取标记后，接下来的marker.len字节将构成文件的一部分。marker.notlen是这样的控制变量marker.len + marker.notlen == 0xffff。最后一个块是这样的marker.tag == 1。
结构可能如下。仍然有未知值。
struct file {
uint8_t name_len; /* number of bytes in the filename */
/* (not sure whether it's uint8_t or uint16_t) */
char name[name_len]; /* filename */
uint32_t file_len; /* size of the file (little endian) */
/* eg. "40 25 01 00" is 0x12540 bytes */
uint16_t unknown; /* maybe a checksum? */
marker marker1; /* first block marker (tag == 0) */
uint8_t data1[marker1.len]; /* data of the first block */
marker marker2; /* second block marker (tag == 0) */
uint8_t data2[marker2.len]; /* data of the second block */
/* ... */
marker lastmarker; /* last block marker (tag == 1) */
uint8_t lastdata[lastmarker.len]; /* data of the last block */
uint32_t unknown2; /* end data? another checksum? */
};
我还没有弄清楚到底是什么，但是由于PNG接受填充，所以它不太戏剧化。但是，编码后的文件大小清楚地表明应忽略最后4个字节...
由于在文件开始之前我无法访问所有块标记，因此我编写了从结尾处开始的解码器，并尝试查找块标记。它一点也不健壮，但是很好，它适用于您的测试图像：
#include <stdio.h>
#include <string.h>
#define MAX_SIZE (1024 * 1024)
unsigned char buf[MAX_SIZE];
/* Usage: program infile.png outfile.png */
int main(int argc, char *argv[])
{
size_t i, len, lastcheck;
FILE *f = fopen(argv[1], "rb");
len = fread(buf, 1, MAX_SIZE, f);
fclose(f);
/* Start from the end and check validity */
lastcheck = len;
for (i = len - 5; i-- > 0; )
{
size_t off = buf[i + 2] * 256 + buf[i + 1];
size_t notoff = buf[i + 4] * 256 + buf[i + 3];
if (buf[i] >= 2 || off + notoff != 0xffff)
continue;
else if (buf[i] == 1 && lastcheck != len)
continue;
else if (buf[i] == 0 && i + off + 5 != lastcheck)
continue;
lastcheck = i;
memmove(buf + i, buf + i + 5, len - i - 5);
len -= 5;
i -= 5;
}
f = fopen(argv[2], "wb+");
fwrite(buf, 1, len, f);
fclose(f);
return 0;
}
较早的研究
这是0x4022从第二个图像中删除字节，然后通过删除byte时得到的0x8092：
它并没有真正“修复”图像；我通过反复试验做到了这一点。但是，它告诉我们每16384个字节有意外数据。我的猜测是，图像打包在某种文件系统结构中，意外数据只是块标记读取数据时应删除的。
我不知道块标记的确切位置和大小，但是块大小本身肯定是2 ^ 14字节。
如果您还可以提供十六进制转储（几十个字节），该十六进制转储显示在映像之前和之后的内容。这将提示有关在块的开头或结尾存储了哪种信息。
当然，提取代码中也有可能存在错误。如果您使用16384字节的缓冲区进行文件操作，那么我将首先在此处进行检查。
