使用
exiftool -a -b -W %d%f_%t%-c.%s -u -g1 -ee -api RequestAll=3 temp.jpg
总共提取<650 kiB的东西。
有什么策略或工具可以用来发现正在发生的事情,以及文件中是否隐藏了某些东西?
如果它使事情变得更容易,相同或非常相似的包含似乎会影响同一Flickr用户的多个文件:2,3,4,5
#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
评论
您要查找的术语是“隐写术”。@schroeder我本来以为隐写方法不会尝试将其有效载荷放在单独的斑点中...我所见过的方法似乎都在操纵像素颜色,不会显着增加图像大小,但是我没有看了十多年了。这似乎更类似于将GIF附加到ZIP上,从而使文件符合两个规范。那真的是隐写术吗?
隐写术是隐藏数据的任何方法。 JPEG不存储“像素”,但是可以以相同的方式从某些参考图像中提取少量的不同量子。追加数据也是隐写术。
对于JPEG,我首先尝试将其解压缩。 JPEG不在乎图像数据结尾之后的内容,而Zip将其目录存储在文件末尾并从那里向后工作。如果将JPEG和Zip串联在一起,则一切正常。
那只动物不是鱼,它是裸bra科动物的一种,是海洋软体动物的一种。