Das Auslesen von Temperaturen oder Lüftergeschwindigkeiten ist eine äußerst hardwarenahe Angelegenheit.
Einfache Funktionen des .NET Frameworks reichen nicht aus, um auf die entsprechenden Register der CPU (MSU) oder des Mainboards zuzugreifen. Oft ist es erforderlich, auf Treiber zurückzugreifen, die den Zugriff auf diese Register ermöglichen.
Darüber hinaus erfordert das Verarbeiten dieser Informationen ein umfangreiches Wissen über entsprechende Hersteller-Produkte, da sich diese mit jeder Generation ständig ändern. In den Anfangsjahren von servereye (2008/09) war es notwendig, sich durch technische Anleitungen von Intel und AMD in technischem Englisch zu arbeiten und zudem eine lange Liste von Fachbegriffen wie TJMac, TSC Frequency, Slope und zahlreichen Registeradressen zu bewältigen.
Jede neue Generation trieb uns in den Wahnsinn, da die Dokumente schwer zu beschaffen und solche spezifischen Änderungen nicht erkennbar waren. Zusätzlich benötigte man auch noch den entsprechenden Prozessor für einen Test – na klar. Immerhin hat man Zugriff auf Adressen wie „0x019C“ – wo auch immer das sein soll. Ob einem damals vielleicht ChatGPT weitergeholfen hätte? Negativ – sogar die AI ist damit überfordert:
Innerhalb der .NET-Welt existieren zahlreiche bemerkenswerte Gemeinschaftsprojekte, die genau dieses Fachwissen bündeln und von weltweitem Feedback aus verschiedenen Branchen profitieren. Dies ermöglicht uns nicht nur, zuverlässig die CPU-Temperatur, Lüftergeschwindigkeit und GPU-Daten anzubieten und zu überwachen, sondern auch, neueste Entwicklungen effizient zu integrieren und davon zu profitieren.
Nach all den Jahren wurde jedoch eine Sicherheitslücke im verwendeten Hardware-Treiber entdeckt. Erste Antivirenprodukte meldeten diese Schwachstelle und blockierten den Treiber. Das Schließen der Lücke war an sich keine allzu große Herausforderung, zumal Personen, die Sicherheitslücken melden, oft direkt Lösungsvorschläge bieten. Allerdings hatte Microsoft inzwischen – verständlicherweise – die Anforderungen an Treiber erhöht. Während es in der Vergangenheit möglich war, Treiber selbst zu signieren und in Windows zu laden, erforderte nun Windows 10 (und höher) einen aufwändigeren Prozess.
Es ist erforderlich, zunächst eine erweiterte Signatur zu erhalten – anschließend muss der überarbeitete Treiber zur Prüfung bei Microsoft eingereicht werden (Windows Hardware Dev Center). Erst nach erfolgreicher Überprüfung erhält man demnach einen Treiber, der nicht nur von dem Entwickler selbst, sondern auch von Microsoft signiert wurde.
Also – zurück auf die Schulbank und erneut Arbeit in die Anpassung / Kompilierung von Treibern sowie in das Einreichen bei Microsoft investieren. Ein großes Dankeschön an den Avast Support, mit dessen Unterstützung Tests durchgeführt werden konnten, um sicherzustellen, dass die Sicherheitslücke nun auch wirklich geschlossen war.
Wo ein Wille ist, ist auch ein Weg und so sind wir voller Stolz, im Client Update H1/23 den Treiber in einer aktualisierten, sicheren Variante anbieten zu können. Möge also die Zukunft weiterhin unsere CPUs zum Glühen bringen und freudig Alarme im Dashboard erzeugen – in der guten Gewissheit, dass wir dies immer noch erkennen können!