Windows 11 enthält einen Dienst namens „Windows Health and Optimized Experiences“ (whesvccodecodecode), der seit 2025 in Canary-Builds gesichtet wird und mittlerweile auf jedem aktuellen Windows 11-System automatisch startet. Eine gründliche Analyse des reverse engineering-Experten Xusheng Li zeigt nun: Der Dienst ist kein Spionagewerkzeug, wie kürzlich in sozialen Medien behauptet wurde – doch die darin verbaute SYSTEM-Lua-Engine besitzt Fähigkeiten, die weit über das für Diagnoseaufgaben Notwendige hinausgehen und bereits zu einer bestätigten Sicherheitslücke (CVE-2025-59241) geführt haben.
„Datenversand alle 15 Minuten“ war falsch – doch niemand hatte den Code geöffnet
Ende Juli 2026 verbreitete ein Nutzer auf der Plattform X die Behauptung, whesvccodecodecode sende alle 15 Minuten CPU-Temperatur- und Akkudaten an Microsoft. Der Beitrag erreichte über 95.000 Aufrufe. Scott Hanselman, Vice President bei Microsoft, widersprach öffentlich und erklärte, der Dienst zeichne lediglich lokale Diagnose-Trace-Daten auf, wenn das System langsamer werde. Eine Übertragung an Microsoft erfolge nur, wenn der Nutzer diese Daten über den Feedback Hub freigebe. Mehrere Medien veröffentlichten daraufhin Faktenchecks, und die Welle ebbte ab.
Doch für Xusheng Li, einen Reverse Engineer und Vulnerability Researcher, der unter anderem Debugger-Entwicklung bei Vector 35 (Binary Ninja) leitet, blieb ein entscheidender Punkt offen. Wie er in seinem am 16. August veröffentlichten Analysebericht und dem dazugehörigen GitHub-Repository klarstellt: Niemand hatte die Binärdatei selbst geprüft. Die Berichte stützten sich allein auf Hanselmans Aussage, nicht auf den tatsächlichen Code. Also analysierte Li sämtliche Komponenten des Dienstes – mit aufschlussreichen Ergebnissen, die weit über die Widerlegung der Falschmeldung hinausgehen.
Eine in SYSTEM-Rechten laufende Lua-Umgebung
Der Dienst whesvccodecodecode selbst ist mit 229 Kilobyte klein. Die Kernlogik steckt in der mitgelieferten Bibliothek windiag.dllcodecodecode (946 Kilobyte), die einen vollständigen Lua 5.4.7-Interpreter enthält. Lua ist bekannt als leichtgewichtige Skriptsprache für Spiele und Embedded-Systeme – ihr Einsatz in einem Windows-Systemdienst ist ungewöhnlich.
Die dritte Komponente, whesvc_assets.dllcodecodecode, enthält keinen ausführbaren Code, keinen .textcodecodecode-Abschnitt und keine Debug-Symbole. Stattdessen sind in ihren Ressourcen 84 vorkompilierte Lua-Skripte abgelegt. Ihre Dateinamen lassen die Funktion erahnen: Sie reichen von der Erkennung von Hängern über die Aufzeichnung langsamer Startvorgänge bis hin zur Bewertung von Lüftergeräuschen und der Erkennung von Speicherlecks. Das entscheidende Detail: Der gesamte Dienst, inklusive des Lua-Interpreters, läuft mit den höchsten Windows-Rechten, dem SYSTEM-Konto.
79 native Funktionen – die „Machtfülle“ der Engine
Für die Bewertung einer Skript-Engine ist die Frage entscheidend, welche Fähigkeiten den Skripten über die Schnittstelle zur Verfügung gestellt werden. Wie Xusheng Li in seiner Analyse feststellt, können die 84 Skripte auf einen globalen Namensraum wdgcodecodecode zugreifen, der nicht weniger als 79 native Funktionen exponiert. Die Liste der Funktionen liest sich wie das Repertoire einer vollwertigen Systemverwaltungssprache:
- Lesen und Schreiben von Registry-Schlüsseln
- Beliebige Dateioperationen (ohne Pfadrestriktionen oder Whitelist-Prüfung)
- Erzeugen von Prozessen (z. B. Ausführen von Programmen)
- Aufruf von WMI-Methoden (Windows Management Instrumentation)
- Steuerung von ETW-Traces (Event Tracing for Windows)
- Prüfung von Sicherheitstoken
- Abruf von Energie- und Temperaturinformationen
- Herunterladen von Debug-Symbolen
- Erstellung von CAB-Dateien
- Durchführen von HTTP-Anfragen
- Ein generisches FFI (Foreign Function Interface) zum Aufruf nativer Funktionen aus beliebigen DLLs
Besonders bezeichnend ist die write_datacodecodecode-Funktion für Dateischreibzugriffe. Sie enthält keinerlei Einschränkung des Pfades, keine Normalisierung, keine Überprüfung auf Verzeichniswechsel. Wie Li feststellt, ruft sie schlicht die Standard-C-Funktion fopencodecodecode auf – dieselbe, die auch das Lua-Standard-I/O nutzt. Die Begrenzung liegt nicht in der Technik, sondern ausschließlich in den mitgelieferten Skripten selbst.
Ausgelieferte Skripte: „Langweilig legitim“
Trotz dieser enormen theoretischen Machtfülle zeigt Lis detaillierte Untersuchung aller 84 Skripte: Sie verhalten sich mustergültig. Kein einziges Skript führt verdächtige Aktionen aus.
Dateioperationen dienen lediglich dazu, temporäre JSON-Zusammenfassungen (system_summarycodecodecode) zu erstellen, die dann vom Skript artifact_managercodecodecode unter %ProgramData%\Whesvc\codecodecode archiviert und mit einer Lebensdauer versehen werden. Registry-Zugriffe beschränken sich fast ausschließlich auf das Fortschreiben eigener Zähler über Neustarts hinweg. Die einzige Ausnahme ist das Skript zur Konfiguration des Driver Verifiers – ein Vorgang, der zusätzlich durch Umgebungsvariablen abgesichert ist. Prozesse werden nur an einer einzigen Stelle gestartet: powercfg.execodecodecode zur Abfrage von Schlafberichten. Die mysteriösen „15 Minuten“ entsprechen dem Wert WINDIAG_SYSTEM_SUMMARY_FLUSH_SECcodecodecode (Standard: 900 Sekunden) im system_summarycodecodecode-Skript. Alle 15 Minuten wird eine kleine Telemetrie-Nachricht geschrieben und eine JSON-Datei aktualisiert. Auf Lis Testrechner enthielt die Datei lediglich die Aufzeichnung eines Absturzes seines eigenen Debuggers.
Netzwerkaktivität findet so gut wie nicht statt. Lediglich eine einzige URL ist in den Skripten hartcodiert: der öffentliche Microsoft-Symbolserver (symweb.azurefd.netcodecodecode). Dieser Download-Mechanismus wird jedoch nur aktiv, wenn die Umgebungsvariable WINDIAG_SYM_CLOUD_TOKENcodecodecode gesetzt ist – was auf Standard-Windows-Systemen nicht der Fall ist. Die DLL windiag.dllcodecodecode importiert nur drei WinINet-Funktionen und keine Socket-Funktionen. Der aktive Dienst hält zudem keine TCP- oder UDP-Endpunkte offen.
Wie „Lüftergeräusche“ erkannt werden
Eine der ersten von Li untersuchten Dateien war das Skript SCENARIO/NOISY_FANcodecodecode – aus Sorge, der Dienst könnte das Mikrofon anzapfen. Doch weder windiag.dllcodecodecode noch whesvc.dllcodecodecode importieren Audio-APIs. Die Erkennung erfolgt indirekt über die Lüfterdrehzahl (RPM). Die von den OEMs definierten Schwellenwerte werden in vier Stufen eingeteilt: Low, Medium, MediumHigh und High. Verharrt der Wert zu lange im High-Bereich, wird ein Problembericht erstellt. Die Methode kommt ohne Mikrofon aus – auf Systemen ohne Lüfterdrehzahl-Telemetrie bricht das Skript sofort ab.
Das Sicherheitsmodell: Vertrauen auf Dateirechte, nicht auf Sandboxing
Die aufschlussreichste Erkenntnis der Analyse betrifft die Sicherheitsarchitektur der Lua-Engine. Es existiert eine Art Sandbox: Vor der Skriptausführung werden die globalen Lua-Funktionen debugcodecodecode, requirecodecodecode, oscodecodecode, packagecodecodecode, loadfilecodecodecode, dofilecodecodecode und loadcodecodecode aus der Umgebung entfernt. Dadurch soll verhindert werden, dass externer, nicht-signierter Code nachgeladen wird. Doch Li bewertet diese Maßnahme als „weniger eine Sandbox, eher eine Namensraum-Bereinigung“. Der iocodecodecode-Namespace ist nicht gesperrt, und die Funktion io.popencodecodecode wird sogar bewusst als io_popencodecodecode re-exportiert – etwa um wpr.execodecodecode für ETW-Traces aufzurufen. Kernelemente der Lua-Standardbibliothek werden vor dem Löschen in Referenzen gesichert; das Skript core/globalcodecodecode hält eine Upvalue namens sandbox_stripped_refscodecodecode. Die Sicherheit hängt also nicht von der Sandbox, sondern von zwei anderen Faktoren ab: den Dateirechten und dem Inhalt der ausgelieferten Skripte.
Die DLL whesvc_assets.dllcodecodecode ist korrekt signiert, doch der Dienst prüft diese Signatur zur Laufzeit nicht. Es gibt keinen Import von WinVerifyTrustcodecodecode, keine MicrosoftSignedOnlycodecodecode-Konfiguration, keinen Hash oder MAC im Container-Header. Wie Li betont, wird die Integrität der Skripte allein über die ACL (Access Control List) der DLL gewährleistet: Nur TrustedInstaller hat Vollzugriff; selbst SYSTEM und Administratoren haben lediglich Lese- und Ausführungsrechte. Ein Angreifer, der diese Datei ersetzen könnte, müsste bereits die volle Systemkontrolle besitzen.
CVE-2025-59241: Eine bereits dokumentierte Schwachstelle
Während seiner Analyse entdeckte Li eine weitere bemerkenswerte Tatsache: Der Dienst whesvccodecodecode war bereits Gegenstand eines gemeldeten Sicherheitsproblems. Die Verwundbarkeit mit der Kennung CVE-2025-59241, bewertet mit CVSS 7.8 (Local Privilege Escalation), wurde im Oktober 2025 von Microsoft geschlossen. Die Schwachstelle fällt in die Kategorie „Ungeeignete Linkauflösung vor Dateizugriff“.
Der Dienst schreibt mit SYSTEM-Rechten in das Verzeichnis C:\ProgramData\Whesvc\codecodecode. Die ACL dieses Ordners erbt jedoch die Berechtigungen von C:\ProgramDatacodecodecode, wodurch normale Benutzer hier Dateien und Verzeichnisse anlegen können. Das Skript system_summarycodecodecode schreibt in vorhersagbare Pfade – ein Angreifer konnte durch das Anlegen einer Junction (Verzeichnisverbindung) den SYSTEM-Schreibzugriff auf ein beliebiges Ziel umleiten.
Microsofts Fix ist, wie Li anmerkt, elegant: Unmittelbar nach dem Start ruft der Dienst SetProcessMitigationPolicy(ProcessRedirectionTrustPolicy, 1)codecodecode auf. Diese Kernel-Richtlinie blockiert Vertrauensumleitungen (Junctions, Symlinks), die von weniger vertrauenswürdigen Prozessen erstellt wurden. Statt einzelner Pfadabsicherungen wird eine ganze Klasse von Angriffen unterbunden. Einziges Zugeständnis an die Lua-Ebene: In der Skriptlogik zur Verzeichnisrekursion wurde eine Prüfung auf Reparse-Points eingefügt, die bei Erkennung abbricht. Allerdings, so Li, sei die DACL des Ausgabeverzeichnisses weiterhin geerbt – eine explizite Verriegelung auf Dateisystemebene wäre ein zusätzlicher Schutz.
Telemetriekontrolle: Zwei positive Aspekte
Unter dem Eindruck der Fehlinformationen geht in der Debatte unter, dass Microsofts Telemetriekontrolle im Detail zwei durchdachte Elemente aufweist. Erstens prüft der Dienst bei schwereren Trace-Erfassungen den Wert AllowTelemetrycodecodecode und führt diese nur aus, wenn der Wert auf 3 („Vollständige oder optionale Diagnosedaten“) gesetzt ist. Kann der Wert nicht ausgelesen werden, wird die Aktion abgelehnt – ein Fail-Close-Verhalten. Zweitens ist die „automatische Eskalation“ von Trace-Daten in die Telemetrie-Pipeline bei allen zehn automatischen Szenarien standardmäßig deaktiviert. Die einzige Ausnahme ist hotkey_tracecodecodecode, ein Szenario, das der Nutzer durch Drücken eines Hotkeys selbst auslösen muss.
Fazit: Keine Spyware – aber eine Architektur mit inhärentem Risiko
Xusheng Lis Analyse widerlegt die Falschmeldung vollständig: Der Dienst zeichnet weder den Bildschirm auf, noch verschickt er ohne Nutzerinteraktion Daten. Hanselmans Beschreibung des Dienstes war akkurat. Die eigentliche Leistung der Analyse liegt jedoch in der Offenlegung der darunterliegenden Architektur. Microsoft hat mit whesvccodecodecode eine vollwertige, mit SYSTEM-Rechten laufende Lua-Engine ausgeliefert. Die 84 aktuellen Skripte sind harmlos – aber die Engine selbst ist es nicht. Sie kann jede Datei schreiben, jede Registry manipulieren, jeden Prozess starten und über FFI jeden nativen Code ausführen.
Der Dienst ist keine Spyware, sondern ein Diagnosewerkzeug auf Basis einer generischen Skriptplattform. Der entscheidende Punkt, den Li wiederholt betont: Ein Programm, das einen Lüftersensor ausliest, und eine Engine, die das ebenfalls kann, sind aus Bedrohungsmodell-Perspektive grundverschieden. Erstere hat ein klar definiertes und begrenztes Risiko, letztere erbt alle Risiken einer vollständigen Laufzeitumgebung. Dass dieses Risiko real ist, zeigt die bereits existierende Schwachstelle CVE-2025-59241. Sie ist der Preis für eine überbordende Fähigkeit, die in der Praxis kaum benötigt wird. Die gründliche Analyse von Xusheng Li liefert die Blaupause dafür, warum solche Architekturen einer deutlich kritischeren Prüfung bedürfen, als ein kurzer Faktencheck zu einer Social-Media-Behauptung leisten kann.
