[Bug 24081] New: Garena is not opening

http://bugs.winehq.org/show_bug.cgi?id=24081

Summary: Garena is not opening
           Product: Wine
           Version: 1.3.1
          Platform: x86
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: -unknown
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

Created an attachment (id=30292)
 --> (http://bugs.winehq.org/attachment.cgi?id=30292)
This is the execution output on terminal with WINEDEBUG=warn+all

Garena is not loading properly. It crashes before showing anything.
The client is available to download freely, and have no dependences.
Here you can find the client: http://www.garena.com

[Bug 24081] Garena is not opening

http://bugs.winehq.org/show_bug.cgi?id=24081

--- Comment #1 from Fernando   2010-08-22 06:47:16 ---
(From update of attachment 30292)
This is the output while trying to run it on Ubuntu 10.04 and Wine 1.3.1

[Bug 24081] Garena crashes

http://bugs.winehq.org/show_bug.cgi?id=24081

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
            Summary|Garena is not opening       |Garena crashes
              Alias|Garena                      |
           Severity|critical                    |normal

--- Comment #2 from Dmitry Timoshkov   2010-08-22 08:08:32 ---
http://bugs.winehq.org/page.cgi?id=fields.html#bug_severity

[Bug 24081] Garena crashes

http://bugs.winehq.org/show_bug.cgi?id=24081

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |download
           Priority|P2                          |P3
                URL|                            |http://www.garena.com

--- Comment #3 from Austin English   2010-08-22 09:15:33 ---
Please attach plain terminal output.

[Bug 24081] Garena crashes (ntoskrnl: out buf length from driver ioctl dispatch used despite error condition)

http://bugs.winehq.org/show_bug.cgi?id=24081

Anastasius Focht  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]
          Component|-unknown                    |ntoskrnl
            Summary|Garena crashes              |Garena crashes (ntoskrnl:
                   |                            |out buf length from driver
                   |                            |ioctl dispatch used despite
                   |                            |error condition)

--- Comment #4 from Anastasius Focht   2010-08-22 11:24:16 ---
Hello,

looks like some anti-cheat software protection.
There is a kernel service "GarenaPEngine" dynamically loaded and started:

