Closed x0rh closed 5 years ago
And other kernelEx approachs?
"Added KernelEx Virtual Device (VKrnlEx.vxd) project which makes modification of kernel32.dll file on disk unnecessary by patching the image directly in memory from kernel space before the shell starts Implemented a fix for a crash occuring when accessing a locked file through file mapping object Some programs shouldn’t complain about not having admin privileges anymore"
Windows NT and its drivers are different beasts from Windows 9x and VXDs :p
But yes, it would be nice to have compatibility implemented as a driver/loader of sorts. OS file replacement is the reason I am hesitant to use One-Core-API in the first place.
I think using very thin hypervisor (such as Bitvisor) would be even a more transparent way to handle in-memory patching.
Something like Viton or GeenKiller to detect drivers loading: https://www.ffri.jp/assets/files/research/research_papers/bh-usa-08-Murakami.pdf https://www.ffri.jp/files/research/research_papers/avar-2009-murakami.pdf ... just not to prevent their patching but to actually do it in transparent way.
Well, as Bitvisor is bare-metal (Type 1) hypervisor, I wonder whether this type it's best suited for transparent module patching. Maybe by virtualizing an OS in a hosted way (using Type 2 hypervisor) it would make easier to know addresses / handles of loaded modules to be patched.
If API redirection based on app directory is possible it will be awesome
Well, is any one there able to do this? I'm not able to this it and i don't have time to learn. So, the one-core-api "patching" keep how is.
Could One-Core API has the kernelex on-the-fly patching in memory, while the system is performing the startup via a specialized driver?
"KernelEx enters the dark world of VMM and kernel drivers. In this release KernelEx doesn’t make any modifications to system files on disk. Instead all patching is done on-the-fly in memory, while the system is performing the startup via a specialized driver."