KsDumper Driver unloadable? Maybe any mapped driver? about kdu HOT 4 CLOSED

In general:
Nothing prevents you from tracking all your resources (threads, memory, hooks, objects whatever you created in kernel mode) and releasing them by sort of request thus making your code "unloadable". Your mapped driver has your own allocated driver object and standard communication scheme that's why it works for you.

Regarding exact readme:
Since it impossible to predict whatever usage of this tool will be and what kind of "drivers" will be mapped readme states general state. You can "unmap" what loaded - there are multiple ways to do that, all depends what your "driver" is doing and how but there is impossible to implement this on KDU side due to obvious reasons.

General purpose of this KDU "map" feature is about giving your code r0 access, what you will do with it is totally on your own. Target driver maybe using threads, setting hooks, allocating additional memory - whatever, everything must be tracked and terminated/freed upon "unmap", including own driver code memory. How you will do that (shellcode, another vulnerable driver/workitem) is out of this topic scope.

There are some caveats also. Don't forget also that driver unloaded with API will be moved later to internal list of unloaded drivers which I assume many users of this project doesn't want. Have no idea if this is already Microsoft concern or maybe added in the future, but unloading with API what wasn't loaded with API is a perfect < insert PatchGuard bsod > moment.

from kdu.

This makes sense as to why it works for KsDumper, it's a very basic kernel driver that's being loaded. So there's really nothing to track.
Ive realized the scope of this project recently when I was updating KsDumper 11, very amazing work.
I appreciate the detailed response on this too.

So should I be wary of giving the ability to unload the driver via API since Microsoft could patch to check for that and bsod? It's already an option to unload the driver on program exit, but if it becomes a situation as mentioned above, should I get ahead of that and not unload the driver but instead keep it running as in the original program?

from kdu.

If it works then why not. Its not some mass production critical infrastructure software isn't it? It's impossible to predict future OS changes, some code in NT wasn't changed since 4.0 so...

from kdu.

Good points, if it works it works lol.

from kdu.