P65d Hacking
- Ersteller Ninebotblinker
- Erstellt am
- 22 Februar 2025
- 7
- 0
- E-Scooter
- G65D
- Telegram
- Bot
Ich habe nur den controller getauscht und das hat auch gerreicht. das dashboard ändert da garnichts an der Seriennummer oder FW. Einziges Problem, dass bisher der Scooter nicht über SHU oder ** Bezahlsoftware ** zu tunen ist. Man muss es mit einer chinesichen APK machen. Das was mich stört ist, dass man dann keinen Geheim Modus oder ander wichtige Modifikationen ändern kann.Woher kommt es das die Leute sagen man müsste Controller & Dashboard tauschen? Hab jetzt schon öfter hier & im ScooterHacking Discord gelesen das das deutsche Dashboard selbst bei internationalem Controller die Seriennummer angeblich wieder auf DE Region überschreiben würde aber hat das schon jemand probiert? Ich lese es immer nur als Fakt dargestellt ohne das mal jemand sagt wo diese Info überhaupt herkommt. Ich behaupte nicht das es garantiert nicht so ist aber wenn man sich anguckt wie das ganze bei den vorherigen Ninebot Modellen gelöst ist und wie sich die EU Modelle verhalten sobald man auf DE Region ändert legt für mich nahe das es einfach nur am Controller liegtWäre also eine Neuheit bei Ninebot das im Dashboard irgendeine Sperre wäre
Wäre interessant falls das mal jemand getestet hätte, dann könnte man sich den Dashboardtausch ja eventuell sparen
- 22 Februar 2025
- 7
- 0
- E-Scooter
- G65D
- Telegram
- Bot
Ja ich habe es heute mit conteroller tausch gemacht, es ist nicht so schwer, das tutorial ist aber ein wenig schwammig einfach auf yt gucken wegen controller austauch, den app vorgang steht in den commis von einem andere nforum kopiert. Man muss es dann mit einer Chinesischen app tunen, da SCU oder ** Bezahlsoftware ** wohl den Scooter noch nicht unterstützen, dadurch fallen dann natürlich auch ein paar Funktionen weg.
- 22 Februar 2025
- 7
- 0
- E-Scooter
- G65D
- Telegram
- Bot
Es werden einfach Kommentare gelöscht die evt. Relevant fürs Tuning ohne Controller wären lol nur weil eine Software erwähnt wird, hier wurde halt nicht mal dafür Werbung gemacht finde ich echt schade dass so die Meinungen unterdrückt werden
- 22 Februar 2025
- 7
- 0
- E-Scooter
- G65D
- Telegram
- Bot
Nein ich frage mich nur warum wird SHU erlaubt aber ** Bezahlsoftware ** nicht? Sind beides Tuning softwaren für escooter
- 22 Februar 2025
- 7
- 0
- E-Scooter
- G65D
- Telegram
- Bot
Haben die Entwickler die Scooter absichtlich gesperrt oder wie ?Richtig. Für die eine zahlt man Geld, für die andere nicht. Deswegen - und wegen anderenereien (Firmwaresperren u.Ä.) supporten wir die Software hier nicht. Wer Geld verlangt, kann seine Software ruhig selbst supporten.
- 22 Februar 2025
- 7
- 0
- E-Scooter
- G65D
- Telegram
- Bot
Hat es inzwischen schon jemand geschafft die Firmware aus dem Controller zu lesen? Also einen Dump zu machen?
Dann wäre es hier zu lesen. Also nein, nichts bekannt. Es besteht auch wohl bei den einschlägigen Gruppen kein Interesse an der P-Serie.
Hmm, das ist schade. Aber ich versucht trotzdem.
Es ist ja ein STM32F103 verbaut welcher mit RDP-1 gesichert ist. Also einfach auslesen ist da nicht.
Ich werd mal meinen Pico Pwner aus der Kiste holen und den STM runter löten. Vielleicht kommt man ja irgendwie dran.
Bisher tauschen ja alle die Controller und dann die Seriennummer. Das müsste ja auch anders gehen. Ist aber sicher sehr aufwendig.
Wenns nicht wieder 2 Jahre dauert bis ich hier wieder schreibe, könnte es vielleicht noch einige interessieren.
Es ist ja ein STM32F103 verbaut welcher mit RDP-1 gesichert ist. Also einfach auslesen ist da nicht.
Ich werd mal meinen Pico Pwner aus der Kiste holen und den STM runter löten. Vielleicht kommt man ja irgendwie dran.
Bisher tauschen ja alle die Controller und dann die Seriennummer. Das müsste ja auch anders gehen. Ist aber sicher sehr aufwendig.
Wenns nicht wieder 2 Jahre dauert bis ich hier wieder schreibe, könnte es vielleicht noch einige interessieren.
Das einfache Auslesen würde dich nicht weiter bringen.
Die RDP wird in den meisten Fällen aktiv, wenn der Controller zum ersten Mal gestartet wird.
Sagen wir mal, sie wäre nicht gesetzt und du könntest die Firmware auslesen, liegt diese immer noch verschlüsselt auf der MCU. Also sozusagen eine *.bin.enc.
Etwas mehr Arbeit ist sowas schon.
Die RDP wird in den meisten Fällen aktiv, wenn der Controller zum ersten Mal gestartet wird.
Sagen wir mal, sie wäre nicht gesetzt und du könntest die Firmware auslesen, liegt diese immer noch verschlüsselt auf der MCU. Also sozusagen eine *.bin.enc.
Etwas mehr Arbeit ist sowas schon.
Du meinst also dass Segway die Software verschlüsselt im STM32 abgelegt hat?
Das ist aber sehr ungewöhnlich. Der STM32F103 biete diese Funktion von Hause aus nicht. Sie müssten die Decryption also im Bootloader untergebracht haben und ständig in den Flash schreiben. Das halte ich für unwahrscheinlich. Der Flash würde so in kurzer Zeit sterben. Vielleicht wird das dann auch im RAM gemacht, der aber nur 20kB beträgt. Das Programm also nicht größer als 10kB sein könnte. Hast du da nähere Informationen drüber? Ich will mir ja die ganze Arbeit nicht umsonst machen.
Aber selbst wenn man nur das verschlüsselte Programm da raus holen könnte, wäre man einen Schritt weiter. Dann könnte man es in andere Controller schreiben. Mal abgesehen von der Version die man bekommt.
Dass der STM32 RDP-1 gesichert ist, steht ja schon mal fest. Das versuche ich ja zu umgehen. Dazu muss der STM32 aber aus der Schaltung raus.
Das ist aber sehr ungewöhnlich. Der STM32F103 biete diese Funktion von Hause aus nicht. Sie müssten die Decryption also im Bootloader untergebracht haben und ständig in den Flash schreiben. Das halte ich für unwahrscheinlich. Der Flash würde so in kurzer Zeit sterben. Vielleicht wird das dann auch im RAM gemacht, der aber nur 20kB beträgt. Das Programm also nicht größer als 10kB sein könnte. Hast du da nähere Informationen drüber? Ich will mir ja die ganze Arbeit nicht umsonst machen.
Aber selbst wenn man nur das verschlüsselte Programm da raus holen könnte, wäre man einen Schritt weiter. Dann könnte man es in andere Controller schreiben. Mal abgesehen von der Version die man bekommt.
Dass der STM32 RDP-1 gesichert ist, steht ja schon mal fest. Das versuche ich ja zu umgehen. Dazu muss der STM32 aber aus der Schaltung raus.
Meine Aussagen sind nicht geraten, sagen wir es mal so.
Auch beim G30D (nicht G30 D2) kam die STM32 MCU zum Einsatz.
Dort liegt jede Firmware auf dem Controller ebenfalls in verschlüsselter Form vor.
Also nicht so, wie du es vielleicht von den DRV.bin's kennst.
Das ist also nichts neues.
Auch beim G30D (nicht G30 D2) kam die STM32 MCU zum Einsatz.
Dort liegt jede Firmware auf dem Controller ebenfalls in verschlüsselter Form vor.
Also nicht so, wie du es vielleicht von den DRV.bin's kennst.
Das ist also nichts neues.
Es ist technisch nicht machbar. Der STM32F103 kann keine Kryptographie. Er hat einfach nicht die Möglichkeit den Code im Flash zu entschlüsseln.
Das Programm liegt hier ganz normal im Flash und wird durch den RDP1 gesichert.
Ich lasse mich ja gerne eines Besseren belehren, dann musste aber schon mit der Sprache rausrücken!
Einfach nur behaupten dass das so sei, kann ja jeder.
Vielleicht kannst du das etwas genauer erklären, was du so herausgefunden hast und wie. Mich interessieren solche Dinge immer brennend.
Wie dem auch sei, ich werde am Dienstag den STM32 mal auslöten und mit dem Pico Glitcher bearbeiten. Vielleicht spuckt er ja den Flashinhalt aus.
Danach sehen wir weiter.
Das Programm liegt hier ganz normal im Flash und wird durch den RDP1 gesichert.
Ich lasse mich ja gerne eines Besseren belehren, dann musste aber schon mit der Sprache rausrücken!
Einfach nur behaupten dass das so sei, kann ja jeder.
Vielleicht kannst du das etwas genauer erklären, was du so herausgefunden hast und wie. Mich interessieren solche Dinge immer brennend.
Wie dem auch sei, ich werde am Dienstag den STM32 mal auslöten und mit dem Pico Glitcher bearbeiten. Vielleicht spuckt er ja den Flashinhalt aus.
Danach sehen wir weiter.
Erstens bin ich hier nicht jeder und zweitens muss ich hier niemandem etwas erklären.
Bin nur so ein dusseliger Moderator, der viele Tutorials über diesen Käse geschrieben hat.
Möglicherweise hat die Geschichte mit der Verschlüsselung auch erst mit der Einführung des AT32 angefangen.
Da ich momentan keinen Zugriff auf meinen Rechner und mein DevKit habe, kann ich das momentan leider nur aus dem Gedächtnis herauskramen.
Hier kommen wir also momentan nicht weiter.
Wenn du aber so einen großen Wissensstand hast, wie du mir verkaufen möchtest, weshalb musst du dann die MCU auslöten?
Ich wünsche dir jedenfalls viel Erfolg bei deiner Arbeit.
Bin nur so ein dusseliger Moderator, der viele Tutorials über diesen Käse geschrieben hat.
Möglicherweise hat die Geschichte mit der Verschlüsselung auch erst mit der Einführung des AT32 angefangen.
Da ich momentan keinen Zugriff auf meinen Rechner und mein DevKit habe, kann ich das momentan leider nur aus dem Gedächtnis herauskramen.
Hier kommen wir also momentan nicht weiter.
Wenn du aber so einen großen Wissensstand hast, wie du mir verkaufen möchtest, weshalb musst du dann die MCU auslöten?
Ich wünsche dir jedenfalls viel Erfolg bei deiner Arbeit.
Das kann ich dir gern erklären.
Um den RDP1 zu umgehen muss man den Chip aus dem Board auslöten.
Das liegt an der Beschaltung auf dem Board. Für einen erfolgreichen Glitch muss man an die Pins: NRST,BOOT0,BOOT1, UART1 2 oder 3, GND und VDD ran. Ebenso die SWCLK und SWDIO.
VDD,GND,SWDIO und SWCLK sind vom Herssteller schon herausgeführt. Das reicht für eine Programmierung auch völlig aus. Da der Chip aber eine RDP1 Protection aktiviert hat, müssen wir auch an die anderen Pins. Besonders der BOOT1 Pin ist hier das Problem. Er ist auf dem Controller fest auf GND gelötet. Wir müssen für den Glitch aber ein kleines Programm in den SRAM schieben. Dieses kann nur ausgeführt werden, wenn man beide BOOT Pins beim Starten auf high legt. Man könnte die Pins auch ablöten und hochbiegen, aber dabei brechen die Beinchen sehr gerne mal ab. Ebenfalls ist VDD also 3,3V ein Problem. Beim Voltage Glitching lässt man die Spannung immer mal wieder etwas einbrechen. Durch die auf dem Board vorhandenen anderen Komponenten wie Spannungsregler und vor allem Kondensatoren, ist das nicht zuverlässig möglich.
Ich will hier aber keine wissenschaftliche Abhandlung zur Umgehung von Sicherheitseinrichtungen geben. Das führt dann sicher zur Sperrung des Beitrags.
Bisher hat noch kein STM32F1xx seine Geheimnisse bewahrt auf meinem Schreibtisch. Wäre schon cool, wenn man wenigstens an den Flash kommt um zu sehen was drin steckt. Ob man das am Ende dekompilieren kann oder sogar ändern und wieder flashen, steht auf einem anderen Blatt.
Ich wollte nur sicher gehen, dass das beim P65(D) nicht schon wer gemacht hat, es nur nicht verraten will.
Um den RDP1 zu umgehen muss man den Chip aus dem Board auslöten.
Das liegt an der Beschaltung auf dem Board. Für einen erfolgreichen Glitch muss man an die Pins: NRST,BOOT0,BOOT1, UART1 2 oder 3, GND und VDD ran. Ebenso die SWCLK und SWDIO.
VDD,GND,SWDIO und SWCLK sind vom Herssteller schon herausgeführt. Das reicht für eine Programmierung auch völlig aus. Da der Chip aber eine RDP1 Protection aktiviert hat, müssen wir auch an die anderen Pins. Besonders der BOOT1 Pin ist hier das Problem. Er ist auf dem Controller fest auf GND gelötet. Wir müssen für den Glitch aber ein kleines Programm in den SRAM schieben. Dieses kann nur ausgeführt werden, wenn man beide BOOT Pins beim Starten auf high legt. Man könnte die Pins auch ablöten und hochbiegen, aber dabei brechen die Beinchen sehr gerne mal ab. Ebenfalls ist VDD also 3,3V ein Problem. Beim Voltage Glitching lässt man die Spannung immer mal wieder etwas einbrechen. Durch die auf dem Board vorhandenen anderen Komponenten wie Spannungsregler und vor allem Kondensatoren, ist das nicht zuverlässig möglich.
Ich will hier aber keine wissenschaftliche Abhandlung zur Umgehung von Sicherheitseinrichtungen geben. Das führt dann sicher zur Sperrung des Beitrags.
Bisher hat noch kein STM32F1xx seine Geheimnisse bewahrt auf meinem Schreibtisch. Wäre schon cool, wenn man wenigstens an den Flash kommt um zu sehen was drin steckt. Ob man das am Ende dekompilieren kann oder sogar ändern und wieder flashen, steht auf einem anderen Blatt.
Ich wollte nur sicher gehen, dass das beim P65(D) nicht schon wer gemacht hat, es nur nicht verraten will.