Insecure Code vs. the Entire RGB Industry | WinRing 0 Driver, ft. Wendell of Level1 Techs

As always, being pessimistic about this kind of thing has eventually paid off, with Hyte emailing us in March and The Verge posting a story about WinRing0 being flagged as a threat by Windows Defender (that article is worth a read for the statements provided by several developers). 

We contacted our own list of developers, and then reached out to Wendell from Level1Techs to help us talk through the technical aspects. This article explores the history and story of the WinRing 0 driver.

History Part 1: WinRing0's Creation

WinRing0 is a library originally released in 2007 by Noriyuki Miyazaki [宮崎 典行] (AKA hiyohiyo), and he regrets it.

The developer is best-known for CrystalDiskMark and CrystalDiskInfo. According to the active GitHub repository, "WinRing0 is a hardware access library for Windows" and "WinRing0 library allows x86/x64 Windows applications to access I/O port, MSR (Model-Specific Register), [and] PCI." 

Basically, WinRing0, the driver, is a unique open-source window into hardware. Over the years, it's become the equivalent of that XKCD comic for small developers who can't afford to develop and certify their own loopholes for controlling hardware like RGB LEDs and fans. 

If you're part of a small team that wants to distribute software for monitoring or controlling any of the hardware in a PC, WinRing0 has been the go-to option.

Hiyohiyo announced the end of development in February 2010, stating (in Japanese) that "WinRing0 is essentially a library that should not exist [...] I wanted to share the joy of low-level programming with as many developers as possible, so I developed and released WinRing0 after fully understanding the various issues, but I had no choice but to accept that this is no longer acceptable in today's age." 

He repeated that sentiment to us in an email, saying that "I consider it a complete youthful indiscretion on my part not to have accepted the changing times." 

The final update from hiyohiyo was WinRing0 2.0.0 in July 2010, where he intentionally removed almost all functionality, apologized again, and described the project (again, in Japanese) as a "big failure."

There’s something sad about that sentiment. For better or worse, the WinRing0 driver was actually not a big failure: A ton of hardware companies transacting hundreds of millions of dollars in revenue have relied upon it; however, this is probably why hiyohiyo views it as a failure.

Technical Explanation

Given what WinRing0 is -- a method of low-level access to hardware -- it makes sense that hiyohiyo has distanced himself from the project so much, especially since he currently collaborates with Microsoft. The releases of Windows Vista in 2007 and Windows 7 in 2009 made it increasingly clear that Microsoft is no longer in the business of letting you f*ck around with this stuff: 

Windows was moving away from low-level programming. The idea of old-school unrestricted memory access is scandalous these days. As Martin Malik of HWiNFO stated to The Verge, "since the driver has access and doesn’t restrict the range, it can read/change other processes, secrets in memory or protected kernel registers. This is very dangerous." As hiyohiyo stated when closing WinRing0 development 15 years ago, "If you think about why the OS restricts access to I/O ports, physical memory, MSR, etc., and why signing kernel-mode drivers is mandatory since Vista x64, you will understand."

We don't want to get too into the weeds here, but kernel-mode is the alternative to user-mode. 

We interviewed Wendell from Level1Techs, who went on to explain:

“What is the kernel? [You may have] heard of the Linux kernel but Windows has a kernel, too. So the kernel is responsible for management of your system; so process management, memory management, hardware abstraction, security isolation, and system calls, which is like a programmer's calls, like the kernel is going to provide this programmer's interface. You call [it] as a programmer and then the kernel goes off and does something. And so the buck stops with the kernel. So your programs just run and they don't have to deal with things like, ‘which processor am I running on,’ ‘how do I allocate memory?’ It just says I would like to allocate memory and the kernel [asks] how much memory would you like and then you get an address and then that's all handled; memory management, all of the abstraction for all those kinds of things. So the kernel is really the smallest, lowest part of your operating system and it is typically engineered to be as uncomplicated as possible. It's only as complex as necessary to do the task and if it has bugs that leads to a lot of problems, not just in terms of system instability but also security issues and that sort of thing.

Sometimes it's fun to think of it abstractly. Your computer is a bus and all of the apps on the bus are the passengers. The kernel is the driver of the bus and your computer hardware is like the engine, the wheels, the door, the brakes, and that kind of thing. The driver gets to decide how to use everything safely and effectively and if one of the passengers wet willies the driver then that's bad because it may put everybody in danger.”

The only reason that analogy is a bit confusing is because Wendell uses the word “driver” to explain the operation of the vehicle and he uses the word bus to explain the vehicle. 

