Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- up-move [2022-05-31 01:52]
Paul
+++ up-move [2023-02-15 23:55] (aktuell)
@@ Zeile 68: / 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.
-Ein Codename des Up Move ist wohl "Pele" (weitere: %%UP: Armstrong, UP24: Pottier, UP2: Spitz, UP3: Thorpe, UP4: Phelps/Sky, UPX: Deion). %%
+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).
-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). %%
+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 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 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.
-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. %%
 ==== 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 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 103: / 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 ->