Posts mit dem Label Software werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Software werden angezeigt. Alle Posts anzeigen

Mittwoch, 15. Januar 2014

Reverse Engineering einer Kaffeemaschine

Meine aktuelle Projektarbeit befasst sich mit dem Innenleben eines Kaffee Vollautomaten der Firma Severin, Genauer gesagt der KV8023 S2+. Ziel dieser Arbeit ist es die Kommunikation zwischen Bedienpanel und Kaffeemaschine zu analysieren und gegebenenfalls so zu manipulieren, dass die Maschine über einen Mikrocontroller ferngesteuert werden kann. Dazu habe ich die Maschine erst einmal geöffnet und zwei Flachbaugrupppen gefunden. Eine ist Netzteil, Netzspannung-Schaltung und Controller für die eigentliche Maschine, die andere ist ein Bedienpanel mit einem eigenen ATmega1284P an board. Das Flachbandkabel, mit dem beide Platinen verbunden sind deutet darauf hin, dass die Steuerung der Maschine über ein Bussystem gelöst ist. Wo die eigentliche Intelligenz steckt ist mit eines der ersten Punkte, die es herauszufinden gibt.
Geöffneter Vollautomat Controller des Bedienpanels

Nach einer genaueren Betrachtung des Panels habe ich die Verbindungen der Bauteile in einem Plan aufgestellt. Dieser Plan zeigt alle Steckverbinder, das Displayinterface und die, an den Controller angeschlossene Hardware (Taster, Drehencoder und LED). Eine Erweiterung des Verbindungskabels mittels eines Schneidklemmsteckers erzeugt den Zugriff auf den vermeindlichen Bus. Dieses Kabel ist verbunden mit dem SPI Interface des Controllers, mit dem Display (hier fehlt noch die Belegung der Kontakte).

Ein kurzer Test mit dem Logic Analyser zeigt, dass auf dem SPI Bus tatsächlich reger Betrieb herrscht. Nach einigen Kaffees habe ich jetzt mehrere Minuten Kommunikation mitgeschnitten und werde im nächsten Schritt versuchen die Telegramme auszuwerten und zuzuordnen.

Mitschnitt zweier Telegramme der Buskommunikation


Die Übertragung startet zyklisch alle 0,126 Sekunden, es werden 10 Byte über den Bus mit Enable Low (An) übermittelt. Auf diese Bytes gibt es eine Antwort auf der MISO Leitung. Darauf folgen 540 Bytes ohne Antwort, bei denen der Enable des Flachbandkabels konstant auf High (Aus) liegt. Es liegt nahe, dass es sich hierbei um Daten für das Display handelt, denn auch dorthin ist MOSI des Controllers verbunden. Mit einem Arduino und einem kleinen Sketch kann ich also nächste Woche die 10 Byte Telegramme abfangen und zur Auswertung aussortieren. Dadurch reduziert sich die Menge der Telegramme auf ein Minimum und die Entschlüsselung ebendieser wird hoffentlich leichter fallen.

Um eine Fernsteuerung durchzuführen, muss die Kommunikationsverbindung unterbrochen werden, da sonst das Bedienpanel in die automatisierten Telegramme zusätzliche Telegramme schicken würde. Gleichzeitig muss dem Bedienpanel die Antwort der Maschine vorgespielt werden, da sonst ein Fehler angezeigt wird. Wie sich die Anzeige des Displays manipulieren lässt habe ich mir noch nicht überlegt, da der Enable Eingang des Displays nicht nach Außen geführt wird.

Samstag, 4. Januar 2014

Sicherheit im Internet der Dinge (Fonera mit SSL)

Sollte es einmal so weit sein, dass sogar der Kühlschrank mit der Heizung und der Waschmaschine spricht um ein möglichst Strom effizientes Miteinander zu gewährleisten, wird das aller Wahrscheinlichkeit nach über Funk passieren. Doch eine Kommunikation über Funk ist alles andere als sicher und so muss der Sicherheitsaspekt von Beginn an in die Entwicklung internetfähiger Haushaltsartikel mit einfließen. Ich experimentiere zur Zeit mit einem kleinen Linuxboard, das unter anderem eine WLAN-Schnittstelle hat.

Sollte dieses Board einmal zum steuern eines Haushaltsgegenstandes verwendet werden, bleibt zu überlegen, wie die Kommunikation von der Kontrollstelle zum Board gesichert werden kann. Eine Möglichkeit wäre das erstellen eines abgeschlossenen WiFi Netzwerks das nur zur Steuerung der Geräte dient und nicht mit dem Internet verbunden ist. Das führt allerdings nicht dazu, dass das Gerät im Internet erreichbar ist, was unserem Ziel nicht gerecht wird. Eine zweite Möglichkeit ist eine normale HTTP Verbindung mit HTTP Auth zu implementieren. Somit ist schon mal eine einfache Sicherheitsebene dazugekommen und das Gerät steht nicht mehr jedem Internetteilnehmer zur Verfügung. Die nächste Schicht wäre eine Verschlüsselte Kommunikation über HTTPS. Dadurch wird das Passwort nicht mehr sichtbar übertragen und einem eventuellen Mithörer bleibt der Anmeldeprozess verborgen. Ein Passwort ist allerdings selten sicher, wenn man dem Benutzer keine vorgegebenen Grenzen setzt. Deshalb bietet sich die Kombination aus Passwort und Zertifikatslogin an. Dabei besitzt der Client ein Public / Private Schlüsselpaar und ein Passwort mit dem das Zertifikat im Client geöffnet werden kann.

