Probleme mit Internetverbindung mit mehreren Netzwerkkarten und falschen Prioritäten, Ping meldet: “Die Gültigkeitsdauer wurde bei der Übertragung überschritten.” bzw. “Time to live exceeded”– kurz, wenn sich alles im Kreis dreht

Ausgangslage war eine Hyper-V-Installation auf Basis von Windows 10. Hyper-V richtet einen “Default Switch” ein. Dieser virtuelle Switch wurde schon mehrfach ohne Probleme für verschiedene VMs benutzt. Nun wurde ein neuer Hyper-V-Switch für ein Testnetz eingerichtet. Im Testnetz kamen nur zwei VMs zum Einsatz. VM1 war OpnSense mit Version 23.7. VM2 war Windows Server 2022. Die VM1 hatte zwei Netzwerkkarten zugeordnet einmal als WAN und einmal als LAN. Die VM2 hatte nur eine Netzwerkkarte die an LAN von VM1 verbunden war. Waren beide VMs aus konnte mit dem Hostsystem problemlos im Internet gesurft werden. Waren beide VMs gestartet war  nach kurzer Zeit der Zugang ins Internet auf dem Hostsystem nicht mehr gegeben. Ebenso war auf den VMs nur ganz kurz eine Verbindung ins Internet möglich.

Beim Versuch eine Internetseite aufzurufen kam von Edge diese Meldung:

Hmmm…diese Seite ist leider nicht erreichbar

Die IP-Adresse des Servers von github.com konnte nicht gefunden werden.

Versuchen Sie Folgendes:

• Proxy-, Firewall- und DNS-Einstellungen überprüfen.
• Windows-Netzwerkdiagnose ausführen

DNS_PROBE_FINISHED_BAD_CONFIG

Also irgendein Problem mit dem DNS.

Ein einfacher Test mit einem Ping brachte dieser Fehlermeldung, dabei ist 172.17.224.1 die IP-Adresse welche dem “Default Switch” auf dem Host-System zugewiesen war:

PS C:\Users\Administrator> ping 8.8.8.8

Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Antwort von 172.17.224.1: Die Gültigkeitsdauer wurde bei der Übertragung überschritten.
Antwort von 172.17.224.1: Die Gültigkeitsdauer wurde bei der Übertragung überschritten.
Antwort von 172.17.224.1: Die Gültigkeitsdauer wurde bei der Übertragung überschritten.
Antwort von 172.17.224.1: Die Gültigkeitsdauer wurde bei der Übertragung überschritten.

Auch ein hochschrauben des Timeouts mittels

PS C:\Users\Administrator> ping 8.8.8.8 -i 60

brachte keine Änderung. Nun der Versuch mittels nslookup eine Antwort zu bekommen:

PS C:\Users\Administrator> nslookup
Standardserver:  OPNsense.localdomain
Address:  192.168.1.1

> google.de
Server:  OPNsense.localdomain
Address:  192.168.1.1

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an OPNsense.localdomain.

Obwohl der Ping an 8.8.8.8 schon nicht funktionierte wurde trotzdem mal ein tracert abgesetzt, was zu diesem interessanten Ergebnis führte:

PS C:\Users\Administrator> tracert 8.8.8.8

Routenverfolgung zu 8.8.8.8 über maximal 30 Hops

  1    <1 ms    <1 ms    <1 ms  OPNsense.localdomain [192.168.1.1]
  2     5 ms     6 ms     3 ms  172.17.224.1
  3     1 ms     1 ms     1 ms  OPNsense.localdomain [192.168.1.1]
  4     2 ms     1 ms     1 ms  172.17.224.1
  5     2 ms     1 ms     1 ms  OPNsense.localdomain [192.168.1.1]
  6     2 ms     7 ms     2 ms  172.17.224.1
  7     2 ms     2 ms     2 ms  OPNsense.localdomain [192.168.1.1]
  8     3 ms     2 ms     2 ms  172.17.224.1
  9     3 ms     2 ms     2 ms  OPNsense.localdomain [192.168.1.1]
10     3 ms     3 ms     3 ms  172.17.224.1
11     4 ms     3 ms     2 ms  OPNsense.localdomain [192.168.1.1]
12     4 ms     2 ms     3 ms  172.17.224.1
13     4 ms     3 ms     3 ms  OPNsense.localdomain [192.168.1.1]

D.h. die Verbindung dreht sich im Kreis!

Nach einigen Neustarts und überprüfen der Netzwerkeinstellungen wurde am Host-System geschaut, ob da alles klappt. Und siehe da, es war auch kein Aufruf mehr von Internetseiten möglich. Das auffällige am Host-System war die DNS-Suffixreihenfolge:

C:\Users\Administrator>ipconfig /all

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : HyperVHost
   Primäres DNS-Suffix . . . . . . . :
   Knotentyp . . . . . . . . . . . . : Hybrid
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein
   DNS-Suffixsuchliste . . . . . . . : localdomain
                                       fritz.box

