Archive for the ‘Windows 8’ Category

Bilder unter Windows gezielt mit der Windows Fotoanzeige öffnen

30 August 2015

Eine Variante die unter Windows XP – Windows 10 immer verfügbar ist, solange es um übliche Dateiformate wie PNG, BMP, TIFF oder JPG handelt ist die Windows Fotoanzeige. Hier der passende Aufruf:

RunDLL32 "%ProgramFiles%\Windows Photo Viewer\PhotoViewer.dll",ImageViewer_Fullscreen C:\temp\test.bmp

Dabei muss der Bilddateiname immer als absoluter Pfad angegeben werden!

Leider kennen die Server Versionen von Windows den Photoviewer nicht.

http://www.autohotkey.com/board/topic/51203-run-rundllexe-photoviewerdll-syntax/

Komischer Eintrag im Taskmanager beim Autostartregister

1 August 2015

Der Taskmanager von Windows 8 und Windows 10 kann, wenn man die Detailanzeige aktiviert hat ein Register Autostart anzeigen. In diesem Fenster werden dann alle Programme aufgelistet, die beim Rechnerstart automatisch ausgeführt werden.

Mit der rechten Maustaste kann man zusätzliche Infos zu den Programmen erhalten, indem man die Punkte “Dateipfad öffnen” oder “Eigenschaften” anklickt. Wenn man allerdings einen Eintrag hat, der beide Punkte nicht zulässt, um was handelt es sich dann?

Mittels http://live.sysinternals.com/autoruns.exe kann man sich die Lage genauer anschauen. Dort wird man dann rausfinden, dass das entsprechende Programm einfach nicht mehr existiert, obwohl der automatische Starteintrag noch vorhanden ist. Dies führt dazu, dass die beiden genannten Menüpunkte nicht aufrufbar sind.

Man kann also den Eintrag in Autoruns löschen und wie von magischer Hand verschwindet postwendend auch der Eintrag im Tastmanager.

Man kann den Vorgang auch simulieren, indem man z. B. folgenden Eintrag per Powershell ausführt:

New-ItemProperty -Name Test -Value "C:\temp\test.exe" -Path "HK
CU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"

Schupps taucht ein Eintrag beim Autostartregister im Taskmanager auf.

So bekommt man ihn wieder weg:

Remove-ItemProperty -Name Test -Path "HKCU:\SOFTWARE\Microsoft\
Windows\CurrentVersion\Run"

Passwörter ändern bei Remote-Desktop bzw. Terminalserversitzungen von Windows XP bis Windows 10

20 Juli 2015

Ein harmloses Thema aber dank der Genialität von Microsoft ein Thema, welches schnell ausarten kann. Zunächst einmal die Ausgangsbasis. Es geht darum den Windows Sicherheitsschirm zu bekommen, dass ist der, wenn man an einem physikalischen Rechner sitzt und STRG+ALT+ENTF drückt. Dort werden meistens diese Punkte angezeigt:

  • Computer sperren
  • Benutzer wechseln
  • Abmelden
  • Kennwort ändern
  • Task Manager starten

Jetzt das Problem: Bei einer Remotedesktopsitzung wird STRG+ALT+ENTF immer auf dem lokalen, also physikalischen Rechner ausgeführt und nicht in der Remotesitzung. Ergo kann der Benutzer sein Kennwort nicht selbständig ändern.

Zu Windows XP und Windows 7 Zeiten konnte man nun im normalen Startmenü in der rechten Spalte auf “Windows Sicherheit” klicken. Dieser Eintrag ist immer automatisch verfügbar sobald man sich in einer Remotedesktopsitzung befindet. Aber durch das verschwinden des Startmenü bei Windows 8 verschwand auch der Eintrag mit “Windows Sicherheit”. Selbst die ganzen nachfolgenden Updates zu Windows 8 mit Windows 8.1 Update Update usw. brachten keine Lösung. Auch Windows 10 mit Build 10240 kennt dazu keinen direkten Startmenüeintrag mehr.

Hier nun die möglichen Lösungen:

Variante 1)
Die einfachste Variante man drückt anstatt STRG+ALT+ENTF die Tastenkombination STRG+ALT+ENDE, also anstatt der Entfernen-Taste die Ende-Taste drücken. In den meisten Fällen sollte dies zum Erfolg führen.

