Mailing List Archive

Re: clamav-devel Digest, Vol 73, Issue 3
the only problem in Bochs and qemu is they are built for supporting full
virtualization . so emulate the hardware and the the cpu and they don't
support emulating the operating system

so you need to emulate the operating system (Windows or Linux)

you have a good choice is Pandora's Bochs but it's very slow and you
couldn't use it in an antivirus because you can't run it inside an antivirus
transparently

Ida-emu could be modified to support running inside an antivirus. it's a
good choice as it's fast and support windows and linux virtualization
(emulating linux and windows)

Pokas emulator is a good choice as it support conditional breakpoints
without decreasing the performance and support many breakpoints. but it
emulates only windows and a bit slower than ida-emu

Thanks
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: clamav-devel Digest, Vol 73, Issue 3 [ In reply to ]
On Sun, 24 Oct 2010 01:11:20 +0200
Amr Thabet <amr.thabet@student.alx.edu.eg> wrote:

> I suggest to add an open source emulator to the application to make
> it run when the md5 scan failed to detect any virus .

Hi,

Thanks for the suggestion.
I think Pokas emulator (or another one) could be used in ClamAV in
the following ways, see the rest of this email for details:
- "port" it to ClamAV bytecode, i.e. make it compilable by the "ClamAV
bytecode compiler" see: (not a trivial task)
http://git.clamav.net/gitweb?p=clamav-bytecode-compiler.git;a=blob_plain;f=docs/user/clambc-user.pdf;hb=HEAD
- write an emulator that can be used to prototype new detections,
which can later be implemented in bytecode without the help of the
emulator
- write a tool for sigmakers, to help them find malicious code
sequences faster (or even automatically)
- write a tool that uses both libclamav and your (or another)
emulator: it would register itself with libclamav's callbacks, scan
files, and on executables it would invoke the emulator from
libclamav. It can then pass back a detection result to libclamav. I
think this might be the quickest way to get started

There are many ways you can use an emulator in AV, and I think it is
important to choose one:
- detect trash code
- detect anti-emulator, VM detection code
- unpack some simple packed malware
- unpack both malware, and legit software
- unpack/emulate enough to reach the actual malicious code (this can be
quite hard)
- prototyping new malware detection ideas, that can later be
implemented directly in libclamav without the emulator, or in
bytecode

Another decision that needs to be made is where the emulator is used:
- is it an emulator run by the end-user?
- is it an emulator run by malware analysists / sigmakers?
- is it an emulator used by an automated signature creation process?

For ClamAV I think it'd make sense to focus on the prototyping part for
the emulator.

I was actually experimenting with an emulator for the first, 3rd and 6th case
(trash code, simple packed malware, and prototyping).
I used libemu for that purpose. Although it is meant to emulate only
win32 shellcode, it works surprisingly well on startup code of malware
(with some tweaks).
Sure it lacks a PE loader, and some other bits, but that is easy to
write. It worked well enough to unpack a rootkit, and record some API
calls. All that without needing a win32 installation.
I didn't publish the code though, since it is not finished yet, but if
someone considers it would be useful, I could probably do that.

Having said that I don't mean to integrate that into libclamav anytime
soon, or in fact ever. This kind of emulator can be used to
build some tools for sigmakers, or maybe some automated analyzer in the
future. Not for the end-user.
Would take too much time to emulate each executable this way, not to
mention possible security issues.

However what an emulator would be really good for is quick prototyping
of new detection ideas: You have an idea how to detect malware, you
plug it into the emulator. You run it on malware samples, see how much
it detects. Then you run it on clean (and packed/copy protected)
software. If you see it detects too many, back to the drawing board for
you.

Once you have the algorithm prototyped with the emulator, and if it
something quite simple, you may implemented it using ClamAV's bytecode.
ClamAV has a disassembler, which can be accessed from the bytecode, so
you could write a simple emulator in bytecode, which then processes the
results using the algorithm you prototyped on the real emulator.
That might work.
Actually I'm already working on one such prototype,
but got caught up in solving bugs for 0.96.4. Will post details about
it once I finish it.

On Sun, 24 Oct 2010 15:29:26 +0200
Amr Thabet <amr.thabet@student.alx.edu.eg> wrote:

> the only problem in Bochs and qemu is they are built for supporting
> full virtualization . so emulate the hardware and the the cpu and

Yes, and they are quite good at that.

> they don't support emulating the operating system

You don't necessarily need or want a full OS emulator in an AV, just
some basics.

>
> so you need to emulate the operating system (Windows or Linux)
>
> you have a good choice is Pandora's Bochs but it's very slow and you
> couldn't use it in an antivirus because you can't run it inside an
> antivirus transparently

Is it available for download?

>
> Ida-emu could be modified to support running inside an antivirus.
> it's a good choice as it's fast and support windows and linux
> virtualization (emulating linux and windows)

That would require a license for IDA Pro, so I don't think it is an
option for ClamAV.

>
> Pokas emulator is a good choice as it support conditional breakpoints
> without decreasing the performance and support many breakpoints. but
> it emulates only windows

