Ingenieurssoftware-Archäologie

Ingenieurssoftware hat oft eine kleine aber feine Zielgruppe – ein Grüppchen, das globale Softwarekonzerne nicht unbedingt im Visier haben. Dementsprechend atmet die Benutzeroberfläche oft nolstalgisch-spartanischen Charme.

Aber auch in den Tiefen solcher Software gibt es aufsehenerregende Funde aus dem Software-Paläozoikum – genau das richtige für das Elkement, das diese Bugs versteckten Features unerbittlich erschnüffelt. Von einem Paradebeispiel aus der täglichen Schnüffelpraxis soll diese Geschichte handeln!

Folgendes Filmchen soll metaphorisch auf das Thema einstimmen – ein prähistorisches Idol des Elkements, ein großartiger Jäger und Schnüffler, demonstriert seine Beharrlichkeit … und wird am Ende wie immer ausgetrickst:

Was man hätte sehen sollen (in jener Software): Ein Bild der Bedienelemente einer Regelung und darüber schwebende Zahlen. Mit Rumspielen an den abgebildeten Knöpfchen hätte man das echte Gerät simulieren können.

Was man sah: Eine Fehlermeldung in einem mutmaßlich fernöstlichen Zeichensatz.

Natürlich fragt der geübte Sniffer als Erstes Google Translate um Hilfe:

Die [XY]-Gerätedatei kann nicht gelesen werden.

… und es gibt tatsächlich eine Datei xydevice.xls … die sich aber mit Excel lesen lässt (?!) … also zumindest lassen sich die überwiegend fernöstlichen Zeichen in den Tabellen darin betrachten.

Nächster Schritt: Wahlloses Durchtesten der üblichen Fallstricke für Software aus vergangenen Epochen? 32bit versus 64bit? Administrator-Rechte? Dateiberechtigungen? Muss eine alte Windows-7-Maschine wiederbelebt werden? … und tatsächlich: Ein einziges Mal sieht der erschöpfte Schnüffler ganz kurz die Animation der XY-Regelung: Beim ersten Test auf einer paläozoischen Maschine (Windows 7 und 32bit). Leider ist der Test nicht reproduzierbar, also wird unerschrocken weitergeforscht.

Ein professionelles Schnüffelwerkzeug – Microsoft Sysinternals Process Monitor – zeigt, dass die Software erfolgreich auf die rätselhafte Datei zugreift:

Process Monitor: Prüfung Zugriff auf xls-Datei durch Anwendung

Kurz vor dem Zugriff arbeitet sich die Software durch Datenbanktreiber (‚JET‘) für Office-Dateien – die letzte davon ist msexcl40.dll – damit kann eine XLS-Datei wie eine Datenbank abgefragt werden.

Aber in dieser Schnüffelspur sieht man keine Fehlermeldung: Die xls-Datei wird geschlossen, bevor das Popupfenster mit Fehlermeldung erscheint … also ist die Anwendung halbwegs kontrolliert mit dem Fehler fertig geworden und hat ihn richtig ‚gehandled‘.

Das Elkement bzw. die Datenkrake haben langjährige einschlägige Erfahrung im wilden Basteln mit Konstrukten aus Excel- / Access- und Textdateien, die zu fragilen Datenbanken vereinigt werden. D.h. im Programmierer aus der fernen Zeitzone erkannte das Elkement eine verwandte Seele. Es versuchte, sich in diesem Lao Tse der Office-Programmierung hineinzufühlen. Beim einzig erfolgreichen Start des Programms waren einige XML-Dateien erzeugt worden. Soweit erahnbar durch Zeichenvergleich, wurden aus der xls-‚Datenbank‘ Einträge zu einem Gerät bestimmten Typs gelesen und in die XML-Datei geschrieben.

Aber was ging schief? Der Schnüffler der nächsten Tiefe wird gestartet – der Windows Debugger WinDbg (Teil der Debugging tools for Windows). Mit Reverse-Engineering-Halbwissen stolpert das Elkement zur nächsten unhandled oder handled exception – und wieder fällt msexec40.dll unangenehm auf:

Output Windows Debugger - Fehler bei Datenbankzugriff - msexec40.dll

Und da war sie endlich – die google-bare Fehlermeldung im Microsoft-O-Ton:

Unexpected error from external database driver (1).

