PIN / application-level instrumentation vs. QEMU / system-level emulation

[gitttt]

I am trying to understand the design decision leading to the current TRITON. I was wondering why you did not use qemu/panda to generate the trace? The advantage of your approach I see is that it is faster because you just instrument the target software and do not emulate an entire system. Are there any more reasons why you chose PIN over qemu?

[JonathanSalwan]

It's a good remark. Actually, I choose Pin because I'm more comfortable with the Pin internals than Qemu, that's all :). But I'm aware that the use of Pin may be inappropriate in specific cases. That's why, since 3 weeks I developing the v0.3 (#226) in secret :P which is Tracer, Arch and OS independent. The release (I hope) will be in ~2 weeks. The new design looks like this:

[0ca]

Using PIN you can also modify the value of registers and memory online from Triton. That is how it works the code coverage tool: https://github.com/JonathanSalwan/Triton/blob/master/tools/code_coverage.py

It would be possible to do the same with a "Tracer" re-executing the program per each new input generated but using PIN and the snapshot tool seems to be more efficient, right?

[JonathanSalwan]

but using PIN and the snapshot tool seems to be more efficient, right?

Right.

About that, that's why we don't implemented the snapshot engine into the v0.3, the snasphot engine will be provided by the Pintool (which will be shipped with the v0.3) not the libTriton itself (because it's Pin dependent).