Variante 2)
Alternativ kann man mit der Bildschirmtastatur arbeiten. Dazu ruft man OSK.EXE auf und _wichtig_ drückt auf seiner physikalischen Tastatur STRG+ALT und klickt dann auf dem OSK-Keyboard mit der Maus auf die ENTF-Taste.

Variante 3)
Man verwendet ein kleines Skript, üblicherweise Powershell:

Powershell  -command  "(New-Object -ComObject Shell.Application).WindowsSecurity()"

Damit wird auch der Windows Sicherheitsbildschirm angezeigt. Allerdings funktioniert dieses Skript nur, wenn man sich in einer Remotedesktopsitzung befindet. Im normalen Betrieb aufgerufen passiert einfach nichts.

https://msdn.microsoft.com/en-us/library/windows/desktop/gg537748(v=vs.85).aspx?cs-save-lang=1&cs-lang=vb#code-snippet-1

Variante 4)
Seit Windows 8 hat sich ja alles auf die modernen Apps verlagert was bei Tablets auch Sinn macht, denn wer hat schon STRG+ALT-Tasten an seinem Tablet? Deshalb gibt es bei Windows 8 und nachfolgend unter PC-Einstellungen->Konten->Anmeldeoptionen die Möglichkeit sein Kennwort zu ändern. Unter Windows 10 geht man dazu auf Einstellungen->Konten->Anmeldeoptionen.

Eine weitere Variante für Commandliner ab Windows 10 ist der Aufruf von:

start ms-settings:signinoptions

Man kann auch im hypermodernen Edgebrowser in der URL-Zeile direkt ms-settings:signinoptions eingeben und landet dann in der Einstellungsseite. Nur Cortana versteht das noch nicht, irgendwie komisch…

 

So das war der kleine Ausflug in der Geschichte der Passwortänderungen für die Benutzer. Hier noch hilfreiche Links zum Thema:

http://superuser.com/questions/492856/how-can-i-send-a-ctrlaltdelete-through-remote-desktop-in-windows-8

https://social.technet.microsoft.com/forums/windowsserver/en-US/2b67fa96-707b-47c4-90f5-c3a087ba16a9/how-do-i-change-password-when-connected-to-remote-desktop

Hier noch Links zum Thema ms-settings: http://winaero.com/blog/how-to-open-various-settings-pages-directly-in-windows-10/ sowie https://msdn.microsoft.com/en-us/library/windows/apps/xaml/dn741261.aspx und wo es herkommt: https://msdn.microsoft.com/en-us/library/windows/apps/jj662937(v=vs.105).aspx

Änderungen an Windows Firewall protokollieren mit Vergleich vorher/nachher

18 Juli 2015

Wenn man manchmal Programme installiert, dann ändern diese Einstellungen an der Firewall. Wenn man nun protokollieren möchte, was geändert wurde, so kann man sich – wie immer – Powershell bedienen.

Seit Windows 8 gibt es die Network Security Cmdlets, dort findet sich Get-NetFirewallRule. Hiermit kann man folgendes machen:

$fwVorher = Get-NetFirewallRule

Damit erzeugt man quasi einen Snapshot $fwVorher mit den alten Einstellungen der Firewall. Hier ein paar kurze Infos zum Status:

PS C:\Windows\system32> $fwVorher.Count
384
PS C:\Windows\system32> ($fwVorher|where enabled -eq True).Count
138

Es gibt also insgesamt 384 Firewallregeln, davon sind schon 138 aktiviert.

Jetzt geht man her und nimmt Änderungen am System vor. Hier aktiviere ich in einem neu eingerichteten Windows 8.1 Pro den RemoteDesktop und frage danach nochmal obige Informationen ab. Ich speichere es aber wieder in einer Variablen.

PS C:\Windows\system32> $fwNachher=Get-NetFirewallRule
PS C:\Windows\system32> ($fwNachher|where enabled -eq True).Count
141

Es sind also drei Regeln aktiviert worden. Stellt sich die Frage, welche das waren? Hier kommt nun wieder die Mächtigkeit von Powershell zum Tragen, denn wir kennen den Zustand davor und danach, somit können wir Powershell beauftragen die Unterschiede zu finden:

PS C:\Windows\system32> diff $fwVorher $fwNachher

