On May 24 07:27, Ryan Johnson wrote:
On 23/05/2011 3:31 AM, Corinna Vinschen wrote:
On May 22 14:42, Ryan Johnson wrote:
In theory, this should completely eliminate the case where us
loading one DLL pulls in dependencies automatically (= uncontrolled
and at Windows' whim). The problem would manifest as a DLL which
"loads" in the same wrong place repeatedly when given the choice,
and for which we would be unable to VirtualAlloc the offending spot
(because the dll in question has non-zero refcount even after we
unload it, due to the dll(s) that depend on it.
There might be a way around this. It seems to be possible to tweak
the module list the PEB points to so that you can unload a library
even though it has dependencies. Then you can block the unwanted
space and call LoadLibrary again. See (*) for a discussion how
you can unload the exe itself to reload another one. Maybe that's
something we can look into as well. ObNote: Of course, if we
could influnce the address at which a DLL gets loaded right from the
start, it would be the preferrable solution.
Corinna
(*) http://www.blizzhackers.cc/viewtopic.php?p=4332690
After poking around at (*) a bit, it looks like NtMapViewOfSection
does more than I would have expected wrt dll loading. However, when
I tried to fire up a toy program to test it, NtOpenSection always
returns C0000024, regardless of whether I pass OBJ_KERNEL_HANDLE to
it.
Does anybody have experience with those two functions?
The Cygwin source code, for instance, is using this function, see
fhandler_mem.cc.
C0000024 is STATUS_OBJECT_TYPE_MISMATCH. I didn't see the error before,
but I have a vague idea why you get it. Are you by any chance trying to
call NtOpenSection with the OBJECT_ATTRIBUTES set to the file? If so,
that's wrong. The OBJECT_ATTRIBUTES names the attributes of the section,
including its name if it has one. It does not specify the file you're
trying to map. What you're looking for is NtCreateSection. It has an
extra parameter to specify the handle to an open file.