Starting Windows 95... _

so thats why its called tunneling! now that makes sense

It’s called tunneling after quantum tunneling. Search for a blog article by Raymond Chen on his Old New Thing blog

I think throwing a dart would give way better results than the stupid names they keep picking/changing splitting/merging/reusing. Seems they're actually going out of their way to troll.

Better name: Attribute Cache

This was created in the late-80s-early-90s when the modern sense of tunneling doesn't exist yet.

Not what I would expect, but it could be argued it tunnels past the changes of the file, the file meta tunnels past the contents. It could also have other functions that weren't talked in the video or were originally made to do something.

​@@mfaizsyahmi The modern definition dates back to the 70s with network protocol tunneling...

This was created in the late-80s-early-90s when the modern sense of tunneling doesn't exist yet.

@@mfaizsyahmi but the concept of a tunnel being something you use to transport something from a to b to, did exist and even in that context it doesn't make sense

⁠@@mfaizsyahmialso, depending when exactly, tunneling might’ve already existed as a computer networking term. I was definitely aware of the concept of tunneling 1 network protocol within another by ‘95, and AppleTalk over Ethernet goes back to the ‘80s (though I can’t remember if we referred to it as “tunneling” at the time). In any case, I’m with OP: nothing is being “tunneled” in any colloquial or technical sense and what is being cached and manipulated isn’t a “file system”, it’s “a file” or “file metadata”, depending on how you want to look at it.

​@@xTerminatorAndy I don't think it is fair to presume that it is poorly named based only on a very high level overview of what may be only _one_ effect of a more complicated system. If a deepdive reveals it as a poor naming choice, fine. But we don't have enough information in this video to serve that purpose.

@@tantalus_complex sure. my comment only represents the opinion of one very sad individual. I give it to you for free. Thank you for your feedback 🙂

Why is it a problem? How would you do a safe save instead?

Third party apps like Word, notepad, visual studio... They fucked up a lot in the OS to work around bugs in these third party apps.

The problem is that MS does this all the time and makes the OS impossibly difficult to follow everything and completely understand it. What should happen is that MS refuses to do this, the developer fixes their buggy software, and the OS interface remains clean and predictable. The problem is that most software on Windows is poor quality closed source software and therefore hard to fix software.

@@SirCutRy Back in the day, with windows machines with 4 or 8mb of RAM, was the optimal way to do it. Nowadays one can just render in memory and write the file once all is OK. The more correct option even back then would be to create a backup and then write directly on the file, that way the metadate is always ok. In case of failure, the user have the previous copy of the file.

I think this is just a remmant of the day they moved to FAT32, sold as a "feature". It could also just be something some big paying company asked them to do, to fix some problem they had with some app.

Unexpected behaviour is expected under Windows xD

Except Microsoft doesn't really have any control over their party applications. Not doing this would result in users being annoyed at the OS (thus Microsoft) because they will perceive the OS as being unable to even do a basic thing such as maintain the correct created date. Good luck trying to educate that it's actually the fault of the third party application. Especially when many applications do this. There's actually a specific API function to do the delete/rename atomically and safely specifically because of this issue but most languages do not expose it as it's Windows specific.

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.

@@chilversc “many applications do this”‽ It’s common for an application, when saving a changed file, to instead delete the old file and save a completely new file with the same name‽ And to _not_ let the file system calls handle that?

@@natbarmore reverse order though, save to a new (temporary) file, delete the old, rename to temp file to the original name.

Yeah, the fact that MSWindows or compression formats commonly used on MSWindows (or both) fail to preserve file creation dates is a major aggravation.

​@@natbarmore You could argue that the file was indeed created now because it simply didn't exist before it was unpacked - but it would be nice to have an option to choose if attibutes should be preserved.

@@robstamm60 if I copy a file from my external drive to my internal drive, should the creation date of that file be when it was first written to my internal drive? Or when it was first created, irrespective of _where_ it was first created? And why should that change just because as part of moving it, it gets compressed and decompressed? I mean, sure, adding the option to update the creation date when uncompressing/unarchiving a file, at least if your file system also lets you arbitrarily edit/update the creation date of _any_ file, makes sense, I guess. But it doesn’t make any sense for that to be the default, if “creation date” is to mean anything as metadata. It also means that it can’t preserve last modification date, unless the file system allows a modification date that predates the file’s creation. I feel like it’s a core functionality of a file system that we can know which of two files, or two copies of the same file, is older and which has been modified more recently. Ideally always, but I realize that between edge cases and nefarious actors, there will probably always be exceptions.

Indeed! And regarding other uses -- it's been theorized that File System Tunneling is used to enable Prefetch to work, since the superfetch/prefetching process has to both read the PF file for the subsequent launch of an application and at the same time modify the existing PF file to record the updated information, which typically isn't possible. So, FST could be used in that scenario -- read existing PF file, delete existing PF file, create new PF file, write updated data, rename new PF file to old name, "borrow" old PF file's creation date. As far as how to further exploit the feature from a malware perspective -- I have some thoughts, but haven't had time to test them. I refrained from mentioning them here since they are only theoretical and would require more testing.

@@13Cubed I want to try this, if it doesn't work may let you know xD

Not sure I follow what you mean?

​​@@13CubedI think they believe that it backdates modification and access times, in order to use a demo application indefinitely. Though, usually with apps like that, they store the time in the registry or in some obscure way that you can't easily find it. That is if they don't install themselves like an outright rootkit to achieve what they need to do.

File System Tunneling predates Windows 10... it's been around for a long time.

​@@13Cubed - Hmm, as I mentioned I tried it but doesn't see to affect my Win7, though I was using a file manager called Z-Tree.