With that in mind, let's take time to explain WinRing0's namesake: security Ring 0. Wendell elaborates, “There's a lot of ring 0 drivers as it turns out. Ring 0…kernel mode. I'm not a Windows developer [as my] day job but kernel operating system…it kind of makes sense. The things that are close to the hardware are ring 0 and they're supposed to have a relatively low surface area. If you are running an application and the application does something bad, which is ring 3, I believe, the application crashes. If you're running something at ring 0 and it crashes, it has the potential to affect the entire system and so the entire system will crash. Windows blue screens are probably ring 0. What has really accelerated Microsoft giving the boot to ring 0 is the CrowdStrike thing. This has been a problem forever but the CrowdStrike thing taking out the vast majority of infrastructure that runs Windows and Crowdstrike…Microsoft sees this as a problem and so this is basically a casualty of war.

Ideally you have things running in user mode ring three, all things running in user mode ring three. And so all of your software runs at ring 3 and the driver is very small and very low level and very lightweight and doesn't need to run quite as low level as ring 0 but is still sort of in the administrative permissions mode. But at a very low fundamental level, you can use software to update your BIOS and that is a pre-boot environment. You could have malware that lives in your BIOS. I would prefer having a motherboard that has a jumper so that when I want to re-flash the BIOS, I physically have to move a little switch to say yes.”

When we brought up Asus Armory Crate, Wendell added, “It goes the other way too, the BIOS could run arbitrary software.”

Kernel-mode drivers are almost always hardware device drivers, and within the x86 structure these (typically) occupy the highest security ring alongside the kernel: Ring 0. 

This is why a device driver literally named WinRing0 getting handed out to anyone who wants it might be a little alarming to Microsoft. As confusing as it is, Wendell's still pretty positive on the basic concept of security rings: “The ring 0, ring negative 1, ring 1…that’s all very tightly coupled with hardware features of x86 to provide isolation, which is great. There's different approaches from AMD and Intel, but there is there is a hardware aspect of this that is very nice for users as well so it's not just like you're entirely reliant on a 100% Microsoft software solution but a lot of this is how Microsoft has chosen to implement the various security levels but it dovetails with a lot of functionality that is at the hardware level, which is nice because the hardware is trying to protect you from code that shouldn't be executed.”

Digital Signatures

Microsoft's method for mitigating those concerns has been to require digital signatures for kernel-mode drivers in all Windows versions since 64-bit Vista. A digital signature is a certificate issued by a "trusted Certification Authority" (CA) that verifies that: "the file, or the collection of files, is signed. The signer is trusted. The certification authority that authenticated the signer is trusted. The collection of files was not altered after it was published." 

Back when WinRing0 was first published, individuals (in Japan) could sign drivers themselves, which hiyohiyo did. More expensive and difficult-to-obtain Extended Validation (EV) certificates were required starting in the Windows 8 era, and they're only issued to businesses, but old drivers were grandfathered in.

Over the years when installing a piece of software, you might have seen some kind of popup about the driver signatory, the lack or the presence of a signature. And we see this a lot with the prototype versions of software where they haven't signed it yet but as for why digital signatures are a useful idea in general, we turn again to Wendell who stated:

“As part of Microsoft’s strategy to deal with…driver signing, in general, any kind of executable signing is actually sort of fun and interesting. It’s a fun and interesting way of approaching security. If you right click on basically any executable on any modern Windows system and you look at the properties, you can see that the executable is digitally signed. That's an identity thing [that indicates] this is from [a particular] company. Drivers are a great way to hide malware and so it has to kind of be a walled garden and so the certificates you have on a website are really not [too] different or the executables from programs are really not [too] different from what you have for a driver. Basically you create the driver. You submit it to Microsoft and well, the submit-it-to-Microsoft process doesn't actually technically have anything to do with signing, but theoretically, Microsoft looks at you as a company and says ‘Okay, yes, we're going to be able to do business with you.’ And you get something that you can sign that is trusted and it is it is the standard certificate signing process where [you say] ‘here is my certificate’ [and] I'm going to send this somewhere that will then say: ‘okay, yes, we are going to sign the certificate that you have asked for except instead of being based on a hash or something ephemeral, it's based on the hash of the actual binary of the driver.’ And so this driver with this hash has been signed and if somebody tampers with the driver or changes it then the cryptographic signature will no longer match and the driver doesn't work anymore and so it's a nice way to affirm that something has signed off on the contents of this driver and this driver is good.”

