Відео

Ridiculous approach. A file creation date should be immutable. And it should never be possible to set the file creation date to anything other than clock time except (possibly) in the context of doing a restore operation on a partition/volume. An additional field, such as a logical file creation date, is one way this could have been better handled. Or a file version approach. You can create a new version of a file with the same logical file creation date as the original. Then you can delete or rename the old version as and when desired. And ensure the file system always select the latest version for the user to access.

Is this "a feature" or is it "behaviour"? :/

Legend

incredibly dumb way to implement file metadata consistency

How we get the disk image files as i am new to this can we get image file from locked system or hardrive

Can't wait to get stuck in to this course !!!

One of the best forensic channel I came across in youtube. Great and unique content as always❤ keep rocking brother.

Great video really helpful I have a question The documentation of arsenal tells that it supports affv4 I have aff files so will it work for image mount what is difference between them And can you please suggest me some more tools for windows cli through which I can mount forensic images and support most formats open source checked xways,xmount but both are of Linux and need something better than osfmount

Atomic file replacement... If a program author wants to maintain the creation date, he can, not windows. Dumb.

I actually noticed this once when i wanted to replace a file with a newer or modified version but the same name and i deleted the old one and then it happened that the "new" file got the timestamps of the one that was previously in the folder, which really confused and upset me tbh.

Thanks this solved a mystery for me... IMO this creates more problems that it solves. Especially in conjunction with file synchronization.

I don't get what legitimate purpose this could serve in modern operating systems. I mean, if you accidentally delete a file, then restore it from the recycle bin within the time limit, since it was never deleted from the drive, wouldn't the original creation date still be attached to the file? And if I fully delete a file and put a new one by the same name in that same folder, I would want my system to treat it like a new file, because it is.

Man, I've never seen the "COPY CON" idiom since the last millenium and the powershell. Is the new ReFS also affected by this thing?

Is Kansa abandonware? It was featured heavily in SANS FOR508, but it seems the project hasn’t seen any updates in two years.

No other OS/Filesystem does this, Microsoft working round bad programming then having to support that forever no matter how garbage that is

I had to change the creation date of a project i had to turn in 5 days late last semester because i got locked out of my college account and the teacher said she would check the metadata. For some reason the date modified and creation date were set to the latest time of modification which had been that morning. Thankfully she had told me that she would check this which allowed me to find a way to edit the metadata. Instead of docking me 10 points per day, she only docked me 25 total

You can just set whatever timestamp you want using the `SetFileTime` API, so I don't know why a threat actor would jump through hoops like this to manipulate the timestamp. Similarly, if I was doing any forensics, I wouldn't rely on the timestamps for anything.

I'm sorry, but this is disgusting to me. It feels like this problem is being solved at the wrong layer.

there's enough tools to change file timestamps... so this "trick" is kinda useless

Raymond Chen is the best! (OR, if he happens to read this: "THE Raymond Chen?")

Fascinating

With the name 'tunnelling', I thought this was going to involve some quantum effect lol

Levels, levels.

Oh yeah I did indeed know about this because a couple of years ago I tried to set up a caching mechanism where a fresh file wouldbe generated if the stale one’s create date was too old. Turns out the modify date is more trustworthy…

Ugh. Yet another way that I can’t trust MS is providing/preserving accurate data and metadata.

Too clever by a half. There is a danger in wiring a single use case and getting perverse results. In the Internet we got buffer bloat because some old line network operators did us a "favor" by buffering and thus breaking TCP. The name swapping technique is good practice and the programmers who care can also copy the creation date so why does the file system need to favors rather than encourage better practice in applications?

I think this is a leftover from DOS compatibility with long file names. Hence also why the name is misleading. It is part of a larger feature set regarding LFN interactions, when a Dos box would safe save, or manipulate a ~1 file. Microsoft tunnels the LFN vFat Filesystem to the 16 bit Dos 8.3 Filesystem, and this is just one leftover part of it.

This is not to be confused with Windows Settings Tunneling which allows settings code as far back as Windows95 to still show up even today. Bill Gates travels in these tunnels at night.

No, is the answer to the question. If an application uses the create, write, rename swizzle, it is a new file, and only a weirdo would expect a creation time in the past. What an insane feature to solve a nonproblem.

2048 in hex is a rather odd value to type. In decimal of course that's a power of two. In hex I would expect a round number like 800.

Or maybe we could just, I don't know, *stop using a 31-year-old flawed file system like NTFS already*. Just a thought. Throwing that out there.

Amazing courses! Are there any plans for linux forensics?

I do remember that writing security software back in the mid '90s, this "feature" caused us a certain amount of hassle. As someone else noted, it was necessary in maintaining the consistency of long filenames. At the time, given the way that MS handled the mix of 8.3 and LFN, putting that on the application would likely have been a disaster of incompatible application approaches. I guess you had to be there. It was a different time.

Something changed with Win11 ? Thumbcacheviewer opens the db-files under Win10Pro 19042 but under Win 11 Pro 22631 it tells me "The file is not a thumbs databse.". But when i copy the thumbcache.db from Win11 to Win10, i can open it. Do you know why?

Omg, this is pretty scary.

When I read the title, I first thought it was some kind of equivalent to Unix domain sockets. Not sure how the name tunneling related to this metadata manipulation.

tbh for the case of a virus you can just set the creation time (and accessed/modified), so imo not an issue. the only place where it might be remotely relevant is if you have a limited rce exploit (e.g. limited to file creation), and you need user interaction and the file creation timestamp changing is something relevant, but that's a scenario that basically only exists in pixie land. in the vast majority of cases where the timestamp is relevant, you will have access to changing the timestamp.

The registry baffles me. Nobody creating something as big as an OS today would dare have so much of the vital settings all collected in a single file with settings way too cryptic to understand. Windows is always one corrupted file away from simply not functioning properly.

i want to save files in-place, atomically, and transactionally but don't have any APIs for that. so "tunnelling" it is i guess

This whole feature seems like a bit of a hack; why doesn't Windows just offer safe saving as a feature so it could do all this under the hood without exposing this potential weakness or possibility for misleading data?

This has potential to help restore corruption and file problems that you were trying to get rid of in the first place

Thanks for video <3

Every single sentence where you explained what "file system tunneling" *is* was a massive red flag and yet another clue that *this is not something that should have ever existed*. 🤦 Manipulating file metadata based on *assumptions about what the user probably expects* instead of providing developers the means to set the metadata correctly themselves based on what they know they're doing has "Microsoft" written all over it.

Wouldn't it have just been cleaner to clone the original filename entry/entries for the temporary file and THEN just remove the original entry and free the blocks once we're done writing the updated file to the drive? This tunneling seems archaic in a modern filesystem. (And yes, clone the metadata including the original creation date... so it doesn't change in the copy.)

Do entries in the list persist past power cycling? Also dont antivirus scanners trigger stuff of these dates?

To be fair this was critical on Win 95 for long file names. If a DOS program did a “safe save” on a file with a ~1 shortname the long name would be lost, so tunneling to keep the LFN would be important.

How is this a threat? If you have write access, you usually can outright edit file metadata without any workarounds.

Does this feature exist on Linux or Mac systems?

Did not know about this feature, great example of building for the customer. Threats tho... why bother if you just can make an API call or even launch a 1-liner in powershell to set that AND date-modified, etc?

Does this DSStoreParser script work for anyone? Is there a new tool etc?