这是在看到这个问题之后有人有用地修复它之前,这是一张相对不张扬且很小的̶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),后面跟着00020003,这似乎是一个递增的数字(从00000001开始,到00000069结束),最后是某种长度字段(除了最后两个块,分别具有f0000396的大多数块,使用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缩略图缩略图和该破裂图像的缩略图,但是如果灰色中隐藏了一些有趣的东西,则介于006A4F5812A2。但是,我不会打赌。

评论


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

– 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