So richtig optimistisch machte dieser eher generisch und schlicht gehaltene Text ja nicht. Aber man glaubt es kaum – es gab tatsächlich einen relativ neuen Microsoft-Artikel, der exakt diesen Fehler im genau passenden Kontext auflistet. In einem Überblick über  Betriebssystem-Updates von Herbst 2017 wird über ein Problem mit älteren JET-Datenbanktreibern für xls-Dateien brichtet – über einen neuer Fehler, der genau seit diesem Windows-Updates auftritt:

Microsoft-Artikel - Problem mit JET-Treiber / xls-Dateien nach Update

Damit kann endlich eine plausible Erklärung für den einzig erfolgreichen Test formuliert werden: Die Software wurde auf diesem länger nicht gestarteten Windows-7-Computer getestet – exakt als die Updates der letzten Monate noch nicht installiert worden waren, inklusive dem in diesem Artikel erwähnten Update.

Auch der dezente Hinweis von Microsoft, doch einen neueren Datenbanktreiber zu verwenden – neuer als Stand Office 2007 – passt dazu: Die ausführbaren Dateien der prähistorischen Softwaren waren alle ca. 10 Jahre alt.

Wie der possierlich-zappelige Schnüffler aus Ice Age wurde das Elkement damit mit einem Dilemma konfroniert und ausgetrickst: Um die Sicherheit nicht zu gefährden [Bitte Buzz Words passend einsetzen: Cyber Security – Internet of Things] wurde das unerbittliche Windows Update nicht mehr deinstalliert. Damit bleibt nur zu hoffen, dass entweder Lao Tse den Datenbanktreiber austauscht oder dass Microsoft, wie im Artikel angekündigt, das prähistorische Feature wieder aktiviert.

Wärmepumpen-Forensik – Teil 2: Mitloggen der Heizenergiewerte

Nachdem sich der neue CAN-Bus-Sniffer warmgeschnüffelt hatte mit nicht sehr spannenden Testwerten, wurde es Zeit für den Einsatz im Feld.

Der Raspberry Pi erhielt zunächst einmal einen würdigen Platz, um sich Überblick über den Heizraum zu verschaffen …

Raspberry Pi hat Alles im Blick

Eine typische provisorische Teststellung. Die einzige Stelle, an der am Beginn der Tests das WLAN-Signal halbwegs OK war. Ein ausgekreuztes Ethernet-Kabel gibt’s außerdem auch noch!

Das CAN-Bus-Kabel wurde entsprechend der Bedienungsanleitung an die Wärmepumpe angeklemmt:

Bedienungsanleitung Stiebel-Eltron WPF 7 basic, Abschnitt Kleinspannung

Abschnitt 12.2.3 – Kleinspannung, Bus-Leitung. Die optionale zusätzliche Stromversorgung („+“) wurde nicht verwendet.

Wie beim Testen mit UVR1611 wurde der ebenfalls kurze CAN-Bus nicht speziell terminiert:

Bedienungsanleitung Stiebel-Eltron WPF 7 basic, CAN-Bus angeschlossen

Stiebel-Eltron WPF 7 basic mit offenem Gehäuse – High (rot), Low (blau) und Ground (gelb) sind angeschlossen.

Damit konnten die elkementaren Tests beginnen …

Der beste Arbeitsplatz

(Für eine mögliche Einreichung bei Wettbewerben wie ‚Great place to work…‘)

… und die CAN-Schnittstelle wurde aktiviert, entsprechend der Anleitung von messpunkt.org mit einer Bitrate von 20kbit/s:

sudo ip link set can0 type can bitrate 20000
sudo ifconfig can0 up

Ohne aktive Kommunikation sind auf dem Bus mit Wireshark dann nur alle paar Minuten zwei Pakete zu sehen – die Wärmepumpe will also gefragt werden.

Besten Dank wieder an juerg5524.ch für die Bereitstellung von CAN-Tools und der Elster-Tabellen, die die diversen interessanten Parameter / ‚Indizes‘ enthalten!

Wir verschaffen uns zuerst einen Überblick darüber, welche CAN-IDs die Wärmepumpe überhaupt verwendet. Eine CAN-ID repräsentiert ein Set von Eigenschaften wie z.B. Ausgänge und kann auch Informationen über die Knoten-ID am CAN-Bus enthalten (Zu CAN-Grundlagen siehe z.B. dieses Dokument.)

Wird der CAN-Bus angefragt mit einer Sender-ID von 680 (siehe ) …

./can_scan can0 680

… erhält man folgende IDs …

elster-kromschroeder can-bus address scanner and test utility
copyright (c) 2014 Jürg Müller, CH-5524

