web-dev-qa-db-ja.com

この435×652ピクセルのJPEGが6 MBを超えるのはなぜですか？

これは 、この質問を見て誰かが問題を修正する前に、283,620ピクセルのaf̶i̶s̶h̶ウミウシの比較的気取らない小さな写真。いくつかのメタデータがあります。テキストのExifタグと8.6kBのカラープロファイル情報、5,557バイトのサムネイルと648,534バイトのプレビュー画像（私は読めません）およびその他のランダムなもの（顔検出領域など）です。スペースを取らない。

使用する

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

合計<650kiBのものを抽出します。

何が起こっているのか、そして何かがファイルに隠されているかどうかを発見するために使用できる戦略やツールはありますか？

物事を簡単にする場合、同じまたは非常に類似したインクルードが同じFlickrユーザーによる複数のファイルに影響を与えるように見えます： 2 、、 4 、 5

forensicsobfuscationsteganography
100
David

他のコメント者 言及した と同様に、ファイルには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を持つ最後の2つのチャンクを除くほとんどのチャンクの場合は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)

結果のファイルは、データの全長（0x618396 = 6390678バイト）と一致する4バイト00 61 83 96（0x618396）で始まります。次はJPEGの始まりであるFF D8 FF DBなので、長さフィールドを取り除くと、4032x3024 JPEGがわかります。これはおそらくカメラからの元の写真です。アップロード制限内に収まるようにサイズ変更された写真は次のとおりです。

first image - 4032x3024

Hachoirに行ってみると、JPEGの構造はごく普通ですが、すべてのメタデータが取り除かれています。不思議なことに、Hachoirは5742120バイトで終了することも示しています。終了後にデータをダンプすると、秒JPEG、サイズ1920x1440がわかります。

second image - 1920x1440

悲しいことに、それはいくつかのエキサイティングなスパイのものではなく、元の画像の単なる別のバージョンですが、多少縮小されています。ただし、実際のトリミングされた写真データよりもはるかに大きくなります。今回は最後に何もないので、ファイルからすべての画像を抽出しました。

残っているのは、データの最後のチャンクで、長さは3008バイトです。このチャンクには、おそらく編集の履歴や詳細な編集情報などを含む実際の画像プロジェクト情報が含まれているようです。フォーマットはかなり不規則ですが、倍精度浮動小数点数や、マジックナンバー（65 D4 11 D1 91 94 44 45 53 54）。もう少し作業を行うと、これらのチャンクもリバースエンジニアリングすることができるはずです。ただし、ここではステガノグラフィック的に興味深いものは何も表示されていません。

26
nneonneo

短い答え：Nikon Picture Projectのアーティファクトです

「ニコンピクチャープロジェクト」を見つけるのに苦労しましたが、ようやく1.5バージョンが見つかりました。生成された最後のバージョンは1.7.6でした。

「Nikon Picture Project」は、元に戻す機能とバージョン管理機能を備えた非破壊編集を実際に実装していることがわかりました。これまでに見た他のすべての写真編集ソフトウェアとは異なり、JPGファイルの構造を直接変更し、編集コントロールとバージョンをJPGに直接埋め込むことでこれを実現します。ソフトウェアにはExport JPEG機能があり、履歴を平坦化して削除しますが、エクスポートを使用する代わりにネイティブの変更されたJPGが投稿されたようです。

最初の参照画像をロードしました（ここでサイズ変更）

Reference 。

案の定、「ニコンピクチャープロジェクト」はそれをより大きな画像の編集とトリミングとして示しました（ここでサイズ変更）

Original 。

前後のファイル構造を確認すると、奇妙なアーティファクトが確認されます。

パズルをありがとう！ ????

157
user10216038

これは最初に思われたよりも面白くなかった。ユーザーは、カメラやメモリカードが壊れているか、写真編集ソフトウェアが故障していて、フル解像度の画像を保存できないが、435×652の「元の」画像など、さまざまなサイズの作業用サムネイルを保存できる場合があります。

サンプル画像のファイルサイズは、4032×3024ピクセルと5,47 MB​​のJPEGストリームで説明されており、分割されて縮小されているため、次のようになります。

Broken image scaled down

FF D8 SOI（イメージの開始））で始まります：

Start Of Image from HxD

そして、ここでFF D9 EOI（画像の終わり）で終わります：

End Of Image from HxD

同じ画像の別の壊れた1920×1440サムネイルとこの壊れた画像のサムネイルもありますが、灰色に何か面白いものが隠されている場合は、006A4Fと5812A2の間です。しかし、私はそれに賭けません。

45
Esa Jokinen

破損しておらず、APP10セグメントで満たされているだけで、アプリケーション固有のデータが含まれています。最初はAPP1/EXIFセグメントにNikon参照があるため、Nikon固有の可能性があります。そして約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)
17
Gerben