I've got serious troubles with Windows 7 not having a case-sensitive file system.
I'm the only developer who's working on Windows in my team (and we wanna keep it that way for cross-OS checks), and I'm the one producing occasional errors due to Windows not crashing on files with different cases.
Is there any way to make Windows go crazy when I try to include 'aSdF.php' where I meant 'asdf.php'?
From a programming viewpoint, you get case sensitivity on Windows by specifying the FILE_FLAG_POSIX_SEMANTICS flag when you call CreateFile.
You do just about have to call CreateFile directly to do that though -- a typical standard library (e.g., if you use fopen in C or std::ifstream::open in C++) will not pass that flag, so file names will be treated as case insensitive.
Related
I know that ntdll is always present in the running process but is there a way (not necessarily supported/stable/guaranteed to work) to create a file/key without ever invoking ntdll functions?
NTDLL is at the bottom of the user-mode hierarchy, some of its functions switch to kernel mode to perform their tasks. If you want to duplicate its code then I suppose there is nothing stopping you from decompiling NtCreateFile to figure out how it works. Keep in mind that on 32-bit Windows there are 3 different instructions used to enter kernel mode (depending on the CPU type), the exact way and where the transition code lives changes between versions and the system call ids change between versions (and even service packs). You can find a list of system call ids here.
I assume you are doing this to avoid people hooking your calls? Detecting your calls? Either way, I can't recommend that you try to do this. Having to test on a huge set of different Windows versions is unmanageable and your software might break on a simple Windows update at any point.
You could create a custom kernel driver that does the work for you but then you are on the hook for getting all the security correct. At least you would have documented functions to call in the kernel.
Technically, registry is stored in %WINDIR%\System32\config / %WINDIR%\SysWOW64\config, excepted your own user's registry which is stored in your own profile, in %USERPROFILE%\NTUSER.DAT.
And now, the problems...
You don't normally have even a read access to this folder, and this is true even from an elevated process. You'll need to change (and mess up a lot...) the permissions to simply read it.
Even for your own registry, you can't open the binary file - "Sharing violation"... So, for system/local machine registries... You can't in fact open ANY registry file for the current machine/session. You would need to shut down your Windows and mount its system drive in another machine/OS to be able to open - and maybe edit - registry files.
Real registry isn't a simple file like the .reg files. It's a database (you can look here for some elements on its structure). Even when having a full access to the binary files, it won't be fun to add something inside "from scratch", without any sotware support.
So, it's technically possible - after all, Windows does it, right? But I doubt that it can be done in a reasonable amount of time, and I simply can't see any benefit from doing that since, as you said, ntdll is ALWAYS present, loaded and available to be used.
If the purpose is to hack the current machine and/or bypass some lack of privileges, it's a hopeless approach, since you'll need even more privileges to do it - like being able to open your case and extract the system drive or being able to boot on another operating system on the same machine... If it's possible, then there is already tools to access the offline Windows, found on a well-known "Boot CD", so still no need to write in registry without any Windows support.
I have my own installer program which I use to install several applications I have written.
I have been updating this program to avoid the application's data file updates going to the user's VirtualStore, as I read this was a "bad thing". I am doing this by storing the program and common data files separately in their correct locations, instead of sticking everything in Program Files like we used to do in the days of XP.
I am also now using SHGetFolderPath (yes, it's deprecated, but I still need to support my XP users), to get known folders instead of trawling the registry, which is another "bad thing" (I read).
The next thing I was trying to do was rewrite the installer code to avoid registry redirection to Wow6432Node when writing stuff to HKLM, as I thought this was another "bad thing".
However, although I could put the application specific stuff that goes there (like the install folder, if the user decides to install in other than the default), the killer is the need to put the uninstall info in HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall. For 32-bit stuff running on a 64-bit system, this is redirected to Wow6432Node. I don't see any way round this - is it in fact possible?
UAC registry redirection could reasonably be described as a "bad thing" because it is designed specifically to provide compatibility with improperly written software, i.e., software that assumes it is going to be run with administrator privilege.
WOW64 registry redirection is a different beast; it's designed to provide compatibility with properly written 32-bit software. If your software is 32-bit, and has no specific need to be 64-bit aware, there's nothing wrong with letting it run in the emulation environment as-is, including allowing registry settings to be redirected to Wow6432Node.
You can bypass WOW64 registry redirection if necessary, but you shouldn't do this arbitrarily, only if there is a specific reason. If WOW64 redirection worries you, the only good alternative is to provide a 64-bit version of your program.
This is a very "BAD THING" !
Microsoft solves a security problem by hiding thing at another place !
I've created a programm to ask the user for some additional parameters (language, directory for lessons) during installation of the app. I tested the programm profoundly, and the registry entries were made perfectly. However during setup the entries were hidden at some strange place!
If Microsoft wants to redirect these enties it should at least be some option to be set.
Never hide things, and think they will not notice, because it's transparant.
Doing this properly would involve an option to be set, so users are aware of the redirection !
Is it safe to assume that Windows local and network file paths are NOT case sensitive?
Yes. Windows (local) file systems, including NTFS, as well as FAT and variants, are case insensitive (normally). The underlying implementation of a network file system may be case sensitive, however, most software that allows Windows to access it (such as SMB) will automatically make case sensitive file systems appear as case insensitive to Windows.
For details, I'd read the section in the Wikipedia article on filenames.
Case sensitivity on Windows is actually implemented in how the application opens the files. NTFS can be a case-sensitive file system and can happily store files, with identical names differing only by case in the same directory.
On Windows all files are ultimately opened via the CreateFile API - If the FILE_FLAG_POSIX_SEMANTICS flag is passed to the call (and the file system being accessed is natively case-sensitive) then the file will be opened based on an exact name match. If FILE_FLAG_POSIX_SEMANTICS is not passed then the filesystem does a case-insensitive file open and will open one of the files with a matching name. If there is more than one it's undefined as to which one is actually opened.
Most C and C++ runtime implementations on Windows do not provide any access to this mechanism and never use this flag so the only way to get access to case-sensitive behaviors is to use the Windows API directly.
tl;dr - Your language runtime probably exposes your filesystem as case insensitive or case preserving. You can, if you use the windows API directly, access supported filesystems fully case senstive.
NO. It is not a safe assumption.
The other answers are informative but regardless of what they say it is not a safe assumption and continues to become more unsafe as time goes on.
NFST - Can be case sensitive.
I use it on a per-directory basis but you can also do it with entire NTFS drives.
https://devblogs.microsoft.com/commandline/per-directory-case-sensitivity-and-wsl/
WSL - Is case sensitive.
Linux GUI apps, and Android apps coming to Windows. They will all be running on a case sensitive file system by default, locally.
For testing and development purposes, it would be nice to somehow simulate (spurious) file access errors to local files. For example, even if an application has correctly opened a file with the appropriate restrictive sharing flags, it still can happen that an attempt to access the file (through any of the Win32 API functions or your favourite framework, which internally will just call any of the Win32 API functions) can fail.
The only example I ever was able to track down was the virus scanner on a machine, but I guess there could be other reasons. (In this question's comment, Luke mentions something about "File system filter drivers".)
FWIW, I know of a few possibilities to "simulate" file problems, that I do not consider good solutions, either because they require to much manual work or because they don't fit for every app/file:
Place a file on a network drive or removable storage device - that way you can just mess up the device (unplug, disk-full, ...).
Open the application process in Process Explorer and close the handle of the file you want to test.
So the question really is if there are any ((semi)automated) tools that can mess up file access (on an NTFS drive) even though an application has already opened a file with appropriate (for the app) sharing flags.
Holodeck purports to allow Win32 API hooking, which would enable you to manipulate return codes as needed for Fault Injection.
If your API set of interest is well-defined, you could probably do this yourself using the Import Address Table approach described here.
I just stumbled on this article on MSDN that says a path can be 259 characters + NUL termination, but if you prefix it with "\\?\" WinAPI allows you to use the
maximum total path length of 32,767 characters.
Eager to see it working I tried using that prefix from Explorer (On XP SP3) but it doesn't work at all (on any path). If you put \\?\C:\Path\to\an\existing.file on explorer's bar, it will give the "file not found" error.
So I'm confused. Can I code something for (non-ancient) Windows that makes full use of the mentioned path size on NTFS? Why Explorer doesn't use it?
There is a SET of API calls that are work with extened-paths and some that do not. The MSDN usually mentions this.
Not that if you just type that path into windows explorerunder xp this does not work, because the extened path syntax is just an escape sequence for the WIn32 API and not for windows explorer. Now, In Win7 this does work because many people expected this to work.
Also for long paths, it does help if you change the working directory or open up explorer with a sub-directory as a root.
Before someone tells me to RTFM...
Note that these examples are intended for use with the Windows API functions and do not all necessarily work with Windows shell applications such as Windows Explorer.
[...]
For file I/O, the "\\?\" prefix to a path string tells the Windows APIs to disable all string parsing and to send the string that follows it straight to the file system. For example, if the file system supports large paths and file names, you can exceed the MAX_PATH limits that are otherwise enforced by the Windows APIs.
On a secondary note, this makes me wonder about the possibilities of hiding files (or finding such files) from explorer by using illegal file names.
Are you asking why all components in Windows do not support it, or are you asking whether it's legal to use these long paths?
You can definitely safely use them, but you may irritate someone who wants to use tools like Explorer to browse them. We see paths like this all the time in the wild. Sometimes people are pretty surprised when they can't use MY_FAVORITE_TOOL to delete it...