scan on CAN-id: 680
list of valid can id's:

  000 (8000 = 325-07)
  180 (8000 = 325-07)
  301 (8000 = 325-07)
  480 (8000 = 325-07)
  601 (8000 = 325-07)

Fragt man gezielt nach jeder dieser IDs …

./can_scan can0 680 180

… sieht man die Liste der Elster-Indizes mit selbst erklärenden Namen der einzelnen Parameter. Die Siedler finden die interessanten (Logging-würdigen) Parameter alle ‚unter‘ der CAN-ID 180 – hier ein Auszug aus dem Output:

elster-kromschroeder can-bus address scanner and test utility
copyright (c) 2014 Jürg Müller, CH-5524

0001:  0000  (FEHLERMELDUNG  0)
0003:  019a  (SPEICHERSOLLTEMP  41.0)
0005:  00f0  (RAUMSOLLTEMP_I  24.0)
0006:  00c8  (RAUMSOLLTEMP_II  20.0)
0007:  00c8  (RAUMSOLLTEMP_III  20.0)
0008:  00a0  (RAUMSOLLTEMP_NACHT  16.0)
0009:  3a0e  (UHRZEIT  14:58)
000a:  1208  (DATUM  18.08.)
000c:  00e9  (AUSSENTEMP  23.3) 
000d:  ffe6  (SAMMLERISTTEMP  -2.6)
000e:  fe70  (SPEICHERISTTEMP  -40.0)
0010:  0050  (GERAETEKONFIGURATION  80)
0013:  01e0  (EINSTELL_SPEICHERSOLLTEMP  48.0)
0016:  0140  (RUECKLAUFISTTEMP  32.0) 
...
01d4:  00e2  (QUELLE_IST  22.6) 
...
092a:  030d  (WAERMEERTRAG_WW_TAG_WH  781)
092b:  0000  (WAERMEERTRAG_WW_TAG_KWH  0)
092c:  0155  (WAERMEERTRAG_WW_SUM_KWH  341)
092d:  001a  (WAERMEERTRAG_WW_SUM_MWH  26)
...
092e:  02db  (WAERMEERTRAG_HEIZ_TAG_WH  731)
092f:  0006  (WAERMEERTRAG_HEIZ_TAG_KWH  6)
0930:  0073  (WAERMEERTRAG_HEIZ_SUM_KWH  115)
0931:  0027  (WAERMEERTRAG_HEIZ_SUM_MWH  39)

Um z.B. den Stand der Raumheizungsenergie in MWh abzufragen, sendet man …

./can_scan can0 680 180.0931

… und der Output enthält gleich die Summe der MWh- und kWh- Angaben (Indices 0930, 0931):

elster-kromschroeder can-bus address scanner and test utility
copyright (c) 2014 Jürg Müller, CH-5524

value: 0027  (WAERMEERTRAG_HEIZ_SUM_MWH  39.115)

Beim Mitschnüffeln mit Wireshark sieht man die beiden Abfagen (Sender-ID 680) und Rückgabe der beiden Werte:

Mitsniffen am CAN-Bus: Wärmepumpe, Abfrage Heizenergie

Netzwerk-Pakete am CAN-Bus: Abfrage der Elster-Indices 0930 (kWh Heizenergie) und 0931 (MWh Heizenergie) mit can_scan. Die Bedeutung der einzelnen Bits wird im Englischen elkementaren Artikel zu diesem Thema beschrieben.

Um das Monitoring dieser Werte zu automatisieren, wird can_scan alle paar Minuten für die interessanten Parameter ausgeführt und der Zahlenwert aus dem Output in eine CSV-Datei geschrieben. Eine andere Option wäre, nur die Abfrage mit can_scan zu starten und den Output dann mit can_logger einzusammeln.

Die CSV-Datei wird dann per FTP an den Server geschickt, der als Datenkrake sämtliche Logfiles aus unterschiedlichen Quellen (UVR1611 / 16×2, PV-Wechselrichter, Smart Meter) zusammenfasst.

Das komplette Skript – wie auch noch etwas mehr Details zur CAN-Forschung – findet man wie immer auf dem elkementaren Blog.

Natürlich muss der neue Logger auch das Professionalitäts-Level des UVR16x2 einhalten, was die Montage betrifft: Deshalb sind im Routinebetrieb nun beide friedlich auf ihrem Holzbrettchen vereint zu finden (und nach einer Restrukturierung der Netzwerk-Architektur gibt es im Heizraum auch verlässliches LAN und WLAN):

