Lidl WI-FI Steckdose SWS-A1 SilverCrest IAN 103043

[SebiM]

Die Frage ist nur ob das auch ohne Handy funktioniert mit über ein LAN wo irgendwo ein WLAN AP hängt ...

Einfach ausprobieren? Mich hat's aber auch gerade interessiert, also...
Jein.
Provisorischer Test, wie meist aber nur mit Schnellschnell-Scripts via PHP-CLI. Drei Ubuntu-Rechner: Sender und ein Listener im LAN, ein Listener via WLAN. Router ist ein Asus AC68U mit normalem AsusWRT.

Der UDP-Broadcast vom Sender kommt auch im WLAN an, und ich habe eine einigermaßen 08/15-Konfig im Router.

Aber, würde das nun funktionieren mit der SmartConfig? Bin mir nicht 100% sicher.
Ich sende ja testhalber mit 10ms-Pausen. Beim LAN-Listener kommt das auch so an, auf dem WLAN-Notebook hingegen sammelt irgendwer die Pakete immer ca. eine Viertelsekunde lang (auf 5 GHz sogar 300ms). Den Effekt habe ich allerdings auch, wenn der Broadcast von der App aufm Handy kommt. Ob da nun der Router was sammelt, oder der Treiber oder Linux-Kernel: Weiß ich nicht, wüsste jetzt auch nicht, wie ich das testen sollte. Ausprobiert habe ich: RT3090 auf 2,4 GHz und Realtek 8812AU (?) auf 2,4 sowie 5 GHz.
Wenn's nicht am Router liegt, würde auch die SmartConfig vom LAN aus gehen.
EDIT Nachtrag: Unter OS X beim Lauschen exakt dasselbe.

Aber nie genutzt diese Funktion, ich mach da immer ein WLAN auf bei meinen Modulen, aber eben über AT Kommandos vom µC. Ist eigentlich auch besser als dieser SmartConfig scheiss, aber gut naja.

/Daniel

Jaa, sicherlich. Die Bastel-Geschichten sind aber doch wieder ein anderes Thema 
Diese Erkenntnis bezüglich Broadcasts ist vielleicht dennoch zu was gut: Eine Erkennung aller bereits ins WLAN eingebundener Dosen via Broadcast würde auf jeden Fall funktionieren.

[ext23]

Router, Broadcast?!? Also Du meinst jetzt ein Router im Sinne von LAN <-> WLAN Brücke?

Diese SmartConfig ist aber schon eine krasse Sicherheitslücke wa. Da kann man sich ja schon ein Scanner bauen der nur lauscht ob er irgendwo ein PSK abfragen kann...

Aber gut, die Paranoiden unter uns nutzen auch kein PSK mehr im WLAN

So ich habe meine gesprengte Dose mal untersucht, hier mal die Beschaltung des WLAN Moduls:

HF-LPB100 PIN | Desc | Ziel
11 | PWM_1 | Relais
39 | UART0_TX | µC Pin 3
41 | UART0_RX | µC Pin 2
43 | nLink | LED
44 | nReady | LED
45 | nReload | Taster und µC Pin 18 über R-Netzwerk
47 | EXT_RESETn | Taster und µC Pin 18 über R-Netzwerk

Soweit ich das noch richtig rekonstruieren konnte, die Platine ist leider etwas verkohlt

/Daniel

[SebiM]

Router, Broadcast?!? Also Du meinst jetzt ein Router im Sinne von LAN <-> WLAN Brücke?

Jaja genau, also LAN, WAN-Port fürs Kabelmodem, und WLAN 2,4 u. 5 GHz.
Was man halt so üblicherweise daheim hat.

Diese SmartConfig ist aber schon eine krasse Sicherheitslücke wa. Da kann man sich ja schon ein Scanner bauen der nur lauscht ob er irgendwo ein PSK abfragen kann...

Hmja, ich wies bereits vorsichtig darauf hin...
Stellt sich die Frage, warum man nicht WPS nutzte, wenn schon eh unsicher. Andererseits, dort zu lauschen dürfte schneller zum Erfolg führen, als ewig darauf zu warten, dass mal ein Nachbar eine neue Dose in Betrieb nimmt.
Aber wir sind ja eindeutig im Consumer-Bereich. Für so richtig wichtige Dinge würde man wohl eh andere teurere Lösungen nehmen. Ne Ethernet-Steckdosenleiste oder was weiß ich...

