|
| From: | F. Zhang |
| Subject: | Re:Re: Re: [Qemu-devel] How to make shadow memory for a process? and how to trace the data propation from the instruction level in QEMU? |
| Date: | Tue, 16 Nov 2010 19:39:31 +0800 (CST) |
Hi!
>Hi....
>
>OK it's getting interesting.... perhaps it would lead into
>instrumentation topic, which is quite hot topic in qemu-devel quite
>recently, so you jump into the wagon just about the right time :)
>
>
>OK, one thing for sure here is, I think you can implement your idea on
>top of several (not so complete) existing frameworks in Qemu.
>Tracing...is one of them...not sure about the rest...
>
You are right! I have considered implementing my idea based on some existing framework such as TEMU.
But on the other hand, I think I should understand how QEMU works first (TEMU is based on QEMU), in order that once I want to add some other features, I know, at leats, where to modify/add code to implement new functions. That’s also the reason why I started this topic here.
>Thanks for sharing that...it's new stuff for me. So, why don't you
>just pick TEMU and improve it instead of...uhm...sorry if I am wrong,
>working from scratch? After all, I believe in both Argos and TEMU (and
>maybe other similar projects), they share common codes here and there.
>
>But ehm...CMIIW, seems like TEMU is based on Qemu 0.9,x, right? So
>it's.... sorry I forgot the name, the generated code is mostly a
>constructed by fragments of small codes generated by gcc. Now, it is
>qemu which does it by itself. So, a lot of things change
>(substantially).
>
L If things change a lot, it is more important for me to figure out how things work in QEMU. Especially something discussed in this topic.
>
>I agree that should be the way it works....but..... (see below)
>
>
>>>How about using unused one of unused PTE flags for such tag?
>>
>> Sorry, what is the PTE flag?
>
>Page Table Entry...i believe not all flags are really used by the OS
>nowadays, so I guess you can utilize 1 or 2 bits there whenever
>possible...
This is the problem of granularity. In fact, one-tag-per-page is too coarse. One tag per byte, or one tag per word, or one tag per double words may be often-seen. As we know, commonly, only a few bytes in a page are malicious, and alarm is raised only when these bytes are used, not when the page is used. Thus the fine-grained tag is necessary, which requires, according to my knowledge, the shadow memory.
>May we know, what kind of information do you plan to store in such tag?
Since the shadow memory exists, you can store any information in the tag as you want. For example, you can use one bit as the tag to indicate whether a byte is tainted or not; or you can use a C-language-like structure as the tag to contain more information, including stack and heap and so on. This depends on your analysis requirement.
>
>I think you should hook all the memory operation related opcode (or to
>be precise, Qemu opcode). That way, you won't miss any..
J That’s the critical problem. Could you tell me how to hook the opcode? I thought before to modify the instruction-translation functions and recompile QEMU, is that right? Is there any better way?
>
>> Yes, I wanna make QEMU cooperate with the GUEST OS. In fact, malware under
>> analysis is run within the GUEST OS.
>
>Hm, I thought it would be host OS + qemu....don't you think, if it is
>guest OS +qemu, while there is a chance guest OS is compromised first,
>then we get such unreliable data? Or am I missing something here?
>
This is a good question!
The scenario that we use the information provided by guest OS is limited within the following scope: “the being analyzed software’s major purpose is NOT to attack OS kernel, but to implement the malicious behavior in the user space”. Since the software under analysis is in the user space and does not touch the kernel, we can safely use the information provided by OS kernel.
However, if the main purpose of the software is to attack the OS (for example, rootks), the information got from OS kernel is not reliable. Fortunately, in this case, the target of taint analysis is NOT the user space software, but the kernel. That is to say, we need not any information provided by kernel.
For the kernel related dynamic analysis, you can reference the paper “HookScout: Proactive Binary-Centric Hook Detection”.
>>The guest os collects “higher” semantic
>> from the OS level, and the QEMU collects “lower” semantic from the
>> instruction level. Combination of both semantics is necessary in the
>> analysis process.
>
>The question is, in a situation where malware already compromise "the
>higher semantic", could we trust the analysis?
>
>> The question is: how to communicate between the QEMU and the guest OS, so
>> that they can cooperate with each other?
>
>OK, so let's assume it's really guest OS +qemu...i think, uhm, better
>create pseudo device, quite similar with virtio....or you can think
>it's like /dev/sda, /dev/rtc etc... the guest OS must somewhat be
>installed with a driver which knows how to read and talk to this
>device.
>
>Via the driver, fed any analysis result....qemu collects it...and
>finally pass it to host OS.
>
>Other possibilty is to reserve certain memory region (kinda BIOS
>reserved memory space), mmap it inside the guest OS, then treat it
>like System V shared memory. Put the data in it, Qemu regularly checks
>it...
>
>What do you think?
>
Good idea!
I am not very similar to System V share memory. But I guess it may be hard to implement the real-time communication between guest OS and QEMU. A pseudo device may be a better choice.
>PS: eduardo cruz might be an interesting person to talk to..he did
>instrumention work lately too....
Thanks! but what about his mail? Is he in the mailing list?
Thank you very much! I think I get so many from the discussion!
>
>--
Best regards!
F. Zhang
| [Prev in Thread] | Current Thread | [Next in Thread] |