Playing with binary data using JPEG Exif information as a starting point

Hello.
I'm Mandai, in charge of Wild on the development team.

The other day, a strange phenomenon in which the images on my smartphone were facing in the direction of tomorrow , I did a lot of research on Exif information, and in the process I was able to read the binary Exif information, so I will explain the structure of Exif information. I would like to.

hope that

  through this process, people will learn that binary data is trivial

What to use for Exif analysis

The tools used for Exif analysis are available on the Internet.
If you have the following three things, it is possible to read Exif information.

First, information on the standards.
the materials provided by the Japan Electronics and Information Technology Industries Association , I would be fine, but since the book was rather difficult to understand, I used Excel to go over each one one by one.

I used a software called
Stirling to reference the binary data It seems that maintenance has already ended, but it is so well made that I have yet to see a better tool in this field.

In the Linux environment, there is a command called od to display binary data, so you can see something similar with od -x [path].
In this case, the dump list will flow slowly, so use the head command, tail command, and grep command as appropriate to display only the parts you want to see.

Image formats that use Exif are JPEG, TIFF, and JPEG XR.
These files often have Exif registered, so samples can be found everywhere.
Let's import a random photo taken with a smartphone.

 

Try to decipher binary information

Binary data is not text information, but a collection of data that conforms to the format indicated by the extension, so from the beginning, the data is arranged in accordance with the JPEG data format.

I tried extracting the beginning part of the JPEG file I had.

FF D8 FF E1 6C 0F 45 78 69 66 00 00 49 49

 JPEG files always start with the 2-byte data "FF D8".
In the JPEG industry, this is a special area called SOI, which will continue to be an area for storing image metadata for some time.

Metadata is data held in addition to image data, and includes Exif information.
This data is divided into required items and other data that can be added independently by the device that took the image or the application that edited it.

The following data is "FF E1", which represents the start of a segment of metadata called the APP1 application segment.
Since this is variable length data, the following 2 bytes contain the data length of the APP1 application segment.
Since the data length is "6C0F" bytes, the data of the APP1 application segment will be up to the 6C13 address.

The continuation data is "45 78 69 66 00 00", which indicates the presence or absence of Exif information.
It seems that this data exists.

The information up to this point is related to the entire APP1 segment.

The information from here on is optional and is not required.

Let's extract the following data.

49 49 2A 00 08 00 00 00

 It starts with the TIFF header, which contains the byte order, TIFF version, and offset to the start of the 0th IFD.
The byte order is "49 49" this time, indicating that the data is arranged in little endian.
In the case of big endian, it is "4D 4D".
From now on, the order of each information will be reversed due to the difference between little endian and big endian, so if you have a photo taken with an Apple product, please be careful because it is big endian.
I think
Wikipedia explanation of the word byte order becomes the reference position for the offset of the data address that will appear after this

Next is the TIFF version, which is "2A 00".

Next, something called 0th IFD comes out. IFD is an abbreviation for Image File Directory and represents a collection of attached information.
The image is that several tags are grouped together in one IFD.
IFD is divided according to the type of data.

The data in the IFD is divided into tags, and each tag is 12 bytes long.
The IFD data structure is as follows.

• "Number of tags" represents how many tags are in the 0th IFD.
• "Offset value to 1st IFD" is the offset value to the address where the following IFD (1st IFD in case of 0th IFD, 2nd IFD in case of 1st IFD) starts. (If this is 0, it means there is no next IFD)
• "Value in 0th IFD" contains data that does not fit in the number of bytes allocated to each tag. (More on the structure later)

The structure of each tag is as follows.

• There are so many types of "tag numbers" that it is impossible to list them all. this part of the specifications , but I feel like it's not very easy to do, so I'll introduce things that are related to Exif acquisition each time.
• "Type" is the data type. This is something that anyone who has experience programming in a typed language will understand. There are only 8 types, so I will introduce them later.
• "Count" indicates how many pieces of data are contained within the tag.
• "Offset value to value" does not fit in the case of data larger than 4 bytes, so a variable area is allocated separately and the value is stored, so the offset value to the location of the data is value. There is an exception, and data of less than 4 bytes will be stored in this offset value section.

I made a list of types.
The counting method differs depending on the type, so I have listed them together.

I don't think you can get a good idea just by looking at the table, so let's look at the data one by one.

 

Read the IFD

I extracted the 0th IFD part from the actual photo data.