Aber gut, die Paranoiden unter uns nutzen auch kein PSK mehr im WLAN

Jetzt sind wir aber Offtopic: Ups, habe ich da was verpasst...?

So ich habe meine gesprengte Dose mal untersucht, hier mal die Beschaltung des WLAN Moduls:

HF-LPB100 PIN | Desc | Ziel
11 | PWM_1 | Relais
39 | UART0_TX | µC Pin 3
41 | UART0_RX | µC Pin 2
43 | nLink | LED
44 | nReady | LED
45 | nReload | Taster und µC Pin 18 über R-Netzwerk
47 | EXT_RESETn | Taster und µC Pin 18 über R-Netzwerk

Soweit ich das noch richtig rekonstruieren konnte, die Platine ist leider etwas verkohlt

/Daniel

Hmja, gut, das ist wenig überraschend.
Bleibt noch die Frage, was daraus machen? Ne eigene Firmware schreiben will glaube ich auch niemand...

[ext23]

Jetzt sind wir aber Offtopic: Ups, habe ich da was verpasst...?

Mhh ka, geht dann in die Richtung WPA-Enterprise

[pjakobs]

Zu den RF-Geräten (433 MHz).
In den "normalen" UDP-Datenpaketen an die Dose haben wir ja bislang:
Paketzähler, CompanyCode, DeviceCode, AuthCode...
und dann eine Befehlsnummer. Bei SilverCrest halt nur die 01 00 00 FF FF zum Anknipsen, 01 00 00 00 FF zum Ausknipsen, und eben die Statusabfrage (0x23).
RF-Geräte werden mit 08 <Adress-Code> angesteuert, und da gibt's dann verschiedene Unterbefehle, auch z.B. für Dimmer.
Die Länge der Payload ergibt sich aus dem Befehls-Wert. Dank der AES-CBC-Verschlüsselung kommt aber immer ein 16-Byte-Block heraus; man sollte also die übrigen hinteren Bytes nicht versuchen, großartig zu interpretieren...

So, wer schreibt das jetzt nun mal irgendwie sinnvoll zusammen. Immer der, der fragt? 

als immer noch FHEM Anfänger stelle ich fest: die Community ist großartig!

Ich habe seit kurzem ein vierer-Set der "micromaxx" Steckdosen, eine enthält das WLAN Gateway plus drei dumme 433MHz Slaves.
Mit dem Silvercrest Modul kann ich die WLAN Dose prima schalten, aber es weiß nichts von den weiteren Dosen. Hat schon jemand Code, der damit umgehen kann?

Grüße

pj

[pjakobs]

Ich hab mal ein paar Zeilen Code geschrieben, die ein pcap File (z.B. von der Fritzbox) dekodieren und gleich entschlüsseln. Vielleicht hilft's ja jemandem.

Code Auswählen Erweitern


se Crypt::Rijndael;
require Net::Packet::Dump;
use Net::Packet::Consts qw(:dump);
use Data::Dumper;

$num_args = $#ARGV+1;
if($num_args!=1){
        print "\nUsage: decode.pl tcpdump_filename\n";
        exit;
}

$filename=$ARGV[0];

$host1 = "192.168.29.36";
$host2 = "192.168.29.23";

$key = "0123456789abcdef";
$cipher = Crypt::Rijndael->new(
                $key,
                Crypt::Rijndael::MODE_CBC()
                ) or warn "cannot init decrypt";
$cipher->set_iv($key);

my $dump = Net::Packet::Dump->new(
        mode            => NP_DUMP_MODE_OFFLINE,
        file            => $filename,
        unlinkOnClean   => 0,
        filter          => "host ".$host1." host ".$host2." udp",
);

$dump->start;
$dump->nextAll;

