Re: base addresses of kernel32
On Sun, Jul 04, 2010 at 10:04:01AM +0400, Илья Басин wrote: > One widely used dll injection technique is copying the dll path to the > target process memory and calling CreateRemoteThread() using the address of > LoadLibraryA as lpStartAddress. This relies on the fact that all processes > have the same base address of kernel32.dll (and some other system dlls). > On Wine only ntdll is always loaded to the same base address, so it's > potentially possible to do the same for kernel32, right? kernel32 is also loaded to the same base address. (the Makefile has: EXTRADLLFLAGS = -Wb,-F,KERNEL32.dll -Wl,--image-base,0x7b80 ) Are you seeing otherwise? Ciao, Marcus
base addresses of kernel32
One widely used dll injection technique is copying the dll path to the target process memory and calling CreateRemoteThread() using the address of LoadLibraryA as lpStartAddress. This relies on the fact that all processes have the same base address of kernel32.dll (and some other system dlls). On Wine only ntdll is always loaded to the same base address, so it's potentially possible to do the same for kernel32, right?
The annoying FAQ of detecting Wine
Unfortunately, this is a FAQ, so I've added it. I based the answer on the last time this came around on wine-users; I'm not a developer, so please sanity-check what I wrote! Hopefully this will be useful in dealing with the actual problems people think they can solve by doing this. http://wiki.winehq.org/FAQ#head-9c045f5ff1df8a1afef91e1152ca7f6a9684f116 8.6. I write a Windows app. How can it detect if it's running under Wine? This is a bad idea. The goal of Wine is that an application will be unable to tell it's running under Wine rather than Windows. So any method to detect running under Wine is unsupported and may break without warning in the future. Wine should not be treated as a "version" of Windows - functionality or performance-tuning is likely to be different between any two development versions. Rather than detecting Wine: * Detect if functionality exists and use it when available. * File a bug if something works in Windows that does not work in Wine. * Ask for help on the developers' list. That said: if you really want to detect Wine, try, e.g., running a native binary or syscall (AppArmor or SELinux may block this), reading the environment, accessing a function (e.g ntdll.get_wine_version() ) or registry key only found in Wine. Any of these may break at any time. Asking the user directly if they are running the app under Wine will be more reliable than trying to automatically detect it. - d.
FAQ just updated and copyedited
Just went through the FAQ, copyediting, tweaking and bringing things into the present: http://wiki.winehq.org/FAQ?action=diff&rev2=347&rev1=346 Please sanity-check :-) - d.
Re: Why some gdi32 calls aren't caught in relay while some are caught?
On 07/01/2010 12:55 PM, Hayan Lee wrote: > Wine doc says relay supports user32, ntdll, etc, but not gdi32. > However when I run wine, some gdi32 calls are caught, e.g, CreateBitmap() > But some aren't caught, e.g, CreateBitmapIndirect() See RelayFromExclude in http://wiki.winehq.org/UsefulRegistryKeys that will exclude all internal calls to listed dlls from relay output. Default Wine setup has that key set to "winex11.drv;user32;gdi32;advapi32;kernel32". Also note that some exports are marked as -norelay in .spec file. You won't get any relay output for such functions. Vitaliy.
