Wer sagt, dass Schatzsuchen nur was für Abenteurer mit Hut und Peitsche sind? Wir haben mit nichts weiter als einem Terminal, einem Linux-System und einem Hauch Forschergeist eine echte digitale Zeitkapsel geöffnet – willkommen zur ausführlichen Analyse einer BIERCard. Was es damit auf sich hat, wie wir tief in die Geheimnisse eingestiegen sind und warum selbst Root-Zugriff manchmal nicht reicht, erfährst du jetzt.
Was ist eine BIERCard überhaupt?
Auf den ersten Blick scheint es sich um eine typische Terminal-Steuerkarte zu handeln, wie man sie z. B. aus Kiosksystemen kennt. Auffällig waren allerdings zwei CompactFlash-Karten: eine mit der Aufschrift „Produktiv“ (4 GB) und eine mit der Aufschrift „Backup“ (2 GB).
Beide Karten stecken auf einer speziellen Trägerplatine, die über IDE, mehrere serielle Schnittstellen (COM1–3) und USB mit dem Mainboard verbunden ist. Zentral auf der Platine sitzt ein ATmega32A – das Gehirn hinter der BIERCard.
Die Backup-Karte heben wir uns für ein späteres Kapitel auf – denn die Produktiv-Karte hatte es bereits in sich.
Die Produktivkarte unter der Lupe
Nach dem Einhängen (mount) zeigte lsblk, dass die Karte drei Partitionen enthält:
/dev/sdb1: vermutlich das Hauptsystem (Adminmodus)/dev/sdb2: vermutlich der Kundenmodus (Kioskansicht)/dev/sdb3: eine eigenständige Datenpartition, vermutlich zur Konfiguration und Sicherung
Ein Blick in /mnt/cf3 (also Partition 3) bestätigte unsere Annahme: Dort fanden sich Dateien wie biercard_version, copies, generate_from sowie ein ominöser oldimage. Alles deutet auf eine kontrollierte Verwaltung und Synchronisierung von Konfigurationen hin.
Zwei Welten auf einer Karte
Was sofort ins Auge fiel: Das System ist in mindestens zwei Modi aufgeteilt. Im Adminmodus (sdb1) gibt es klassische Systemzugriffe, Root-Zugriff, Logging und diverse Analysewerkzeuge. Im Kundenmodus (sdb2) hingegen scheint alles auf eine abgesicherte Anzeige reduziert – vermutlich ein Kiosksystem, das ohne direkte Eingriffe laufen kann.
Monitorerkennung und Grafik-Setup
Mit der PNY Quadro NVS 290 fiel der letzte Puzzlestein an seinen Platz: Zwei Monitore für den Kunden – robust, stromsparend, professionell. Keine Gaming-Karte, kein Schnickschnack – sondern ein Werkzeug, geschaffen für den Dauerbetrieb. Die parallele Anzeige von Quoten, Spielinformationen und Werbeanimationen war kein Zufall, sondern System.
Netzwerk und Peripherie – alles fest verdrahtet
Auch die Netzwerkverbindung ist hart kodiert: Die Datei iBet.conf nennt eine feste IP 192.168.100.11. Die Konfiguration erfolgt also zentral – vermutlich über ein internes Servernetzwerk. Auch der verwendete Drucker und Leser sind fix:
cashAcceptorDevice=/dev/ttyS2
receiptPrinterName=/dev/lp0
barcodeReaderDevice=/dev/ttyS0
chipCardReaderName="SCM SCR 333"
Automatenskripte mit Retro-Charme
Eines der ersten Highlights: das Skript automatHelper.sh. Es prüft Logdateien, mountet gegebenenfalls Konfigurationspartitionen, analysiert Systemzustände und zeigt beim Systemstart passende Screens an. Es wirkt wie der zentrale Boot-Dispatcher.
Das zweite wichtige Skript: copy_ibet_conf.sh. Es kopiert iBet.conf auf eine spezielle Partition und sichert so zentrale Konfigurationsdaten – automatisiert, robust und mit viel Shell-Magie:
mount "/dev/${AUTOMAT_DEVICE}${AUTOMAT_CONFIG_PARTITION_DEVICE_NO}" ${CONFIG_MNT}
cp /etc/automat/iDev/iBet.conf "${CONFIG_MNT}/copies/etc/automat/iDev/iBet.conf"
Ein drittes Skript – reset_barcode_scanner.sh – verrät: Selbst die Scannerhardware konnte aus dem Terminal heraus neu initialisiert werden.
Kryptografie, bitte einmal unknackbar
Die Datei iBet.conf enthält nicht nur einfache Konfigurationsdaten, sondern auch einen über 3000 Zeichen langen RSA-Block im DER-Format. Was wie ein einfacher Header aussieht, entpuppt sich als massiver Public Key mit fest kodierten Parametern:
id=308204BD020100300D0609...
Obwohl es sich „nur“ um einen Public Key handelt, suggeriert die Verwendung: Hier wird nichts dem Zufall überlassen. Eine Kombination aus agencyId, companyId und serverId lässt vermuten, dass die Terminals zentral ausgerollt und individuell verschlüsselt aktiviert werden.
Ein Reverse Engineering wäre selbst mit Root-Zugriff keine triviale Aufgabe – besonders da keine privaten Schlüssel auffindbar sind. Wir sprechen hier definitiv von industriellem Anspruch.
Die BIERCard im Code
Mittels strings auf den Binaries automat und biertool fanden wir klare Bezüge zu einer C++-Klasse BierCard. Methoden wie BierCard::sendCmd() oder BierCard::switch2rescue() lassen vermuten, dass die Firmware modular auf das Umschalten zwischen Haupt- und Backup-System vorbereitet ist – vermutlich per seriellem Trigger über den ATmega:
BierCard::ReturnCode BierCard::switch2rescue()
Ein eindeutiger Cliffhanger für unser zukünftiges Kapitel, in dem wir uns die „Backup“-Karte vornehmen werden.
Besonders nerdig: Die Code-Pfade zeigen auf ../ibet/cashacceptor/biercard.cpp, was einen vollständigen C++-Quelltext vermuten lässt – leider natürlich nur als kompiliertes Binär vorliegend.
Die Fundstücke im Detail
Zu den spannendsten Fundstücken der Produktiv-Karte gehören:
automat– Hauptsteuerprogramm mit GUI-Funktionalität (vermutlich Qt-basiert)biertool– Kommandozeilentool zur Kommunikation mit der BIERCard- Diverse Shellskripte zur Erkennung, Konfiguration und Reboot-Steuerung
- Tools zur Barcodescanner-, Chipkarten- und Cashbox-Verwaltung
- Feste Schnittstellen:
/dev/ttyS0,/dev/ttyS2und ein ChipkartenleserSCM SCR 333 - Automatisiertes Speichern und Aktualisieren von Konfigurationen
- Netzwerkbindung an eine feste Adresse
192.168.100.11 - Hinweise auf Qt-basierte Architektur in den Binärdaten
- Eine 3. Partition für Sicherungskopien und Versionsverwaltung (
/mnt/cf3) - Eine Versionsdatei
biercard_versionmit Release-Informationen - Hinweise auf Debug- und Entwicklerfunktionen (u. a.
elousbd,set_ibet_conf_option.sh,biertool,copy_config_files.sh)
Wer tiefer ins Thema Reverse Engineering alter Hardware eintauchen möchte, dem sei RetroReversing.com empfohlen – dort findest du fundierte Analysen und Community-Wissen zu klassischen Embedded-Systemen, Konsolen und Industrieelektronik.
Fazit: Reverse Engineering einer CF-Card mit Überraschungen
Die BIERCard entpuppt sich als modularer Embedded-Systemträger mit Sicherheitsfokus, Wartungsskripten und flexibler Systemstruktur – perfekt für Industrieumgebungen, aber auch für Nerds wie uns ein echter Schatz.
Ob wir das System je vollständig knacken? Vielleicht. Aber bis dahin bleibt uns ein würdiger Cliffhanger: BierCard::switch2rescue() – was passiert wohl, wenn wir die Backup-Karte aktivieren?
Stay tuned für Teil 2.
Lesetipp: Was wurde aus XML und XSLT? – weitere Technikarchäologie auf prokrastinerd.de
Affiliate-Tipp*: Wer ähnliche alte Systeme analysieren will, braucht solide Hardware – z. B. dieses CF-Kartenlesegerät* (bezahlter Link) oder einen günstigen USB-Seriell-Adapter* (bezahlter Link) für alte Steuerplatinen.