Zweiter Frühling für ION-Antrieb --- Sparta, Batavus, Koga ...

[Hochsitzcola]

Gab es auch ein foto von dein "setup"

Ich habe das Sparta ION gestern weiterverkauft. Nachdem hier (ausgenommen von dir) keiner Interesse gezeigt hat, fehlte mir die Motivation, die Kommunikation noch weiter zu analysieren um die Emulation soweit zu verbessern, daß der Motor unterstützt.
Ich hatte das Kabel zum Motor schlichtweg durchgekniffen und mit Lüsterklemmen wieder verbunden. An die Lüsterklemmen habe ich die Kabel vom "Sniffer" / Emulator parallel mit angeschlossen. Für die Emulation habe ich die 26V per Labornetzteil in den Superseal-Stecker eingespeist. Den USB-UART Converter habe ich nur ganz zu Anfang benutzt und bin dann recht schnell auf den ESP32 umgestiegen, der die Nachrichtenflut gleich "on the fly" analysiert und mit Zeilenumbruch und Checksummenüberprüfung aufbereitet an die USB-Buchse weiterleitet.
Der aktuelle Code für den ESP32 ist bei Github hochgeladen.
Vielleicht findet sich ja noch jemand, der auf Basis dieser Vorarbeit weiter macht, ich bin erst mal raus...

Gruß
hochsitzcola

 

[void-spark]

(Niederlandisch, also mein deutsch ist nicht gut, verontschuldigung )

Cool!
Ich wolte genau dasselbe machen.
Ich hoffe es ist mochlich ein kleines chip (atmel) zu programmiere das der batterie emuliert, so das ich einer eigener battery + bms darin setzen kann.
Hatte auch gedacht ein esp32 zu brauchen um zur der data zu gucken
War es nicht moglich der 'charging port' zu brauchen um mit de bus zu sprechen?
Hab mindest ein sparta ion hier, und mehrere batterien, und kan mehr ion's finden if notwendig.
Hatte auch probiert der eeprom in de batterie von der Atmega32 aus zu lesen, aber der lock bits ware geset (wuste ich schon, aber man mus etwas selber probieren ).

Denkst du es soll mochlich sein? Wann einge cryptographie dazu is wird es compliziert

Danke

 

[Hochsitzcola]

War es nicht moglich der 'charging port' zu brauchen um mit de bus zu sprechen?

Nur zum Lauschen geht das vielleicht, habe ich nicht ausprobiert. Mein Ziel war es aber ja, nur den Motor zu behalten und Batterie und Display zu ersetzen. Darum bin ich gleich an den Motorstecker gegangen, so konnte ich isoliert mit dem Motor "sprechen" ohne Nachrichten von der Batterie oder dem Display auf der Leitung zu haben.

Denkst du es soll mochlich sein? Wann einge cryptographie dazu is wird es compliziert

Ich habe schon eine ganze Menge über die verwendete Kommunikation gelernt, ob es nur eine Kleinigkeit ist, die noch fehlt, um den Motor zum Unterstützen zu bewegen, oder ob ein verschlüsselter Handshake fehlt, der nicht so leicht zu emulieren ist, weiß ich nicht. Ich hänge meine gesammelten logs vom Originalsystem mit Einschalten, auf Power stelllen, eine Zeitlang strampeln, dann ausstellen hier an, vielleicht findet ja jemand das fehlende Puzzleteilchen...
Die Rohdaten kann man in die Excel-Datei ION UART communication.xlsx reinkopieren, dann fällt die Analyse etwas leichter

Gruß
hochsitzcola

 

[void-spark]

Schritt eins, das soll zwischen der display und Akku gehen

Charging port war keine gute idee, das geht direkt zum Atmel in der Batterie, und nicht zum bus.

 

[void-spark]

Und jetzt gibt es data, mit einem ganz lange USB Schnur

 

[void-spark]

Hmm, ich denke ich verstehe der 'framing' ein wenig besser jetzt.

Es gibt 5 Nachrichten:
'0' - Hat nur ein target und kein data, meinst 'jetzt sind du dran'.
'4' - Hat source und target, aber kein data. Vielleicht 'bist du noch da'? Ist ein request, und die response sollte um die source zurückgehen
'3' - Hat source und target, aber kein data. Ist de response auf ein '4' bericht.
'1' - Hat source und target, und data. Der echte berichten. Ist ein request, und die response sollte um die source zurückgehen
'2' - Hat source und target, und data. Ist der response auf ein '1' Bericht