for ($dump->frames){
        $frame=$_;
        $head=$frame->l3->print;
        $head =~ s/L3\:[+\ ]IPv4\://g;
        $head =~ s/\n//g;
        #
        # L3:+IPv4: version:4  hlen:5  tos:0x00  length:40  id:51729
        # L3: IPv4: flags:0x00  offset:0  ttl:63  protocol:0x06  checksum:0x78c2
        # L3: IPv4: src:52.10.39.38  dst:192.168.29.36
        #
        #  version:4  hlen:5  tos:0x00  length:40  id:51729 flags:0x00  offset:0  ttl:63  protocol:0x06  checksum:0x78c2 src:52.10.39.38  dst:192.168.29.36
        #

        $head =~ s/\s+//;
        %values=split /[\s\:]{1,}/, $head;
        if((($values{'src'}==$host1 && $values{'dst'}==$host2) || ($values{'src'}==$host2 && $values{'dst'}==$host1))&&$values{'protocol'}=='0x11'){
                print "package id: $values{'id'}, ";
                print "From: $values{'src'} To: $values{'dst'} ";
                # L7:+Layer7: dataLength:25
                # L7: Layer7: data: 0140accf234dfcce10e642289d8270432ec236cf21ea5909f0
                $body=$frame->l7->print;
                $body =~ s/L7\:\+Layer7\:\ dataLength\://g;
                $body =~ s/L7\:\ Layer7\:\ data\: //g;
                @body=split /\n/, $body;
                print "len: ".@body[0]."\n";

                $crypt=pack "H*",@body[1];
                $crypt=substr($crypt,9);
                $plain=$cipher->decrypt($crypt);
                $plain =~ s/(.)/sprintf("%02x",ord($1))/eg;
                print $plain."\n\n";
        }
}


[starfish]

hallo,
ich habe im ähnlichen Thread betr. die Aldi WiFi - Dose  ein wireshark-Mitschnitt hochgeladen.  Wahrscheinlich lassen sich die Erkenntnisse aus diesem Thread darauf anwenden - könnte dies einer der Spezialisten hier kurz anschauen?
https://forum.fhem.de/index.php/topic,57612.msg500117.html#msg500117
gruss
starfish

[SebiM]

Puh, 10 Monate später...
Ja das scheint dasselbe Protokoll zu sein, es gelten die bekannten Regeln: Befehlsbyte (01), Lock-Status-Byte (40h), MAC-Adresse, Länge des kodierten Blocks, der Rijndael-kodierte Block selbst. Nur das Kommando selbst ist nen Tick anders aufgebaut, da steckt irgendwo noch die 433MHz-Funkadresse drin.

[SebiM]

Ok hab's mal durch den Dekoder gejagt.
Also, wenn wenn den SilverCrest-Dosen diese Befehle gehen:
01000000ff  ausschalten
010000ffff einschalten

dann sind's hier anscheinend, nach der PCAP-Datei:
0002a1 c21192
und
0002a2 c21192
(Reihenfolge weiß ich nicht?)

wobei offensichtlich der c21192 die 433MHz-Funkadresse der Ziel-Steckdose ist.

Viel Glück damit, ich kann's nicht testen; notfalls kann ich nur mit gewissen Aufwand nochmal in die dekompilierte App gucken (wenn ich die Files noch finde )

[starfish]

@SebiM  anbei eine etwas längere Aufzeichnung mit je 2 EIN-AUS Schaltbefehlen  zuerst an die WLAN-Dose anschliessend für die 433 MHz-Dose.  192.168.0.167 ist die Android APP   und 192.168.0.178  die WLAN-Dose. 
Was auffällt ist, dass die Datenfelder unterschiedlich sind für z.B. die beiden WLAN-EIN    bzw. die beiden WLAN-AUS. (also bei 10 x EIN  10 verschiedene Datenfelder) ist das bei den Lidl-Dosen auch so oder bedeutet das, dass die Aldi-Dose gar nicht auf diese einfache Weise zu schalten ist?

p.s. ich habs mal selbst mit dem decoder von pjacobs versucht, aber da fehlt offenbar noch was:
root@cubietruck:~# ./decode.pl aldi-dose5.pcap
./decode.pl: line 1: se: command not found
./decode.pl: line 2: require: command not found
./decode.pl: line 3: syntax error near unexpected token `('
./decode.pl: line 3: `use Net::Packet::Consts qw(:dump);'

[SebiM]

