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

[wine-bugs at winehq.org]

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





--- Comment #93 from Anastasius Focht <focht at gmx.net>  2007-11-01 11:21:59 ---
Hello,

--- snip ---
EB absolutely refuses to bend their code to conform with wine or cedega, nor
will they support users of these api compatibility layers as Stuart Dunsmore
has been quoted as stating before.

so bugger EB = render the checks useless and persuade them to drop them
--- snip ---

Render useless? Then hack the PB server binaries not the client.
The server schedules the client side checks. In case of signature checks it
gets the "match" list from EB servers and verifies against what the clients
returned.

Windows users get 131xxx kicks too because Micro$oft issues hot fixes/security
updates on regular schedule which can change API entry signatures.
Yesterday I encountered an API signature even invalid for my Windows XP SP2
with latest updates.

Just a "bad" example how brain damaged the PB signature approach is:

"UNKNOWN WINDOWS API FUNCTION [131131]" 

This is in fact a signature mismatch of kernel32.GetTickCount() API.

They currently have 9(!) different signatures for this one (as of 29.10.2007).
In this case, few signatures contain opcode "wildcards", mostly exact match is
needed.
Due to the nature of this API call, it changes very frequently because its
entry code contains unconditional 32 bit jump destinations (mostly through "jmp
<rel32>" or "jmp <rel8> + jmp <rel32> or "mov <reg32>,<off32> ; jmp <reg32>"
...)
Every time Micro$oft changes some of their code in system libraries, the
compiler _might_ generate different destination addresses, even for code blocks
which are not directly changed (but contain branches to other code) ->
different signature if no wildcards are used for jump destinations.

When users report their kicks, they usually get an answer like "blame
virii/hacks/cheats/3rd party software".
This might be true for some cases but in fact many signature mismatches are
caused by windows security updates.

So even if I take the opcode sequences containing most "wildcards" from each
API call it is difficult to mimick because the __asm__ wrappers must not do any
"damage", e.g. leave the callstack and data structures intact.
Some of their API selections have only one signature = difficult to mimick due
to specific register usage in entry code.

The more the list grows, the more reluctant I get to go any further. Never
ending story, which might be unmaintainable even for unofficial patches.

Regards


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