Looking for Full Firmware / EDL Image – Boox Tab Ultra (Non-C)

[Slifer]

Hi again,

as mentioned in a previous post, I’m still trying to recover my soft-bricked Boox Tab Ultra (original B/W version, not C or Pro). Recovery and ADB work, but sideloading hasn’t resolved the boot issues.

I’m now looking for a full firmware image or EDL-compatible files for this specific model. If anyone has access to such files or knows where they might be shared, I’d really appreciate your help.

Thanks in advance!

[Renate]

The Tab Ultra has a full update here:

Model:  TabUltra (English)
Finger: Onyx/TabUltra/TabUltra:11/2025-04-02_12-29_v4.0-rel_6d15a71551/49344:user/release-keys
Link:   http://firmware-us.boox.com/266e3dc6e455a4bcbf99f8f7a7684349/update.upx
Size:   1,862,304,832
MD5:    266e3dc6e455a4bcbf99f8f7a7684349

There is also the 4.0.2 incremental update, but you should worry about that afterwards.

I've not got specific info about the processor on the TabUltra, but the Firehose loader for the Go6 would be a good starting point.
See: http://www.temblast.com/ref/onyxldr.htm
Please report what the HWID is. (It's not secret or specific to your unit.)

[Slifer]

Originally Posted by Renate

The Tab Ultra has a full update here:

Model:  TabUltra (English)
Finger: Onyx/TabUltra/TabUltra:11/2025-04-02_12-29_v4.0-rel_6d15a71551/49344:user/release-keys
Link:   http://firmware-us.boox.com/266e3dc6e455a4bcbf99f8f7a7684349/update.upx
Size:   1,862,304,832
MD5:    266e3dc6e455a4bcbf99f8f7a7684349

There is also the 4.0.2 incremental update, but you should worry about that afterwards.

I've not got specific info about the processor on the TabUltra, but the Firehose loader for the Go6 would be a good starting point.
See: http://www.temblast.com/ref/onyxldr.htm
Please report what the HWID is. (It's not secret or specific to your unit.)

Hi again,

Sorry for the late reply – I wanted to take some time before continuing and didn't get back as quickly as I should have.

I tried working with the poke6.bin Firehose loader. The device is detected successfully in EDL mode, and I was able to run commands like nop, w boot, and r boot without issues. However, printgpt and gpt don’t return anything, and I can’t retrieve the HWID either – it’s not shown in any command output.

I also tried peekhex 0x0 0x400 but couldn’t identify an obvious HWID string.

Any idea how I can proceed from here? Would a different loader help?

[Renate]

Show your work. I don't know what's going on.
How can you not get the HWID.
Use my EDL client, at least I know that.

[mariocord]

Hi,

I have an Onyx Boox Tab Ultra (non-C, purchased Nov 2022, Snapdragon 662) that got bricked back in January during an OTA firmware update — power/update failed mid-way and it's been stuck at the ONYX boot logo ever since, no matter how I try to reboot it.

It does NOT show up in normal fastboot or adb devices. The only way I can get it to respond at all is using a test-point short cable with a button, which puts it into EDL (Sahara) mode.

I tried various recovery/flashing attempts back in January (with some help from ChatGPT) without success, but at the time I was on Windows. Since then I've migrated my PC to Ubuntu (around April), so I no longer have my old Windows setup or any of the tools/files I used back then.

I set up bkerler's edl.py on Ubuntu and ran `edl printgpt`. Here's what it reports:

```
HWID: 0x001740e100000000 (MSM_ID:0x001740e1, OEM_ID:0x0000, MODEL_ID:0x0000)
CPU detected: "kamorta_IoT_APQ"
PK_HASH: 0xd40eee56f3194665574109a39267724ae7944134cd53cb76 7e293d3c40497955bc8a4519ff992b031fadc6355015ac87
Serial: 0xdb19616f
```

None of the auto-detected generic loaders (quectel mdm9x05, SDM855LA, sdm662 factory, sc8180x factory) work — uploading any of them fails with "Error: Invalid data size received in image header".

Since the CPU string comes back as "kamorta_IoT_APQ", I'm guessing this needs the specific Onyx/kamorta firehose loader (signed for this exact PK_HASH) rather than a generic Qualcomm one, which Onyx doesn't publish publicly.

Does anyone have the correct firehose loader (and ideally the full rawprogram/patch images) for the Tab Ultra (non-C, kamorta platform)? Happy to run any further diagnostics needed. Thanks so much in advance!

[Renate]

As it says in https://www.temblast.com/ref/onyxldr.htm, the Firehose loader is:
https://github.com/bkerler/Loaders/b...dr_patched.elf

The latest update is:

Model:  TabUltra (English)
Finger: Onyx/TabUltra/TabUltra:11/2026-06-30_11-25_4.2-rel_0630_b7cf3517a3/51518:user/release-keys
Link:   http://firmware-us.boox.com/6b7ec9b9bfc68ec1f871ab0c227f0c24/update.upx
Size:   1,866,926,032
MD5:    6b7ec9b9bfc68ec1f871ab0c227f0c24

[mariocord]

Originally Posted by Renate

As it says in https://www.temblast.com/ref/onyxldr.htm, the Firehose loader is:
https://github.com/bkerler/Loaders/b...dr_patched.elf

The latest update is:

Model:  TabUltra (English)
Finger: Onyx/TabUltra/TabUltra:11/2026-06-30_11-25_4.2-rel_0630_b7cf3517a3/51518:user/release-keys
Link:   http://firmware-us.boox.com/6b7ec9b9bfc68ec1f871ab0c227f0c24/update.upx
Size:   1,866,926,032
MD5:    6b7ec9b9bfc68ec1f871ab0c227f0c24

Update: huge thanks, the loader worked perfectly! Got full Firehose access, dumped the GPT across all 6 LUNs, verified the boot chain (xbl_b, abl_b, boot_b, dtbo_b, vbmeta_b, modem_b, vbmeta_system_b, recovery_b) by re-flashing them from the official firmware you linked and confirming with MD5 that writes landed correctly. Active slot is confirmed as 'b' throughout.

Device still hangs at the boot logo after all that, so I dumped the 'super' partition (LUN 0, 4GB) to inspect it, and found the root cause: the logical partition metadata is corrupt.

```
AssertionError: Logical partition metadata has invalid geometry magic signature.
```

(using liblp/lpunpack in Python to parse it)

This lines up perfectly with the January OTA failing mid-flash while writing the dynamic partitions (system/vendor/product/system_ext), leaving 'super' with an invalid/corrupted metadata header. The kernel boots fine (hence the logo showing), but init can never mount the dynamic partitions, so it hangs on the splash forever.

I have all four raw partition images (system.img, vendor.img, product.img, system_ext.img) extracted from the full OTA payload.bin you linked earlier, ready to rebuild 'super' with lpmake.

Before I start guessing at lpmake parameters (metadata size, partition group name, slot count) and risk multiple write cycles, does anyone know the exact lpmake invocation used for the Tab Ultra (kamorta platform)? Specifically the dynamic partition group name (is it 'qti_dynamic_partitions' or something else for this platform?) and metadata-size/metadata-slots values. The 'super' partition itself is exactly 0x100000000 bytes (4GiB) per the GPT.

Thanks again for all the help so far — this has been a great troubleshooting session.

[mariocord]

hi. Still stuck on the dynamic partition group name for rebuilding super — anyone know if it's 'qti_dynamic_partitions' for the Kamorta/TabUltra platform? Happy to share more diagnostic output if useful

[Renate]

super has a lot of details in it.
I always prefer to modify vs. build it from scratch.

I'm guessing that you flashed some random partition to super.
It's not that super is corrupted, it's not even super now.
The geometry magic is the first thing that the system looks for and you don't have it.

See if you can get a full super image from somewhere.
Or else get the first 1 MB of one which is the metadata.

[mariocord]

Thanks for the pointer! You were right about the original corruption — I dumped the original 'super' before touching anything, and 'file' identified it as a plain ext2 filesystem, not dynamic partition data at all. So indeed something (probably from an earlier attempt with another AI's guidance, before I found this thread) wrote a raw filesystem image directly onto the physical 'super' partition, wiping the geometry header entirely.

I couldn't find a full super image anywhere, so I rebuilt one with lpmake instead, using the exact group name 'qti_dynamic_partitions' (confirmed directly from strings inside payload.bin's own manifest, not guessed) with the _b slot suffix, --virtual-ab flag, metadata-size 65536, metadata-slots 2, containing system_b/vendor_b/product_b/system_ext_b sized to match the payload.bin images exactly.

I wrote this to the device's 'super' partition via EDL, then read it back to confirm: it matches byte-for-byte what I wrote, and lpdump (from Rprop's aosp15 partition tools) parses the metadata cleanly — valid geometry magic, correct partition table, no errors.

Device still hangs at the boot logo exactly as before, no change at all.

Given the metadata now parses fine under current-gen liblp tooling but the device's firehose loader itself is dated Nov 2020 (Android 11 era), could there be a metadata version mismatch — i.e. is it possible this device's own parser expects an older/different liblp version than the 10.2 that current lpmake produces? Or is there some other structural detail (block size, alignment, super-partition naming in the block device table, etc.) that could cause a device-side parser to still reject a structurally 'valid' image? Happy to share the full lpdump output or try alternate lpmake flags if you have something specific in mind.

[Renate]

You sure that you have all the versions, flags, partitions, extents, groups, devices, block sizes and alignments correct?

Maybe someone with one of these devices can pull the first MB of super for you.

[mariocord]

Fair point — I can't be fully certain every parameter (block size, alignment, exact offsets, slot count nuances) matches the original, only that the structure parses cleanly with current liblp tooling. That's not the same as byte-correct.

Getting a real super from a working Tab Ultra (non-C) sounds like the most reliable path. If anyone in this thread or elsewhere in the community has a working, rooted (or ADB-accessible) Tab Ultra, would they be willing to pull just the first 1MB (metadata only, no personal data)?

```
adb shell su -c "dd if=/dev/block/by-name/super of=/sdcard/super_first1MB.bin bs=1M count=1"
adb pull /sdcard/super_first1MB.bin
```

Happy to compare it against my rebuilt version to see exactly what differs. If no one here has one, I'll also ask around r/onyxboox and the Boox Telegram group. Thanks again for sticking with this.