[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 #15 from Anastasius Focht <focht at gmx.net>  2007-11-05 12:31:16 ---
Hello,

unfortunately the PE header patch works only for one of the 3 conditions
mentioned earlier...

Comparison with previous data (from comment #9):

standard:

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

with PE header .init section patch (moves PE header before pc thunk code):

    kernel32   user32      gdi32       condition (cx < threshold)
--------------------------------------------------------------------
c1:  0x59       0x53        0x5C        0x5F
c2:  0x46*      0x43*       0x53*       0x3C
c3:  0x00       0x00        0x00        0x5A

At least condition c3 is completely satisfied.
By doing some dirty stuff *g*, I forced the analyzer to load my own, custom
made dll at the point where it checks the system libraries.
I ran some series to find more about the meaning of calculated stats values.

--------

The custom dll exports a specific number of functions (10 for percentage
values) with pure asm code to control generation of opcodes.

I made some test cases with different nesting levels and calling destinations.

"t_x" = testcase x
"n_x" = nesting level x (e.g. func0() { func1(); }  func1() { ...} )
"i_fn" = internal function
"exp" = exports

t_1: 10 data exp, init with 0
t_2: 10 exp, call to i_fn, n_1, simple register calculation
t_3: 10 exp, call to i_fn, n_1, emulates get_pc_thunk.bx()
t_4: 10 exp, call to i_fn, n_1, { mov eax, <outside_of_pe_dest> ; jmp eax } 
t_5: 10 data exp, init with 0xE8 (call xxx opcode) to check if the analyzer
makes difference of section (.data vs .text)
t_6: 10 exp, call to i_fn, n_1, calls GetModuleHandleA("kernel32.dll")
t_7: 10 exp, call to i_fn, n_10, at n_10 call GetModuleHandleA("kernel32.dll")
- nesting level test
t_8: 10 exp, call to GetModuleHandleA("kernel32.dll")
t_9: 5 exp, call GetModuleHandleA("kernel32.dll") and
     5 exp, call to i_fn, n_1, calls GetModuleHandleA("kernel32.dll")

     t1     t2     t3     t4     t5     t6      t8    t9    condition (cx < th)
--------------------------------------------------------------------
c1:  0x00   0x64   0x64   0x64   0x64   0x64   0x64   0x64   0x5F
c2:  0x00   0x64   0x64   0x64   0x64   0x64   0x64   0x32   0x3C
c3:  0x00   0x00   0x00   0x64   0x50   0x00   0x64   0x32   0x5A

Well ... determining the meaning of conditions seem to be pretty hard because
several information is taken into account and I only varied call destination
and nesting level.
I dropped the idea of testing various other opcode sequences/entry signatures
(length of sequences, stack parameters, ..) due to time constraints ... 

c3 seems to be directly related to the destination of first call/jump
encountered at nesting level 0.
So the get_pc_thunk.bx() location problem was only one reason.

That makes two options left: drop -fPIC or go with fake data exports.
Though dropping -fPIC for the libraries in question seems to be more natural
solution ;-)

Regards


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