Wenn alles aktiv ist, geht das so:
Motor sendet ein '0' Bericht zum Batterie
Batterie sendet ein '0' Bericht zum Motor
etc. etc. etc.
Wann einer was zu sagen hatte, sendet er kein '0', aber ein '1' oder '4' Bericht.
Darauf kommt dan (möglich) ein '2' oder '3' Bericht von der Empfänger.
Un dann wird einer ein '0' Bericht gesendet.

Der display sendet nimmer ein '0' Bericht, nur der Motor und Batterie, der Display sendet nur replies zum '1' berichten.

Schreibe etwas zum Decodieren in python, das seht dan so aus (anschliesen der display nach der system in schlaf war, und er gibt ein einzelne '0' byte am start das nicht getönt wird):

tgt:MT typ:0        [10-00-b1]
tgt:DP typ:1 src:BT [10-c121-2280-5f] [2280] - Yo display 80
tgt:MT typ:0        [10-00-b1]
tgt:BT typ:0        [10-20-68]
tgt:DP typ:1 src:BT [10-c121-2280-5f] [2280] - Yo display 80
tgt:MT typ:0        [10-00-b1]
tgt:BT typ:0        [10-20-68]
tgt:MT typ:0        [10-00-b1]
tgt:BT typ:0        [10-20-68]
tgt:MT typ:0        [10-00-b1]
tgt:BT typ:0        [10-20-68]
tgt:MT typ:0        [10-00-b1]
tgt:BT typ:0        [10-20-68]
tgt:MT typ:0        [10-00-b1]
tgt:BT typ:0        [10-20-68]
tgt:MT typ:1 src:BT [10-0124-0914b009c4-e0] [0914b009c4]
tgt:BT typ:2 src:MT [10-2201-0900-d6] [0900]
tgt:MT typ:0        [10-00-b1]
tgt:BT typ:0        [10-20-68]
tgt:04 typ:4 src:BT [10-4420-19]
tgt:MT typ:0        [10-00-b1]
tgt:BT typ:0        [10-20-68]
tgt:04 typ:4 src:BT [10-4420-19]
tgt:MT typ:0        [10-00-b1]
tgt:BT typ:0        [10-20-68]
tgt:DP typ:1 src:BT [10-c129-26030cc000c000f09104-dc] [26030cc000c000f09104] - SET ASSIST LEVEL: 03, rest=0cc000c000f09104
tgt:BT typ:2 src:DP [10-22c0-26-d9] [26]
tgt:MT typ:0        [10-00-b1]
tgt:BT typ:0        [10-20-68]
tgt:MT typ:1 src:BT [10-0120-30-14] [30]
tgt:BT typ:2 src:MT [10-2200-30-8b] [30]
tgt:MT typ:0        [10-00-b1]
tgt:BT typ:1 src:MT [10-2104-089438283a-d7] [089438283a]
tgt:MT typ:2 src:BT [10-022b-080094384047283a3e651da8-85] [080094384047283a3e651da8]
tgt:BT typ:0        [10-20-68]
tgt:DP typ:1 src:BT [10-c121-2280-5f] [2280] - Yo display 80
tgt:BT typ:2 src:DP [10-22c2-220008-5c] [220008] - Yeah, have this 0008
tgt:MT typ:0        [10-00-b1]
tgt:BT typ:0        [10-20-68]

 

[Hochsitzcola]

Schreibe etwas zum Decodieren in python

Schön, daß du so tief einsteigst!
Wie die Nachrichten im Prinzip aufgebaut sind, hatte ich ja weiter vorn schon mal beschrieben:

Es wäre schön, wenn du deine Erkenntnisse in gleicher Form ergänzen würdest...
Bei einigen Nachrichten haben wir die Bedeutung einzelner Bytes im Payload schon zuordnen können, wie zum Beispiel Speed oder Tastendruck. Siehe auch meinen "Notizzettel.txt"

Gruß
hochsitzcola

 

[void-spark]