Wendell also interestingly pointed out that CAs can be broken into and certificates can (and have been) stolen, but that's a subject for a different time.

So, hiyohiyo apologized for pulling the plug and refusing to maintain WinRing0's certification back in 2010, seemingly with the expectation that its certification would be pulled and everyone's projects would break: 

"WinRing0 was discontinued without any alternative plan in order to avoid the worst case scenario of the signature being revoked" and  "if the digital signature for WinRing0 is revoked, all WinRing0-based applications will be unable to start in an x64 environment."

History Part 2: WinRing0's Adoption

That brings us to the second part of WinRing0’s history.

WinRing0 actually became a foundational element of many, many projects, and some of those projects—like Open Hardware Monitor, later forked as LibreHardwareMonitor—would themselves become foundational to even more software on top of that. So there are nested layers of reliance on something that hasn’t really been even maintained or even liked by its original developer for 15 years. 

Seriously: You have very likely encountered WinRing0 in some capacity, and with the changes Microsoft is making for security reasons, a lot of those software encounters would no longer work today.

And that’s for good reason: Over the years, hiyohiyo's concerns were repeatedly validated.

In 2019, HP got in hot water for including WinRing0 pre-installed in its HP Touchpoint Analytics service "preinstalled on most HP PCs." This became a massive security concern from one of the biggest OEMs.

In 2020, WinRing0 was named in another CVE, or Common Vulnerability and Exposure, for EVGA's Precision X1. In 2021, it was Crucial's turn. Even though specific software was called out each time this happened, HP, EVGA, and Crucial were using the same 1.2.0 version of WinRing0 that everyone else was. 

As GermanAizek put it to us, "The driver was made in 2007. CVE in 2020. Microsoft started blocking it in 2025. Vulnerability has been around for 18 years." As for why Microsoft hasn't blocked it before now, according to OCCT, "They haven't done it yet because big corporations were lazy enough to use it in their software in the past, so that would invalidate their own software, so they cannot do it right away."

And the list of software that has used it at some point, and therefore software that has had vulnerabilities and attack vectors, is huge: CapFrameX (but not PresentMon), Precision X1, Crucial MOD, HP Touchpoint Analytics, SignalRGB, OpenRGB, and many more are on the list.

The issue isn't that Precision X1 or Crucial MOD or any of the vast array of affected software (CapFrameX, OpenRGB, SignalRGB, at least some versions of Afterburner, et cetera) are compromised: the issue is that they install an insecure driver (WinRing0) that's then accessible to any other software that wants it, including malware. 

This is precisely what happened with actual malware SteelFox starting in 2023; the vulnerability is real and has been actively exploited for profit. This isn’t just some proof of concept, this is an actual, in-the-wild malware that has been used to illicitly make money. 

Calling it "theoretical," as CapFrameX did, is irresponsible and dangerous, and it's not really relevant whether the software that installs the driver is itself safe. To quote OCCT:

"It's vulnerable as f*ck."

And here’s what Wendell thought, “If you say the last time the driver was meaningfully updated was in 2008 and it has not yet been exploited by malware, then that's a miracle.” We had to interject and say that it has been exploited by malware. 

For another example of a Ring 0 driver problem (not WinRing 0), check out what Wendell had to say about Crowdstrike, “So what happened was Crowdstrike has a ring 0 malware detection driver and Crowdstrike is otherwise very good software. It's very effective at what it does. It's an interesting security architecture. They made a mistake in their software and as a result of the mistake, the system tried to jump to memory address zero or start executing memory address zero. I don't really remember exactly what the details were but it was something obviously incredibly stupid and there was no safety rails for anything at this level and so systems would crash. And it was an impossible situation because the system would [consistently] boot and crash. If you were lucky after the 20th or 30th time, it would do that, the system would notice and deal with it and so Microsoft is saying ‘this is the wild west. We’ve got to deal with this ring 0 problem immediately and software like CrowdStrike cannot run at ring 0. We as operating system vendors have to provide a lower level facility to let these software vendors do what they need to do but without compromising the integrity of an update process without compromising the integrity of a boot process to provide fallbacks' and that sort of thing. As a result of that…I mean, internally, Microsoft has known this is an issue almost since day one. They didn't care until millions of machines had very large problems, basically every crowd customer that got the update.”

Beyond the current wave of Windows Defender alerts, WinRing0 and similar drivers also have a tendency to get flagged by software like Easy Anti-Cheat due to their ability to read and rewrite memory. You can make your own judgement about how serious the issue is, but these are not false positives. We want to make sure that’s clear. It isn’t a “false positive,” it’s just a true positive.