That would be enough. I don't see a point in emulating Linux.

> and a bit slower than ida-emu

I assume you could limit the amount of instructions you emulate,
depending on the purpose of the emulation.

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 Digest, Vol 73, Issue 3 [ In reply to ]
Hello Mr. Edwin,

- "port" it to ClamAV bytecode, i.e. make it compilable by the "ClamAV
bytecode compiler" see: (not a trivial task)
http://git.clamav.net/gitweb?p=clamav-bytecode-compiler.git;a=blob_plain;f=docs/user/clambc-user.pdf;hb=HEAD

Yeah I see that it's not a trivial task but at least it could done

- write a tool for sigmakers, to help them find malicious code
sequences faster (or even automatically)

I could help in supporting that also Pokas Dbg could help see this link:
https://sourceforge.net/projects/pokasdbg


There are many ways you can use an emulator in AV, and I think it is
important to choose one:
- detect trash code

not so good :)

- detect anti-emulator, VM detection code

Need to make the emulator bypass these types of code

- unpack some simple packed malware

I write a detection code for win32.Virut.A with pokas emu at the examples\04
in x86emu-src.zip at https://sourceforge.net/projects/x86emu

- unpack both malware, and legit software
- unpack/emulate enough to reach the actual malicious code (this can be
quite hard)

yeah it will take long time (in some malware) but you don't need to find the
entry point so you will emulate until the Maximum Iterations reached and
then scan the memory with the sig

Another decision that needs to be made is where the emulator is used:
- is it an emulator run by the end-user?

it's a small tool and could be run in any OS . it could run on windows users
easily. and also linux with just a copy of
(kernel32.dll,user32.dll,ntdll.dll)

- is it an emulator run by malware analysists / sigmakers?

it's not a stand alone application so it's not so flexible to be used with
malware analysists / sigmakers but Pokasdbg help a lot in this point

- is it an emulator used by an automated signature creation process?

surely (the benefit of this emulator is that it's a dll file (or .so) with
many functions make you control the whole application you emulate and the
emulator behavior easily and do many modifications in it )



I hope To see ClamAV more better and I hope you could support an Emulator .
I also hope you find Pokas Emulator helpful on that . if you decide to
choose it you will find me online with you for any questions.

also it has a good reference in x86emu-docs.zip in
https://sourceforge.net/projects/x86emu/

and good examples specially example 04 that has the detection and the
disinfection of virut.A

also you could find it in :
http://www.woodmann.com/collaborative/knowledge/images/Bin_Virut.A_Malware_Analysis_Paper_2010-9-3_15.53_Virut.A.rar

I hope that helps

wait for your reply

Thanks
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: clamav-devel Digest, Vol 73, Issue 3 [ In reply to ]
On Fri, 29 Oct 2010 14:21:40 +0200
Amr Thabet <amr.thabet@student.alx.edu.eg> wrote:

> Hello Mr. Edwin,
>
> - "port" it to ClamAV bytecode, i.e. make it compilable by the "ClamAV
> bytecode compiler" see: (not a trivial task)
> http://git.clamav.net/gitweb?p=clamav-bytecode-compiler.git;a=blob_plain;f=docs/user/clambc-user.pdf;hb=HEAD
>
> Yeah I see that it's not a trivial task but at least it could done
>
> - write a tool for sigmakers, to help them find malicious code
> sequences faster (or even automatically)
>
> I could help in supporting that also Pokas Dbg could help see this
> link: https://sourceforge.net/projects/pokasdbg

Will have a look this weekend.

>
>
> There are many ways you can use an emulator in AV, and I think it is
> important to choose one:
> - detect trash code
>
> not so good :)
>
> - detect anti-emulator, VM detection code
>
> Need to make the emulator bypass these types of code

Or we could just say its malicious when we find these. Unless it leads
to too many FPs.

>
> - unpack some simple packed malware
>
> I write a detection code for win32.Virut.A with pokas emu at the
> examples\04 in x86emu-src.zip at
> https://sourceforge.net/projects/x86emu

Thanks, will test it.

>
> - unpack both malware, and legit software
> - unpack/emulate enough to reach the actual malicious code (this can
> be quite hard)
>
> yeah it will take long time (in some malware) but you don't need to
> find the entry point so you will emulate until the Maximum Iterations
> reached and then scan the memory with the sig

Right.

>
> Another decision that needs to be made is where the emulator is used:
> - is it an emulator run by the end-user?
>
> it's a small tool and could be run in any OS . it could run on
> windows users easily. and also linux with just a copy of
> (kernel32.dll,user32.dll,ntdll.dll)

The real ones, or will wine's version do?
Do you need the actual code in them, or just the export tables?

>
> - is it an emulator run by malware analysists / sigmakers?
>
> it's not a stand alone application so it's not so flexible to be used
> with malware analysists / sigmakers but Pokasdbg help a lot in this
> point
>
> - is it an emulator used by an automated signature creation process?
>
> surely (the benefit of this emulator is that it's a dll file (or .so)
> with many functions make you control the whole application you
> emulate and the emulator behavior easily and do many modifications in
> it )
>
>
>
> I hope To see ClamAV more better and I hope you could support an
> Emulator .

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.

