[Top][All Lists]
[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/
- [Qemu-devel] A couple of question,
Balazs Attila-Mihaly \(Cd-MaN\) <=