Ethernet-Adapter vEthernet (Default Switch):

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #2
   Physische Adresse . . . . . . . . : 00-15-5D-96-A6-6B
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::b711:9aff:aa98:4d94%32(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 172.17.224.1(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.240.0
   Standardgateway . . . . . . . . . :
   DHCPv6-IAID . . . . . . . . . . . : 536876381
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-18-49-78-BD-C8-60-00-8E-47-11
   DNS-Server  . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter vEthernet (OpnSenseNetzwerk):

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #3
   Physische Adresse . . . . . . . . : 00-15-5D-8E-A2-5C
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::ad:802c:9657:2eaf%13(Bevorzugt)
   IPv4-Adresse (Auto. Konfiguration): 169.254.252.98(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.0.0
   Standardgateway . . . . . . . . . :
   DHCPv6-IAID . . . . . . . . . . . : 805311837
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-18-49-78-BD-C8-60-00-8E-47-11
   DNS-Server  . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter vEthernet (KundeTestNetz):

   Verbindungsspezifisches DNS-Suffix: localdomain
   Beschreibung. . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #4
   Physische Adresse . . . . . . . . : 00-15-5D-8E-A2-74
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::fb91:31ae:c923:8c31%22(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.1.102(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Samstag, 2. September 2023 11:19:47
   Lease läuft ab. . . . . . . . . . : Montag, 4. September 2023 02:19:48
   Standardgateway . . . . . . . . . : 192.168.1.1
   DHCP-Server . . . . . . . . . . . : 192.168.1.1
   DHCPv6-IAID . . . . . . . . . . . : 620762461
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-18-49-78-BD-C8-60-00-8E-47-11
   DNS-Server  . . . . . . . . . . . : 192.168.1.1
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter vEthernet (Controller der Familie Realtek PCIe GBE Virtual Switch):

   Verbindungsspezifisches DNS-Suffix: fritz.box
   Beschreibung. . . . . . . . . . . : Hyper-V-Adapter – virtuelles Ethernet #2
   Physische Adresse . . . . . . . . : C8-60-00-8E-47-11
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::4f87:2147:db21:39c5%23(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.20.56(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Samstag, 2. September 2023 04:33:58
   Lease läuft ab. . . . . . . . . . : Donnerstag, 14. September 2023 00:21:54
   Standardgateway . . . . . . . . . : 192.168.20.2
   DHCP-Server . . . . . . . . . . . : 192.168.20.2
   DHCPv6-IAID . . . . . . . . . . . : 331898880
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-18-49-78-BD-C8-60-00-8E-47-11
   DNS-Server  . . . . . . . . . . . : 192.168.20.2
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Fritz.box war vom lokalen Netz und localdomain war von der VM-OpnSense-Maschine. Warum hat diese eine höhere Priorität wie das lokale Netz?!?!?

Zuerst dachte ich das Problem über direkte Manipulation der DNS-Suchreihenfolge wie hier beschrieben https://learn.microsoft.com/de-de/troubleshoot/windows-client/networking/configure-domain-suffix-search-list-domain-name-system-clients zu lösen. Allerdings, nachdem es sich um keine einfache Lösung sondern um eine Registry-Manipulation handelte, wurde nach einer anderen Lösung gesucht.

Früher ließ sich so ein Problem bei den Netzwerkverbindungen mittels des versteckten Menüs Erweitert (vorher ALT-Taste einmal drücken) und dann Auswahl von “Erweiterte Einstellungen” lösen. Dort gab es das Register “Adapter und Bindungen”:

 

Doch unter Windows 10 gibt es nun nur noch das Register Anbieterreihenfolge (Provider Order):

Mal wieder eine tolle Sache. Wer kommt auf die Idee hier Menüs verschwinden zu lassen? Dieser Artikel brachte dann die Lösung https://learn.microsoft.com/de-de/windows-server/networking/technologies/network-subsystem/net-sub-interface-metric. Es gibt ein Powershell Kommando um die Schnittstellenmetrik definieren zu können, es nennt sich Set-NetIPInterface. https://learn.microsoft.com/en-us/powershell/module/nettcpip/set-netipinterface?view=windowsserver2022-ps.

So sah die Sache auf dem Host aus:

PS C:\WINDOWS\system32> Get-NetIPInterface -AddressFamily IPv4|select interfacemetric, interfacealias

interfacemetric interfacealias
————— ————–
             15 vEthernet (KundeTestNetz)
             15 vEthernet (OpnSenseNetzwerk)
             25 vEthernet (Controller…ek PCIe GBE Virtual Switch)
             15 vEthernet (Default Switch)
             75 Loopback Pseudo-Interface 1

D. h. die Netzwerkkarte im Host-System hatte eine niedrigere Priorität als der “Default Switch”. Die Metric-Wert war auf 25 und die virtuellen Switche hatten 15. Es konnte also nie ein Paket nach außen gelangen.

Nachdem dann mittels

Set-NetIPInterface -InterfaceIndex 23 -InterfaceMetric 5

der Metric-Wert geändert wurde, wie hier zu sehen:

PS C:\WINDOWS\system32> Get-NetIPInterface -AddressFamily IPv4|select interfacemetric, interfacealias

interfacemetric interfacealias
————— ————–
             15 vEthernet (KundeTestNetz)
             15 vEthernet (OpnSenseNetzwerk)
              5 vEthernet (Controller…ek PCIe GBE Virtual Switch)
             15 vEthernet (Default Switch)
             75 Loopback Pseudo-Interface 1

waren auf einmal alle Probleme behoben! Nachdem nun alles richtig gestellt war, war auch die Darstellung von ipconfig /all wieder in Ordnung:

C:\Users\Administrator>ipconfig /all

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : HyperVHost
   Primäres DNS-Suffix . . . . . . . :
   Knotentyp . . . . . . . . . . . . : Hybrid
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein
   DNS-Suffixsuchliste . . . . . . . : fritz.box
                                       localdomain

Ethernet-Adapter vEthernet (Controller der Familie Realtek PCIe GBE Virtual Switch):

   Verbindungsspezifisches DNS-Suffix: fritz.box
   Beschreibung. . . . . . . . . . . : Hyper-V-Adapter – virtuelles Ethernet #2
   Physische Adresse . . . . . . . . : C8-60-00-8E-47-11
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::4f87:2147:db21:39c5%23(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.20.56(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Samstag, 2. September 2023 04:33:58
   Lease läuft ab. . . . . . . . . . : Donnerstag, 14. September 2023 00:21:54
   Standardgateway . . . . . . . . . : 192.168.20.2
   DHCP-Server . . . . . . . . . . . : 192.168.20.2
   DHCPv6-IAID . . . . . . . . . . . : 331898880
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-18-49-78-BD-C8-60-00-8E-47-11
   DNS-Server  . . . . . . . . . . . : 192.168.20.2
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter vEthernet (Default Switch):

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #2
   Physische Adresse . . . . . . . . : 00-15-5D-96-A6-6B
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::b711:9aff:aa98:4d94%32(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 172.17.224.1(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.240.0
   Standardgateway . . . . . . . . . :
   DHCPv6-IAID . . . . . . . . . . . : 536876381
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-18-49-78-BD-C8-60-00-8E-47-11
   DNS-Server  . . . . . . . . . . . : 192.168.20.2
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter vEthernet (OpnSenseNetzwerk):

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #3
   Physische Adresse . . . . . . . . : 00-15-5D-8E-A2-5C
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::ad:802c:9657:2eaf%13(Bevorzugt)
   IPv4-Adresse (Auto. Konfiguration): 169.254.252.98(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.0.0
   Standardgateway . . . . . . . . . :
   DHCPv6-IAID . . . . . . . . . . . : 805311837
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-18-49-78-BD-C8-60-00-8E-47-11
   DNS-Server  . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter vEthernet (KundeTestNetz):

   Verbindungsspezifisches DNS-Suffix: localdomain
   Beschreibung. . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #4
   Physische Adresse . . . . . . . . : 00-15-5D-8E-A2-74
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::fb91:31ae:c923:8c31%22(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.1.102(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Samstag, 2. September 2023 11:19:48
   Lease läuft ab. . . . . . . . . . : Montag, 4. September 2023 15:19:49
   Standardgateway . . . . . . . . . : 192.168.1.1
   DHCP-Server . . . . . . . . . . . : 192.168.1.1
   DHCPv6-IAID . . . . . . . . . . . : 620762461
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-18-49-78-BD-C8-60-00-8E-47-11
   DNS-Server  . . . . . . . . . . . : 192.168.1.1
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Der Vollständigkeithalber sind hier noch die Reaktionen eines Debian 12 Linux dokumentiert, wenn obiges Problem vorhanden ist.

Zunächst der Ping:

user@debian:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 172.17.224.1 icmp_seq=1 Time to live exceeded
From 172.17.224.1 icmp_seq=2 Time to live exceeded
From 172.17.224.1 icmp_seq=3 Time to live exceeded
From 172.17.224.1 icmp_seq=4 Time to live exceeded
^C
— 8.8.8.8 ping statistics —
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3004ms

Dann dig die nslookup-Variante von Linux:

user@debian:~$ dig google.de
;; communications error to 192.168.1.1#53: timed out
;; communications error to 192.168.1.1#53: timed out
;; communications error to 192.168.1.1#53: timed out

; <<>> DiG 9.18.16-1~deb12u1-Debian <<>> google.de
;; global options: +cmd
;; no servers could be reached

und noch zum Abschluss die Reaktion bei traceroute:

user@debian:~$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1  OPNsense.localdomain (192.168.1.1)  1.356 ms  1.333 ms  1.318 ms
2  172.17.224.1 (172.17.224.1)  1.791 ms  1.776 ms  1.762 ms
3  OPNsense.localdomain (192.168.1.1)  3.665 ms  3.650 ms  3.636 ms
4  172.17.224.1 (172.17.224.1)  4.003 ms  3.989 ms  3.976 ms
5  OPNsense.localdomain (192.168.1.1)  4.206 ms  4.192 ms  4.178 ms
6  172.17.224.1 (172.17.224.1)  4.604 ms  3.034 ms  3.013 ms
7  OPNsense.localdomain (192.168.1.1)  3.135 ms  6.627 ms  6.607 ms
8  172.17.224.1 (172.17.224.1)  7.442 ms  7.427 ms  7.412 ms
9  OPNsense.localdomain (192.168.1.1)  8.946 ms  7.167 ms  7.150 ms
10  172.17.224.1 (172.17.224.1)  7.566 ms  7.553 ms  7.540 ms
11  OPNsense.localdomain (192.168.1.1)  8.883 ms  8.870 ms  8.859 ms
12  172.17.224.1 (172.17.224.1)  9.025 ms  9.013 ms  9.498 ms
13  OPNsense.localdomain (192.168.1.1)  11.299 ms  11.466 ms  11.447 ms
14  172.17.224.1 (172.17.224.1)  11.797 ms  11.774 ms  9.114 ms
15  OPNsense.localdomain (192.168.1.1)  9.677 ms  10.444 ms  10.428 ms
16  172.17.224.1 (172.17.224.1)  11.654 ms  12.299 ms  12.277 ms
17  OPNsense.localdomain (192.168.1.1)  13.547 ms  13.534 ms  13.396 ms
18  172.17.224.1 (172.17.224.1)  13.081 ms  13.063 ms  13.050 ms
19  OPNsense.localdomain (192.168.1.1)  14.555 ms  14.542 ms  14.530 ms
20  172.17.224.1 (172.17.224.1)  12.825 ms  12.802 ms  12.754 ms
21  OPNsense.localdomain (192.168.1.1)  12.848 ms  12.830 ms  12.716 ms
22  172.17.224.1 (172.17.224.1)  13.123 ms  12.464 ms  12.447 ms
23  OPNsense.localdomain (192.168.1.1)  13.101 ms  15.354 ms  15.335 ms
24  172.17.224.1 (172.17.224.1)  15.706 ms  17.928 ms  18.225 ms
25  OPNsense.localdomain (192.168.1.1)  18.211 ms  18.198 ms  18.186 ms
26  172.17.224.1 (172.17.224.1)  20.433 ms  20.424 ms  20.407 ms
27  OPNsense.localdomain (192.168.1.1)  20.586 ms  20.570 ms  19.709 ms
28  172.17.224.1 (172.17.224.1)  19.961 ms  19.948 ms  17.236 ms
29  OPNsense.localdomain (192.168.1.1)  17.514 ms  15.482 ms  14.287 ms
30  172.17.224.1 (172.17.224.1)  12.110 ms  12.086 ms  12.070 ms

In früheren Zeiten verwendete man anstatt Set-NetIPInterface “route CHANGE” unter Windows. Die aktuellen Einstellungen Einstellungen unter Linux gibts mittels “ip route list” und Änderungen nimmt man mittels “ip route change” vor.

Nachdem nun klar war, wo das Problem lag, findet man natürlich auch Blog-Artikel die sich in ähnlicher Form dem Problem annehmen, wie hier z.B.: https://blog.pauby.com/post/hyper-v-default-switch-issues/.

Tar.exe unter Windows 10 der neue Tausendsassa

Mit Windows 10 v1803 wurde ein neues Utility-Programm von Microsoft ins Windows-System mitaufgenommen. Es handelt sich um TAR.EXE. Tar ist unter Linux im Dauereinsatz aber auch bei Mac OS X verfügbar. Bei Windows handelt es sich um ein reines 32- bzw. 64-Bit Windows Anwendungsprogramm und ist unter 32- und 64-Bit Windowsversionen vorhanden. Obwohl die EXE tar genannt wird, handelt es sich eigentlich um BSDTar, welches primär auch beim Mac zum Einsatz kommt. Die Besonderheit von BSDTar ist, dass es auf libarchive aufsetzt, d. h. viele Features werden durch libarchive definiert. Tar.EXE ist bereits bei einer einfachen Grundinstallation sofort verfügbar. Es hat auch nichts mit dem Windows Linux Subsystem zu tun, welches ihre eigenen tar-Programme mitbringen. tar ist bei Servern ab Windows Server 2019, auch beim Hyper-V Server. Leider fehlt die Unterstützung in WinPE. Hier die offizielle Ankündigung von Microsoft tar unterstützen zu wollen: https://blogs.technet.microsoft.com/virtualization/2017/12/19/tar-and-curl-come-to-windows/.

Um zu wissen was alles mit Tar möglich ist, gilt es zuerst die Version herauszufinden, dazu ruft man

tar –version

auf, welches

bsdtar 3.3.2 – libarchive 3.3.2 zlib/1.2.5.f-ipp

liefert. Hiermit wird obige Aussage bei tar handelt es sich um bsdtar verdeutlicht. Auch wird damit libarchive klar. Um nun die Möglichkeiten und den Versionstand besser verstehen zu können, kann man hier nachschauen: http://www.libarchive.org/. Zum aktuellen Zeitpunkt gibt es die Version 3.3.3, also ist Microsoft recht nahe am Original. Übrigens hat Windows 10 v1809 keine neuere Version mitgebracht, stellt sich die Frage, ob Microsoft zukünftig die Version aktualisieren wird oder ob die Version auf ewig bei 3.3.2 verharren wird. Der Source Code zur Version 3.3.2 ist hier zu finden: https://github.com/libarchive/libarchive/tree/v3.3.2.

Was kann man nun mittels tar unter Windows tun? Jede Menge, nicht umsonst die Überschrift. tar kann ZIP-Dateien erstellen, sogar ZIP64-Dateien, also ZIP-Dateien größer als 4GB, dadurch kann man komplette Platten mittels tar sichern. tar kann auch die Dateien mit AES-128 oder AES-256 verschlüsseln, somit kann man Sicherungen erstellen, verschlüsseln und bedenkenlos in die Cloud schieben. tar kann auch mit ISO-Dateien umgehen und diese sogar erstellen. tar kann aber nicht nur mit normalen und großen ZIP-Dateien umgehen, sondern unterstützt auch 7-Zip-Dateien. Daneben noch viele andere Formate mehr. Es soll auch mit CAB-Dateien umgehen können, aber meine Versuche hiermit sind alle gescheitert.

Nun ein paar Anwendungsbeispiele.

Erzeugt eine Test.ISO-Datei mit den beiden Dateien Datei1.txt und Datei2.txt:

tar -cf test.iso –format=iso9660 datei1.txt datei2.txt

Erzeugt eine Test.ZIP-Datei mit den beiden Dateien Datei1.txt und Datei2.txt, wobei die Test.ZIP-Datei zusätzlich AES-256 verschlüsselt und mit dem Passwort password versehen wird:

tar -cf test.zip –format=zip –options=encryption=aes256 –passphrase=password datei1.txt datei2.txt

Wie oben beschrieben darf die resultierende ZIP-Datei auch größer als 4GB haben, unterstützt also ZIP64.

Dieses Beispiel listet den Inhalt einer ISO-Datei auf:

tar -tvf test.iso

Die gleiche Variante stellt auch den Inhalt von ZIP-Dateien dar. tar versucht dabei unabhängig von der Endung das passende Format zu erkennen. Ein angeben des Formats mittels –format=zip ist nicht erlaubt und wird mittels Fehler quittiert.

Natürlich kann man Dateien auch extrahieren:

tar -xvf test.zip

entpackt alle in Test.ZIP enthaltenen Dateien.

So toll tar unter Windows auch ist, hab ich leider noch keinen Parameter finden können, über den ein Fortschrittsbalken oder Hinweis ausgegeben werden kann. Gerade bei größeren Dateien wäre dies absolut hilfreich. Auch ist der Einsatz von Filtern per Kommandozeile nicht so klar. Ein weiteres Problem sind Dateien die gesichert werden sollen, die gerade in Benutzung sind, hier bricht tar einfach mit einer Fehlermeldung ab. Leider fehlt die Unterstützung für –ignore-read-error.

Aber ist vielleicht alles nur eine Frage der Zeit…

Positiv festzuhalten gilt vor allem, tar löst nun das Problem, dass man seither mittels ZIP64 gepackte oder mittels AES-verschlüsselte Dateien nicht ohne Bordmittel öffnen bzw. erstellen konnte. Zumindest für Kommandliner geht dies nun.

Spectre und Meltdown schönes Powershell-Script welches auch den Zugriff und vor allem die Mächtigkeit von NtQuerySystemInformation verdeutlicht

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…

Was hat es mit FLTMC.EXE auf sich?

Mit FLTMC.EXE kann man unter Windows Filtertreiber für Dateisysteme managen. Was sind nun Filtertreiber? Filtertreiber sind Kerneltreiber, welche zwischen anderen Treibern eingeschoben werden können, um bestimmte zusätzliche Funktionen realisieren zu können. Als da wären der Virenscanner, Dateikontingente usw.

Ruft man bei einem Windows 10 (v1703) FLTMC.EXE auf so erhält man z. B. als Ausgabe:

Filtername       Anzahl von Instanzen    Höhe    Frame
—————  ——————–    —-    —–
WdFilter                      6       328010         0
storqosflt                    0       244000         0
wcifs                         1       189900         0
FileCrypt                     0       141100         0
luafv                         1       135000         0
npsvctrig                     1        46000         0
Wof                           4        40700         0
FileInfo                      6        40500         0

Damit weiß man schon mal welche Filtertreiber bekannt sind und welche durch laufende Instanzen aktiv sind. Aber welche ist nun für was zuständig?

Um dies rauszufinden hilft ein kleiner Powershell-Aufruf:

fltmc|Out-String -Stream|select -skip 3|% {($_ -split ‚ ‚)[0]}|% {Get-ChildItem "C:\windows\system32\drivers\$_.sys"}| select name, @{n="Description";e={$_.VersionInfo.FileDescription}}

Name           Description
—-           ———–
WdFilter.sys   Microsoft antimalware file system filter driver
storqosflt.sys QoS-Filter für Speicher
wcifs.sys      Windows Container Isolation FS Filter Driver
FileCrypt.sys  Windows sandboxing and encryption filter
luafv.sys      LUA-Filtertreiber zur Dateivirtualisierung
npsvctrig.sys  Named pipe service triggers
Wof.sys        Windows-Überlappungsfilter
FileInfo.sys   FileInfo Filter Driver

Filtertreiber die nicht gestartet sind, tauchen in der Liste nicht auf. So taucht ein weiterer Treiber auf, wenn z. B. die OneDrive-Unterstützung mittels des cldflt-Dienst gestartet wird, indem man Start-Service cldFlt aufruft:

Name           Description
—-           ———–
WdFilter.sys   Microsoft antimalware file system filter driver
storqosflt.sys QoS-Filter für Speicher
wcifs.sys      Windows Container Isolation FS Filter Driver
CldFlt.Sys    Cloud Files Mini Filter Driver
FileCrypt.sys  Windows sandboxing and encryption filter
luafv.sys      LUA-Filtertreiber zur Dateivirtualisierung
npsvctrig.sys  Named pipe service triggers
Wof.sys        Windows-Überlappungsfilter
FileInfo.sys   FileInfo Filter Driver

Ähnlich verhält es sich, wenn man z. B. Kaspersky Interent Security installiert, dann verschwindet auf einmal der WdFilter.sys von Microsoft und es taucht KLIF.sys auf:

Name           Description
—-           ———–
KLIF.sys      Core System Interceptors [fre_win8_x64]
storqosflt.sys QoS-Filter für Speicher
wcifs.sys      Windows Container Isolation FS Filter Driver
CldFlt.Sys    Cloud Files Mini Filter Driver
FileCrypt.sys  Windows sandboxing and encryption filter
luafv.sys      LUA-Filtertreiber zur Dateivirtualisierung
npsvctrig.sys  Named pipe service triggers
Wof.sys        Windows-Überlappungsfilter
FileInfo.sys   FileInfo Filter Driver

Die Treiber hängen alle vom Filtermanager-Dienst ab. Wenn man den zugehörigen Dienst abfragt, findet man noch weitere Infos, vor allem abhängige Treiber die nicht mittels FLTMC.EXE bearbeitet werden können:

(get-service fltmgr).DependentServices|where status -eq running

Name       DisplayName
—-       ———–
vmcompute  Hyper-V-Hostserverdienst
Wof        Windows Overlay File System Filter Driver
FileInfo   File Information FS MiniFilter
WdFilter   Windows Defender Antivirus-Minifiltertreiber
wcifs      Windows Container Isolation
storqosflt QoS-Filter für Speicher – Treiber
luafv      UAC-Dateivirtualisierung
SysMain    Superfetch
FileCrypt  FileCrypt

Man sieht, dass die Namen sich mit den FLTMC-Namen deckt aber die Bezeichnungen der Dienste von den Dateibeschreibungen vereinzelt abweicht.

Detaillierte Infos zu den einzelnen Diensten findet man hier: https://notesfromthedatacenter.wordpress.com/tag/fltmc/

Schaut man sich die Ausgabe von FLTMC.EXE an, dann gibt es noch die Spalte Höhe bzw. Altitude, dahinter verbirgt sich eine Nummer. Dabei sind dies keine willkürlichen Nummern, sondern es gibt gewisse Nummernblöcke. D. h. jeder Treiber ist einem bestimmten Block zugeordnet:

Block	Beschreibung
420000 – 429999	Filter
400000 – 409999	FSFilter Top
360000 – 389999	FSFilter Activity Monitor
340000 – 349999	FSFilter Undelete
320000 – 329998	FSFilter Anti-Virus
300000 – 309998	FSFilter Replication
280000 – 289998	FSFilter Continuous Backup
260000 – 269998	FSFilter Content Screener
240000 – 249999	FSFilter Quota Management
220000 – 229999	FSFilter System Recovery
200000 – 209999	FSFilter Cluster File System
180000 – 189999	FSFilter HSM
170000 – 174999	*FSFilter Imaging (ex: .ZIP)
160000 – 169999	FSFilter Compression
140000 – 149999	FSFilter Encryption
130000 – 139999	FSFilter Virtualization
120000 – 129999	FSFilter Physical Quota Management
100000 – 109999	FSFilter Filter Open File
80000 – 89999	FSFilter Security Enhancer
60000 – 69999	FSFilter Copy Protection
40000 – 49999	FSFilter Bottom
20000 – 29999	FSFilter System

Quelle: https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/allocated-altitudes. Welche Bedeutung die jeweiligen Blöcke haben, findet man hier: https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/load-order-groups-and-altitudes-for-minifilter-drivers.

Feststellen welches Programm das Entfernen eines USB-Gerätes unter Windows verhindert

Wenn man unter Windows USB Geräte abmeldet bzw. auswirft, kann es passieren, dass man mit dieser schönen Meldung beglückt wird:

—————————
Fehler beim Abdocken von "USB-Massenspeichergerät"
—————————
Das Gerät "USB-Massenspeichergerät" kann aufgrund eines unbekannten Fehlers nicht beendet werden. Entfernen Sie das Gerät nicht, solange es noch verwendet wird. Schließen Sie alle Programme, von denen das Gerät verwendet wird, und entfernen Sie es anschließend.
—————————
OK  
—————————

Unter Windows 7 sieht die Meldung etwas anders aus, ist aber genauso sinnlos:

—————————
Fehler beim Abdocken von "USB-Massenspeichergerät"
—————————
Dieses Gerät wird gerade verwendet. Schließen Sie alle Programme oder Fenster, die möglicherweise das Gerät verwenden, und wiederholen Sie den Vorgang.
—————————
OK  
—————————

Tja, “Unbekannte Fehler” sind des Benutzers liebste Fehler! Selbst heute in Zeiten von Windows 10 hat es Microsoft noch nicht geschafft diese Meldung mit mehr sinnvollen Informationen zu versehen und kommt immer noch so kryptisch wie zu Windows XP-Zeiten daher.

Aber dank Powershell kann der gequälte Anwender sich etwas mehr Informationen beschaffen. Zumindest bei Windows 7 bis Windows 10.

Get-WinEvent -ProviderName Microsoft-Windows-Kernel-PnP -MaxEvents 5 | where {$_.TimeCreated.Date -eq (Get-Date).Date -and $_.id -eq 225} | ft TimeCreated, Message –Wrap

Denn es werden in der Ereignisanzeige in Windows tiefergehende Informationen zum Vorgang gespeichert und damit kann man in der Regel den Grund für obige Fehlermeldung herausfinden. Man muss nur beim Microsoft-Windows-Kernel-PNP Provider nach der EventID 225 suchen.

In diesem Fall bekommt man z. B.:

TimeCreated         Message
———–         ——-
30.08.2017 17:33:47 Die Anwendung \Device\HarddiskVolume4\Windows\System32\cmd.exe mit der Prozess-ID                     21832 hat das Entfernen oder Auswerfen für das Gerät                     USB\VID_1E68&PID_0035\BB00000XXXXXXX beendet.

angezeigt. D. h. cmd.exe, also die Eingabeaufforderung, mit der ProzessID 21832 hatte Zugriff auf den USB-Stick und verhinderte dadurch das Auswerfen.

Systemrechte unter Windows erlangen

Schon seit Ewigkeiten ist bekannt wie man Systemrechte unter Windows erlangen kann. Aber das Ziel ist es – wie immer – es mit möglichst wenig Aufwand und am besten mit Bordmitteln zu erlangen. Zwar bringt jedes aktuelle Windows mittlerweile ein Recoverypartition mit aber man hat nicht immer unbedingt Zugriff im Bootvorgang darauf (z. B. bei gehosteten Webservern).

Der übliche Vorgang ist das Kopieren von CMD.EXE auf UTILMAN.EXE, OSK.EXE oder SETHC.EXE. Dies gelingt normalerweise nur, wenn man von einer Recoverypartition oder von WinPE bzw. eben WinRE-CD gebootet hat. Aus diesem Grund verwenden viele Sysinternals PSExec: https://docs.microsoft.com/en-us/sysinternals/downloads/psexec.

Mit Adminrechten und etwas Gefummel in der Registry, bekommt man es auch mit Bordmitteln hin. Da es komfortabler ist dies per Script zu erledigen hier die nötigen Powershell-Anweisungen. Zuerst kopieren wir Utilman.exe und cmd.exe:

copy "C:\Windows\System32\utilman.exe" "C:\Windows\System32\utilman.exe.bak"
copy "C:\Windows\System32\cmd.exe" "C:\Windows\System32\cmd.exe.bak"

Nun benötigen wir den Zugriff auf den Registryschlüssel HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\ um dort die Werte PeningFileRenameOperations und AllowProtectedRenames zu setzen.

$smreg = "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\"

AllowProtectedRenames ist wichtig, sonst klappt der Vorgang nicht. Dies ist mal wieder einer von so vielen Registrywerten die nicht klar dokumentiert sind. Er wird im MSDN nur einmal im Zusammenhang mit VSS und der Wiederherstellung von Dateien der Windows File Protection genannt: https://msdn.microsoft.com/en-us/library/windows/desktop/aa381498(v=vs.85).aspx.

set-ItemProperty -Path $smreg -Type DWORD  -Name AllowProtectedRenames -Value 1

Jetzt muss man die zu kopierenden Dateien angeben. Da es aber kein klassischer Copy-Befehl sondern ein Move-Befehl ist, wo die Quelldatei nach dem Vorgang weg ist, verwenden wir die vorher erstellte Kopie von CMD.EXE. Dabei ist darauf zu achten, dass vor den Dateinamen noch eine spezielle Notation \??\ nötig ist. Leider gibt es keine Informationen darüber wann !\??! verwendet wird. Aber damit hat es immer funktioniert. Wichtig ist noch, dass es ein String-Array sein muss, damit die Werte in der Registry korrekt als REG_Multi_Sz gespeichert wird.

[string[]]$moveFiles= @("\??\C:\Windows\System32\cmd.exe.bak", "!\??\C:\Windows\System32\Utilman.exe")
set-ItemProperty -Path $smreg -Type MultiString -Name PendingFileRenameOperations -Value $moveFiles

Nun muss nur noch der Rechner neu gestartet werden und schon steht einem eine Eingabeaufforderung mit Systemrechten zur Verfügung. Bei Verwendung von UTILMAN.EXE klickt man am Anmeldebildschirm einfach auf den Kreis mit den zwei Pfeilen und der Einblendung “Erleichterte Bedienung”.

Um die Änderung rückgängig zu machen, könnte man nun dieses Script verwenden, welche einfach die Kopie von Utilman.exe zurückkopiert:

$smreg = "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\"
set-ItemProperty -Path $smreg -Type DWORD  -Name AllowProtectedRenames -Value 1
[string[]]$moveFiles= @("\??\C:\Windows\System32\Utilman.exe.bak", "!\??\C:\Windows\System32\Utilman.exe")
set-ItemProperty -Path $smreg -Type MultiString -Name PendingFileRenameOperations -Value $moveFiles

Es geht aber noch einfacher, auch im Falle eines Fehlers zwischendrin, bemüht man einfach die Windows File Protection und beauftragt diese mit der Wiederherstellung der betreffenden Dateien:

# Falls was schiefgeht:
SFC /SCANFILE=C:\Windows\System32\cmd.exe
SFC /SCANFILE=C:\Windows\System32\utilman.exe

Jetzt nochmal das ganze Script um oben beschriebene Funktionalität zu erreichen:

copy "C:\Windows\System32\utilman.exe" "C:\Windows\System32\utilman.exe.bak"
copy "C:\Windows\System32\cmd.exe" "C:\Windows\System32\cmd.exe.bak"
$smreg = "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\"
set-ItemProperty -Path $smreg -Type DWORD  -Name AllowProtectedRenames -Value 1
[string[]]$moveFiles= @("\??\C:\Windows\System32\cmd.exe.bak", "!\??\C:\Windows\System32\Utilman.exe")
set-ItemProperty -Path $smreg -Type MultiString -Name PendingFileRenameOperations -Value $moveFiles

Hier noch ein guter Blogartikel mit Registrybildern, wer es von Hand machen möchte: https://blog.cscholz.io/windows-72008-movefileex/. Eine weitere Methode anstatt PendingFileRenameOperations:
https://guyrleech.wordpress.com/2014/07/16/reasons-for-reboots-part-2-2/, einfachere Beschreibung: https://superuser.com/questions/1204878/how-can-i-tell-windows-to-overwrite-a-system-file-on-the-next-reboot.

Eine weitere Variante an Systemrechte zu gelangen ist hier beschrieben: https://newyear2006.wordpress.com/2013/01/01/eingabeaufforderung-mit-lokalen-systemdienst-rechten-unter-windows-8-und-windows-server-2012/.

Binärtyp einer EXE-Datei unter Windows ermitteln, ob 32- oder 64-Bit–man spricht auch von Bitness

Möchte man unter Windows bei einer ausführbaren Datei wissen, ob diese eine 32-Bit oder 64-Bit Version ist, dann kennt die Win32-API die Funktion GetBinaryType. Mittels Powershell kann man diese Funktion wie folgt nutzen:

$MethodDefinition = @‘

// https://msdn.microsoft.com/en-us/library/windows/desktop/aa364819(v=vs.85).aspx
[DllImport("kernel32.dll")]
public static extern bool GetBinaryType(string lpApplicationName, out uint lpBinaryType);

‚@

$Kernel32 = Add-Type -MemberDefinition $MethodDefinition -Name ‚Kernel32‘ -Namespace ‚Win32‘ -PassThru

# Funktioniert aber nur, wenn man sich in einem 64-Bit Prozess befindet, also: [System.IntPtr]::Size -eq 8
$type=0
$Kernel32::GetBinaryType("c:\windows\system32\cmd.exe", [ref] $type)  # unter 64-Bit sollte es 6 sein
$type
$Kernel32::GetBinaryType("c:\windows\syswow64\cmd.exe", [ref] $type)  # unter 64-Bit sollte es 0 sein
$type

# mögliche Werte für $type:
# SCS_32BIT_BINARY = 0, // A 32-bit Windows-based application
# SCS_64BIT_BINARY = 6, // A 64-bit Windows-based application.
# SCS_DOS_BINARY = 1,   // An MS-DOS – based application
# SCS_OS216_BINARY = 5, // A 16-bit OS/2-based application
# SCS_PIF_BINARY = 3,   // A PIF file that executes an MS-DOS – based application
# SCS_POSIX_BINARY = 4, // A POSIX – based application
# SCS_WOW_BINARY = 2    // A 16-bit Windows-based application

Dabei ist zu beachten, wenn man den Test macht, dass IntPtr 8 liefern sollte, sonst befindet man sich in einem simulierten WOW64-32Bit-Prozess und bekommt verwunderliche Ergebnisse zurück.

Ganz einfach WLAN-Sicherheitsschlüssel unter Windows auslesen

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…

Festplatten löschen (wipen) mit Windows Bordmitteln

Unglaublich was man manchmal für Entdeckungen macht und sich wundert, warum man davon noch nie gehört hat. Per Zufall bin ich heute über Cipher.EXE gestolpert. Hatte ich zuvor noch nie gehört. Wenn man die Hilfe von Cipher.EXE anschaut, dann wird schnell klar, dass es für die Verschlüsselung von Dateien und Verzeichnissen zuständig ist.

Aber dann taucht da auch der Parameter /W für Wipe auf:

    /W       

Entfernt Daten aus verfügbarem, nicht verwendetem Speicherplatz auf dem Volume. Alle anderen Optionen werden ignoriert, wenn diese Option ausgewählt wird. Das angegebene Verzeichnis kann sich an einer beliebigen Position auf dem lokalen Volume befinden. Wenn es sich um einen Bereitstellungspunkt oder einen Verweis auf ein Verzeichnis auf einem anderen Volume handelt, werden die Daten auf diesem Volume entfernt.

Es agiert also nicht wie Sdelete von Sysinternals und überschreibt bestehende Dateien, sondern überschreibt den freien Speicherbereich eines Volume.

Wenn man nun eine Festplatte mittels DISKPART Befehl CLEAN löscht, dann eine Partition darauf einrichtet, dann kann man mittels CIPHER /W die Festplatte komplett löschen.

Spannend wird die Sache in Verbindung mit WinPE. Schade das WinPE, WinRE und die Windows-Bootmedien keine direkte Unterstützung für CIPHER.EXE haben. Aber oft hat man ja sowieso irgendwo ein Windows bzw. auf der zu löschenden Platte ein vorhandenes Windows.

Man muss also einfach nur CIPHER.EXE von der lokalen Windows-Installation kopieren. Dabei ist allerdings zu beachten, ob die WinPE-Umgebung 32-Bit oder 64-Bit unterstützt. Je nachdem verwendet man dann C:\Windows\System32\cipher.exe oder C:\Windows\SysWOW64\cipher.exe. Wenn die Cipher.EXE von dem Laufwerk kommt, welches gelöscht werden soll, kopiert man es auf das RAM-Laufwerk X: und startet es von dort aus.

Ach noch was: Man könnte auch den CLEAN Befehl mit dem Parameter ALL bei DISKPART verwenden, dann würde auch alles mit 0x00 überschrieben. Warum sollte man dann CIPHER.EXE verwenden? CIPHER.EXE geht beim Überschreiben anders vor, es überschreibt in drei Durchgängen. Zuerst wird alles mit 0x00 dann mit 0xFF und am Schluss mit Zufallswerten überschrieben. Dies ist auch der Grund, warum CIPHER.EXE nachgesagt wird, es wäre langsam.

http://blogs.technet.com/b/chad/archive/2012/08/16/tip-53-wipe-your-hard-drive-without-any-extra-programs.aspx

Und noch was: Bei SSDs gibt es nicht die sichere Möglichkeit wirklich alles zu löschen. In diesem Fall sollte man schauen, ob die betreffende SSD eine interne AES-Verschlüsselung bietet und ob man dort den zugehörigen Key löschen kann.

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

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.