Hallo, ich würde gerne die Software von einem elektrischen Skateboard auslesen und verändern, ist es möglich den Code vom kombinierten Empfänger und ESC auszulesen ? Falls ja würde ich die Elektronik demontieren und schauen welcher Mikrocontroller verbaut wurde.
Heckmann M. schrieb: > ist es möglich den Code vom kombinierten Empfänger und ESC auszulesen ? Nur, wenn 1. das überhaupt ein programmierbarer uC ist und 2. der Hersteller so dumm war, die Security-Bits nicht zu setzen. Davon solltest du aber nicht ausgehen.
Also ich würde locker 20€ drauf setzen, dass der Hersteller Einen uC mit Schutz gegen auslesen genommen hat und den Schutz natürlich auch nutzt. Je nach Bauteil lesen das die Chinesen für teuer Geld trotzdem aus, lohnt aber normal nicht. Was willst du denn ändern? Etwa böse Dinge wie maximale Geschwindigkeit?
> ist es möglich den Code vom kombinierten Empfänger und > ESC auszulesen ? Nein. Und selbst wenn, jemand der solche Fragen stellt koennte damit sowieso nichts anfangen. Ich schaetze mal wenn 1985 noch 50-90% der Entwickler ein Binary haetten dekodieren koennen, so sind es heute hoechstens noch 1-5%. Olaf
Ich frag mal konkret: Kann man ein STM32 XXX auslesen? Wenn ja, wie? Und wie kann mann dann das HEX File in ein lesbares Code umwandeln? Wie kann man das Auslesen bei einem STM32 XXX verhindern?
Micro C. schrieb: > Und wie kann mann dann das HEX File in ein lesbares Code umwandeln? Definiere "lesbar" und definiere "Code".
Micro C. schrieb: > wie kann mann dann das HEX File in ein lesbares Code umwandeln? mit einem Disassembler https://de.wikipedia.org/wiki/Disassembler das disassemblieren ist unter Umständen genau so aufwändig, wie aus der Frikadelle das Schwein wieder zurück zu konstruieren
Micro C. schrieb: > Wenn ja, wie? Und wie kann mann dann das HEX File in ein lesbares Code > umwandeln? Was ist für dich lesbar? Volldokumentierter Quellcode in einer Hochsprache wird dabei wohl kaum herauskommen. Schreib oder besorg dir ein LED-Blink-Programm für die entsprechende Chipfamilie und versuche das mal zu lesen bevor du das Teil zerpflückst.
Tom schrieb: > http://www.st.com/web/en/resource/technical/document/application_note/DM00033344.pdf Ende der Einleitung: "For more details about the complete solution, please contact your local ST sales representative." Liest hier jemand mit, der schonmal gefragt hat?
Das ist in Anbetracht der systemimmanenten Probleme jetzt reichlich irrelevant, oder? Egal welcher Microcontroller es ist, selbst wenn kein Ausleseschutz vorhanden sein sollte, der Versuch, aus Binärcode ein les- und änderbares Programm zu rekonstruieren, ist proportional zur Größe des Programmes und zur Komplexität des Prozessorkerns steigend zum Scheitern verurteilt, insbesondere, wenn man nicht schon ein paar Jahre Erfahrung in der Assemblerprogrammierung auf dem gegebenen Controller hat. Ein 2kByte-Programm für einen 8051 kann man mit viel Aufwand sicherlich noch nachvollziehen, aber ein paar-hundert-kByte-Programm für einen ARM ganz sicher nicht mehr.
Rufus Τ. F. schrieb: > Ein 2kByte-Programm für einen 8051 kann man mit viel Aufwand sicherlich > noch nachvollziehen, aber ein paar-hundert-kByte-Programm für einen ARM > ganz sicher nicht mehr. Wobei zu fragen wäre, für was ein skateboard mehrere HundertK code bräuchte. Wenn dann ist sicher ein Grossteil Daten - Kennlinienfeld und so. Damit wäre der zu dissassemblierende Code deutlich kleiner. MfG,
Was kann denn dein Board? Ich wette, dass man das zehnmal schneller nachprogrammirt als den Code zu verstehen und hinzudrehen
Fpga K. schrieb: > Rufus Τ. F. schrieb: > >> Ein 2kByte-Programm für einen 8051 kann man mit viel Aufwand sicherlich >> noch nachvollziehen, aber ein paar-hundert-kByte-Programm für einen ARM >> ganz sicher nicht mehr. > > Wobei zu fragen wäre, für was ein skateboard mehrere HundertK code > bräuchte. > > Wenn dann ist sicher ein Grossteil Daten - Kennlinienfeld und so. Damit > wäre der zu dissassemblierende Code deutlich kleiner. > > MfG, Och, man muss nur die richtigen Frameworks verwenden um die paar Funktionen "zusammen zu klicken" und dazu noch irgendein OS und schon sind aus einer handvoll Bytes die minimal notwendig wären zig KByte geworden. Ist heutzutage ja echt "In" sowas. Und das ganze dann noch mit z.B. den Kannlinien usw. zu einem einzigen Binaryklumpen zusammen gepanscht und jemand ist schon ewig damit beschäftigt überhaupt erstmal zu sortieren was ist gültiger Programmcode und was sind Daten die nicht disassembliert werden dürfen...
Lothar M. schrieb: > Hersteller so dumm war, die Security-Bits nicht zu setzen. Im Gegenteil, wenn der Hersteller schlau ist und was verkaufen will dann macht er sein Gerät modding fähig. Sowas spricht sich herum und erhöht die Verkaufszahlen. Wenn ich sowas bauen würde dann gäbe es den Quellcode kostenlos dazu, es ist ja nicht so dass da 100 Mannjahre an Arbeit dahinterstecken. Aber zur Frage, wer Fragen muss ob es geht der kann nichts daran ändern, jemand der es kann muss unverhältnissmässig viel Arbeit und evtl. Geld reinstecken(z.B. für abschleifen und auslesen lassen)
Chr. M. schrieb: > Im Gegenteil, wenn der Hersteller schlau ist und was verkaufen will dann > macht er sein Gerät modding fähig. Das funktioniert dann aber nicht übers Auslesen und Disassemblieren, sondern über das "zufällige" Leaken eines Quellcodes (gerne auch älter und etwas buggy über möglichst dubiose Kanäle), wo sich dann ein paar Hacker dran austoben können. Und dann ist auch ein Ausleseschutz kein Problem mehr, weil man den Controller ja neu programmieren kann...
:
Bearbeitet durch Moderator
Chr. M. schrieb: > Lothar M. schrieb: >> Hersteller so dumm war, die Security-Bits nicht zu setzen. > > Im Gegenteil, wenn der Hersteller schlau ist und was verkaufen will dann > macht er sein Gerät modding fähig. > Sowas spricht sich herum und erhöht die Verkaufszahlen. Na dann musste Apple und Co längst Pleite sein. Bei "Modding" verliert man auch die Garantie und ggf auch die Zulassung für das Gerät. Es hat schon gute Gründe warum man Nicht-Fachleuten das rumschrauben am Gerät erschwert. MfG,
>Bei "Modding" verliert man auch die Garantie und ggf auch die Zulassung >für das Gerät. >Es hat schon gute Gründe warum man Nicht-Fachleuten das rumschrauben am >Gerät erschwert. Was ist denn jetzt so nachteilig für den Hersteller, wenn der Käufer die Garantie verliert? Ich würde das auf jeden Fall als Vorteil verbuchen. Der ggf. Entzug der Zulassung betrifft den Hersteller auch nicht, sondern nur das Gerät des Kunden und dürfte damit den Hersteller auch nicht interessieren. Er liefert seine Geräte ja mit Zulassung aus. So lange kein Kostengünstigerer Nachbau dadurch in den Umlauf gebracht wird, ist der Hersteller immer der Gewinner.
Wegstaben V. schrieb: > Micro C. schrieb: > wie kann mann dann das HEX File in ein lesbares Code umwandeln? > > mit einem Disassembler > https://de.wikipedia.org/wiki/Disassembler > > das disassemblieren ist unter Umständen genau so aufwändig, wie aus der > Frikadelle das Schwein wieder zurück zu konstruieren was hab ich jetzt gelacht??
Nicht 100%-tig OnTopic und relativ lang: https://youtu.be/JZ3EB68v_B0 Ich fand den Vortag aber interessant und er zeigt, dass man nicht unbedingt direkt an die Firmware muss um mit den Teilen Schabernak zu treiben ;)
@ Autor: Micro Controller (fischgebruell) Wenn du zwei Paar Hosen hast, dann verkaufe eins und erstehe diesen Emulator: www.ebay.de/itm/ST-LINK-V2-ST-LINK-STM8-STM32-kompatibler-Emulator-USB-P rogrammer-Debugger-/401080063158 Wenn der Controller nicht geschützt ist, dann hast du Glück gehabt.
Heckmann M. schrieb: > ich würde gerne die Software von einem elektrischen Skateboard auslesen > und verändern, ist es möglich den Code vom kombinierten Empfänger und > ESC auszulesen ? Falls ja würde ich die Elektronik demontieren und > schauen welcher Mikrocontroller verbaut wurde. Hi Markus, mach doch bitte mal Bilder von der gesamten Maschinerie: - Skateboard / ESC (Hersteller/Typ) - Leiterplatte (oben/unten) - Motor (Typenschild?) - Akku (Typenschild?) Anhand derer können Spezialisten wie z.B. Max D. schrieb: > Was kann denn dein Board? Ich wette, dass man das zehnmal schneller > nachprogrammirt als den Code zu verstehen und hinzudrehen eine Aufwandsabschätzung machen, wie lange sie für den Nachbau der Firmware brauchen. Ich meine, an dem Controllerprogramm ist doch bestimmt nix dran, oder? Ich vermute nur ein bisserl BLDC Ansteuerung, dazu ein wenig Drahtlostechnik. Hier sieht man auch warum der Wurstvergleich hinkt: Wegstaben V. schrieb: > das disassemblieren ist unter Umständen genau so aufwändig, wie aus der > Frikadelle das Schwein wieder zurück zu konstruieren Hier werden verschiedene Fähigkeiten gebraucht. Für einen Biotechnologen, will meinen versierten Firmwareentwickler, kann es deutlich leichter sein, den Hexdump zum Schwein zu machen, als mal eben eine BLDC Ansteuerung und ein Funkübertragungsprotokoll für eine nicht komplett bekannte Hardware zu implementieren. Olaf schrieb: > ...Ich schaetze mal wenn 1985 noch 50-90% der Entwickler > ein Binary haetten dekodieren koennen, so sind es heute hoechstens noch > 1-5%. Naja, noch sind wir nicht alle tot, die in den 80ern einen Homecomputer hatten. Aber Dein Vergleich ist recht brauchbar: Wenn der TO sein Rollbrett pimpen will, dann entspricht das dem Einfügen eines "Cheatcodes" in ein altes 8bit Spiel, z.B. für ewig Leben (oder auch verkürztes Leben, hängt an den motorischen Skills des Bastlers). Das "zehnmal schneller" Nachprogrammieren entspricht dann einem "ich habe das Spiel von außen gesehen und baue es nun von unten her so auf, wie es mir gefällt". Diese Einstellung hat uns hunderte Asteroids-, Pacman- und Arkanoid-Clones gebracht. Ich würde mich sehr über die Bilder vom Brett freuen, weil ich in absehbarer Zeit sowas nicht in die Hand bekommen werde. Grüße, marcus
Marcus H. schrieb: > Olaf schrieb: >> ...Ich schaetze mal wenn 1985 noch 50-90% der Entwickler >> ein Binary haetten dekodieren koennen, so sind es heute hoechstens noch >> 1-5%. > Naja, noch sind wir nicht alle tot, die in den 80ern einen Homecomputer > hatten. Ja, aber ob deren Anteil bei 1-5% liegt darf bezweifelt werden - schließlich sind die 80iger seit 3 Jahrzehnten vorbei. Und davon hat nur ein Teil seinen Computer per dissassembler/"Action Replay modul" ergründet - die meisten haben gedaddelt. Statt alleiniges auslesen ist man hier eh besser beraten Reverse Engineering am lebenden Object zu betreiben. Beispielsweise den Controller zu entnehmen und auf eine Zwischenplatine setzen und nur die I/O zu manipuliern die getunt werden sollen. So hat man es damals mit macrovision gemacht.
Wobei man allerdings auch sagen muss, dass bei diversen Herstellern ebenfalls oft genug nur mehr Leute sitzen, die ausser "irgendwas zusammenklicken" wenig auf der Pfanne haben. Da kocht man oft auch nur mit sehr gewöhnlichem Leitungswasser. Und das macht wiederum das Lesen der Disassembly leichter, weil Compiler nunmal relativ vorhersagbaren Code liefern. Haste ein gesehn, haste alle gesehn. Dass dahinter noch irgendwelche handgegriffelten ASM-Routinen kommen gibt's doch heute fast nicht mehr. Besonders bei billiger Massenware.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.