[Bug 10273] satisfy SafeDisc 2.x heuristic API analyzer by "adjusting" API exports/entry statistics of wine builtins

[wine-bugs at winehq.org]

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





--- Comment #9 from Anastasius Focht <focht at gmx.net>  2007-11-04 11:29:50 ---
Hello,

@Peter Beutner: good point with

-- quote --
__i686.get_pc_thunk.bx call it dislikes because it determines that it goes
outside of the dll image.
-- quote --

I wrote earlier "... the call should still considered harmless seen from tracer
perspective, because it remains in code section .." and missed the fact that
this little code snippet is indeed *outside* of PE dll section boundary (but
within same ELF .text section) .. *bangs his head*.
Thanks for the hint ;-)

Additionally I ran some debugging series, gathering some statistics.
I hope bugzilla doesn't mess all the tables up...

used: wine-0.9.48-196-gbeab2c1

How to read the data:

c1,c2,c3 are statistical values, calculated from all entry point code (all
named exports) of each library (tracer).
They are required to be below given threshold "condition".
The conditions are hard coded and the same for all system libraries.

Hex values are percent (0x64 = 100%, 0x32 = 50% ...)
"*" means condition not satisfied

standard:

    kernel32   user32      gdi32       condition (cx < threshold)
--------------------------------------------------------------------
c1:  0x59       0x53        0x5D        0x5F
c2:  0x46*     0x47*       0x50*       0x3C
c3:  0x43       0x4B        0x4B        0x5A

(c2 is not met for kernel32, user32, gdi32)

with relay:

    kernel32   user32      gdi32       condition (cx < threshold)
--------------------------------------------------------------------
c1:  0x61*       0x63*      0x63*       0x5F
c2:  0x59*       0x64*      0x64*       0x3C
c3:  0x00        0x00       0x00        0x5A

(c1 and c2 are not met for kernel32, user32, gdi32)

with WINE_NO_TRACE_MSGS and WINE_NO_DEBUG_MSGS (tracing code compiled out):

    kernel32   user32      gdi32       condition (cx < threshold)
-------------------------------------------------------------------
c1:  0x51       0x4B        0x57        0x5F
c2:  0x38       0x28        0x44*       0x3C
c3:  0x39       0x3E        0x43        0x5A

(c2 is not met by gdi32)

*** Now the interesting ones ***

kernel32, user32, gdi32 compiled without -fPIC:

    kernel32   user32      gdi32       condition (cx < threshold)
--------------------------------------------------------------------
c1:  0x20       0x10        0x19        0x5F
c2:  0x07       0x01        0x05        0x3C
c3:  0x00       0x00        0x00        0x5A

(significantly dropped, all conditions are met)

200 fake data exports (aliased to 0 DWORD value):

    kernel32   user32      gdi32       condition (cx < threshold)
--------------------------------------------------------------------
c1:  0x4A       0x41        0x3F        0x5F
c2:  0x37       0x2A        0x26        0x3C
c3:  0x38       0x3B        0x33        0x5A

(all conditions are met)

200 fake data exports (aliased to 0 DWORD value) + relay:

    kernel32   user32      gdi32       condition (cx < threshold)
--------------------------------------------------------------------
c1:  0x51       0x4D        0x44        0x5F
c2:  0x40*      0x3B        0x2E        0x3C
c3:  0x00       0x00        0x00        0x5A

(c2 is not met for kernel32, so "relay" feature is not "safe" to use)

400 fake data exports (aliased to 0 DWORD value):

    kernel32   user32      gdi32       condition (cx < threshold)
--------------------------------------------------------------------
c1:  0x40       0x25        0x30        0x5F
c2:  0x25       0x20        0x18        0x3C
c3:  0x30       0x30        0x27        0x5A

(all conditions are met)

400 fake data exports (aliased to 0 DWORD value) + relay:

    kernel32   user32      gdi32       condition (cx < threshold)
--------------------------------------------------------------------
c1:  0x46       0x3F        0x34        0x5F
c2:  0x2E       0x29        0x1B        0x3C
c3:  0x00       0x00        0x00        0x5A

(all conditions are met)

===================================

The reason why +relay shifts statistics to the worse is because relay stubs
have get_pc_thunk.bx in entry code.

Now the question remains whether to drop -fPIC for these libraries or finding a
way to relocate the "get_pc_thunk.bx" code snippet into PE section boundaries.
There is one interesting thing I found while dumping kernel32 ELF sections:

7b8303fc l     F .text  00000000              .hidden __i686.get_pc_thunk.cx
7b8140e7 l     F .text  00000000              .hidden __i686.get_pc_thunk.bx

The address of "__i686.get_pc_thunk.cx" is within "visible" PE section space
(starts at 7b820000) whereas "__i686.get_pc_thunk.bx" is not.
Both calculate global offset table addresses (choice is probably made by
compiler what register does not need to be saved in that code context).
If the code location could be fixed to "visible" PE section space like for the
get_pc_thunk.cx we might fix this problem while keeping -fPIC.

--- snip ---
Any greater version of safedisc2(>= 2.6x?) seems to have additional checks and
it fails again with the usual "ExitProcess( 0xfeedface)".
--- snip ---

Could you elaborate which games?
I have successfully tested the Battlefield game series which have SafeDisc 2.5
and 2.8 (either with dummy exports or by dropping -fPIC).
I've also tested one SafeDisc 3.x (doom3) and one 4.x game (BF2).
Maybe we're seeing different issues.

Regards


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