Microsoft hat für die geplagten Administratoren von Windowssystemen ein kleines Powershellscript herausgegeben. Damit werden einige Infos aus dem Prozessor, BIOS/UEFI und von Windows ermittelt und dargestellt. Damit lässt sich zum momentanen Zeitpunkt dann leicht nachvollziehen, ob ein Rechner noch Updates oder Änderungseinstellungen braucht.
Hier zunächst der Link zum Powershell-Script: https://gallery.technet.microsoft.com/scriptcenter/Speculation-Control-e36f0050. Hier noch die offizielle Beschreibung dazu von MS: https://support.microsoft.com/en-us/help/4073119/protect-against-speculative-execution-side-channel-vulnerabilities-in. Gleich noch der Link zur Powershell Gallery: https://www.powershellgallery.com/packages/SpeculationControl/1.0.3.
Wenn man Updates von einem Hardwarehersteller benötigt, ist auch diese Liste noch hilfreich: https://www.heise.de/newsticker/meldung/Meltdown-und-Spectre-Die-Sicherheitshinweise-und-Updates-von-Hardware-und-Software-Herstellern-3936141.html. Hier eine Liste mit Links von MS: https://support.microsoft.com/en-us/help/4073757/protect-your-windows-devices-against-spectre-meltdown.
Aber wo ich eigentlich drauf hinaus wollte, war diese nette PInvoke-Definition im Powershell-Skript:
$NtQSIDefinition = @‘
[DllImport("ntdll.dll")]
public static extern int NtQuerySystemInformation(uint systemInformationClass, IntPtr systemInformation, uint systemInformationLength, IntPtr returnLength);
‚@
$ntdll = Add-Type -MemberDefinition $NtQSIDefinition -Name ’ntdll‘ -Namespace ‚Win32‘ –PassThru
Um NtQuerySystemInformation sinnvoll anwenden zu können, braucht man noch etwas drumherum:
[System.IntPtr]$systemInformationPtr = [System.Runtime.InteropServices.Marshal]::AllocHGlobal(4)
[System.IntPtr]$returnLengthPtr = [System.Runtime.InteropServices.Marshal]::AllocHGlobal(4)
[System.UInt32]$systemInformationClass = 201
[System.UInt32]$systemInformationLength = 4
Nun kann man einen Aufruf wagen:
$retval = $ntdll::NtQuerySystemInformation($systemInformationClass, $systemInformationPtr, $systemInformationLength, $returnLengthPtr)
Ist $retval vom Wert 0 ist alles gut, bei 0xc0000003 oder 0xc0000002 ist $systemInformationClass nicht vorhanden. Alle anderen Werte stellen einen Fehler dar.
Nach dem Aufruf zeigt $systemInformationPtr auf einen Speicherbereich, welche die Daten vom System enthält. Diese Daten kann man z. b. so abfragen:
[System.UInt32]$flags = [System.UInt32][System.Runtime.InteropServices.Marshal]::ReadInt32($systemInformationPtr)
$flags enthält anschließend die ersten 4Bytes.
Hat man die Informationen, die einen interessieren, dann gibt man den Speicher wieder brav frei:
if ($systemInformationPtr -ne [System.IntPtr]::Zero) {
[System.Runtime.InteropServices.Marshal]::FreeHGlobal($systemInformationPtr)
}
if ($returnLengthPtr -ne [System.IntPtr]::Zero) {
[System.Runtime.InteropServices.Marshal]::FreeHGlobal($returnLengthPtr)
}
Die Freigabe sollte auch im Fehlerfall erfolgen, weshalb man ein try catch drumherum bauen sollte.
Jetzt stellt sich die Frage, wie kommt man an die gültigen SysteminformationClass-Werte und die zurückgegebenen Strukturen? Diese findet man zum Beispiel hier: http://www.exploit-monday.com/2013/06/undocumented-ntquerysysteminformation.html. Weitere Infos gibt es hier: http://www.geoffchappell.com/studies/windows/km/ntoskrnl/api/ex/
sysinfo/query.htm.
Wer mehr mit der Geschichte spielen möchte, der nimmt Get-NtSystemInformation aus dem PowershellArsenal: https://github.com/mattifestation/PowerShellArsenal.
Ach wenn ich schon am verlinken bin, hier noch wie man damit PerformanceCounter abfragen kann: http://blog.whatsupduck.net/2010/05/querying-peak-commit-bytes-with.html. Oder wie man gelockte Filehandles in Erfahrung bringen kann: https://blogs.technet.microsoft.com/heyscriptingguy/2013/12/01/weekend-scripter-determine-process-that-locks-a-file/. Der Kernel weiß eben über alles Bescheid 
.
Wer sich für weitere Möglichkeiten von NtQuerySystemInformation interessiert, der sollte sich noch nach ZWAPI.H umschauen…
Das nie endende Chaos! 