> I also hope you find Pokas Emulator helpful on that . if
> you decide to choose it you will find me online with you for any
> questions.

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?
- 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

Is your code supposed to work on Linux, or would I be better of testing
in on Windows first?

>
> also it has a good reference in x86emu-docs.zip in
> https://sourceforge.net/projects/x86emu/
>
> and good examples specially example 04 that has the detection and the
> disinfection of virut.A
>
> also you could find it in :
> http://www.woodmann.com/collaborative/knowledge/images/Bin_Virut.A_Malware_Analysis_Paper_2010-9-3_15.53_Virut.A.rar

Will take a look.

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 Digest, Vol 73, Issue 3 [ In reply to ]
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
Re: clamav-devel Digest, Vol 73, Issue 3 [ In reply to ]
On Tue, 2 Nov 2010 23:06:05 +0200
Amr Thabet <amr.thabet@student.alx.edu.eg> wrote:

> 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

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

>
> >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

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.

> I think this code couldn't be executed on x64 so it's hard to convert
> the emulator to work on x64

I compiled with -m32, so it is executed as 32-bit code.
Hint: you can run your program under valgrind on Linux.
It is an excellent memory debugger.

It shows errors like this in your code, looks like you are consistently
off by 4 bytes.

==30022== Invalid read of size 4
==30022== at 0x48E2299: op_pushad(Thread&, ins_disasm*) (jmps.cpp:80)
==30022== by 0x48E8412: Process::emulate() (process.cpp:193)
==30022== by 0x80491E7: main (in /home/edwin/X86
Emulator/examples/02/a.out)
==30022== Address 0x70a072c is 0 bytes
after a block of size 68 alloc'd
==30022== at 0x48AF72E: operator
new(unsigned int) (vg_replace_malloc.c:255)
==30022== by 0x48E7E91:
Process::CreateThread(unsigned long) (process.cpp:114)
==30022== by
0x48E7E07: Process::Process(System*, std::string) (process.cpp:100)
==30022== by 0x8048F82: main (in /home/edwin/X86
Emulator/examples/02/a.out)

==30022== Invalid write of size 4
==30022== at 0x48EE787: op_stos(Thread&, ins_disasm*)
(strings.cpp:65) ==30022== by 0x48E8412: Process::emulate()
(process.cpp:193) ==30022== by 0x80491E7: main (in /home/edwin/X86
Emulator/examples/02/a.out) ==30022== Address 0x70a072c is 0 bytes
after a block of size 68 alloc'd ==30022== at 0x48AF72E: operator
new(unsigned int) (vg_replace_malloc.c:255) ==30022== by 0x48E7E91:
Process::CreateThread(unsigned long) (process.cpp:114) ==30022== by
0x48E7E07: Process::Process(System*, std::string) (process.cpp:100)
==30022== by 0x8048F82: main (in /home/edwin/X86
Emulator/examples/02/a.out)

... ==30119== ERROR SUMMARY: 1695990 errors from 324 contexts
(suppressed: 15 from 6)

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.

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.

>
>
> >- 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

OK, that makes sense.

>
> >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

You can intercept SIGSEGV, but that is not the way to go in a portable
program.
You have to avoid the segmentation fault in the first place,
for example by checking that your memory access is in bounds, *before*
the access.

>
> >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)

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

>
> about compiling I test it again and it compiled perfectly perfectly
> on gcc 4.0.1 with string.h as I think

gcc 4.4 is more strict about C++ headers. They cleaned up a lot of
useless includes, so code that was not entirely ISO standards compliant
may get compile errors.

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 Digest, Vol 73, Issue 3 [ In reply to ]
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 <= xxxx && 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
Re: clamav-devel Digest, Vol 73, Issue 3 [ In reply to ]
On Fri, 5 Nov 2010 13:56:55 +0200
Amr Thabet <amr.thabet@student.alx.edu.eg> 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 <= xxxx && 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 Digest, Vol 73, Issue 3 [ In reply to ]
Hello Mr. Edwin

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.

no problem I will support another debugger but until that time use
process->emulatecommand()


> also if you
> try to do something like that :
>
> process->emulatecommand();
>
> if (thread->Eip <= xxxx && 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).


I didn't care about this at this time because it was designed first for
Windows for PC-User but I'll write another debugger to work with
substituting with the old debugger . nor problem

What features does SEH need from the debugger to work?


sorry for that . no problem the application will work perfectly


I already wrote one, one month ago.

after you read the manual .you will figure out what are the advantages and
disadvantages of Pokas Emulator over libemu. you can at this time choose
form libemu and Pokas x86 Emulator. because designing clamav with the two
emulator will take a long time

add to the Advantages of pokas emulator that it now support tls callbacks
and now nearby all bugs in pe loader now fixed . many of EXE files are not
easy to load like winpack.exe packed files

and add to the disadvantages of pokas emulator that it will need some
maintenance. at this project created in 2010 but libemu in 2007 so libemu
most of its bugs now fixed compared to pokas emulator

Best Regards,

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