What pros/cons of WDF driver model vs. WDM for rootkits and antivirus drivers. From what I've seen and from personal experience (though I'm still a newbie) WDM is good in that you have to do most of the stuff manually and at the same time you are given the right foundation elements so it is like building a Lego. On the other hand I haven't seen any WDF mentioning in terms of a rootkit being written in WDF ? Is there any particular reason why WDF and more specifically KMDF (and why not UMDF even?) are not widely (at all?) used for development of rootkit/security type of software ?
A friend of mine answered the question:
It's like with security, really (e.g. using PGP as opposed to no encryption). Add more security and it has to become a little more inconvenient and the person who does it has to know some level of details. Make things convenient and they become less secure.
With WDF you are giving up power (and possibilities). So like with security the convenience comes at a price.
But let me liken the WDF / WDM discussion to something that is perfectly within the realm of antivirus software. File system filter drivers (FSFDs). Legacy FSFDs are difficult to write, to debug and to maintain. Some details change in subtle ways depending on the patch level of the OS, not to mention broken APIs or that certain APIs only exist at certain OS versions. The easier method - and used by the majority of AV vendors I am aware of - uses mini-FSFDs, where, similar to the WDF, btw, another driver sits in between you and the kernel from the logical perspective (you can still make direct calls) and abstracts away a lot of the difficult details.
If someone were to write a rootkit in WDF - which has probably been tried - it would be easier to catch, btw. Remember that one of the main objectives of a rootkit is to go udner the radar.
Also keep in mind that MS has two objectives by introducing new driver models:
- cater the needs of devs to have simpler ways of doing stuff and shipping faster
- making it easier for them (i.e. MS) to test drivers (the driver models usually abstract away complexities)
- provide a stabler OS to end users (BSODs are more often than not blamed on MS instead of the vendor that created the driver!)