[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 #6 from Anastasius Focht <focht at gmx.net>  2007-11-02 04:38:30 ---
Hello again,

well I rethought about why the analyzer would see gcc generated code (mostly
-fPIC in wine builtins) as "problematic"...

The analyzer seems to have it's trace depth (nesting level) somewhat limited
though I didn't figured out the exact number ... something around 4-5.
Usually all calls at first trace levels have standard stack frame (ebp, esp)
and a RET.
Sure, there is code that deals with global offsets table, like the infamous
"__i686.get_pc_thunk.bx"

--- snip ---
__i686.get_pc_thunk.bx+0: MOV EAX, DWORD PTR [ESP]
__i686.get_pc_thunk.bx+3: RET 
--- snip ---

Even if the analyzer doesn't know about the trick to get current EIP, the call
should still considered harmless seen from tracer perspective, because it
remains in code section and sequence is too short for code cave/hostile code.
It traces some levels deep to see which sections/modules the code brances to
(either they end up in ntdll.dll or remain in builtin code).

After another debugging session I have to revise my statement about the
"weighting" of opcodes .. I probably mixed it up with their disassembler state
machine variables (reading partly obfuscated disassembly code isn't easy when
you're not the one that wrote the logic behind it) ;-)

It's only the analyzed API entry itself that gets some sort of "behavioral
probability"/"statistical value" which is calculated from nesting
level/recursion depth encountered, amount of trace instructions spent in
own/system library code, parameters (callstack) and the like.
That combinations and the large number of exports makes it somewhat hard to
find the exact cause why the overall wine builtins entry code statistics say
"bad guy".

Fortunately the overall number of exports are taken into final calculations
(percentage based).
That renders few "invalid" ones, like data exports with pointer values (which
might confuse the disassembler) harmless.
If 2 of 300 exports are considered completely "invalid" (like the pfnXXX gdi32
data exports) they don't have any significance on final statistics.

Just by adding enough fake API entries/data exports the overall analyzer stats
can be significantly dropped below the "bad guy" threshold. 
Play with the exports and you will see, e.g. change number of dumnmy exports,
aliased values, entry opcodes.
For the non-debugging freaks the result is just "loads" or "does not load", the
infamous "ExitProcess( 0xfeedface)" if you trace log.

Regards


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