Ja, ich habe deine Beiträge gesehen, keine Duplizierung
Die neuen Dinge sind die Nachrichtentypen '0'/'3'/'4' und wie sich Nachrichten zeitlich aufeinander beziehen.
Es ist jedoch nicht einfach, in ein Bild zu passen
Ich werde jedoch die aktuelle Python anhängen. Ich empfehle nicht, es zu verwenden, aber es sollte interessant sein, es zu lesen

 

[TyraMisoux]

Ich hab hier noch ein noch älteres "Sparta emove" herumstehen. Hatte ursprünglich ne ähnliche Aktion geplant, dann aber gelesen, dass Display. Motor und Akku total verdongelt wären bei dem Modell. Heisst Du kannst von ausgehen dass diese "geheimnisvolle Abfrage mit der Seriennummer" - wenn es richtig gemacht ist noch mit einem Timestamp versehen, dass es nicht immer die gleiche Antwort ist, verschlüsselt beantwortet werden muss (oder eben umgekehrt, die Abfrage muss korrekt verschlüsselt sein, damit dann diese Antwort mit der Seriennummer kommt).
Das wird als "Diebstahlschutz" verkauft. Kannst also nicht mal eben ein anderes Display aufstecken und auch den Akku nicht benutzen.
Muss natürlich Service-Befehle geben mit denen man das ganze Zeug resettet und/oder Keys aufspielt.

Bei diesem emove ist der Controller in dem Direktläufer verbaut. Akku sind alte NICD Zellen und das Display fehlte komplett. Ich habs dann gelassen.
Gibt einen Thread dazu wo die dann die Wicklungen im Motor direkt anzapfen und mit extrem Kontroller dran gehen. Hatte meinen daraufhin auch mal zerlegt und den Controller herausgerupft. Der Motor taugt aber nichts viel so dass ich da kein Zeit reinstecken wollte.
Was mir gefällt ist das Open-Source Controller Projekt. Da gäbt es sooooooviel zu machen. Im Grunde ist das ganze E-Bike-Zeug noch ziemlich am Anfang. Mein schönes Farbdisplay hat verdammt nochmal nicht mal eine Uhr. Da fehlen tausend Nettigkeiten und man kann so viel machen.

Von dem emove hab ich derweil den Gepäckträger in Benutzung an einem anderen Rad. Ach ja, und den Sattel finde ich cool. Den nutze ich auch. Das wars dann aber auch schon. Der Rahmen steht da echt wie neu aber die 29" hatte ich auch nicht wirklich Bock was mit zu machen.

 

[Hochsitzcola]

aber es sollte interessant sein, es zu lesen

Ja, deckt sich ja mit meinen logs. Hast du schon eine Idee, wie sich die Antwort vom Display auf 10-c121-22 von der Batterie errechnet?! Kann schon sein, daß hier irgendwie ein Timestamp eingerechnet wird, wie @TyraMisoux vermutet.

dass es nicht immer die gleiche Antwort ist, verschlüsselt beantwortet werden muss

Ich hatte ja gehofft, daß dieser verschlüsselte Handshake hauptsächlich zwischen Batterie und Display stattfindet und der Motor nichts verschlüsseltes benötigt. Es gibt nach meiner Analyse ja auch nur eine einzige Nachricht vom Motor an das Display, die die Seriennummer des Displays abfragt.
Aber offensichtlich lauscht der Motor passiv mit und lässt sich nur zum Unterstützen bewegen, wenn der Datenverkehr zwischen Display und Batterie passt.
Ich habe es auf jeden Fall nicht geschafft, dem Motor diese Nachricht an das Display in meiner Emulation zu entlocken...

Gruß
hochsitzcola

 

[TyraMisoux]

Ich habe es auf jeden Fall nicht geschafft, dem Motor diese Nachricht an das Display in meiner Emulation zu entlocken...

Ich hab nur das Eine Log gesehen - gibt es da von Start zu Start Unterschiede oder läuft da immer das Gleiche Protokoll? Klar, akkuspannung die sicher irgendwo abgefragt wird, könnte sich unterschieden und sowas. Kannst das doch einfach mal komplett simulieren.
Klar, an dem Punkt wo Du bist, würd ich das jetzt auch nicht schmeissen sondern wollt noch was sehen

