 Wer bin ich überhaupt? Ich bin hauptsächlich Student, aber ich bin auch viel länger in der IT tätig und ich mache auch Freifunk mit und ich entwickle Open Source Software. Mein Steckenpferd im Moment ist das sogenannte Micro Jeep Project, das ich ins Leben gerufen habe und das Ziel dieses Projekts ist es, die Google orientierte Software auf Envoid durch freie Software zu ersetzen. Im Rahmen dieses Projekts bin ich dann auch zu Envoid OER gekommen und deswegen musste ich dieses Protokoll erfolgreich, mehr oder weniger erfolgreich, reverse-engineering und das ist im Prinzip das, worüber ich jetzt reden werde. Ja, was kennt man von EnvoidWare? Die meisten werden sich denken, das geht über Bluetooth, das ist aber nicht ganz korrekt, das Protokoll hat auch andere Übertragungswege, neben Bluetooth geht es auch über TCP und zwar gibt es da eine spezielle Schnittstelle über die Envoid Debug Bridge, also die Schnittstelle über die man Envoid Devices debaggen kann. Darüber hinaus gibt es auch noch ein sogenanntes Cloud Sync Feature, das nicht so viel eigentlich mit dem Protokoll zu tun hat, aber das ich gleich noch eingehen möchte. Das relevante an dem Cloud Sync Feature ist, dass es end zu end verschlüsselt, etwas, was man bei Google doch recht selten sieht, weil sie sowas nicht für nötig halten, weil man kann ja Google sein, also braucht man das nicht. Ja, die Frage, die man sich dann bestellt, da habe ich so ein Envoid Gerät, da habe ich Bluetooth drauf gemacht, wie komme ich jetzt an die Daten dazwischen? Bluetooth ist, wie ihr vielleicht wisst, verschlüsselt, aber es ist Envoid und es geht total einfach, denn es gibt die Backoptionen und man kann einfach sagen, hey, gib mir mal den gesamten Bluetooth Traffic und schreibe ihn auf die SD-Karte, dann habe ich den. Das ist sehr praktisch, weil die Ausgabe kann man wunderbar in Warrior Shark analysieren und bin damit im Prinzip schon fertig. Fertig heißt, na ja, ich kann ein paar Sachen beobachten. Zum einen, ich habe das Ganze dann auch über TCP gemacht, das ist ja ähnlich einfach zu beobachten, dort liegt gar keine Verschlüsselung vor, also keine Transportverkaufschlüsselung, gar nichts, kann man also einfach beobachten und praktischerweise ist das Protokoll auf TCP und Bluetooth als gleiche, das heißt, ab da habe ich eigentlich nur noch mit TCP gearbeitet, weil es viel einfacher. Man sieht, das ist ein Binary Protocol, das ist ja mal doof, so was wie Jason wäre angenehm gewesen, aber das war auch irgendwie nicht zu erwarten, weil das ist ja im Mobilbereich, man muss hier optimieren, man will wenig Traffic erzeugen, gerade über Bluetooth, das ist jetzt auch nicht unbedingt immer das schnellste, also es ist ein Binary Protocol, aber man konnte direkt feststellen, Strings kamen im Klartext durch und wer schon mal mit Google Sachen gearbeitet hat, kann dann relativ schnell auf die Idee kommen, dass sie Google Protocol Buffers benutzt haben. Ich weiß nicht, ob allen Leuten Google Protocol Buffers im Begriff ist, das ist im Prinzip ein Serialisierungsformat von Google, was Google entwickelt hat, was eben Binary Ausgabe erzeugt, relativ effizient ist und relativ schnell auch gebaut werden kann und entsprechend nicht nur von Google, sondern auch von sehr vielen anderen Leuten eingesetzt wird. Kleine Anmerkungen über TCP wurden zwar die gleichen Inhalte verschickt, allerdings basiert das Protocol, weil es ursprünglich für Bluetooth auch designt wurde, eben auf Paketen. Bluetooth-Pakete haben eine gewisse Länge, aber im TCP haben wir natürlich ein Stream und sprechen keine Pakete mit Länge, deswegen ist jeder Eintrag einfach mit so einem kleinen, mit der Paketgröße, die wir in Bluetooth sehen würden, Geprefix, dann ist das Ganze auch möglich, das Ganze zu pasen, weil das Protocol Buffers praktisch ist, die Länge des Ganzen zu kennen, damit man nicht endlich weiter liest. So, jetzt kommt die Frage, wie Biverse-Engineer jetzt schon Protocol Buffers ding? So, praktisch, Protocol Buffers kann man sehr trivial wieder in eine strukturierte Form zurückbringen, auch wenn man das eigentliche Format nicht kennt. Was fehlt, sind natürlich Namen und so weiter, der Felder, weil diese Realisierung soll ja optimieren, und entsprechend geht man davon aus, dass man, dass der, das ist gegenüber die nicht sehr realisierte Form selbst erzeugen kann aus diesem Daten, das heißt, wir haben eine Struktur, aber wir haben keine Namen auf den Feldern, das heißt, der Rest ist, man schaut sich den Traffic an und wenn man, dann sieht man ein Felder und dann muss man gucken, was, was gründ die logisch bedeuten, bei Springs ist es meistens relativ einfach, Zahlen kann man Time Stamps natürlich relativ, auch relativ einfacher kennen, wenn man einfach nur willkürliche Zahlen 1, 2, 3 dastehen hat, dann darf man fröhlich raten, aber das geht eigentlich auch ganz gut. Was man bekommt dann ist das hier, das ist das Format, mit dem man Protocol Buffers definiert, es ist eigentlich relativ einfach, es sieht so aus wie so ein C-Strukt, das heißt, wir haben einfach untereinander geschrieben die Felder mit den zugehörigen Nummern, die jeweils haben, und dann halt den Typ da dran. Die Namen-Annotationen, wie gesagt, kommen von mir, die sind nicht vorhanden, das heißt, das muss ich mir jetzt ausdenken, von einem des Inhalts, und so sieht ein Paket aus, was drüber kommt, die sehen alle so aus. Denkt man sich natürlich, Moment, alles da drin, das ist irgendwie doof, und der Grund dafür ist ganz einfach, das ist erstmal nur ein Framing für klassische Protokollen wie TCP oder so kennt. Das heißt, wir haben den eigentlichen Payload, wird in dem obersten Feld abgespeichert, und im Digist-Feld haben wir halt eine Hash-Summe, umgenot seinen Share 1, und ansonsten wird mehrere Pakete dann zusammengesetzt, und deswegen zählen wir dort die Nummer des Pakets in einer Kette zusammen, Total Frames die Anzahl der Pakete, die zusammengebaut werden müssen, und dann gibt es noch eine QID, das ist einfach eine zufällige Zahl, und dort werden halt die Pakete dann zusammengesetzt aus Paketen, um die die QID identisch haben. Und wenn man hier weitermacht, wird es komplex, und damit das klar wird, wie das funktionieren kann, dann nach, müssen wir erst mal gucken, wie denn eigentlich das Android-Werb überhaupt funktioniert. Dazu kann man auch mal ein bisschen Dokumentationen gibt es ja immerhin schon, nicht zum Protokoll selbst, aber was man damit machen kann, weil Google liegt ja schon API-Star für zur Verfügung, und da gibt es drei Sachen, die man, drei Kommunikationsprimitiven, die man benutzen kann, die heißen halt Channel, Data, Item und Message, die Namen kommen aus der Google-Dokumentation, ob die so gut gelungen sind oder nicht, kann man drüber beschreiten, aber das lassen wir mal aus und vor. Channels zumindest bietet sich den Namen an, denn es handelt sich dabei einfach um, wie man das, um eine Stream-Verbindung, quasi ein, ich kann nicht fast vorstellen, wie eine DCP-Verbindung, wir haben Acknowledgements, das heißt, wir prüfen auch alle Pakete angekommen sind und das Ganze funktioniert synchron, das heißt, es geht nur dann, wenn auch beide Seiten verfügbar sind. Daneben gibt es noch Data-Items, Data-Items werden im gesamten Netzwerk verteilt, das heißt, beim Android-Ware gibt es halt tatsächlich ein Netzwerk im eigentlichen Sinne und nicht irgendwie nur die Plutus-Verbindung, sondern wenn man mehrere Geräte hat, können die sich zu einem Netzwerk verbinden. Das ist erst mal nicht unbedingt sinnvoll oder notwendig, wenn man darüber nachdenkt, dass die meisten Leute wahrscheinlich nur im Smartphone und einer Smartwort rumlaufen und ansonsten wird das Gerät auf ungefähr keinem, bisher wird das Protokoll auf keinem Gerät implementiert und es gibt eine technische Blockade, die Google eingebaut hat, die vom Protokoll nicht notwendig ist, aber die sie halt eingebaut haben und das ist, dass man in einem solchen Netzwerk nur ein Smartphone haben kann. Das heißt im Prinzip relevant ist das Ganze nur für die Leute, die ein Smartphone und mehrere Smartwatches haben, ich glaube davon gibt es jetzt nicht so viele. Aber immerhin kann man in einem solchen Netzwerk dann diese Data-Items komplett scheren, die werden im gesamten Netzwerk verteilt, die kommen halt an und vielleicht kommen sie auch nicht an, denn es gibt keine Acknowledgements und dadurch, dass es aber auch keine Acknowledgements gibt, kann man das Ganze auch synchron machen. Das heißt, man speichert was ins Netzwerk ab und wenn mal so eine Smartwatch dazu kommt, dann kann die das empfangen und wenn da noch eine andere dazu kommt, dann bekommt die es halt auch. Genau, es sind einzelne Pakete, kein Stream und entsprechend kann man, es ist die Größe, ist im Schrechen auch beschränkt und zwar nicht wirklich logisch, sondern einfach willkürlich auf genau 5.000 Bytes und entsprechend muss es deswegen auch notwendig, dass trotzdem eins von diesen Paketen über mehrere Bluetooth-Pakete geleitet werden, weil Bluetooth ist in der Größe eben die Paketbräuße auch beschränkt. Als dritte Form gibt es noch die Messages, das soll laut Google genau sowas sein, wie ein Channel eben auch gerichtet einer einzelnen Person und mit der Acknowledgement allerdings dafür Asynchron und eben auch Paketbasiert und nicht als Stream. Warum ich sage, laut Google-Message, das gibt es im Protokoll gar nicht, die haben einfach Data-Items genommen und schicken die durch die Gegend und sagen halt dem anderen Acknowledge das mal, dann haben wir Data-Items mit Acknowledgement und dann sind wir bei Messages, weil so eigentlich nicht speziell ist. Außerdem kann man über das Cloud-Sync-Feature auch tatsächlich Data-Items übertragen werden, das ist auch irgendwie logisch, denn sonst müsste man ja einen direkten Stream zu einem Gerät machen, weil das man eigentlich, wie der Name schon sagt, eigentlich nur synchronisieren will und das ist halt nicht möglich oder vorgesehen und wie gesagt Cloud-Sync benutzt nicht das gleiche Protokoll, aber hat eben eine Kompatibilität damit. Dann gibt es noch ein paar weitere Sachen, die bei Google nicht dokumentiert sind, aber die gibt es, ich habe schon gesagt, die Data-Items sind in der Größe beschränkt und das ist ein Problem, weil wenn man Bilder oder so übertragen möchte, weil man ja vielleicht das Foto von einem Kontakt anzeigen möchte, wenn der angerufen wird, dann muss man irgendwie auch mal ein bisschen mehr übertragen können und deswegen ist es möglich, sogenannte Assets zu verschicken, das sind halt normalerweise, fast allen Fällen handelt sich dabei um Bilder, aber wenn man eine Anwendung auf der Watch installiert, dann kann es sich dabei auch eben so eine APK-File oder eben prinzipiell ist es auch möglich, beliebige Sachen darüber zu verteilen. Es gibt außerdem Möglichkeit, einen RPC-Request abzusetzen, also eine bestimmte Anfrage, die uns Android-System orientiert ist, das heißt, Android werden Anwendungen mit bestimmten Anfragen gestartet, sogenannten Intents und so eins kann man halt im Prinzip definieren und über das Netzwerk an einem bestimmtes Gerät verteilen und wenn die Nachricht angekommen ist, dann wird halt das ausgeführt. Es gibt keine Garantie, dass es ankommen, aber wenn es dann da ist, dann kann man auf dem Gerät im Prinzip den entsprechenden Anwendung ausführen, wie man lustig ist. Ja, das Protokoll hat auch noch Heartbeats, die sind total sinnlos, aber sie werden gemacht. Also die bringen absolut gar nichts, weil Bluetooth hat ein eigenes Heartbeating-System und entsprechend über TCP hat man auch Heartbeats, es ist also völlig sinnlos, aber sie gibt es, also sie sind da. Man muss auch nicht darauf reagieren, also wenn du in deinem Kleinen deine Heartbeats nicht implementiert hast und entsprechend nicht dein Heartbeat ag verschickst, dann ist das auch okay, weil es interessiert auch absolut niemanden. Was gibt es da noch so? Data Items, ich habe es schon angesprochen und habe mich noch ein bisschen mehr darüber reden, weil das ist das eigentliche Kernkomponente, die Channels werden so gut wie nicht benutzt, ausschließlich in einigen wenigen Anwendungen, die darüber Live-Daten übertragen wollen, zum Beispiel kommt das in der Google Maps Anwendung für die Smartwatch vor. Wenn keine Internet Verbindung auf der Smartwatch selbst besteht, dann kommuniziert die beiden solchen Channels mit der Google Maps Anwendung auf dem Smartphone, aber sonst eben gar nicht und deswegen werde ich auch nicht so viel Zeit darüber reden, weil es im Prinzip sich verhält wie eine TCP-Verbindung. Für den Data Items lässt sich mehr sagen, zum Beispiel wie sie übertragen werden, das funktioniert so, dass jedes Data Item so eine Sequenz-Nummer bekommt, die für jeden Not einzeln hochgezählt wird, also jedes Mitglied im Netzwerk. Das erlaubt es, dieses werden dann eben identifiziert, die diese Data Items, und zwar, weil das Ganze auf Android ausgerichtet ist, benutzt man die typische Identifizierung, die man unter Android benutzt, um Anwendungen zu identifizieren. Das ist der Damer des Pakets und an dieser Stelle haben sie sich außerdem noch die Mühe geben, die die Signatur des Public Keys, mit dem dieses Paket signiert wurde, dazu zu packen. Das hat den Hintergrund, dass wenn man die Anwendung deinstalliert und andere Anwendungen im anderen Public Key installiert, dass dann entsprechende Pakete nicht mehr empfangen werden können, weil die Pakete bleiben ja im Netzwerk erhalten und entsprechend können sie danach wieder abgerufen werden, wenn das nicht der Fall wäre. Außerdem wird in so einem Data Item noch zusätzlich eine UI hinzugefügt, die im Prinzip das System nicht sonderlich interessiert, aber die die Anwendung benutzen kann, um es auszulesen und die auch als Identifier agiert. Das heißt, auf jedem Gerät kann für jeden Not, für jede Anwendung und dann zusammen mit diesem Identifier auch nur ein Data Item existieren. Außerdem müssen in jedem Data Item erwähnt werden, welche Assets daran referenziert werden. Wenn das nicht passiert, kann man sehr leicht, sehr lustige Sachen mit den Geräten machen. Das ist total toll, weil in der Implementierung, die Google vorgibt, es wird bereits, werden referenzierte Assets versucht direkt aufzulösen. Wenn die nicht vorhanden sind, gibt es eine Nullpoint Interacception und das den ganzen Smartwatch fliegt um die Ohren. Du kannst sie danach nicht mehr benutzen, bis du sie komplett resetted hast. Was es nicht geht, weil das Interface blockiert ist, das heißt viel Spaß beim Anschließen deiner seriellen Schnittstelle. Was gibt es noch zu Data Items zu sagen, wenn du im Gerät verbunden bist, über zum Beispiel in der Bluetooth Verbindung oder über eine TCP Verbindung, dann wird ein Data Item, wenn es abgespeichert wird, direkt darin übertragen, sodass man eine live notification bekommt, da ist jetzt ein neues Data Item. Zum Beispiel, wenn man, das ist denke ich, der typische Use Case, zum Beispiel wenn eine Notification auf deinem Smartphone bekommt und die auf deine Smartwatch übertragen werden, dann passiert das eben genau über ein solches Data Item und das wird halt genau dann live gepusht, weil die Verbindung eben besteht. Wenn eine Verbindung nicht besteht mit einem Knoten, der sich danach anschließend verbindet oder wenn der Knoten bisher noch nie im Netzwerk vorhanden war, schickt da eine Anfrage an den Knoten, mit dem er sich verbunden hat und sagt ihm, ich kenne folgende Details über das Netzwerk. Ich kenne diese Knoten in diesem Netzwerk und von den Knoten habe ich bis zu der folgenden Sequence ID ein Data Item bekommen, schickt mir mal alles, was du noch kennst und dann kommt eben die Antwort dazu und entsprechend kann so das gesamte Netzverhobber synchronisiert werden, ohne dass unwürdige Sachen übertragen werden. Wenn man ein Asset referenziert, muss man das auch aus immer dem Gerät übertragen, bevor man das Data Item überträgt, das heißt, die Asset sind vorher vorhanden sein und es ist Aufgabe des Descendenden, das zu überprüfen. Wenn man ein Data Item schickt, ohne dass das Asset schon wandern ist, tritt eben genau das gleiche Problem, was ich eben erwähnt habe, das Gerät wird unbrauchbar. Wenn es Änderungen gibt, ja, ich habe schon gesagt, wir haben einen eindeutigen Identifier für jedes Data Item, das heißt, in Änderungen pusht man einfach, indem man eine neue Version mit derselben ID pusht, dann hat man Änderungen übertragen, das bekommen alle wunderbar mit. Löschen von Data Item funktioniert ähnlich genial, wir haben so sich so ein Data Item im Netz aus und da gibt es ein tolles Boole deleted, juhu, es ist deleted. Es wird gespeichert, aber es ist laut Gerät dann nicht mehr verfügbar und wird wunderbar auch allen Leuten weiter synchronisiert, dass es gelöscht wurde, also inklusive der Daten, weil die braucht man, um zu wissen, dass es gelöscht wurde. Was gibt es noch? So sieht so eine Synchronisierungsanmeldung aus, ich habe schon gesagt, es gibt die Device ID und dann die Last-Node Sequence ID, würde in eine Tabelle übertragen und dann zusätzlich noch eine Versionsnummer des Protokolls, das ist eigentlich relativ einfach. So, Demo wäre jetzt eigentlich geplant gewesen, aber das funktioniert nicht, ist aber auch nur kurz, ich kann grob sagen, was schon geht, ich habe ein bisschen was zum Protokoll ja erzählt, ich habe noch gar nicht das gesamte Protokoll über das engineered, das heißt, was ich gefunden habe, habe ich jetzt mehr oder weniger vorgetragen, ein bisschen mehr auch noch, hätte ich auch noch gefunden, aber das ist ein bisschen langweilig geworden, also hätte ich jetzt eigentlich die Demo gemacht und da hätte ich zu sehen gewesen, wie ich eine Nachricht an die Urverteile und danach wieder zurückbekomme, nachdem ich mich mit einer neuen Kleinverbinde in das selbe Netzwerk ist aber jetzt nicht da, aber man kann das sicher vorstellen, es funktioniert, so wie ich es dokumentiert habe, wie ich es gerade erklärt habe und es ist also kein Problem. Wenn jemand daran interessiert, dass er den Projekt mitmachen möchte, vielleicht beim Reverse Engineering helfen oder auch bei der Implementation helfen, weil das ganze, wie ich erwähnt habe, mache ich im Rahmen dieses MicroG Projekt und da brauchen wir auch eine gute Implementation, die dann auch auf dem Android-Gerät ausgeführt werden kann, so dass es im finalen Zustand dann möglich sein soll, seinen Android-Wehr-Gerät auch unter freier Software zu betreiben und davon nicht auf Google-Software angewiesen zu sein wäre super, wenn jemand auf die Webseite dazu draufguckt, da habe ich ein bisschen zusammengefasst, die Information, die habe ich zwar links breit gestellt und wenn ihr euch für das Projekt auch interessiert, in dem das Ganze abläuft und vielleicht mal auch ausprobieren wollt, der hat es auch herzlich eingeladen, eben auf dieser Webseite findet man das und wenn ihr mich kontaktieren wird, geht das unter dieser E-Adresse ansonsten, bin ich jetzt auch offen noch für Fragen. Keine Fragen. Keine Fragen. Okay, dann halt nicht.