Raspberry Pi mit PiCAN-Board von SK Pang, neben UVR16x2

Raspberry Pi mit PiCAN-Board von SK Pang neben UVR16x2 auf ökologischem Brettchen.

Wie der aufmerksame Leser sieht, wurde auch das CAN-Board getauscht – eine serielle Schnittstelle eröffnet Perspektiven für zukünftige Forschungsprojekte. Danke an SK Pang für ein eigentlich gar nicht mehr verfügbares Board!!

Wärmepumpen-Forensik – Teil 1: Mithorchen am Test-CAN-Bus

In grauer Vorzeit war die Aufnahme von Messdaten eine Herausforderung, die an physische und psychische Grenzen ging:

White-Out

White-Out im Winter 2012/13. Bodentemperaturen mussten trotzdem Irgendwer messen!

Wurzelsepp misst

Warten auf das Temperaturgleichgewicht…

Mittlerweile werden fast alle Messdaten automatisch aufgenommen:

Online-Schema CMI/UVR1611/UVR16x2

Online-Schema CMI/UVR1611/UVR16x2 mit den für die Steuerung nötigen Temperatur- und Durchflusssensoren und einigen weiteren Sensoren für ‚Forschungszwecke‘ (Bodentemperatur, Strahlung)

Aber ein wesentlich Sensor hatte sich der Automatisierungswut der Siedler bis jetzt widersetzt: Die offizielle Arbeitszahl in der Messdaten-Dokumentation wird berechnet aus der Wärmeenergie, die Irgendwer tagaus, tagein am Display der Wärmepumpe abliest.

Die Siedler-Wärmepumpe ist zwar ‚absichtlich dumm gewählt‚ – aber vielleicht gibt es ja doch smarte Ansätze? Im Handbuch der Stiebel-Eltron WPF 7 basic werden sie fündig: Im Abschnitt Kleinspannung, BUS-Leitung werden die Anschlüsse CAN-Bus für Fernbedienung angeführt – vielleicht könnte man ja hier die Ergebnisse der bisherigen CAN-Bus-Forschung nutzen? Und vielleicht sogar den derzeit nicht produktiven Raspberry Pi verwenden?

Wie praktisch immer, wenn man glaubt ein Pionier zu sein, findet man im Internet bereits Anleitungen und Tools. Besten Dank an die Stiebel-Eltron-Raspberry-Pi-CAN-Bus-Hacker von messpunkt.org und juerg5524.ch!

CAN-Erweiterungsboard für Raspberry Pi

Erste Herausforderung: Unser Pi ist das ältere ‚Modell B‘. Im Gegensatz zum Nachfolgermodell B+ hatte dieser Pi nur 26 GPIO-Pins für Steuerungszwecke anstatt 40. Die PIN-Belegung hat sich zwar nicht geändert, aber neuere CAN-Boards für 40 Pins passen nicht auf den alten Pi. Der versierte Bastler wird aber auf ebay fündig und freut sich über dieses kleine Board passend für 26 Pins.

Damit ist die CAN-Schnüffel-Hardware einsatzbereit:

Raspberry Pi mit CAN-Board

Raspberry Pi mit aufgestecktem CAN-Board und verdrahtetem CAN-Kabel (grau). Blaues Kabel: Ethernet, schwarzes Kabel: Stromversorgung.

Um nicht gleich die Energieversorgung der Siedlerhütte lahm zu legen und Software zu testen, schnüffeln wir zuerst in einer…

Testumgebung: UVR1611 mit Logger BL-NET

Der Pi-Schnüffler wird daher an einen Test-Bus angeschlossen der aus den folgenden altbekannten Geräten besteht:

  • UVR1611-Steuerung mit einem angeschlossenen Temperatursensor
  • Datenlogger BL-NET, per ausgekreuztem Ethernet-Kabel mit einem Test-PC verbunden, auf dem Winsol läuft. Daten werden jede Minute geloggt. (Überblick zu Logging mit UVR1611 und BL-NET).

Eigentlich müsste jeder CAN-Bus an beiden Enden terminiert werden. Da dieser Test-CAN-Bus wie auch der Wärmepumpen-CAN-Bus nur sehr kurze Kabel verwenden und sie keine negativen Erfahrungen gemacht hatten mit kurzen falsch terminierten Bussen, verzichten die Siedler auf eine korrekte Terminierung.

Test Can-Bus: UVR1611 und BL-NET

