I have a file from an Android cell phone. I performed a chip-off physical image of the phone. The file in question is located in the Chrome browser cache. I have an issue with the time stamps that Cellebrite is reporting. Cellebrite is working with me on the issue, but I'd like to see if anyone else has any thoughts on this.
Cellebrite is reporting Modified, Accessed and Created time stamps. Cellebrite assures me that the "Created" time stamp is in fact the Created time stamp(crtime or birth time) and not the Changed time stamp (ctime). The Created time stamp is 3 days after the Modified and Accessed time stamps. Does anyone have an explanation for how this could happen? If a file is created by visiting a webpage and is given an initial set of dates, and then the person revisits the page 3 days later, would / could rewriting the identical file to cache cause the created time stamp to be updated but not the Modified or Accessed time stamps, assuming the inode # stayed the same?
Thanks in advance.
i had a case like that i parsed it with ief mobile extention then it solved
We also had time stamps mismatch issues before which we couldn't explain.
The LE used different software to analyze the same physical dump and it turned out that Oxygen Forensics and Belkasoft software reported good time stamps, while UFED was reporting for some reason 1970 dates. I don't recall exact software versions, still this problem existed once.
I don't intend to advertise any products, all I say is sometimes is better to check more platforms before closing the task, because forensics software can also do "mistakes".
If you find it interesting, read up the "Forensics Tools are Terrible" of this post by Jonathan Zdziarski
http//
It is an older article, but I think that program mistakes is a permanent issue.
Cellebrite assures me that the "Created" time stamp is in fact the Created time stamp(crtime or birth time) and not the Changed time stamp (ctime). The Created time stamp is 3 days after the Modified and Accessed time.
Have you verified their claim? (You can do so using debugfs, but it needs some minor technical trickery – the file system cannot be mounted – and I'm not sure in what form you have the file system image.)
Does anyone have an explanation for how this could happen?
I was actually going to ask you what explanations you had considered and rejected. You should be able to come up with at least half a dozen.
It seems to have been a design decision that Ext4 crtime should not be possible to change. As far as I can tell, it's not addressed by the standard syscalls to change time stamps. The only method I know is the debugfs path, alluded to above.
Your best starting point is, I imagine, to assume that crtime reflects the phone's idea of what current time is. So … how does that change? Can the user do it? Deliberately or by mistake? Could you find traces of such activity?
If a file is created by visiting a webpage and is given an initial set of dates, and then the person revisits the page 3 days later, would / could rewriting the identical file to cache cause the created time stamp to be updated but not the Modified or Accessed time stamps, assuming the inode # stayed the same?
Technically, it's software. It apt to have bugs. I'd probably fire up an Android emulator with the appropriate version of Android on, and try some tests both general platform tests, as well as application-specific tests (assuming the file can be tied to an application).
For Ext4 in general, there is some related info at https://articles.forensicfocus.com/2015/08/25/linux-timestamps-oh-boy/. Unfortunately, the test protocol and set up is underdocumented, so I would not treat anything in that article as more as 'this may in the right circumstances be true'.
Is the file in an application-specific location?
Is it tied to use action, or is it something that hasn't been touched since installation?
Have you verified their claim? (You can do so using debugfs, but it needs some minor technical trickery – the file system cannot be mounted – and I'm not sure in what form you have the file system image.)
The file system is a raw dump. It was a chip-off procedure. I'll look into debugfs and see what I can come up with.
I was actually going to ask you what explanations you had considered and rejected. You should be able to come up with at least half a dozen.
I've considered several possibilities, one of which I outlined in my original question, and haven't rejected any of them because I don't have the answers.
It seems to have been a design decision that Ext4 crtime should not be possible to change. As far as I can tell, it's not addressed by the standard syscalls to change time stamps. The only method I know is the debugfs path, alluded to above.
I'll look into debugfs and see what I can do with that.
Your best starting point is, I imagine, to assume that crtime reflects the phone's idea of what current time is. So … how does that change? Can the user do it? Deliberately or by mistake? Could you find traces of such activity?
This particular file is in the Chrome browser cache, which is not accessible by the user. It was a file that was placed in the file system by the browser during it's caching activity.
Is the file in an application-specific location?
The file is specific to the Chrome browser cache.
Is it tied to use action, or is it something that hasn't been touched since installation?
It is somewhat tied to user action. A specific website was visited seconds before the cache file showed up, on both dates, meaning the date I'm questioning and 3 days earlier also.
This particular file is in the Chrome browser cache, which is not accessible by the user. It was a file that was placed in the file system by the browser during it's caching activity.
It seems I didn't put the question well enough. Can you tie the activity that placed the file there to a direct user activity (such as running the browser), to system activity or to activity by another application (such as requesting resources through a URL scheme that Chrome happens to provide)? Was it a http// or https:// request, or perhaps a xyz// request (where xyz is assumed to be a scheme provided by Chrome).
It seems I didn't put the question well enough. Can you tie the activity that placed the file there to a direct user activity (such as running the browser), to system activity or to activity by another application (such as requesting resources through a URL scheme that Chrome happens to provide)? Was it a http// or https:// request, or perhaps a xyz// request (where xyz is assumed to be a scheme provided by Chrome).
I can only tie it to browser activity based on it being a browser cache file. The created date for this particular file and several other cache files like it, occur seconds after a specific website is visited. It seems logical that, because they are very similar files and they are created 1-3 seconds after visiting the same website, on two different dates, that they came from that website. Like I eluded to earlier, my problem is that the 'created' date is after the 'accessed' and 'modified' dates. Cellebrite is still claiming that the dates are correct.
I would be helpful to know what type of file are we talking about? (.jpeg or multimedia file or something else?)
NTFS/FAT and EX* does not require those times to be accurate or to have any value at all. Bugs in software and/or malicious user activity can report false times. Also, those times tend to be generated by the local machine time (at least in computers, not sure on ex* android systems) so that may also affect what is reported.
EX* file systems have historically maintained that C-time was changed time of the inode data.
NTFS/FAT have historically maintained that C-time was create (birth) time. Even so, however, NTFS/FAT C-time will change if file is copied to a new volume. (Modified time will not) (NTFS also has MFT create time which is when the file was written to the MFT - which is also the least likely to be changed/modified)
I do not know enough about Yaffs or F2FS but I imagine they are not different than Ex* file system.
So to make a short answer longer, in my experience there are many reasons that the C-time is different (including after) than the M-time
Your tools are wrong (testing and looking at the raw hex can confirm this)
The software that created the file is wrong
The device time is wrong (or where ever it is getting that time information from)
The inode data was change after the file was modified (or created)
Someone changed the time
Copying a file from one directory to another may change the C-time and not the M-time (less likely would be not changing the A-time but it is possible for that scenario to happen)
There may be other things also that could have happened that I haven't though of.
MAC times are great tools for furthering an investigation, but are not 100% reliable and should always be corroborated by other evidence.
EDIT - To answer your question earlier about copying files
Copying a file with the exact file path name (ie. deleting /overwriting the original file) should change C-time (inode information changed) and A-time (last access time changed) but may not change M-time (last time file was modified (especially with images and videos) in a Ex4 file system.
I have not tested this! This is based on my understanding of the Ex4 file system.
Theoretically you are writing a completely new file with a new inode and new data location in memory and the original file should still be somewhere (which may require carving). Its not like Ex4 will overwrite the data in the exact same blocks as the original file. (at least not likely, though it is possible)
Refer to Brian Carrier's File System Forensic Analysis book for more information about MAC times and file systems in general. Its pretty dated now but the concepts are pretty much the same. (and many of the file systems talked about are still in use today)