Re: [Qemu-devel] A couple of question

2007-06-13 Thread Jan Marten Simons

Balazs Attila-Mihaly (Cd-MaN) schrieb:

Hello all.

First of all I want to congratulate everybody on this list for the wonderful 
job s/he is doing. Qemu is the best Open Source emulator out there (and it is 
fast ;-) ). I'm using Qemu to build an automated malicious code analysis system 
and as such I would like to make some modifications:
  


You're not the first doing so, if you don't know: 
http://www.few.vu.nl/argos/ perhaps you can base your work on argos or 
just contribute to this project.


regs.
Jan




Re: [Qemu-devel] A couple of question

2007-06-06 Thread C . W . Betts
It looks like you are missing the pthread library.  What might be  
happening is that the pthread library is installed, but qemu is not  
linking to it for some odd reason.  Maybe it's looking for a static  
version of it that isn't on your Hard Drive?
On Tuesday, June 5, 2007, at 03:20 PM, Balazs Attila-Mihaly ((Cd-MaN))  
wrote:


PPPS. I can't really debug Qemu (GDB seems to jump all over the  
place). I tried to build it statically (as per an advice given in the  
mailing list some time ago), but if I do


./configure --target-list=i386-softmmu --static
make

I end up with a bunch of linker errors, like the following:

/usr/lib/gcc/i486-linux-gnu/3.4.6/../../../../lib/ 
librt.a(aio_cancel.o): In function `aio_cancel64': (.text+0x2f):  
undefined reference to `pthread_mutex_lock'

...
/usr/lib/gcc/i486-linux-gnu/3.4.6/../../../../lib/librt.a(aio_misc.o):  
In function `handle_fildes_io': (.text+0x737): undefined reference to  
`pthread_mutex_lock'

...
/usr/lib/gcc/i486-linux-gnu/3.4.6/libgcc_eh.a(unwind-dw2-fde-glibc.o):  
In function `__register_frame_info_bases': (.text+0x21c): undefined  
reference to `pthread_create'


What am I missing? (probably something very obvious since I'm  
relatively new to Linux)


Best regards, sorry for taking up so much of you valuable inbox space  
;-), and thank you in advance for your time,

Attila-Mihaly Balazs



PGP.sig
Description: This is a digitally signed message part


Re: [Qemu-devel] A couple of question

2007-06-06 Thread Sunil Amitkumar Janki

C.W. Betts wrote:
It looks like you are missing the pthread library.  What might be 
happening is that the pthread library is installed, but qemu is not 
linking to it for some odd reason.  Maybe it's looking for a static 
version of it that isn't on your Hard Drive?


I have been seeing these kinds of errors lately building software on MIPS,
even when they build fine on x86. My solution to these kinds of errors
was to include -lpthread somewhere in the CFLAGS or patch the source
code to include this linker flag. I haven't seen it with QEMU though.




[Qemu-devel] A couple of question

2007-06-05 Thread Balazs Attila-Mihaly \(Cd-MaN\)
Hello all.

First of all I want to congratulate everybody on this list for the wonderful 
job s/he is doing. Qemu is the best Open Source emulator out there (and it is 
fast ;-) ). I'm using Qemu to build an automated malicious code analysis system 
and as such I would like to make some modifications:

-create an option to dump all the traffic coming out of an interface in a 
tcpdump (pcap) file. I've managed to implement this (and if anyone is 
interested, I can provide a diff against the latest CVS, the changes being very 
localized and no more than 100 lines), however I have my doubts: I do the 
traffic logging in the qemu_send_packet function, which refers to VLAN's not to 
NIC's. 

Because of this I associated the structures needed for the dump (like the 
output file handle) with the VLANState structure, however maybe it would be 
more appropiate to associate it with a NICInfo structure (because it makes - 
usually - more sense to dump the traffic from one NIC rather than one VLAN 
imho), but I couln't find (a) any method to get the appropiate NICInfo 
structure inside of qemu_send_packet or (b) find a different function which has 
access to NICInfo.

My first question would be: am I hooking at the right point?

-modified the breakpoints to be stored in a hash structure (like this 
breakpoints[256][1024]) where the hash key is given by the least significant 
byte of the breakpoint address.  I've done this because I intend to put a lot 
(and I mean a lot :-) ) of breakpoints. I also modified the watchpoint code in 
a similar manner. again, if you are interested I can provide a diff against the 
CVS. 

-Created an option to dump the sectors where there been writes to a file / 
console / etc (whatever qemu_chr_open supports). I've done this because after 
the execution of the malicious code I want to quickly asses which sectors have 
been written (again, if somebody would find something like this usefull, I can 
provide diffs). An other option would have been to create a difference disk 
over the basic image and take the list of sectors from the difference image 
(which obviously are present because they have been modified). However this 
approach has the drawback that it can't be used with snapshots. Specifically, I 
would like to do something like this

[ base image (with a snapshot for quick startup) ] -- [ diff image ] -- Qemu

However it seems that Qemu can read the snapshot only from the last image in 
the chain (diff image in the example). How hard is it to make this work with an 
arbitrary image from the chain? One obvious thing which needs to be done is 
making sure that the snapshot ID's / tag names are unique across the whole 
chain, but other than that how easy is to make this happen?

-Also created an option to dump the program state (ie. variables from the 
stack) at certain points in the execution. My solution is the following:

1. Add a list of breakpoints right before main_loop(); (to the first_cpu)
2. In the main_loop function where it says if (ret == EXCP_DEBUG) {, I added 
a function call to check if it is one of my breakpoints. 
3. If so I log the data and return 1, otherwise 0. I check the return value and 
if it's 1, I do a vm_start(); (this all is done after vm_stop(EXCP_DEBUG);)

However there seem to be a flaw in this approach and the code seem to enter in 
an infinite cycle. My theory is the following (which I hope somebody can 
confirm or prove wrong);

-the execution hits the TB which contains the 0xCC (int 3) corresponding to the 
breakpoint
-the int 3 is catched (before the instruction is executed) and control is 
transferred back to the main loop
-the logging procedure gets called
-when resuming the execution is started at the TB (because the instruction did 
not execute yet and needs to be executed), but because it contains a 0xCC, it 
again is thrown back to the main loop and so on.

If my theory is right, then the breakpoint must be removed (at least 
temporarily) for the execution to continue. However there is no guarantee that 
I can get back control in timely fashion (for example at the next instruction) 
to insert the breakpoint back because of TB chaining, plus I'm concerned that 
such an add / remove would very quickly trash the TB cache. My questions would 
then be:

1. Is my assumption of what's going on correct? and
2. what can I do? for example one thing I though of was to set some flag when 
such a breakpoint is occured to ignore the next int 3 in the exception handler 
which catches it and gives back the control to the main loop. An other thing 
would be to dynamically patch the TB and replace 0xCC (int 3) with 0x90 (NOP). 
Of course this has the problem that to patch the TB must be located first and 
also the problem of when can the back patching occur.


PS. I'm willing to provide the code for this part also (if somebody is 
interested), however it's still very alpha (it doesn't even work yet , as you 
can see from my questions :-))

PPS. If there are