http://bugs.winehq.org/show_bug.cgi?id=10273
--- Comment #6 from Anastasius Focht focht@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