0B 00 0F 01 02 00 05 00 00 00 92 00 00 00 10 01 02 00 07 00 00 00 98 00 00 00 12 01 03 00 01 00 00 00 01 00 00 00 1A 01 05 00 01 00 00 00 A0 00 00 00 1B 01 05 00 01 00 00 00 A8 00 00 00 28 01 03 00 01 00 00 00 02 00 00 00 31 01 02 00 14 00 00 00 B0 00 00 00 32 01 02 00 14 0 0 00 00 C4 00 00 00 13 02 03 00 01 00 00 00 01 00 00 00 69 87 04 00 01 00 00 00 D8 00 00 00 25 88 04 00 01 00 00 00 2C 52 32 52 00 00

 this table , first extract the first two bytes.
The "0B 00" part indicates how many tags are included in the 0th IFD.
The byte order of this data is little endian, so when read by a human it will be 0x000B.
In other words, it's 11.
Therefore, 0th IFD contains 11 tags.

One tag is a 12-byte block, so 12*11=132 bytes is tag data.

Let's extract the tags in chunks.

0F 01 02 00 05 00 00 00 92 00 00 00 10 01 02 00 07 00 00 00 98 00 00 00 12 01 03 00 01 00 00 00 01 00 00 00 1A 01 05 00 01 00 00 00 A0 00 00 00 1B 01 05 00 01 00 00 00 A8 00 00 00 28 01 03 00 01 00 00 00 02 00 00 00 31 01 02 00 14 00 00 00 B0 00 00 00 32 01 02 00 14 00 00 0 0 C4 00 00 00 13 02 03 00 01 00 00 00 01 00 00 00 69 87 04 00 01 00 00 00 D8 00 00 00 25 88 04 00 01 00 00 00 2C 52 00 00

 Let's cut out the tags into elements and create a table.
I also looked into the specifications to find out what the tag number represents and added it

As for how to actually get the value, there is a pattern: if the type is BYTE, SHORT, LONG, or SLONG, and the count is 1, the value is stored in the offset part.
Even in the case of ASCII and UNDEFINED, if the count is 4 or less, the value is stored in the offset part.

Otherwise, this , calculate the data address and retrieve the data for the type and count.
The obtained result will be as shown below.

It becomes. The model of my cell phone was discovered, but even if it's just a jpeg image, this amount of information can be easily retrieved.

Now that we know where the Exif IFD is, let's take a look at the main topic, the Exif information.

 

Read the Exif information

The procedure is exactly the same as 0th IFD. Let's extract the binary of the Exif information part.

1C 00 9A 82 05 00 01 00 00 00 2E 02 00 00 9D 82 05 00 01 00 00 00 36 02 00 00 27 88 03 00 01 00 00 00 A0 00 00 00 00 90 07 00 04 00 00 00 30 32 32 30 03 90 02 00 14 00 00 00 3E 02 00 00 04 90 02 00 14 00 00 00 52 02 00 00 01 91 07 00 04 00 00 00 01 02 03 00 01 92 0A 00 01 00 00 00 66 02 00 00 04 92 0A 00 01 00 00 00 6E 02 00 00 07 92 03 00 01 00 00 00 05 00 00 00 08 92 03 00 01 00 00 00 00 00 00 00 09 92 03 00 01 00 00 00 10 00 00 00 0A 92 05 00 01 00 00 00 76 02 00 00 7C 92 07 00 70 4F 00 00 7E 02 00 00 90 92 02 00 07 00 00 00 EE 51 00 00 91 92 02 00 07 00 00 00 F6 5 1 00 00 92 92 02 00 07 00 00 00 FE 51 00 00 00 A0 07 00 04 00 00 00 30 31 30 30 01 A0 03 00 01 00 00 00 01 00 00 00 02 A0 04 00 01 00 00 00 60 17 00 00 03 A0 04 00 01 00 00 00 26 0D 00 00 05 A0 04 00 01 00 00 00 0E 52 00 00 01 A4 03 00 01 00 00 00 00 00 00 00 02 A4 03 00 01 00 00 00 00 00 00 00 03 A4 03 00 01 00 00 00 00 00 00 00 00 04 A4 05 00 00 00 00 00 00 006 52 00 006 A4 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 

This is followed by GPS information, which allows you to immediately know where the photo was taken.
It would be interesting to display photos taken on a map when taking photos from a travel destination, but it would be a problem if the photos were taken at home.

I am filled with a sense of accomplishment that I was able to successfully read the Exif information, but in PHP, the above data can be easily obtained using the read_exif_data function.
I hope this article will be helpful if you only have a binary editor and Exif materials at hand.

 
That's it.