Unmodified file wit...
 
Notifications
Clear all

Unmodified file with a close M timestamp after C timestamp

5 Posts
5 Users
0 Likes
756 Views
(@skywalker)
Posts: 152
Reputable Member
Topic starter
 

Hello,

I have a PDF file in a HDD's forensic image. The file has not been modifed because I have checked its hash digest with the original and it matches, but its modification timestamp is very close and after its creation timestamp. It is supposed the file has been downloaded from the Internet, specifically from a GMail account. I know the PDF has not been modified because I have matched both hashes, I mean, I have accessed to the original file in the GMail account and checked its hash which matches with the downloaded file's hash in the HDD's forensic image.

Aditionally, the three MAC times are setted one day before the email was sent and it has been confirmed the file couldn't be getted by another way than this email.

For further information, the whole folder's files have very close M and C timestamps, but M ones are ALWAYS after C ones. I have read a paper called "The Rules of Time on NTFS File System" (it is available on the net), but I cannot find the answer. C and A are the same. So M > C; C = A.

Any ideas of what is happening?

Thanks!!

 
Posted : 20/09/2019 11:39 am
minime2k9
(@minime2k9)
Posts: 481
Honorable Member
 

I think the answer may be in the question.
If you download a file from Gmail, the time should be when the file is initially created (depending on the browser it will have a different name until it is fully downloaded) and then the modified will be when it finishes downloading.

 
Posted : 20/09/2019 11:44 am
Omnius
(@omnius)
Posts: 39
Eminent Member
 

I think the answer may be in the question.
If you download a file from Gmail, the time should be when the file is initially created (depending on the browser it will have a different name until it is fully downloaded) and then the modified will be when it finishes downloading.

Concur. Standard for files downloaded from the internet.

 
Posted : 20/09/2019 12:36 pm
(@athulin)
Posts: 1156
Noble Member
 

For further information, the whole folder's files have very close M and C timestamps, but M ones are ALWAYS after C ones. I have read a paper called "The Rules of Time on NTFS File System" (it is available on the net), but I cannot find the answer. C and A are the same. So M > C; C = A.

Any ideas of what is happening?

If you don't see what your looking for, you're probably looking in the wrong place.

The most important information is of course just how much is the difference? On the order of fractions of a second? Or several minutes? Just what is 'very close'?

Rules of Time are fine, as far as it goes. But it is not relevant for files downloaded from Internet. (Read it again.) It's not a good idea to apply rules that work in one type of scenario for a completely different one. And by the way, the results of those tests were from Windows XP, so it's heavily outdated, as well. You should not be using that document for anything else than background information 'In days of yore, when the world was young, and Windows shone brighter than today, these were the rules of the stamping of time and other noble and glorious deeds …'

As GMail seems to be involved, you have to see if there is any way to download a file that produces the same results. That is, repeat the action, and see what happens. (Some care needs to be taken, if too much time has passed.) I presume you don't have a problem identifying the client that was used. (And yes, you very probably do have to do that.)

But I see no technical issue. M changes when a file is modified, althoug noone seem to have studied exactly what Windows file management operations actually change it and reported the results. So we're not too solid ground here. (I tried once, but got side-tracked once I got into the file encryption operations.) But we do know that a file in Windows includes ADS.

So, hypothetical scenario The file is downloaded, so M and C are set. Then, the file is reopened, and that 'downloaded from remote ' ADS (Zone.Identifier) was added, which – probably – updates M. (I assume that that ADS is present. If it isn't … wrong explanation, or it was removed manually)

minime2k9's scenario involving a change of names is also a possibility. There are more possibilities … for example involving Windows Shell.

But these scenarios may be possible only for M-C that is very small. If the difference is more than a second or two, some other explanation is required. (Such as some action may not finish until the user clicks an 'OK' button. If that happens to take a long time – perhaps the user went for a cup of coffee – it could explain larger differences.)

In any case, if you want to explain the oddity, you have to identify the client that was used, and then repeat the action you think took place, and see what happens.

 
Posted : 20/09/2019 3:58 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

I think the answer may be in the question.
If you download a file from Gmail, the time should be when the file is initially created (depending on the browser it will have a different name until it is fully downloaded) and then the modified will be when it finishes downloading.

So, given a sufficient number of (possibly largish) files downloaded around the same time one could even infer the speed of the connection while downloading which in the case of a laptop could even - in some cases - provide indirect evidence of the laptop location at the time (or of a non-location) even if conection data is lost. delted ot however not retrievable.

I mean, let's say that the laptop under examination is normally used at home, via a (crappy) 812.11b Wi-Fi connection that maxes out at - say - 6 Mbps

https://www.lifewire.com/how-fast-is-a-wifi-network-816543

if the M and C times difference imply a much faster download time it would be reasonable to believe that a different (much faster) connection Wi-Fi or cable was used, so logically the laptop must have been somewhere else at the time.

jaclaz

 
Posted : 20/09/2019 6:13 pm
Share: