JPEGのExif情報をとっかかりにバイナリデータと戯れる

こんにちは。
開発チームのワイルド担当、まんだいです。

先日、スマートフォンの画像があさっての方を向くという怪奇現象に遭遇した際、Exif情報について色々調べた訳ですが、その過程でExif情報のバイナリが読めるようになったので、Exif情報の構成を解説したいと思います。

また、その過程を通じて、バイナリデータってチョロいんだという事を知ってもらえたらといいなと思っています。

 

Exif解析に使うもの

Exifの解析に使ったものは、インターネットで手に入ります。
以下の3つがあれば、Exif情報を読取る事は可能です。

まずは、規格の情報。
一般社団法人 電子情報技術産業協会の資料を完璧に理解できれば、余裕なのでしょうが、中々難解な書物なので、エクセルなんかを使って、一つ一つ確認していきました。

バイナリデータの参照には、Stirlingというソフトウェアを利用しました。
既にメンテナンスは終了しているようですが、この分野においてこれを超えるツールは、まだ見かけないくらい、良い作りです。

Linux環境の場合、バイナリデータを表示するコマンドとして、odというコマンドがあるので、od -x [path]で、だいたい同じようなものを見ることが出来ます。
この場合は、ダンプリストがズラーッと流れてしまうので、適宜headコマンド、tailコマンド、grepコマンドを駆使して、見たい部分だけ表示するようにします。

Exifが採用されている画像フォーマットは、JPEG、TIFF、JPEG XRとなっています。
これらのファイルには、Exifが登録されている事が多いため、サンプルはどこにでもありますね。
適当にスマートフォンで撮った写真を取り込んでみましょう。

 

バイナリ情報を読み解いてみる

バイナリデータは、テキスト情報ではなく、拡張子に表されるフォーマットに則ったデータの集合ですから、出だしの部分から、JPEGデータのフォーマットに沿ったデータの並び方をしています。

手元にあったJPEGファイルの先頭部分を抜き出してみました。

 
JPEGファイルは、必ず「FF D8」という2バイトのデータから始まります。
JPEG業界では、SOIと呼ばれる特殊な領域で、ここからしばらく、画像のメタデータを保存する領域が続きます。

メタデータとは、画像データ以外に保持しているデータの事で、Exif情報もこの中に含まれます。
このデータは必須項目と、それ以外の撮影した機器や、編集したアプリケーションが独自に付与できるデータに分けられます。

続くデータは「FF E1」で、これは、APP1アプリケーションセグメントというメタデータのセグメントの開始を表します。
これは可変長のデータなので、続く2バイトに、APP1アプリケーションセグメントのデータ長が格納されています。
データの長さは「6C0F」バイトなので、APP1アプリケーションセグメントのデータは、6C13アドレスまでになります。

続きデータは「45 78 69 66 00 00」で、これはExif情報の有無を示しています。
今回のデータは存在するようです。

ここまでがAPP1セグメント全体に関わる情報になります。

ここから先は、付属情報で必須ではありません。

続きのデータを抜き出してみましょう。

 
まず始まるのは、TIFFヘッダで、バイトオーダー、TIFFバージョン、0th IFDの開始位置までのオフセット情報がここで表されています。
バイトオーダーは、今回は「49 49」でリトルエンディアンでデータが並んでいる事を表します。
ビッグエンディアンの場合は「4D 4D」となります。
以降、リトルエンディアン、ビッグエンディアンの違いで、各情報の並び順が逆になりますので、Apple製品で撮影した写真がお手元にある場合は、ビッグエンディアンなので、注意が必要です。
バイトオーダーという言葉の説明は、Wikipediaが詳しいかなと思います。
また、このデータの開始位置がこの先に出てくるデータアドレスのオフセットの基準位置になりますので、割と重要なポジションです。

その次がTIFFバージョンで、「2A 00」となっています。

