Apply Registry changes immediately (c++ question)

Lets say to maintain a level of security on a windows system you need to make changes to the registry at every logon. Making the changes is easy (small c++ app called from logon script), however they dont seem to go into effect until the user logs off and back on to the system.

Is there a way to force the changes into effect immediately? Through the c++ app or other system command that can be called from the login script? One example would be the current wallpaper.

PS - I've been gone from the AO community for quite some time, it's good to be back!

I think what you need to is to ensure the logon script runs first.
Registry changes will take place right away but the executing program probably gets these values right when it starts up so sequence of events would be important in your case..now the next??? can you enforce sequential execution of logon programs

Thanks for the comments.

The problem is that registry changes are not all applied immediately. You can test this yourself, open regedit and navigate to HKEY_CURRENT_USER/Control Panel/Desktop and change the 'Wallpaper' value. You'll notice that your wallpaper does not change immediately, however if you log off and then log back in again the new wallpaper will be displayed.

So what I need is some type of api call that will force the operating system to refresh this information, or a system command that will do the same.

Not sure if applicable to what you're trying to do...

But if you're using a version of Win95 or Win98 you can kill the explorer.exe process and refuse the reboot. This will cause it to open a new explorer.exe process with the new registry settings... (Was a nifty trick I found and useed on old PI 133mhz and slower systems to save myself the reboot time)

Doesn't work with Win2K (probably not XP either) as they won't restart a new explorer process automatically...

Figurred this could point you in right direction if nothing else.

RRP

i would like to recommend that if you have never meddes with your registry before that you take caution when doing so in the future.

I think the registry changes are made immediately, but the problem is that they are not propogated to all applications - that is, you change the wallpaper, but the explorer application does not refresh its wallpaper source. I have done a number of bits of work that update the registry and they have always updated immediately.

My first thought would be to check the windows messages, and see if there is one to notify applications of a registry update. Or of Wallpaper updates or something relating to this. Sending this message either globally or to the explorer.exe should make it do what you want.

If I get a chance, I will look up my windows message reference to see.

That would be great Schrodinger, if you could. I did some googling on the subject and didnt come up with much of anything.

I can't make any promises on this, as I work in VB, and am using a 5 year old reference book. So this may at least help you to move towards the answer.

It would seem that if you broadcast the WM_SETTINGCHANGE message ( &H1A ), this will hit all top level windows telling them a system-wide change has been made. I cannot be certain that this will include a wallpaper change, but this would seem to fit. If not, you may need to chase down some similar windows messages.

I hope this is helpful.

Thanks for the help.

I dig some more digging and found a SystemParametersInfo() function in the windows library that can change all kinds of these things, most without touching the registry directly. So, I think I'm gonna stick with using that for these purposes.

That sounds good, but bear in mind that you may have to still tell the system that things have changed. But hopefully not.

Hope you can get this sorted.

Just a small note: I don't think that setting registrykeys during a logonscript is a good idea.

Setting keys when the logonscript runs means the user in question has the appropriate rights to change them (remember the logonscript runs with the users credentials). Since anyone can read the logon scripts, anyone could also find out which keys get changed. Once they know that they could undo/modify any changes you made.

Use the (group)policy editor to create a policy that dictates these changes. These cannot be modified by the user.

SirDice - I would agree with you in principle, but my understanding of Shkuey's original question was that the registry changes were being performed from a C++ program. So reading the script would not give any indication of the keys being changed, as this would be in the executable.

If an application is not written to look for registry changes while running, the changes will not take affect until the program is restarted. This also applies to changes that only occur when the system is rebooted, or when a user logs on/off. There is no way to force this to happen.

For instance, there are several keys in the reg that most people are familiar with CurrentControlSet. If you look, there are also keys called ControlSet, ControlSet1, etc...

