P3 Firmware You can't flash wrong firmware on DJI products

[quaddamage]

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:

    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:

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.

 

[mj2019]

hello again am going from thread to thread to finish my new p3p fix , now i bought this p3p a month ago and as every thing in 2020 it turned out bricked and the transmitter was bricked too ( offcorse when i bought it the the seller told me it only needs upgrade! and the price was very good i checked the battery life to see if the quad was heavily used it was 100% it also showed on another working p3p that it has only 10 recharges)so i thought it would be a 20 min update but it turned a challenging month of work, so far i flashed the communication board on transmitter and i tested it on a freinds app it shows firmware 1.2.6 after 2 weeks strugle i managed to flash the gimbal board and just ran a fw update to 1.11.0020 from dji site after the fix the firmware update gave the sounds it only took 5min (i dont know if earlier tries before fix that took 15min but failed have done part of up date and after fix the rest was done in 5 min) now a ddd sound and green gimbal led and this is the text file mentioning success and this is the hidden log file , but upon restarting the p3p after update it is still giving beepbeep allet sound for a min or so. i want your advice mr quaddamage how to proceed??
the first file is the hidden log before i flashed the gimbal board, the second text is the hidden file after the gimbal board flashing, the third is the txt file i got after the last firmware update that seemed successful