[Bug 44910] New: BattlEye 'BEDaisy' kernel service fails in driver entry point due to ' ntoskrnl.exe.ObReferenceObjectByHandle' stub (needs STATUS_SUCCESS)
wine-bugs at winehq.org
wine-bugs at winehq.org
Wed Apr 4 17:15:13 CDT 2018
https://bugs.winehq.org/show_bug.cgi?id=44910
Bug ID: 44910
Summary: BattlEye 'BEDaisy' kernel service fails in driver
entry point due to
'ntoskrnl.exe.ObReferenceObjectByHandle' stub (needs
STATUS_SUCCESS)
Product: Wine
Version: 3.5
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ntoskrnl
Assignee: wine-bugs at winehq.org
Reporter: focht at gmx.net
Distribution: ---
Hello folks,
continuation of bug 44907
Prerequisite:
* bug 44837 -> missing
'ntoskrnl.exe.Ps{Acquire,Release}ProcessExitSynchronization'
* bug 44906 -> missing 'ntoskrnl.exe.ExfUnblockPushLock'
* bug 44907 -> missing 'fltmgr.sys.FltGetRoutineAddress'
Unlike the other bug reports, I added +server debug channel to show which
handle is being dereferenced.
--- snip ---
$ WINEDEBUG=+seh,+relay,+ntoskrnl,+server wine net start BEDaisy >>log.txt 2>&1
...
0033:Call driver init 0x78d000
(obj=0x11cb00,str=L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\BEDaisy")
...
0033:Call
ntoskrnl.exe.PsCreateSystemThread(0065ec4c,001fffff,0065ec50,00000000,00000000,0078308e,00000000)
ret=0080858c
0033:Call
ntdll.RtlCreateUserThread(ffffffff,00000000,00000000,00000000,00000000,00000000,0078308e,00000000,0065ec4c,00000000)
ret=7ec1823e
0033: *fd* 21 <- 145
0033: new_thread( access=001fffff, attributes=00000000, suspend=0,
request_fd=21 )
0033: new_thread() = 0 { tid=0035, handle=0040 }
0033:Ret ntdll.RtlCreateUserThread() retval=00000000 ret=7ec1823e
0033:Ret ntoskrnl.exe.PsCreateSystemThread() retval=00000000 ret=0080858c
0033:Call
ntoskrnl.exe.ObReferenceObjectByHandle(00000040,001fffff,00000000,00000000,0078b55c,00000000)
ret=007840d4
0033:fixme:ntoskrnl:ObReferenceObjectByHandle stub: 0x40 1fffff (nil) 0
0x78b55c (nil)
0033:Ret ntoskrnl.exe.ObReferenceObjectByHandle() retval=c0000002 ret=007840d4
0033:Call ntoskrnl.exe.KeSetEvent(0078b3f4,00000000,00000000) ret=00790914
0033:fixme:ntoskrnl:KeSetEvent (0x78b3f4, 0, 0): stub
0033:Ret ntoskrnl.exe.KeSetEvent() retval=00000000 ret=00790914
0033:Call ntoskrnl.exe.ZwClose(00000040) ret=007f2c73
0033:Call ntdll.NtClose(00000040) ret=7bc803ab
0033: close_handle( handle=0040 )
0033: close_handle() = 0
0033:Ret ntdll.NtClose() retval=00000000 ret=7bc803ab
0033:Ret ntoskrnl.exe.ZwClose() retval=00000000 ret=007f2c73
0033:Call fltmgr.sys.FltUnregisterFilter(deadbeaf) ret=007fd488
0033:fixme:fltmgr:FltUnregisterFilter (0xdeadbeaf): stub
0033:Ret fltmgr.sys.FltUnregisterFilter() retval=00000039 ret=007fd488
0033:Call ntoskrnl.exe.PsRemoveCreateThreadNotifyRoutine(0078130c) ret=0082f2bc
0033:fixme:ntoskrnl:PsRemoveCreateThreadNotifyRoutine stub: 0x78130c
0033:Ret ntoskrnl.exe.PsRemoveCreateThreadNotifyRoutine() retval=00000000
ret=0082f2bc
0033:Call ntoskrnl.exe.PsRemoveLoadImageNotifyRoutine(00781dc6) ret=008242ab
0033:fixme:ntoskrnl:PsRemoveLoadImageNotifyRoutine stub: 0x781dc6
0033:Ret ntoskrnl.exe.PsRemoveLoadImageNotifyRoutine() retval=00000000
ret=008242ab
0033:Call
ntoskrnl.exe.KeWaitForSingleObject(0078b530,00000000,00000000,00000000,00000000)
ret=0080b669
0033:fixme:ntoskrnl:KeWaitForSingleObject stub: 0x78b530, 0, 0, 0, (nil)
0033:Ret ntoskrnl.exe.KeWaitForSingleObject() retval=c0000002 ret=0080b669
0033:Call ntoskrnl.exe.ObUnRegisterCallbacks(deadbeaf) ret=007ac56b
0033:fixme:ntoskrnl:ObUnRegisterCallbacks stub: 0xdeadbeaf
0033:Ret ntoskrnl.exe.ObUnRegisterCallbacks() retval=0000003b ret=007ac56b
0033:Call ntoskrnl.exe.KeReleaseMutex(0078b530,00000000) ret=00839822
0033:fixme:ntoskrnl:KeReleaseMutex stub: 0x78b530, 0
0033:Ret ntoskrnl.exe.KeReleaseMutex() retval=c0000002 ret=00839822
0033:Call ntoskrnl.exe.IoDeleteSymbolicLink(0065ec74) ret=0080d6dc
0033:Call ntdll.NtOpenSymbolicLinkObject(0065eb40,00000000,0065eb28)
ret=7ec158ab
0033: open_symlink( access=00000000, attributes=00000040, rootdir=0000,
name=L"\\DosDevices\\BattlEye" )
0033: open_symlink() = 0 { handle=0044 }
0033:Ret ntdll.NtOpenSymbolicLinkObject() retval=00000000 ret=7ec158ab
0033: unlink_object( handle=0044 )
0033: unlink_object() = 0
0033:Call ntdll.NtClose(00000044) ret=7ec15924
0033: close_handle( handle=0044 )
0033: close_handle() = 0
0033:Ret ntdll.NtClose() retval=00000000 ret=7ec15924
0033:Ret ntoskrnl.exe.IoDeleteSymbolicLink() retval=00000000 ret=0080d6dc
0033:Call ntoskrnl.exe.IoDeleteDevice(0011cce0) ret=00867fef
0033:trace:ntoskrnl:IoDeleteDevice 0x11cce0
0033: delete_device( handle=0038 )
0033: delete_device() = 0
0033:Call ntdll.NtClose(00000038) ret=7ec15773
0033: close_handle( handle=0038 )
0033: close_handle() = 0
0033:Ret ntdll.NtClose() retval=00000000 ret=7ec15773
...
0033:Ret ntoskrnl.exe.IoDeleteDevice() retval=00000001 ret=00867fef
0033:Ret driver init 0x78d000
(obj=0x11cb00,str=L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\BEDaisy")
retval=c0000002
...
0033:Ret ntoskrnl.exe.IoCreateDriver() retval=c0000002 ret=7effb832
0033:err:winedevice:async_create_driver failed to create driver L"BEDaisy":
c0000002
--- snip ---
MSDN:
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/wdm/nf-wdm-obreferenceobjectbyhandle
One of MS official kernel driver examples, illustrating how the API is meant to
be used here (general pattern for getting thread object pointer):
https://github.com/Microsoft/Windows-driver-samples/blob/master/general/cancel/sys/cancel.c
--- snip ---
...
status = PsCreateSystemThread(&threadHandle,
(ACCESS_MASK)0,
NULL,
(HANDLE) 0,
NULL,
CsampPollingThread,
deviceObject );
if ( !NT_SUCCESS( status ))
{
IoDeleteSymbolicLink( &unicodeDosDeviceName );
IoDeleteDevice( deviceObject );
return status;
}
//
// Convert the Thread object handle into a pointer to the Thread object
// itself. Then close the handle.
//
ObReferenceObjectByHandle(threadHandle,
THREAD_ALL_ACCESS,
NULL,
KernelMode,
&devExtension->ThreadObject,
NULL );
ZwClose(threadHandle);
...
--- snip ---
NOTE: Unlike the snippet shown above, 'BEDaisy' driver checks the return value
of 'ObReferenceObjectByHandle' and initiates teardown on failure.
For testing I simply returned 'STATUS_SUCCESS' but also set the object pointer
to a magic value (if ptr is non-NULL). The idea is when the driver tries to
access/dereference the pointer we can easily see that a "poor" man's "succeed"
stub is not enough.
It seems it doesn't need a real thread object for now and runs much further.
$ sha1sum Tibia_Setup.exe
50951008ccc402cc32407bfc56a88da873e3e9bd Tibia_Setup.exe
$ du -sh Tibia_Setup.exe
5.2M Tibia_Setup.exe
$ wine --version
wine-3.5-107-gf4573adb0f
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