Request: DJI RC 2 / RC331 Firehose programmer — QCS5430, eMMC, PK_HASH 4d3b79c7

Open
#166 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
embedded-iot

Research direction

Start by reading the Loaders repository’s device and programmer support entry points; the issue does not name specific files or tests. The requested outcome is a legitimately shareable RC331-compatible EDL programmer or public service-package source, verified with its SHA256, supported hardware IDs, and a successful Sahara/Firehose log. The work depends on finding and validating hardware-specific firmware.

Written by the indexing model from the issue text.

Description

I am recovering my own DJI RC 2 (RC331 / KATMAI-IDP), which stopped booting after an experimental system flash. Original stock partition backups are available. The controller responds to Sahara identification over USB 05c6:9008, but I do not have a verified compatible Firehose programmer.

Read from this controller:

  • HWID: 0020f0e101a80000
  • MSM ID: 0020f0e1
  • OEM ID: 01a8
  • Model ID: 0000
  • Platform: QCS5430 / Kodiak family
  • Storage: eMMC
  • OEM PK hash (SHA384):
4d3b79c7cd869227091b30af8d9b884a80f60aedece7a515300db391f8cd5a5da1def5a798e8f7f1d7fbb4a0c9dc496e

The outer DJI Root CA certificate in the saved original XBL hashes to the same value. Authentication-enable fuses have not been read, and no candidate loader has been uploaded, so I am not claiming an observed signature rejection.

Does anyone have a legitimately shareable RC331-compatible programmer, or a public service-package source containing one? A source URL, file SHA256, supported hardware IDs and successful Sahara/Firehose log would help verify it. I am looking for an actual EDL programmer rather than an OTA firmware .bin, Android rescue APK, or fastboot image.

Generic Xiaomi/Oplus/Samsung candidates inspected so far have different OEM roots; the published Action 5 Pro/RedMagic method targets a different processor. The aim is to read the live partition layout first and preserve calibration, RPMB and device-specific data before restoring stock.

Device serial numbers, account information and private backups are intentionally omitted. Thanks for any leads.

Dominant language
Python
Stars
555
Forks
154
PR merge metrics
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from bkerler/Loaders

All issues in bkerler/Loaders

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.