--- snip ---
0016:Call KERNEL32.CreateProcessW(00000000,00118548
L"C:\windows\system32\winedevice.exe
GarenaPEngine",00000000,00000000,00000000,00000000,00000000,00000000,0073e55c,0073e5a0)
ret=68340f38 
...
0026:Call KERNEL32.LoadLibraryW(0011a610
L"C:\users\focht\Temp\HDR24d4.tmp") ret=6833c7f9 
...
0026:Ret  KERNEL32.LoadLibraryW() retval=00540000 ret=6833c7f9 
...
0026:Call ntdll.RtlInitUnicodeString(0053e72c,005415bc
L"\Device\GG_Protector") ret=005407f8
0026:Ret  ntdll.RtlInitUnicodeString() retval=00000028 ret=005407f8
...
ntoskrnl.exe.IoCreateDevice(6833e5c0,00000100,0053e72c,00008fc7,00000000,00000000,0053e734)
ret=00540823 
...
0026:Call ntoskrnl.exe.MmGetSystemRoutineAddress(0053e710) ret=00540914
...
0026:Call KERNEL32.GetProcAddress(683a0000,0011d178
"PsGetProcessImageFileName") ret=683bb5b0
0026:Ret  KERNEL32.GetProcAddress() retval=683b4294 ret=683bb5b0
...
0026:Ret  ntoskrnl.exe.MmGetSystemRoutineAddress() retval=683b4294 ret=00540914 
...
0026:Call ntoskrnl.exe.PsSetCreateProcessNotifyRoutine(00540614,00000000)
ret=00540861
0026:fixme:ntoskrnl:PsSetCreateProcessNotifyRoutine stub: 0x540614 0
0026:Ret  ntoskrnl.exe.PsSetCreateProcessNotifyRoutine() retval=00000000
ret=00540861 
...
--- snip ---

Client opens the device link and issues initial ioctl (0x8FC7A244):

--- snip ---
0009:Call KERNEL32.CreateFileW(02b14700
L"\\.\GG_PROTECTOR",c0000000,00000000,00000000,00000003,00000004,00000000)
ret=02b05af3
0009:Ret  KERNEL32.CreateFileW() retval=0000013c ret=02b05af3 
...
0009:Call
KERNEL32.DeviceIoControl(0000013c,8fc7a244,02b36c30,00000008,00000000,00000000,00328a14,00000000)
ret=02b05c55
0026:Ret  KERNEL32.WaitForMultipleObjects() retval=00000001 ret=683baf76 
...
0026:Call driver dispatch 0x540486 (device=0x11d558,irp=0x53e7e0)
0026:Call hal.KeGetCurrentIrql() ret=005404a3
0026:fixme:ntoskrnl:KeGetCurrentIrql  stub!
0026:Ret  hal.KeGetCurrentIrql() retval=00000000 ret=005404a3
0026:Call
ntoskrnl.exe.KeWaitForSingleObject(005437e0,00000000,00000000,00000000,00000000)
ret=00540a4f
0026:fixme:ntoskrnl:KeWaitForSingleObject stub: 0x5437e0, 0, 0, 0, (nil)
0026:Ret  ntoskrnl.exe.KeWaitForSingleObject() retval=c0000002 ret=00540a4f
0026:trace:ntoskrnl:__regs_IofCompleteRequest 0x53e7e0 0
0026:trace:ntoskrnl:IoCompleteRequest 0x53e7e0 0
0026:Ret  driver dispatch 0x540486 (device=0x11d558,irp=0x53e7e0)
retval=00000000
0026: get_next_device_request( manager=003c, prev=0000, status=c0000005,
prev_data={} )
0026: get_next_device_request() = PENDING { next=0000, code=00000000,
user_ptr=00000000, in_size=0, out_size=0, next_data={} }
0026:Call KERNEL32.WaitForMultipleObjects(00000002,0053e908,00000000,ffffffff)
ret=68215f76
0026: select( flags=4, cookie=0053e4fc, signal=0000, prev_apc=0000,
timeout=infinite, result={}, handles={0034,003c} )
0026: select() = PENDING { timeout=infinite, call={APC_NONE}, apc_handle=0000 }
001d:err:ntdll:RtlpWaitForCriticalSection section 0x7bca2604
"../../../wine-git/dlls/ntdll/loader.c: loader_section" wait timed out in
thread 001d, blocked by 0009, retrying (60 sec)
--- snip ---

After return from driver dispatch, get_next_device_request() should unblock the
waiting ioctl request from client.
This fails, resulting in another get_next_device_request() round-trip (see the
one with status=c0000005), finally getting stuck on STATUS_PENDING.
Because the client never returns from device ioctl call (ioctl data not set ->
pending request not satisfied), the whole thing hangs.

Took me a while to find out the cause .. this driver stuff isn't easy to debug
because the client will continue to go further when the service start is
delayed, not issuing device i/o controls (you have to attach fast and set bp
into driver entry with some magic O_o).

The server call (the one with status=c0000005) after driver dispatch return is
actually the result of an earlier server call failing.
I noticed that when doing an strace on the whole thing.
Ntdll's send_request() -> wineserver pipe write failed with -EFAULT.
Going back I noticed the request header size had an insane value of 1431655765.
Converting to hex gives: 0x55555555 ... ring a bell? Sure, its the IRP magic
filler value.

--- snip dlls/ntoskrnl.exe/ntoskrnl.c ---
static NTSTATUS process_ioctl( DEVICE_OBJECT *device, ULONG code, void
*in_buff, ULONG in_size,
                               void *out_buff, ULONG *out_size )
...
    *out_size = (irp.IoStatus.u.Status >= 0) ? irp.IoStatus.Information : 0;
...
--- snip dlls/ntoskrnl.exe/ntoskrnl.c ---

The driver returns ntstatus 0xc0000002 from its dispatcher (due to stubs).
As you see in code snippet this results in unmodified out length field being
taken for real (the driver did not touch it).
This value is passed further, resulting in failing wine_server_call() finally
ending up blocking the client.

With that problem fixed, the client starts up and gives login.

=========
> From a quick glance at the driver code: technically this is not really going to

work (if client really depends on functional driver, answering ioctls with
proper data).
The driver supervises SSDT (watching for ring0 hookers) is something Wine's
architecture doesn't support.
Additionally it uses several _low_ level functionality to peek deeply into
kernel structures (KPROCESS, KTHREAD).

=========

For a short workaround see appdb -> a user posted a script which just kills the
service after start:

--- snip ---
#!/bin/bash
export WINEDEBUG=-all
wine Garena.exe &

sleep 5
ret=`ps ax | grep GarenaPEngine`
pid=${ret%% *}
kill -9 $pid
--- snip ---

Regards

[Bug 24081] Garena crashes (ntoskrnl: out buf length from driver ioctl dispatch used despite error condition)

http://bugs.winehq.org/show_bug.cgi?id=24081

--- Comment #5 from Fernando   2010-08-25 17:57:33 ---
Can we patch the client with this info?

[Bug 24081] Garena crashes (ntoskrnl: out buf length from driver ioctl dispatch used despite error condition)

http://bugs.winehq.org/show_bug.cgi?id=24081

--- Comment #6 from Fernando  2010-09-07 08:10:38 CDT ---
As a workaround you can follow what is discussed on this topic:
http://forum.winehq.org/viewtopic.php?t=9468

I could play a DotA match on Garena, by only making my startup shortcut for
Garena be: 
env WINEPREFIX="/home/fernando/.wine" wine C:\Arquivos\ de\
programas\Garena\Garena.exe && killall winedevice.exe

I really don't have any idea of how killing winedevice.exe could make the
client startup, but it really worked for me.
The system that I used was Ubuntu 10.04 and wine 1.3.2, and the client were the
Garena client downloaded at 06/September/2010

[Bug 24081] Garena crashes (ntoskrnl: out buf length from driver ioctl dispatch used despite error condition)

http://bugs.winehq.org/show_bug.cgi?id=24081

Saulius K.  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 24081] Garena crashes (ntoskrnl: out buf length from driver ioctl dispatch used despite error condition)