InputObject                                                 SideIndicator
———–                                                 ————-
MSFT_NetFirewallRule (CreationClassName = "MSFT?FW?Firew… =>
MSFT_NetFirewallRule (CreationClassName = "MSFT?FW?Firew… =>
MSFT_NetFirewallRule (CreationClassName = "MSFT?FW?Firew… =>

Ja toll, super das wussten wir davor schon, dass es drei Regeln sind. Die Informationsaussage ist gleich 0. Nächster Versuch, das Compare-Object Cmdlet welches dem diff-Alias zugrunde liegt kennt einen Parameter Property mit dem kann man die Eigenschaft bestimmen, welche verglichen werden soll. Vielleicht klappt es ja damit:

PS C:\Windows\system32> diff $fwVorher $fwNachher -Property Enabled

                                                    Enabled SideIndicator
                                                    ——- ————-
                                                       True =>
                                                       True =>
                                                       True =>

Nicht viel besser wie die erste Variante.

OK, die Lösung des Problems ist ein weiterer Paramater: Passthru

Hier die Variante, wo alles schön ausführlich ausgibt:

diff $fwVorher $fwNachher -Property Enabled -PassThru

Eine etwas besser lesbare Variante wäre die hier:

PS C:\Windows\system32> (diff $fwVorher $fwNachher -Property Enabled -PassThru)| select dis*, des*, ena* | Fl *

DisplayName  : Remotedesktop – Schatten (TCP eingehend)
DisplayGroup : Remotedesktop
Description  : Eingehende Regel für den Remotedesktopdienst, um das Spiegeln einer vorhandenen Remotedesktopsitzung
               zuzulassen. (TCP eingehend)
Enabled      : True

DisplayName  : Remotedesktop – Benutzermodus (UDP eingehend)
DisplayGroup : Remotedesktop
Description  : Eingehende Regel für den Remotedesktopdienst, die RDP-Datenverkehr zulässt [UDP 3389]
Enabled      : True

DisplayName  : Remotedesktop – Benutzermodus (TCP eingehend)
DisplayGroup : Remotedesktop
Description  : Eingehende Regel für den Remotedesktopdienst, die RDP-Datenverkehr zulässt. [TCP 3389]
Enabled      : True

Damit hat man nun ein schönes Protokoll, welche Firewallregel aktiviert bzw. deaktiviert wurde.

Übrigens Windows 10 Build 10158 bringt in der Pro Fassung 626 Firewallregeln mit! Da geht was…

Windows 8.1 Images auf neuesten Stand bringen

2 Mai 2015

Hier die offizielle Beschreibung, wie man Images von Windows 8.1 auf den aktuellen Stand bringen kann: https://technet.microsoft.com/en-us/library/dn622020.aspx?f=255&MSPPError=-2147217396.

Dies ist vor allem wichtig, wenn man seinen Rechner auffrischen oder sein Windows über die windowseigene Funktion neu aufsetzen lassen möchte. Führt man obige Anweisungen nicht durch, landet man schnell bei Windows 8.

Aber Vorsicht bei kleineren Geräte mit <= 32GByte Festplatte, da sollte man die Sache nicht anwenden. Der Artikel über WIMBoot geht darauf ein: https://technet.microsoft.com/en-us/library/dn594399.aspx. Microsoft hat damals auch das Disklayout umgestellt, wie die Partitionen künftig aufgeteilt werden sollen.

Ganz einfach WLAN-Sicherheitsschlüssel unter Windows auslesen

23 Februar 2015

Ich hab hier früher schon einmal eine Methode beschrieben, wie man WLAN-Netzwerkkennwörter per Commandline auslesen kann: https://newyear2006.wordpress.com/2013/01/02/wifi-netzwerksicherheitsschlssel-unter-windows-per-powershell-auslesen/. Die Variante funktioniert, ist aber entsprechend aufwändig. Was wenn nun von Haus aus eine viel einfachere Methode existiert?

Na dann nutzen wir diese halt:

netsh wlan show profiles

listet zunächst die verfügbaren WLAN-Profile auf. Den Schlüssel dafür bekommt man mittels:

netsh wlan show profiles "Mein WLAN-Netzwerkname" key=clear

Dabei löscht clear nichts, sondern sagt lediglich, dass der Netzwerkschlüssel im Klarnamen angezeigt werden soll.

So sieht der Aufruf konkret z. B. bei einer Fritzbox aus:

netsh wlan show profiles "Fritz!Box 7490" key=clear

Die Sache funktioniert bereits bei Windows 7! Für Windows 8 gibt es sogar eine offizielle Doku: http://windows.microsoft.com/de-at/windows-8/manage-wireless-network-profiles.

Viel Spaß beim Stöbern…

Erweitertes Bootmenü bei Start von Windowsrechnern anzeigen

28 Dezember 2014

Bei neueren Rechnern und optimalen Bios bzw. UEFI-Einstellungen ist es manchmal recht schwer bzw. unmöglich beim Starten des Rechners das erweiterte Bootmenü mittels F8 zu aktivieren.

Wenn der Rechner bereits hochgefahren ist, kann man sich aber behelfen, indem man einen speziellen Parameter mittels BCDEDIT.EXE setzt. Dadurch wird das erweiterte Bootmenü immer angezeigt, bis es wieder explizit abgeschaltet wird:

bcdedit /set {bootmgr} displaybootmenu yes

Zum Ausschalten verwendet man dann später wieder:

bcdedit /set {bootmgr} displaybootmenu no

Nun kann man zwischen den Bootvorgängen in aller Ruhe das passende Auswählen. Hier noch eine bebilderte Anleitung: http://support2.microsoft.com/kb/2809468/en.

Die Variante klappt übrigens auch bei Windows 7. Besonders wertvoll ist es auch bei Verwendung von virtuellen Maschinen, wo man oft noch nicht den passenden Tastaturfokus hat.

Hier die aktuellste Beschreibung von BCDEDIT /set und die möglichen Parameter: http://msdn.microsoft.com/en-us/library/windows/hardware/ff542202(v=vs.85).aspx.

Eine kurze Erklärung zu {bootmgr} erhält man über:

bcdedit /? ID

Hier noch der Link zur offiziellen BCDEDIT-Befehlszeilenreferenz: http://technet.microsoft.com/en-us/library/cc731662.aspx. Leider wie so oft ziemlich unbrauchbar.

Unter Windows 8 und Server 2012 bzw. dessen Nachfolger kann man mittels

bcdedit /set {current} onetimeadvancedoptions on 

das Menü auch nur einmalig für den nächsten Bootvorgang aktivieren.

Fehlende Rechte bei Standardbenutzer zur Konfiguration von Geräte-Manager oder Modemoptionen unter Windows 8

23 Juli 2014

Auf einer aktuellen Windows 8.1 Maschine musste ein Callbridge TAPI Treiber installiert werden. Abgesehen vom ganzen Vorspiel, dass wegen eines Bugs von Microsoft bzw. eine Änderung der TAPI-API bei Windows 8.1 64-Bit, eine komplette neue Telefonanlage nötig war, sollte nur ein TAPI Treiber konfiguriert werden.

Nach der Treiberinstallation wurde unter der Systemsteuerung Modem und Telefonoptionen aufgerufen sowie das Register Erweitert. Hier kann man üblicherweise Konfigurieren anklicken, damit man die betreffenden zusätzlichen Einstellungen vornehmen kann. Leider war dies immer ausgegraut. Denn der angemeldete Benutzer ist nur Standardbenutzer. Ist ja eigentlich kein Problem aber obwohl bei der Konfigurationsschaltfläche das Schild für die höheren Adminrechte angezeigt wurde, wurde nie nach den Adminrechten gefragt. Jeder Klick wurde großzügig ignoriert.

Dies äußert sich auch an viel prominenterer Stelle. Klickt man auf System und dann auf Geräte-Manager, erscheint dies:

—————————
Geräte-Manager
—————————
Sie sind als Standardbenutzer angemeldet. Dies ermöglicht Ihnen zwar das Anzeigen von Geräteinstellungen im Geräte-Manager, zum Vornehmen von Änderungen müssen Sie jedoch als Administrator angemeldet sein.
—————————
OK  
—————————

Dabei war davor am Link auch noch das Zeichen mit dem Schild zu sehen, wo normalerweise nach Adminrechten gefragt wird. Aber das interessiert halt nicht.

Wieder mal typisch MS Chaos. Was tun?

Diese Liste verzeichnet Programme die man direkt aufrufen kann: https://newyear2006.wordpress.com/2008/02/08/direktstartprogramme-unter-windows-vista-und-windows-xp/. Unter anderem gibt es hier telephon.cpl. Genau das wird benötigt aber mit mehr Rechten, also:

C:\>runas /profile /user:pc\admin "cmd.exe /c start telephon.cpl"
Geben Sie das Kennwort für "pc\admin" ein:
Es wird versucht, cmd.exe /c start telephon.cpl als Benutzer "rms\admin" zu starten…

Trommelwirbel: Das wars. Damit war Konfigurieren anklickbar. OK, das war die komplizierte Lösung. Es reicht eigentlich wenn man eine Eingabeaufforderung als Admin aufmacht und dann

start telephon.cpl

oder

devmgmt.msc

für den Gerätemanager aufruft.

Windows 8 Autostart Ordner – ja wo haben sie denn den versteckt?

9 Juli 2014

Da nun mittlerweile absehbar ist, dass es mit dem Startmenü bei Windows 8 nicht so schnell was wird, hier ein Tipp, wie man möglichst schnell zum Autostartordner kommt.

http://blogs.msdn.com/b/jasone/archive/2012/08/19/windows-8-where-did-the-startup-folder-go.aspx beschreibt die Funktion mittels:

shell:startup

nur als alter Commandliner muss man

start shell:startup

aufrufen. Wichtig, wenn man den allgemeinen Autostartordner möchte, funkt es so:

start "" "shell:common startup"

Wenn wir schon bei den kleinen Helferlein sind, mittels

control printers

öffnet sich der “Geräte und Drucker”-Ordner. Und

control update

öffnet die Windows Updates. Braucht man mehr bei der Einrichtung eines Rechners?

Übrigens die Befehle funktionieren auch bei Windows 7. Weitere Kürzel findet man hier: https://newyear2006.wordpress.com/2008/02/08/direktstartprogramme-unter-windows-vista-und-windows-xp/

Windows OEM Key aus BIOS/UEFI bzw. ACPI per Powershell auslesen oder wo kommt der Windowskey für die Aktivierung her?

30 Juni 2014

Letzthin war ich doch etwas geschockt, als es darum ging, einem neuen Rechner Windows 8.1 Update 1 beizubringen. Nicht dass jetzt die Installation unmöglich gewesen wäre aber ein paar Details haben mich etwas stutzig gemacht.

Zunächst muss ich sagen, es handelt sich um einen fertigen ASUS-Tower. Dieser wird mit Windows 7 vorinstalliert ausgeliefert. Da aber Windows 8 drauf sollte und dabei gleich die neueste Fassung mit 8.1 Update 1, wollte ich über die übliche Methode diese Version installieren: https://newyear2006.wordpress.com/2013/09/13/windows-8-1-mit-product-key-von-windows-8-installieren/ indem ich die Installation über einen Microsoft-Demokey vornehmen wollte. Bei der Vorbereitung machte ich mich dann auf die Suche nach dem Windows 8 Key. Aber was soll ich sagen? Es gab keinen! Weder auf dem Tower aufgeklebt noch auf den DVDs oder sonstwo.

OK, es gibt ja die Möglichkeit den Key auf die DVD zu verpacken. Also DVD untersucht und die WIM-Dateien mittels 7zip angeschaut aber nix. Keine Datei mit einem Key. Was geht hier ab?

Ich gebs zu, ich hab dann doch von der Original-DVD Windows 8 installiert. Aber nur um zu sehen, ob später ein Key eingetragen ist. Siehe da, die Installation flutscht durch, ohne nach dem Key zu fragen und führt bei Internetverbindung gleich noch die Aktivierung durch. Das nenn ich ja mal Service! Aber genau diesen Service möchte ich am allerwenigsten.

Die Herausforderung
Jetzt wird es aber interessant. Also auf der DVD ist kein Key zu finden. Aber Windows ist nach der Installation aktiviert. Wie geht das? Wo kommt der Key für die Aktivierung her? Hat es Microsoft etwa eingesehen, dass dieses ganze Zwangsaktivierungsgedöns langfristig deren Untergang ist und aktiviert einfach so? Oder ist die Sache irgendwie an das ASUS-Bios bzw. ASUS UEFI Umgebung gebunden?

Mit der letzten Vermutung kommen wir der Sache näher aber zu meiner Überraschung ganz anders, als ich ursprünglich gedacht hatte. Es hat tatsächlich etwas mit UEFI zu tun aber es wird nicht einfach ein Hersteller ermittelt und dieser freigeschaltet, sondern jeder Rechner bringt seinen eigenen Key im ACPI mit! Dies ist auch keine Besonderheit von ASUS sondern alle Hersteller LENOVO, ACER, DELL usw. alle scheinen diese Variante mittlerweile zu praktizieren!

Die verfügbaren Tools
Hier der erste Artikel bei dem ich über die Sache gestolpert bin: http://www.zdnet.com/will-bios-embedded-windows-8-product-keys-cause-reinstall-troubles-7000008226/. Dieser bestätigte also schon mal, dass es tatsächlich so ist, dass der OEM-Key im BIOS hinterlegt ist. Dann ging es weiter: Wenn der da hinterlegt wird, dann kann man den ja irgendwie auslesen: http://www.nextofwindows.com/how-to-retrieve-windows-8-oem-product-key-from-bios/. Hier kommt neben den üblichen Verdächtigen wie Nirsoft auch RWEverything (http://rweverything.com/download/) zur Sprache, welches ich bisher noch nicht kannte. Der Link bei nextofwindows hat auch ein Python-Script parat. In diesem Script kommen interessante Win32-Funktionen zum Einsatz um den OEM-Key auszulesen! Hier das Script auf Github: https://github.com/christian-korneck/get_win8key#files. Python ist gut aber Powershell wäre besser! http://www.eightforums.com/installation-setup/35444-laptop-encrypted-key-uefi-bios-how-obtain-iso-2.html hat einen Powershellfetzen und spricht mittels WMI den SoftwareLicensingService an, welcher mittels OA3xOriginalProductKey den Key anscheinend auslesen kann. Nur leider klappte dies bei mir nie!

Die Hintergründe
Microsoft hat scheinbar schon lange die Möglichkeit vorgesehen, Daten aus dem BIOS bzw. aus dem Firmwarebereich auszulesen. So gibt es z. B. die Win32-Funktion EnumSystemFirmwareTables bereits seit Windows XP mit 64-Bit und generell seit Windows Vista. Macht auch Sinn, da ja ab Windows Vista durch die Umstellungen der Systemsicherheit vieles abgeschottet und umgebaut wurde. http://msdn.microsoft.com/en-us/library/windows/desktop/ms724259(v=vs.85).aspx. Mittels EnumSystemFirmwareTables und GetSystemFirmwareTable kann man nun die nötigen Daten aus der Firmware auslesen. http://msdn.microsoft.com/en-us/library/windows/desktop/ms724379(v=vs.85).aspx. Diese Funktionen nutzt auch das Pythonskript um den Key auszulesen.

Dazu gibt es auch eine offizielle Beschreibung der Speicherstruktur: http://msdn.microsoft.com/en-us/library/windows/hardware/dn653305(v=vs.85).aspx. Microsoft nennt es Microsoft Software Licensing Tables, welche im ACPI-Bereich unter den Systembeschreibungstabellen zu finden ist. Das Dokument spezifiziert davon zwei, einmal SLIC-Table und einmal MSDM-Table. Obwohl das Tabellenformat identisch ist, ist der Unterschied, dass SLIC für VolumeLicenseKeys und MSDM für individuelle Keys gedacht ist.

Bei Tests hat sich herausgestellt, dass Lenovo wie Asus und wahrscheinlich die meisten Hardwarehersteller MSDM benutzen. Dies zeigen auch die vielen Scripte, die es zum Auslesen gibt, welche sich ausschließlich immer auf MSDM beziehen. Interessant dabei ist natürlich, dass bei der Herstellung der Rechner jeder einzelne mit seinem individuellen Key versehen wird! Okay, früher waren es die individualisierten Keyaufkleber aber durch diese Methode können ja im Prinzip viel mehr Dinge auf dem Rechner aktiviert oder individualisiert werden. Denken wir jetzt an nichts Böses, sondern einfach mal an die bei der Bestellung hochgeladene, individuelle Startgrafik.

Powershell Fassung
Auf der weiteren Suche nach einer Fassung in Powershell, bin ich über diese Variante gestolpert: http://winaero.com/blog/how-to-get-the-windows-product-key-without-using-third-party-software/. Auf den ersten Blick genau was ich wollte aber leider wird nur wieder der Key aus der Registrierung ausgelesen, wie man es früher gemacht hat.

Diese Variante war auch ganz hilfreich und enthält noch mehr Infos zu verschiedenen Gegebenheiten und verschiedene Sourcecodes und Scripte: http://forums.mydigitallife.info/threads/43788-C-C-VB-NET-Read-MSDM-license-information-from-BIOS-ACPI-tables/page3.

Aber am Ende war keine Powershellfassung dabei. Also selber machen! Warum eigentlich Powershell? Ja warum? Weil Powershell wird solange da sein, wie sich Microsoft über Wasser halten kann und es ist bei jedem neuen Rechner von Haus aus mit an Bord! Sogar Windows RT bringt es mit. In der reinen Lehre gibt es also nichts anderes.

Also hier der Code:

$SFTCode = @"

 

[DllImport("kernel32")] public static extern uint EnumSystemFirmwareTables (uint FirmwareTableProviderSignature, IntPtr pFirmwareTableBuffer, uint BufferSize);

[DllImport("kernel32")] public static extern uint GetSystemFirmwareTable   (uint FirmwareTableProviderSignature, uint FimrwareTableID, IntPtr pFirmwareTableBuffer, uint BufferSize);

 

"@

 

$SFT = Add-Type -MemberDefinition $SFTCode -Name "SFTKlasse" -Language CSharp -UsingNamespace "System.Reflection", "System.Diagnostics", "System.Collections.Generic" -PassThru

 

# 0x41435049=ACPI ? https://github.com/michaelforney/coreboot/blob/master/src/include/cbmem.h

$firmwareTableProviderSignature = 0x41435049

$StructSize = $SFT::EnumSystemFirmwareTables($firmwareTableProviderSignature, [IntPtr]::Zero, 0)

try

{

    $StructPtr = [Runtime.InteropServices.Marshal]::AllocHGlobal($StructSize)

}

catch [OutOfMemoryException]

{

    throw Error[0]

}

 

$buffer = New-Object Byte[]($StructSize)

$SFT::EnumSystemFirmwareTables($firmwareTableProviderSignature, $StructPtr, $StructSize)

[Runtime.InteropServices.Marshal]::Copy($StructPtr, $buffer, 0, $StructSize)

[Runtime.InteropServices.Marshal]::FreeHGlobal($StructPtr)

 

if (([System.Text.Encoding]::ASCII).GetString($buffer).Contains("MSDM"))

{

    $firmwareTableMSDMID = 0x4d44534d

 

    $StructSize = $SFT::GetSystemFirmwareTable($firmwareTableProviderSignature, $firmwareTableMSDMID, [IntPtr]::Zero, 0)

    try

    {

        $StructPtr = [Runtime.InteropServices.Marshal]::AllocHGlobal($StructSize)

    }

    catch [OutOfMemoryException]

    {

        throw Error[0]

    }

 

    $buffer = New-Object Byte[]($StructSize)

    $SFT::GetSystemFirmwareTable($firmwareTableProviderSignature, $firmwareTableMSDMID, $StructPtr, $StructSize)

    [Runtime.InteropServices.Marshal]::Copy($StructPtr, $buffer, 0, $StructSize)

    [Runtime.InteropServices.Marshal]::FreeHGlobal($StructPtr)

 

    $encoding = [System.Text.Encoding]::GetEncoding(0x4e4)

 

    $key = $encoding.GetString($buffer, 56, 29)

}

$key

Wie immer gilt, von der Formatierung nicht abschrecken lassen, sondern einfach Copy&Paste und loslegen. Übrigens es werden keine Admin-Rechte benötigt! Da einiges durcheinander geht, hier noch der Gist-Verweis: https://gist.github.com/newyear2006/5578386bf4793a334f85#file-getacpi-oemkey-ps1

Würde mich freuen, wenn der eine oder andere seine Erfahrungen im Kommentarbereich verewigen könnte, um ein Gefühl dafür zu bekommen, welche Hersteller die Variante unterstützen.

Zusätzlich interessiert mich besonders:

PS > ([System.Text.Encoding]::ASCII).GetString($buffer)

Dies gibt einen String aus, mit den auf dem Rechner verfügbaren Firmwaretabellen.

Noch ein Hinweis:
Falls es nach dem Copy&Paste zu einem Fehler wie diesem hier kommt:

0×41435049 : Die Benennung "0×41435049" wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt. Überprüfen

Sie die Schreibweise des Namens, oder ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.

In Zeile:12 Zeichen:35

+ $firmwareTableProviderSignature = 0×41435049

+ ~~~~~~~~~~

+ CategoryInfo : ObjectNotFound: (0×41435049:String) [], CommandNotFoundException

+ FullyQualifiedErrorId : CommandNotFoundException

dann bitte das x bei 0x41434049 löschen und nochmal eingeben. Scheint eine nette Anomalie von WordPress zu sein.


Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.