@starfish
Hm ich habe leider auch keinen fertigen Paket-Decoder für Wireshark, aber von Hand ein paar Pakete nochmal in mein altes PHP-Script kopiert und dekodiert...
Aber, eine Antwort habe ich eventuell, welche schon alles Weitere erledigt:
Der unterschiedliche Inhalt gleicher Schaltbefehl-Pakete. Das hat einen relativ einfachen Grund: Die Verschlüsselung arbeitet immer mit Blöcken von 16 Bytes Länge (128 Bit Block-Cipher). Wenn nun aber die App intern das UDP-Paket zusammenbastelt, nimmt er dafür einfach ein 16-Byte-Array, aber uninitialisiert. Der setzt nicht erstmal alle Bytes auf 0 oder so, sondern nimmt wie's grad aus dem Speicher (Heap/Stack) kommt, und schreibt dann Byte für Byte seine Daten dort sein. Die 433MHz-Schaltbefehle sind nun eben anscheinend 8 Byte lang (siehe mein vorheriges Posting), d.h. die zweite Hälfte dieses Blocks hat Zufalls-Inhalt.
Apropos, ich sehe gerade in meinem Script eine kleine Panne, die ich letztens übersehen habe: Bin mir nicht sicher, ob die Nutzdaten nun 7 oder 8 Bytes lang sind. Im 8. Byte steht anscheinend nochmal immer entweder 61h oder 01h, je nach ein- oder ausschalten.

Das ist eben die einfache Erklärung für die abweichenden Pakete. Bei der Lidl-Dose füllt die SilverCrest-App glaube ich dessen Schaltbefehle mit 04-Bytes auf, aber darauf verlassen sollte man sich nicht. Alle Dosen ignorieren aber anscheinend sowieso, was nach den eigentlichen Nutzdaten steht, wenn man selbst UDP-Pakete basteln will...

Apropos: Da ist halt eben das kleine Problem, dass anscheinend die App die 433er-Adressen vergibt und verwaltet. Wenn man in der App ein neues Gerät hinzufügt, nimmt er irgendeine freie Adresse. Das Gerät, welches ja im Koppel-Modus sein muss, nimmt dann wohl einfach die erste emfpangene Adresse an. Da gibt's einen eigenen Steuercode für, aber ohne Mitschnitt...
Ich kann das ja leider alles nicht selbst testen, ich hab's nur damals (mit der Lidl-Dose) in der dekompilierten App grob gesehen, was die noch könnte.
Also zur Erinnerung: Die Lidl-Steckdose schaltet ja direkt, und ihr 433MHz-Sender liegt von der offiziellen App her brach, weil der entsprechende Menüpunkt für die Verwaltung der 433MHz-Geräte deaktiviert ist. Die Aldi-Dose hat ja die Konfiguration genau andersherum; wenn ich das im Prospekt richtig gesehen habe, schaltet der WLAN-Zwischenstecker gar nicht, sondern kann nur 433er-Befehle weiterleiten.
Das ist also eine Art Baukasten-System mit etwas verschiedenen Konfigurationen sowohl der Hardware als auch für die Apps. Integrierbar in Systeme wie FHEM oder einfache gescriptete Kommandozeilen-Geschichten sind sie aber alle, und zwar eben mit denselben Mechanismen.

So, falls jetzt noch Unklarheiten sein sollten, müsste ich den ganzen App-Kram nochmal finden und mich wieder einlesen, bitte nicht...

[micky0867]

p.s. ich habs mal selbst mit dem decoder von pjacobs versucht, aber da fehlt offenbar noch was:
root@cubietruck:~# ./decode.pl aldi-dose5.pcap
./decode.pl: line 1: se: command not found
./decode.pl: line 2: require: command not found
./decode.pl: line 3: syntax error near unexpected token `('
./decode.pl: line 3: `use Net::Packet::Consts qw(:dump);'

Pack mal in die ALLERERSTE Zeile

Code Auswählen Erweitern


#! /usr/bin/perl


und ersetze das erste "se" durch "use" (ohne Anführungszeichen).

Micky

[enterpriseII]

Hallo zusammen,

ich habe mir auch das Set von Aldi besorgt und den Verkehr etwas näher analysiert.
Ich kann inzwischen im LAN durch ein Perl-Script sowohl die WLAN- als auch die daran angebundene 433 MHz Steckdose mit UDP schalten.

Zum Filtern des Netzwerkverkehrs der App ist es ganz sinnvoll tshark auf einen Mitschnitt lozulassen:

Code Auswählen Erweitern

tshark -nr [pcap File]  -Y udp -Y udp.dstport==8530 -Y udp.srcport!=8530  -T fields -e data

