Registry Symbolic Links

I can successfully create this registry symbolic link;

   Link => "hkey_local_machine\software\techinc"

   Target => "hkey_users\S-1-5-21...\software\microsoft"  (hkey_current_user works as well)



But I cannot get this one to work, I always get Error 5, access denied;

   Link => "hkey_users\S-1-5-21...\software\techinc"

   Target => "hkey_local_machine\software\microsoft"




Is it not possible to create a registry symbolic link between registry hives, when one of them is the user's current hive?

I am using the traditional "RegCreateKeyEx", along with with "RegSetValueEx", which I know works, since the first example above is working fine. Also, any link that I create within any single hive works perfectly. It's just when I try to link between (2) different hives is when the problem happens.

Is there any way to get around this obstacle?

Last edited on
Have you considered that "access denied" means you need admin rights to be able to do something?
I should have mentioned that as well, thank you salem c. :)

I ran all my testing logged in as Administrator. I ran my MFC console application within an elevated command prompt.

I've also tried "RegOpenCurrentUser" and it did not fix the issue. Is there another way to obtain the required access rights for "hkey_current_user", programmatically?

1
2
HKEY keyCurrentUser;
lResult = RegOpenCurrentUser(KEY_ALL_ACCESS, &keyCurrentUser);
Last edited on
closed account (z05DSL3A)
Two things you could look at:

1. Use regedit to look at the Permissions on the key you want.

2. Turn off anti-virus or anti-malware products and test again.
Good point, I checked those as well, I have full permissions on "hkey_current_user" and i shut down the anti-virus.

The strange thing is, is that I can add the keys manually via Regedit and everything is fine. Mind you, the key that I'm adding is not a Symbolic link key.

There must be some other permission that is required to create a Symbolic link key. I've scoured the web, for many hours, the best solution I've found is using "RegOpenCurrentUser" with "KEY_ALL_ACCESS". You would think this would do the trick??
closed account (z05DSL3A)
I don't know if it will be any help...
https://www.codeproject.com/articles/11973//Articles/11973/Registry-Symbolic-Links
That is the code that I based my application off of. :)

The same issue, when trying to set a symbolic link between "hkey_current_user" and a different hive (i.e. hkey_local_machine) it gives an error 5, access denied.

Someone has to have run into this before?

https://docs.microsoft.com/en-us/windows/desktop/api/winreg/nf-winreg-regcreatekeyexa
I notice this, and wonder what you're trying to do.

Note Registry symbolic links should only be used for for application compatibility when absolutely necessary.


Also,

If the function fails, the return value is a nonzero error code defined in Winerror.h. You can use the FormatMessage function with the FORMAT_MESSAGE_FROM_SYSTEM flag to get a generic description of the error.

If you do this, do you get a better description of the error?

Which version of windows are you on?
Given the above disclaimer, it might be rather more deprecated than you imagine.

You might need to right-click on the exe and choose some "compatibility" options (perhaps).



Yeah, there is hardly any documentation from Microsoft on this topic. I do like what you found to get more of a detailed message descriptor on this error 5!

Personally, I think that they don't want to let us know about these capabilities, since it is used within the Windows O/S itself and users could easily nuke their O/S. I could be wrong, but all the data on the net has been put together by programmers who need the functionality to make applications portable.

This is what I am trying to do. It has to be the permissions on the current user registry hive! Are there any other ways to assign higher privileges to registry keys?
There is some information which may be of interest in this old DrDobb's article:
http://www.drdobbs.com/understanding-nt/184416290?pgno=1

In particular, it notes:
There’s one more catch: the target registry key needs to be in kernel-mode registry syntax, and it absolutely must be written as a Unicode string.
Check, I am using kernel-mode registry syntax and it's in Unicode. I've read that article as well. :) I've been researching this for about (2) weeks now...

I think I may have found something interesting.... just running some tests now. I'll let you folks know if this works or not ... (just found an article on invoking Administrator rights in Visual Studio, as opposed to using "as invoker"...)

Crap! Just tried it, no luck, WTF is going on??

I tried this idea;


In C++ you need to change the Manifest in the properties:

Right click on the head of the project, below the solution
You will get a popup menu, select: Properties
Under: Configuration Properties/Linker/Manifest file, select:
UAC Execution Level: change from asInvoker to requireAdministrator
Rebuild
This change will allow you to write to HKLM.

You should be using parameters like:

RegCreateKeyEx(HKEY_LOCAL_MACHINE, subKey, 0,
REG_NONE, REG_OPTION_NON_VOLATILE, KEY_WRITE|KEY_READ,
NULL, &hSectionKey, &dw);


Which came from this article (5th message from the bottom);

https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/073349b1-0f29-41ef-aaab-dbb262d52457/registry-access-worked-on-xp-vista-but-not-windows-7


Now, I'm not dynamically loading "advapi32.dll", I'm just including "windows.h"? I'll give this a try as well.




Last edited on
Nope, that didn't work either!

From what I'm seeing you CAN'T create a registry symbolic link, under "hkey_current_user", if the target is located in any other hive (anything other than under "hkey_current_user").

If someone can prove me wrong, please let me know.
Very strange ....

Creating these registry symbolic links below (using WIN32 API or Native API);

Works:

"hkey_local_machine\software\techinc" =>  "hkey_current_user\software\microsoft"


Works:

"hkey_current_user\software\techinc" =>  hkey_current_user\software\microsoft"


Access Denied:

"hkey_current_user\software\techinc" =>  hkey_local_machine\software\microsoft"


Why?

Last edited on
Logically it makes sense. current_user is part of the local_machine but local_machine is not part of the current_user.

local_machine has a higher level than current_user.
Good suggestion coder777!

So according to your information, if we programmatically assign "current_user" the same security descriptors as "local_machine", it should allow the link to work?

If you think this will work, how would you go about accomplishing the reading & writing of registry security descriptors? I tried assigning ADMIN security descriptors to the link key, but that didn't work for me, I'm assuming we'd need to read (capture) the security descriptors for "local_machine" and then write (assign) them to "current_user". Is that the process? Does anyone have a code sample?
Last edited on
The question is whether it can be modified or not. I.e. it might be a trait of the hkey itself.

I did not try it and you should be very carefully with changing the rights as well.
That is what I'm thinking as well, that this is a trait of the hkey structure and this boundary cannot be crossed.

I also found a similar limitation within the hkey_users keys themselves. I can't create a symbolic link between hkey_users\<AdminSID> and hkey_users\<pre-loaded registry hive>?

I'd like to know more about these boundaries/limitations, since they all look to be permission based, it should be doable.

I am doing all my testing within a VM, so when things go crazy, I revert back to a previous snapshot. I want to get this perfected before I try it live on my host machine. :)
Okay, one step closer ....

Using SubInACL, I discovered that "hkey_current_user" has the inheritance flag set. It is showing "SE_DACL_PROTECTED" set, while "hkey_local_machine" does not have that flag set. This looks to be the only difference between their security descriptors.

I don't see a way to de-select this inheritance flag from SubInACL, has anyone done this before?
Topic archived. No new replies allowed.