As hiyohiyo stated fifteen years ago: "although a general-purpose hardware access library such as WinRing0 1.x is very useful for prototyping, developers would need to develop dedicated device drivers for public release." 

But there needs to be a better, secure solution to gain access to this control and hardware. There is one and there has been one. As a developer, the 100% proper by-the-books response to this (from talking to numerous people) is to drop WinRing0, develop your own dedicated driver for your specific product, and obtain a signature for it. 

This is apparently the path that EVGA took back in 2020 after that CVE we mentioned.  

New signatures for kernel-mode drivers are really only accessible to large companies, though, with smaller dev teams unable to afford dedicating their time and money (in recurring payments) to the process, not to mention the software development work. 

Other manufacturers, including Hyte, have informed us that EVGA was somewhat propping-up fan control and RGB software by getting signatures on the driver. We’ve had a tough time trying to verify some of these claims, but that seems to be the belief held by, for example, Hyte. 

Therefore, WinRing0 has been eternally recycled and eternally frozen at vulnerable version 1.2.0. 

If you dig around in LibreHardwareMonitor's source code (for example), it references WinRing0.sys 1.2.0.5 from July 2008, which makes sense: hiyohiyo's next release included a reference in a patch note, saying that "it would have been an easy fix if only a digital signature could be obtained, but since the kernel mode driver cannot be updated, this was scrapped." 

According to Martin Malik of HWINFO64, this day of reckoning has been a long time coming, with Microsoft repeatedly warning that the driver would be blocked.

Again, we've heard unconfirmed reports that EVGA possibly took up the maintenance for WinRing0's digital signature in the post-2010 era, possibly arranging for its renewal (as we understand that certificates expire over time) or just convincing Microsoft not to revoke it. If EVGA had any involvement, it probably ended in 2020 when the company stopped using WinRing0, or at least in 2022 when the company basically halted operation. Microsoft's statement to The Verge that "we are aware of reports about gaming and monitoring applications being flagged as a threat due to the use of unsigned versions of the WinRing0 driver" implies that the driver is now unsigned, which could be a further clue that EVGA was doing some kind of upkeep behind the scenes.

Somehow, we continue to learn EVGA’s impact beyond its GPUs.

The Future of WinRing0

All of this is a problem, because there are limited tools to control hardware through the OS -- and for good reasons -- but there needs to be something, and currently, many of those tools are breaking or broken. Or insecure.

That brings us to the future of WinRing0.

The easiest solution to all this would be to patch WinRing0 itself. After hiyohiyo's last constructive contribution in 2009, Herman Semenov [Герман Семёнов] (AKA GermanAizek) took over maintenance in 2019, initially with the goal of optimizing crypto mining with access to CPU MSR registers. As he stated to us, "around 2023, many people wanted to build WinRing0 Windows driver themselves to increase mining hashrate, even though it was much more difficult than just mining on Linux."

In a weird way then, crypto mining potentially provided something directly useful to those controlling hardware for non-mining use cases.

Development accelerated in 2023 as other members contributed to the project, adding x64 support and fixing some BSOD triggers in the old driver. Eventually, the team applied patches to address the open CVE from 2020. Critically, this fork of WinRing0 remained unsigned: only the un-optimized, insecure version from 2008 had the valid signature vital to projects like LibreHardwareMonitor.

This is where HYTE has stepped in. HYTE originally contacted us with the story, stating that it wants to take the version of WinRing0 that GermanAizek's team has been updating, submit it to Microsoft for signing, and fork LibreHardwareMonitor to integrate the patched, signed driver. HYTE would then take on the responsibility of paying Microsoft, basically replacing EVGA’s assumed role in this chain.

The direct benefit is that HYTE's own software can continue to function, while the rest of the industry gets to keep using WinRing0 (and LibreHardwareMonitor) without getting auto-quarantined by Windows Defender.

GermanAizek told us that "these fixes restrict the use of the driver only to programs running with administrator rights." This is certainly safer, but (as Martin Malik of HWiNFO warned The Verge), this just means that an app has to be run as admin before it can access the driver. 

We asked Wendell about this. Specifically about running things as admin and how much that might help. Here’s his response:

