Re: Enumerating 32-bit modules from 32-bit processes in WOW64

I will try very briefly to summarize how a 32-bit process is loaded.

- an EPROCESS is created, with the 32bit process `flag` set
- the image is mapped in the new address space
- the 64bit ntdll.dll is loaded
- the 64-bit ntdll.dll realizes this is a wow64 process
- it then loads the wow64 modules (wow64, wow64bin, wow64cpu)
and the wow64 modules runs the cpu simulation loop (let's not argue on
this name for now)
- the cpu simulation loop loads the 32-bit ntdll.dll, that carries on
process initialization as usual.
- during (32-bit) process initialization, ntdll loads the other modules
(from SysWoW64)

NtDll.dll is treated specially, given its role in process intialization.
So, to summarize, there are 2 list of modules for a 32-bit process under
wow,
and, 64-bit tlist.exe pointed to a 32-bit process clearly shows that.

The paths are always consistent for the "half of the world" that uses them.
Unless you disable redirection, opening `c:\windows\system32` from a 32-bit
process
will effectively go to `c:\windows\SysWOW64`, that is the correct result
from the point of view of the 32-bit process. Opening `c:\windows\syswow64`
is again correct for a 32-bit process.

However, as 64-bit process can be 32-bit aware, and, opening
`c:\windows\syswow64\xxx.dll` will really open the 32-bit binary,
and that may be expected and wanted, since 64-bit processes
can be designed to be aware of the wow64 subsystem, while
the coverse is not necessarely true.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Philip Sloss" <stuff@xxxxxxxxx> wrote in message
news:uBYP2IOcFHA.3120@xxxxxxxxxxxxxxxxxxxxxxx
> "Jochen Kalmbach [MVP]" <nospam-Jochen.Kalmbach@xxxxxxxxx> wrote in
message
> news:OxMdiXKcFHA.3504@xxxxxxxxxxxxxxxxxxxxxxx
> >
> > Maybe the the fact that some names have the sysWow64 path inside the
> > names is becuase of the way the DLL is loaded (maybe is it is inidrectly
> > loaded, the OS will have to find the correct one... and then it will use
> > the sywow64-directory). But this is just a assumption.
>
> Hi Jochen,
>
> I think that's a good assumption that this has to do with compatibility.
> This is one of those cases where I didn't find the "backwards
compatibility
> directive" to be an intuitive thing. And looking at a list of loaded
> modules for a couple of apps, the DLLs that point to "system32" do seem to
> be ones that tend to be loaded explicitly rather than implicitly. The
core
> Win32 libraries point to syswow64 (KERNEL, USER, GDI), as do a few others.
> NTDLL points to system32, but then that library is probably a special
case.
> The libraries that I'm loading explicitly (wtsapi32, iphlpapi,
> ws2_32/wsock32) point to system32.
>
> I'll probably invest a little time to check this out in more detail, but
> this behavior may prove to be useful if it provides an indication (even
it's
> not a guarantee) of how a 32-bit DLL was loaded.
>
> Thanks,
>
> Philip Sloss
>
>


.

Relevant Pages

  • Re: msbac.exe and .dll
    ... My apologies, I was trying to do many things at one time. ... I had tried to paste the malicious part of the code from the .dll, ... separate posts. ... Please summarize the problem if there is one. ...
    (microsoft.public.security.virus)
  • Re: Problems with DLL from Matlab
    ... Pascal Steiss wrote: ... So many things had to be done - I can't summarize it here... ... I'm having the exact same problem - dll works perfectly when called ...
    (comp.soft-sys.matlab)