続いて、0th IFDというものが出てきます。IFDは、Image File Directoryの略で、付属情報のまとまりを表します。
一つのIFDの中に、幾つかのタグがまとめられているというイメージです。
データの種類によって、IFDが分けられています。

IFD内のデータはタグ毎に分けられていて、それぞれのタグは12バイトの長さと決まっています。
IFDのデータ構造は以下のようになっています。

• 「タグ数」は、0th IFD内に何個のタグがあるかを表します。
• 「1st IFDへのオフセット値」は、続くIFD（0th IFDの場合は1st IFD、1st IFDの場合は2nd IFD）が始まるアドレスまでのオフセット値になります。(ここが0の場合は、次のIFDはないという意味になります)
• 「0th IFD内の値」は、各タグに割り当てられたバイト数で収まらないデータが入ります。（構造の仕組みは後ほど）

各タグの構成は以下のようになっています。

• 「タグ番号」は、結構な種類があって、列挙しきれません。仕様書のこの辺りから始まるのを、照らし合わせていくのが、一番確実かと思いますが、結構やってられない感もあるので、Exifの取得に関係あるものは都度紹介していきます。
• 「タイプ」は、データ型です。型付けがある言語でのプログラミングを経験された方にはよく分かる、あれです。8種類しかないので、後ほどご紹介します。
• 「カウント」は、タグ内に何個のデータが収められているかを表します。
• 「値までのオフセット値」は、4バイトよりも大きいデータの場合、この中には入らない為、別途可変領域を割り当てて値を入れるようにする仕組みのため、そのデータへの場所へのオフセット値になります。例外があって、4バイト以下のデータはこのオフセット値用の部分にデータを入れてしまいます。

タイプを一覧にしてみました。
タイプによって、カウントの取り方が違うので、合わせて記載しました。

表だけ見ても、イメージは沸かないと思うので、データを見ながら一つずつ見ていきましょう。

 

IFDを読んでみる

実際の写真データから、0th IFDの部分を抜き出してみました。

 
こちらのテーブルを頼りに、まずは先頭の2バイトを抜き出します。
「0B 00」の部分は、0th IFDに何個のタグが含まれているかを表す部分です。
このデータのバイトオーダーはリトルエンディアンなので、人間が読む場合は、0x000Bとなります。
つまり、11ですね。
なので、0th IFDには、11個のタグが含まれている、という事になります。

1つのタグは12バイトの固まりなので、12*11=132バイトがタグデータです。

タグを固まりごとに抜き出してみましょう。

 
タグを要素ごとに切り出して、表にしてみます。
ついでに、タグ番号が何を表しているかを仕様書から調べて追記しています。

実際の値の取り方ですが、これにはパターンがあって、タイプがBYTE、SHORT、LONG、SLONGの場合、カウントが1の場合はオフセット部分に値が入っています。
ASCII、UNDEFINEDの場合も、カウントが4以下の場合はオフセット部分に値が入っています。

それ以外の場合は、ここを基準に、データのアドレスを計算してタイプとカウントの分だけ、データを取得します。
取得した結果が以下のようになります。

となっています。私の携帯の機種がバレた訳ですが、たかがjpeg画像といえど、この程度の情報は簡単に取り出せるということですね。

では、Exif IFDの場所が分かったところで、本題のExif情報を見てみましょう。

 

Exif情報を読んでみる

手順は、0th IFDと全く同じです。Exif情報部分のバイナリを抜き出してみましょう。

 

この後、GPS情報と続く訳ですが、GPS情報に至っては、どこで撮ったかすぐに分かってしまう訳です。
旅行先の写真などの場合は、撮った写真を地図上に表示したりすると面白いでしょうが、自宅で撮った写真がそうであると困ります。

Exif情報が無事読めて良かったなという達成感でいっぱいですが、PHPなら、read_exif_data関数で上記のデータは簡単に手に入ります。
手元にバイナリエディタとExif資料しかない場合に、この記事が参考になれば幸いです。

 
以上です。