Hello all,
We have a 4GB microSD from a Fujifilm AV150 camera where we are asked about the "creation date" of a particular photo named SP_A0038.jpg, however the "creation date" of the is missing(n/a) but there is "modified date" and "acccess date". That is unusual.
Here are the details
Creation date N/A
Modifed date 13.03.2014 11.58.40
Access date 04.04.2014
And when looked at the SP_A0038.jpg for further analysis with exif viewer, the file does not have any exif data either.
There are other photos in the memory card with different naming DSCFXXXXX.jpg and they all have creation dates and exif data.
We have found out that there are other two files with the same naming pattern like SP_A0019 and SP_A0020 and they have samsung C3053 phone in their exif data, so those pictures might have been taken in a samsung mobile phone with that memory card inside the mobile phone, but there should still be creation date.
So, why do you think the photo is missing the creation date?
Thanks
Here are the details
But you omit to state what file system you're looking at.
As far as FAT goes, however
"Many FAT file systems do not support Date/Time other than DIR_WrtTime and DIR_WrtDate. For this reason, DIR_CrtTimeMil, DIR_CrtTime, DIR_CrtDate, and DIR_LstAccDate are actually optional fields. DIR_WrtTime and DIR_WrtDate must be supported, however. If the other date and time fields are not supported, they should be set to 0 on file create and ignored on other file operations."
From the Microsoft fatgen103 specification, p. 25. (Microsoft Extensible Firmware Initiative FAT32 File System Specification FAT General Overview of On-Disk Format.)
There's also an ISO standard patterned on FAT (though the number escapes me). If I remember it correctly, it states that creation date and time fields must be set to zero.
Added It's ISO 9293 / Ecma-107.
Another explanation is that the tool you are using to interpret the timestamp is buggy, and fails to convert the timestamp correctly. However, that should be easy to verify by checking the binary contents of the field.
As it is, you seem to have a hypothesis as to the reason why the creation time stamp may be missing. The obvious thing would be to attempt test that hypothesis.
Thanks for the good details.
The file system is FAT32 and we used FTK 6 for analysis of sdcard. To verify the issue with the date, we used adroit photo forensics. The results match, there is no "created date".
I have never seen such a situation before and still wonder how it might have happened.
@Yunus Instead of testing with another tool why don't you open a hex editor and look for yourself? This would be a great opportunity to verify that your second tool is working, and learn how FAT actually stores date/time information.
WinHex is a good one if you've not done that before, as it's pretty easy to use (in my opinion)
Just find the directory entry for the file (i'm assuming its not deleted / unallocated) and look at the beginning of the file's hex values and find where the Create time is stored and then see if there is a value there. I've included a table that shows the basic data structure for a typical FAT directory entry
Byte Range | Description
0–0 First character of file name in ASCII and allocation status (0xe5 or 0x00 if unallocated)
1–10 Characters 2 to 11 of file name in ASCII
11–11 File Attributes (see Table 10.6)
12–12 Reserved
13–13 Created time (tenths of second)
14–15 Created time (hours, minutes, seconds)
16–17 Created day
18–19 Accessed day
20–21 High 2 bytes of first cluster address (0 for FAT12 and FAT16)
22–23 Written time (hours, minutes, seconds)
24–25 Written day
26–27 Low 2 bytes of first cluster address
28–31 Size of file (0 for directories)
Below I will show a quick example.
The first thing to do is find the file and look at the first few bytes of a file. I will not go into how to do that manually, but it's easy in WinHex. Lets look a few bytes of the root directory in our example.
0000000 5245 5355 4d45 2d31 5254 4620 00a3 347e RESUME-1RTF ..4~
0000016 4a30 8830 0000 4a33 7830 0900 f121 0000 .0.0…..0…!..
We can see by looking at the first few bytes that this entry is called RESUME-1.RTF. This is a typical short file name we would expect to see in FAT. If the file has a long file name (longer than 8 ascii characters) then it would look slightly different. I'll leave it to you to research that topic.
The first few bytes are the short file name (bytes 0-10). Byte 11 (0x20) shows that the file has the Archive attribute set. Now comes the interesting stuff, bytes 13-17 show the created time.
Using our data structure as a guide we can determine the created day is 0x304a (bytes 16-17) the time is 0x7e34 (14-15) and the tenths of a second are 0xa3 (byte 13). The times are stored in Little Endian format which are read right to left. So 0x304a looks like 4a30 (byte 16-17) on the actual hex editor. This puts our example time at Feb 10, 2004 154940. There are plenty of tools online that can convert the hex into a readable time for you and WinHex has one built in.
Modify Access and Create (MAC times) are not essential times for FAT or NTFS file systems. This means that the operating system does not have to write accurate data there and they can be easily manipulated with a simple hex editor. Your case shouldn't rely on those time on their own. There are many reasons that your tool did not read the time. It could be a bug in the tool, or the OS simply did not write a time, or a user or application wrote invalid data or zero's in that space. Regardless FAT does not require anything valid to be there.
Disclaimer The example given was from Brian Carrier's File System Forensic Analysis (ISBN0-32-126817-2) and I highly recommend reading it. Even though its getting pretty dated, many of the concepts are still valid. You can find WinHex here https://