Is there anything like PIN or DynamoRIO to instrument at Kernel level? The platforms I'm more interested on are Windows and OSX.
-
5Linux covered here.– Igor Skochinsky ♦Apr 15, 2013 at 22:55
-
5Related: 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– cb88Apr 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 ♦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?– joxeankoretApr 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.– RobotHumansApr 19, 2013 at 22:40
1 Answer
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. 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.– AndrewApr 20, 2013 at 20:26