Last week ESET released a Rootkit Detector tool for OS X. I finally gave a look at it today and as I suspected it is useless (unless rootkit authors are not reading my slides like ESET does not seem to). The only thing it appears to be doing is to check if sysent pointers were modified. Let’s be honest, it’s useless in particular when they mention they have limited visibility into OS X rootkits. So the way to improve it is to release a tool that only verifies old tricks from known rootkits. That’s the way to go!

The tool loads a kernel extension that will retrieve some information such as the kernel ASLR slide and sysent table. Just by looking at the code you know this is a fail. It will not work with Mavericks since the sysent structure is different as my SyScan360 slides show.
It is also extremely easy to detect using the same trick to attack the memory dumpers (once again, SyScan360 slides). A device called esysent is created by the kernel extension. Just hook devfs_make_node, lookup for this device and when detected play with it. Game over, flawless victory!

To prove how useless it is, I just loaded my PoC rootkit using the shadow sysent method and ESET tool says there is no rootkit loaded. The system is safe. Yeah, right!

Besides the useless scanning technique used, its design can’t work. It requires a driver to analyse what is happening inside the kernel and that’s is the weakest link. A rootkit can easily control and react to drivers being loaded. The real problem is no Apple supported interface for interacting with kernel memory in a default install (kmem can be enabled with a boot parameter, non-default). I doubt Apple will ever restore /dev/kmem by default or implement a secure interface for this kind of stuff because there is no such thing as OS X rootkit(s), right?

Conclusion: don’t trust this tool or any other tools that promise point and click rootkit hunting. The game is a bit harder and you can’t win playing it with this kind of tools.

ESET, at least read my slides ok?

Have fun,
fG!