文章内容

Abstract

文件雕刻技术可以在缺失元数据的存储器中恢复文件，当数据被编码和压缩后，对文件的雕刻需要编码和压缩的相关信息（元数据）

文章检测了大量的JPEG图片头以识别它们的结构特征，并运用这一信息实现需要两个步骤的新技术。

解压不完整的文件数据，以获得一个空间域的描述
然后依据这个在空间域的数据中，还原得到一个感官上有意义的图像（即得到正常的图片）

Introduction

随着越来越多的数据的产生以及被存储到数不尽的设备中，对于在设备错误或遗失情况下的文件数据恢复技术的需求开始增长。所有的设备通过将文件打散为不通过的小块来存储到设备上，对于较为老式的存储设备，这一小块的大小为0.5Kb，而到最新的设备，大小会是64Kb。而在访问这些数据的时候需要根据元数据将这些块连成一个链表，以取得文件的数据。由此，对于一个文件的恢复存在的挑战（challenge）有：

由于分块存储的原因，无法连续地展开文件数据用来进行恢复
数据会被进行编码、压缩到二进制中进行存储，以最大化的节省空间（压缩）

碎片文件雕刻问题受到了人们的研究兴趣，并且具有一定数量的技术来进行解决。这些技术尝试在解码JPEG图像的同时识别出碎片点。在解码失败或者开始产生错误时候将对应的位置识别为一个碎片点，而这些技术通过多次合并新的数据块和已经识别的数据块来恢复和验证数据。但是目前最前沿的技术中，都默认文件头是存在的，如果一个文件是部分存在，但是文件头被删除了，现有的技术则不能对该文件进行恢复。

文章会指出恢复孤立的JPEG碎片的具有挑战性的问题，文章实现的最为根本的方法是为碎片文件重建一个文件头。JPEG图像通常是由数码相机创建，所以通过检查大量的Flick图像分享网站上的大量图片来获取得到编码信息。

下一节中提供了基于该角度和所描述的挑战给出了恢复一个碎片文件头部的概述
在第三节中提供了在Flickr数据集中的发现以及它们如何用于重建文件头
第四节描述了文章提出的文件雕刻技术的每一步
最后一节通过实现的效果来总结该文章

Craving Challengs

JPEG标准定义了四个压缩模式：无损、基线（baseline）、渐进式、阶梯式。

在baseline模式中，通过从上到下扫描图像以顺序存储图像数据，并且这种模式需要在JPEG标准中作为一种基本的能力进行一致的实现。而与之相反的是，渐进式模式通过多次扫描来船速图像数据，阶梯模式允许图像在不同分辨率的机器上显示。而baseline模式是最为广泛被使用的压缩模式，该模式最为简单并且需要较少的计算资源。

JFIF定义了一种被称为YCbCr的用于编码色彩信息的标准色彩空间，Y（luminance）接近于图像的明度数据，CrCb则接近于图像的色度数据。

JPEG文件数据包含两类segments，标记段包含关于这个图像的基本信息，而数据段包含了图像的编码数据

所有的JPEG图像被作为一系列图像块进行存储，而这些图像块的大小具有8x8、8x16、16x8以及16x16像素四种，这样的最小图像块（MCU）中具有确定数量的来自于每个颜色组件的块。而在每个MCU中的颜色组件数量取决于在编码时的子采样过程。

设计一种自动雕刻孤立碎片的方式需要解决两个问题：

碎片数据需要解压缩，而解压缩需要正确识别压缩方式、压缩参数和子采样配置。但是在删除文件中进行解码需要在一些任意的位开始解压缩数据流，而这样可能会导致和哈夫曼编码不一致。
另外一个需要克服的挑战是正确地渲染一部分图像数据，而这需要能够正确通过已经恢复的数据猜测缺失的参数例如宽度和量化表

很显然的是，解码文件碎片数据最为具有挑战性的是需要尝试大量可能的压缩设置。而最为起到决定性的是选取哈夫曼表。但是由于现有的图片可能被在相同的相机中进行裁剪，或者是被相同的图像编辑工具编辑，又或者是在相同的网站上下载。所有可以通过这些信息来猜测可能的编码信息，在检查了大量的图像后得到的信息可以用于进行这些参数的补充。

JPEG Encoding Setting Statistics

为了实现可靠的对JPEG编码的统计，编写了一个来自Flickr所有数码相机和模型的图像的列表。为了保证编码能够反映图像捕获设备的设置，而不是由编辑工具重新编辑过的图像，对接口抓取的图像进行了过滤，最后得到767916张图像。而后面为了去掉通过编辑软件编辑的图像，又通过ExIF数据信息筛去了一部分图像，最后剩余460643张图像。

对图像检查后，有5963套哈夫曼表，而每一套哈夫曼表有四个不同的表用于编码亮度中的AC和DC，以及色度。然而有98.61%的图像的哈夫曼表是同一套，其他的5962套哈夫曼表用于编码其他的6425张图像。而类似得到信息还有：子采样方式、图像尺寸、Restart Markers、DCT表信息

Fragment Carver

为了技术的通用性，考虑得到的图像碎片都没有头部数据或者任何的标记，例如开始或结束扫描标记，该技术的步骤如下：

在只有部分的比特流中检测字节边界，用于区分被编码的图像数据
选取一套哈夫曼表用于解码，由于标准的哈夫曼表是较为常用的，所以目前仅考虑选取标准的哈夫曼表
通过选取的哈夫曼表用于三种可能的MCU结构，如果都不可行的话换下一个可能的比特位开始，直到能够成功解码
使用常见的DCT表对解码的MCU进行反量化，而这一步骤通过对图像块分析得到宽度

Decoding the Bitstream

在任意一个比特位置开始解码需要两个条件：

MCU的哪一个组件需要解码，这决定了使用哪一个哈夫曼表来解码
codeword的对齐

字节边界查找：由于0xFF作为JPEG图像的第一个标识，在检查到该数据的时候，将其视为开始的标志。为了避免混乱，一个0xFF后面必须跟着0x00，这表明这个0x00是可以忽略的。

而0xFF01到0xFFCF以及0xFFD8到0xFFFF是不会出现在已编码的数据中的，所以这些字节出现的位置应该排除在字节边界外。

实现同步：一个解码器如果正确地从任意字节开始解码得到代码字（codeword），则被称为是同步成功的。而哈夫曼编码的自同步属性保证它的弹性较好，在添加、删除比特后也可以解码成功。所以如果比特流中存在错误的话，会导致在解码的数据不正确。而在Fig.7中展示了数据流的部分数据丢失后，解码得到的数据不正确的例子。

在任何的同步设置下，正确解码数据块的能力依赖于EOB标记的出现。在45w张图像数据中，8x8的数据块有94.11%是在EOB位置结束编码的。尽管EOB标准出现的频率比较高，但是对于解码器来说也可能在没有EOB标志的情况下进入同步。在这样的情况下，和可能解码器会解码到8x8的MCU溢出或者出现非法的代码字的情况下才会停止，这也意味着同步失败。