大疆firmware-tools-master

# dji-firmware-tools Tools for extracting, modding and re-packaging firmwares of [DJI](http://www.dji.com) multirotor drones. # Motivation The project started as an alternative implementation of the parser from [phantom-licensecheck](https://github.com/probonopd/phantom-licensecheck). Over time it has grown to support many generations of DJI products. It consists of tools which allow not only extraction, but also re-packing of the previously extracted modules back into single file. There are also tools which are supposed to be used on specific modules to extract and allow modification of their content. # Step by step instruction Such instruction will not be provided. These tools are for engineers with vast hardware and software knowledge. You need to know what you're doing to achieve anything with these tools. This is to make sure the tools won't be used by script kiddies to disable security mechanisms and to allow breaking the law. If you can't understand how the tools work, you should not use them. If any warnings are shown, you must investigate the cause to make sure final firmware will not be damaged. You are using the tools on your own risk. # Firmware structure Since all the tools are available in source code form, it is easy to check details on the structure and protocols processed by these tools by looking at their source. The source code is intended to also act as a format documentation. For higher level and more hardware related info, check [the project Wiki](https://github.com/o-gs/dji-firmware-tools/wiki). # Tools Below the specific tools are described in short. Running them without parameters will give you details on supported commands in each of them. To get specifics about command line arguments of each tool, run them with `--help` option. Some tools also have additional remarks in their headers - try viewing them. ### dji_xv4_fwcon.py DJI Firmware xV4 Container tool; allows extracting modules from package file which starts with `xV4`, or creating container by merging firmware modules. Use this tool first, to extract the BIN file downloaded from DJI, as long as the file starts with `xV4`. Example: ```./dji_xv4_fwcon.py -vv -x -p P3X_FW_V01.08.0080.bin``` ### dji_imah_fwsig.py DJI Firmware IMaH Un-signer and Decryptor tool; allows to decrypt and un-sign module from `.sig` file which starts with `IM*H`. Use this tool after untarring single modules from a firmware package, to decrypt its content. The tool can also sign an un-signed module, as long as private part of the chosen key is available. Example: ```./dji_imah_fwsig.py -vv -u -i wm335_0306_v03.03.04.10_20180429.pro.fw.sig``` ### dji_mvfc_fwpak.py DJI Mavic Flight Controller Firmware Decryptor tool; removes second layer encryption in Flight Controller firmware modules from several DJI products released around the same period: Mavic Pro, Spark, Inspire 2 and Phantom 4. Does not accept `IM*H` format - requires input files with first level encryption already removed. Example: ```./dji_mvfc_fwpak.py dec -i wm220_0306_v03.02.40.11_20170918.pro.fw``` ### amba_fwpak.py Ambarella A7/A9 firmware pack tool; allows extracting partitions from the firmware, or merging them back. Use this to extract Ambarella firmware from files created after DJI Container is extracted. You can recognize the Ambarella firmware by a lot of "Amba" strings within, or by a 32-char zero-padded string at the beginning of the file. Example: ```./amba_fwpak.py -vv -x -m P3X_FW_V01.08.0080_m0100.bin``` ### amba_romfs.py Ambarella A7/A9 firmware ROMFS filesystem tool; allows extracting single files from ROMFS filesystem file, or rebuilding filesystem from the single files. Use this after the Ambarella firmware is extracted. You can recognize ROMFS partitions by file names near beginning of the file, surrounded by blocks of 0xff filled bytes. Example: ```./amba_romfs.py -vv -x -p P3X_FW_V01.08.0080_m0100_part_rom_fw.a9s``` ### amba_ubifs.sh Linux script for mounting UBIFS partition from the Ambarella firmware. After mounting, the files can be copied or modified. Use this after the Ambarella firmware is extracted. The file containing UBIFS can be easily recognized by `UBI#` at the beginning of the file. Example: ```sudo ./amba_ubifs.sh P3X_FW_V01.08.0080_m0100_part_rfs.a9s``` ### arm_bin2elf.py Tool which wrapps binary executable ARM images with ELF header. If a firmware contains binary image of executable file, this tool can rebuild ELF header for it. The ELF format can be then easily disassembled, as most debuggers can read ELF files. Note that using this tool on encrypted firmwares will not result in useable ELF. Example: ```./arm_bin2elf.py -vv -e -b 0x8020000 -l 0x6000000 -p P3X_FW_V01.07.0060_m0306.bin``` The command above will cause the tool to try and detect where the border between code (`.text`) and data (`.data`) sections should be. This detection is not perfect, especially for binaries with no `.ARM.exidx` section between them. If `.ARM.exidx` exists in the binary, the tool can easily find it and divide binary data properly, treating `.ARM.exidx` as a separator between `.text` and `.data`. In other words, position of the `.ARM.exidx` influences length of the `.text` section, and starting offset of the `.data` section. If there is no `.ARM.exidx` section in the file, it will still be used as separator, just with zero size. After first look at the disassembly, it is good to check where the correct border between `.text` and `.data` sections is located. File offset of this location can be used to generate better ELF file. Additional updates to the ELF after first look can include defining `.bss` sections. These sections represent uninitialized RAM used by the binary. It is tempting to just define one big section which covers whole RAM address range according to programming guide of the chip, but that results in huge memory usage and related slowdowns while disassembling the file. Note that all section offsets are defined using start of the BIN file as reference, or in other words - they assume base address of 0x0. If you have found proper location of a section, remember to remove base address from the memory location before inserting to the command line of this tool. Base address can be often found in programming guide of the specific chip; sometimes it may be shifted from that location, if the binary is loaded by an additional bootloader. In such cases the bootloader takes the location from documentation, and the real firmware binary is loaded at a bit higher base address. Optimized examples for specific firmwares: ```./arm_bin2elf.py -vv -e -b 0x8020000 --section .ARM.exidx@0x085d34:0 --section .bss@0x07fe0000:0xA000 --section .bss2@0x17fe0000:0x30000 --section .bss3@0x37fe0000:0x30000 -p P3X_FW_V01.07.0060_m0306.bin``` ```./arm_bin2elf.py -vv -e -b 0x000a000 --section .ARM.exidx@0x01ce50:0 --section .bss@0xfff6000:0x8000 --section .bss2@0x3fff6000:0x50000 --section .bss3@0xdfff6000:0x10000 -p C1_FW_V01.06.0000_m1400.bin``` ```./arm_bin2elf.py -vv -e -b 0x000a000 --section .ARM.exidx@0x0193E0:0 --section .bss@0x1ff6000:0x4000 --section .bss2@0x1ffe000:0x1000 --section .bss3@0x1bff6000:0x2400 --section .bss4@0x1c01a000:0x2400 --section .bss5@0x40022000:0x50000 --section .bss6@0x400ee000:0x200 --section .bss7@0xe0004000:0x1200 -p C1_FW_V01.06.0000_m1401.bin``` ```./arm_bin2elf.py -vv -e -b 0x8008000 --section .ARM.exidx@0x0D510:0 --section .bss@0x17FF7700:0x5A00 --section .bss2@0x37ff8000:0x6700 --section .bss3@0x38008000:0x5500 --section .bss4@0x38018000:0x2200 --section .bss5@0x3a1f8000:0x100 --section .bss6@0x3a418000:0x500 -p P3X_FW_V01.08.0080_m0900.bin``` ```./arm_bin2elf.py -vv -e -b 0x8008000 --section .ARM.exidx@0x0136D0:0 --section .bss@0x17FF7700:0xC900 --section .bss2@0x37ff8000:0x6700 --section .bss3@0x38008000:0x5500 --section .bss4@0x38018000:0x7000 --section .bss5@0x48058800:0x100 -p P3X_FW_V01.11.0030_m0400.bin``` ```./arm_bin2elf.py -vv -e -b 0x04200