Honor X8B Kali nethunter

Open
#154 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
38/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
python
Domain
embedded-iot

Research direction

Start by tracing how the loader file is selected and how the Sahara session transitions to streaming or Firehose; the payload does not identify a source file or test. Reproduce with the Honor X8b, the supplied sm6225.bin loader, and the shown printgpt command, then compare the logged handshake with a known-working device. Done means establishing whether this is an incompatible/rejected loader or a protocol-detection defect and, if applicable, documenting or fixing the verified cause.

Written by the indexing model from the issue text.

Description

Device: Honor X8b (Snapdragon 680 / SM6225 "Bengal" platform)
HWID: 0x001b80e101a40003 (MSM_ID: 0x001b80e1, OEM_ID: 0x01a4, MODEL_ID: 0x0003)
PK_HASH: 1816101f1302cf634f7002490e6742134f5fcde05a7eaff5ba7029aa0e69f9521e921a171a2f60a67baef26b81ae61eb
Memory type: UFS

I tried using the sm6225.bin loader from this thread on my Honor X8b (same MSM_ID as the Onyx devices, different OEM_ID). Sahara handshake succeeds, but it seems to fall into the legacy "streaming" (HDLC) mode instead of Firehose, and then just times out repeatedly. No actual image transfer to the device seems to happen before this.

Command used:

python edl.py printgpt --loader=/home/koza/Downloads/sm6225.bin --memory=UFS --debugmode

Log:

Qualcomm Sahara / Firehose Client V3.62 (c) B.Kerler 2018-2025.
main - Using loader /home/koza/Downloads/sm6225.bin ...
main - Waiting for the device
main - Device detected :)
DeviceClass - [LIB]: TX:
DeviceClass - [LIB]: read:0x10
DeviceClass - [LIB]: RX:04000000100000000d00000001000000
main - Mode detected: sahara
DeviceClass - [LIB]: (streaming_client.py -> streaming.py -> hdlc.py: send_cmd_base -> send_unframed_buf)
DeviceClass - [LIB]: TX:11001200a0e30000c1e50140a0e31eff2fe14bd97e
DeviceClass - [LIB]: read:0x10
DeviceClass - [LIB]: RX:04000000100000000d00000001000000
DeviceClass - [LIB]: Timed out
DeviceClass - [LIB]: Timed out
[... repeats indefinitely ...]

I also tried renaming the file to .elf in case the extension affects loader-mode detection — same result.

Is this loader expected to work on non-Onyx devices with the same MSM_ID but a different OEM_ID/PK_HASH? Or is this device likely being rejected due to Secure Boot, as mentioned in the original post ("severe limitations... only work on devices without Secure Boot enabled")? Any pointers on whether this is a protocol-detection bug (streaming vs. Firehose) vs. an incompatible/rejected loader would be appreciated.
Pls help guys

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.