inpout driver is a security risk.
As long as the inpout driver used by ZenTimings is installed it allows universal read-write access to the whole systems memory. This is especially problematic because it enables software running without admin privileges to do that.
I have no viable alternative, that's why I'm thinking of killing the project, although don't really know how to handle that properly. Other apps also use this driver (including most of the other oc utilities for Ryzen APU/CPU, realbench, LibreHardwareMonitor and more), so it is still a concern. If it wasn't for the power table (read from memory), I wouldn't need such a driver and could only use WinRing0 DLL). The problem is it needs to be signed and also free to distribute.
I don't have the knowledge to write new proper kernel driver and even if I could, it needs to be signed, which costs a lot of money as far as I know.
PS: The only similar OC software that I know and which doesn't use inpoutx64 is Hydra, but it disguises the Intel pmxdrv.sys as a driver with another name and as an open-source project don't think I'm allowed to do this and distribute it with ZenTimings.
Plus older versions of pmxdrv are said to be vulnerable as well.
Only having the driver installed while Zen Timings is running would be a improvement. Because currently after you use Zen Timings the driver stays installed.
The developers of that driver could have easily used the WdmlibIoCreateDeviceSecure api to make administrative privileges required to use the driver but they didn't.
Yes, I have the code for uninstallation and cleanup on close (not in a release build), but it is still problematic if some other app is using the driver at the same time. Will think about it.
@alberts8 I'm going to try remove the original DLL and implement an own installer of the kernel driver and service.
Only having the driver installed while Zen Timings is running would be a improvement. Because currently after you use Zen Timings the driver stays installed.
The developers of that driver could have easily used the WdmlibIoCreateDeviceSecure api to make administrative privileges required to use the driver but they didn't.
This is finally coming in the future update (auto-uninstall of the driver), the rest is not ready yet.