Re: [Clamav-devel] clamav-devel Digest, Vol 73, Issue 3

2010-11-05 Thread Török Edwin
On Fri, 5 Nov 2010 13:56:55 +0200
Amr Thabet  wrote:

> >Why do you need to generate assembly code to compare Thread.ecx with
> >something? Is it that much faster?
> >You could simply put a function pointer in your structure, a pointer
> >to the value you want to compare, and the constant to compare to.
> >Then compare using C code, not assembly.
> 
> >.func = compare_values
> >.lhs = (char*)&Thread.ecx - (char*)&Thread
> >.rhs = 0x5678
> 
> >Then call ->func(bp->lhs, bp->rhs), and compare_values would
> >do *(uint32_t*)((char*)Thread + bp->lhs) == bp->rhs.
> 
> why??
> 
> because I don't need to decrease the performance . if you have a
> breakpoint like :
> "eip >=0x00401000 && eip <=0x00405000 && __isdirty(Eip) &&
> (__read(Eip) & 0xFF) != 0xC3"
> 
> if I create a parser parses these condition every time you emulate an
> instruction that's will decrease the performance surely.

No, you don't have to parse the condition each time. You parse it once
and create a tree. When you need to evaluate, you evaluate the tree.

> also if you
> try to do something like that :
> 
> process->emulatecommand();
> 
> if (thread->Eip <=  && Thread-> Eip >= xxx  ){
>   break;
> }
> you will lose many of the features of the emulator and could not

Using assembly like this is not portable. It will only work on x86
(and with some work on x86-64). It won't work on Sparc.

Currently it doesn't seem to work on x86 either. The reason is you
allocate memory with malloc(), and then you execute it. That doesn't
work due to NX protection. 
You will have to allocate using mmap and allow execution, but then
SELinux won't allow your code to run (W^X protection).

You're better off not emitting assembly on the fly.
On the other hand, why can't you use the emulator to execute the
assembly instructions you emit? (sure it'll be slower than tree approach
I suggested above).

> emulate the SEH perfectly and will surely decrease the performance

What features does SEH need from the debugger to work?

> 
> surely but I only demand from you is to read the Manual of The
> emulator in x86emu-docs.zip it's not so big maybe 5 pages to 10
> maximum I think

OK, I'll read it.

> 
> it will make you easy to detect the bug and maybe for small bugs you
> fix it by yourself  :)
> 
> libemu will take more time for you to add a PE Loader

I already wrote one, one month ago.

Best regards,
--Edwin
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net


Re: [Clamav-devel] clamav-devel Digest, Vol 73, Issue 3

2010-11-05 Thread Amr Thabet
Hello Mr.Edwin,

>OK, so in that sense it is like libemu (they have the exports table
>included in their code).

it uses only the dlls that you need to emulate its apis but the others (like
user32.dll and so on) you don't need them so you can not write a dll for
them

I don't know many about libemu but it seems good with one exception that it
doesn't have a PELoader

>Why do you need to generate assembly code to compare Thread.ecx with
>something? Is it that much faster?
>You could simply put a function pointer in your structure, a pointer to
>the value you want to compare, and the constant to compare to.
>Then compare using C code, not assembly.

>.func = compare_values
>.lhs = (char*)&Thread.ecx - (char*)&Thread
>.rhs = 0x5678

>Then call ->func(bp->lhs, bp->rhs), and compare_values would
>do *(uint32_t*)((char*)Thread + bp->lhs) == bp->rhs.

why??

because I don't need to decrease the performance . if you have a breakpoint
like :
"eip >=0x00401000 && eip <=0x00405000 && __isdirty(Eip) && (__read(Eip) &
0xFF) != 0xC3"

if I create a parser parses these condition every time you emulate an
instruction that's will decrease the performance surely. also if you try to
do something like that :

process->emulatecommand();

if (thread->Eip <=  && Thread-> Eip >= xxx  ){
  break;
}
you will lose many of the features of the emulator and could not emulate the
SEH perfectly and will surely decrease the performance

you can do that and ignore the debugger breakpoints but it's more faster and
more easy to use and also the debugger has up to 10 functions for easy to
add your own breakpoint like

__isdirty(Eip)  execution on Modified Data
__islastaccessed()  get the last accessed place on memory
__isapiequal("GetProcAddress")
__isapi()
__islastmodified()

and many more

you will lose them if you try to ignore the debugger breakpoints



>The code doesn't crash when run under valgrind (because it prints the
>error, and continues). Once you fix the valgrind warnings I'm sure
>it'll work better without it too.

really we could fix most of the problems together :)

>Another hint: valid indexes for Thread::dword Exx[7] are from 0 to 6,
>you have for loops that go from 0 to 7 (inclusive).
>You should review your code and make sure you declare and use
>appropriate bounds.

Will be fixed surely :)

>I agree about the testing part, but bugfixing should be done by the
>emulator's author.

surely but I only demand from you is to read the Manual of The emulator in
x86emu-docs.zip it's not so big maybe 5 pages to 10 maximum I think

it will make you easy to detect the bug and maybe for small bugs you fix it
by yourself  :)

libemu will take more time for you to add a PE Loader and add the functions
you need for breakpoints and so on .. also Pokas x86 Emulator will take a
time for bug fixing but surely less time I think

Best Regards,

Amr Thabet
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net