Die Idee, "dass der das Mitliest" klingt plausibel aber ist in der Praxis eher ungewöhnlich. Das Device reagiert auf seine Adresse und hat sich sonst totzustellen. was diese - ehm 4 und 6 waren es glaube ich sind ist noch ne Andere Sache. Könnte ja sowas wie ein "Security-Device" sein. Vielleicht haben aber auch die Hallsensoren ne eigene Elektronik. Da würd ich erstmal physikalisch eruieren wie das herkommt und eben einzelne Komponenten vom Bus nehmen.

 

[Hochsitzcola]

gibt es da von Start zu Start Unterschiede oder läuft da immer das Gleiche Protokoll

ich habe ja in #43 sechs logs angehangen, bei denen immer das gleiche Prozedere mitgeschrieben wurde. Einschalten, auf Stufe Power schalten, etwas strampeln, abschalten.
Zwischen Batterie und Motor gibt es diese ominösen Befehle 0x08 und 0x09 die irgendwie hochzählen, ob das der Kilometerstand oder die Tageskilometer oder sowas sind, habe ich nicht herausgefunden. Ansonsten ist die Kommunikation zwischen Batterie und Motor immer gleich.
Zwischen Batterie und Display gibt es eben diese 10-c121-22 Sequenz von der Batterie, auf die das Display immer was anderes antwortet...
Da ich das Rad aber weiter verkauft hab, kann ich hier nur noch theoretisch mitspielen

Gruß
hochsitzcola

 

[TyraMisoux]

Ja, so ein Zähler reicht da im Prinzip ja aus. Kann der dann mit nem Public-Key verschlüsseln und die Antwort wird mit dem Secret-Key wieder entschlüsselt und das Ergebnis muss diesem Zähler entsprechend. Zum Verifizieren ob es das ist müsste man an der Stelle die Kommunikation unterbrechen. Also die Antwort noch abgreifen aber verhindern dass sie ankommt. Dann weiss man für den nächsten Start was man braucht. Naja - vielleicht. Vielleicht wird er trotzdem wieder hochzählen und einen neuen Code erwarten.
Public-Key-Verfahren RSA oder so (würd ich da nehmen).
Naja, ist nicht so dass man die Chips nicht dumpen könnten. Kommt man schon ran. Ist aber mächtig aufwändig. Ganzen Scheiss dumpen und durch IDA ziehen
In dem Akku von dem Sparta sitz ein ATMEGA64L auf dem Controller. Der hat zwar ne Fuse um den Code zu schützen aber der lässt sich glitchen. Oft fehlen auch diesen Befehlsinterpretern jede Fehlerkorrektur, dann kannst den sagen "jetzt kommt ein Befehl mir 32KB Daten und kannst dann mal eben eigenen Code auf den Stack schieben von dem Ding und seriell den Inhalt dumpen.
Aber da brauchst Sportsgeist - und ob sich das lohnt ist die Frage bei der Gurke wo Du n Umbaukit mit offener Hardware für n paar Euro kriegst.
Seit bei den Chinesen alles für n Apfel und Ei kaufen kannst, hab ich mächtig die Lust verloren in sowas so viel Zeit zu stecken.

 

[void-spark]

Hast du schon eine Idee, wie sich die Antwort vom Display auf 10-c121-22 von der Batterie errechnet?! Kann schon sein, daß hier irgendwie ein Timestamp eingerechnet wird, wie @TyraMisoux vermutet.

Ich bin mir nicht sicher, aber diese Nachricht kommt alle 100 ms, und beide Seiten haben eine Nummer, die für jede Nachricht nur um eins hochzählt. Die Zahlen werden nicht einmal perfekt synchron gehalten, die Anzeige wiederholt manchmal dieselbe Zahl und die Anzeige zählt 00-ff, während die Batterie 00-0f zählt. Ich denke, es ist nur eine Möglichkeit, die beiden synchron zu halten oder sicherzustellen, dass das Display wach bleibt oder so ähnlich.

Ende des Wochenendes aber..

 

[void-spark]

In dem Akku von dem Sparta sitz ein ATMEGA64L auf dem Controller. Der hat zwar ne Fuse um den Code zu schützen aber der lässt sich glitchen.

Ich habe nach einer Beschreibung von jemandem gesucht, der dies tut, aber nichts für den ATMega32L oder -irgendein- atmega/avr gefunden

 

[Mike747]

