File found, creation date 11/6/2040 12:11 PM

[Hinata]

I found a file called ect did.not

This file has 3/4/2009 10:00 PM modified. I don't know what this is, corrupted? It was found on my flash drive (32 GB) after a deep scan. It is 1.81 GB File. I tried VLC, but didn't work.

EDIT: And also Accessed 1/13/1980? 11:00:00 PM?

MORE EDIT: 12:11:37 PM 11/6/2040?

[Winapp2.ini]

Sounds weird. I'd hazard a guess between something your USB drive uses for its file handing or an infection of some sort. Did you try scanning it with an anti-virus/malware?

[Derek891]

A file from the future? Maybe a message or a warning to all mankind.

[Hinata]

Problem is I never encrpted anything... I don't remember anything, and it is ?

[Derek891]

It seems the filenames were corrupted somehow, the dates as well. Are these files from a computer, a camera? The only thing that looks consistent is the size of the files, all 1.8 to 1.9 GB.

[Hinata]

These are from a flash drive. 32 GB. The problem is I only put photos there, and I never encryted it ether. I tried analzying the file that wasn't overritten, but it is somehow unreadable (though clearly it isn't entriely corupted...)

[hazelnut]

Hinata see here for what your .not file could be. (scroll down slightly)

 

http://filext.com/file-extension/NOT

[login123]

Hi, Hinata.

Not much help here, just information about a similar oddity.

I had a similar issue when someone stepped on a camera.

No kidding.

The photos had dates in the future. But they opened OK.

[Augeas]

This is fun. I deep scanned a 8 gb flash drive, about two years old, and sorted by date, and I have a 30k file called InkmenuI.tem created 12/11/2032, last access 14/11/2030, and last mod 03/02/2034.

 

The contents (not overwritten) indicate that it's to do with a Debenhams order, which is fairly recent - unless the file was overwritten by the Debenhams file which was subsequently deleted.

 

Of course a deep scan makes some assumptions. It recognises a file signature as the start of a .not or .tem or whatever file, and could pick up a sector with this signature in random data. Unlikely, but it could. So where would the dates and times come from? Not from the file table or directory, as the relevant data does not exist there - that's why you're doing a deep scan. So date and time comes from an assumed offset within the file. So does the file name as well, everything has to come from the data. This is all conjecture, but the point is that you should not be surprised if some of the info is flaky.

 

If I could wander off into my own universe for a moment, you would expect that a normal scan would return file names and directory info from the file table, and a deep scan to return all the normal scan stuff plus a list of un-named and un-directoried files, as file names (usually) and directory names (especially) are not kept in the file data. So why does a deep scan produce the normal scan stuff, then a list of file names and directories, and then a list of un-named, un-directoried stuff? Where does the additional list in the middle come from? For instance, a deep scan on my flash drive finds at least two .txt files, complete with file name and directory, not found in a normal scan. Txt files have no file signature, and don't have the file name and directory in their structure - there is no structure. So where do they come from?

 

 

By the way for some years I've had the impression that Recuva's last access time and created time were transposed, as many files seem to be accessed before they were created. Whether this is correct or whether the actual values in the file are wrong I don't know.

[Alan_B]

Accessed, Created, and Modified are stupid names for something else when Microsoft is involved.

 

Some years ago an emergency Patch Tuesday update included Explorer.exe

 

The update that fixed the vulnerability had the same creation date as the original vulnerable version.

The update version was SMALLER than the version which had the vulnerability.

 

I concluded that the original source file included the date string of when the developer threw the code together,

and the source code had extra debug code (and I now also realise backdoors for authorised agencies),

and the "bug-fix" was not a change of the source code but a change to a header file or make/build file that deactivated the bit of debug (or backdoor) which was the latest zero day exploit.

 

I found some time stamp changes in Microsoft files that were even stranger,

but I feared for my sanity and gave up looking for reasons.

 

All the above refers to files that have NOT been deleted and corrupted.

 

Files that Recuva looks for have had additional confusion thrust upon them.

[TheWebAtom]

Never trust timestamps. They're incredibly easy to fool.

 

In fact, I used to submit high school assignments late by tampering with the timestamps using the unix 'touch -t' command.

[Winapp2.ini]

A file from the future? Maybe a message or a warning to all mankind.

 

I'm going with this

[login123]

. . .

By the way for some years I've had the impression that Recuva's last access time and created time were transposed, as many files seem to be accessed before they were created. Whether this is correct or whether the actual values in the file are wrong I don't know.

 

In windows explorer it often shows that the date created is later than the date modified. I noticed that too, but wouldn't have dared mention it until you did.

 

Why is that? It's strange. Even for windows.

 

Glad to know someone else wonders about it also

[Augeas]

Ah, my old brain cells, or what few are left. I remember coming across something years ago where the access or modify time was before the create time, but only by a small amount, a few secs or a minute or so. I think it was to do with one of these time fields being rounded up to a two-minute boundary and the others being more accurate. The details are fuzzy.

 

However the discrepancies in Recuva are sometimes days or even months, so that doesn't apply.

 

Anyone tried tunnelling with file create dates? That's fun too - for a certain section of the populace.

[login123]

. . . The details are fuzzy. . ..

I've sort of gotten used to that.

Here are a couple of oddities as shown in windows explorer:

 

.....

 

Edit: Don't mean to hijack Hinata's thread, but this stuff might be relevant, can't tell since I have absolutely no idea why it occurs.