I recently wrote a native NT registry editor for Windows, and ran it on Windows 7. To my surprise, in addition to the two standard root keys, MACHINE and USER, that are present on Windows XP, there was also a mysterious key named "A", that cannot be opened in any way, whether by permission changes or backup privileges or otherwise:
Does anyone know what this key is for? I don't believe it's for any software, because it was there before I installed anything on the machine, and I believe I saw it on another fresh installation as well. It's rather very suspicious, and I'm curious as to why it's there. (If I'm curious enough, I might end up writing a driver to open it up without a privilege check, to see what happens!)
(I wasn't sure whether to put this on SuperUser or StackOverflow, since I think it could go in either one. I could be wrong, though; sorry if this isn't the appropriate place.)
Edit:
If forgot to say, I don't believe you can even see this key using the Win32 API, like RegOpenKey -- you have to use the native API like NtEnumerateKey instead.
Here is the comment from one of our driver writers: "DISCACHE.sys driver seems to be caching system file attributes and using \REGISTRY\A in an undocumented way. This driver is part of the kernel so it can load any hive wherever it wants."
Interesting...
The key indeed can be opened with a relative path, but not with an absolute path.
And it seems to contain information about all file systems and whatnot. Looks mysterious, indeed...
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.
So i recently got myself into a sticky situation, it seems like windows 'forgot' about a program I had installed (some drives changed letters / not really sure what happened).. I could find files that it created, but in 'Programs' and 'Add/Remove Programs' it is not there.
Also, when I use the 'programs' installer, it says it cant install because it exists already (to some extent), and I can un-install because windows doesn't know it exists.
BUT! I have an executable of the 'program' that works.
So I am wondering what the difference is between an executable, and what windows considers to be, and keeps track of, a 'program'.
This is definitely the kind of program that would show up in 'add/remove programs', as I have several other very similar ones from the same company that show up there, and I know it used to show up there.
I am not looking for wikipedia answers, I am interested in what exactly a 'program' is. What are the necessary pieces that make up a 'program' as far as windows is concerned?
For a program to show up in "add/remove programs", it needs to be installed. Typically, this is done through an installer that takes care of registering the program with windows and modifies the environment so that the program functions properly.
It may modify the registry to store user preferences for example...
When you have just an executable, it's not necessarily installed. It may be standalone.
Some programs don't absolutely need to be installed even if it's the canonical way to add a program in the Windows system. That's why it may work.
Another executable may fail because it relies on modifying the state of the system to work properly.
I hope it helps :)
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 !
SHGetKnownFolderPath() and its cohorts accept one of the constants defined here, returning the path to a directory.
I'm looking for one of these folders which is reliably writable by all users (including LocalSystem) on XP, Vista, and Windows 7... but I think I'm striking out. It appears that, in fact, there is no single location on the hard drive anymore where you can put a file and be assured that all users can write to it on all these OS versions, without fiddling the permissions first.
Is this true?
You are correct; there is no such folder.
You will need to create one yourself.
%ALLUSERSPROFILE%
This will not be writable by low-integrity processes or limited users, however.
One option seems to be FOLDERID_PublicDocuments, another could be FOLDERID_ProgramData. If there's a similar function you can use though to get a Documents type folder (for the user) that could work as well.
Edit: this blog post may help you.
To me its a no-brainer. The settings for my program go into the Windows Registry. After all, that's what it's for, isn't it?
But some programmers are still hesitant in using the Registry. They state that as it grows it slows down your computer. Or they state that it gets corrupted and causes your computer to malfunction.
So they write their own configuration files, or may use the INI files that Microsoft has depreciated since a few OS's ago.
From what I hear, the problems with the registry that occurred in early Windows OS's were mostly fixed as of Windows XP. It may be the plethora of companies that make Registry Cleaners that are keeping up the rumors that "registry bloat" and "orphaned entries" are still bad.
So I ask, is there any reason today not to use the Windows Registry to store my program configuration settings?
If the user does not allow registry access, you're screwed.
If the user reinstalls Windows and he wants to migrate his settings, it's much more complicated than with a simple file
Working with a config file means your app is portable
Much simpler for the user to change a setting manually
When you'll want to port your app to other OS, what are you gonna do with your registry settings ?
Windows Registry is bloated. Do you really want to contribute to this chaos?
For me, quickly installing, migrating and moving applications is a key point to productivity. I can't if I need to care of hundreds of possible registry keys. If there's a simple .ini or .cfg or .xml file somewhere in my user folder (or even the application directory if it is a portable app), migration is easy.
Often-heard argument pro registry: easy to write and read (assuming you're using plain WinAPI). Really? I consider the RegXXXfamily of functions pretty verbose ... too many function calls and typing work for storing just a few bits of information. So you always end up wrapping the registry away .. and now compare this effort with a simple text configuration file, maybe just key=value-like.
It depends, when you have small entries that need to read by multiple programs registry is ok, as database have locking issues, and config files are application based.
The problem happens when the user does not allow registry access, that are lots of software in the market that will show a pop up when anyone tries to modify registry and the user can cancel or allow the users. These programs are too common with the anti virus programs.
Putting your settings into the Registry means that if your user wants to move your program and its settings to another computer, he can't. Backup, ditto. Those settings are in a mysterious invisible place. I find this to be a hostile approach to one's users.
I've written numerous small-to-medium programs, and always used a .ini file. A tech-savy user can edit this file using an editor, he can check the settings in it, he can email it to a tech supporter, he can do a large variety of things that are significantly harder to do with registry entries.
And my programs don't contribute to slowing the computer down.
Personally speaking, I just don't like binary configuration of any type. I much prefer text file format which can be easily copied, edited, diffed & merged, and put under change control complete with history.
The last of these is the biggest reason not to use the registry - I can stick configuration files into SVN (or similar) with the full support given to text files, instead of having to treat it as a blob.
I don't really have much of an opinion for or against using the registry, but I'd like to note something... Many answers here indicate that registry access may be restricted for a certain user. I'd say the exact same thing goes for config files.
With registry you need to write to the "current user" to be fairly certain about having access (and should do so anyway, in many cases). Config files should be put in a user based area as well (e.g. AppData/Local) if you want "guaranteed" access without questions asked. As far as I know putting config files in "global" areas are as likely to yield access problems as the registry is.