Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- up-move [2022-05-26 21:56]
Paul
+++ up-move [2023-02-15 23:55] (aktuell)
@@ Zeile 5: / Zeile 5: @@
 {{ :up-move-animation.mp4}}Da die Dinger an einen Onlinedienst gebunden sind den Jawbone natürlich nicht mehr weiterbetreibt, sind sie jetzt quasi Elektroschrott. Wir haben ein paar davon und wollen mal schauen, was man damit noch so machen kann.
-Wir sind nicht die Einzigen, die sich dafür interessieren. Es gibt noch [[https://md.margau.net/dummeJawboneDinge|ein HedgeDoc mit weiteren interessanten Infos]].
+Es gibt noch [[https://md.margau.net/dummeJawboneDinge|ein HedgeDoc mit weiteren interessanten (low-level-) Infos]]. <sup>[von wem?]</sup>
-===== Mögliche Anwendungszwecke =====
+Anmerkung der Redaktion: Leider macht Dokuwiki Doppelstriche zu langen Einzelstrichen, was die Kommandos kaputtmacht. Sorry!
+===== Ziele =====
+  * Bluetooth-Kommunikationsprotokoll verstehen und sprechen lernen
+  * Firmware-Update mit eigener Firmware
+==== Zwischenbaustellen ====
+  * App auseinandernehmen
+  * App wieder in Betrieb nehmen (patchen oder API nachbauen)
+  * Protokoll zwischen App und NRF8001 verstehen (App beobachten)
+  * Protokoll zwischen MSP430 und NRF8001 verstehen (wie tut man den MSP in den DFU-Modus? App beobachten)
+  * MSP430 programmieren lernen (inkl. Peripherie)
+===== Mögliche neue Verwendung =====
   * Fitness-Tracker :- ) - Vielleicht kann man sie einfach mit ihrem Originalzweck weiter benutzen.
   * Irgendeine andere Art von Bewegungstracker (Türsensor, Alarmanlage)
   * Fernsteuerknopf (dafür besonders cool: Es gibt die Dinger in verschiedenen Farben und Mustern, man kann also mehrere auseinanderhalten. Außerdem lassen sich durch die LEDs besonders komplexe Interaktionen realisieren)
-  * Airtag-Klon (z.B. mit [[https://github.com/seemoo-lab/openhaystack|OpenHaystack-Firmware]])
+  * Airtag-Klon (z.B. mit )
   * Bluetooth LE-Experimentierplattform
-  * Irgendein Akteur: Man hat schließlich 14 Ausgänge, vielleicht auch UART und mehr (evtl. sogar USB)
+  * Irgendein Akteur: Man hat schließlich 14 Ausgänge auch UART, USB und mehr
-  * Irgendeine Anzeige
+  * Irgendeine Anzeige (die LEDs blinken doch nett)
-===== Technische Details =====
+===== Hardware =====
 Das Move Up hat den Modellnamen V3J-JL06, details gibt es dazu bei [[https://fccid.io/V3J-JL06|fccid.io]].
 Es kommuniziert mit dem Handy des Nutzers per Bluetooth Low Energy (LE) 4.0. Die App und das FCC-Filing deuten darauf hin, dass das Gerät einen Firmware-Update-Modus hat.
-=== Hardware ===
 Unter der schwarzen Klebefolie befinden sich ganz schön viele Testpunkte. Die zu identifizieren könnte viel bringen: Vielleicht befinden sich darunter UART-Schnittstelle & Co.
@@ Zeile 40: / Zeile 53: @@
 Ganz interessant ist an dem Gerät, dass es nicht umprogrammierbar ist.
-===== Ziele =====
-  * Bluetooth-Kommunikationsprotokoll verstehen und sprechen lernen
-  * Firmware-Update mit eigener Firmware
 ===== Offizielle App =====
@@ Zeile 60: / Zeile 68: @@
 Mit ''jadx up.apk --export-gradle --deobf -d up-decompiled''. --deobf sorgt dafür, dass gekürzte Bezeichner (wie gz.a) durch zwar genau so kryptische, aber wenigstens einfacher Suchbare ersetzt werden. ''--export-gradle'' sorgt dafür, dass ein Gradle-Projekt erstellt wird. Noch ist das nicht besonders nützlich, da es sowieso nicht kompiliert, aber vielleicht lässt sich das irgendwann mal schaffen.
-=== Kommunikation ===
+Ein Codename des Up Move ist wohl "Pele" (weitere: %%UP: Armstrong, UP24: Pottier, UP2: Spitz, UP3: Thorpe, UP4: Phelps/Sky, UPX: Deion).   Die interessantesten Sachen für die BLE-Kommunikation scheinen in com.jawbone.ble.common und com.jawbone.ble.sparta zu sein. Potenziell interessante Klassen sind: OtaService (ganz viele magische Werte), DeviceInfo, JawboneDevice, SpartaDevice, C2994gs, C3223mz (enthalten characteristic und service-UUIDs), C2988gn (fpabl.%%AndroidWirelessBandManager, macht grundlegende BLE-Sachen).
-Ein Codename des Up Move ist wohl "Pele" (weitere: %%UP: Armstrong, UP24: Pottier, UP2: Spitz, UP3: Thorpe, UP4: Phelps/Sky, UPX: Deion). %%
+Die interessanteste Klasse für's Login ist wohl ''com.jawbone.p006up.oobe.SignInActivity''. Dort wird in der Methode ''mo6922b'' die Antwort auf einen Loginversuch verarbeitet. Gibt es keine Fehler, wird der Benutzer in die lokale Datenbank eingetragen. Interessant ist die Fehlerbehandlung. Hier wird bei einem generischen Fehler "Email or Password cannot be validated. Please try again" (bzw. "E-Mail-Adresse oder Passwort konnten nicht bestätigt werden. Bitte versuche es noch einmal.") ausgegeben - allerdings auch, wenn tatsächlich vom Server eine Verweigerung kommt. Das sind unterschiedliche Codepfade, die sich darin unterscheiden, dass der Dialog im ersten Fall mit ''materialAlertDialogBuilder.setNeutralButton'' und im zweiten Fall mit ''materialAlertDialogBuilder.setPositiveButton'' gebaut wird. Kann man da einen Unterschied erkennen?
-Die interessantesten Sachen für die Kommunikation scheinen in com.jawbone.ble.common und com.jawbone.ble.sparta zu sein.
+Die Klasse %%''com.jawbone.p006up.datamodel.Login'' enthält die Daten für einen Loginversuch: Eine ID für die Session (''session_uid'') und einen User, sowie Konstanten für Fehlerzustände (''AUTH_FAIL'', ''INVALID_EMAIL'', ''INVALID_PASSWORD''). Außerdem hat die Klasse einen Builder.   Die Klasse %%''com.jawbone.p006up.datamodel.User'' ist deutlich weniger überschaubar, da hier wohl so gut wie alle Nutzerdaten gespeichert sind. Die Klasse enthält scheinbar auch Methoden für die Nutzerverwaltung (''saveUser'', ''getCurrentUser'', ''setCurrentUser''). Besonders interessant könnte die Methode ''isAuthenticated'' sein, die überprüft, ob der aktuelle Nutzer in der Datenbank existiert (''getCurrentUser'') und er eine ID (''xid'') hat. ''User'' leitet von ''Xid'' ab, welches das String-Feld ''xid'' und einige Hilfsmethoden enthält.
-Interessante Klassen für die Kommunikation: %%OtaService (ganz viele magische Werte), %%DeviceInfo, JawboneDevice, SpartaDevice, C2994gs, C3223mz (enthalten characteristic und service-UUIDs), C2988gn (fpabl.%%AndroidWirelessBandManager, macht grundlegende BLE-Sachen). %%
 ==== Mitm ====
-Da die App %%als targetSdkVersion 22 hat, haben wir noch nicht das Problem, dass sie nutzerinstallierten Zertifikaten nicht vertraut (ab API Version 24 wäre das so, dann müssten wir [[https://hurricanelabs.com/blog/modifying-android-apps-to-allow-tls-intercept-with-user-cas/|die app dafür patchen]]). %%
+Da die App %%als targetSdkVersion 22 hat, haben wir noch nicht das Problem, dass sie nutzerinstallierten Zertifikaten nicht vertraut. Ab API Version 24 wäre das so, dann müssten wir die App dafür patchen.
+Für's Login sendet die App einen POST-request an ''[[https://api-android.jawbone.com/nudge/api/v.1.59/users/login]]''.
+Mit mitmproxy [[https://github.com/mitmproxy/mitmproxy/]] und einem einfachen Skript lassen sich hoffentlich die API-Antworten spoofen, die richtige Antwort ist allerdings noch unklar. Ein Beispielskript dafür sieht so aus:
+<code python up-api.py>
+from mitmproxy import http, ctx
+def request(flow: http.HTTPFlow) -> None:
+    if flow.request.pretty_host == "api-android.jawbone.com":
+        res = b"""
+{}
+        """
+        flow.response = http.Response.make(
+,
+            res,
+            {"Content-Type": "application/json"}
+        )
+</code>
+Das lässt sich ausführen mit ''mitmdump --set connection_strategy=lazy -s up-api.py''. ((
+ ''connection_strategy=lazy'' ist wichtig, [[https://github.com/mitmproxy/mitmproxy/issues/3843#issuecomment-959552877|da mitmproxy sonst versucht, sich mit dem Originalserver zu verbinden]] und einen Verbindungsfehler wirft.   Das sieht dann so aus:
+<code ->
+client connect
+error establishing server connection: [Errno 8] nodename nor servname provided, or not known
+CONNECT api-android.jawbone.com:443
+<< 502 Bad Gateway 101b
+client disconnect
+</code>
+))
+[[http://eric-blue.com/projects/up-api/#JawboneUPAPI-Response|Die von Eric Blue dokumentierte API-Antwort]] funktioniert scheinbar nicht; ist wohl einfach veraltet. Schade.
 ===== Testpunkte =====