http://bugs.winehq.org/show_bug.cgi?id=24081

Anastasius Focht  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |ABANDONED

--- Comment #7 from Anastasius Focht  2011-12-21 17:33:20 CST ---
Hello,

it seems with newer Garena client they use a different kernel driver now:

--- snip ---
002b:trace:winedevice:ServiceMain starting service L"GGSAFERDriver"
002b:trace:winedevice:load_driver loading driver L"C:\Program Files\Garena
Classic\safedrv.sys"
002b:fixme:ntoskrnl:MmGetSystemRoutineAddress L"ObRegisterCallbacks" not found
002b:fixme:ntoskrnl:MmGetSystemRoutineAddress L"ObUnRegisterCallbacks" not
found
002b:fixme:ntoskrnl:KeInitializeEvent stub: 0x1135f0 1 0
002b:fixme:ntoskrnl:PsSetLoadImageNotifyRoutine (0x541190) stub
002b:trace:winedevice:init_driver init done for L"GGSAFERDriver" obj 0x6837e8e0
002b:trace:winedevice:init_driver - DriverInit = 0x547000
002b:trace:winedevice:init_driver - DriverStartIo = (nil)
002b:trace:winedevice:init_driver - DriverUnload = 0x546010
002b:trace:winedevice:init_driver - MajorFunction[0] = 0x5417b0
...
002b:trace:winedevice:init_driver - MajorFunction[27] = 0x5417b0
002b:fixme:ntoskrnl:__regs_ExAcquireFastMutex 0x1135e4: stub
002b:fixme:ntoskrnl:__regs_ExReleaseFastMutex 0x1135e4: stub

--- snip ---

Unfortunately that one doesn't cause a crash.

I found an old download that seems to have the driver version used to report
the crash:

http://getdota.info/wp-content/uploads/2010/06/Garena_setup.zip

Unfortunately I can't get the client to issue at least one ioctl to the driver
to show the previously reported behaviour.
After login the client always tries to auto-update itself with newer version.

I'll mark this one abandoned because it can't be reproduced anymore easily due
to client updating itself.

Though one could write a small C program that starts the driver (service/driver
dynamically created) and issues the ioctl from snippet ... but only out of
total boredom ;-)

$ wine --version
wine-1.3.35-117-g27e3e1a

Regards

[Bug 24081] Garena crashes (ntoskrnl: out buf length from driver ioctl dispatch used despite error condition)

http://bugs.winehq.org/show_bug.cgi?id=24081

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #8 from Austin English  2012-01-23 23:54:56 CST ---
Closing.