Is there anything like PIN or DynamoRIO to instrument at Kernel level? The platforms I'm more interested on are Windows and OSX.

  • 5
    Linux covered here.
    – Igor Skochinsky
    Commented Apr 15, 2013 at 22:55
  • 5
    Related: stackoverflow.com/questions/8058005/… and the DanamoRio developers are activly interested in Mac OS X(updated as of yesterday): code.google.com/p/dynamorio/issues/detail?id=58
    – cb88
    Commented Apr 16, 2013 at 10:14
  • @joxeankoret: I'd suggest to split the question into two, one for Windows one for MacOSX. vTune clearly does what you're asking, so I reckon it is possible.
    – 0xC0000022L
    Commented Apr 16, 2013 at 14:46
  • @0xC0000022L I don't think we need to split it. An answer for just one platform is more than what I honestly expect. BTW, as far as I see, vTune does not support instrumenting at kernel level in Windows, does it? Commented Apr 16, 2013 at 15:53
  • An additional point of interest for just detouring instead of a dbi framework is something like NCodeHook. It needs a little work to get to kernel space, but not much. Commented Apr 19, 2013 at 22:40

1 Answer 1


Tools like Qemu or Bochs are IMO pretty similar to DBI frameworks conceptually and they work on the entire system, including the kernel. Research efforts like BitBlaze and S2E have used modified versions of Qemu to trace kernel mode components for bug finding.

The key difference, I think, is that Qemu/Bochs as whole system emulators do not present a by default view of the program under inspection as a DBI does. A DBI allows for dynamic editing of the program by default. Emulators have the primitives required to effect DBI, they can read and write memory and by extension program code, but they do not provide the API that PIN does for program modification.

So the best I can do is, you can use Qemu to make a kernel mode DBI and others have done this, but I don't know of something more usable out of the box.

  • This is true, but as noted in the intro to the DynamoRIO kernel paper, one big reason to do DBI in the kernel is because you want to analyze device drivers. And QEMU etc. emulate a fairly limited range of hardware. The S2E project has done a little bit of work in this area by using symbolic execution to fake out the missing device inputs, but it's not a panacea. A real kernel DBI solution that can run on real hardware would be better. Commented Apr 20, 2013 at 17:33
  • Oh there was a system that did this called Simics, you could program device drivers in Python or C. I wonder if it's still for sale.
    – Andrew
    Commented Apr 20, 2013 at 20:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.