 Wirklich los. Entschuldigung, ja, Bima ist immer so eine Sache oder Projektoren. Ich mag sie nicht, sie mögen mich nicht. Das hier wird tatsächlich die einzige Folie, die ich heute zeigen werde, denn ich denke, dass das in einem Terminal zu demonstrieren, doch etwas interessanter ist, als einfach alles auf Folien zu zeigen. Was ich heute vorstelle, sind meine zwei Favoriten-Themen für die BSD und D-Trace, aber wir sind etwas zeitlich konstant. Das heißt, wir schauen uns mehr D-Trace an als BSD an. Ich hatte ursprünglich ein bisschen mehr BSD geplant, das kommt jetzt nicht vor. Es passt dann auch etwas besser der Resilience-Track. Vorher anfangend, wer hier im Saal benutzt, tatsächlich D-Trace mehr als ich mir gedacht habe. Aber ich würde natürlich gerne noch mehr sehen und ich hoffe, dass ihr nach dem Talk tatsächlich euch damit noch weiter beschäftigen möchtet. Also, für diejenigen von euch, die D-Trace noch nicht kennen, dass ich mal kurz in Zusammenfassung gehe, es ist Open Source, es kommt aus den Open Solaris-Welt oder Solaris-Welt. Und es wird weiterentwickelt auf Illumos, was ein Fog von Solaris ist. Es läuft auf FreeBSD, NetBSD, OSX. Es gibt auch ein Port für Linux, der D-Trace vor Linux heißt. Es wurde auch nach QNX portiert und die OpenBSD-Leute arbeiten gerade auch daran, eine Technologie ähnlich wie D-Trace bei sich zu implementieren. Ich habe gehört, es gibt auch einen Port für Windows. Ich weiß nicht, ob das tatsächlich wahr ist, aber es klingt irgendwie cool und das heißt, es ist quasi überall. Die meisten von euch kennen vermutlich staatliche Tools wie S-Trace unter Linux oder Truss unter FreeBSD. Und was die machen, ist, dass man sie an einem Prozess attacht und dann vom System die System-Code sieht, die dieser Prozess ausführt. Das heißt, wir können von außen in das Programm reinschauen und aussehenden, was das Programm tut, von außen vor allem. Es ist gleichzeitig auch relativ limitiert, einmal, weil das den Prozess, den wir gerade betrachten wollen, bremst, ausbremst. Das heißt, dass die Bugging auf einmal ein Performance-Problem wird. Wir können mal nur auf einen Prozess schauen, aber vielleicht wollen wir vielleicht nicht nur einen Prozess anschauen, sondern das ganze System. Wir haben in dem System eben viele Layer, die alle miteinander arbeiten, das Virtual Data-Teil-System, Netzwerk, Datenbanken usw. Und die alle irgendwie kommunizieren. Oder wenn wir eine höher leveligere Problemiersprache haben mit einer Runtime, dann ist das vielleicht auch alles nicht mehr so klar. Das heißt, wenn irgendwas in so einem System schief geht, das mit so einer hohen Komplexität arbeitet, dann passiert etwas, dass wir das Blame-Game nennen. Das Grundkonzept ist, dass es niemals die eigene Schuld ist, sondern immer die von jemand anderem. Und was wir machen möchten, ist, auf das ganze System zu schauen und die Daten zu korrelieren, die da drinnen anfallen, um tatsächlich an, wo uns finden, auf das den Grund weshalb der Hand schief gehen. Das heißt, wir möchten unseren Prozess aber auch gleichzeitig nicht austauschen und stattdessen Debug-Bilds von denen benutzen, sondern wir möchten in Production debuggen. Also das heißt im Produktionssystem. Also um das relativ arbiträr und ohne vorherige Konfiguration zu machen, brauchen wir eine Art Programmiersprache. Wir müssen irgendwie beschreiben, wenn das passiert, dann emittiert diese Daten irgendwohin, damit wir sehen können, was passiert. Und das impliziert tatsächlich irgendeine Art Programmiersprache. Und Detrace kommt mit so einer Art Programmiersprache, ist so ein bisschen Mix aus Org. Und C ist es eigentlich relativ einfach zu lernen, kann es innerhalb von 20 Minuten lernen und man kann dann schnelle Erfolgserlebnisse haben. Wenn man schon Org kennt, ihr kennt das mit Sicherheit, also man kann das benutzen, um große Mengen an Text zu analysieren. Und Detrace macht im Prinzip dasselbe, wie fühlt nur für Systemverhalten. Und zusätzlich möchten wir das System nicht ausbremsen. Das heißt, wir möchten tatsächlich auch Performance-Tests machen. Und das geht mit Detrace. Ich habe diese Demo hier vorbereitet. Ich hoffe, man kann das lesen, wir hatten hier ein paar Schwierigkeiten mit dem Beamer. Wir schauen mal auf einen ganz naiven Art. Ein kleiner Moment. Sehr einfacher Art, einen Benutzer anzumelden. Wir nehmen einen Benutzer, einen Namen und vergleichen ihn mit einem Geheimnis. Das Geheimnis hier steht als Klartext da. Das ist ein bisschen künstlich, aber es geht hier darum, das zu demonstrieren. Diese Checkfunktion ist korrekt. Wir nehmen zwei Strings, vergleichen sie miteinander. Und wenn wir uns jetzt angucken, wie der Stringvergleich tatsächlich funktioniert, er nimmt die beiden Strings und vergleicht jedes Zeichen der beiden Strings miteinander. Sobald er ein paar Zeichen findet, die nicht übereinstimmen, wissen wir, dass die Strings nicht leicht sind. Wenn diese Funktion sehr schnell läuft, nur eine ganz kurze Ausführungszeit hat, und wenn das Passwort besser raten, dann wird die Funktion länger laufen, weil sie mehr Zeichen als leicht gefunden hat. Und wenn wir die Zeit messen können, dann können wir versuchen, damit das Passwort auszuprobieren und vollständig zu raten. Ich habe also hier ein Programm, das über das Alphabet iteriert. Und wir benutzen Detrays, um die Timinginformationen vom Stringvergleich zu finden. So, das Programm läuft jetzt im Hintergrund. Ich kann gerade nicht sehen, was ich da tippe. Aber ich kann euch die ganzen Programme hinterher auf meinem Github-Account nachgucken. So, hier sehen wir jetzt die Verteilung der Laufzeit des Vergleichs. Und wir sehen, dass jedes versuchte Zeichen einen leicht unterschiedlichen Laufzeit hat. So, für diese Zeichen sehen wir, da läuft das Stringvergleich ein paar Nanosekunden länger. Das ist die Zeitschale, auf der wir hier operieren. So, jetzt probieren wir das aus. Leider ist die Ausgabe hier ein bisschen abgeschnitten. Wir würden jetzt eigentlich sehen, wie sich die Distribution der Messwerte ganz dramatisch ändert. Und wir können hier noch ein bisschen weiterspielen. Wir testen ein bisschen länger und jedes Mal fügen wir einen Buchstaben hinzusuchen, wo tatsächlich die Laufzeit sich verlängert. Und so können wir jetzt Schritt für Schritt, so können wir dann innerhalb weniger Sekunden jeweils den nächsten Buchstaben erraten und damit das ganze Passwort herausfinden. Das ist jetzt von diesem Beispiel etwas generalisierbar. Also bei Kompografie zum Beispiel, wo wir Timingseitenkanäle haben können, dadurch dass Operationen unterschiedlich lange dauern. Ich könnte zum Beispiel auch die Trace benutzen, um ein tatsächliches Binary zu analysieren. Und das ist die wichtige Beobachtung hier. Ich musste keinen Deeper-Code in das Binary einschleusen, um es zu debuggen, sondern ich habe hier das Production-Binary, also das Production-Programm, das ich observieren kann mit die Trace. Einige von diesen Timingseitenkanälen können zum Beispiel durch eine Compiler-Optimierung eingefügt werden sein. Das heißt, wenn wir jetzt Deeper-Code da einschügen und auf Deeper-Code vielleicht kompilieren, dann könnten diese Timingseitenkanäle weggehen und das Problem tritt gar nicht auf. Das heißt, das ist eben ein ziemlich guter Grund, warum man in Production debuggen möchte. Ich zeige euch jetzt hier ein Script, also ein Detrace-Script. Da sind drei interessante Dinge drin und keine Sorge. Es ist jetzt etwas komplizierter, aber ich möchte euch vor allem inspirieren, was ihr eigentlich so alles mit Detrace machen könnt. Ihr könnt tatsächlich mit ziemlich verrückten Ideen aufkommen, was man da so machen kann. Und ich zeige euch jetzt erstmal ein paar einfache Sachen. Also, es gibt drei interessante Teile hier drinnen. Es gibt zuerst den, eine sogenannte Probe, und das ist ja ein Punkt, an dem wir das System instrumentieren möchten. Das heißt, kühlt es mal, wenn ein bestimmtes Event aufredet, dann wird diese Probe auslösen, feiern und wir haben dann eben diese Wirklichkeit dort da zusammen. Der zweite interessante Teil dieser Abschnitt hier, diese Bedingung, und die beschreibt, was diese Probe ausführen soll oder was ausgeführt werden soll, wenn diese Probe auslöst. Und diese Probe hier ist jetzt etwas interessanter. Er erzählt uns jetzt endlich etwas, wie so eine, oder man sieht daran, wie eine Struktur aussieht. Jeder Probe wird eindeutig identifiziert durch einen Viertupel, also vier Komponenten, die eine Probe eindeutig identifizieren. Und der erste Teil von diesem Tupel ist der sogenannte Provider, das erzähle ich gleich. Der zweite ist das Modul, der dritte ist die Funktion und der vierte ist der Name der Probe. Und diese vier Stückchen Daten und Namen zusammen identifizieren eine Probe eindeutig. Also, das dritte, was es dann noch gibt, ich komme gleich nochmal darauf zurück, aber das dritte, was es jetzt noch gibt, das Modul, das ich leider heute keine Zeit habe und nichts unterhalten, ist eine sogenannte Akkagulation. Und diese Zeile, diese einzelne Zeile ist dafür verantwortlich, diese ganzen Daten zu akkombulieren und diese Diszipektionen, die hier auf der rechten Seite seht, zu generieren. Und das ist alles in Detrays eingebaut. Ihr müsst es nicht selber schreiben, den Code dafür. Dieses Skript ist gerade mal 42 Zeilen Code und es hat mich gerade mal fünf Minuten gekostet, diesen ersten Prototypen zu entwickeln. Das heißt, man muss nicht viel da rein investieren, um relativ viele Informationen zu extrahieren. Und das heißt, wenn ihr tatsächlich Detrays benutzt, dann werdet ihr gerade das ja, diese Produktion benutzen, werdet ihr das ja häufig benutzen. Also, ja, schauen wir uns den nächsten Mal Provider an. So, das wird dann wahrscheinlich auch etwas abgeschnitten sein. Das heißt, ich werde jetzt einen kleinen Trick anwenden und den Buffer dabbeln, damit man das oben sieht. So, und jetzt, wenn wir uns hier diese Provider anschauen, mit NextProviders, ich habe 27 Provider, die Anzahl an Providern variiert, je nach Betriebssystem, auch unterschiedliche Provider je nach Betriebssystem. Und es kann aber auch noch andere Provider geben. Das heißt, ich habe 27 Provider und wir schauen jetzt sehr speziell den Cisco Provider an. Und jeder Provider weiß im Kern, wer in bestimmten Teilformsystemen instrumentieren soll. Das heißt, der Cisco Provider weiß, wer die Cisco Table instrumentieren soll. Das ist relativ wenig überraschend. Das heißt, wir können uns den Cisco Provider anschauen und da können wir jetzt hier sehen, alle Systemaufrufe, Eintritte und Returns von allen Systemaufrufen, die FreeBSD bereitstellt. Das heißt, der Provider ist Cisco, der ist jetzt Modul und so weiter. Und das sind die, alle Systemkreuz, die ich in meinem System habe. Und ja, der andere Provider, den wir uns anschauen wollen, ist der FPT Provider. Und das ist der sogenannte Function Boundary Tracer. Und der erlaubt uns, jede einzelne Funktion im Kernel zu tracen. Das heißt, wir können jede einzelne Funktion im Kernel instrumentieren. Wir schauen uns quasi jede einzelne Funktion an im Kernel, die aufruft wird. Und um das zu illustrieren, habe ich jetzt ein sehr einfaches Detrace Script geschrieben, das ihr jetzt rechts oben sehen könnt. Das heißt, ich werde den M-Map-System-Call instrumentieren, für die, die es nicht wissen. Der M-Map-System-Call map eine Datei in den Adressraum eines Programms. Also, relativ, ja, zwei sind sehr einfache Erklärungen, aber das ist das, was wir machen. Das heißt, wenn wir den M-Map-Call aufrufen, also ein Cisco betreten, dann werden wir die Variable Follow auf Einsetzen. Und was das itself bedeutet, ist letztendlich eine thread-lokale Variable. Und das heißt, wir werden, wir assoziieren jetzt eben diese Variable Follow mit dem thread, den wir instrumentieren möchten. Dann machen wir jetzt etwas, was etwas gruselig aussieht. Aber wir werden jetzt tatsächlich den ganzen Kernel instrumentieren. Jeden einzelnen Funktionsaufruf und Austritt, werden wir hier instrumentieren. Hier seht ihr dann ein sogenanntes Predicate, das ist quasi das Detail, der so ist wie Org. Das heißt, wir matchen hier auf dieses Predicate, und nur wenn dieses Predicate auf wahr evaluiert, dann wird die Clause darunter ausgeführt. Und das ist tatsächlich einfach nur eine leere Clause. Wir möchten einfach nur wissen, dass wir dahin gekommen sind. Wenn wir dann aus dem M-Map-System-Call rauskommen und dieses Predicate wieder gesetzt ist, dann setzen wir die Variable Follow auf 0 und wie jede unizialisierte Variable in Detrace, das ist quasi das LBWD Allocieren davon, also zerstören und dann bänden wir das Detrace. Das lassen wir jetzt mal laufen und boom. Das heißt, ihr habt eine kleine Pause gesehen. Das war, wenn Detrace den Kernel revertiert hat, zurückgerollt hat, was es vorher gemacht hat. Und jetzt können wir hier sehen, was im M-Map-System-Call passiert, und das ist jetzt etwas schwierig in VI zu sehen, und jetzt habe ich hier mit einem weiteren Fleck an etwas schöneres Rücken, das ist halt eine Visualisierung erzeugt. Und ja, ihr sagt jetzt, ah, das klingt irgendwie ziemlich gefährdig, dass du da einfach beliebigen Code in den Kernel induzieren kannst, aber ich zeige euch etwas, das ich tatsächlich interessant finde. Ich gehe jetzt nicht zu sehr in die Tiefe, aber das hier ist ByteCode. Das heißt, jedes Detrace-Gib wird zuerst in ByteCode kompelliert, und dieser ByteCode wird dann in den Kernel gesendet, und im Kernel existiert eine kleine virtuelle Maschine, die diesen ByteCode interpretiert. Und das heißt, wenn ihr ein Skript schreibt, das bösartig ist an den Kernel angreifen möchte, also zu viel Speicherallokiert oder zu lange braucht, dann kann die virtuelle Maschine das einfach anhalten und die ganzen Änderungen, die gemacht wurden, wieder rückgängig machen. Und das ist tatsächlich gar keine neue Idee. Wenn ihr zum Beispiel mal TCP-Dump benutzt habt, dann habt ihr das schon mal gesehen. TCP-Dump, BPF haben auch diesen ByteCode, oder einen anderen ByteCode, das ist keine neue Idee. Alles, was ich euch hier gezeigt habe, bezieht sich auf Funktionsaufrufe. Das ist nicht besonders spannend. Wir gucken uns mal an, wie wir viel mehr interessante Informationen aufzeichnen können. Lass uns mal auf den tatsächlichen Kernel gucken. Ich musste meinen Rechner rebooten, deswegen ist mein Setup ein bisschen kaputt. Hier ist die Funktion VMFort. Ich benutze hier FreeBSD Current, Version 12. Diese Funktion, wir haben uns eben MAP angeguckt und MAP erlaubt es einem, eine Datei in den Speicher reinzumäppen, nicht zu laden, sondern zu mapen. Wie das technisch funktioniert, ist über diese Funktion, sobald unser Prozess auf Speicher zugereift, der nicht schon als Ramm hinterlegt ist, tritt ein sogenannter PageFault auf und diese Funktion wird aufgerufen. Lass uns auf die Argumente dieser Funktion schauen. Das ist die Adresse. Das ist der Typ des PageFaults und ein paar Flex. So, was ist das? Was ist das für ein Typ des ersten Arguments? Es ist ein Pointer und eine große Struktur. Und wir möchten gerne uns diese Struktur angucken. Ich sollte das hier machen. Lass uns auf dieses Skript VMFort schauen. Ich ignoriere mal diesen Code am Anfang, damit es lesbarer wird. Und hier geht es wirklich los. Was ich hier mache, ich instrumentiere die VMFort-Funktion. Wann immer die aufgerufen wird, also wie in die Funktion einsteigen, geben wir die folgenden Datenbau aus, nämlich der Prozess, der Name des Executables, die PID und die Argumente dieses Prozesses. Nichts Besonderes. Erst mal einfach ein paar Daten ausgegeben. So, und was wir jetzt hier machen, wir geben das Arcs Array aus und das Besondere an diesem Argument ist, dass es tatsächlich Typ-Informationen enthält. So, wir lassen das einfach mal laufen. So, jetzt sehen wir hier eine Datenstruktur im Kernel. In Detrace erlaubt es uns, da reinzuschauen. Es ist sehr leistungsfähig, weil wir hier die einzelnen Felder dieser Struktur sehen. Ich kann auf jede dieser Elemente zugreifen, auf ganz normale Variablen noch zugreifen kann. Und dazu gibt es etwas, was ich CTF nennt, nicht Capture the Flag. Und es gibt einen kleinen Abschnitt im Kernel Binary, wo diese ganze Typ-Informationen im Kernel untergebracht ist. Und Detrace benutzt diese Informationen, die im Kernel hinterlegt sind, um diese Typen tatsächlich analysieren und anzeigen zu können. Und warum möchte ich das überhaupt machen? Warum möchte ich in den Kernel reinschauen? Erinnert sich noch jemand an Dirty Cow? Das war ein sehr unangenehmes Problem im Linux Kernel. Darüber konnte man als normaler Benutzer in Dateien schreiben, die einem gar nicht gehört haben. Sehr, sehr unangenehm. Das sind sehr komplizierte Sachen. Ich will hier gar nicht auf den Linux Leuten rumrahmen. Und in 2005 ist es zum ersten Mal aufgetreten. Und dann kam es in 2015. Und dann noch mal in 2017. Weil der Code wirklich sehr schwer ist, Kernel Code richtig zu schreiben. Und das war sozusagen die Vulnerability des Jahrzehnts. Wenn man kein Tool wie Detrace hat, dann kann es sehr, sehr gut sein. Und das ist das, wenn man kein Tool wie Detrace hat, dann kann es sehr, sehr schwer sein, rauszufinden, was da wirklich los ist. Ich habe gehört, manche Leute entwickeln Exploits speziell für Systeme, die Detrace haben, weil ich damit so tolle Möglichkeiten habe, da reinzuschauen. Und das ist cool. Ein Exploit ist ein Proof of Concept, um zu demonstrieren, da läuft das falsch. Und ich hatte Situationen, in denen Leute mir gesagt haben, das ist gar nicht unser Problem, das ist gar nicht das Problem in unserer Software, das ist das Betriebssystem. Und dann habe ich ein bisschen Detrace-Kripte geschrieben und konnte Ihnen zeigen, wo das Problem wirklich steckt. Also, alles, was ich bis jetzt gezeigt habe, war ziemlich an Funktionsaufrufe gebunden. Wir möchten vielleicht aber manchmal auch ein bisschen mehr Symantec haben. Also, wir möchten nicht immer nur ins Kript haben, dass eine Funktion instrumentiert, sondern vielleicht ein Protokoll, also TCP oder so was. Und wir wollen jetzt gar nicht wissen, welche Funktion im Kernel für das Handling von TCP zuständig ist, sondern wir möchten da höherer Symantec haben. Wir haben hier eine hier zeigen lassen, welche verschiedenen Funktionen oder Namen, also welche Probes es gibt. Also noch ganz zum Beispiel die Priorität sicher anschauen. Und ja, zumindest ich finde das ziemlich interessant. Und es ist tatsächlich auch einfach nützlich in Situationen, wo ich mich frage, warum wird das jetzt gerade gescheduled? Warum wird das nicht gescheduled? Was geht eigentlich gerade ab? Ich habe jetzt nicht mehr besonders viel Zeit. Ich möchte euch eigentlich nur noch was zeigen. Das ist jetzt alles Kernelzeug. Kann man das auch im Userspace machen? Natürlich. Es gab einen Provider, der noch nicht angezeigt wurde, als ich meine Provider-Liste gezeigt habe. Also ich habe diese Timing-Attacke demonstriert und das ist der sogenannte PID-Provider. Der PID-Provider generiert Probes dynamisch. Das heißt Prozesse haben vielleicht sehr viele Probes und ja, das möchten wir eben lieber dynamisch händeln. Und das heißt, ich habe jetzt hier ein sehr kleines Programm, einfach nur mit Execut 0. Und dieses $Target, das wir hier stehen haben, wird dann ersetzt durch den Prozess, den wir gestartet haben. Und das ist alles, was passiert, wenn wir den Prozess, also dieses Programm starten. Und er sieht tatsächlich, dass es deutlich feindgranularer ist als der Function-Boundary-Tracing-Provider. Das heißt, diese Nummern, die hier seht, sind tatsächlich die Instruktionsaufsets innerhalb der Funktionen. Wir können uns jetzt auch Libraries anschauen, zum Beispiel libc hier. Und es passiert tatsächlich ziemlich viel in libc, wenn wir einfach nur das Programm True ausführen. Und ja, vielleicht noch eine letzte Sache, die ich euch zeigen kann. Ich nutze relativ viel Haskell und die MacOS-Leute haben auch DeTrace. Und sie haben Unterstützung für den Glasgow Haskell Compiler in DeTrace, also Entschuldigung, der Glorious Haskell Compiler. Und sie haben tatsächlich auch Probs, um zu instrumentieren, was eigentlich in der Laufzeit passiert. Und ich möchte das unter FreeBSD auch haben. Und das heißt, nachdem ich ungefähr eine Woche mit Makefiles und Linkern gekämpft habe, funktioniert es tatsächlich. Das heißt, wenn man den Headbrown vom GHC-Provider auscheckt, dann bekommt man tatsächlich Probs für die Haskell Runtime. Das ist jetzt ein ziemlich langweiliges Programm. Das startet einfach mit ein paar Pink-Kommandos. Und was ich jetzt tatsächlich tun kann, ist folgendes DeTrace-Kommando ausführen. Ich kann auch White Cards benutzen, wer hier seht. So, dass wir hier anzeigen, was innerhalb von GHC passiert. Zum Beispiel in Garbage Collection. Und das heißt, ich kann würzliche DeTrace-Script schreiben, die tatsächlich auch meinen Runtime-System instrumentieren. Das gibt es auch für Pfeifen, bin ich mir aber nicht so ganz sicher, weil ich es nicht benutze. Für Node.js gibt es es auch. Postgres hat auch eigene Provider. Und was ich auch interessant finde, Firefox. Wenn ihr JavaScript in eurem Firefox ausführt, dann hat es einen DeTrace-Provider. Das heißt, ihr könnt JavaScript, das in eurem Browser läuft, mit DeTrace instrumentieren. Das heißt, vielleicht wisst ihr es gar nicht über, vielleicht nutzt ihr das schon. Oder könnt ihr das benutzen, oder eine Anwendung. Ich muss jetzt leider aufhören, wir werden sonst keine Zeit mehr für Fragen haben. Und ihr habt bestimmt welche. Danke für eure Aufmerksamkeit. Wir sind tatsächlich schon über der Zeit, aber wir haben noch zwei Minuten, weil wir drei Minuten zu spät angefangen haben. Das heißt, wenn es tatsächlich irgendwelche Fragen gibt, die jetzt ganz schnell Fragen stellt, dann lassen wir uns die Fragen mal anhören. Welche Änderungen müssen im Kernel gemacht werden, damit man DeTrace benutzen kann? Das macht man nicht unbedingt an einem Wochenende, also die Person, die damit angefangen hat in FreeBSD ist leider mittlerweile verstorben. Aber es hat sie tatsächlich einige Jahre gebraucht, bis alles fertig war, bis man das benutzt kann. Man braucht zum Beispiel dieses CTF-Zeug, also die Typinformation und das ist auch das, wo OpenBSD gerade dran arbeitet. Und man muss es dann auch für so Geschichten wie Kölner-Module unterstützen und das macht alles dann etwas kompliziert. Aber es ist tatsächlich schon sehr weit portiert worden, wie ich am Anfang gesagt habe, die schon die Weiterverbreitung haben. Das heißt, man kann es tatsächlich benutzen. Es gibt jetzt keine weiteren Fragen im Raum. Ihr könnt mit Reiko auch außerhalb vom Raum reden weiter.