为什么此435×652像素JPEG超过6 MB？

这是在看到这个问题之后有人有用地修复它之前，这是一张相对不张扬且很小的̶f̶i̶s̶h̶nudibranch照片，具有283,620像素。它具有一些元数据：文本Exif标签，8.6kB的颜色配置文件信息，5,557字节的缩略图以及648,534字节的预览图像（我无法阅读）和一些其他随机内容（例如人脸检测区域）

使用

exiftool -a -b -W %d%f_%t%-c.%s -u -g1 -ee -api RequestAll=3 temp.jpg

总共提取<650 kiB的东西。

有什么策略或工具可以用来发现正在发生的事情，以及文件中是否隐藏了某些东西？

如果它使事情变得更容易，相同或非常相似的包含似乎会影响同一Flickr用户的多个文件：2，3，4，5

您要查找的术语是“隐写术”。

@schroeder我本来以为隐写方法不会尝试将其有效载荷放在单独的斑点中...我所见过的方法似乎都在操纵像素颜色，不会显着增加图像大小，但是我没有看了十多年了。这似乎更类似于将GIF附加到ZIP上，从而使文件符合两个规范。那真的是隐写术吗？

隐写术是隐藏数据的任何方法。 JPEG不存储“像素”，但是可以以相同的方式从某些参考图像中提取少量的不同量子。追加数据也是隐写术。

对于JPEG，我首先尝试将其解压缩。 JPEG不在乎图像数据结尾之后的内容，而Zip将其目录存储在文件末尾并从那里向后工作。如果将JPEG和Zip串联在一起，则一切正常。

那只动物不是鱼，它是裸bra科动物的一种，是海洋软体动物的一种。

#1 楼

正如其他评论者所提到的，该文件包含来自Nikon Picture Project的数据。如果您无法运行该软件，但仍想知道隐藏在里面的软件怎么办？

Nikon的Picture Project格式似乎是完全没有文档记录的，这并不奇怪，因为它是一种自定义格式特定的应用，并且从未设计用于互换。也就是说，该格式似乎非常简单，可以通过检查嵌入在二进制文件中的APP10块（FF EA标签）来辨别。我使用Hachoir（一种通用文件分析工具）通过以下代码查看了这些块：

from hachoir.parser.image.jpeg import JpegFile
from hachoir.stream import FileInputStream
import struct

p = JpegFile(FileInputStream('20200519221417!Goniobranchus_aureomarginatus_2.jpg'))
for i in p.array('chunk'):
    print(i['data'].value[:100].hex())

只需排列所有这样的块，就立即看到模式：

