>> >>>It's a common technique to rely on the fact that exports from kernel32
>> >>>reside at the same address to use CreateRemoteThread calling LoadLibrary
>> >>>for remote code injection (this is not what Vitaliy's App is doing here
>> >>>but the assertions are the same).
>> >>It's hard to implem
> >>>It's a common technique to rely on the fact that exports from kernel32
> >>>reside at the same address to use CreateRemoteThread calling LoadLibrary
> >>>for remote code injection (this is not what Vitaliy's App is doing here
> >>>but the assertions are the same).
> >>It's hard to implement t
Kuba Ober wrote:
On Sunday 07 August 2005 10:13, Mike McCormack wrote:
http://www.codeguru.com/Cpp/W-P/system/processesmodules/article.php/c5767
/
says:
> When creating a process, the loader on Win 2000, Win XP and Win 2003
> checks if kernel32.dll and user32.dll (their names are hardcoded
On Sunday 07 August 2005 10:13, Mike McCormack wrote:
> > http://www.codeguru.com/Cpp/W-P/system/processesmodules/article.php/c5767
> >/
> >
> > says:
> > > When creating a process, the loader on Win 2000, Win XP and Win 2003
> > > checks if kernel32.dll and user32.dll (their names are hardcoded
Mike McCormack wrote:
You might be able to do it by staticly linking ntdll, kernel32 and
user32 with wine-pthread/wine-kthread, and fixing the binary's address
in memory, though that would probably be quite a bit of work.
Mike
This is not a bad Idea for other stuff as well one thing that
http://www.codeguru.com/Cpp/W-P/system/processesmodules/article.php/c5767/
says:
> When creating a process, the loader on Win 2000, Win XP and Win 2003
> checks if kernel32.dll and user32.dll (their names are hardcoded into
> the loader) are mapped at their preferred bases; if not, a hard e
Vitaliy Margolen wrote:
You could "fix" it for a specific dll by reserving a memory area using
the wine-preloader, but that would be a hack.
I think you missing the point. I'm not talking about separate runs of wine.
I'm talking about one instance with parent & child processes. I would assume
Saturday, August 6, 2005, 11:24:05 PM, Mike McCormack wrote:
>> app1.exe: GetProcAddress(mKernel32, "LoadLibraryA") returns 0x404FCBCC
>> app2.exe: GetProcAddress(mKernel32, "LoadLibraryA") returns 0x404FFBCC
>> Is there are any reason why this is happening? Any ways to fix this?
> Under Windows
Mike McCormack wrote:
Yes it is. NTDLL and KERNEL32 are both mapped to always the same
address on >=NT4 (in NT3 only NTDLL was at a fixed address however).
KERNEL32 and NTDLL are special cases because they are loaded first when
the address space is empty, and since the NT kernel has no address
Felix Nawothnig wrote:
Yes it is. NTDLL and KERNEL32 are both mapped to always the same address
on >=NT4 (in NT3 only NTDLL was at a fixed address however).
KERNEL32 and NTDLL are special cases because they are loaded first when
the address space is empty, and since the NT kernel has no add
Mike McCormack wrote:
Is there are any reason why this is happening? Any ways to fix this?
Under Windows 98, you will always get the same address for the same
export from a dll, however that's not garanteed under Windows NT (or Wine).
Yes it is. NTDLL and KERNEL32 are both mapped to always the
Vitaliy Margolen wrote:
app1.exe: GetProcAddress(mKernel32, "LoadLibraryA") returns 0x404FCBCC
app2.exe: GetProcAddress(mKernel32, "LoadLibraryA") returns 0x404FFBCC
Is there are any reason why this is happening? Any ways to fix this?
Under Windows 98, you will always get the same address
Found an interesting inconsistency with GetProcAddress between wine and native.
On windows GetProcAddress of that's say "LoadLibraryA" exported from kernel32
always returns the same address, no matter which process it's called from.
On wine it's different. That's say there are two programs app1.ex
13 matches
Mail list logo
