Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1081
  • Last Modified:

Interpret binary file for Exif project

Hello,
I am working on a C# project to process some jpg images using the exif data.  I have many questions, but my first is simply interpreting the binary file using a hex editor.  The exif format specifies the DateTimeOriginal at 0x9003.  When I open the binary file in a hex editor, I see column headings and row identiers that I don't know how to interpret.  Essentially, I'm trying to understand how to look at the hex editor, find 0x9003 and see the DateTimeOriginal for the jpg.  I know the text is on the right, but I'm really trying to "learn" here.  Can someone guide me as to how to interpret the binary file?  I have attached an image of a hex editor with a loaded binary image (jpg) file.
hexEditorWithJpg.jpg
0
chrisog
Asked:
chrisog
  • 4
  • 2
1 Solution
 
gemailjCommented:
this a very complete data how to read and write image metadata using the .net
you need not to read the binary data manually

http://www.vsj.co.uk/dotnet/display.asp?id=649
0
 
chrisogAuthor Commented:
gemailj,
Thanks for your comment, but I'm really trying to understand how to interpret a binary file as part of this project.  For example, if the DateTimeOriginal is at address 0x9003, I thought I'd see it in the binary file, but I don't (I must be interpreting the file incorrectly).  When I load the file into a Exif viewer, I see the appropriate DateTimeOriginal, ...so I must be interpreting the file wrong when looking in the Hex editor.
0
 
DanRollinsCommented:
OK, i found the EXIF spec here:
   http://www.exif.org/dcf-exif.PDF
It's pretty standard techno gobblety-gook.   The key is on page 17-18which shows the tag format  and the list of tags on page 21.
xx xx   -- tag
xx xx  -- type
xx xx xx xx -- count
xx xx xx xx -- offset of the data
A tag value 0x0132 means "file change date and time"
Loking at your hex dump, I see such a value at offset 005Eh
005Eh: 32 01   (tag value: 132h)
0060h: 02 00   (type -- 02 = ASCII)
0062h: 14 00 00 00 (count  -- for type 02 ASCI, length in bytes 14h - 20 in decimal
0066h: B0 00 00 00 (offset is 000000B0h)
Now looking further down, we see that the ASCII data we want is actually at 00BCh
Looking back on page 13, I see that the file data is considered to start at the
    II
that is att offset 000Ch (apparantly the first 12 bytes are used to hold the Exif file signature).
Therefore the offset value of a tag really indicates an offset from 000Ch.  So, add that (12 decimal) to the value in any tag data offset value and you will have the actual offset to within the file

-- Dan


 
0
Get your Conversational Ransomware Defense e‑book

This e-book gives you an insight into the ransomware threat and reviews the fundamentals of top-notch ransomware preparedness and recovery. To help you protect yourself and your organization. The initial infection may be inevitable, so the best protection is to be fully prepared.

 
chrisogAuthor Commented:
Dan,
Thanks, I think I'm beginning to understand.  So, based on your feedback, when looking at the hex values for Tags, Types, Count, and Offset, you read the "LEFT-TO-RIGHT" huh?  For example, you said:

005Eh: 32 01   (tag value: 132h)
0060h: 02 00   (type -- 02 = ASCII)
0062h: 14 00 00 00 (count  -- for type 02 ASCI, length in bytes 14h - 20 in decimal
0066h: B0 00 00 00 (offset is 000000B0h)

I now see that the tag is "132h" not "3201h" as I had initially interpreted.  So, I guess all hex values  of "n" bytes are read from left to right, just like the values themselves (I guess this makes sense, but not as I initially interpreted).  This is confirmed, I guess, by the actual values themselves (when shown in decimal or ASCII on the right side of the editor) being readable from left to right.

I'm a little confused by the offset you point out on page 13.  you say page 13 says the file data is consered to start at the "II".  I don't understand this.  From the "II", you deduce an offset of 000Ch (12 decminal or the 13th bye).  How do you get 00Ch from the "II"?  I included an image of the Table I think you are referring to from the specification.

Finally, I'm learning at "tag" is not an address or offset in the file, ...its just a "tag" that resides at some address in the file.  One would have to stream through the file to find a tag, lookup the offset, calculate the absolute offset using the relative offset value ("II") specified in the file, then go to the absolute offset address, and read the value (in my case a date).

Final question, Dan, what is the best zone to post Exif and Hex questions like this in as I had a hard time getting a response.
 
specTable.jpg
0
 
chrisogAuthor Commented:
Dan,
Sorry I'm being confusing, ...I meant to say that I now understand Tags, Types, Counts and Offsets bytes are read from Right to Left, not Left to Right.  In contrast, actual values (as in the DateTimeOriginal) are read Left to right.  
0
 
DanRollinsCommented:
The II that i mention is in the top-left corner of your original screenshot. It means that this is a "little endian" variation -- the data works as with all Intel processors.  The byte at the pointer's location is the least significant byte.   Whether it is read as a single byte, a 16-bit word, or a 32-bit DWORD, the first byte is the low value..
When reading these programmatically, you set a pointer to the start of the data, and read it into the correct-sized variable. The "endian-ness" is then irrelevant.  It only comes into play when eye-balling hex dumps :-)
Let's say that the file is in a buffer named abBuf. A value that you need can be found 0x66h from the start of the buffer.
BYTE abBuf[10000];
... read the entire file into abBuf...
BYTE* pb= &abBuf[0x66]; // get an address for a byte
DWORD* pdw= (DWORD*) pb; // get the address of a DWORD (they are the same)
DWORD nValue= *pdw; // get the 4-byte value
Now if you look at the nValue variable, the bytes have been interpretted correctly.
0
 
chrisogAuthor Commented:
Dan was most helpful and thorough.  Thank you very much Dane!
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now