Hello Mr. Edwin,
>The real ones, or will wine's version do?
>Do you need the actual code in them, or just the export tables?
it's really a linux version and it only needs the export table not the real
code. we could create a modified kernel32.dll and ntdll and so on with inly
the export table to decrease its size
>I don't know yet. Looks like I'm hitting some portability issues now:
>- missing <cstdio> and <cstring> include (otherwise fails to build
>with gcc 4.4)
>- dbg/dbg.cpp has x86 assembly code, so it won't work on x86-64:
>:71: Error: operand type mismatch for `push'
>Is there a way to disable that part of the code?
it simply do the following
mov eax,XXX
mov ebx,XXX
call ecx
it could be converted into x64 but that's not the problem
the problem is the parser in the dbg as it creates a 32-bit Assembly Code
that test the breakpoint like:
addbp("ecx==0x5678");
the parser converts this into
mov eax,0x5678
mov ecx,eax
mov eax,dword ptr [&Thread.ecx - &Thread]
test eax,ecx
jz Lable1
mov eax,0
ret
Label1:
mov eax,0
ret
this call is executed every time it emulates an instruction
I think this code couldn't be executed on x64 so it's hard to convert the
emulator to work on x64
>- with -m32 the first example works, but the 2nd example tries to
>execute some code in TestBP. What code is it trying to execute?
>It wouldn't be wise to execute the malware code on the real CPU ...
>thats the point of having an emulator in the first place
>
>Program received signal SIGSEGV, Segmentation fault.
>0x08078e98 in ?? ()
>(gdb) bt
>#0 0x08078e98 in ?? ()
>#1 0xf7fedd39 in Debugger::TestBp (this=0x806b8c8, num=0, thread=...,
>ins=0x8078de8) at dbg/dbg.cpp:39
>#2 0xf7fedda9 in Debugger::TestBp (this=0x806b8c8, thread=...,
>ins=0x8078de8) at dbg/dbg.cpp:48
>#3 0xf7fe82f9 in Process::emulate (this=0x805fe68) at process.cpp:179
>#4 0x08049239 in main (argc=1, argv=0xffffd354) at main.cpp:58
>
sometimes it returns error. but it's not execute the malware in the real CPU
but the breakpoint testing procedure only
>is your code supposed to work on Linux, or would I be better of testing
>in on Windows first?
it works on Windows mainly but it should run on linux with no problems . but
sometimes it returns Segmentation Fault
if there's something like SEH on Linux or any exception handler that will be
great
>I think I'll write an app that uses libclamav, multiple emulators,
>and compares their execution.
>I think contrib/ would be good place for such an app.
>Then I'll scan part of our zoo with it, and see how much it can
>emulate.
surely no emulator hasn't any bug . nearby most of them contain bugs and
error in emulation. but the emulators like bochs and vmware they tested
hundreds of times so there's no real bugs
For any emulator you choose you do many beta testing and many fixing as it
will be a part of your project (clamav)
about compiling I test it again and it compiled perfectly perfectly on gcc
4.0.1 with string.h as I think
it should work well in gcc 4.4 but not x64
and at Last
I hope everything go so fine
Regards,
Amr Thabet
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
