#993 Bricked moxee investigation

untitaker2026-04-21, edited 2026-05-10OpenGeneral

I’ve taken a look at a bricked Moxee sent to me (#865).

First, the state of the Moxee I tested: RNDIS works, no working DHCP server, when I use static IPs I can ping 192.168.1.1 but all TCP ports are closed (connection refused), no adb.

It seems that Moxee exposes EDL when one:

holds the reset button while the device is powered. The Moxee says “resetting”, then the display goes dark.
once the screen goes dark, hold power + reset. The screen doesn’t turn on at all, but you will see it in dmesg -w when plugged into a PC:

Apr 21 15:04:12 denkpad kernel: usb 2-4.4.1.4: New USB device found, idVendor=05c6, idProduct=9008, bcdDevice= 0.00
Apr 21 15:04:12 denkpad kernel: usb 2-4.4.1.4: Product: QHSUSB__BULK
Apr 21 15:04:12 denkpad kernel: usb 2-4.4.1.4: Manufacturer: Qualcomm CDMA Technologies MSM
Apr 21 15:04:12 denkpad kernel: qcserial 2-4.4.1.4:1.0: Qualcomm USB modem converter detected
Apr 21 15:04:12 denkpad kernel: usb 2-4.4.1.4: Qualcomm USB modem converter now attached to ttyUSB0

$ lsusb
  Bus 002 Device 063: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode)

With edl.py the Sahara handshake works, but then I get stuck. This is the output of edl printgpt:

Capstone library is missing (optional).
Keystone library is missing (optional).
Qualcomm Sahara / Firehose Client V3.62 (c) B.Kerler 2018-2025.
main - Trying with no loader given ...
main - Waiting for the device
main - Device detected :)
sahara - Protocol version: 2, Version supported: 1
main - Mode detected: sahara
sahara -
Version 0x2
------------------------
HWID:              0x0004a0e10158779a (MSM_ID:0x0004a0e1,OEM_ID:0x0158,MODEL_ID:0x779a)
CPU detected:      "MDM9607"
PK_HASH:           0x952f545de71ce37daa0ef295a67223d74a968f6de96ca04be352667337260df8
Serial:            0x3c5fd831

sahara
sahara - [LIB]: Couldn't find a loader for given hwid and pkhash (0004a0e10158779a_952f545de71ce37d_[FHPRG/ENPRG].bin) :(

Then the command just hangs, and in dmesg I see that the device is kind of gone (lsusb still shows it):

[95199.893766] qcserial ttyUSB0: Qualcomm USB modem converter now disconnected from ttyUSB0
[95199.893797] qcserial 2-4.4.1.4:1.0: device disconnected

I’ve taken apart an Orbic device and haven’t found anything that resembles an UART point, so I would assume there’s nothing on Moxee as well. I’m not very familiar with this level of abstraction, so somebody actually experienced in hardware hacking may try.

Comments (4)

untitaker2026-04-22

Tried qc_boot (https://github.com/platform-system-interface/qc_boot). Held power + reset to get into EDL, then:

$ sudo ./target/release/qc_boot info
[2026-04-22T09:07:47Z INFO  qc_boot::protocol] Found Qualcomm CDMA Technologies MSM QHSUSB__BULK
Hardware ID: 0004a0e1 (unknown)
Serial number: [31, d8, 5f, 3c, 00, 00, 00, 00]
OEM PK hashes:
  [95, 2f, 54, 5d, e7, 1c, e3, 7d, aa, 0e, f2, 95, a6, 72, 23, d7, 4a, 96, 8f, 6d, e9, 6c, a0, 4b, e3, 52, 66, 73, 37, 26, 0d, f8]
  [95, 2f, 54, 5d, e7, 1c, e3, 7d, aa, 0e, f2, 95, a6, 72, 23, d7, 4a, 96, 8f, 6d, e9, 6c, a0, 4b, e3, 52, 66, 73, 37, 26, 0d, f8]
  [95, 2f, 54, 5d, e7, 1c, e3, 7d, aa, 0e, f2, 95, a6, 72, 23, d7, 4a, 96, 8f, 6d, e9, 6c, a0, 4b, e3, 52, 66, 73, 37, 26, 0d, f8]

Running this tool again hangs briefly after the first line, then panics:

[2026-04-22T09:08:30Z INFO  qc_boot::protocol] Found Qualcomm CDMA Technologies MSM QHSUSB__BULK

thread 'main' (674716) panicked at src/protocol.rs:245:5:
assertion `left == right` failed
  left: 0
 right: 1
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Then the device needs power cycling.

qc_boot has other subcommands but they don’t seem to be implemented yet.

orangecms2026-04-22

yea the EDL protocol is unfortunately stateful and changed over time, so I only implemented as much - any insight would be highly welcome!

I just remembered that Qualcomm themselves started a new tool, too: https://github.com/qualcomm/qdlrs/

untitaker2026-04-23, edited 2026-04-23

FTR I have also tried the linked official tool, and it didn’t work either. All image uploads timeout. Stuck here on getting a working firehose programmer for the moxee.

programmers I have tried

Each test was run on a freshly-booted device, and the device was reest in between. All hung silently after image transfer.

nprg9x07p.bin — bkerler/Loaders/qualcomm/patched/mdm9x07/
```
edl --loader=nprg9x07p.bin --memory=nand printgpt
```
org/sim7600/NPRG9x07.mbn — bkerler/Loaders/qualcomm/patched/mdm9x07/
```
edl --loader=org/sim7600/NPRG9x07.mbn --memory=nand printgpt
```

update/firehose/prog_nand_firehose_9x07.mbn — Biktorgj/quectel_eg25_recovery

edl --loader=update/firehose/prog_nand_firehose_9x07.mbn --memory=nand printgpt

update/NPRG9x07.mbn — Biktorgj/quectel_eg25_recovery

edl --loader=update/NPRG9x07.mbn --memory=nand printgpt

update/ENPRG9x07.mbn — Biktorgj/quectel_eg25_recovery

edl --loader=update/ENPRG9x07.mbn --memory=nand printgpt

update/firehose/prog_nand_firehose_9x07.mbn — Biktorgj/quectel_eg25_recovery (tool-independence retry)
```
qdl-rs --loader-path update/firehose/prog_nand_firehose_9x07.mbn --storage-type nand nop
```

untitaker2026-05-10, edited 2026-05-10

I’ve disassembled the device and am able to connect to UART.

littlekernel UART

Rotated like in the picture, let’s label the contacts:

  A . B
  C . D . E
  . . F . G

F is TX, G is RX (probably), E is GND. I used a raspberry pico, this firmware, and a few resistors to connect:

Voltage is 1.8V on the moxee and 3.3V on the pico, hence the resistor stuff. Without resistors (connecting G directly), the moxee crashes.
1k means 1 kohm.

But in the end only reading logs worked anyway, and the console was non-responsive to any input. Reading logs you can do without getting resistors anyway, just don’t connect TX. So technically I can’t be sure that the resistor stuff ever really worked properly.

Here are the logs: moxee-boot-uart.txt – note that after linux has booted, there are no logs at all anymore no matter how much I interact with the device.

So maybe there’s a second UART somewhere:

Where is the goddamn linux console?

On the other side of the PCB, opposite this UART pad cluster, there is a soldered-on heatshield that doesn’t come off. I tried to heat up the shield using a soldering iron, and pry it off, but heating up just the edges melts the PCB.

Anyway, even if I’m able to get under that heatshield it doesn’t seem like a viable path for an unbrick procedure. I’d have tolerated a path that “only” required disassembling the device and holding some wires onto the UART above. But soldering off a heatshield is too much.