4e696b6f6e20496d61676520496e666f000200000001f00000618396ffd8ffdb0084000101010101010101010101010101010201010101010202020102020202020202020202030303020303030202030403030304040404020304040404040304040401
4e696b6f6e20496d61676520496e666f000200000002f000bdcc1b6d3b9c535cb2bf520b2bff00340964d84ab6dc03cb7bf3c8ce6bd5bc1fae18562188d5e194bb9597040e36820f5e99e4f7fad7979b41bfebe67a5867785cf6e1e30c5b6e92621d8ef6
4e696b6f6e20496d61676520496e666f000200000003f000e0753fe7debf986355e1d34cfea696b17639dfb088ae1434600070a0fe7c57456f6931450a62507e47431072c3af04e3079af2b1152cf9bab65538dd5999b77a32f9991103d4739ce49e7eb5
4e696b6f6e20496d61676520496e666f000200000004f0000948036296da18e4e78e2bd98d292a577bbfebf1382b452bdcd28ef448cd8904a91a95f2cae368ee73d4fad4134b0ac68e082cd2336d033839ea7fbd9cf35c9384bda5dbd422a37b1fffd3fc
4e696b6f6e20496d61676520496e666f000200000005f000aa47dbc746ce9c2569c612aab7b9ffd3fcc2d67c0bf1b3e2d7c42bff00106972b695e0fd1ef46a1e25d7a4dc16360f84b7deea57730380b9dd5f6b7876730e8b6d664bce2c20581e590e7715
4e696b6f6e20496d61676520496e666f000200000006f000a0aa5a99ffd1fc2e5bb3ba2937c46471fc07210e73f89ae82c6e0163299631b8e58e793827afeb5fcc74aa3a57b1fd758cf7a3a1e8fa19230102b051921864306e7b9f7af54b1558e18dc310
4e696b6f6e20496d61676520496e666f000200000007f0009ddd707f957e974e7f5887b56f563a10743961d57e274be1ed7fed266b4b53219236659f703b78273863c139eb8ef5da695aba5a6b3610ddc2f3594ab219f6b0c162328727d0f6ef5e0d6c23
4e696b6f6e20496d61676520496e666f000200000008f000375ab993f790cd188651874393939cee0dd7a6411f4ae7478836811db4eac9972c4e41f94fcc416e5b9e01afa4861a528b99e34a6a261ea1e2268edc012399d0923692d9dc4920fe679ae12f
4e696b6f6e20496d61676520496e666f000200000009f000cd6fc7e6ee6de32bf75492727be7f0e6bf8be10536dbef73fb25c6317643f50958d9b9190318720124d73ba5c71c97af15e42df67b88c46252721893cf07ebfcfd2b2745467ccf7b9e950925
4e696b6f6e20496d61676520496e666f00020000000af000b0f9659df1b0f5c903a9c73f98aee03c5344b0c368bf31cf981f25f3fdecd44b1156524e5b1e156a692777a9c77882e65b547b60db6220b9dbd171ea7b579aa91a8de189519b24072b260e72
4e696b6f6e20496d61676520496e666f00020000000bf000d4fceeb5d124f262789d622cfb08924cf24e7a1e6bad8b462234ce245fe251b8063cf39afe48c5d48ceab6fccfe9ba5074e96a6c59db3c0ca8f1b850a18b2938662581e7f0fd6ba9b5b958fe
...
4e696b6f6e20496d61676520496e666f000200000068f0001acec0e2a791b919b9d91fffd6c432c611ce79c71594cf1cb202d8241af9849ec7b37b97ed648e59d60de067a8cd67f8816350d120048ef4a707a32a9cd5ec729a4de8d1b53576190c7a1af4
4e696b6f6e20496d61676520496e666f00020000006903960f515ce93b9d6e57d0cfbb94953c74eb58372df31e7f0ae983b239ea22a32a95e4d4ba7a057c139ad5dec713dcffd7f8f6f13692cc7807818a8609c4732b7615e7ad51dcb73a55bd82e60f9c
4e696b6f6e20496d61676520496e666f00030000000100000bbb0bbb40a9867a1be9d211a90a00aa00b1c1b70200a90b00000032a476a217d411a90a00aa00b1c1b70100050000000161512be4df5dd211a90a00aa00b1c1b7020005000000000132a476

我们可以看到有一个固定的标头（4e696b6f6e20496d61676520496e666f：ASCII中的Nikon Image Info），后面跟着0002或0003，这似乎是一个递增的数字（从00000001开始，到00000069结束），最后是某种长度字段（除了最后两个块，分别具有f000和0396的大多数块，使用0000）。之后，它看起来像数据。

所以，我猜标题是这样的：

uint16_t chunktype;
uint16_t unknown; /* always zero */
uint16_t serial;
uint16_t datasize;
uint8_t payload[];

，然后转储所有有效负载文件的位：

out = open('dump.bin', 'wb')
for i in p.array('chunk'):
    data = i['data'].value
    magic, ctype, unknown, serial, size = struct.unpack('>16sHHHH', data[:24])
    print(magic, ctype, serial, size, len(data[24:]))
    chunk = data[24:24+size]
    out.write(chunk)

生成的文件以四个字节00 61 83 96（0x618396）开头，该字节与数据的总长度匹配（0x618396 = 6390678字节）。接下来是FF D8 FF DB，这是JPEG的开头，因此，剥离长度字段会显示4032x3024 JPEG。这大概是相机的原始照片。这是经过调整大小以适合上传限制的照片：

前往Hachoir的旅程显示JPEG在结构上是相当正常的，但是已删除了所有元数据。奇怪的是，Hachoir还显示它在5742120字节之后结束。结束后转储数据会显示出第二个JPEG，大小为1920x1440：

可悲的是，这并不是一些令人兴奋的间谍工作，它只是原始图片的另一个版本，但尺寸有所缩小。不过，它仍然比实际裁剪的照片数据大得多！这次没有任何内容了，因此我们从文件中提取了所有图像。

剩下的就是最后一块数据，它的长度为3008字节。该块似乎包含实际的图片项目信息，大概包括编辑的历史记录，详细的编辑信息等。该格式更加不规则，尽管我认识到很多双精度浮点数以及一些看起来像幻数（65 D4 11 D1 91 94 44 45 53 54）。经过更多的工作，应该也可以对这些块进行反向工程-但隐匿在这里似乎没有任何有趣的隐瞒:)

#2 楼

简短答案：这是Nikon Picture Project的产物。

我很难找到“ Nikon Picture Project”，但最终找到了1.5版本尝试。最终生成的版本是1.7.6。

事实证明，“ Nikon Picture Project”确实实现了具有撤消和版本控制功能的非破坏性编辑。与我见过的所有其他照片编辑软件不同，它是通过直接更改JPG文件结构并将编辑控件和版本直接嵌入JPG来实现的。该软件中有一个Export JPEG功能，可以展平和删除历史记录，但是看起来像是贴了原生的JPG，而不是使用export。

我加载了您的第一张参考图像（在此处调整大小）

。

果然，“尼康图片计划”将其显示为更大图片的编辑和裁剪（在此处调整大小）

。

检查文件之前和之后的结构可以验证奇怪的工件。

谢谢您！ br

喔，不错！看起来我可以分离出同一张图片，但未被认为是功能齐全的JPEG图片。关于为什么这可能与标准JPEG不同的任何见解？

– Esa Jokinen
20年5月19日在19:58

@EsaJokinen Wild是我的猜测，但是鉴于它们将多个相似的图像存储在一个文件中，我想知道是否正在进行一些自定义压缩-存储要重新组合的部分图像（例如带有关键帧和增量的视频编解码器）还是只是检测多个版本中数据的相似部分。

–IMSoP
20 May 19'20:39

Adobe Fireworks对PNG图像也做类似的事情。

–gparyani
20-05-19在22:44

实际的JPEG格式支持许多古怪的模式，并且我可以非常看到在技术标准内这是可能的。我们通常共享的简单图像实际上是更小的JFIF子集，大多数软件都没有实现更多。

–SE-停止解雇好人
20-05-21在14:05

围绕该用户的其他贡献来查看是否还有其他类似的“未展平”图像将是很有趣的。

–曼上尉
20年5月21日在14:45

#3 楼

这没有一开始看起来那么有趣。用户可能只是相机损坏，存储卡损坏或照片编辑软件故障而无法保存完整分辨率的图像，但能够保存各种大小的工作缩略图，包括435×652“原始”图片。 />
示例图片的文件大小由4032×3024像素和5,47 MB JPEG流解释，该流已损坏，并按比例缩小，如下所示：

从FF D8 SOI（图像开始）开始：

，从此处以FF D9 EOI（图像结束）开始：

同一图像还有另一个不同的1920 x 1440缩略图缩略图和该破裂图像的缩略图，但是如果灰色中隐藏了一些有趣的东西，则介于006A4F和5812A2。但是，我不会打赌。

我为摄影师感到抱歉。这些都是好照片，但由于设备损坏而毁了。：'（

– Esa Jokinen
20年5月18日在16:15

这里还有很多怪异之处。最初，exif表示奥林巴斯E-Pl1。继续介绍奥林巴斯镜头和设置。然后，它突然有了Nikon档案和Apple Computer的主要平台。从6A2F开始的十六进制文件结构中，有一个标有“ Nikon Image Info”的标签。此后还有105个“ Nikon Image Info”块。这似乎不是可能的故障机制。这很有趣，但是我没有很好的答案。

–user10216038
20 May 18 '23：16

看起来图像可能已经在Apple上使用“ Nikon Picture Project”进行了编辑。我不熟悉Picture Project，但是我想知道它是否在文件中保存了多个撤消操作吗？

–user10216038
20年5月18日在23:54

相机或软件可能有问题，但是由于同一用户有多个类似的损坏图像，因此某些系统故障很严重。元数据可能相关，也可能不相关，并且不会单独说明文件大小。我在编辑中对此做了澄清。不过，尼康图片项目是一个不错的选择！

– Esa Jokinen
20-05-19在6:42

我确实尝试了字符串，并在文件中看到大量“ Nikon Image Info”字符串...我以为这是Olympus授权的Nikon固件...但是，我没有任何证据，并在dpreview的照片上尝试了字符串。 com / reviews / olympusepl1 / 9根本没有显示尼康字符串，因此，如果有的话，编辑软件似乎很可能。

–大卫
20-05-19在7:29

#4 楼

它没有损坏，只是充满了APP10段，其中包含某种特定于应用程序的数据。可能是特定于尼康的，因为开始时APP1 / EXIF段中有尼康参考。在大约6 MB的APP10段之后，有103,001字节的实际JPEG图像数据。但是所有分段标记都在正确的位置，这意味着它们会在有效载荷长度之后显示，因此它似乎是带有6 MB尼康特定数据的有效图像：

Byte 0x00000000 (0): marker 0xD8 found: SOI (Start Of Image)

Byte 0x00000002 (2): marker 0xE1 found: APP1 (EXIF data)
        Payload length: 18523 bytes

Byte 0x00004861 (18529): marker 0xE2 found: APP2 (ICC profile)
        Payload length: 8650 bytes

Byte 0x00006A2F (27183): marker 0xEA found: APP10 (Application marker 10)
        Payload length: 61468 bytes

Byte 0x00015A4F (88655): marker 0xEA found: APP10 (Application marker 10)
        Payload length: 61464 bytes

Byte 0x00024A6B (150123): marker 0xEA found: APP10 (Application marker 10)
        Payload length: 61464 bytes

(... this goes on and on, 6 MB of APP10 segments...)

Byte 0x00610577 (6358391): marker 0xEA found: APP10 (Application marker 10)
        Payload length: 61464 bytes

Byte 0x0061F593 (6419859): marker 0xEA found: APP10 (Application marker 10)
        Payload length: 942 bytes

Byte 0x0061F945 (6420805): marker 0xEA found: APP10 (Application marker 10)
        Payload length: 3032 bytes

Byte 0x00620521 (6423841): marker 0xDB found: DQT (Define Quantization Table)
        Payload length: 130 bytes

Byte 0x006205A7 (6423975): marker 0xC4 found: DHT (Define Huffman Table)
        Payload length: 168 bytes

Byte 0x00620653 (6424147): marker 0xC0 found: SOF0 (Start Of Frame (Baseline DCT))
        Payload length: 15 bytes

Byte 0x00620666 (6424166): marker 0xDA found: SOS (Start Of Scan)
        Reading image data... 103001 bytes read.

Byte 0x006398C1 (6527169): marker 0xD9 found: EOI (End Of Image)

尽管这很有趣，但是昨天已经在评论中发布了类似信息，并且在3小时前发布的答案中发现了这些块的含义。

–IMSoP
20-05-19在20:34

好吧，那个评论者说：“这里还有很多怪异之处。”我要指出的是根本没有怪异。文件结构非常清晰。虽然很高兴他发现该文件属于“ Nikon Picture Project”，但仍然没有解释为什么文件为6 MB。这不是SE的“摄影”部分，而是“信息安全/取证”部分。人们想更深入地挖掘。我仍然没有显示为什么它是6 MB，但是至少我正在显示文件结构的概述，并且EXIF文件在技术上是有效的。

–格尔本
20-05-19在20:48

是的，但是在该评论和您的答案之间，发布了另一个答案（当前被接受，分数为32），并准确解释了额外数据包含的内容。您的答案似乎是这两者之间的一条线索，但迟到了3个小时。就像我说的那样，尽管还是如此，但是如果您解释了使用什么工具来获取此信息的话，会更有趣。

–IMSoP
20年5月19日在20:50

这个答案解释了为什么文件如此之大，以及“额外信息”如何以符合标准的方式存储在文件中。公认的答案是，这样做的原因和原因远不那么有趣。

– JCRM
20-5-20在1:38

@JCRM许多文件格式都是可扩展的容器，我知道JPEG是一种，因为它们可以包含多种类型的元数据，嵌入的缩略图等。所以“怎么做”并没有让我特别惊讶。不过，在接受的答案中多一些技术细节会很好。

–IMSoP
20年5月20日在7:01

编程黑洞网

为什么此435×652像素JPEG超过6 MB？

评论

#1 楼

#2 楼

评论

#3 楼

评论

#4 楼

评论