Schöne Analyse! Den Baro-Sensor konnte man aber bereits früher aus den Bildern im Beitrag „Runner 250 MultiWii Flugsteuerung von innen” verorten. Dort ist auf der Oberseite des Boards eine Bestückungssfläche für ein 8‑poliges SMD Bauelement zu erkennen. Die Beschaltung passt für den Baro-Sensor MS5611-01BA01. Ich habe den Sensor mal nachgerüstet. Leider scheint die frühere Firmware den Sensor nicht zu unterstützen (was nicht verwundert, da er ja serienmäßig nicht bestückt ist), jedenfalls erkennt die MultiWiiGUI das Vorhandensein des Sensors nicht. Es muss also eine neue Version des Flugcontrollers verbaut sein, die wahrscheinlich auch eine neue Bestellnummer erhalten wird. Wäre schön, wenn mal jemand den neuen Flugcontroller öffnen und ein paar Fotos von beiden Bestückungsseiten schießen würde. Dann könnte man zweifelsfrei feststellen, ob sich der neue Controller nur durch die Bestückung des Baro-Sensors unterscheidet, oder ob das Board gegenüber der Vorversion auch anderweitig verändert wurde. Rein technisch ist der Runner-Controller eine zugeschnittene und abgespeckte Version des AIOP-Controllers von Crius/HobbyKing. Es wurden quasi die gleichen Komponenten verbaut.
Es ist sehr angenehm, einen sehr kompetenten Mitstreiter zu sehen 🙂
Ich öffne sehr gerne den neuen Controller und mache Fotos!
Ich habe auf den alten Controller über SPI die neue MultiWii mit der AIOP Konfiguration aufgespielt, allerdings scheinen da die Ein- und Ausgänge nicht zu stimmen. Da das Pinout noch nicht bekannt ist, gestaltet sich die Suche nach den richtigen Ausgängen schwierig. Oder ich habe sonst wo einen Fehler gemacht. Hatte noch keine Zeit da weiter zu machen. Es würde mich freuen, wenn du da auch mithackst 🙂
Hallo Gektor, wenn man einen Atmel-Programmer an den Programmierstecker des Runner-Conrollers anschließt (was Du ja wohl auch gemacht hast) kann man zwar die Fuses auslesen, der Programmcode ist allerdings per Lock-Bits maximal gegen Auslesen und Verifizieren sowohl des Flash-Speichers, als auch des EEPROMS geschützt. Das Aufspielen einer anderen Firmware (z. B. der original MultiWii-Firmware) ist daher eine Einbahnstraße, von der es kein Zurück mehr gibt, wenn man nicht eine Originalfirmware des Runners von Walkera als Binärcode-Datei bekommt (und den geben die ja wohl nicht heraus). Das ist es, was mich bisher noch davon abhält, denn genau dieselbe Idee einen zugeschnittenen MultiWii-Code mal zu probieren hatte ich auch schon. Wenn ich zwischendurch mal nicht weiß, was ich tun soll 🙂 gebe ich mich mal daran den Schaltplan des Runner-Controllers zu extrahieren. Das ist zwar per Durchklingeln mühsam und fehlerträchtig (eigentlich müsste man alle Komponenten vom Board extrahieren um sicher sein zu können) aber das ist ja Hobby und allemal besser als Briefmarken sammeln.
P.S.: Da ich’s bisher noch in keinem Beitrag gelesen habe und es vielleicht den einen oder anderen interessiert: Ich habe den in der Betriebsanleitung unkommentierten 4‑poligen Stecker (nach vorheriger Prüfung der Belegung) mal an das Programmer-Tool von Walkera angeschlossen und der Flugcontroller hat sich in der Programmer-GUI als „Runner 250” zu erkennen gegeben. Diese Schnittstelle dient also dem Firmware-Upgrade. Bei dem 6‑poligen Stecker (ebenfalls unkommentiert) hatte ich früh die Ahnung, das es sich um eine kombinierte UART-Schnittstelle (für ein GPS) und I2C-SChnittstelle (für einen externen Kompass) handelt, was sich ja jetzt bei dem Runner Advanced bestätigt hat, der diesen Stecker für das kombinierte GPS/Kompass-Modul nutzt.
Das mit dem UP02 Adapter an den 4‑Poligen Stecker anschließen habe ich gewusst, aber in der Tat nicht veröffentlicht. Mir liegt auch eine Original .bin Datei für den Runner 250 von Walkera vor, die ich über diese Schnittstelle aufspielen kann. Ich habe getestet: Sie funktioniert. Leider sind diese Dateien verschlüsselt. Man kann sie mit diesem Tool entschlüsseln, braucht dafür aber spezielles Equipment: https://github.com/rprinz08/UP42
Das wäre wirklich gut, die Datei zu entschlüsseln, um sie mit dem AVR Programmer brennen zu können, denn es stimmt natürlich: Mein Walkera Bootloader ist jetzt weg. Diesen Bootloader rückt Walkera aber vermutlich erst Recht nicht aus. Da bin ich schon froh, dass ich die jetzige verschlüsselte .bin für den UP02 habe.
Insgesamt kann ich zur Dokumentationsarbeit anmerken, dass es mir auch sehr lieb wäre, wenn wir viel mehr dokumentieren könnten. Wissen ist ja da. Leider ist die Zeit der Leute sehr begrenzt, und dokumentieren sollte man ja möglichst ordentlich und vollständig. Im Forum werden einige Sachen auch recht gut dokumentiert, dort ist es aber etwas weniger strukturiert als hier. Außerdem ist die Zahl der wirklich guten und engagierten Spezialisten immer weniger, als die Zahl der Fragen und Probleme.
Der Link mit dem Entschlüsselungs-Tool ist wirklich interessant, danke. Wenn ich das richtig verstehe ist im einfachsten Fall nur ein FTDI-USB-nach-UART-Konverter für 3,3V nötig (den es im China-Laden auf EBAY an jeder Ecke gibt) und die herunterladbare Kommandozeilen-Software. Wo sich die Katze aber in den Schwanz beißt ist, dass zum Entschlüsseln der original Walkera *.bin-Files ein individueller Schlüssel benötigt wird, der für jeden Walkera-Typ und vielleicht sogar für jede Firmware-Version anders ist. Die Codefolge ist so lang, dass man sie nicht raten oder in endlicher Zeit ausprobieren kann. Hier bräuchte man einen Cryptologen. Für die beiden Typen „Lady-Bird” und „Hoten‑X” sind die Schlüssel beigefügt, aber der Rest …? Bleibt noch das Bootloader-Problem: Mit jedem Löschvorgang der Firmware über den AVR-Programmer ist immer auch der Bootloader weg und dann hilft auch das über den obigen Link verfügbare Tool nichts mehr. Beim Runner wäre das nicht so schlimm, denn es gibt ja eine eigene Programmierschnittstelle, aber die meisten anderen Modelle, insbesondere die kleinen, haben so etwas nicht bzw. nur rudimentär über Mini-Pads auf dem Board (s. „Lady-Bird”).
Nein, es wird realistisch nur gehen, wenn man einen Runner-Controller „opfert” und dann nur noch mit der MultiWii-Firmware darauf arbeitet. Die 40 EUR muss einem der Spaß dann wert sein 🙂
Vielen Dank für die Einschätzung zum Schaltbild des UP42. Für mich war es nicht klar, was der DIY Adapter macht. Einen FTDI Adapter habe ich natürlich.
Den Schlüssel kann man laut der Doku offenbar aus dem Controller auslesen. Dieser ist vermutlich für jedes Modell (nicht jedes Exemplar) individuell.
Man kann den Schlüssel mit dem ‑I Parameter auslesen:
„-I, – info
Connects to a Walkera receiver board and displays it’s information string. Does not flash firmware.”
„o there must be some form of security mechanism (encryption) applied. Using the Hoten‑X firmware I started with the simplest form of encryption – the XOR. As the integrated boot loader has to perform the process of decrypting the uploaded firmware before writing the clear bytes to the flash during the update process, it could only be a very simple mechanism as there is not much room for complex algorithms like certificate based ones in the boot loader.
The interrupt jump table at the beginning of the file is more or less empty resulting in a repeating pattern of jump statements. By calculating the difference from the bytes in the encrypted firmware with the jump opcode value a part of the key could be restored repeating after 16 bytes. So the key was 16 bytes long. An XOR with the partial key reveals the final information needed to get the whole key. At the end of the Hoten‑X firmware update file a more or less human readable text apears.
This text is the same information you can read from the boot loader by using the I (Information) command described here. So this way the rest of the key could be easily calculated. The same mechanism also works for the Ladybird receiver. It looks like that every Walkera receiver model has its own “unique” 16 byte key. These are the keys I have discovered so far:”
Ich habe einen Controller schon geopfert, würde aber, falls mein Pin-Reverse-Engineering scheitert gerne eine bin Datei haben, um sie auf auch ohne Bootloader auf den Atmega zu brennen. Dazu müsste ich die .bin von Walkera entschlüsseln. Außerdem könnte man die entschlüsselte bin in einem Decompiler schmeißen und versuchen so rauszufinden, welche Pins was machen. Das wäre aber vermutlich mühsamer, als das Pin Layout selber dokumentieren.
Die Aufgabe, die aktuell die höchste Priorität hat ist das Deaktivieren des LVC. Die Original MultiWii von Walkera hat die Parameter dafür völlig falsch gesetzt, was dazu führt, dass der Kopter schon nach 5 Minuten zu Boden sinkt. Wenn man genau schaut, hat Walkera die Reihenfolge der Warnungen vertauscht. Der Schwellenwert für Critical kommt vor Warning. Hier sieht man das: http://walkera-fans.de/wp-content/uploads/2015/06/Walkera-Runner-250-MultiWii‑2.png
Diese Werte kann man in der MultiWii 2.2 nur im Sketch ändern und nicht in der GUI.
Eigentlich ist das ja hier nicht die geeignete Plattform für unsere ausschweifende Diskussion, aber sei’s drum: Ich war überrascht über Deine Aussage, man könne die Parameter der Batteriewarnung nicht per GUI verändern, denn bei den Regelparametern der PIDs geht das ja. Also habe ich es selber probiert, Parameter verändert, „Write” geklickt, „Read” geklickt und tatsächlich erschien wieder der vorherige Wert im Parameterfeld. Bei mir sind die Werte aber etwas anders als in Deinem Screenshot. Der CRITICAL-Wert steht bei mir auf 10.0 Vielleicht liegt es daran, dass ich das Verhalten des Kopters bei leerwerdendem Akku bisher nicht als so negativ empfunden habe. Wie muss man diese Zahlen denn interpretieren? Spannungswerte können das ja nicht sein. Wenn es wirklich so ist, dass es unterschiedliche Parameter bei Koptern aus unterschiedlichen Produktionsphasen gibt, dann können die Parameter nicht Bestandteil der Firmware sein, sonst würde Walkera üblicherweise Firmwareupdates anbieten. Ich würde also vermuten, dass die Parameter im EEPROM des Controllers abgelegt sind. Das wäre dann ein Grund mehr sich um das Decrypten der Firmware (Flash) und der auslesbaren Modellparameter (EEPROM) zu kümmern. Vielleicht kannst Du mir Deine ausgelesenen Modellparameter (und gerne auch die Runner-Firmware) mal zusenden. Ich würde dann prüfen ob es Unterschiede gibt und wenn das Decrypten dereinst gelingt auch verorten können, wie der Wert im Speicher abgelegt ist. Sobald das klar ist, kann man ihn auch auf dem gleichen Weg ändern.
Zum Thema Decrypten: So wie ich den Text aus dem angegebenen Link deute, kann man mit dem ‑I-Kommando nicht den Schlüssel aus dem Controller auslesen, sondern nur den Modellnamen und Versionsinformationen als Textstring. Wenn man die aber kennt (oder erahnen kann) und das Verschlüsselungsverfahren kennt (XOR mit 16 Byte Schlüsselwort), kann man mit etwas Geschick und Know-How den Schlüssel rekonstruieren. Das kann zwar ein Stundengrab werden, aber ich probier’s gerne mal.
Schon schade, dass Walkera die opensource Multiwii so „verschlossen” hat . Habe einen Kompass / Baro am I2C angeschlossen. Kompass klappt sofort, Baro müsste im Sketch aktiviert werden. GPS würde vermutlich auch direkt funktioniren , da schon aktiviert.
Schöne Analyse! Den Baro-Sensor konnte man aber bereits früher aus den Bildern im Beitrag „Runner 250 MultiWii Flugsteuerung von innen” verorten. Dort ist auf der Oberseite des Boards eine Bestückungssfläche für ein 8‑poliges SMD Bauelement zu erkennen. Die Beschaltung passt für den Baro-Sensor MS5611-01BA01. Ich habe den Sensor mal nachgerüstet. Leider scheint die frühere Firmware den Sensor nicht zu unterstützen (was nicht verwundert, da er ja serienmäßig nicht bestückt ist), jedenfalls erkennt die MultiWiiGUI das Vorhandensein des Sensors nicht.
Es muss also eine neue Version des Flugcontrollers verbaut sein, die wahrscheinlich auch eine neue Bestellnummer erhalten wird. Wäre schön, wenn mal jemand den neuen Flugcontroller öffnen und ein paar Fotos von beiden Bestückungsseiten schießen würde. Dann könnte man zweifelsfrei feststellen, ob sich der neue Controller nur durch die Bestückung des Baro-Sensors unterscheidet, oder ob das Board gegenüber der Vorversion auch anderweitig verändert wurde.
Rein technisch ist der Runner-Controller eine zugeschnittene und abgespeckte Version des AIOP-Controllers von Crius/HobbyKing. Es wurden quasi die gleichen Komponenten verbaut.
Es ist sehr angenehm, einen sehr kompetenten Mitstreiter zu sehen 🙂
Ich öffne sehr gerne den neuen Controller und mache Fotos!
Ich habe auf den alten Controller über SPI die neue MultiWii mit der AIOP Konfiguration aufgespielt, allerdings scheinen da die Ein- und Ausgänge nicht zu stimmen. Da das Pinout noch nicht bekannt ist, gestaltet sich die Suche nach den richtigen Ausgängen schwierig. Oder ich habe sonst wo einen Fehler gemacht. Hatte noch keine Zeit da weiter zu machen. Es würde mich freuen, wenn du da auch mithackst 🙂
Hallo Gektor,
wenn man einen Atmel-Programmer an den Programmierstecker des Runner-Conrollers anschließt (was Du ja wohl auch gemacht hast) kann man zwar die Fuses auslesen, der Programmcode ist allerdings per Lock-Bits maximal gegen Auslesen und Verifizieren sowohl des Flash-Speichers, als auch des EEPROMS geschützt. Das Aufspielen einer anderen Firmware (z. B. der original MultiWii-Firmware) ist daher eine Einbahnstraße, von der es kein Zurück mehr gibt, wenn man nicht eine Originalfirmware des Runners von Walkera als Binärcode-Datei bekommt (und den geben die ja wohl nicht heraus).
Das ist es, was mich bisher noch davon abhält, denn genau dieselbe Idee einen zugeschnittenen MultiWii-Code mal zu probieren hatte ich auch schon. Wenn ich zwischendurch mal nicht weiß, was ich tun soll 🙂
gebe ich mich mal daran den Schaltplan des Runner-Controllers zu extrahieren. Das ist zwar per Durchklingeln mühsam und fehlerträchtig (eigentlich müsste man alle Komponenten vom Board extrahieren um sicher sein zu können) aber das ist ja Hobby und allemal besser als Briefmarken sammeln.
P.S.: Da ich’s bisher noch in keinem Beitrag gelesen habe und es vielleicht den einen oder anderen interessiert: Ich habe den in der Betriebsanleitung unkommentierten 4‑poligen Stecker (nach vorheriger Prüfung der Belegung) mal an das Programmer-Tool von Walkera angeschlossen und der Flugcontroller hat sich in der Programmer-GUI als „Runner 250” zu erkennen gegeben. Diese Schnittstelle dient also dem Firmware-Upgrade. Bei dem 6‑poligen Stecker (ebenfalls unkommentiert) hatte ich früh die Ahnung, das es sich um eine kombinierte UART-Schnittstelle (für ein GPS) und I2C-SChnittstelle (für einen externen Kompass) handelt, was sich ja jetzt bei dem Runner Advanced bestätigt hat, der diesen Stecker für das kombinierte GPS/Kompass-Modul nutzt.
Das mit dem UP02 Adapter an den 4‑Poligen Stecker anschließen habe ich gewusst, aber in der Tat nicht veröffentlicht. Mir liegt auch eine Original .bin Datei für den Runner 250 von Walkera vor, die ich über diese Schnittstelle aufspielen kann. Ich habe getestet: Sie funktioniert. Leider sind diese Dateien verschlüsselt. Man kann sie mit diesem Tool entschlüsseln, braucht dafür aber spezielles Equipment: https://github.com/rprinz08/UP42
Das wäre wirklich gut, die Datei zu entschlüsseln, um sie mit dem AVR Programmer brennen zu können, denn es stimmt natürlich: Mein Walkera Bootloader ist jetzt weg. Diesen Bootloader rückt Walkera aber vermutlich erst Recht nicht aus. Da bin ich schon froh, dass ich die jetzige verschlüsselte .bin für den UP02 habe.
Insgesamt kann ich zur Dokumentationsarbeit anmerken, dass es mir auch sehr lieb wäre, wenn wir viel mehr dokumentieren könnten. Wissen ist ja da. Leider ist die Zeit der Leute sehr begrenzt, und dokumentieren sollte man ja möglichst ordentlich und vollständig. Im Forum werden einige Sachen auch recht gut dokumentiert, dort ist es aber etwas weniger strukturiert als hier. Außerdem ist die Zahl der wirklich guten und engagierten Spezialisten immer weniger, als die Zahl der Fragen und Probleme.
Der Link mit dem Entschlüsselungs-Tool ist wirklich interessant, danke. Wenn ich das richtig verstehe ist im einfachsten Fall nur ein FTDI-USB-nach-UART-Konverter für 3,3V nötig (den es im China-Laden auf EBAY an jeder Ecke gibt) und die herunterladbare Kommandozeilen-Software. Wo sich die Katze aber in den Schwanz beißt ist, dass zum Entschlüsseln der original Walkera *.bin-Files ein individueller Schlüssel benötigt wird, der für jeden Walkera-Typ und vielleicht sogar für jede Firmware-Version anders ist. Die Codefolge ist so lang, dass man sie nicht raten oder in endlicher Zeit ausprobieren kann. Hier bräuchte man einen Cryptologen. Für die beiden Typen „Lady-Bird” und „Hoten‑X” sind die Schlüssel beigefügt, aber der Rest …?
Bleibt noch das Bootloader-Problem: Mit jedem Löschvorgang der Firmware über den AVR-Programmer ist immer auch der Bootloader weg und dann hilft auch das über den obigen Link verfügbare Tool nichts mehr. Beim Runner wäre das nicht so schlimm, denn es gibt ja eine eigene Programmierschnittstelle, aber die meisten anderen Modelle, insbesondere die kleinen, haben so etwas nicht bzw. nur rudimentär über Mini-Pads auf dem Board (s. „Lady-Bird”).
Nein, es wird realistisch nur gehen, wenn man einen Runner-Controller „opfert” und dann nur noch mit der MultiWii-Firmware darauf arbeitet. Die 40 EUR muss einem der Spaß dann wert sein 🙂
Vielen Dank für die Einschätzung zum Schaltbild des UP42. Für mich war es nicht klar, was der DIY Adapter macht. Einen FTDI Adapter habe ich natürlich.
Den Schlüssel kann man laut der Doku offenbar aus dem Controller auslesen. Dieser ist vermutlich für jedes Modell (nicht jedes Exemplar) individuell.
Man kann den Schlüssel mit dem ‑I Parameter auslesen:
„-I, – info
Connects to a Walkera receiver board and displays it’s information string. Does not flash firmware.”
Hier ist das Verfahren etwas genauer beschrieben: https://www.min.at/prinz/?x=entry:entry150325-175037
„o there must be some form of security mechanism (encryption) applied. Using the Hoten‑X firmware I started with the simplest form of encryption – the XOR. As the integrated boot loader has to perform the process of decrypting the uploaded firmware before writing the clear bytes to the flash during the update process, it could only be a very simple mechanism as there is not much room for complex algorithms like certificate based ones in the boot loader.
The interrupt jump table at the beginning of the file is more or less empty resulting in a repeating pattern of jump statements. By calculating the difference from the bytes in the encrypted firmware with the jump opcode value a part of the key could be restored repeating after 16 bytes. So the key was 16 bytes long. An XOR with the partial key reveals the final information needed to get the whole key. At the end of the Hoten‑X firmware update file a more or less human readable text apears.
This text is the same information you can read from the boot loader by using the I (Information) command described here. So this way the rest of the key could be easily calculated. The same mechanism also works for the Ladybird receiver. It looks like that every Walkera receiver model has its own “unique” 16 byte key. These are the keys I have discovered so far:”
Ich habe einen Controller schon geopfert, würde aber, falls mein Pin-Reverse-Engineering scheitert gerne eine bin Datei haben, um sie auf auch ohne Bootloader auf den Atmega zu brennen. Dazu müsste ich die .bin von Walkera entschlüsseln. Außerdem könnte man die entschlüsselte bin in einem Decompiler schmeißen und versuchen so rauszufinden, welche Pins was machen. Das wäre aber vermutlich mühsamer, als das Pin Layout selber dokumentieren.
Die Aufgabe, die aktuell die höchste Priorität hat ist das Deaktivieren des LVC. Die Original MultiWii von Walkera hat die Parameter dafür völlig falsch gesetzt, was dazu führt, dass der Kopter schon nach 5 Minuten zu Boden sinkt. Wenn man genau schaut, hat Walkera die Reihenfolge der Warnungen vertauscht. Der Schwellenwert für Critical kommt vor Warning. Hier sieht man das:
http://walkera-fans.de/wp-content/uploads/2015/06/Walkera-Runner-250-MultiWii‑2.png
Diese Werte kann man in der MultiWii 2.2 nur im Sketch ändern und nicht in der GUI.
Die Strommessung muss genau so gelöst sein wie beim X350. Daher wäre eine Überbrückung möglich und sinnvoll: http://walkera-fans.de/x350-lvc-kabel-mod/
Wenn man die passenden Pins fände, könnte man sie verbinden und das Problem wäre gelöst.
Eigentlich ist das ja hier nicht die geeignete Plattform für unsere ausschweifende Diskussion, aber sei’s drum:
Ich war überrascht über Deine Aussage, man könne die Parameter der Batteriewarnung nicht per GUI verändern, denn bei den Regelparametern der PIDs geht das ja. Also habe ich es selber probiert, Parameter verändert, „Write” geklickt, „Read” geklickt und tatsächlich erschien wieder der vorherige Wert im Parameterfeld. Bei mir sind die Werte aber etwas anders als in Deinem Screenshot. Der CRITICAL-Wert steht bei mir auf 10.0
Vielleicht liegt es daran, dass ich das Verhalten des Kopters bei leerwerdendem Akku bisher nicht als so negativ empfunden habe. Wie muss man diese Zahlen denn interpretieren? Spannungswerte können das ja nicht sein.
Wenn es wirklich so ist, dass es unterschiedliche Parameter bei Koptern aus unterschiedlichen Produktionsphasen gibt, dann können die Parameter nicht Bestandteil der Firmware sein, sonst würde Walkera üblicherweise Firmwareupdates anbieten. Ich würde also vermuten, dass die Parameter im EEPROM des Controllers abgelegt sind. Das wäre dann ein Grund mehr sich um das Decrypten der Firmware (Flash) und der auslesbaren Modellparameter (EEPROM) zu kümmern. Vielleicht kannst Du mir Deine ausgelesenen Modellparameter (und gerne auch die Runner-Firmware) mal zusenden. Ich würde dann prüfen ob es Unterschiede gibt und wenn das Decrypten dereinst gelingt auch verorten können, wie der Wert im Speicher abgelegt ist. Sobald das klar ist, kann man ihn auch auf dem gleichen Weg ändern.
Zum Thema Decrypten: So wie ich den Text aus dem angegebenen Link deute, kann man mit dem ‑I-Kommando nicht den Schlüssel aus dem Controller auslesen, sondern nur den Modellnamen und Versionsinformationen als Textstring. Wenn man die aber kennt (oder erahnen kann) und das Verschlüsselungsverfahren kennt (XOR mit 16 Byte Schlüsselwort), kann man mit etwas Geschick und Know-How den Schlüssel rekonstruieren. Das kann zwar ein Stundengrab werden, aber ich probier’s gerne mal.
Schon schade, dass Walkera die opensource Multiwii so „verschlossen” hat . Habe einen Kompass / Baro am I2C angeschlossen. Kompass klappt sofort, Baro müsste im Sketch aktiviert werden.
GPS würde vermutlich auch direkt funktioniren , da schon aktiviert.