[Bug 9685] Punkbuster removes me from game for UNKNOWN WINDOWS API FUNCTION [131124]

wine-bugs at winehq.org wine-bugs at winehq.org
Wed Oct 3 06:12:36 CDT 2007


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


Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #8327 is|0                           |1
           obsolete|                            |




--- Comment #61 from Anastasius Focht <focht at gmx.net>  2007-10-03 06:12:35 ---
Created an attachment (id=8365)
 --> (http://bugs.winehq.org/attachment.cgi?id=8365)
patch to make PB kernel driver happy. Revamped ioctl buffer handling and more

Hello,

this patch enables the PB kernel driver to work. See comments in source for
further information.

- ioctl buffer handling has been party rewritten and clearified (especially
"in" and "out" buffer parameters)
- MmGetSystemRoutineAddress as previous patch
- simple stubs for MmMapIoSpace, MmUnmapIoSpace and MmGetPhysicalAddress

The Mm-io and physical address space related stuff are just simple minded stubs
which let _this_ driver work.
Wine "kernel" has no concept of page mapping mechanism (page tables, phys vs.
virtual) and paged vs. nonpaged pool.
See comments.
For other malware^H^H^H^H^H^H^Hrootkits like gameguard a full page
directory/page tables emulation is required.

All three components, PB "A", "B", "K" services/driver are now functional.
The kernel driver talks to its user mode client and the "heartbeat" is
established.

As of wine-0.9.46-81-g4a5ba4c the following patches are needed:

http://bugs.winehq.org/attachment.cgi?id=8295&action=edit (driver entry point
fix)
http://bugs.winehq.org/attachment.cgi?id=8322&action=edit (device object access
fix)
http://bugs.winehq.org/attachment.cgi?id=8363&action=edit
(ZwQuerySystemInformation fix)

and this one (ntoskrnl stubs+fixes)

... Sadly I have to take the optimism from you now ;-(
Even the PB components work correctly now, there is currently an issue I cannot
fix using _legal_ ways.

You will see sooner or later the infamous "UNKNOWN WINDOWS API FUNCTION
[131124]" kick message.
Sometimes it takes 30 minutes, sometimes the kick comes immediately after
server join.
It depends on the client checks "work item" scheduling position of the PB
server.
There is no predefined order for the checks to be issued at client side nor the
interval is constant.

The main problem is the way they check for API hooking.
To catch not only the simple redirected ones (trampolines) the take a
fingerprint of certain API entries.
That involves some well known system dlls, few API exports each.
Usually XX bytes (opcodes) of an entry are read and send to server.
EB probably has a database with all known signatures for different windows
versions and patch levels (though I wonder how they handle windows dlls with
hot-patching API).
That signature is verified and if not matched a kick is issued for the client
at game server.

Though even windows users suffer from this problem.
There are (legal) tools like Powerstrip and others which hook certain API
entries, which cause this exact problem (signature mismatch due to changed
opcode sequences).
When a new windows version and/or m$ patches come out, the signatures have to
be added to avoid false kicks.

Some may suggest: "use native (windows) dlls". Well in fact you can't.
Some dlls are a very integral part of wine (ntdll, kernel32) and can't be
exchanged without rendering wine unusable.

Getting EB to add wine builtin dlls signatures is not really an option.
Think of different wine versions, compiler setups and the like (= may produce
wide range of different signatures). Impossible to manage.

Well, you could try to get EB to drop API signature checks which must be
globally, because there is no differentiation between "real" windows and wine
clients and even if: they have to make sure there is no abuse (pretending to be
wine).

The only way that currently works (without known flaws) is another, completely
different approach which involves native linux client.
But before further steps are taken in this direction, some (legal) issues have
to be resolved.

Regards


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the wine-bugs mailing list