Test Can-Bus: UVR1611 (Mitte) mit einem Pt1000-Temperatursensor (Metallhülse, schwarzes Kabel) und Datenlogger BL-NET (oben, weiß). Das CAN-Kabel (grau) verbindet 1) UVR1611, 2) BL-NET (blauer Stecker) und Raspberry Pi (nicht im Bild). Am LAN-Kabel (gelb) ist ein PC mit Winsol angeschlossen.

Software und Konfiguration

Zuerst wird der Kernel des Raspberry Pi auf eine Version upgedated, die die CAN-Schnittstelle unterstützt. Für Details siehe z.B. diesen Blog-Artikel (Abschnitt Software Installation).

In der Raspberry-Pi-Konfiguration muss der für CAN benötigte SPI-Bus aktiviert werden. Dies wird im Detail beschrieben im Blog des CAN-Board-Herstellers SK Pang.

Bitrate einstellen

Der UVR-CAN-Bus verwendet eine Bitrate von 50kbit/s – im Gegensatz zum Wärmepumpen-Bus, der 20kbit/s benötigt. Mit folgendem Befehl wird die Bitrate eingestellt und die CAN-Schnittstelle ‚aktiviert‘:

sudo ip link set can0 type can bitrate 50000
sudo ifconfig can0 up

Bei falscher Bitrate sieht man beim Mitschnüffeln keine Pakete weil das CAN-Interface ’stummgeschaltet‘ wurde (Fehler BUS OFF [*]).

Wenn man alles richtig macht, sind jetzt alle zwischen BL-NET und UVR1611 ausgetauschten Pakete auch für den Raspberry Pi lesbar. Installiert man Wireshark, kann die CAN-Schnittstelle ausgewählt werden … und die Pakete werden korrekt dem CAN-Protokoll zugeordnet:

CAN-Bus-Netzwerkverkehr mitsniffen mit Wireshark

Nachdem Steuerung und Logger diesen Test überstanden haben, wagen sich die Siedler an die Kommunikation mit der Wärmepumpe heran. Fortsetzung folgt … hier in Teil 2.

[*] Etwas mehr Details im elkementaren Artikel zu diesem Thema.

_______________________________________________

Weitere Details zur CAN-Kommunikation der UVR1611

Das Internet der Dinge

Die Siedler betonen gerne, dass sie bodenständige Wissenshandwerker sind, die bezüglich visionären Phrasen eine gesunde Skepsis an den Tag legen.

Gewissen Trends können sie sich dennoch nicht verschließen.

Wer würde nicht wollen, dass der Kühlschrank automatisch Pizza nachbestellt oder PV-Module stolz ihren täglichen Ertrag twittern? All das fällt unter den Begriff Internet der Dinge. Diese Dinge sind oft auf abenteuerliche Weise – gewollt oder ungewollt – mit dem Internet verbunden.

Im Sinne einer realistischen Abschätzung von Sicherheitsrisiko zu Nutzen ist praktische Forschungsarbeit nötig. So führen die Siedler eine minuziöse Untersuchung sämtlicher netzwerkfähiger Dinge in ihrer Siedlerhütte durch. Welches Ding kommuniziert ungefragt mit dem Dem Internet? Und welche Siedlergeheimnisse werden dabei ausgeplaudert?

Entgegen den Klischées in Hacker-Filmen ist es gar nicht so einfach, den Netzwerkverkehr mitzuschnüffeln. Das war einmal, als unsere Netzwerkverkabelung noch mit dem Antennenkabel verwechselt werden konnte:

10base2 t-pieceWehmütig bereuen die Siedler auch, ihren Hub aus dem letzten Jahrtausend entsorgt zu haben. Wie beim Koaxialkabel würde jedes angeschlossene Ding alle von allen anderen Dingen versendeten Netzwerkpakete sehen können.

Heute sind auch im billigsten Internet-Router schon Switches eingebaut. Das Möchtegern-Hacker-Notebook kann dadurch nur noch jene Pakete lesen, die für seine Hardwareadresse bestimmt sind.

Davon lässt sich das Elkement nicht aufhalten – und es hat ein Ziel: Der breiten Öffentlichkeit, also auch dem typischen Windows-Benutzer, zu ermöglichen, die Kommunikation seiner Dinge mitzuverfolgen.

Die Lösung besteht darin, das Ding zu zwingen, mit Dem Internet nur über das Hacker-Notebook zu kommunizieren. Das Notebook wird zum Router; das Ding befindet sich also hinter einer Kaskade von zwei Routern: 1) dem Hacker-Notebook und 2) dem eigentlichen Internet-Router.

