{"id":14982321,"url":"https://github.com/o-gs/dji-firmware-tools","last_synced_at":"2025-05-14T06:14:00.274Z","repository":{"id":37445294,"uuid":"64874678","full_name":"o-gs/dji-firmware-tools","owner":"o-gs","description":"Tools for handling firmwares of DJI products, with focus on quadcopters.","archived":false,"fork":false,"pushed_at":"2025-04-25T21:07:08.000Z","size":24436,"stargazers_count":1722,"open_issues_count":242,"forks_count":440,"subscribers_count":159,"default_branch":"master","last_synced_at":"2025-04-25T22:19:43.539Z","etag":null,"topics":["ambarella","dji","elf","firmware","inspire","mavic","modding","phantom","reverse-engineering","spark","tools"],"latest_commit_sha":null,"homepage":"","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/o-gs.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":"supported_firmwares_xv4.csv","governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2016-08-03T19:48:39.000Z","updated_at":"2025-04-25T21:07:16.000Z","dependencies_parsed_at":"2023-02-19T07:15:45.363Z","dependency_job_id":"8b194927-acbc-4563-a7e4-f752e6faa39f","html_url":"https://github.com/o-gs/dji-firmware-tools","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/o-gs%2Fdji-firmware-tools","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/o-gs%2Fdji-firmware-tools/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/o-gs%2Fdji-firmware-tools/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/o-gs%2Fdji-firmware-tools/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/o-gs","download_url":"https://codeload.github.com/o-gs/dji-firmware-tools/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254083783,"owners_count":22011902,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["ambarella","dji","elf","firmware","inspire","mavic","modding","phantom","reverse-engineering","spark","tools"],"created_at":"2024-09-24T14:05:11.766Z","updated_at":"2025-05-14T06:14:00.251Z","avatar_url":"https://github.com/o-gs.png","language":"C","funding_links":[],"categories":["C","⚙️ Backend \u0026 APIs","💽 Autopilot Firmware"],"sub_categories":["Firmware Extraction"],"readme":"# dji-firmware-tools\n\nTools for extracting, modding and re-packaging firmwares of [DJI](http://www.dji.com) multirotor drones.\n\n# Motivation\n\nThe project started as an alternative implementation of the parser from [phantom-licensecheck](https://github.com/probonopd/phantom-licensecheck).\nOver time it has grown to support many generations of DJI products.\nIt consists of tools which allow not only extraction, but also re-packing of\nthe previously extracted modules back into single file. There are also tools\nwhich are supposed to be used on specific modules to extract and allow modification\nof their content.\n\n# Use cases\n\nHere are a few of possible uses of the tools.\n\n### Calibration after repair\n\nReplacing some components of the drone may require calibration. The tools are\ncapable of triggering calibration in some devices, mostly gimbals with\n[Hall sensors](https://en.wikipedia.org/wiki/Hall_effect_sensor).\n\nIt is also possible to use them to send any custom packet to the drone, and\nthis way trigger factory functions like calibration or pairing - as long\nas you know how the packet should look like.\n\n### Parts identification on board and component level\n\nThe [wiki of this project](https://github.com/o-gs/dji-firmware-tools/wiki)\nhas tons of information about boards within each drone,\nand components on each board. This info is created and shared by many enthusiasts\nand repair technicians.\n\n### Flight parameters modification\n\nThe tools can be used as command line version of DJI Assistant software,\nwhich also allows to change parameters for platforms which lacks such\nOEM software or where it has the advanced functions locked.\n\nFlight Controllers from DJI define hunderds of parameters which affect their\nbehavior. These can be modified by just sending a command to the drone,\nas long as the new value is within limits accepted by FC firmware.\n\n### Firmware modification\n\nThe tools allow modifying firmware binaries, and then re-packing them back\ninto flashable firmware package. This way, any software-controled functionality\ncan be altered, including:\n* hardware pairing can be disabled,\n* allowed value ranges of parameters can be changed,\n* all hard-coded limits can be lifted or extended,\n* unused hardware features can be enabled,\n* additional devices can be added and integrated to the drone,\n* anything you can imagine, as long as you're capable of implementing the change.\n\nIt may sometimes require additional knowledge and software modifications\n(ie. rooting the drone) to flash modified firmware - some firmware packages\nare signed using asymmetric cryptography, and private keys are rarely available.\n\n### Research\n\nIf you're interested in DJI hardware and software, this is the place to start\nlearning. You can:\n\n* capture and analyze communication between modules within the drone and RC\nto figure out what specific hardware and software does,\n* use the wiki to compare hardware and software between platforms, or to analyze\nboards on component level before opening your drone,\n* extract firmware update packages to analyze and compare binaries executed by\neach programmable chip within the drone,\n* analyze a specific binary from firmware, for example by converting it to ELF\nand using disassembler to look at the content, applying symbols for easier\nunderstanding of what the code does,\n* find security vulnerabilities within firmware binaries and communication protocols,\n* compare firmware binaries between FW package versions,\n* parse flight logs generated by the drones,\n* get some basic knowledge to not act stupid when interacting with community\nof modders or researchers.\n\n# Step by step instruction\n\nSuch instruction will not be provided. These tools are for engineers with vast\nhardware and software knowledge. You need to know what you're doing to achieve\nanything with these tools.\n\nThis is to make sure the tools won't be used by script kiddies to disable\nsecurity mechanisms and to allow breaking local laws.\n\nIf you can't understand how the tools work, you should not use them. If any\nwarnings are shown, you must investigate the cause to make sure final firmware\nwill not be damaged. You are using the tools on your own risk.\n\nIf you don't know where to start, check the [tests](#tests). They will provide\nyou with command lines to communicate to the drone, or to extract all the layers\nof a specific firmware (as long as you can place it correctly).\n\n# Firmware structure\n\nSince all the tools are available in source code form, it is easy to check details\non the structure and protocols processed by these tools by looking at their source.\nThe source code is intended to also act as a format documentation.\n\nFor higher level and more hardware related info, check [the project Wiki](https://github.com/o-gs/dji-firmware-tools/wiki).\n\n# Tools\n\nThe tools can be divided into two categories:\n\n* Hardware-independent tools - Those for which you do not need to have any DJI product\nto use. You just need an input file they use, like DJI Firmware Package or DAT Log file.\n\n* Product Communication tools - You need to connect your drone to a PC in order\nto use these tools in any meaningful way. Currently the tools use serial interface\n(UART) and I2C.\n\nBelow the specific tools are described in short. Running them without parameters\nwill give you details on supported commands in each of them.\n\nTo get specifics about command line arguments of each tool, run them with `--help`\noption. Some tools also have additional remarks in their headers - try viewing them.\n\n### dji_xv4_fwcon.py\n\nDJI Firmware xV4 Container tool; allows extracting modules from package file which\nstarts with `xV4`, or creating container by merging firmware modules. Use this tool\nfirst, to extract the BIN file downloaded from DJI, as long as the file starts with\n`xV4`.\n\nExample of extracting modules from DJI firmware package for *Phantom 3 Pro*:\n\n```./dji_xv4_fwcon.py -vv -x -p P3X_FW_V01.08.0080.bin```\n\n### dji_imah_fwsig.py\n\nDJI Firmware IMaH Un-signer and Decryptor tool; allows to decrypt and un-sign module\nfrom `.sig` file which starts with `IM*H`. Use this tool after untarring single\nmodules from a firmware package, to decrypt its content. The tool can also re-sign\na module, as long as private part of the chosen key is available.\n\nKeys used for encryption and authentication were changing over time; when an\n`IM*H` file refers to a key for which the tool has several versions, it will\ndisplay a list of possible keys in a warning message, and select the most\nrecent key for current operation.\n\nExample of un-signing Camera firmware for *Mavic Pro*:\n\n```./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```\n\nExample of un-signing FC firmware for *Phantom 4 Pro V2*:\n\n```./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```\n\nExample of signing previously un-signed FC firmware for *Mini 2* (requires `PRAK` with private part):\n\n```./dji_imah_fwsig.py -vv -k PRAK-2019-09 -s -i wm161_0306_v03.04.09.74_20210112.pro.fw.sig```\n\nFor more examples of usage of the tool, as well as identifiers of keys for specific\nplatforms, read the script used for testing it: `tests/test_dji_imah_fwsig_rebin1.sh`.\n\n### dji_mvfc_fwpak.py\n\nDJI Mavic Flight Controller Firmware Decryptor tool; removes second layer encryption\nin Flight Controller firmware modules from several DJI products released around the\nsame period: *Mavic Pro*, *Spark*, *Inspire 2* and *Phantom 4*. Does not accept `IM*H`\nformat - requires input files with first level encryption already removed.\n\nExample of decrypting FC firmware for *Mavic Pro*:\n\n```./dji_mvfc_fwpak.py dec -i wm220_0306_v03.02.40.11_20170918.pro.fw```\n\n### amba_fwpak.py\n\nAmbarella A7/A9 firmware pack tool; allows extracting partitions from the\nfirmware, or merging them back. Use this to extract Ambarella firmware from\nfiles created after DJI Container is extracted. You can recognize the Ambarella\nfirmware by a lot of \"Amba\" strings within, or by a 32-char zero-padded string\nat the beginning of the file.\n\nExample of extracting partitions from Ambarella firmware for *Phantom 3 Pro*:\n\n```./amba_fwpak.py -vv -x -m P3X_FW_V01.08.0080_m0100.bin```\n\n### amba_romfs.py\n\nAmbarella A7/A9 firmware ROMFS filesystem tool; allows extracting single files\nfrom ROMFS filesystem file, or rebuilding filesystem from the single files.\nUse this after the Ambarella firmware is extracted. You can recognize ROMFS\npartitions by file names near beginning of the file, surrounded by blocks of\n0xff filled bytes.\n\nExample of extracting ROMFS partition from Ambarella firmware for *Phantom 3 Pro*:\n\n```./amba_romfs.py -vv -x -p P3X_FW_V01.08.0080_m0100_part_rom_fw.a9s```\n\n### amba_ubifs.sh\n\nLinux script for mounting UBIFS partition from the Ambarella firmware. After\nmounting, the files can be copied or modified. Use this after the Ambarella\nfirmware is extracted. The file containing UBIFS can be easily recognized\nby `UBI#` at the beginning of the file.\n\nExample of mounting Root Filesystem partition from Ambarella firmware for *Phantom 3 Pro*:\n\n```sudo ./amba_ubifs.sh P3X_FW_V01.08.0080_m0100_part_rfs.a9s```\n\n\n### arm_bin2elf.py\n\nTool which wrapps binary executable ARM images with ELF header. If a firmware\ncontains binary image of executable file, this tool can rebuild ELF header for it.\nThe ELF format can be then easily disassembled, as most debuggers can read ELF files.\nNote that using this tool on encrypted firmwares will not result in useable ELF.\n\nExample of converting FC firmware for *Phantom 3* to ELF:\n\n```./arm_bin2elf.py -vv -e -b 0x8020000 -l 0x6000000 -p P3X_FW_V01.07.0060_m0306.bin```\n\nThe command above will cause the tool to try and detect where the border between\ncode (`.text`) and data (`.data`) sections should be. This detection is not perfect,\nespecially for binaries with no `.ARM.exidx` section between them. If `.ARM.exidx`\nexists in the binary, the tool can easily find it and divide binary data properly,\ntreating `.ARM.exidx` as a separator between `.text` and `.data`.\n\nIn other words, position of the `.ARM.exidx` influences length of the `.text` section,\nand starting offset of the `.data` section. If there is no `.ARM.exidx` section in\nthe file, it will still be used as separator, just with zero size.\nAfter first look at the disassembly, it is good to check where the correct border\nbetween `.text` and `.data` sections is located. Memory address of this location can\nbe used to generate better ELF file.\n\nAdditional updates to the ELF after first look can include defining `.bss` sections.\nThese sections represent uninitialized RAM and MMIO areasused by the binary. It is\ntempting to just define one big section which covers whole memory map address range\naccording to programming guide of the chip, but that results in huge memory usage\nand related slowdowns while disassembling the file, while also making the file harder\nto navigate.\n\nNote that all section offsets are defined using in-memory address, not the position\nwithin BIN file. If you have found proper location of a section within BIN file,\nremember to add base address to the file position before inserting to the command\nline of this tool.\n\nBase address can be often found in programming guide of the specific chip; sometimes it\nmay be shifted from that location, if the binary is loaded by an additional bootloader.\nIn such cases the bootloader takes the location from documentation, and the real firmware\nbinary is loaded at a bit higher base address.\n\nOptimized examples for specific firmwares:\n\n```./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```\n\n```./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```\n\n```./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```\n\n```./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```\n\n```./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```\n\n```./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```\n\n```./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```\n\n```./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```\n\n```./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```\n\n```./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```\n\n```./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```\n\n```./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```\n\nThis tool supports only conversion in direction of bin-to-elf. To convert an ELF\nfile back to BIN (ie. after modifications), use `objcopy` utility for the\nspecific architecture. The `objcopy` tool is a part of GNU Binary Utilities\n(`binutils`) and not a part of this repository.\n\nExamples:\n\n```arm-none-eabi-objcopy -O binary P3X_FW_V01.07.0060_m0100_part_sys.elf P3X_FW_V01.07.0060_m0100_part_sys.bin```\n\n```arm-none-eabi-objcopy -O binary P3X_FW_V01.07.0060_m0900.elf P3X_FW_V01.07.0060_m0900.bin```\n\n### amba_sys2elf.py\n\nAmbarella A7/A9 firmware \"System Software\" partition converter. The partition\ncontains a binary image of executable file, and this tool wraps it with ELF\nheader. The ELF format can be then easily disassembled, as most debuggers can\nread ELF files. This tool is very similar to `arm_bin2elf.py`, it is just\npre-configured to specific firmware.\n\nExample: ```./amba_sys2elf.py -vv -e -l 0x6000000 -p P3X_FW_V01.08.0080_m0100_part_sys.a9s```\n\nAll border adjusting rules explained for `arm_bin2elf.py` apply for this tool as well.\n\nOptimized examples for specific firmwares:\n\n```./amba_sys2elf.py -vv -e -l 0x6000000 --section .ARM.exidx@0xEA83E4C:0 -p P3X_FW_V01.08.0080_m0100_part_sys.a9s```\n\n```./amba_sys2elf.py -vv -e -l 0x6000000 --section .ARM.exidx@0xEA82EC0:0 -p P3X_FW_V01.07.0060_m0100_part_sys.a9s```\n\n```./amba_sys2elf.py -vv -e -l 0x6000000 --section .ARM.exidx@0xEA64774:0 -p P3X_FW_V01.01.0008_m0100_part_sys.a9s```\n\n### amba_sys_hardcoder.py\n\nAmbarella A7/A9 firmware \"System Software\" partition hard-coded values editor.\n\nThe tool can parse Ambarella firmware SYS partition converted to ELF.\nIt finds certain hard-coded values in the binary data, and allows\nexporting or importing them. Only `setValue` element in the exported JSON file\nis really changeable, all the other data is just informational.\n\nExample of exporting hard-coded values to JSON file:\n\n```./amba_sys_hardcoder.py -vv -x --elffile P3X_FW_V01.08.0080_m0100_part_sys.elf```\n\nExample of importing values from JSON file back to ELF:\n\n```./amba_sys_hardcoder.py -vv -u --elffile P3X_FW_V01.08.0080_m0100_part_sys.elf```\n\n### dm3xx_encode_usb_hardcoder.py\n\nDji DM3xx DaVinci encode_usb binary hard-coded values editor.\n\nThe tool can parse encode_usb ELF file from Dji Firmware module for\nTI DM3xx DaVinci Media Processor.\nIt finds certain hard-coded values in the binary data, and allows\nexporting or importing them.\n\nExample of exporting hard-coded values to JSON file:\n\n```./dm3xx_encode_usb_hardcoder.py -vv -x --elffile P3X_FW_V01.07.0060_m0800-encode_usb.elf```\n\nExample of importing values from JSON file back to ELF:\n\n```./dm3xx_encode_usb_hardcoder.py -vv -u --elffile P3X_FW_V01.07.0060_m0800-encode_usb.elf```\n\n### lightbridge_stm32_hardcoder.py\n\nDji Lightbridge STM32 micro-controller binary hard-coded values editor.\n\nThe tool can parse Lightbridge MCU firmware converted to ELF.\nIt finds certain hard-coded values in the binary data, and allows\nexporting or importing them.\n\nExample of exporting hard-coded values to JSON file:\n\n```./lightbridge_stm32_hardcoder.py -vv -x --elffile P3X_FW_V01.07.0060_m0900.elf```\n\nExample of importing values from JSON file back to ELF:\n\n```./lightbridge_stm32_hardcoder.py -vv -u --elffile P3X_FW_V01.07.0060_m0900.elf```\n\n### dji_flyc_hardcoder.py\n\nDji Flight Controller firmware binary hard-coded values editor.\n\nThe tool can parse Flight Controller firmware converted to ELF.\nIt finds certain hard-coded values in the binary data, and allows\nexporting or importing them.\n\nExample of exporting hard-coded values to JSON file:\n\n```./dji_flyc_hardcoder.py -vvv -x -e P3X_FW_V01.07.0060_m0306.elf```\n\nExample of importing values from JSON file back to ELF:\n\n```./dji_flyc_hardcoder.py -vvv -u -e P3X_FW_V01.07.0060_m0306.elf```\n\n### dji_flyc_param_ed.py\n\nFlight Controller Firmware Parameters Array Editor finds an array of flight\nparameters within firmware binary, and allows to extract the parameters to a JSON\nformat text file. This file can then easily be modified, and used to update\nbinary firmware, changing attributes and limits of each parameter.\n\nIn order to find the Parameters Array, the tool needs base address used for loading\nthe binary file into RAM of the micro-controller. If you don't know the base address\nto use, programming guide of the specific chip used may give you clues.\n\nExample of extracting and then updating the flight controller parameters:\n\n```./dji_flyc_param_ed.py -vv -x -m P3X_FW_V01.07.0060_m0306.bin```\n\n```./dji_flyc_param_ed.py -vv -u -m P3X_FW_V01.07.0060_m0306.bin```\n\nMore examples, for other products:\n\n```./dji_flyc_param_ed.py -vv -x -b 0x420000 -m A3_FW_V01.02.00.00_m0306.bin```\n\n```./dji_flyc_param_ed.py -vv -x -b 0x420000 -m MATRICE600_FW_V02.00.00.21_m0306.bin```\n\n```./dji_flyc_param_ed.py -vv -x -b 0x420000 -m MATRICE600PRO_FW_V01.00.00.80_m0306.bin```\n\n```./dji_flyc_param_ed.py -vv -x -b 0x420000 -m wm220_0306_v03.02.35.05_20170525.pro.bin```\n\n```./dji_flyc_param_ed.py -vv -x -b 0x0000 -m wm230_0306_v01.00.02.255_20170213.bin```\n\n### comm_dat2pcap.py\n\nDJI Universal Packet Container stream pareser with pcap output format.\n\nThe script parses Raw DUML stream (ie. flight log files ```FLY???.DAT```) and wraps\nsingle packets with PCap headers. Packets CRC is checked before the data is passed.\nAny tool with PCap format support can then be used to analyse the data (ie. Wireshark).\n\nExample of converting flight log file:\n\n```./comm_dat2pcap.py -vv -d FLY002.DAT```\n\n### comm_serial2pcap.py\n\nDJI serial bus sniffer with DUML packetizer and PCap output format.\n\nThe script captures data from two UARTs and wraps single DUML packets with PCap headers.\nPackets CRC is checked before the data is passed to the PCap file or FIFO pipe.\nAny tool with pcap format support can then be used to analyse the data (ie. Wireshark).\n\nThe utility requires two serial interfaces with RX lines connected to RX and TX lines\nwithin the drone.\n\nExample of starting the capture from two UART-to-TTL (aka FTDI) converters:\n\n```./comm_serial2pcap.py -b 115200 -F /tmp/wsf /dev/ttyUSB0 /dev/ttyUSB1```\n\n### comm_mkdupc.py\n\nDUML Packet Builder with hex string output.\n\nThis tool can build a proper DUML packet containing given header fields and payload.\nThe packet will be outputed in hexadecimal form. List of known commands and the look\nof expected payloads can be found in Wireshark dissectors described below.\n\nExample of generating a packet to ask Spark camera module for its Sensor ID:\n\n```./comm_mkdupc.py --receiver_type=Camera --seq_num=65280 --ack_type=ACK_After_Exec --cmd_set=Camera --cmd_id=181```\n\n### comm_serialtalk.py\n\nDUML Builder which sends packet to DJI product and receives a response.\n\nThis tool builds a proper DUML packet containing given header fields and payload.\nThen it sends it via given serial port and waits for response. It shows the\nreturning packet upon receiving it.\n\nIt can be considered an alternative to `dji_mb_ctrl` binary which can be found\nin some drones. Parameter names are different between these two tools though.\n\nExample of asking Flight Controller for hardware and firmware version data (tested on Ph3):\n\n```./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```\n\nExample of asking Flight Controller for hardware and firmware version data (Mavic 3):\n\n```./comm_serialtalk.py --bulk -vv --timeout=5000 --receiver_type=FlyController --seq_num=65280 --ack_type=ACK_After_Exec --cmd_set=General --cmd_id=1```\n\n### comm_og_service_tool.py\n\nOGs Service Tool for Dji products.\n\nThe script allows to trigger a few service functions of Dji drones. It talks to the drone\nlike `comm_serialtalk.py`, but provides easier interface for some important functions.\n\nExample of listing Flight Controller Parameters 200-300 on Ph3 Pro to CSV format:\n\n```./comm_og_service_tool.py --port /dev/ttyUSB0 P3X FlycParam list --start=200 --count=100 --fmt=csv```\n\nExample of getting value of Flight Controller Parameters on Spark:\n\n```./comm_og_service_tool.py --port /dev/ttyUSB0 -vv SPARK FlycParam get g_config.flying_limit.max_height_0 --fmt=2line```\n\nExample of setting value of Flight Controller Parameters on Spark:\n\n```./comm_og_service_tool.py --port /dev/ttyUSB0 -vv SPARK FlycParam set g_config.flying_limit.max_height_0 500```\n\nExample of performing service \"joint coarse\" calibration of Spark gimbal:\n\n```./comm_og_service_tool.py --port /dev/ttyUSB0 -vv SPARK GimbalCalib JointCoarse```\n\nExample of performing service \"linear hall\" calibration of Spark gimbal, using Windows host:\n\n```python3 comm_og_service_tool.py --port COM23 -vv SPARK GimbalCalib LinearHall```\n\nExample of listing Flight Controller Parameters 200-300 on the Mavic 3 Pro to CSV format:\n\n```./comm_og_service_tool.py --bulk MAV3 FlycParam list --start=200 --count=100 --fmt=csv```\n\n### comm_sbs_bqctrl.py\n\nSmart Battery System communication tool.\n\nThis tool allows to interact with chips designed based on Smart Battery Data\nSpecification. It also supports some extensions to that specification\nimplemented by Texas Instruments in their BQ series gas gauge chips.\n\nUsage of this tool requires connection to SMBus lines (SDA,SCL,GND) of the\nSBS-compatible chip. SMBus communication uses I2C as a base, so most devices\nwith I2C bus can be used to establish the communication.\n\nExample of simple read of BatteryStatus(), using I2C interface (the script will construct SMBus messages internally):\n\n```./comm_sbs_bqctrl.py -vvv --bus \"i2c:1\" --dev_address 0x0b read BatteryStatus```\n\nExample of reading several flag fields from BQ30z55 by ManufacturerAccess(), using SMBus interface:\n\n```./comm_sbs_bqctrl.py -v --bus \"smbus:1\" --dev_address 0x0b --chip BQ30z55 --short monitor BQStatusBitsMA```\n\nExample of unsealing BQ30z55 (enabling write capabilities), with default SHA-1 key, using I2C interface on 2nd bus device available to OS:\n\n```./comm_sbs_bqctrl.py -v --bus \"i2c:2\" --dev_address 0x0b --chip BQ30z55 --short sealing Unseal```\n\n### tests\n\nThe `tests` folder contains a collection of scripts which can be used to verify\nwhether the tools do their job correctly. There are two general types of tests\nthere:\n\n* Communication tools tests, marked `comm`. These are for the scripts which normally\n talk to real devices. The tests are injecting expected answers to receive\n buffers, so they can be run without the product connected.\n\n* Firmware extraction tools tests, marked `fw_xv4`, `fw_imah_v1`, `fw_imah_v2`.\n These extract and re-pack a firmware found in `fw_packages` directory, then\n compare the resulting file to original to check whether no unintended changes\n were introduced.\n\nBesides testing your modifications, you can also use tests as source of more\nusage examples of the tools. They log command lines used to extract specific\nfirmwares and execute specific commands on the products.\n\nThe tests are prepared to be used with `pytest`. Example of executing all tests:\n\n```pytest tests -rsx --full-scope --log-cli-level=INFO```\n\nThe `--full-scope` option makes the tests execute on all known binaries, rather\nthat on a selection used for continous integration. The CI tests are selective\nto make sure the automatic testing ends in reasonable time.\n\nRemeber that the tests will only run on binaries placed in proper sub-folder\nof the `fw_packages` folder. Valid names of sub-folders can be easily found\nwithin the test scripts. If no firmware binaries are put to the folder,\nall firmware extraction tests will be skipped.\n\nBesides running all tests, you can also run a specific one (with `-k`) or a group\nof tests with specific marking (with `-m`). Example of running `fw_xv4` tests only:\n\n```pytest tests -rsx --full-scope -m fw_xv4 --log-cli-level=DEBUG```\n\n\n### comm_dissector\n\nThe folder contains [Wireshark](https://www.wireshark.org/) dissector for for analyzing\ncommunication in DJI drone interfaces.\n\nDocumentation of the tool is [included in its folder](comm_dissector/README.md).\n\n# Symbols\n\nFor some specific firmware modules in specific versions, there are partial symbols\navailable in 'symbols' directory. The symbols are in two formats:\n\n- MAP files - Can be loaded into most disassemblers with minimal effort. For IDA Pro,\nthere is a plugin which can read MAP files and rename functions and variables\naccordingly. Only functions and global variables which were given a meaningful names\nare included in these files.\n- IDC script - Format specific to IDA Pro. Stores not only functions and globals,\nbut also type information - enums and structs. Allows storing function parameters\nand local variables with their names and types, too. Can be easily applied to an\nopened ELF file via IDA Pro, no other tool will understand it.\n\nSymbols are matched with ELF files generated with the tools described above,\nnot directly with the BINs. Use example commands provided in previous section\nto generate ELF files with content matching to the symbols.\n\nWhen working on a firmware version for which no symbols are available, you may\nwant to use a version with symbols for reference in naming.\n\nIf you are looking for a best FW version for reference symbols, or you do not care\nfor FW versions at all and just want the most complete symbols - check size of MAP\nfile. MAP file mostly contains manually-named symbols, so the largest one will be\nfor firmware version on which more reversing work was done.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fo-gs%2Fdji-firmware-tools","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fo-gs%2Fdji-firmware-tools","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fo-gs%2Fdji-firmware-tools/lists"}