Zum auslesen von ATMEGA64L: sind alle programma/code und data verschlusseld (fuses)? Oder sind zb die data von kms und (wichtig) fehlercode doch aus zu lesen und vielleicht anderbahr? Die accu-print ended sein "leben" mit E0003. Mocht die error-code "erase-bar" sein, konnte "defecte" batterien doch renoviert werden.

 

[void-spark]

Zum auslesen von ATMEGA64L: sind alle programma/code und data verschlusseld (fuses)? Oder sind zb die data von kms und (wichtig) fehlercode doch aus zu lesen und vielleicht anderbahr? Die accu-print ended sein "leben" mit E0003. Mocht die error-code "erase-bar" sein, konnte "defecte" batterien doch renoviert werden.

Nicht verschlüsselt, aber die Befehle (ISP oder ASM) zum Lesen/Schreiben des Flash/Eeproms werden durch die Lockbits deaktiviert. Es gibt zwei Teile, einen Bootloader und das eigentliche Programm, und das einzige, was erlaubt ist, ist das Schreiben des Programms (nicht des Bootloaders) mithilfe von Assembly, wodurch der Hersteller die Firmware aktualisieren kann. Um dies zu nutzen, benötigen Sie jedoch die Herstellersoftware, die eine Verbindung zur 'Homebase' benötigt. Angeblich kann das Eeprom, das ein wenig Daten aufnehmen kann, gelesen werden, nachdem Sie den Rest des Chips gelöscht haben, aber das ist nicht sehr nützlich. Auch Pufferüberläufe helfen nicht, da es eine Harvard-Architektur ist, mit separatem Programm (der Flash ) und Datenspeicher.

 

[TyraMisoux]

Auch Pufferüberläufe helfen nicht, da es eine Harvard-Architektur ist, mit separatem Programm (der Flash ) und Datenspeicher.

Bei den Grossen gehts. Hatte zuletzt mit einem AT32UC3256 zu tun und da code von nem Seriellen EEPROM ins RAM kopiert zum Ausführen. Die sind Linear durchadressiert. Bei den ganz Kleinen geht es aber nicht. Das ist richtig.
Und bei diesen ATMEGA weiss ich gar nicht.
Ja, da geht dann nur noch "Chip-Erase" wenn die Lockbits gesetzt sind. Verschlüsselt ist es nicht. Wenn man das schafft, dass er das Zeug auskotzt, wäre das schon klartext. Vermutlich spuckt er aber nur RAM-Inhalte.
Ich hab schon dumps gesehen von den Atmel. Weiss aber nicht genau wie die das machen

An Timestamps glaube ich nicht wirklich. Dazu bräuchte jedes Device nen halbwegs genauen Timer der permanent mitläuft. Eher unwahrscheinlich. Wie breit ist dieser Counter? Naja für 16 Bit alle möglichen Antworten dann in einer Tabelle ablegen bräuchte man schon nen grösseren Chip mit dem Platz. Aber machbar.
Mal schaun ob ich in den Logs noch was entdecke heuteabend.

 

[void-spark]

Kleiner Seitenschritt an diesem Wochenende, habe eine Batterie in besserem Zustand, die ich in mein Fahrrad einbauen wollte. Es stellte sich nur heraus, dass es nicht mit meinem Display sprechen möchte. (Fahrrad hat ein cu2v2-Display, die Meldungen, die ich auf dem Bus sehe, sind cmd '28', für die neueren cu3-Displays). Ich denke, der bms ist für einen Anzeigetyp programmiert und erkennt nicht automatisch. Frage mich, ob der Bikeshop eine Softwareversion installieren kann, die mit dem älteren Display funktioniert, 'downgrade'
Habe zumindest ein paar interessante Logs

 

[Mike747]

Fahrrad hat ein cu2v2-Display, die Meldungen, die ich auf dem Bus sehe, sind cmd '28', für die neueren cu3-Displays

schlägt. Laut EBCS-Info muss die Batterie G2xxxxx (oder höher) sein, um mit CU3 zu funktionieren. Meine Erfahrung ist, dass Batterien von G2 mit einer Sicherung auf 2 Drähten außerhalb des Gehäuses liegen. Software im Akku ist wahrscheinlich für cu2 und cu3 tatsächlich unterschiedlich. Übrigens: die erste Ziffer nach Gx ist das Baujahr des Akkus; zum Beispiel G509xxxxxx. Das gleiche gilt für die Motoren.