Closed danyhm closed 1 year ago
Hi did you packed your driver in some way? If so you can try without pack it or try to debug where is the wrong reading and send a pull request to include into the source
Hi, Thanks for reply.
actually, I just found out it was not the problem with resolving imports. since the next step is calling the driver entry, the logs were not being written to the console in time so I had to put a Sleep(100);
after each log to find out that it is a problem with calling the intel_driver::CallKernelFunction
right after displaying Callback example called
I'm trying to load this hypervisor https://github.com/wbenny/hvpp
I guess is has something to do with the custom entry point. should I just change the name of the driver entry?
the driver is compiled with /GS option. your mapper works with /GS- option . does this mean I have to disable /GS ?
Original driver entry params are not supported, this is not a real driver loading just calling driver entry on kernel this for example is an insta bsod: https://github.com/wbenny/hvpp/blob/84b3f3c241e1eec3ab42f75cad9deef3ad67e6ab/src/hvppdrv_c/main.c#L36
so many drivers rely on the input parameters. what is the correct way to handle this situation? can you point me to the right direction?
If you really need that parameters for anything, kdmapper isn't the software that you need since the idea is map kernel code without driver loaded and in a hidden way, anyway you can call kernel routines to initialize your own driver with valid parameters but take care of patch guard since you are executing from bad memory it can bsod your driver for security
The only idea i have is to use kdmapper to disable DSE temporarily anf then load my driver normaly and enable DSE again. This way patchguard won't trigger if the whole operation is done quickly
Hello, my driver doesn't even gets to entry point and kdmapper hangs in resolving imports https://github.com/TheCruZ/kdmapper/blob/3a21e3a5a8955633d6b8fb159ae605420e44802e/kdmapper/kdmapper.cpp#L119
any ideas?