Apart from the MSDN reference, I want to know what these keys do? Does KEY_WOW64_32KEY means that a 32-bit app on x64 OS will access the WOW64 Registry Tree ? And does KEY_WOW64_64KEY means that a 32-bit app on x64 OS will access the normal Registry Tree and not the WOW64 Registry Tree ? What if I have to access some keys which I do not know whether lies in the WOW64 or normal Registry Tree ?
KEY_WOW64_64KEY on a 64-bit OS means that the registry access, no matter if it's a 32 or 64 bit process, will access the 64 bit registry view.
KEY_WOW64_32KEY on a 64-bit OS means that the registry access, no matter if it's a 32 or 64 bit process, will access the 32 bit registry view.
Neither of them have any effect on a 32-bit OS.
Leaving the flag out (the default) on a 64-bit OS will send registry accesses from 32-bit processes to the 32 bit registry view, and accesses from 64-bit processes to the 64 bit registry view.
For more info, this reference page at Microsoft should tell the whole tale.
From the linked reference:
For more information, see Accessing an Alternate Registry View.
Which says:
KEY_WOW64_64KEY: Access a 64-bit key from either a 32-bit or 64-bit application.
KEY_WOW64_32KEY: Access a 32-bit key from either a 32-bit or 64-bit application.
Related
I am trying to disassemble the 64-bit ntdll.dll using IDA. From my understand, this DLL is located in C:\Windows\System32 on a Windows 64-bit OS. When I disassemble this DLL, it shows 32-bit addresses and a 32-bit instruction set. However, in the debugger, when I load this library into a process from the same directory, it has a 64-bit instruction set during runtime.
How can I disassemble the 64-bit ntdll?
Please check whether IDA is a 32 bit application in Task Manager (on the Processes page 32 bit processes should have the suffix (32 bit). If you switch to the Details page in Task Manager perform a right click on the column header and choose Select columns from the context menu. Select Platform to display the bit-ness of a process and close the dialog. 32 bit processes are listed as 32 bit in the Platform column.
If IDA is a 32 bit application, use the path c:\windows\sysnative\ntdll.dll to open the DLL. If you specify sysnative instead of System32, Windows uses the SYSTEM32 directory instead of the SysWOW64 for 32 bit apps.
I am currently trying to get a list of all autoruns, but I am struggling on a 64-bit system. When I use:
My.Computer.Registry.LocalMachine.OpenSubKey("SOFTWARE\Microsoft\Windows\CurrentVersion\Run", False)
It shows me entries from:
My.Computer.Registry.LocalMachine.OpenSubKey("SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run", False)
Anyone know why and/or how to fix this?
I should also state that the items in HKLM\..\Run are different to those in HKLM\..\Wow6432Node..\Run.
Your process is a 32 bit process and so, on a 64 bit OS, the registry redirector comes into play. The HKLM\Software key is redirected and there are two views of it, a 32 bit view that your process is finding, and a 64 bit view.
It is true that if you run a 64 bit process, you will see the 64 bit view of the registry. However, that is not the full story. Windows processes CurrentVersion\Run entries from both 32 and 64 bit views of the registry. So, if you just switched to an x64 or AnyCPU process you would then be missing the autoruns stored in the 32 bit registry view.
So, since your goal is to list all the autoruns, you will need to read both 32 and 64 bit views of the registry. You can do that using the RegistryView enumeration that was introduced in .net 4. This allows a 32 bit process to access the 64 bit view of the registry. And indeed it allows a 64 bit process to access the 32 bit view of the registry.
If you want a process that runs on both 32 bit and 64 bit systems you will need to target either x86 or AnyCPU. And then use RegistryView to read both views of the registry if you detect that you are running on a 64 bit system.
That's happen because your application is compiled for x86 platform and running on a 64bit operating system. There is a comprensive article on Registry Redirection on MSDN
The registry redirector isolates 32-bit and 64-bit applications by
providing separate logical views of certain portions of the registry
on WOW64. The registry redirector intercepts 32-bit and 64-bit
registry calls to their respective logical registry views and maps
them to the corresponding physical registry location. The redirection
process is transparent to the application. Therefore, a 32-bit
application can access registry data as if it were running on 32-bit
Windows even if the data is stored in a different location on 64-bit
Windows
You could fix the problem compiling your application for AnyCPU platform
Attempting to call SetupDiCallClassInstaller from a program compiled in 32 bit mode fails on 64 bit Windows.
Apparently this is by design, but I'd like to know the reason.
According to MSDN:
Device Installations on 64-Bit Systems:
The 32-bit version of the application must check the value returned by UpdateDriverForPlugAndPlayDevices. If the return value is ERROR_IN_WOW64, the 32-bit application is executing on a 64-bit platform and cannot update inbox drivers. Instead, it must call CreateProcess (described in the Windows SDK documentation) to start the 64-bit version of the application. The 64-bit version can then call UpdateDriverForPlugAndPlayDevices, specifying a FullInfPath parameter that identifies the location of the 64-bit versions of all files.
So it looks like any API that is designed to report ERROR_IN_WOW64 is specifically intended NOT to work in WOW64, a 32bit process has to invoke a 64bit process to call the API.
If you are making that call from a 32bit process on a 64bit OS, it fails because it has to modify some registry keys in the 64bit portion of the registry. Where else if you were to make that call from a 64bit process on a 64bit OS, it would succeed likewise with 32bit process on a 32bit OS.
Here's my scenario: the company I work has applications deployed to a 32bit Windows 2003 server and they want to move to a Windows 2008 Server that is 64 bit. It has been noted that these 32bit custom developed applications will not run on a 64 bit machine. I was not aware of this.
I have always thought that 32bit software CAN run on a 64 bit OS and just use the 32bit address. A 64 bit software on the other cannot run on a 32 bit OS. On a 64 bit, one does have to create 64 bit software but can and still also create software that is designed for 32 bit machines.
Can someone please elaborate on this?
In general, 32-bit applications will run under a 64-bit Windows (This is technically called WOW64 - Windows On Windows). This applies to all 64-bit Windows version to date, including Server.
WOW64 processes are marked in task manager with *32, For example: chrome.exe *32. Sysinternals' Process Explorer has a separate column for this: Image Type (64 vs 32-bit).
If the app has components hosted inside other processes, then those components must accommodate processes they're hosted in. Examples:
Shell extensions are hosted in explorer.exe, whose bitness matches the OS' bitness. Therefore, you should compile the extension in both 32- and 64-bit, and register the one matching the OS' bitness during installation.
Kernel-mode driver are hosted in the Kernel, whose bitness also matches the OS' bitness. So, the above applies.
Winsock LSPs (Layered Service Providers) are hosted in all processes, both 64-bit (native) and 32-bit (WOW64). Therefore, you should compile the LSP in both 32- and 64-bit, and register both in their respective catalogs during installation.
There are also considerations regarding file redirection (System32 / SysWOW64 / SysNative) and registry redirection (Wow6432Node), which I will not go into.
In general, 32-bit applications will run under a 64-bit OS. If your app relies on a 32-bit kernel driver (say, a VPN client), then you will have to port to 64-bit.
It appears that specifying the KEY_WOW64_64KEY flag (reference) when accessing a registry key under 32-bit Windows XP has no effect - that is, no error is thrown, and the key is opened as if you hadn't had the flag set.
I know Windows 2000 throws an error when it encounters this flag.
I want to make sure my app is compatible with as many versions of windows (2k and later) as possible.
Is there a Microsoft reference that specifies each version of Windows' behaviour for this flag? In particular, I'd like something that validates my assumption that it has no effect at all on post-2k 32-bit Windows.
I can't speak to Windows 2000 or XP, but I know that on Vista and above, KEY_WOW64_64KEY opens the registry key in the 64bit registry if it's a 64bit OS and the 32bit registry if it's a 32bit OS.
According to this Windows page:
https://learn.microsoft.com/en-us/windows/win32/sysinfo/registry-key-security-and-access-rights?redirectedfrom=MSDN
Both
KEY_WOW64_32KEY (0x0200)
KEY_WOW64_64KEY (0x0100)
will be ignored on 32-bit Windows.
And those flags are not supported on Windows 2000.
I have tested on Windows XP 32 bit, and it seems to work OK.
Also, you should usually be avoiding this key - WOW64 provides a pretty complete "illusion" to 32-bit apps; just write your app properly on 32-bit without this flag, and it will still work on WOW64. Don't try to use this flag (and other mechanisms) to be "64-bit compatible".