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?

[Mulyadi Santosa]

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

2010/11/15 F. Zhang <address@hidden>:
> I am very pleased to share ideas with you. But my English is too poor, er…,
> I’ll try my best to make it clear. J

Either do I. How much do you expect Indonesian like me to write
fluently English, after all? :D heheh, just joking :)

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

> Yes, I have read that paper, it’s wonderful!
>
> Besides the Argos, the bitblaze group, led by Dawn Song in Berkeley, has
> achieved great success in the taint analysis. The website about their
> dynamic analysis work (called TEMU) can be found at:
> http://bitblaze.cs.berkeley.edu/temu.html
>
> And TEMU is now open-source.

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

> Yes. For each process’s memory space A, I wanna make a shadow memory B. The
> shadow memory is used to store the tag of data. In other words, if addr in
> memory A is tainted, then the corresponding byte in B should be marked to
> indicate that addr in A is tainted.

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...
>
> In fact, the tag is stored in the shadow memory of the process.
>
> Let us consider the following instruction:
>
> mov eax, [esi]
>
> If data in [esi] is tainted, then eax is tained, too.

May we know, what kind of information do you plan to store in such tag?

> In this instruction, we should first consider whether [esi] is tainted or
> not. This is done by checking the tag in the shadow memory. If [esi] is
> tainted, then the tag for eax in the shadow memory is set, too.
>
> The question is: how to implement the upper functions? maybe I should modify
> the instruction-translation functions to implement the trace of tainted data
> propagation?


I think you should hook all the memory operation related opcode (or to
be precise, Qemu opcode). That way, you won't miss any..

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

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

PS: eduardo cruz might be an interesting person to talk to..he did
instrumention work lately too....

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com