Ne alles entspannt
ich mag Technik, Elektronik im speziellerem und eben auch wie diese funktioniert, ergo das ist mein Hobby
Wegen dem Link, kam mir jetzt nicht direkt illegal oder so vor, einfach ein BMS Hersteller der seine Software anbietet, meinst die ist problematisch?
Ich war damals natürlich auch neugierig und habe die APK vom H2 gezogen, aber ich konnte mich nicht einloggen, weil der gemotzt das ihm die Device Serial unbekannt vorkäme.
Es ließt die Seriennummer des Android Gerätes aus, kann man bestimmt alles spoofen
aber dann müsste jemand ja seine Serial eines Gerätes "opfern". Wenn ihr da weiter gekommen seit, topp! Bezüglich offline... also ich war als ichs bekommen hatte bei mir daheim im WLAN, es ist dünn auf dem Hof ja, aber es geht halbwegs. Da ich daheim in meiner Firewall nicht alles erlaube, war der MQTT(S) Port gesperrt, der H2 war online konnte auch Diagnosen auswählen, aber es gab einfach keine Verbindung zum Roller, war schon am Verzweifeln bis ich über den Menüpunkt Server Status gestolpert bin dort wurden zwei TLS Verbindungen angezeigt und MQTT rot. Hab mir nichts dabei gedacht, bis ich dann MQTT erlaubt habe und erst dann hat es funktioniert.
Ich hab noch kein Man-in-the-Middle probiert, aber ich könnte mir vorstellen, dass was gemacht werden soll an die Cloud geschickt wird und diese dann via MQTT die Befehle auf den eigentlichen USB Schwengel gesendet wird. Weil sobald das WLAN zu dünn wird, bricht die Verbindung ab bzw. es kommt nichts mehr "vom Roller an". Wenn eine der TLS oder HTTPS Verbindung getrennt wird, beendet sich die App instant.
Also wenn ihr die App ans rollen gebracht habt, dann sollte auch flashen drin sein
H1 ist RS485 (definiert nur die elektrischen Parameter, Layer 1) und dort wird ja ein eigenes Protokoll gesprochen, was bedeutet man müsste erstmal herausfinden wie das eigentlich funktioniert, Preämbel, Startbits, Stoppbits, Länge, Adressierung, Nutzdatenbereiche, Prüfsumme usw. wenn man soweit ist kann man dann Gemeinsamkeiten analysieren.
Hat die Batterie immer die gleiche Adresse oder Nutzdaten (die aus Befehlen und sonstwas bestehen können) etc..
Deswegen hab ich beim NPro auch nichts diesbezüglich unternommen, zu mal es auch ja schon Software und ein Arduinoprojekt gab, um die kostbaren Batterien auszulesen. Das Projekt hab ich mir angeschaut, im Prinzip werden da diverse Befehle gesendet und es wird auf eine bestimmte Antwort innerhalb einer bestimmten Zeit gewartet und ausgewertet, eine komplette Protokollbeschreibung ist dies nicht, daher funktioniert das Tool auch nicht am Roller selbst.
Der CAN Bus elektrisch gesehen ist auch nur RS485 (Twisted Pair, Differential Signaling), allerdings wenn man CAN benutzt verbaut man nicht nur den Transreceiver IC, sondern dazu kommt noch ein CAN Controller der via SPI, I2C, UART oder auch per USB Tunneling an die Anwendung angebunden wird. Das hat den extrem Vorteil, dass du dich in deiner Anwendung bezüglich Kommunikation um "nichts" mehr kümmern musst, die Daten die versendet werden sollen, werden dem Controller einfach in dessen Warteschlange gesendet, dieser kümmert sich um den Versand, Collision Detecting, Resend und der gibt dir an deine Anwendung zurück ob es erfolgreich versendet worden ist. Des weiteren gibt es diverse Statusmeldungen wie die Last oder auch diverse Busfehler.
Da ich in früheren Projekten auch mal über längere Strecken kommunizieren wollte, hab ich das auch mit RS485 gemacht, allerdings kein eigenes Protokoll entwickelt, sondern auf das freie Modbus zurückgegriffen. Dies ist aber auch recht simpel aufgebaut und ums Timing, Collision detection und resending muss man sich in der Anwendung kümmern, was auch Ressourcen verbraucht.
Deswegen hab ich erst jetzt mit dem reverse engineering angefangen, zum einen da es für EVO noch nichts gab und ich auf eine genormte Übertrangungsschicht setzen und direkt mit der Nutzdatenanalyse starten konnte.
Der USB Schwengel hat bestimmt auch irgendeine "tolle" Firmware, von daher vermute ich das die HEX Befehle nicht direkt 1:1 in CAN umgesetzt werden, aber ich habs mir noch nicht angeschaut. Der USB Adapter wird ansonsten also normaler USB-Serial-Wandler erkannt. Ich hab die Kommunikation auf dem CAN selbst zwischen H2 und Batterie(n) angeschaut und eine Open Source Lösung gebaut, die sogar noch ein paar Daten mehr wie das H2 darstellen kann, dadurch würde der Bedarf im Bereich der Batteriediagnose schonmal "reduziert".
Am laufenden Roller direkt diverse Meldungen zu erkennen ist auch nicht unbedingt einfach, wesentlich einfacher als im Auto da dort wesentlich mehr los ist. Aber man kann nicht immer davon ausgehen das die Daten wie Messwerte oder eben die Uhrzeit "nackig" übertragen wird. Vor allem im Autobereich werden oft Offsets und Multiplikatoren verwendet, was es echt nicht einfach macht.
Was es effizienter macht ist es, wenn man eben einzelne Komponenten auf dem Tisch liegen hat. Bestes Beispiel die Batterien, der H2 zeigt alle Werte an, ich hab nur den H2 und einen Akku angeschlossen, das heißt ich MUSS alle diese Werte auf den dutzenden CAN Meldungen wiederfinden, egal wie
In deinem Fall wäre es sinnvoll eine ECU und das Dashboard "auf den Tisch zu legen". Als erstes würde ich mal nur das Dasboard bestromen und schauen ob die Uhrzeit selbstständig weiterläuft. Wenn ja weißt du das die RTC (Real Time Clock) im Dashboard verbaut ist und diese "nur" gestellt werden muss, das heißt es wird ein Befehl mit der aktuellen Uhrzeit versendet und die eingebaute RTC zählt selbst weiter. Das wäre der Idealfall.
Falls keine Uhrzeit oder nur blinken oder sonstwas angezeigt wird, weißt du schon das das Dashboard blöd ist und nur Daten anzeigt die per RS485 reinkommen. Das wäre blöd, denn wenn du selbst die Uhrzeit senden musst, kollidiert das mit den ECU Paketen. Es wird dann im Wechsel deine gesendete und die von der ECU gesendeten Zeiten angezeigt.
Egal wie, geht es weiter ECU einschalten und schauen was passiert, wenn dann eine Zeit angezeigt wird (egal ob korrekt oder nicht), gillt es irgendwie diese Werte auf dem RS485 zu finden, wenn man diese vermeintlich gefunden hat (Protokoll!) versuche diese selbst zu senden und versuchen die Werte zu ändern und schauen was passiert. Dazu muss man die wie Batteriejungs mit ihrem Projekt nicht das ganze Protokoll reversen, aber es erfordert aufjeden Fall bestimmt eine Art Checksumme um die Integrität der Datenpakete nachzuweisen und selbst wenn du das gefunden hast, kann es trotzdem sein das die ECU die Uhrzeit-Stellen Pakete ständig sendet und somit eine ggf. korrekt eingestellte Zeit wieder überschrieben wird. Um das zu Unterbinden könnte man eben ein Mikrocontroller dazwischen als Bridge einbauen, der alle Pakete durchlässt außer die Uhrzeit- oder Uhrzeit-Stellen Pakete, diese werden dann von ihm selbst gesendet, dazu müsste man aber das Protokoll leider etwas besser kennen.
Also das ganze Reverse Engineering ist im Prinzip: Eine große Blackbox auf mehere kleinere Blackboxen aufzuteilen und mittels bisschen rechnen, logischem Denken und auch viel Try and Error diese Böxchen zu lüften, praktisch wie ein Puzzle für Freaks oder so
Obwohl man muss nicht unbedingt ein Freak sein.. ein kleines Beispiel ich bin aktuell dran das Easylink (Renaults Multimedia System) zu knacken, erste Hürde war es auf dem Tisch zum laufen zu bekommen, hab die CAN Nachrichten gefunden um es anzusteuern, da es VIN Locking hat, hat es gesperrt angezeigt. Diese CAN Nachricht habe ich auch gefunden, da es aus meinem Auto war musste ich es nur senden und es startete. Ich wollte aber wissen wie die Nachricht aufgebaut war, zum Beispiel um eine auf eBay zu kaufen und diese zu starten. Ich bin einfach nicht dahinter gekommen, habs einem Kumpel gezeigt hier ist die VIN, das ist der CAN frame, er dann kurz drüber geschaut und gesagt "Bischd blind! Das ist die VIN rückwärs und ein F hinten dran"
)