“That's probably not unreasonable. Short of Microsoft getting involved and offering a better solution or somebody that is that deep in the Microsoft kernel driver developer ecosystem, that's probably what it would take: somebody that has very deep intricate knowledge of the operating system and also knows what the operating system is capable of. As far as I know, you're on your own to implement a lot of the functionality that would be needed to do that. So this driver is probably still your best hope to do that. Microsoft probably doesn't want to adopt the driver, which would also be a reasonable outcome. At the same time, Microsoft probably doesn't want to re-implement the functionality that's in the driver, but how this is usually done is you peel away the minimum functionality and you stuff that in your ring 0 driver and then you have all of the other stuff live somewhere else. And that ring 0 driver, you trust not to be able to be manipulated to access memory, it's not supposed to or write to a bus address that it's not supposed to be able to.”

So, as Wendell helped us understand, the idea that a combination of patches and signatures can fix the root cause of the problem is arguably misguided. 

We contacted Franck Delattre of CPUID (CPU-Z, HWMonitor), who explained that CPUID has had similar difficulties with its own software. "In order to fix the problems, we had to move a big part of the user code into the kernel code, in the unique goal of reducing exposure. We could do that because only our code uses our driver, but for a generic driver like WinRing0, this was simply not possible since its functions were used in a different context by the different application. To go further, this means that no replacement of WinRing0 is possible, at least not with the same genericity that WinRing0 provided until today." 

In other words, the thing that makes WinRing0 uniquely useful is the same thing that makes it dangerous. 

GermanAizek is literally the frontman for the "fixed" version of WinRing0. 

He told us that "personally, I migrated to Linux and BSD systems because Windows has become really insecure, and as a Unix developer, such operating systems really seem convenient to me." 

He also openly asked that developers use the InpOut32 driver instead of WinRing0 (although we've seen other developers express concerns about that as well).

OCCT has also announced that it will be providing a publicly-available but closed-source alternative to WinRing0, and it's possible that other organizations will follow suit.

Wendell informed us that there are other bigger-picture alternatives, “For sensors and fan speed, one way that you could solve this architecturally is to just move it to a USB controller. That's slightly more cost or if somebody wants to build in a USB client interface then that's probably a marginal cost increase. I'm slightly surprised it hasn't gone in that direction but I'm also slightly surprised because this is a problem for Windows server in the context of the system management bus because servers need access to the system management bus and kind of hilariously, you have the out-of-band management that also has access to the system management bus so like servers have a whole other computer inside them that has access to the system management bus and the same controllers and so you can use that computer within a computer to monitor the sensors. You could just not have that and plug it into USB in the case of client computers. Like I say, we put important things on the system management bus and so like controlling CPU voltage probably should be on the system management bus. Controlling fan speed…You could probably do that through USB, but when it's through USB, the chipset and other things probably are not able to control fan speed. So you end up with a chipset that needs a system management bus so low-level parts of the system can make those controls but user overrides have to come through another path like through USB or something that's low security. Or Microsoft can provide a reasonable facility that is reasonably locked down to access the system management bus facility.”

Conclusion

That’s the story of how this small piece of code has supported an entire industry and its software for 15 years now, even in spite of its own developer disowning it and regarding it as not only a mistake, but a failure. We feel bad for hiyohiyo who now is powerless to stop people from using his youthful development project, but these multi-million and billion dollar companies have the resources to develop a responsible alternative. That includes Microsoft, Razer, and everyone else. 

That brings us around to what power an end user has, if any.

Our recommendation is to do what your antivirus software says: if Windows Defender quarantines WinRing0, let it happen, and if anyone tells you to ignore the warnings, treat them with extreme skepticism. Some manufacturers and developers have called these “false positives,” but they are not. 

They are real positives, and there are real vulnerabilities that have been used which can exploit your machine.

Microsoft appears to have paused the "ban" as of this writing, but it's only a matter of time. If everything goes according to plan, though, the patched driver should be usable soon thanks to HYTE, at which point you can decide whether requiring admin privilege for access meets your personal standard for security. 

For whatever it's worth, the Windows Dynamic Lighting RGB control feature continues to be developed, although it doesn't feel great to be railroaded into using it just because Microsoft bricked the alternatives. 

Still, it's probably the right direction for Microsoft with Wendell stating, “There is one aspect of this where Microsoft is doing the right thing and that is RGB control. Windows 11 allows you to control RGB directly in the operating system. Microsoft [shouldn’t take] half measures here and add some fan controls and or at least provide a programming interface. [Microsoft doesn’t] have to [provide] a GUI for fan control like it did with RGB control but wherever that's plumbed in, [Microsoft should] go ahead and plumb in the other stuff. It's really not any more complicated than that.”

Thanks to the various developers that provided quotes for this piece, as well as Wendell.