qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] A couple of question


From: Balazs Attila-Mihaly \(Cd-MaN\)
Subject: [Qemu-devel] A couple of question
Date: Tue, 5 Jun 2007 14:20:39 -0700 (PDT)

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 some coding guidelines / formatting standards my code should 
adhere to before it can be accepted, please point me in the right direction.

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




      ___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/ 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]