 Hier im CCC-Umfeld beschäftigen wir uns ja über die Jahre immer wieder mit ungefähr den gleichen Themen, aber immer wieder aus einer etwas anderen Perspektive oder auf einem etwas höheren Niveau. Und gerade das Thema elektronische Bezahlsysteme bietet sehr viel Potenzial zum Lachen und zum Weinen. In der Vergangenheit gab es zum Beispiel beim 29 C3 schon mal einen Vortrag über Mensa-Karten und wie man es schafft, dass da plötzlich Tausende von Euros draufspornen. Und vor zwei Jahren gab es beim 34 C3 auch den Ladesäulentalk und auch der ist thematisch so ein bisschen verwandt mit dem, was ihr jetzt hört. Genau, Jonas Streib, Janis Streib ist unser Speaker, er ist Student und erzählt euch jetzt live von der Front, wie das aussieht mit diesen elektronischen Bezahlsystemen. Und deswegen bitte ich euch um einen ganz herzlichen Applaus für Janis und wünsche euch ganz viel Spaß mit ihm. Ja, wer in einer Hochschule studiert oder in einem großen Unternehmen arbeitet, kennt das sicher. Es gibt Automaten und man kann, wenn man Durst oder Hunger hat, sich an solchen Automaten einen mehr oder weniger gesunden Snack oder Getränk kaufen und diesen dann mit einem, mit der Studentenausweis oder mit dem Mitarbeiterausweis bezahlen. Diese Systeme begegnet einen häufig dann auch in der Kantine oder in der Mensa oder in der Cafeteria. Und man kann, man lädt diese Karten dann an solchen Auflade-Terminals wieder auf, also aufwärtern. Manchmal gibt es dann auch noch solche Status-Terminals. Auf solchen Terminals kann man dann sehen, wie viel Geld man auf der Karte hat und was man in letzter Zeit so gebucht hat. Die Architektur bei diesen Systemen sieht häufig irgendwie so aus. Wir haben unsere Vending-Maschinen, in dem Schankauer nennt man diese häufig auch Vending-Maschinen-Controller. Und dieser kommuniziert über MDB, das ist ein serielles Protokoll mit dem Vending-Reader. Dieser Vending-Reader wickelt die Bezahlung ab und kommuniziert dabei mit einem Backend-Ubalid-TPS, wo dann die Buchungen durchgeführt werden, also bei diesem cloudbasierten System. So ein Bezahlvorgang sieht dann ungefähr so aus, man hält die Karte an den Automaten, der Automaten an den Vending-Reader. Der Vending-Reader holt Informationen über den Kunden, wie zum Beispiel, was ist der Kartenstand. Manchmal auch solche Dinge wie Date of Birth, also im Geburtstag, wenn man die alkoholische Getränke verkauft. Der Nutzer wählt dann das Produkt aus, der Preis wird nachgeschoben und schließlich erfolgt der Verkaufsprozess mit dem Update des Kontostands in der Cloud. Und der Nutzer erhält letztlich das Produkt. Ja, wie bin ich dazu gekommen? Eigentlich sollte ich für solche Waschmaschinenabwärter eine Integration für ein neues Kartensystem bauen. Das ist dieses Gerät, dieses mit dem roten Feld und dem zwei Zeilen-Display unten links. Aber wie das nun so ist als Hacker, wenn man ein unbekanntes Gerät mit Ethernet-Anschluss vor sich liegen hat, man macht erst mal einen Portscanner. Und da hatte ich dann schon so eine erste Überraschung erlebt. Da erscheint nämlich ein VNC-Server auf den Kisten zu laufen. Das ist offenbar ein VNC. Und wenn wir da mal in der Export-DB nachschauen, finden wir unter anderem einen Null-Authentication-Bypass, der womöglich auf die Version passen könnte. Naja, ausprobiert, sag, interessant, läuft ein Windows CE drauf. Wir können hier wunderbar an diesem Desktop auch ein wenig explorieren. Es gibt einen vollwertigen Explorer und wir können uns da mal ein bisschen umschauen. Genauso können wir der Software beim Arbeiten zuschauen. Wir sehen, wie die heißt offensichtlich die CS Core. Naja, somit ergibt sich für unser System folgendes Bild. Wir haben durch Explorieren, habe ich bereits gefunden, sind dann offensichtlich zwei Datenbanken auf diesem Vending Reader. Zum einen die Static DB für Statische Konfiguration, zum anderen die Work DB. Da werden wohl temporäre Arbeitsdaten abgespeichert. Diese Datenbanken haben relativ wenig erkennbare Struktur von außen. Es ist also davon auszugehen, dass die irgendeine Form verschüsselt sind. Und sie lassen sich auch nicht mit irgendeinem gängigen Datenbank-Browser öffnen. Gut, spannend, meine Neugie war somit geweckt. Wir haben hier also einen, sodass ich noch den VNC als Vektor. Und ich habe mich daraufhin weiter beschäftigt, allerdings ausschließlich mit dem Vending Reader weder mit dem Kartensystem, was dahinter verwendet wird, also was meistens dann MyFair oder Desfire ist, noch mit dem Vending Machine Controller, also den Getränkeautomaten. Ich habe also begonnen, eine oberflächliche Analyse durchzuführen. Es wäre nämlich eigentlich auch erst mal offensichtlich spannend, was denn auf diesem HTPS-Kanal so läuft. Klar, einfaches Setup. Wir machen ein Mandemiddle Gateway. Dahin läuft eine Reverse Proxy. Wir loggen die Request mit und schicken die Daten weiter an den Backend-Server. Um ein bisschen zu schauen, was wir dafür Verantwortung brauchen, lohnt sich es einmal mit Wire Shark mitzuschneiden, was denn überhaupt gesprochen wird. Und wer jetzt schon mit scharfem Augehinschall erkennt, ist wohl ein SSLV2-Kleintello. Und wir bekommen außerdem die unterstützte Cypher-Liste, also die unterstützte Liste der kryptografischen Verfahren, die für diesen Henshake benutzt werden können. Wenn man sich die mal nochmal genauer anschaut, dann stellt man auch fest, die sind schon ganz schön antiquiert. Unter anderem finde ich sehr exotisch SSLV-RC4 Export 40 MD5. Das habe ich sonst auch noch nie in freier Wildbahn gesehen. Damit haben wir aber ein kleines Problem für unseren Bittenproxy. Denn es gibt erstaunlich wenige Implementationen, die aktuell noch SSLV2 und RC4 oder Triple Desk können. Und weil ich mir nicht jetzt umständlich ein altes Open SSL mit sonstigen Paketen zusammenlinken wollte, habe ich mich ein wenig umgeschaut, wie man das dann auch einfach hinkriegen könnte. Und die Lösung war Java 8. Tatsächlich kann man, wenn man in Java 8 lang genug drauf tritt, noch SSLV2 Kleintello und RC4 Triple Desk anmachen. Also eignen Reversproxy geschrieben und ausprobiert. Eigentlich wollte ich in diesem Video einfach nur ausprobieren, funktioniert der Henshake. Wir sehen hier jetzt mein Tested-Up, mein Laptop dient als Proxy. Und Zack! Da haben wir schon Request. Das war so ein bisschen unerwartet, weil ich eigentlich noch nicht das gefälschte Zertifikat auf dem System platziert habe vorhin. Heißt offensichtlich passiert hier keine keinerlei Zertifikatsverifizierung. Cool, brauchen weniger Arbeit, fette Lücke gefunden. Können wir uns mal die APIS genauer anschauen. Ja, gerade eben schon in dem Video gesehen hat, es gibt zwei APN Points. Der erste APN Point ist die sogenannte Heartbeat API. Die wird so ziemlich für alles benutzt, was mit der Konfiguration der Vending Reader in Zusammenhang steht. Zum Beispiel stellt sie die Static-Debate bereit für die Geräte, also sprich die Konfiguration und wird im regelmäßigen Intervall und auch beim Start des Vending Readers einmal gepolt. Das ganze ist eine XML-API und sieht ungefähr so aus, das ist jetzt ein Request des Vending Readers. Der Vending Reader schickt so ein bisschen Metadaten über sich, was das für ein Gerät ist und schickt außerdem einen Scharprüfssumme an den Server von seiner Static-Debate. Ist noch keine Static-Debate auf dem Gerät, also ist es ein neues Gerät, frisch aus dem Karton, schickt er einfach eine Lehreprüfssumme und ich habe mir jetzt in der Request eine Weile angeschaut und festgestellt, irgendwie gibt es da nicht so eine richtige Authentifikation. Das Einzige, was sich wohl zwischen verschiedenen Vending Readers in diesem Request unterscheiden scheint, ist diese lustige Plattform-ID und irgendwo her kann man die doch bekannt vorn. Ja, richtig, wird beim Boot angezeigt. Also cool. Das heißt, über diese HardBit API können wir schon Static-Debate beantragen von beliebigen Geräten und wir müssen sie nur rebooten, um an diese ID zu kommen. Praktisch sind es zwar noch verschlüsselt, aber vielleicht können wir damit ja später noch was anfangen. Die zweite API, oder nein, erst mal hier die Übersicht, wir sehen also schon, wir haben diesen Provisionierungsfahrt gebrochen und offensichtlich auch die komplette Kommunikation im Backend, die können man komplett abfangen, ohne dass man irgendwie den Vending Reader manipulieren muss. Dann gibt es die zweite API, das ist die APIX. Ich habe keine Ahnung, für was das X stehen soll. Auf jeden Fall dient diese Schnittstelle zur Interaktion mit den Nutzerkonten. Zum Beispiel werden darüber die ganze Verkaufsprozesse geregelt. Da gibt es drei Stück. Das erste ist Vend, also ich verkaufe etwas. Das zweite ist Negative Vend, also ein negativer Kauf. Es wird verwendet, wenn man zum Beispiel Panflaschen an einem Panflaschenautomaten zurückgibt. Und dann gibt es Revalue. Das ist tatsächlich das Aufladen der Karte an einem Thermal gegen Bargeld oder gegen andere Bezahlungsmittel. Und da ist tatsächlich eine Authentifikation drin. Diese wird aus der StudyDB gelesen und ist tatsächlich pro Gerät verschieden. Das zweitere Dienst auch zur Interaktion mit dem Kontoverlauf. So kann man zum Beispiel darüber den Kontoverlauf des Nussers abrufen. Interessanterweise wird auch der Kontoverlauf angelegt darüber. Allerdings über den separaten Request. Das bedeutet, wenn eine normale Zahlung erfolgt, passiert erst mal kein Eintrag in der Konto-Historie. Das passiert in dem separaten Request. Und man muss nicht zwangsläufig was mit der Zahlung zu tun haben, wie sich später herausgestellt hat. Außerdem für die Freunde der Obskuren-API-Interface ist daran sicher, ob eine CSV-API, also sprich, da werden kommerseparierte Werte geschickt, die sich pro Anfangswert in der Länge unterscheiden dann und im Format. Mit den Informationen, die wir nun haben, also sprich, da wir aus Mende-Mittel-Angriff Authentifikationen haben können, können wir nun einfach mit meinem Laptop, die ein Revalue ausführen, man sieht, 100 Euro mehr auf dem Konto, problemlos, auch ohne dass der Nutzer irgendetwas tun musste. Ich musste nur einmal die Karten-ID herausfinden oder die Wallet-ID und kann dann mit einem API-Token in Freibuchungen durchführen. Praktisch, hier sieht man einmal einen Auszug aus dem Administration-Interface, was die Administratoren-Systems, also der Betreibelssystem sehen kann. Das ist jetzt aus einem anderen Zeitpunkt des Kontos, also nicht das eben von der Buchung, sondern das ist ein anderer Zeitpunkt. Wir sehen unten in der Mitte, uns unten links, sehen wir den Kontostand, das sind hier 722,76. Und oben sehen wir die Kontohistorie mit einer Wertstellung vom 13.06.2020 und es wurde irgendwie ein Betrag von 2.000 Euro gebucht. Es ist ein nettes Beispiel, wo man sieht, dass die Kontohistorie-Kaiserlei-Verbindung mit tatsächlich dem gebuchten Kontowert steht. Also sprich, man könnte zum Beispiel, wer jetzt Böses im Kopf hat, abitere Buchungen einfach in der History verstecken. Gut, nun wäre es eigentlich irgendwie noch spannend, wenn man versteht, wie diese Datenbanken funktionieren. Denn noch ist es uns nur möglich, Angriffe zu fahren, wenn wir ursprünglich ein Geheimnis, also dass die Authentifikationen gegen die AP durch einen Mindermittelangriff und durch Zugang zu einem solchen Vending wieder erschnüffelt haben. Dazu muss man jetzt quasi diese Software ein bisschen tiefer analysieren und mal mit einem beliebigen Reverse-Engineer tun, genauer anschauen. Dabei hat man ein bisschen das Problem, dass es ganze eine Windows PE-CE6-ARM executable ist. Das ist ein sehr exotisches Format, zu dem es quasi keine Debugger gibt und auch nur relativ wenige Disassembler können das korrekt darstellen. Ida kann das. Aber ich muss mich wohl vorerst mit einer statischen Allise zufrieden geben. Also ich kann nicht beobachten, wie die Datenbank entschlüsselt wird, sondern ich kann nur anschauen oder versuchen zu identifizieren, wie das funktioniert. Dazu geht es nun ein sehr praktisches Tool, das nennt sich Feind-Grypt. Das habe ich einfach mal auf die Beinerie geworfen. Das Feind-Grypt sucht in Beineries nach Spuren von bestimmten Verschlussungsverfahren. Zum Beispiel sucht es hauptsächlich nach Konstanten, die ganz gern benutzt werden von verschiedenen Verschlussungsverfahren. In dem Fall haben wir eine S-Box oder eine inverse S-Box gefunden. Das ist doch sehr stark hin, dass hier wohl ein AES-Vernoint wird. Und wenn man jetzt schaut, wo diese Werte benutzt werden, kann man dann herausfinden, wo diese Verschlüsselung stattfindet. Allerdings sollten wir dazu etwas verstehen, wie AES funktioniert. Dazu ein kurzer Disclaimer. Auch wenn AES relativ einfach aussieht und es jetzt mal so, vielleicht auch ganz lustig wäre das zu bauen, aber eher eine schlechte Idee, das In-Production-Code einzusetzen. So ein Hinweis. Aber AES ist prinzipiell relativ einfach. Das ist jetzt natürlich eine starke Vereinfachung. Aber vom Prinzip besteht AES nur daraus, dass wir unseren Key nehmen. Daraus sehr viele Keys machen. Und diesen in mehreren Runden auf unseren zu verschüsselten Block X on. Und zwischendurch immer wieder mal diese linearen Transformationen durchführen. Wir haben jetzt Subbytes, ShiftShows und MixColumns. Das sorgt ein bisschen für Diffusionen da drin. Und in der letzten Runde lassen wir eines dieser Diffusionsschritte weg und haben am Ende unsere 128-Bit verschlüsselte Daten. Wir haben jetzt unsere Verschlüsselungsfunktion identifiziert. Wir können auch anhand der Operationen ungefähr erkennen, dass es vermutlich auch AES-Verschlüsselung ist. Das sieht sehr nach aus nach AdWound Key und entsprechend diesen Transformationen. Ein wenig Monkey Patchen und können versuchen, den Key zu extrahieren. Praktischerweise gibt es in dieser Software eine Lockfunktion, die auch Hex-Dampen kann. Das ist ziemlich cool, denn damit können wir, sobald wir ein Key den Key identifiziert haben, diesen entsprechenden Register Hex-Dampen und kriegen dann sauber im Lock-File einen schön formatierten Key. Das hat auch wunderbar funktioniert. Hier unten in der letzten Zeile hat man dann den extrahierten Schlüssel. Nur irgendwie hat er nie funktioniert. Egal, welche AES-Implimentation ich benutzt habe, egal, welche Varianten ich eingesetzt habe, ich habe es irgendwie nie geschafft, irgendwas Sinnvolles aus dieser Technik herauszufinden. Irgendwie doof. In dieser Stelle habe ich quasi aufgegeben und gedacht, okay, das war es damit. Ich werde das wohl nicht herausfinden, wie diese Verschlüsselung funktioniert. Doch dann kam irgendwann mal, habe ich irgendwann mal mit einem Atmen des Systems gesprochen und der Mann hat dann irgendwas am Rande erwähnt von wegen, ah, wir haben da so ein Entschlüsselungstool, damit können wir alle Datenbanken von allen Geräten öffnen, auch von den Alten, funktioniert super. Da bin ich dann ein wenig hellhörig. Es hört sich nämlich ein bisschen so an, als ob da irgendwie überall dieselben Keys benutzt werden. Na ja, gut. Schauen wir mal, wir haben jetzt aber praktisch auch dieses Tool und dieses Tool, das können wir jetzt debanken, weil das ist X86, das ist eine halbwegs verbreitete Architektur auf einem halbwegs verbreiteten Betriebssystem. Da können wir mit Ida die Bagger reingehen. Nun gut, schrittweise gehen wir jetzt einmal durch, was hier kaputt sein könnte. Als erstes schauen wir uns die Key Expansion an. Das ist jener Schritt, der aus dem einen 256-Bit Keys ganz viele Keys macht. Und dort habe ich einmal beobachtet, wie diese Expansion funktioniert. Was wir jetzt gleich sehen, ist ein Video aus Ida, in dem ich einmal mir diese Variable anschau, in dem der Expansion Key gespeichert wird und jede Runde der Expansion Skript einmal durchsteppe und dort sollten wir eigentlich sehen, wie es diese Variable füllt. Und man sieht auch, das ist ein relativ großes Feld an Zahlen, die da gefüllt werden. Wir sehen so, ja, es füllt so langsam, geht voran. Jetzt fängt er aber wieder von vorne an. Komisch. Es geht eine Weile so, bis er fertig ist. Und dann steht er am Ende, steht am Ende ein paar Variablen, ein paar, irgendwas, ein paar Daten da und ganz viele Nullen. Das heißt, irgendwie unsere Key und die andere Expansion macht irgendwie was anderes, wie die andere Key Expansion, wie die übliche Key Expansion. Wir bekommen aus einem Key einen anderen Key und ganz viele Nullen. Wenn man das jetzt wieder in unsere Grafik von vorhin einsetzt, also wir nehmen die ganzen Nullen und den Key 1, dann zerfällt dieser ganze Prozess ein bisschen. Diese Xors kürzen sich weg, wie darauf liegen. Das ist ein Prinzip, der nur noch eine einfache Xor-Fischsisselung mit einem festen Schlüssel, wo man noch ein bisschen drin rumgerührt hat, mit reversiblen linearen Transformationen. Cool. Mit diesem Wissen können wir nun also aus einem bekannten Block in der Datenbank, zum Beispiel der Escolite, von dem wissen wir, dass dort relativ viele Null Padding Blöcke drin sind. Das heißt, wir suchen uns eine dieser Null Padding Blöcke. Wir haben das mit dem Dachverband vor, plus etwas lineare Transformationen und finden damit den Schlüssel raus. Praktisch. Nun können wir also über die Hard-Bit API mit bekannter BordID uns Freihaus eine Datenbank besorgen. Das braucht meistens einen kleinen Moment. Entschlüsseln und öffnen. Also sprich, wir haben jetzt Freihaus all unsere Konflikte, die wir brauchen. Wir müssen jetzt nicht mal mehr in die Hand nehmen. Das wäre praktisch. Also gut. Es ist so ziemlich alles kaputt, was ich mir angeschaut habe. Also, ja, dachte ich, wäre fertig. Ich gehe zu dem Atmen hin. Er zeigten das alles. Und da meinte irgendwann, hey, hier haben wir eine neue Version. Probiert die doch mal aus. Er drückt mir ein USB-Stay-Gerhand, meint so, ja, einfach einstecken, dann hier die Updates verteilt. Interessant. Offensichtlich also über USB-Stay. Diese Vending Reader haben auf der Rückseite einen USB-Port. Und da kann man einen USB-Stay einstecken. Ich habe das in eine Weile angeschaut und rausgefunden, okay, man kann da einen XML-Fall drauflegen. Eine sogenannte CMD.xml. Und wenn man dann eine Weile auch wieder in IDA sucht, findet man einen ziemlich großen Pasa. Und da gibt es noch so spannende Kommandos wie Copy-Fall oder Execute-Fall. Und die CMD.xml ist auch nicht signiert in irgendeiner Form. Also, wir können, ja, die Integrität dieser Datei wird nicht wirklich überprüft. Das heißt, ich konnte mir so eine kleine CMD.xml erzeugen. Wir auf ein USB-Stay packen. Das ist jetzt einmal auf der Rückseite des Vendingen wieder angeschlossen. Es braucht einen Moment, bis das ausführt. Und wenn wir den USB-Stay wieder anschließen, haben wir uns einmal ein paar nutzige Daten kopiert. Also, von dem USB-Stay, wenn wir sich die CSCorexl, unsere Datenbanken und somit auch alle Geheimnisse dabei können wir auch beliebig Code ausführen. recht praktisch. Spannender wird es dann noch, wenn man sieht, wenn man da genauer hinsieht, erkennt man das. Und das USB-Port vorne dran. Das hat man wohl bei der alten, das hat man wohl irgendwann mal behoben. Aber diese Version hängt bei uns jahrelang rum. Und läuft größtenteils mit derselben Software. Also, beunruhigend, kann man sagen. Gut, ich bin ein bisschen, ich habe es auch ein wenig Zeit. Das heißt, ich kann hier noch einmal etwas durchgehen, wie ich, wie man ein bisschen mit dieser Analyse gemacht hat. Bei der Analyse hat natürlich sehr geholfen, dass diese Datei, dass diese CSCore-Achse sehr ausführliche Lockdateien schreibt. Das ist sehr hilfreich. Hier sind sogar Funktionsnahmen drin. Und dadurch war es sehr einfach, Funktion zu identifizieren nachher in der Analyse. Und diese Strings, die können wir nämlich suchen in der Binary. Und dann wiederum auflösen, wo diese verwendet werden. Auf jeden Weise können wir entsprechend die Funktion identifizieren. So sieht dann so ein Paar aus, wenn man dann mal Funktionen findet. Entschuldigung. Genau. Jetzt habe ich noch ein kleines Problem beim Reverse-Engineen. Nämlich beim Monkey-Patchen, beim Herausfinden des Kies. Das ist doch für da so ein bisschen gegen Wert. Sie sagt nämlich, FS ist extra safe. Failed. Interessant ist extra safe. Kommt okay, offensichtlich prüft irgendwie diese Binary sich selber. Scheint wohl irgendwie CSC zu sein, weil man sieht, da vorne CSC innet. Aber wenn CSC, das kommt irgendwie auch komisch vor, das dient ja eigentlich eher zu Erkennung von Bitfehlern. Hier wird das aber vermutlich nicht mehr genutzt. Also ist extra safe, hört sich schon so ein bisschen so an. Das ist in mehrlei Hinsicht komisch. Denn das Ganze lässt sich durch eine relativ einfachen Patch aushebeln. Also man kann einfach sagen, der Check-Reton passt alles, ist korrekt. Oder man kann einfach, die Summe ist ja praktischerweise gegeben, die die Binary haben möchte, man kann einfach ausrechnen, was man da für eine Summe hat, braucht und so lange einfach an seinen Binary das so verändern, dass das wieder passt. Noch viel einfacher, der Pfad dieser Binary ist hardcoded. Das heißt, wenn wir einfach allen richtigen Ort die richtige Datei legen und irgendwo anders unsere gefakte Binary ausführen, dann funktioniert das auch wunderbar. Ja. Gut. Das wäre es soweit bei mir. Ich glaube, wir haben nur noch etwas Fragen für QA. Wir sehen hier noch mal etwas als Übersicht, die wir von den Lücken. Und nun freue ich mich auf eure Fragen und bedanke mich, dass ihr hier trotzdem Wärme im Zelt, die paar Minuten mit mir verbracht habt. Vielen herzlichen Dank, Janis, für diesen sehr aufschlussreichen und augenöffnenden und amusanten Talk. Wir haben jetzt noch einiges an Zeit für Fragen, also bestimmt eine Viertelstunde. Wenn ihr Fragen habt, dann kommt gerne hier zu unseren beiden lebenden Mikrofonständern, die jetzt Mikrofone hochhalten. Also wenn ihr was fragen wollt, wie ihr eure Getränkeautomaten hacken könnt oder zu anderen speziellen Themen, dann kommt gerne zu den beiden und stellt Fragen. Seid nicht schüchtern. Sehr gut. Ein Applaus für den ersten Frager. Bitte schön. Du hast das Wort. Was denkst du, wie man das am besten nutzen könnte um wirklich, ich glaube mal, gratis einzukaufen? Ja. Also um wirklich gratis einzukaufen. Man kann sich natürlich verschiedene Angriffsszenarien an der Stelle vorstellen. Also zum Beispiel, man schaut sich an, welche Nutzer gibt es im System. Man geht einmal die, man sucht, man brutforst sich ein paar IDs zusammen, erzeugt bei anderen Leuten, sagen wir mal, einen Cent Buchungen. Gerade bei so größeren Set-Ups-Parker sind ja ganz gerne mal 20.000 Karten unterwegs. Man bucht den allen vielleicht einen Cent ab, das merkt niemand und bucht sich selbst die Differenz auf. Das ist zum Beispiel möglich, sobald man irgendwie eines dieser Geheimnisse nicht viel mehr bekommen hat. Und sonst gibt es auch verschiedene Varianten, das zu verschleiern. Es kann natürlich immer sein, dass das dann auffällt, auftaucht, also im Gesamtsystem. Deswegen, aber man kann ja auch fremdbuchen, weil dann muss ja nichts authentifizieren beim Kauf. Vielen herzlichen Dank. Bitte die zweite Frage von dem Mikrofon hier vorne. Moin moin. Erstmal vielen Dank für den Talk. Du hast jetzt ja praktisch viel mit meinem Mittel gemacht. Das heißt, du hast den Netzwerk gehangen, wobei ich es auf eine externe IP gab in einem deiner Slides. Ich glaube beim M-Web-Scan hast du es rausgelassen, das ist noch mal sichtbar. Was mich interessiert ist von dem Transport von den Daten her, hast du getestet anhand der Daten, die von der Karte selber kommen, ob du damit im Backend irgendwas machen kannst. Sprich, wurde jetzt von der Karte selber bloß eine ID übertragen. Ich habe den Anfang des Talks nicht ganz mitbekommen. Ich bin ein bisschen später gekommen. Oder konntest du auch weitere Daten damit einschleusen? Also der Kartenleser ist als USB-Tastatur angeschlossen. Der gewünschte Sektor, den man entsprechend in diesem Kartenleser eingestellt hat eingegeben, das kann je nach Setup alles mögliche sein. Zum Beispiel eine verschlüsselten Blöcke auf der Karte kann der Inhalt übergeben werden und dann wird diese ID nur benutzt, um den Nutzer aufzulösen. Also über die Karte lässt sich da relativ wenig untermachen, weil das ist dann, ja, alles der Rest ist dann cloudbasiert dahinter. Also der nutzt generell auch bloß die ID von 20 kHz irgendwas oder 13,5,7. Oder irgendwie den Inhalt eines Blockes. Das kann man entsprechend einstellen, dann weiter vorne im Kartenleser. Okay, aber du hast da nicht getestet. Ich meine, wenn du innerhalb der Blöcke davon auch Daten genutzt werden, zum Beispiel bei einer etwas komplexeren Karte, die halt keine reine ID-Karte ist, ob davon Daten ebenfalls ans Backend weitergegeben werden? Soweit ich beobachtet habe, nein. Alles klar, danke. Vielen herzlichen Dank. Haben wir sonst noch Fragen aus dem Internet oder aus dem Zelt? Sieht so aus, dass werden alle Fragen abschließend beantwortet worden. Dann danke ich noch einmal ganz herzlich, Janis, für den interessanten Talk. Vielen herzlichen Dank. Ich bitte euch noch einmal einen herzlichen Applaus für Janis. Vielen Dank auch an unsere ganzen Technik-Engel und vor allem an unsere Translation-Engel, die hier bei der Hitze im kochenden Zelt weiterarbeiten, und wir wünschen euch viel Spaß.