Um eine SSL Verbindung über HTTPS zur Fonera zu ermöglichen, benötigt man einen anderen Webserver als den Busybox httpd. Ich habe mich für den mini-httpd entschieden, der bringt auch die Erweiterung für SLL nämlich matrixssl mit. Im OpenWrt Wiki findet sich eine gute Anleitung, wie man mini-httpd mit SSL durchführt. Anders als in der Anleitung angegeben muss allerdings das Paket mini-httpd-matrixssl anstelle von mini-httpd-openssl installiert werden. Ansonsten kann der Anleitung gefolgt werden. Jetzt steht auf der Fonera nur noch  HTTPS mit einem eigenen Zertifikat zur Verfügung. Der nächste Schritt ist nun ein Frontend zu Anmeldung auf der Fonera zu programmieren.

Montag, 25. November 2013

GPIOs der Fonera

Heute habe ich ein wenig mit den GPIOs der Fonera gespielt. Um später das SoC der Fonera zum Steueren von anderen Hardwareprojekten zu verwenden, habe ich die vier am einfachsten zu erreichenden GPIO Kontakte mit einer Leitung verbunden. Dabei habe ich gleich noch die Kondensatoren nach Masse entfernt. Die bildeten mit dem Widerstand zusammen einen Tiefpass am Eingang und verhindern somit die Signalintegrität bei schnellen Schaltvorgängen.

Fonera mit LED an GPIO Ports

Die 8 IO Ports der Fonera sind teilweise schon von Hardware belegt, es bleiben jedoch fünf freie Ports übrig, die beliebig verwendet werden können. Vier dieser Kontakte sind auf den Steckplatz für SW1 geführt. Für die kleinen Experimente habe ich auch nur diese vier verbunden. Wenn komplexere Aufgaben gesteuert werden sollen, kann auch der serielle Port  der Fonera verwendet werden um mit einer Mikrocontroller Schaltung zu kommunizieren.

GPIO Description
0    TP3
1    pin 5 of SW1
2    WLAN LED
3    pin 1 of SW1
4    pin 2 of SW1
5    RESET (!)
6    RESET button
7    pin 6 of SW1

Zum Steuern der GPIOs kann das Kommandozeilentool gpioctl verwendet werden. Dieses ist standardmäßig bei der openWRT Installation mit installiert worden und kann zum Beispiel über die SSH Verbindung ausgeführt werden.

gpioctl dirout 3
gpioctl set 3

Dadurch wird der Port 3 als Ausgang definiert und eingeschaltet. Der erste Pin von SW1 ist jetzt auf +3,3V. Nachdem die Funktion der GPIOs funktioniert, wenden wir uns im nächsten Artikel der Software zu und schauen, wie die Fonera dazu gebracht werden kann als Gateway für eben diese Schaltung zu agieren.

Donnerstag, 14. November 2013

Handy -> Bluetooth -> RGB-LED [Teil 1: Protokoll]

Die Vernetzung von Haushaltsgegenständen ist heutzutage nicht mehr weg zu denken. Das so genannte Internet der Dinge wird in den nächsten Jahren immer mehr Geräte miteinander vernetzen und untereinander kommunizieren lassen. Ein kleiner Teil davon wird die Wohnraumbeleuchtung sein. RGB-LEDs sind mittlerweile günstig auf dem Markt erhältlich und werden konventionelle Lampen ablösen. Dieser Artikel beschreibt Überlegungen für die Steuerung einer RGB-LED über ein serielles Protokoll.

Für dieses Projekt wird eine RGB-LED und der Mikrocontroller ATtiny2313A verwendet. Das Bluetooth Modul HC-05 bildet die Schnittstelle zwischen Beleuchtungseinheit und Steuerungssoftware auf Andorid Basis.

Um die Übertragung von Helligkeitswerten mit möglichst wenig Aufwand zu realisieren, wird ein Protokoll erstellt, dass aus einem 4 Byte großem Block besteht. Der Block beginnt mit einem Null Byte (0x00), darauf folgen die Helligkeitswerte für Rot, Grün und Blau. Das Nullbyte dient zur Synchronisation. Die sonstigen Bytes dienen zum Übertragen von Kommandos. Somit ist das Protokoll am Ende bei Bedarf erweiterbar, da erst nach der Synchronisation wieder mit den Farbwerten gerechnet wird.
Telegramm zur Steuerung der Lampe
Die Sonstigen Bytes können für Steuerbefehle verwendet werden. Um erneut eine Farbe zu übertragen muss das Byte 0x00 übertragen werden und danach die Bytes für Rot, Grün und Blau. So lässt sich zum Beispiel der Status der Lampe mit dem Code 0x01 abfragen, der aktuelle Batteriezustand mit 0x02 und so weiter. Die Befehle hier sind erst einmal nur als Beispiel gedacht, um die Grundfunktionen zu implementieren.
Steuerbefehle
Als nächstes wird der Aufbau der Hardware folgen.

Dienstag, 12. November 2013

[WIP] Ein neuer Versuch mit ASURO

Ich bearbeite für das Studium eine Projektarbeit für die Roboterplattform ASURO. Den Verlauf der Entwicklung werde ich hier dokumentieren. Ziel ist es ein Betriebssystem zu erstellen, dass die Werte der sechs Sensoren kontinuierlich ermittelt und sie für den Programmierer aufbereitet. Dazu gehört neben der reinen Speicherung der Messwerte eine, abhängig vom Sensor, kontinuierliche Verarbeitung. Deshalb habe ich mich in letzter Zeit intensiv mit der Wandlung von analogen Spannungen zu digitalen Werten beschäftigt; konkret mit der Wandlung von Spannungen eines IR-Transistors an einem ATmega8.