On 07/05/2010 11:53 AM, Ilya Basin wrote:
> I Wonder why our package maintainers didn't mark prelink as
> makedepends.
Report that as a bug to your distro.
> Maybe it's not 100% reliable?
It is 100% reliable, if prelink works of course.
> For example if one of the wine's dependencies, say, libpth
On 07/04/2010 12:08 PM, James McKenzie wrote:
> Marcus Meissner wrote:
>> kernel32 is also loaded to the same base address.
> Is there a good reason for this? Otherwise, this opens a security
> vulnerability in Wine that does not exist in Windows
Yes, safedisk.
Vitaliy
TC> In that case you should check if you have prelink installed and
TC> then configure and build wine.
Kinda works. kernel32 and user32 seem to be on their places.
I Wonder why our package maintainers didn't mark prelink as
makedepends. Maybe it's not 100% reliable? For example if one of the
wine'
Andrey Turkin wrote:
On Sunday 04 July 2010 22:31:49 Dan Kegel wrote:
the Makefile has:
EXTRADLLFLAGS = -Wb,-F,KERNEL32.dll -Wl,--image-base,0x7b80
Is there a good reason for this? Otherwise, this opens a security
vulnerability in Wine that does not exist in Windows
On Sunday 04 July 2010 12:10:36 Ilya Basin wrote:
>>> int main() {
>>> HMODULE hKernel32 = GetModuleHandle("kernel32.dll");
>>> printf("0x%8x\n", hKernel32);
>>> }
>>>
>>> [...@il winetest]$ wine a.exe
>>> 0x7edf
>>> [...@il winetest]$ wine a.exe
>>> 0x7edf
>>> [...@il winetest]$ wine a
On Sunday 04 July 2010 22:31:49 Dan Kegel wrote:
> >> the Makefile has:
> >> EXTRADLLFLAGS = -Wb,-F,KERNEL32.dll -Wl,--image-base,0x7b80
> >
> >Is there a good reason for this? Otherwise, this opens a security
> >vulnerability in Wine that does not exist in Windows
>
> This is the way Win
>> the Makefile has:
>> EXTRADLLFLAGS = -Wb,-F,KERNEL32.dll -Wl,--image-base,0x7b80
>
>Is there a good reason for this? Otherwise, this opens a security
>vulnerability in Wine that does not exist in Windows
This is the way Windows worked before Vista.
(Does Vista actually randomize where
Marcus Meissner wrote:
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 al
>> int main() {
>> HMODULE hKernel32 = GetModuleHandle("kernel32.dll");
>> printf("0x%8x\n", hKernel32);
>> }
>>
>> [...@il winetest]$ wine a.exe
>> 0x7edf
>> [...@il winetest]$ wine a.exe
>> 0x7edf
>> [...@il winetest]$ wine a.exe
>> 0x7ede
TC> Is this on Linux?
yes
--
On Sunday 04 July 2010 09:14:14 Илья Басин wrote:
> 2010/7/4 Marcus Meissner
>> 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
2010/7/4 Marcus Meissner
> 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 th
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
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 W
13 matches
Mail list logo
