[Bug 44924] New: StarForce v3 kernel drivers need ntoskrnl.IoCreateSynchronizationEvent to return a non-NULL handle

wine-bugs at winehq.org wine-bugs at winehq.org
Fri Apr 6 03:51:19 CDT 2018


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

            Bug ID: 44924
           Summary: StarForce v3 kernel drivers need
                    ntoskrnl.IoCreateSynchronizationEvent to return a
                    non-NULL handle
           Product: Wine
           Version: 3.5
          Hardware: x86
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ntoskrnl
          Assignee: wine-bugs at winehq.org
          Reporter: focht at gmx.net
      Distribution: ---

Hello folks,

as it says, the driver expects something non-NULL.

It can be a magic number for now since Wine doesn't implement any "kernel"
synchronization objects nor wait primitives.

Prior to the test-patch:

--- snip ---
...
0036:Call driver init 0x785300
(obj=0x11cc28,str=L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\sfhlp02") 
...
0036:Call
ntoskrnl.exe.IoCreateDevice(0011cc28,00000000,0065fc84,00009000,00000000,00000000,00783004)
ret=007850f8
0036:trace:ntoskrnl:IoCreateDevice (0x11cc28, 0, L"\\Device\\sfhlp02", 36864,
0, 0, 0x783004)
...
0036:Ret  ntoskrnl.exe.IoCreateDevice() retval=00000000 ret=007850f8
...
0036:trace:ntoskrnl:IoCreateSymbolicLink L"\\DosDevices\\sfhlp02" ->
L"\\Device\\sfhlp02"
...
0036:Call
ntoskrnl.exe.IoCreateDevice(0011cc28,00000000,0065fc7c,00009001,00000000,00000000,00783008)
ret=0078513f
0036:trace:ntoskrnl:IoCreateDevice (0x11cc28, 0, L"\\Device\\sfhlp02i", 36865,
0, 0, 0x783008)
...
0036:Ret  ntoskrnl.exe.IoCreateDevice() retval=00000000 ret=0078513f
0036:Call ntoskrnl.exe.IoCreateSymbolicLink(0065fc74,0065fc7c) ret=0078515b
0036:trace:ntoskrnl:IoCreateSymbolicLink L"\\DosDevices\\sfhlp02i" ->
L"\\Device\\sfhlp02i"
...
0036:Call ntoskrnl.exe.IoCreateSynchronizationEvent(0065fc80,0065fc8c)
ret=00785414
0036:fixme:ntoskrnl:IoCreateSynchronizationEvent (0x65fc80 0x65fc8c) stub
0036:Ret  ntoskrnl.exe.IoCreateSynchronizationEvent() retval=00000000
ret=00785414
...
0036:Call ntoskrnl.exe.IoDeleteDevice(0011ce58) ret=00785258
...
0036:Ret  ntoskrnl.exe.IoDeleteDevice() retval=00000001 ret=00785258
...
0036:Call ntoskrnl.exe.IoDeleteDevice(0011cd98) ret=0078526d
...
0036:Ret  ntoskrnl.exe.IoDeleteDevice() retval=00000001 ret=0078526d
0036:Ret  driver init 0x785300
(obj=0x11cc28,str=L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\sfhlp02")
retval=c000009a 
...
--- snip ---

With a patch that returns 0xcafebabe, resulting in driver running further and
calling 'ntoskrnl.exe.KeWaitForSingleObject( 0xcafebabe, ...)':

--- snip ---
...
0035:Call driver init 0x785300
(obj=0x11caf0,str=L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\sfhlp02") 
...
035:Call ntoskrnl.exe.IoCreateSynchronizationEvent(0065fc80,0065fc8c)
ret=00785414
0035:fixme:ntoskrnl:IoCreateSynchronizationEvent (0x65fc80 0x65fc8c) stub
0035:Ret  ntoskrnl.exe.IoCreateSynchronizationEvent() retval=cafebabe
ret=00785414
0035:Call ntoskrnl.exe.KeEnterCriticalRegion() ret=0078542c
0035:fixme:ntoskrnl:KeEnterCriticalRegion : stub
0035:Ret  ntoskrnl.exe.KeEnterCriticalRegion() retval=00000031 ret=0078542c
0035:Call
ntoskrnl.exe.KeWaitForSingleObject(cafebabe,00000000,00000000,00000000,00000000)
ret=00785437
0035:fixme:ntoskrnl:KeWaitForSingleObject stub: 0xcafebabe, 0, 0, 0, (nil)
0035:Ret  ntoskrnl.exe.KeWaitForSingleObject() retval=c0000002 ret=00785437
0035:Call ntoskrnl.exe.RtlInitUnicodeString(0065fc78,007853ac
L"\\Callback\\StarForceCreateThread") ret=00785442
0035:Call ntdll.RtlInitUnicodeString(0065fc78,007853ac
L"\\Callback\\StarForceCreateThread") ret=7bc7f41b
0035:Ret  ntdll.RtlInitUnicodeString() retval=0065fc78 ret=7bc7f41b
0035:Ret  ntoskrnl.exe.RtlInitUnicodeString() retval=0065fc78 ret=00785442
0035:Call ntoskrnl.exe.ExCreateCallback(0065fc88,0065fc60,00000000,00000001)
ret=00785472
0035:fixme:ntoskrnl:ExCreateCallback (0x65fc88, 0x65fc60, 0, 1): stub
0035:Ret  ntoskrnl.exe.ExCreateCallback() retval=c0000002 ret=00785472
0035:Call ntoskrnl.exe.ZwClose(00783014) ret=007854ee
0035:Call ntdll.NtClose(00783014) ret=7bc7f41b
0035:Ret  ntdll.NtClose() retval=c0000008 ret=7bc7f41b
0035:Ret  ntoskrnl.exe.ZwClose() retval=c0000008 ret=007854ee
0035:Call ntoskrnl.exe.KeLeaveCriticalRegion() ret=007854f4
0035:fixme:ntoskrnl:KeLeaveCriticalRegion : stub
0035:Ret  ntoskrnl.exe.KeLeaveCriticalRegion() retval=00000031 ret=007854f4
0035:Call ntoskrnl.exe.IoAllocateErrorLogEntry(0011caf0,00000030) ret=0078103a
0035:fixme:ntoskrnl:IoAllocateErrorLogEntry stub: 0x11caf0, 48
0035:Ret  ntoskrnl.exe.IoAllocateErrorLogEntry() retval=00000000 ret=0078103a 
...
0035:Ret  driver init 0x785300
(obj=0x11caf0,str=L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\sfhlp02")
retval=c0000002
...
0035:Ret  ntoskrnl.exe.IoCreateDriver() retval=c0000002 ret=7effb786
0035:err:winedevice:async_create_driver failed to create driver L"sfhlp02":
c0000002 
--- snip ---

The driver is still failing, but that's another problem.

Anyway, at some point in future one should think about properly emulating
kernel-level synchronization objects. It's not very hard to do.
Wine doesn't need to follow/mimic the exact structure layouts for Windows
kernel objects by design.
The structs would just wrap native API synchronization objects and the actual
sync APIs, such as KeWaitXXX, KeEnterXXX ... would call corresponding native
NtXXX API (NtWaitXXX, ...).
See also bug 44588 (ntoskrnl.exe.KeWaitForMultipleObjects) and related ones.

$ sha1sum tmsunrisedemo_setup.exe 
2d44577a71718464c595d9da91a017fb0914afc4  tmsunrisedemo_setup.exe

$ du -sh tmsunrisedemo_setup.exe 
210M    tmsunrisedemo_setup.exe

$ wine --version
wine-3.5-91-g3263d51a1f

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