@@BillAnt Interesting. Try with Explorer?

​@@13Cubed - Ya, in Explorer only the Birth/Creation data is retained from the deleted file. I guess using a DOS looking Ztree accesses it differently.

Because some of those methods only affect $SI timestamps, and not $FN timestamps.

Sure, but there are ways that can be detected.

Yes, there are timestomping utilities that are still effective. Timestomping the $SI creation/modification date and then renaming or moving the file right after would also clobber the $FN timestamps, making detection even harder without reviewing $J ($UsnJrnl).

I loved my copy of edate back on XP. Come audit time, everyone would ask again for a copy so they could rewrite recent history ...

What list are you referring to? Power cycling the box right after performing an action that would normally utilize File System Tunneling would preclude the behavior I demonstrated from happening. In other words, delete file a.exe. Reboot. Create file a.exe in the same location. This would result in the creation date (B) being set to current time, and not the time of the previous a.exe file. As for your AV question, yes, Access Times may be updated as a result of AV scans, which is yet another reason why this is one of the least reliable timestamps in Windows (from a forensics perspective).

If an app wants to swizzle and imply it is just writing, there are totally reasonable system calls to copy the metadata over.

This is a file system feature applicable to NTFS (and also supposedly FAT and exFAT, though I have not tested). I am not aware of any such feature in Linux.

* imo it doesn't make sense to call this a filesystem feature. the filesystem is just a place where you store files and their metadata (like the creation date). at best it's a filesystem driver feature. (because use one of these filesystems on linux and they will likely not do this) * all i would call filesystem feature is being able to have a file creation date. * there's tools to set arbitrary creation dates on files still the behavior is in interesting find. I do not regret having watched this video :)

No, shouldn't have anything to do with that.

I am not aware of anything like this in other operating systems, but it actually makes sense though. It's just a way of maintaining consistency with file operations to make sure the user experience is as one would expect.

exactly. It would seem Windows was always been written this hacky way and they pile up over time - one "feature" over another, and then one patch over the other and it never ends, it's always buggy and insecure in so many ways.

@moetocafe As someone who investigates Windows, Linux, and macOS intrusions, I can assure you it's just as secure as its modern counterparts. Nothing is impervious to a determined adversary.

@@13Cubed while it's true, that a system is as secure, as the administering party is able to secure it and use it in a safe way, I would disagree. Windows is broken by design on many levels - in terms of stability, code base, security and privacy. Just few very basic examples - on Win there are executables by default, and the practice for years is for people to download programs from anywhere and blindly install, trusting the supplying party. Compare that to FOSS, which code is available for security audit and the fact, that the collection of software in a Linux distribution were at least on basic level security audited. An unknown software, that is not well known and tested in time can hardly make it to a repo. Look at firewalls - Windows firewall by default has a bunch of ports and services open. Some Win native services have been notorious for security vulnerabilities - such as NetBIOS (ports 137, 139, 445 ....) Compare that to a Linux firewall, where the default is to close all ports for Incoming and only allow Outgoing. If you look at these and other factors - from a basic user perspective - how can you claim, they're equally secure?

You don't know what you are talking about. ​@@moetocafe

Good question on ReFS. I haven't seen any documentation about File System Tunneling and that file system, nor have I tested it.

This is used for "safe save" and similar behavior, where the end user is not going to be expecting a new file even though one is created behind the scenes to facilitate the operation.

Both. :)

Perhaps... that is a question for the original developers, but agreed that the entire concept of File System Tunneling is very strange...hence the video :)

Yep, it was an odd naming choice, but that's what it's called.

If a file was seemingly modified before it was created, it's likely the result of a file copy operation. There are a few videos on the channel that go into detail about this if you are interested.

No, this is a Windows-exclusive feature.

It doesn't -- these are two different technologies used for different purposes. ADS's were originally created to ensure compatibility with the Macintosh Hierarchical File System (HFS), allowing NTFS files to contain multiple hidden data streams.

@@13Cubed Thats not the point. If this is to work as MS intends it MUST copy the ADS data to the new file. This "Tunelling" is as old as at least 1989 because it is required because of the way MS Office Windows (not DOS) apps work. A Word document can contain an ADS, so .....

Sqlite stores the whole db in a single file, should have told them prob

@@rufiorogue but what os uses sqlite for all of its settings?

Actually it was MS Office 6.0 (1989) that created the problem. So it WAS self inflicted.

That would be absolutely worse. You not only are doubling the amount being written, but if something fails during that write-back, you've mangled the original. And while this isn't a problem now, when this was developed, file fragmentation was a real problem, and at least this method of saving had a better chance of slotting files in a contiguous section of a drive.

Not necessarily that easy. Keep in mind that a given file in Windows on an NTFS file system can have up to 20 timestamps! kzfaq.info/get/bejne/rsuVqdx01qmaYnk.html

@@13CubedThat's horrifying.

A little of both, I suppose.

Excellent! I'll be sure and let the threat actors know.

Hope you enjoyed the video regardless!

NTFS is actually an incredibly advanced journaling file system, even compared to modern alternatives. A lot of this "legacy debt" is in place for backwards compatibility.

Understood. I always standardize on ISO 8601 in training materials, but that's literally just a screen recording of a default US English configuration of Windows 11. I'll keep this in mind for the future.

I like AM/PM what's wrong with that. By the way the US *IS* on the metric system. Their measurements are based on metric ones. They just haven't told their population to use the metric system. (what I mean is that in the US an inch and a foot are based on a metric value). I'm just being facetious I guess 😛