The way that these keys work is that for the most part the data that is contained in these keys is only looked at when the system is loaded(for the most part, there are many exceptions). This allows windows to do the last known good boot option. Instead of loading from currentcontrolset, it loads from controlset, or controlset1. So if you knew that your system worked fine when you loaded the system three times ago, you could rename controlset02 to currentcontrolset, boot the system. And you are good. This is in theory of course.

For OS level changes most of this has to do with the kernel architecture of windows. In that you cannot dynamically reload or change settings in kernel mode settings. You have to reboot. Many people see this as a bug or a problem, but it is actually good security. It is the thing that keeps people from writing root kits for windows. Linux and most unix variants allow for the kernel to be recompiled, or portions of it, on the fly. Which allows for things such as root kits to be loaded without the system being rebooted.

The bottom line though, is that if the application you are trying to alter via the registry does not have logic built into it to constantly check the registry for changes, there is very little you can do to force the change other than reboot/restart or logon/off. There might be specific commands for different apps to reload on the fly, but it will vary by application as to whether the ability is there or not.

And to answer the question about changing reg keys at login. We do it all of the time with very good results. For instance, we recently found a problems with McAfee VirusScan 7.0. By default the NAI virusscan add-in for outlook is enabled. There is a bug in this add-in which eats up resources on your exchange server. The easiest way for us to fix the issue on 70k+ clients was to write a batch file that looks for the proper version of VS, and if it finds it, delete the reg keys that enables this plug-in. Very easy solution for a large change.

Quote:

---

Originally posted here by Schrodinger
SirDice - I would agree with you in principle, but my understanding of Shkuey's original question was that the registry changes were being performed from a C++ program. So reading the script would not give any indication of the keys being changed, as this would be in the executable.

---

You are correct. It's still easy however to do a simple strings on this executable. You would need to do some obfuscation to hide the keys in the executable. Or I could just copy the executable and disassemble it in the comfort of my own home. It may take a bit more time but it's still doable.

Quote:

---

Originally posted here by SirDice


You are correct. It's still easy however to do a simple strings on this executable. You would need to do some obfuscation to hide the keys in the executable. Or I could just copy the executable and disassemble it in the comfort of my own home. It may take a bit more time but it's still doable.

---

But does it really matter if a user can see what registry keys you are setting? I don't think it does. The registry by default has the everyone group set to read only. In most cases, you cannot lock out sections of the registry to not allow read access as the programs that run in that users name may not work properly if they cannot read their corresponding reg keys. However, they user cannot change the values, so what difference does it make if they know how you are doing it? I don't think it does.

The job isn't to be sneaky and make the user wonder how you are accomplishing something, just that the security works as intended and cannot be circumvented.

SirDice - I accept that you are right, but I suspect shkuey is dealing with normal users. Providing security from users who have the technical knowledge and desire to take their startup script executables home and decompile them is a very different ball game.

Quote:

---

Originally posted here by mohaughn
However, they user cannot change the values, so what difference does it make if they know how you are doing it? I don't think it does.

---

The user IS able to change these keys. If you use a logonscript to set these keys the user MUST be able to change them. The logonscript runs with the users credentials. So it DOES matter. :D

Instead of modifying the registry directy, there are certain win32 API funtions that will allow you to edit certain keys and apply them instantly. I'm not sure but I beleive the function in "setreg()"? or "setkey()"?

scat

Quote:

---

Originally posted here by SirDice


The user IS able to change these keys. If you use a logonscript to set these keys the user MUST be able to change them. The logonscript runs with the users credentials. So it DOES matter. :D

---

The logon script calls an executable that sends a message to a service running under the system account that makes changes. The user does not neccisarily have rights to all the effected keys. Not only that, but there is no way the logon script or the executable it calls can be decompiled to reveal what changes were made.

Not that it particularly matters, because the user can change everything right back each time they log in for all I care, I just have very specific rules for how it must be when a user first accesses the system.

And thanks Scat, I had found the API calls (the specific one I needed was SystemParametersInfo()). So, problem was solved.