DOS File Path Magic Tricks
By: Carrie Roberts @OrOneEqualsOne
I wanted to take a close look at how the Windows operating system handles file paths. Learning creative or obscure details often leads to cool hacking techniques. A hacker may use these tricks to bypass a blacklist of unapproved input, or to satisfy a white-list. Designers of systems should keep these functional, but perhaps unexpected techniques in mind as they develop their systems, both for functionality and security reasons.
In this article I give a variety of examples of how to refer to the notepad.exe executable from the C:\Windows\System32 directory using various path notations. I also discuss how some of these tricks can be used to annoy or fool system administrators and information security analysts.
Fully Qualified DOS Paths
Fully qualified DOS paths are the most familiar. They begin with a drive letter, a volume separator, and a component separator (c:\). Environment variables such as %SystemRoot% can be used as shortcuts to pieces of the path. Use the ‘set’ command from the Windows command prompt to see which environment variables are available to you.
DOS Device Paths
DOS Device paths begin with two back slashes followed by a period or question mark and then another back slash (\\.\) or (\\?\). The difference between the two notations is that a path with the question mark prefix will skip normalization. More information on normalization is provided later in this post. Also, some applications may handle these paths differently, for example we had to use the “start” command with the question mark notation from the command prompt but but not when used from PowerShell.
Device paths contain references to devices and directories through named symbolic links. You can use the WinObj tool from Sysinternals to view the named links available to you.
The examples on lines 2–5 refer to the various names you see in WinObj referring to hard disk volume 4 (the C: drive in my case). Line 6 throws in “Global” which is a symbolic link back to the GLOBAL?? namespace we were already looking at in our WinObj screenshot.
UNC Paths
UNC Paths start with two separators and then something other than a question mark or a period. Following the two separators is the server where the share is found, which is then followed by the share name to be accessed.
These examples use variations on the IP address used for the local machine (local host) including IPv4 and IPv6.
Relative Paths
Relative paths are specified in relation to another path. If a path starts with a backslash, it is a path relative to the root of the current drive, C: for example.
If you run the command on line two while on the D: drive, the path will point to the D: drive. The next example specifies a drive (C:) without a slash following. Or in other words, it begins with a drive letter, a volume separator and no component separator. These paths are relative to the current directory of the specified drive. Each drive has it’s own current directory, you could refer to the current directory of the C: drive from the D: drive using the notation shown on lines 5 and 6. Note that for notepad to launch with the given examples, the current directory (cwd) must be as specified in the comment.
Most people are already familiar with the relative path notation using a single period for the current directory and a double period for the parent directory so I don’t go into much detail on that here. The last examples I give show that you can specify parts of paths that don’t even exist, and then ignore them by jumping to the parent directory with a double period.
Path Normalization
Path normalization is the coolest of the magic tricks in my opinion. Path normalization removes trailing spaces and single periods from path components. It also changes forward slashes to back slashes.
Path normalization occurs when paths that don’t start with //?/ are passed to the Windows API (except relative path components are always normalized). Path normalization can lead to some interesting results, including security bypasses.
The “UAC Bypass by Mocking Trusted Directories” blog post describes how User Account Control (UAC) can be bypassed by exploiting path normalization.
The Command History Con
If you looked around a bit in WinObj you may have noticed a special symbolic link called CON, which points to the console. It’s a bit surprising, but you can often use these symbolic links to devices in the same way you use symbolic links to basic files. For example, you can use CON creatively to write multiple line input to a file from the command prompt.
Here we used “copy con out.txt” to write whatever we type next into a file called out.txt. The “^Z” is where I pushed Ctrl+Z in order to send the End of File (EOF) indicator to the console so it would stop waiting for input and then write the output file.
Another symbolic link you might have noticed in the Object Viewer (WinObj) was the NUL symbolic link that points to a magic nowhere. You send stuff to NUL and it just goes away. So we could do something similar to the above and copy anything we type to console and send it to NUL, and have it vanish.
But why would we ever want to do that? Well, you never know, maybe you want to write a bunch of fake commands into the command history as if they had been run, but they actually hadn’t.
Here we place a firewall command and a ping command into our command history without actually executing them. We use the “doskey /h” command to view the command history. Notice that where we pressed Ctrl-Z you see a little question mark in a box. This is what the command prompt decided to display for the EOF character we placed there. If we cared, we could have entered enough space characters to scroll off the screen before we pressed Ctrl-Z so it wouldn’t be readily seen in the command history. OK, cute parlor trick, let’s move on.
A Folder Named Con
So CON is special, that’s interesting. What if I wanted to create a folder named con?
Negative, it looks like a “No Con do”. But wait, a little Googling says we can do it using what we learned about file paths. In this case, we can use a DOS device path to get around this limitation.
Ok, let’s try to do something with this folder now.
If we hadn’t have been the one to create this folder, we’d be thinking ‘What is wrong with this folder?’ I can’t see what’s in it and I can’t delete it even though I have ownership of it and the proper permissions. Oh, I know, I’ll just click on it in Windows file explorer.
Oh snap, the GUI has failed me and it says “The handle is invalid”. I’ve never seen that before, that doesn’t even make sense!
As a red-teamer, I think this would be a cute little trick to play on the blue team to slow them down a bit. As a blue teamer, I can recall my list of nerdy tricks and realize I can use device paths to handle this directory just like any other directory. Let’s delete the con folder with “rmdir \\.\c:\temp\con”.
A Folder Named “<space>”
How else could we be annoying with the use of device paths? Hmm, how about a folder whose name is a single space character.
Our path got “normalized” before the directory creation and the space was removed, resulting in an attempt to create the already existing c:\temp directory. But wait, we learned about a second way to specify a device path that bypasses normalization. This path starts with “\\?\” instead of “\\.\”
That did it, we have a directory whose name is a single space character. We do a directory listing and find it is hardly even noticeable. What does File Explorer do for us in this case?
It appears as a seemingly un-named folder. If we click it, we don’t get an error about an invalid handle like we did with the con folder, but it shows us what appears to be another un-named folder. We have to click on this second folder, which doesn’t even exist, and then we can see what’s inside. Odd…
I saved a file in our “c:\temp\ \” folder called “something”. I try to open it in Notepad but it can’t find the file because of the two, space folder anomaly.
What a pain! This could give us heart-ache but we are equipped with the knowledge to handle it just fine now.
A Folder Named “…”
Let’s create a folder named “…” because that seems like it could create chaos.
Here we created a file with a name of 3 dots and placed a file in that directory. We find that this really does cause Windows Explorer a great deal of confusion.
Every time we click on the “…” folder, it adds a “…” to the path in the address bar but leaves us where we were, outside of the folder, so that we can’t see the files inside the folder. In addition, we cannot delete this folder, or any of it’s parent folders from Windows Explorer. Well, that is a fun little magic trick!
Conclusion
As was demonstrated, we can use these features of file path handling in Windows to bypass controls or otherwise hide information or make file discovery and recovery difficult.
Keep these tidbits of trivia tucked away because you never know when they might come in handy for accomplishing your purposes in the future.
References
File path formats on Windows systems:
https://docs.microsoft.com/en-us/dotnet/standard/io/file-path-formats
Geeky Trick to Amaze your Friends:
https://www.ahuka.com/dos-lessons-for-self-study-purposes/dos-lesson-7-dos-filenames-ascii/
Creating a Folder Named CON in Windows:
https://superuser.com/questions/129141/creating-a-folder-named-con-in-windows
Mocking Trusted Directories: https://medium.com/tenable-techblog/uac-bypass-by-mocking-trusted-directories-24a96675f6e
https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces
