dji firmware tools
1.0.0
Werkzeuge zum Extrahieren, Moddieren und Wiederverpacken von Unternehmensmultirotor-Drohnen.
Das Projekt begann als alternative Implementierung des Parsers von Phantom-Licensecheck. Im Laufe der Zeit hat es viele Generationen von DJI -Produkten unterstützt. Es besteht aus Tools, die nicht nur Extraktion ermöglichen, sondern auch die zuvor extrahierten Module wieder in eine einzelne Datei abpacken. Es gibt auch Tools, die für bestimmte Module verwendet werden sollen, um ihren Inhalt zu extrahieren und zu ändern.
Hier sind einige mögliche Verwendungen der Werkzeuge.
Das Ersetzen einiger Komponenten der Drohne kann eine Kalibrierung erfordern. Die Werkzeuge können in einigen Geräten, hauptsächlich Gimbals mit Hallsensoren, Kalibrierung auslösen.
Es ist auch möglich, sie zu verwenden, um ein benutzerdefiniertes Paket an die Drohne zu senden. Auf diese Weise können Sie Werksfunktionen wie Kalibrierung oder Paarung auslösen - solange Sie wissen, wie das Paket aussehen sollte.
Das Wiki dieses Projekts enthält unzählige Informationen über Boards in jeder Drohne und Komponenten auf jedem Vorstand. Diese Informationen werden von vielen Enthusiasten und Reparaturtechnikern erstellt und geteilt.
Die Tools können als Befehlszeilenversion der DJI -Assistenz -Software verwendet werden, mit der auch Parameter für Plattformen geändert werden können, denen solche OEM -Software fehlt oder in denen die erweiterten Funktionen gesperrt sind.
Flugcontroller von DJI definieren Hunderds von Parametern, die sich auf ihr Verhalten auswirken. Diese können geändert werden, indem nur ein Befehl an die Drohne gesendet wird, solange der neue Wert innerhalb der von der FC -Firmware akzeptierten Grenzen liegt.
Die Tools ermöglichen die Änderung von Firmware-Binärdateien und werden dann wieder in das Flashable-Firmware-Paket überpackt. Auf diese Weise kann jede Software-kontrollierte Funktionalität verändert werden, einschließlich:
Es kann manchmal zusätzliche Kenntnisse und Software -Änderungen (dh Rooting der Drohne) für Flash -modifizierte Firmware erfordern. Einige Firmware -Pakete werden mit asymmetrischer Kryptographie signiert, und private Schlüssel sind selten verfügbar.
Wenn Sie an DJI -Hardware und Software interessiert sind, ist dies der Ort, um zu lernen. Du kannst:
Eine solche Anweisung wird nicht zur Verfügung gestellt. Diese Tools sind für Ingenieure mit großem Hardware- und Softwarekenntnissen gedacht. Sie müssen wissen, was Sie tun, um mit diesen Tools etwas zu erreichen.
Dies soll sicherstellen, dass die Tools nicht von Skriptkinds verwendet werden, um Sicherheitsmechanismen zu deaktivieren und die lokalen Gesetze zu brechen.
Wenn Sie nicht verstehen können, wie die Tools funktionieren, sollten Sie sie nicht verwenden. Wenn Warnungen angezeigt werden, müssen Sie die Ursache untersuchen, um sicherzustellen, dass die endgültige Firmware nicht beschädigt wird. Sie verwenden die Tools auf eigenes Risiko.
Wenn Sie nicht wissen, wo Sie anfangen sollen, überprüfen Sie die Tests. Sie bieten Ihnen Befehlszeilen, um mit der Drohne zu kommunizieren oder alle Schichten einer bestimmten Firmware zu extrahieren (solange Sie sie richtig platzieren können).
Da alle Tools im Quellcodeformular verfügbar sind, können Sie die Details der Struktur und Protokolle, die von diesen Tools verarbeitet werden, einfach überprüft, indem Sie sich die Quelle ansehen. Der Quellcode soll auch als Formatdokumentation fungieren.
Weitere Informationen über höhere Ebenen und mehr hardwarebezogene Informationen finden Sie im Projekt -Wiki.
Die Werkzeuge können in zwei Kategorien unterteilt werden:
Hardware -unabhängige Tools - diejenigen, für die Sie kein DJI -Produkt benötigen. Sie benötigen nur eine Eingabedatei, die sie verwenden, wie das DJI -Firmware -Paket oder die DAT -Protokolldatei.
Produktkommunikationsinstrumente - Sie müssen Ihre Drohne an einen PC anschließen, um diese Tools auf aussagekräftige Weise zu verwenden. Derzeit verwenden die Tools die serielle Schnittstelle (UART) und I2C.
Unter den spezifischen Werkzeugen werden kurz beschrieben. Wenn Sie sie ohne Parameter ausführen, erhalten Sie Details zu unterstützten Befehlen in jedem von ihnen.
Führen Sie sie mit der Option --help aus. Einige Tools haben auch zusätzliche Bemerkungen in ihren Headern - versuchen Sie sie anzusehen.
DJI Firmware XV4 Container Tool; Ermöglicht das Extrahieren von Modulen aus der Paketdatei, die mit xV4 startet, oder das Erstellen von Container durch Zusammenführen von Firmware -Modulen. Verwenden Sie zuerst dieses Tool, um die von DJI heruntergeladene Bin -Datei zu extrahieren, solange die Datei mit xV4 beginnt.
Beispiel für das Extrahieren von Modulen aus dem DJI -Firmware -Paket für Phantom 3 Pro :
./dji_xv4_fwcon.py -vv -x -p P3X_FW_V01.08.0080.bin
DJI Firmware Imah Unsigner und entschlüsseltes Tool; Ermöglicht das Entschlüsseln und das Unsignal-Modul aus .sig Datei, die mit IM*H beginnt. Verwenden Sie dieses Tool, nachdem Sie einzelne Module aus einem Firmware -Paket entschlüsseln, um seinen Inhalt zu entschlüsseln. Das Tool kann auch ein Modul neu unterschreiben, solange der private Teil des gewählten Schlüssels verfügbar ist.
Die für Verschlüsselung und Authentifizierung verwendeten Schlüssel änderten sich im Laufe der Zeit; Wenn sich eine IM*H -Datei auf einen Schlüssel bezieht, für den das Tool über mehrere Versionen verfügt, wird eine Liste möglicher Schlüssel in einer Warnmeldung angezeigt und den neuesten Schlüssel für den aktuellen Betrieb ausgewählt.
Beispiel für die unerschlossene Kamera-Firmware für Mavic Pro :
./dji_imah_fwsig.py -vv -k PRAK-2017-01 -k PUEK-2017-07 -u -i wm220_0101_v02.00.55.69_20161215.pro.fw.sig
Beispiel für die unerschlossene FC-Firmware für Phantom 4 Pro V2 :
./dji_imah_fwsig.py -vv -k PRAK-2017-01 -k PUEK-2017-07 -u -i wm335_0306_v03.03.04.10_20180429.pro.fw.sig
Beispiel für die Unterzeichnung der zuvor nicht signierten FC-Firmware für Mini 2 (erfordert PRAK mit privatem Teil):
./dji_imah_fwsig.py -vv -k PRAK-2019-09 -s -i wm161_0306_v03.04.09.74_20210112.pro.fw.sig
Weitere Beispiele für die Nutzung des Tools sowie die Identifikatoren von Schlüssel für bestimmte Plattformen finden Sie im zum Testen verwendeten Skript: tests/test_dji_imah_fwsig_rebin1.sh .
DJI Mavic Flight Controller Firmware entschlüsseltes Tool; Entfernt die Verschlüsselung der zweiten Schicht in Flugcontroller -Firmware -Modulen aus mehreren DJI -Produkten, die im gleichen Zeitraum veröffentlicht wurden: Mavic Pro , Spark , Inspire 2 und Phantom 4 . Akzeptiert nicht IM*H -Format - erfordert Eingabedateien mit bereits entferntem Verschlüsselungsverschlüsselung.
Beispiel für die Entschlüsselung der FC -Firmware für Mavic Pro :
./dji_mvfc_fwpak.py dec -i wm220_0306_v03.02.40.11_20170918.pro.fw
Ambarella A7/A9 Firmware Pack Tool; Ermöglicht das Extrahieren von Partitionen aus der Firmware oder verschmelzen sie zurück. Verwenden Sie dies, um Ambarella -Firmware aus Dateien zu extrahieren, die nach dem Extrahieren von DJI -Container erstellt wurden. Sie können die Abarnella-Firmware durch viele "Amba" -Saiten innerhalb oder durch eine 32-Char-Null-String am Anfang der Datei erkennen.
Beispiel für das Extrahieren von Partitionen von Ambarella -Firmware für Phantom 3 Pro :
./amba_fwpak.py -vv -x -m P3X_FW_V01.08.0080_m0100.bin
Ambarella A7/A9 Firmware romfs Dateisystem -Tool; Ermöglicht das Extrahieren einzelner Dateien aus der Dateisystemdatei von ROMFS oder das Wiederaufbau von Dateisystemen aus den einzelnen Dateien. Verwenden Sie dies, nachdem die Abarnella -Firmware extrahiert wurde. Sie können ROMFS -Partitionen durch Dateinamen am Anfang der Datei erkennen, die von Blöcken von 0xff -gefüllten Bytes umgeben sind.
Beispiel für die Extraktion von ROMFS -Partition aus Abarnella -Firmware für Phantom 3 Pro :
./amba_romfs.py -vv -x -p P3X_FW_V01.08.0080_m0100_part_rom_fw.a9s
Linux -Skript zur Montage von Ubifs Partition aus der Abarnella -Firmware. Nach der Montage können die Dateien kopiert oder geändert werden. Verwenden Sie dies, nachdem die Abarnella -Firmware extrahiert wurde. Die Datei mit UBIFs kann von UBI# am Anfang der Datei leicht erkannt werden.
Beispiel für die Montage der Stammdateisystem -Partition von Ambarella Firmware für Phantom 3 Pro :
sudo ./amba_ubifs.sh P3X_FW_V01.08.0080_m0100_part_rfs.a9s
Werkzeug, das binäre ausführbare Armbilder mit Elf -Header umwickelt. Wenn eine Firmware ein binäres Bild der ausführbaren Datei enthält, kann dieses Tool den ELF -Header dafür wieder aufbauen. Das ELF -Format kann dann leicht zerlegt werden, da die meisten Debugger Elf -Dateien lesen können. Beachten Sie, dass die Verwendung dieses Tools für verschlüsselte Firmawares nicht zu einem nutzbaren Elf führt.
Beispiel für die Konvertierung von FC -Firmware für Phantom 3 in ELF:
./arm_bin2elf.py -vv -e -b 0x8020000 -l 0x6000000 -p P3X_FW_V01.07.0060_m0306.bin
Der obige Befehl veranlasst das Tool, zu erkennen, wo die Grenze zwischen Code ( .text ) und Daten ( .data ) Abschnitten sein sollte. Diese Erkennung ist nicht perfekt, insbesondere für Binärdateien mit Nr .ARM.exidx Abschnitt zwischen ihnen. Wenn .ARM.exidx im Binary existiert, kann das Tool es leicht finden und binäre Daten ordnungsgemäß dividieren und .ARM.exidx als Trennzeichen zwischen .text und .data behandelt.
Mit anderen Worten, die Position des .ARM.exidx beeinflusst die Länge des .text und starten Sie den Offset des .data -Abschnitts. Wenn es in der Datei keinen Abschnitt .ARM.exidx gibt, wird er weiterhin als Trennzeichen verwendet, nur ohne Größe. Nach dem ersten Blick auf die Demontage ist es gut zu prüfen, wo sich die richtige Grenze zwischen .text und .data -Abschnitten befindet. Die Speicheradresse dieses Ortes kann verwendet werden, um eine bessere ELF -Datei zu generieren.
Weitere Aktualisierungen des Elf nach dem ersten Look können die Definieren .bss -Abschnitten enthalten. Diese Abschnitte repräsentieren nicht initialisierte RAM- und MMIO -Bereiche, die von der Binärdatei verwendet werden. Es ist verlockend, nur einen großen Abschnitt zu definieren, der den gesamten Speicherkarten -Adressbereich gemäß dem Programmierhandbuch des Chips abdeckt. Dies führt jedoch zu einer enormen Speicherverwendung und zugehörigen Verlangsamungen, während sie die Datei zerlegt und gleichzeitig die Datei schwieriger zu navigieren.
Beachten Sie, dass alle Abschnitts-Offsets mithilfe der In-Memory-Adresse definiert werden und nicht die Position in der Bin-Datei. Wenn Sie einen ordnungsgemäßen Ort eines Abschnitts in der Bin -Datei gefunden haben, sollten Sie der Dateiposition die Basisadresse hinzufügen, bevor Sie in die Befehlszeile dieses Tools einfügen.
Die Basisadresse kann häufig im Programmierhandbuch des spezifischen Chips gefunden werden. Manchmal kann es von diesem Ort verschoben werden, wenn die Binärdatei von einem zusätzlichen Bootloader geladen wird. In solchen Fällen nimmt der Bootloader den Standort aus der Dokumentation, und die reale Firmware -Binärdatei wird mit einer bit höheren Basisadresse geladen.
Optimierte Beispiele für bestimmte Unternehmenswares:
./arm_bin2elf.py -vv -e -b 0x8020000 --section .ARM.exidx@0x80A5D34:0 --section .bss@0x10000000:0x0A000 --section .bss2@0x20000000:0x30000 --section .bss3@0x40000000:0x30000 -p P3X_FW_V01.07.0060_m0306.bin
./arm_bin2elf.py -vv -e -b 0x000A000 --section .ARM.exidx@0x026E50:0 --section .bss@0x10000000:0x08000 --section .bss2@0x40000000:0x50000 --section .bss3@0xE0000000:0x10000 -p C1_FW_V01.06.0000_m1400.bin
./arm_bin2elf.py -vv -e -b 0x000A000 --section .ARM.exidx@0x0212E0:0 --section .bss@0x10000000:0x08000 --section .bss2@0x40000000:0x50000 --section .bss3@0xE0000000:0x10000 -p C1_FW_v01.09.0200_m1400.bin
./arm_bin2elf.py -vv -e -b 0x000A000 --section .ARM.exidx@0x0233E0:0 --section .bss@0x02000000:0x04000 --section .bss2@0x2008000:0x1000 --section .bss3@0x1C000000:0x2400 --section .bss4@0x1c024000:0x2400 --section .bss5@0x4002C000:0x50000 --section .bss6@0x400F8000:0x200 --section .bss7@0xE000E000:0x1200 -p C1_FW_V01.06.0000_m1401.bin
./arm_bin2elf.py -vv -e -b 0x8008000 --section .ARM.exidx@0x8015510:0 --section .bss@0x1FFFF700:0x05A00 --section .bss2@0x40000000:0x6700 --section .bss3@0x40010000:0x5500 --section .bss4@0x40020000:0x2200 --section .bss5@0x42200000:0x100 --section .bss6@0x42420000:0x500 -p P3X_FW_V01.08.0080_m0900.bin
./arm_bin2elf.py -vv -e -b 0x8008000 --section .ARM.exidx@0x801B6D0:0 --section .bss@0x1FFFF700:0x0C900 --section .bss2@0x40000000:0x6700 --section .bss3@0x40010000:0x5500 --section .bss4@0x40020000:0x7000 --section .bss5@0x50060800:0x100 -p P3X_FW_V01.11.0030_m0400.bin
./arm_bin2elf.py -vv -e -b 0x0420000 --section .ARM.exidx@0x4EDAF0:0 --section .bss@0x20400000:0x40000 --section .bss4@0x42200000:0x100 -p MATRICE600_FW_V02.00.00.21_m0306.bin
./arm_bin2elf.py -vv -e -b 0x0420000 --section .ARM.exidx@0x4F0E00:0 --section .bss@0x20400000:0x60100 --section .bss2@0x400E0000:0x2000 -p wm330_0306_v03.01.10.93_20160707.fw_0306.decrypted.bin
./arm_bin2elf.py -vv -e -b 0x0420000 --section .ARM.exidx@0x5277d0:0 --section .bss@0x20400000:0x60000 --section .bss2@0x400E0000:0x1000 --section .bss3@0xE0000000:0x10000 -p wm100_0306_v03.02.43.20_20170920.pro.fw_0306.decrypted.bin
./arm_bin2elf.py -vv -e -b 0x0420000 --section .ARM.exidx@0x5465d8:0 --section .bss@0x20400000:0x60100 --section .bss2@0x400E0000:0x2000 -p wm220_0306_v03.02.35.05_20170525.pro.fw_0306.decrypted.bin
./arm_bin2elf.py -vv -e -b 0x7D000000 --section .ARM.exidx@0x7D0356E0:0 --section .bss@0x7D04f380:0x3800 --section .bss2@0x7D0f1900:0x200 -p wm230_0801_v10.00.07.12_20180126-recovery.img.TZOS.bin
./arm_bin2elf.py -vv -e -b 0xFFFC0000 --section .ARM.exidx@0xFFFDA540:0x20 --section .bss@0xFFFE14D0:0x42B0 --section .bss1@0x0202000:0x20 --section .bss2@0x0402020:0x20 --section .bss3@0x0B00000:0x40 --section .bss4@0x2700000:0x40 --section .bss5@0x9000000:0x20 --section .bss6@0xF0440000:0x4500 --section .bss7@0xF0501200:0x200 --section .bss8@0xF0A09000:0x20 --section .bss9@0xF0A40000:0x1200 --section .bss10@0xF0A4D000:0x2100 --section .bss11@0xF0A61000:0x1200 --section .bss12@0xF0A72000:0x20 --section .bss13@0xF0D02000:0x20 --section .bss14@0xF0D04000:0x20 --section .bss15@0xF0E00A00:0xC0 --section .bss16@0xF0E08000:0x20 --section .bss17@0xF5001000:0x40 --section .bss18@0xF6409000:0x100 --section .bss19@0xF6800000:0x1200 --section .bss20@0xFA800000:0x100 --section .bss21@0xFAF01000:0x3500 --section .bss22@0xFB001000:0x2900 --section .bss23@0xFCC01000:0x2400 --section .bss24@0xFD001000:0x2D00 --section .bss25@0xFD400000:0x20 --section .bss26@0xFD501000:0x2400 --section .bss27@0xFF001000:0x1100 -p wm230_0801_v10.00.07.12_20180126.pro.fw_0801.bootarea_p0_BLLK.bin
Dieses Tool unterstützt nur die Konvertierung in Richtung Bin-to-Elf. Verwenden Sie für die spezifische Architektur eine objcopy -Datei zurück in Bin (dh nach Änderungen). Das objcopy -Tool ist Teil von GNU -Binärversorger ( binutils ) und nicht Teil dieses Repositorys.
Beispiele:
arm-none-eabi-objcopy -O binary P3X_FW_V01.07.0060_m0100_part_sys.elf P3X_FW_V01.07.0060_m0100_part_sys.bin
arm-none-eabi-objcopy -O binary P3X_FW_V01.07.0060_m0900.elf P3X_FW_V01.07.0060_m0900.bin
Ambarella A7/A9 Firmware "System Software" Partition Converter. Die Partition enthält ein binäres Bild der ausführbaren Datei, und dieses Tool umhüllt es mit ELF -Header. Das ELF -Format kann dann leicht zerlegt werden, da die meisten Debugger Elf -Dateien lesen können. Dieses Tool ist sehr ähnlich wie bei arm_bin2elf.py , es ist nur vorkonfiguriert in bestimmte Firmware.
Beispiel: ./amba_sys2elf.py -vv -e -l 0x6000000 -p P3X_FW_V01.08.0080_m0100_part_sys.a9s
Alle für arm_bin2elf.py erläuterten Randeinstellungsregeln.
Optimierte Beispiele für bestimmte Unternehmenswares:
./amba_sys2elf.py -vv -e -l 0x6000000 --section .ARM.exidx@0xEA83E4C:0 -p P3X_FW_V01.08.0080_m0100_part_sys.a9s
./amba_sys2elf.py -vv -e -l 0x6000000 --section .ARM.exidx@0xEA82EC0:0 -p P3X_FW_V01.07.0060_m0100_part_sys.a9s
./amba_sys2elf.py -vv -e -l 0x6000000 --section .ARM.exidx@0xEA64774:0 -p P3X_FW_V01.01.0008_m0100_part_sys.a9s
Ambarella A7/A9 Firmware "System Software" Partition Hartcoded Values Editor.
Das Tool kann Ambarnella Firmware -Sys -Partition in ELF konvertiert werden. Es findet bestimmte hartcodierte Werte in den Binärdaten und ermöglicht das Export oder Importieren. Das einzige setValue -Element in der exportierten JSON -Datei ist wirklich wechselhaft, alle anderen Daten sind nur informativ.
Beispiel für den Exportieren hartcodierter Werte in die JSON-Datei:
./amba_sys_hardcoder.py -vv -x --elffile P3X_FW_V01.08.0080_m0100_part_sys.elf
Beispiel für das Importieren von Werten aus der JSON -Datei zurück zu ELF:
./amba_sys_hardcoder.py -vv -u --elffile P3X_FW_V01.08.0080_m0100_part_sys.elf
DJI DM3XX DAVINCI COD_USB Binärer hartcodierter Werte Editor.
Das Tool kann die ELF -Datei der Encode_USB vom DJI -Firmware -Modul für Ti DM3XX Davinci Media Processor analysieren. Es findet bestimmte hartcodierte Werte in den Binärdaten und ermöglicht das Export oder Importieren.
Beispiel für den Exportieren hartcodierter Werte in die JSON-Datei:
./dm3xx_encode_usb_hardcoder.py -vv -x --elffile P3X_FW_V01.07.0060_m0800-encode_usb.elf
Beispiel für das Importieren von Werten aus der JSON -Datei zurück zu ELF:
./dm3xx_encode_usb_hardcoder.py -vv -u --elffile P3X_FW_V01.07.0060_m0800-encode_usb.elf
DJI LightBridge STM32 Micro-Controller Binärer hartcodierter Werte Editor.
Das Tool kann die MCU -Firmware von LightBridge analysieren, die in ELF umgewandelt wurde. Es findet bestimmte hartcodierte Werte in den Binärdaten und ermöglicht das Export oder Importieren.
Beispiel für den Exportieren hartcodierter Werte in die JSON-Datei:
./lightbridge_stm32_hardcoder.py -vv -x --elffile P3X_FW_V01.07.0060_m0900.elf
Beispiel für das Importieren von Werten aus der JSON -Datei zurück zu ELF:
./lightbridge_stm32_hardcoder.py -vv -u --elffile P3X_FW_V01.07.0060_m0900.elf
DJI Flight Controller Firmware Binärer hartcodierter Werte Editor.
Das Tool kann Flight Controller -Firmware an ELF konvertiert. Es findet bestimmte hartcodierte Werte in den Binärdaten und ermöglicht das Export oder Importieren.
Beispiel für den Exportieren hartcodierter Werte in die JSON-Datei:
./dji_flyc_hardcoder.py -vvv -x -e P3X_FW_V01.07.0060_m0306.elf
Beispiel für das Importieren von Werten aus der JSON -Datei zurück zu ELF:
./dji_flyc_hardcoder.py -vvv -u -e P3X_FW_V01.07.0060_m0306.elf
Der Array -Editor der Flight Controller -Firmware -Parameter findet eine Reihe von Flugparametern in Firmware Binär und ermöglicht es, die Parameter in eine Textedatei für JSON -Format zu extrahieren. Diese Datei kann dann leicht geändert und zur Aktualisierung von Binärfirmware und zur Änderung von Attributen und Grenzen jedes Parameters verwendet werden.
Um das Parameter-Array zu finden, benötigt das Tool die Basisadresse, mit der die Binärdatei in den RAM des Mikrokontrollers geladen werden kann. Wenn Sie die zu verwendende Basisadresse nicht kennen, kann der Programmierhandbuch des verwendeten Chips Ihnen Hinweise geben.
Beispiel für das Extrahieren und Anschließungen der Flugregelungsparameter:
./dji_flyc_param_ed.py -vv -x -m P3X_FW_V01.07.0060_m0306.bin
./dji_flyc_param_ed.py -vv -u -m P3X_FW_V01.07.0060_m0306.bin
Weitere Beispiele für andere Produkte:
./dji_flyc_param_ed.py -vv -x -b 0x420000 -m A3_FW_V01.02.00.00_m0306.bin
./dji_flyc_param_ed.py -vv -x -b 0x420000 -m MATRICE600_FW_V02.00.00.21_m0306.bin
./dji_flyc_param_ed.py -vv -x -b 0x420000 -m MATRICE600PRO_FW_V01.00.00.80_m0306.bin
./dji_flyc_param_ed.py -vv -x -b 0x420000 -m wm220_0306_v03.02.35.05_20170525.pro.bin
./dji_flyc_param_ed.py -vv -x -b 0x0000 -m wm230_0306_v01.00.02.255_20170213.bin
DJI Universal Packet Container Stream Pareser mit PCAP -Ausgangsformat.
Das Skript analysiert den Rohduml -Stream (dh Flugprotokolldateien FLY???.DAT ) und wickelt Einzelpakete mit PCAP -Headern ein. Pakete CRC werden überprüft, bevor die Daten übergeben werden. Jedes Tool mit PCAP -Formatunterstützung kann dann verwendet werden, um die Daten (dh Wireshark) zu analysieren.
Beispiel für die Konvertierung der Flugprotokolldatei:
./comm_dat2pcap.py -vv -d FLY002.DAT
DJI Serienbus -Sniffer mit DUML -Paket- und PCAP -Ausgangsformat.
Das Skript erfasst Daten von zwei UARTs und wickelt einzelne DUML -Pakete mit PCAP -Headern ein. Pakete CRC wird überprüft, bevor die Daten an die PCAP -Datei oder die FIFO -Pipe übergeben werden. Jedes Tool mit PCAP -Formatunterstützung kann dann verwendet werden, um die Daten (dh Wireshark) zu analysieren.
Das Dienstprogramm erfordert zwei serielle Schnittstellen mit RX -Linien, die mit RX- und TX -Linien in der Drohne verbunden sind.
Beispiel für den Start der Erfassung von zwei UART-to-TTL-Konvertern (auch bekannt als FTDI):
./comm_serial2pcap.py -b 115200 -F /tmp/wsf /dev/ttyUSB0 /dev/ttyUSB1
Duml Packet Builder mit Hex -String -Ausgabe.
Dieses Tool kann ein ordnungsgemäßes DUML -Paket erstellen, das angegebene Headerfelder und Nutzlast enthält. Das Paket wird in hexadezimaler Form ausgegeben. Liste der bekannten Befehle und das Aussehen der erwarteten Nutzlasten finden Sie in Wireshark -Disssektoren, die unten beschrieben wurden.
Beispiel für die Erzeugung eines Pakets, um das Spark Camera -Modul für seine Sensor -ID zu fragen:
./comm_mkdupc.py --receiver_type=Camera --seq_num=65280 --ack_type=ACK_After_Exec --cmd_set=Camera --cmd_id=181
DUML Builder, das Paket an DJI -Produkt sendet und eine Antwort erhält.
Dieses Tool erstellt ein ordnungsgemäßes DUML -Paket, das angegebene Headerfelder und Nutzlast enthält. Dann sendet es es über einen bestimmten seriellen Anschluss und wartet auf die Antwort. Es zeigt das zurückkehrende Paket beim Empfangen.
Es kann als Alternative zu dji_mb_ctrl Binary angesehen werden, die in einigen Drohnen zu finden ist. Die Parameternamen unterscheiden sich jedoch zwischen diesen beiden Tools.
Beispiel für die Frage, wie Flugcontroller nach Daten zur Hardware- und Firmware -Versionsdaten bitten (getestet auf PH3):
./comm_serialtalk.py --port /dev/ttyUSB0 -vv --timeout=5000 --receiver_type=FlyController --seq_num=65280 --ack_type=No_ACK_Needed --cmd_set=General --cmd_id=1
Beispiel für die Frage, dass Flugcontroller nach Daten für Hardware- und Firmware -Versions (Mavic 3) gefragt wird:
./comm_serialtalk.py --bulk -vv --timeout=5000 --receiver_type=FlyController --seq_num=65280 --ack_type=ACK_After_Exec --cmd_set=General --cmd_id=1
OGS -Service -Tool für DJI -Produkte.
Das Skript ermöglicht es, einige Servicefunktionen von DJI -Drohnen auszulösen. Es spricht mit der Drohne wie comm_serialtalk.py , bietet jedoch eine einfachere Schnittstelle für einige wichtige Funktionen.
Beispiel für die Auflistung von Flugcontroller-Parametern 200-300 auf PH3 Pro zu CSV-Format:
./comm_og_service_tool.py --port /dev/ttyUSB0 P3X FlycParam list --start=200 --count=100 --fmt=csv
Beispiel für den Wert von Flugcontroller -Parametern auf Spark:
./comm_og_service_tool.py --port /dev/ttyUSB0 -vv SPARK FlycParam get g_config.flying_limit.max_height_0 --fmt=2line
Beispiel für den Einstellungswert von Flugcontroller -Parametern auf Spark:
./comm_og_service_tool.py --port /dev/ttyUSB0 -vv SPARK FlycParam set g_config.flying_limit.max_height_0 500
Beispiel für die Durchführung von Service "Joint Grob" -Kalibrierung von Spark Gimbal:
./comm_og_service_tool.py --port /dev/ttyUSB0 -vv SPARK GimbalCalib JointCoarse
Beispiel für die Durchführung von Dienst "Linear Hall" -Kalibrierung von Spark Gimbal mit Windows Host:
python3 comm_og_service_tool.py --port COM23 -vv SPARK GimbalCalib LinearHall
Beispiel für die Auflistung von Flugcontroller-Parametern 200-300 im Mavic 3 Pro zu CSV-Format:
./comm_og_service_tool.py --bulk MAV3 FlycParam list --start=200 --count=100 --fmt=csv
Kommunikationsinstrument des Smart -Batterie -Systems.
Mit diesem Tool können Sie mit Chips interagieren, die auf der Basis von Smart -Battery -Datenspezifikationen entwickelt wurden. Es unterstützt auch einige Erweiterungen der von Texas Instruments in ihren BQ -Serien -Gasmesser -Chips implementierten Spezifikationen.
Die Verwendung dieses Tools erfordert eine Verbindung zu Smbus-Linien (SDA, SCL, GND) des SBS-kompatiblen Chips. Smbus Communication verwendet I2C als Basis, sodass die meisten Geräte mit I2C -Bus verwendet werden können, um die Kommunikation festzustellen.
Beispiel für das einfache Lesen von batteryStatus () unter Verwendung der I2C -Schnittstelle (das Skript erstellt Smbus -Nachrichten intern):
./comm_sbs_bqctrl.py -vvv --bus "i2c:1" --dev_address 0x0b read BatteryStatus
Beispiel für das Lesen mehrerer Flag -Felder von BQ30Z55 von HerstellerAccess () unter Verwendung der Smbus -Schnittstelle:
./comm_sbs_bqctrl.py -v --bus "smbus:1" --dev_address 0x0b --chip BQ30z55 --short monitor BQStatusBitsMA
Beispiel für den Entfesseln von BQ30Z55 (aktivierende Schreibfunktionen) mit Standard-SHA-1-Taste, wobei die I2C-Schnittstelle auf dem 2. Busgerät für Betriebssystem verfügbar ist:
./comm_sbs_bqctrl.py -v --bus "i2c:2" --dev_address 0x0b --chip BQ30z55 --short sealing Unseal
Der tests -Ordner enthält eine Sammlung von Skripten, mit denen Sie überprüfen können, ob die Tools ihre Arbeit korrekt erledigen. Dort gibt es zwei allgemeine Arten von Tests:
Kommunikationstools Tests, markiert comm . Dies sind für die Skripte, die normalerweise mit echten Geräten sprechen. Die Tests verleihen den erwarteten Antworten auf Empfangspuffer, sodass sie ohne angeschlossenes Produkt ausgeführt werden können.
Firmware -Extraktionstools -Tests mit fw_xv4 , fw_imah_v1 , fw_imah_v2 . Diese extrahieren und packen eine Firmware, die im Verzeichnis fw_packages gefunden wurde, die resultierende Datei mit dem Original vergleichen, um zu überprüfen, ob keine unbeabsichtigten Änderungen eingeführt wurden.
Neben dem Testen Ihrer Änderungen können Sie auch Tests als Quelle für mehr Verwendungsbeispiele für die Tools verwenden. Sie protokollieren Befehlszeilen, die zum Extrahieren bestimmter Unternehmenswares verwendet und bestimmte Befehle für die Produkte ausführen.
Die Tests sind darauf vorbereitet, mit pytest verwendet zu werden. Beispiel für die Ausführung aller Tests:
pytest tests -rsx --full-scope --log-cli-level=INFO
Die Option --full-scope Option lässt die Tests in allen bekannten Binärdateien ausgeführt, sondern bei einer Auswahl, die für die kontinuierliche Integration verwendet wird. Die CI -Tests sind selektiv, um sicherzustellen, dass der automatische Test in angemessener Zeit endet.
Erinnern Sie sich daran, dass die Tests nur auf Binärdateien ausgeführt werden, die im ordnungsgemäßen Unterordner des Ordners fw_packages platziert sind. In den Testskripten können gültige Namen der Unterordner leicht gefunden werden. Wenn keine Firmware -Binärdateien in den Ordner eingereicht werden, werden alle Firmware -Extraktionstests übersprungen.
Neben allen Tests können Sie auch eine bestimmte (mit -k ) oder eine Gruppe von Tests mit spezifischer Markierung (mit -m ) ausführen. Beispiel für das Ausführen fw_xv4 -Tests nur:
pytest tests -rsx --full-scope -m fw_xv4 --log-cli-level=DEBUG
Der Ordner enthält Wireshark -Dissektor für die Analyse der Kommunikation in DJI -Drohnen -Schnittstellen.
Die Dokumentation des Tools ist in seinem Ordner enthalten.
Für einige spezifische Firmware -Module in bestimmten Versionen stehen im Verzeichnis „Symbole“ teilweise Symbole zur Verfügung. Die Symbole sind in zwei Formaten:
Die Symbole werden mit Elf -Dateien übereinstimmen, die mit den oben beschriebenen Tools generiert werden, nicht direkt mit den Behältern. Verwenden Sie Beispielbefehle im vorherigen Abschnitt, um ELF -Dateien mit Inhalten zu generieren, die mit den Symbolen übereinstimmen.
Wenn Sie an einer Firmware -Version arbeiten, für die keine Symbole verfügbar sind, möchten Sie möglicherweise eine Version mit Symbolen als Referenz für die Benennung verwenden.
Wenn Sie nach einer besten FW -Version für Referenzsymbole suchen oder sich überhaupt nicht um FW -Versionen kümmern und nur die vollständigsten Symbole möchten, überprüfen Sie die Größe der Kartendatei. Die Kartendatei enthält hauptsächlich manuell benannte Symbole, daher ist die größte für die Firmware-Version, auf der mehr Umkehrarbeiten durchgeführt wurden.
