I want to read with a simple c# application the windows key from the registry. But on a x64 machine I recieve only BBBBB-BBBBB-BBBBB-BBBBB-BBBBB as the key and that is wrong... How can I fix that problem?
RegistryKey key = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64);
RegistryKey subkey = key.OpenSubKey("SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion");
Thanks!
According to this Web Site that makes CD Key recovery software and this Windows7Forums thread, the existance of all B's for the product ID is indicative of a MAK(Multiple Activation Key) key.
From First link:
The B’s means the cd key is not stored in your computer, so cannot be recovered. That can be due to a few reasons:
A MAK was used for activation;
SLMGR was used to remove the key from the windows registry,
or You’re running a pirated version of Windows.
From Second Link
This is a big problem when an administrator sets up many PCs with a
volume license key. Because everyone can extract the VLC key and use
it for additional installations. Because this reason the VLC key is
automatically deleted from the registry after activation. And after
this all key finder show only "not available" or
BBBBB-BBBBB-BBBBB-BBBBB-BBBBB. With command line: slmgr –dli you
can get a "Partial product key" – the last 5 characters of the product
key. This "Partial product key" is saved in encrypted form in the
certificate file "tokens.dat"
(C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SoftwareProtectionPlatform\tokens.dat).
Everyone who fears that his key can be stolen can also delete manually
the product key from registry with this command line: slmgr –cpky
(cpky = clear product key = remove product key from the registry)
A quick web search shows many people with the same problem. One solution seems to be to get the DigitalProductID4 value if DigitalProductID is all B's.
Related
I'm new to using DPAPI so this is something I've messed up on my app because I've been redeploying between my work laptop and my personal desktop so now the key that DPAPI is using to protect my data has changed between environments.
Now I'm getting the error that the key isn't in the key ring.
I hit this answer where a link provided discusses configuring key storage so I've updated my code to persist keys to file system (while I wait for sysadmin to get back so he can set up blob storage on azure as an alternative) and this should work fine for dev anyway.
var path = this.Environment.ContentRootPath + "/Data/Keys/";
services.AddDataProtection()
.PersistKeysToFileSystem(new DirectoryInfo(path));
I can see the key files being created, but the error persists because I don't have the key that the app is looking for.
So how can I get it to generate/use/look for a new key here?
Oddly enough, it seems like completely reinitializing the app's database solved the problem.
My guess is it has something to do with the encrypted values that I stored in there (the DPAPI IDataProtector.Protect() output values). Specifically the fact that those values were encrypted with what I assume to be the key that the app was reporting couldn't be found.
Having reinitialized the database with new data, everything now works as expected.
I want to read all Values out of the Registry that are in the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
I am trying to do this with the following Code:
RegistryKey key = Registry.LocalMachine.OpenSubKey(#"SOFTWARE\Microsoft\Windows\CurrentVersion\Run", false);
string[] values = key.GetValueNames();
But my values String is always empty.
The interesting part about that is, if I change the Code to
RegistryKey key = Registry.LocalMachine.OpenSubKey(#"SOFTWARE\Microsoft\Windows\CurrentVersion", false);
string[] values = key.GetValueNames();
I get the correct amount of ValueNames in CurrentVersion. Why does it not work in \Run?
If I change from LocalMachine to CurrentUser the \Run path works too.
RegistryKey key = Registry.CurrentUser.OpenSubKey(#"SOFTWARE\Microsoft\Windows\CurrentVersion\Run", false);
string[] values = key.GetValueNames();
Can someone tell me why my first CodeExample does not work? Thanks!
You don't provide details on whether your C# application is 32-bit (x86) or 64-bit (x64). If the application is 32-bit running on 64-bit Windows, registry calls for HKLM\Software are redirected to HKLM\Software\Wow6432Node. Microsoft call this the Registry Redirector. Only certain keys are redirected, the details are in the linked article.
If your application is 64-bit, these registry calls are not redirected.
You can test this by manually adding a single REG_SZ entry of say "TestWOW" to HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run. Your 32-bit code should read this value (even though you actually asked for another registry key!).
If you can, re-compile your application as 64-bit. Now the same code will return the expected values from HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.
Unfortunately, I'm not aware of a mechanism to force Windows to NOT re-direct your registry calls to the Wow64 node for 32-bit applications running on a 64-bit OS.
I am trying to read the registry path
HKEY_CURRENT_USER\Software\MyFolder
By running the following code
RegistryKey key1 = Registry.CurrentUser.OpenSubKey(path);
if (key1 != null)
{
RegistryKey key2 = key1.OpenSubKey(subPath);
if (key2 != null)
{
return key2.GetValue(registryKey);
}
}
Where path = Software and subPath = MyFolder
key2 is always NULL
I believe this code is actually reading from HKEY_LOCAL_MACHINE\Software\MyFolder because it will default to this under the IIS account (I am running under application pool identity)
How to I force this code to access HKEY_CURRENT_USER? Do I need to change the identity of the app pool? Or some other way?
For me when deployed to IIS on Windows Server the HKCU for IIS is at \HKEY_USERS\S-1-5-18
This is a web app - I would stay far away from the registry. Put the information in a configuration file or a database. Others have explained why you can't open it. Here is a little more information around it.
Link for information below.
• HKEY_LOCAL_MACHINE (HKLM): Contains configuration information related to all hardware devices and software programs that are installed on your system.
• HKEY_USERS (HKU): Contains information related to all user profiles configured on the system. HKEY_USERS key has a template, which is used by your system to generate new user profiles with default configuration.
• HKEY_CLASSES_ROOT (HKCR): Stores information about file types and extensions, protocols, and classes registered on your computer. This key is user-specific and extracts user-specific data from the HKLM key. The information displayed in the HKCR subtree is obtained from the HKLMSOFTWAREClasses and HKCUSOFTWAREClasses keys.
• HKEY_CURRENT_USER (HKCU): HKEY_CURRENT_USER key contains information related to desktop settings, variables, variables, environment user folders, and other user-specific settings for the current user. Like HKCR, this key extracts user-specific information from the HKU key. The information displayed by this key is pulled out from the HKUSecurity ID key of the user logged in on the system.
• HKEY_CURRENT_CONFIG (HKCC): This key contains information about hardware configuration for the current user. This key extracts relevant information from the HKLMSYSTEM CurrentControlSet CurrentControlSetHardware Profiles key.
If you do decide to still use the registry - store the information in HKLM.
I've successfully signed my XML files using the RSACryptoServiceProvider. My key is stored in the Machine Key Store.
Now, I would like to check if the machinekeystore already contains the key that is related with the keycontainername or if the rsacryptoserviceprovider will need to create a new one.
How may I accomplish this?
Appreciate for your help!
Camille.
According to Key Storage and Retrieval, when Windows creates a Machine key store, it creates a file in the Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\Machine Keys directory. You could loop through the files and search for the file. See the example here called TryKeyContainerPermissionCheck for a way you might find the file.
I'm trying to get at the UserData registry subkeys on a C# 3.5 application so I can look up the installed location of an external program to start it.
Doing something like this:
RegistryKey installerKey = Registry.LocalMachine.OpenSubKey("Software\\Microsoft\\Windows\\CurrentVersion\\Installer");
and then
RegistryKey userDataKey = installerKey.OpenSubKey("UserData");
returns null; if I go back and call installerKey.GetSubKeyNames() to figure out which subkey names are present under Installer it only returns one subkey name: ResolveIOD. I haven't been able to find what only being able to find this key indicates.
regedit does not show the ResolveIOD key being there, and it shows that much more than just that one key is present - UserData, Folders, Secure, etc are all there and not returned by GetSubKeyNames() either.
This is my first time accessing anything in the Installer section of the registry hive, so I've probably done something wrong. Is there some kind of special permission I have to request in order to read these (probably sensitive, security-wise) keys from a client application, or is this generally not an acceptable thing to do on Windows 7 and I should find an alternative way of figuring out where the program is located?
Because I'm seeing this mentioned on other registry questions: This is running as a 32-bit application on 64-bit Windows.
First, to ensure you are accessing the 64-bit registry rather than the Wow6432Node sandbox, use the RegOpenKeyEx function with KEY_WOW64_64KEY (http://msdn.microsoft.com/en-us/library/ms724878%28v=vs.85%29.aspx) included as one of the access options.
pinvoke.net has a C# example: http://www.pinvoke.net/default.aspx/advapi32/RegOpenKeyEx.html
Also note that with UAC enabled, an unelevated app will, at best, only have read access to HKLM.