Dafür verwenden wir ein wenig bekanntes und wahrscheinlich in Expertenkreisen belächeltes Feature: Die Internetverbindungsfreigabe in Windows.

Ein Router hat mehr als eine Netzwerkkarte und verbindet mindestens zwei (adressmäßig unterschiedliche) Netzwerke.

Ein typisches Laptop hat diese beiden Netzwerkadapter!

  1. WLAN – zur Verbindung mit dem Internet-/WLAN-Router
  2. LAN – eine RJ45-Buchse für ein Ethernetkabel.

(2) wird nun verwendet, um das Ding anzuschließen, bzw. genauer gesagt, ein kleines privates Netzwerk aufzubauen, das nur das Ding enthält. Dafür wird ein ausgekreuztes Kabel verwendet.

Zusätzlich muss eine Sniffer-Software installiert werden, wie z.B. das frei verfügbare  Wireshark.

Ziel ist der folgende Aufbau – in der Darstellung werden der Standard-IP-Adressbereich der Verbindungsfreigabe verwendet (192.168.137.x) und 192.168.0.x als typisches internes Netz:

|     Ding    |       |      Laptop-Router      |      |Internet-Router
|     LAN     |-cross-|     LAN     |    WLAN   |-WLAN-|Internes LAN
|192.168.137.2|       |192.168.137.1|192.168.0.2|      |192.168.0.1

Konfiguration:

  • Eigenschaften des WLAN-Adapters suchen, in Windows 7 unter:
    Systemsteuerung
    –Netzwerk und Internet
    —-Netzwerkstatus und -aufgaben
    ——Adaptereinstellungen ändern
  • In den Eigenschaften des WLAN-Adapters auf Freigabe klicken und anhaken der Option: Anderen Benutzern im Netzwerk gestatten die Internetverbindung dieses Computers zu verwenden.
  • In einem Dropdown-Menü werden alle anderen Adapter außer dem zu teilenden angezeigt – hier wird die Lokale Internetverbindung als privates Netzwerk ausgewählt:

  • Der LAN-Anschluss des Dinges wird über das Crossover-Kabel mit der LAN-Buchse des Laptops verbunden.
  • Wenn das Gerät DHCP verwendet, erhält es automatisch eine IP-Adress aus dem Bereich 192.168.137.x. Wenn nicht, muss eine statische Adresse mit x ungleich 1 vergeben werden. Das Router-Notebook erhält die Adresse 192.168.137.1 und ist  DHCP-Server, DNS-Server, und Default Gateway.
  • Wireshark starten, klick auf Capture, Interfaces…, Auswahl des Adapters mit der Adresse 192.168.137.1 … und … Start!

Ein harmloses Praxisbeispiel – der Blu-Ray-Player der Siedler:

Das Ding erhält eine Adresse über DHCP – nur das letzte Paket (‚acknowledge‘) ist hier gezeigt – und versucht dann die MAC-(Hardware-)Adresse für den Router-Computer 192.168.137.1 zu finden – ein DELL-Laptop. Benötigt wird nämlich ein DNS-Server, um einen offenbar hart-kodierten Namen aufzulösen: liveupdate.blurayplayer.samsung.com.

Gut, dass die Kommunikation nicht verschlüsselt ist – sonst könnten wir nicht so einfach mithören.

Mit der Wireshark-Option Follow TCP stream sieht man noch besser, was jetzt passiert:

Der Player ruft die Seite liveupdate.jsp über HTTP auf, schickt die Typenbezeichnung, eine Versionsnummer und den Standort ‚EU‘. Samsung sieht diese Anfrage von der nicht wirklich anonymen IP-Adresse der Siedler in einem kleinen mitteleuropäischen Land kommend.

Samsung antwortet mit [NO UPDATE] und einem Cookie, das bereits vor 3,5 Jahren abgelaufen ist.

Und die Moral aus dieser Geschichte? Nicht, dass es überraschend wäre, dass Geräte versuchen, sich automatisch Updates von einem Server im Internet zu holen. Computer machen das seit ‚ewigen Zeiten‘ – allerdings mit dem ‚feinen‘ Unterschied, dass man hier das Updateverhalten als Besitzer 1) prinzipiell kontrollieren könnte und 2) auch das Mitverfolgen sehr viel einfacher wäre.

Unser Vorschlag für Was gibt es Neues: Das Ding der Woche an seinem Internetraffic zu erkennen!