Martin,
Another viable option is use smth like PTLSIM (http://www.ptlsim.org/)
which could be more suitable for your particular task (although
performance may suffer).
Thanks,
Nikolay
Sander van Leeuwen пишет:
Martim,
The software virtualization code scanner was not designed to catch all
occurrences of certain instructions, but
rather as a helper for static scanning upfront and dynamic scanning
after hitting certain faulting instructions.
You can modify CSAM to inject int 3 patches (0xcc instructions) for
all call and ret instructions it encounters.
When you hit such an int3 patch, then you can do whatever it is you
wish and invoke the scanner for a target address
you haven't encountered before. It shouldn't be very hard to adjust
the code to do just that and to emulate all ret and
call variants.
The only tricky thing is dealing with self-modifying code. We already
invalidate patches when unsupported modifications occur, but
you'll have to take this into account for further scanning too.
Sander
On 15-4-2010 23:21, Martim Carbone wrote:
Hello,
Thank you for your replies to my previous question "VBox CSAM/PATM in
VMX mode".
I think I should probably make my intentions clearer. My ultimate goal
is to be able to intercept, from inside the hypervisor, all
kernel-level executions of CALL and RET instructions performed by a
guest OS. I understand the performance implications of this.
Considering the role that CSAM/PATM already play, it seemed natural to
me that these could be extended so that kernel CALL and RET
instructions could be dynamically "patched" (as already done with
sensitive operations) with code which would trap to the hypervisor
upon execution. If CSAM/PATM are not used in VMX mode, I can live
without VMX. The question really is to what extent would CSAM/PATM
need to be modified to implement this kind of CALL/RET tracing.
I'm not expecting a step-by-step guide, of course; rather an estimate
from more experienced Vbox developers (as I'm not myself very
experienced) as to what amount of effort would be involved in this
addition and any possible pitfalls that I should watch out for when
modifying the code.
Thanks again,
-- Martim
_______________________________________________
vbox-dev mailing list
[email protected]
http://vbox.innotek.de/mailman/listinfo/vbox-dev
_______________________________________________
vbox-dev mailing list
[email protected]
http://vbox.innotek.de/mailman/listinfo/vbox-dev
