Does anyone have a smal example of how to programmatically, in c/c++, load a users registry hive? I would loike to load a hive set some values and close the hive.
Thanks in advance for any help.
Tony
You can use RegLoadKey() and RegUnLoadKey(). You can build the paths to the user hives (NTUSER.DAT) via the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. However, it's generally not a good idea to use these functions willy-nilly. If the user tries to logon while you have his profile loaded, he will be unable to load his profile and will get a temporary default profile.
Documentation says you should pass predefined key HKEY_CURRENT_USER as first argument of RegOpenKeyEx function.
You can also enumerate HKEY_CURRENT_USER passing it directly to RegQueryInfoKey.
I haven't got a specific example, but the Windows API calls you need would be:
RegOpenKeyEx() to load the registry
key
RegSetValueEx() / RegGetValue() [and sister
functions] to get/set registry values
RegCloseKey() to close the
registry.
There's some example code behind this link on codersource.net ... although I can't vouch for how complete or correct it is. Review against the MSDN :-)
Related
I have read a few posts on StackOverflow itself about getting the UpgradeCode using 2 queries. First, use MsiGetProductInfo to get the database path (how?!) to open the database which will contain the UpgradeCode. Please provide the API call to fetch the database path! Urgent.
Call MsiEnumProducts to find the package code if you only know the name, then call MsiGetProductInfo with the product code to get INSTALLPROPERTY_LOCALPACKAGE property (i.e. the "database"/msi file), open the database, find UpgradeCode in the property table, done. That answers your question - but I'm not sure why you would need this in such a manner.
I have a BHO which on the first run is gathering activation information and storing this in the registry.
(I think) due to IE's permission's I am only able to store this in the registry branch
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\InternetRegistry\REGISTRY\USER\S-0-0-00-000000000-000000000-000000000-0000\Software\MyBHO\MyKey
Where S-0-0-00-000000000-000000000-000000000-0000 is a unique key for each user.
Which is fine using RegCreateKey() with "Software\MyBHO\MyKey". It's all created and running lovely. It determines where in space to store the Key with no problems.
The Problem:
When I carry out an uninstall I want to remove this key and as this is run outside of IE I have no way to determine where that key is / what the user string is.
Options I have in mind:
Option 1 (Ideal)
Find out this user string first to then build a new path for the key I wish to remove and remove it. How?
Option 2
At the point of activation store the path to the key in another registry value that can be accessed. Then read, and delete both (Which seems a bit backwards and probably wont work due to the access restrictions of the BHO on the registry (Thus it being written there in the first place))
Do you know if there is any way to find this User key or even how to find the parent dir.
Edit Upon continued research I've found that the thing I'm referring to as "user key" is the current Users "SID". Maybe this will yield me better results.
Call GetUserName to get the user name, and LookupAccountName to get his SID.
ConvertSidToStringSid is a useful utility function to format a SID as a S-1-5-32-00000000-00000000-00000000-00000000-0000 string
If you really want to write per-user data to the registry, use IEGetWriteableHKCU().
In general there is no good way to remove per-user data at uninstall. For example, what if you install as user A and the uninstall as user B? Are you going to go find all of them and delete them? Just leave the turds behind.
Alternatively you could consider using a different data store. Do you really need the registry? Can you store this data in a file? What about Web Storage?
I am writing some C++ code for the Windows(XP/7) platform to check the permission associated to a file. I want to verify that the file I am reading cannot be written by accounts with non elevated privileges. This is what I am currently doing:
I get the DACL associated with the file calling GetNamedSecurityInfo
I call CreateWellKnownSid with well known Sids, such as WinAuthenticatedUserSid (the Users group)
I call BuildTrusteeWithSid to build a TRUSTEE with the previous SID
I call GetEffectiveRightsFromAcl with the previously created trustee to get the effective acl
I check that the ACL does not contain the Write Flag set.
This code is working perfectly for the Users group. What about the other groups such as Everyone, Guests, or other specific users which may have specific write access on the file? I would like to find a solution where I don't need to enumerate all possible SID and check against all of them. Is there a SID I could use such as "anything but not admin"?
Regards,
Ant
I'd take a slightly different approach:
Get all ACE's via GetExplicitEntriesFromAcl, for the file and all its parents
Select the GRANT_ACCESS and SET_ACCESS ACE's
Get the list of trustees from the selected ACE's
For each of the trustees, perform an access check. GetEffectiveRightsFromAcl is probably the easiest solution here.
You'll want to think specifically what you want to do with the OWNER. He can alter the rights at any time.
Would someone be able to point me to the C++ API's that I can use to display a list of processes and the user name in Windows?
My current code uses the CreateToolhelp32Snapshot Function which shows all the processes running for all users, but I do not know what API's to use to retreieve the user name so I can filter it by user. I do not need to use CreateToolhelp32Snapshot, and I have seen other methods to retrieve the process list, but none seem to get me the user name that is running the process.
Thanks for any help.
I know that using GetTokenInformation with TokenUser gets you the SID, and a quick serach reveals that LookupAccountSid should get you the corresponding account. Havent't tried that last one myself though.
Well this link appears to have helpful code for you. Apply the code contained there in to the Token handle you get from calling OpenProcessToken on the handle you get from Process32First/Next.
Im currently using ie as an active x com thing on wxWidgets and was wanting to know if there is any easy way to change the user agent that will always work.
Atm im changing the header but this only works when i manually load the link (i.e. call setUrl)
The only way that will "always work," so far as I've been able to find, is changing the user-agent string in the registry. That will, of course, affect every web browser instance running on that machine.
You might also try a Google search on DISPID_AMBIENT_USERAGENT. From this Microsoft page:
MSHTML will also ask for a new user
agent via DISPID_AMBIENT_USERAGENT
when navigating to clicked hyperlinks.
This ambient property can be
overridden, but it is not used when
programmatically calling the Navigate
method; it will also not cause the
userAgent property of the DOM's
navigator object or clientInformation
behavior to be altered - this property
will always reflect Internet
Explorer's own UserAgent string.
I'm not familiar with the MSHTML component, so I'm not certain that's helpful.
I hope that at least gives you a place to start. :-)
I did a bit of googling today with the hint you provided head geek and i worked out how to do it.
wxWidgets uses an activex rapper class called FrameSite that handles the invoke requests. What i did was make a new class that inherits from this, handles the DISPID_AMBIENT_USERAGENT event and passes all others on. Thus now i can return a different user agent.
Thanks for the help.
Head Geek already told you where in the registy IE will look by default.
This is just a default, though. If you implement [IDocHostUIHandler::GetOptionKeyPath](http://msdn.microsoft.com/en-us/library/aa753258(VS.85%29.aspx) or [IDocHostUIHandler2::GetOverrideKeyPath](http://msdn.microsoft.com/en-us/library/aa753274(VS.85%29.aspx), IE will use that registry entry instead.
You'll probably want to use SysInternal's RegMon to debug this.