@starfish:
Ich habe dein pcap-File mal durch mein Analyse-Script geschickt.
Die dekodierten Befehlstteile der Nachricht sehen so aus:

Code Auswählen Erweitern

000015c21192dd6157facb2004040404
000016c21192dd010000ffff04040404
000018c21192dd01000000ff04040404
000019c21192dd010000ffff04040404
00001ac21192dd6157facb3e04040404
00001cc21192dd01000000ff04040404
00001dc21192dd0879fa116004040404
00001ec21192dd0879fa117004040404
000020c21192dd0879fa116004040404
000021c21192dd6157facb5c04040404
000022c21192dd0879fa117004040404

Ich habe das mal mit meinen Daten verglichen:
00xxxxc21192dd010000ffff04040404 und 00xxxxc21192dd01000000ff04040404 sind die bereits bekannten Ein- und  Ausschaltbefehle für die WLAN-Steckdose.
xxxx zählt in der Regel einfach hoch. Um ein immer gültiges Paket zu erhalten, lässt sich xxxx durch ffff ersetzen.
Für deine 433 MHz-Steckdose sieht es so aus:
00xxxxc21192dd0879fa116004040404 ist zum Einschalten.
00xxxxc21192dd0879fa117004040404 ist zum Ausschalten.
Deine spezieller Funkadapter müsste durch den Teil 79fa11 identifiziert sein.
Auch hier ist xxxx für einen allgemeingültigen Schaltbefehl wieder durch ffff zu ersetzen.

"Verschlüsselt" man dann den Befehlsteil wieder und baut den Gesamtbefehl wieder zusammen, müssten sich für dich diese Paketinhalte zum Schalten der Funkdose ergeben:
Einschalten:

Code Auswählen Erweitern

0140009569a731281082b36c894db462909fc19e24a48f73f8
Ausschalten:

Code Auswählen Erweitern

0140009569a7312810aff14bdafc0a3127bfadeb2a4d904bbf

Kannst du das mal testen?

[Für die WLAN-Steckdose gelten wie bekannt
0140009569a73128105b94d42ef5c01e302b1b7cb7a7d8eab0
0140009569a73128106630bcfe88830cb4eeab4a784356ab9f
]

Viele Grüße

enterprise

[SebiM]

@enterpriseII
hmja kann ich ungefähr so bestätigen.

Nur eine Frage zum Verständnis allgemein zum Aldi-Set, weil mir das weder aus dem Prospekt noch aus der Website klar hervorging: Sind das letztlich _zwei_ Schaltdosen? Ich hätte das so verstanden, dass das WLAN-Ding nur ein Zwischenstecker als Bridge ist für 433MHz-Dosen.

Und, nächste Frage falls ja, gibt's die wohl noch?   (Hier Raum München)

[SebiM]

Für deine 433 MHz-Steckdose sieht es so aus:
00xxxxc21192dd 08 79fa11 6004040404 ist zum Einschalten.
00xxxxc21192dd 0879fa117004040404 ist zum Ausschalten.
Deine spezieller Funkadapter müsste durch den Teil 79fa11 identifiziert sein.
Auch hier ist xxxx für einen allgemeingültigen Schaltbefehl wieder durch ffff zu ersetzen.

So ich habe gerade doch nochmal in dem dekompilierten Zeugs von ca. letztem Jahreswechsel rausgesucht, um das nochmal zusammenzufassen. Das mit der verschlüsselten "Load" (dem normalerweise 16 Byte langem Block) sollte ja eh klar sein, also nochmal dessen Aufbau, hier sind mir eh auch wieder Fehler unterlaufen:

1 B  immer 0
2 B  Packet Counter, oder einfach FFFF
1 B  Company Code. ANSCHEINEND C1 = Lidl, C2 = Aldi
1 B  Device Code -- 11h für Funksteckdose?
2 B  "Auth Code", hier 92DD, wohl bei jeder Dose anders
x B  Kommando

RF-Kommando:
1 B  08 "ich bin ein RF-Kommando"
2 B  RF-Adresse
1 B  Kommando: 60h/70h fürs Schalten, 0 wird für Dimmer verwendet (gefolgt von einem Wert)

Das nun also als vollständige Load-Beschreibung für die RF-Dosen. (...von denen ich immer noch keine habe und auch nicht unbedingt brauche.. )