KsDumper Driver unloadable? Maybe any mapped driver?

[mastercodeon314]

I have been using KDU for about a year now to support KsDumper 11, the revival of KsDumper with win11 support.
https://github.com/mastercodeon314/KsDumper-11
I was able to add functionality to the KsDumper driver to be unloadable. This is interesting since the readme for KDU says that i cannot have mapped code unload itself, however, i am able to setup an IO CTRL code and when getting that IOCTRL code, the driver calls the Unload function.
NTSTATUS Unload(IN PDRIVER_OBJECT DriverObject) { IoDeleteSymbolicLink(&symLink); IoDeleteSymbolicLink(&deviceName); IoDeleteDevice(deviceObject); return ZwUnloadDriver(&deviceName); }

This seems to contradict what it says in the readme, but i am not sure if i am releasing all resources allocated by my mapped code.
Any explanation on this?
Usage of the ZwUnloadDriver made this possible,

[hfiref0x]

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.

[mastercodeon314]

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?

[hfiref0x]

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...

[mastercodeon314]

Good points, if it works it works lol.