This thread is to clear misconceptions when:
- someone claims he/she flashed wrong firmware to a Dji drone
- someone warns about flashing wrong firmware
Such claims are always misunderstandings or misinterpretations. In fact, you need some specific knowledge and malicious intentions in order to flash invalid firmware to a DJI drone.
In summary:
- If you will place incorrect FW on sd-card, the drone will ignore it, and it will not start flashing
- If you will select wrong product while updating via mobile app, the app will either download correct firmware anyway, or will fail the update soon after download, before any component is updated
- Even if you place two firmwares on the SD-card, it will not cause any issue and the update will not start unless you sort things out and leave only one update on the card
Details:
Now for a proof, let's look at specific case - trying to update P3 Pro (P3X) with P3 Adv (P3S) firmware.
So we place specific firmware, say "P3S_FW_V01.11.0030.bin", on the SD-card. We turn on the drone. What happens? Thankfully we can look at the update code within firmware - we will use code from "P3X_FW_V01.08.0080.bin" for the example.
The code is:
The DjiUegGetPacketFileNameWildcard() will return:
- "P3X_FW_V??.??.????.bin" on first run
- "P3X_FW_V??.??.????_????.bin" on second run
For each of these file masks, AmbaFS_FirstDirEnt() and AmbaFS_NextDirEnt() will search for matching files in root folder of the SD-card.
Only if exactly one matching file is found, the file will go to process of its verification.
Note that our "P3S_FW_V01.11.0030.bin" does not match any of the mask - so it will be ignored. The end.
But let's assume someone has malicious intentions and will in purpose rename the firmware to "P3X_FW_V01.11.0030.bin". Now will the file pass?
It will pass the initial file searching above, but will be rejected soon after reading its header:
If we will look insde our renamed P3S firmware, we will notice that buf->magic will pass the test, and so buf->manufacturer will, but - buf->model in our renamed firmware is different! No update!
We will have to be double malicious. We use a hex editor to modify the binary file, and change the "P3S" string in its header to "P3X". Now we pass the buf->model test. So, will it update?
By changing the binary data within the file, we influenced the header checksum - CRC. So now the next call - DjiUegPkgVerifyCrc() - will fail. Update will not start.
It is getting hard to damage that pesky drone.. but we have dji-firmware-tools! Being triple malicious, we can extract the firmware, modify metadata in the extracted files, and re-pack it. The tools will take care of updating the CRC, so that the above tests will all pass. Not a path a complete newbie can follow, but many people can do that.
We will run into several more issues we need to fix in specific modules (ie. in this specific case we need to change header of Ambarella firmware from "FC300S" to "FC300X"), but this brings us relatively close to bricking the drone with wrong firmware. Being quadruple malicious is enough.
Now, was that easy path to follow? Is it possible to "accidently" write wrong firmware? You decide.
- someone claims he/she flashed wrong firmware to a Dji drone
- someone warns about flashing wrong firmware
Such claims are always misunderstandings or misinterpretations. In fact, you need some specific knowledge and malicious intentions in order to flash invalid firmware to a DJI drone.
In summary:
- If you will place incorrect FW on sd-card, the drone will ignore it, and it will not start flashing
- If you will select wrong product while updating via mobile app, the app will either download correct firmware anyway, or will fail the update soon after download, before any component is updated
- Even if you place two firmwares on the SD-card, it will not cause any issue and the update will not start unless you sort things out and leave only one update on the card
Details:
Now for a proof, let's look at specific case - trying to update P3 Pro (P3X) with P3 Adv (P3S) firmware.
So we place specific firmware, say "P3S_FW_V01.11.0030.bin", on the SD-card. We turn on the drone. What happens? Thankfully we can look at the update code within firmware - we will use code from "P3X_FW_V01.08.0080.bin" for the example.
The code is:
Code:
for (i = 0; i < 2; i++)
{
// Get file mask for searching
if (DjiUegGetPacketFileNameWildcard(i, wildstr) != 0) {
continue;
}
[...]
// find first file matching the mask
if (AmbaFS_FirstDirEnt(full_wildstr, 0x61u, &pDirEnt) != 0) {
continue;
}
// Add the found file to a list
[...]
num_firmwares_found++;
[...]
while (AmbaFS_NextDirEnt(&pDirEnt) == 0)
{
// Add the found file to a list
[...]
num_firmwares_found++;
[...]
}
}
[...]
if (num_firmwares_found != 1) {
return -1;
}
// Start the file verification
The DjiUegGetPacketFileNameWildcard() will return:
- "P3X_FW_V??.??.????.bin" on first run
- "P3X_FW_V??.??.????_????.bin" on second run
For each of these file masks, AmbaFS_FirstDirEnt() and AmbaFS_NextDirEnt() will search for matching files in root folder of the SD-card.
Only if exactly one matching file is found, the file will go to process of its verification.
Note that our "P3S_FW_V01.11.0030.bin" does not match any of the mask - so it will be ignored. The end.
But let's assume someone has malicious intentions and will in purpose rename the firmware to "P3X_FW_V01.11.0030.bin". Now will the file pass?
It will pass the initial file searching above, but will be rejected soon after reading its header:
Code:
int DjiUegPktHeaderCheck(const char *fname, struct FwPkgHeader *buf)
{
[...]
if (buf->magic != 0x12345678)
{
DJIUEG_LOG(1,"%s: Invalid Param! MagicCode[0x%08x].",__func__,buf->magic);
return -1;
}
if (strcmp(buf->manufacturer, "DJI") != 0)
{
DJIUEG_LOG(1,"%s: Invalid Param! Manufacturer[%s].",__func__,buf->manufacturer);
return -1;
}
if (strcmp(buf->model, "P3X") != 0)
{
DJIUEG_LOG(1, "%s: Invalid Param! ProductName[%s].", __func__, buf->model);
return -1;
}
if (DjiUegPkgVerifyCrc(buf, buf->hdrend_offs, 0x3692))
{
DJIUEG_LOG(1, "%s: Vertify Header Crc Fail!", __func__);
return -1;
}
[...]
}
If we will look insde our renamed P3S firmware, we will notice that buf->magic will pass the test, and so buf->manufacturer will, but - buf->model in our renamed firmware is different! No update!
We will have to be double malicious. We use a hex editor to modify the binary file, and change the "P3S" string in its header to "P3X". Now we pass the buf->model test. So, will it update?
By changing the binary data within the file, we influenced the header checksum - CRC. So now the next call - DjiUegPkgVerifyCrc() - will fail. Update will not start.
It is getting hard to damage that pesky drone.. but we have dji-firmware-tools! Being triple malicious, we can extract the firmware, modify metadata in the extracted files, and re-pack it. The tools will take care of updating the CRC, so that the above tests will all pass. Not a path a complete newbie can follow, but many people can do that.
We will run into several more issues we need to fix in specific modules (ie. in this specific case we need to change header of Ambarella firmware from "FC300S" to "FC300X"), but this brings us relatively close to bricking the drone with wrong firmware. Being quadruple malicious is enough.
Now, was that easy path to follow? Is it possible to "accidently" write wrong firmware? You decide.
Last edited: