Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- up-move [2022-05-31 01:08]
Paul
+++ up-move [2022-05-31 01:32]
Paul
@@ Zeile 6: / Zeile 6: @@
 Es gibt noch [[https://md.margau.net/dummeJawboneDinge|ein HedgeDoc mit weiteren interessanten (low-level-) Infos]]. <sup>[von wem?]</sup>
+Anmerkung der Redaktion: Leider macht Dokuwiki Doppelstriche zu langen Einzelstrichen, was die Kommandos kaputtmacht. Sorry!
 ===== Ziele =====
@@ Zeile 65: / Zeile 67: @@
 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 Kommunikation scheinen in com.jawbone.ble.common und com.jawbone.ble.sparta zu sein.
+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). %%
-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). %%
+Die interessanteste Klasse für's Login ist wohl %%package ''com.jawbone.p006up.oobe''. 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? %%
 ==== 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]]''.
@@ Zeile 99: / Zeile 99: @@
 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 ->