BLU G35 (Unisoc SC9863A) bootloader unlock — kit via the publicly documented CVE-2022
BLU G35 (Unisoc SC9863A) bootloader unlock — kit via the publicly documented CVE-2022
14-10-2026, 03:38 AM
BLU G35 (SC9863A) bootloader unlock — a self-contained Linux kit, publicly documented CVE-2022-38694 method
- Bootloader unlock via the Unisoc BootROM download-mode method published as CVE-2022-38694 — a publicly documented Unisoc signature-verification flaw, no unpublished material involved.
- Insurance gates everything: three complete, cross-verified firmware backups are taken BEFORE anything writes to the phone, and the insurance step cannot be skipped.
- Root via a gated Magisk init_boot writer; the boot chain stays stock except for two byte-verified patches.
- Every write is followed by a hash-verified read-back; a failed read-back halts the kit loudly.
- Rollback to full box state (stock + relock + wipe) is field-proven.
- The BootROM itself cannot be damaged by software.
Get it — and verify your copy before running anything
The kit carries its own proof: it re-derives every patched byte against the firmware on YOUR phone and refuses to bless a wrong or tampered copy.
https://github.com/mpse-engineering/BLU_G35
git clone ... blug35_unlock_kit
./verify.sh
Expect the final line: verify: ALL CHECKS PASS — this copy is stamped .verified
Requirements
- All phases run on Linux.
- Your firmware must be the exact BLU G35 supported build — the kit fingerprints it (hard-fail by design on anything else; that is the kit working as intended).
- Work inside the guide's workspace + follow 00_GUIDE.md chapters in order.
Evidence behind the claims
- Field-tested on real BLU G35 hardware across three full cycles (unlock, root, rollback to stock+relock+wipe) — each cycle recorded in the project's own decision log.
- No trust required upfront: ./verify.sh runs the complete choreography offline (13/13 scenarios) and re-derives every one of the 28 patched bytes against your own device — before any phone is connected.
- Rollback was exercised for real: the same kit path that returns a phone to full box state was run on the test device, not hypothesized.
Support knows one address
This post is a signpost, not a support desk. All help happens at the repo: README there → pinned issue → report template → your issue, with the raw logs/<script>.log files attached. When it works, please report back with ./make_report.sh — that report is what gives the next person confidence.
Provenance of record
tag 2026.10.13-2334Z · commit 4dc0f749b8acbdef4e2869498a616f116c3ca9eb — head of the repo IS the release; mirrors, re-zips, and chat-drop tarballs are not official.
14-10-2026, 03:51 AM
- Bootloader unlock via the Unisoc BootROM download-mode method published as CVE-2022-38694 — a publicly documented Unisoc signature-verification flaw, no unpublished material involved.
- Insurance gates everything: three complete, cross-verified firmware backups are taken BEFORE anything writes to the phone, and the insurance step cannot be skipped.
- Root via a gated Magisk init_boot writer; the boot chain stays stock except for two byte-verified patches.
- Every write is followed by a hash-verified read-back; a failed read-back halts the kit loudly.
- Rollback to full box state (stock + relock + wipe) is field-proven.
- The BootROM itself cannot be damaged by software.
Get it — and verify your copy before running anything
The kit carries its own proof: it re-derives every patched byte against the firmware on YOUR phone and refuses to bless a wrong or tampered copy.
https://github.com/mpse-engineering/BLU_G35
git clone ... blug35_unlock_kit
./verify.sh
Expect the final line: verify: ALL CHECKS PASS — this copy is stamped .verified
Requirements
- All phases run on Linux.
- Your firmware must be the exact BLU G35 supported build — the kit fingerprints it (hard-fail by design on anything else; that is the kit working as intended).
- Work inside the guide's workspace + follow 00_GUIDE.md chapters in order.
Evidence behind the claims
- Field-tested on real BLU G35 hardware across three full cycles (unlock, root, rollback to stock+relock+wipe) — each cycle recorded in the project's own decision log.
- No trust required upfront: ./verify.sh runs the complete choreography offline (13/13 scenarios) and re-derives every one of the 28 patched bytes against your own device — before any phone is connected.
- Rollback was exercised for real: the same kit path that returns a phone to full box state was run on the test device, not hypothesized.
Support knows one address
This post is a signpost, not a support desk. All help happens at the repo: README there → pinned issue → report template → your issue, with the raw logs/<script>.log files attached. When it works, please report back with ./make_report.sh — that report is what gives the next person confidence.
Provenance of record
tag 2026.10.13-2334Z · commit 4dc0f749b8acbdef4e2869498a616f116c3ca9eb — head of the repo IS the release; mirrors, re-zips, and chat-drop tarballs are not official.
Users browsing this thread:
1 Guest(s)
1 Guest(s)
Users browsing this thread:
1 Guest(s)
1 Guest(s)