[Bug 37355] New: Tages Protection v5.x needs ntoskrnl 'MmMapLockedPagesSpecifyCache' implementation

wine-bugs at winehq.org wine-bugs at winehq.org
Thu Oct 2 16:06:58 CDT 2014


https://bugs.winehq.org/show_bug.cgi?id=37355

            Bug ID: 37355
           Summary: Tages Protection v5.x needs ntoskrnl
                    'MmMapLockedPagesSpecifyCache' implementation
           Product: Wine
           Version: 1.7.27
          Hardware: x86-64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ntoskrnl
          Assignee: wine-bugs at winehq.org
          Reporter: focht at gmx.net

Hello folks,

reported here: https://github.com/compholio/wine-compholio/issues/80

Michael Müller from FDS team:

--- quote ---
Sadly this is not enough to make the Tages copy protection happy. The issue you
are now running into is:

fixme:ntoskrnl:MmMapLockedPagesSpecifyCache (0x111988, 0, 1, (nil), 0, 32):
stub

The MmMapLockedPagesSpecifyCache command is used to map memory of a process
into the kernel, so that a kernel driver can write / read it. This is necessary
since the kernel does not share the same address space as the process. The
problem is that this command is a stub and always returns 0 as mapped address.
The Tages protection does not check for NULL pointers and tries to write to the
address resulting in:

wine: Unhandled page fault on write access to 0x00000000 at address 0x57fe27
(thread 0018), starting debugger...

The problem is that there is no way to properly implement this on Linux since
there is no way to simply map the memory of a different process if you are not
inside the kernel. Since wine is no kernel module it can only use memory of
different processes, when they explicitly create it as shared memory block.
Sadly you can not declare a memory block as shared after it was allocated, so
this does not help implementing this command.

Anyway in the case of the Tages protection we have some luck since it seems
like the process is paused (I think it was waiting for the response of the
DeviceIoControl function) while the memory is changed by the windows kernel
driver. This allows us to emulate the mapping of the memory by using
ReadProcessMemory and WriteProcessMemory. I wrote some hack to implement this,
but this only prevented the crash and made the application to exit silently. I
either made a mistake in my hack or there is still something else which
prevents it from working.
--- quote ---

Regards

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.


More information about the wine-bugs mailing list