bootloader-unlock-wall-of-shame: a documented list of who lets you unlock your phone

What the wall of shame actually is, and who it is for

This is a documentation repository. There is no library, no CLI and no build step. The README opens by saying it keeps track of companies that "care about your data", and the stated motivation is a pattern: vendors that block or strictly limit bootloader unlocking on hardware the buyer owns. The author argues the precedent matters even for people who never unlock, because the same controls have already been aimed at sideloading, and asks what gets restricted next.

The audience is narrow but real. Someone choosing a phone for LineageOS or GrapheneOS wants to know before purchase whether the bootloader can be unlocked at all. A repair technician or a hobbyist with a drawer of old handsets wants the workaround, not the policy. A writer or advocate wants a citable list. The repository serves all three because it splits the answer into per-brand pages under brands/ and a separate carriers/ directory.

The framing is opinionated, and that is the point. The tiers are named Avoid at all costs, Just terrible, Proceed with caution and "Safe for now" with a trollface. That is a judgement about vendor behaviour, not a neutral compatibility table, and reading it as a compatibility table will mislead you.

How the vendor tiers are structured

The list is a four-level classification, and the level tells you what kind of obstacle you face rather than how bad the company is in general.

Avoid at all costs covers manufacturers where unlocking is described as completely impossible without a workaround. The README names Alcatel, Amazon, Apple, Asus, Cat, Coolpad, Doogee, Energizer, Huawei, Meizu, Panasonic, Samsung, Sharp, TCL/BlackBerry, Vivo/IQOO, Vsmart and Windows phones. Just terrible covers vendors that allow unlocking only under conditions such as region, model or SoC, or that require a sacrifice: Hisense, HMD/Nokia, Honor, HTC, LG, Motorola/Lenovo/NEC, OPPO/Realme, Oukitel and Xiaomi/Redmi/POCO. Proceed with caution covers vendors that require an internet connection or a waiting period: Fairphone, Google/Nexus, Infinix, itel, OnePlus, Sony and Tecno. "Safe for now" lists Blackview, Cubot, Micromax, Microsoft, Nothing, Shift, Teclast, Teracube, TP-Link/Neffos, Ulefone, Umidigi and Volla.

The tier boundary that matters most is the third one. An internet connection or a waiting period means the unlock is granted by a server, so the vendor can revoke it, rate-limit it or shut the service down. The repository's own caution block states the principle directly: do not trust a company unless the unlock process is 100 percent offline. That sentence is the whole thesis, and it is why Google and OnePlus sit below Xiaomi despite being friendlier in practice.

Carrier-locked devices get their own page rather than a tier, because the lock comes from the carrier contract, not the OEM. The README notes these are common in North America and that many devices stay locked even after the carrier lock is lifted.

Reading a brand page: Huawei, Vivo/IQOO and the SoC routes

The front page is an index. The substance lives in brands/<name>/README.md, and the useful pattern is that a brand page pairs the vendor's official position with a hardware-level workaround when one exists.

For Huawei the README points at Kirin SoCs. Kirin 620, 650, 655, 658, 659, 925, 935, 950 and 960 are listed as unlockable using test points and PotatoNV, with the instruction to read that project's README. That is a hardware procedure requiring the device to be opened, not a command you type.

For MediaTek devices the route is mtkclient, with a fork of the old version linked as an alternative, or Penumbra. The README adds that OPPO and Realme MediaTek devices may need lkpatcher to reach fastboot, and links a web version of that tool. It also notes a second path for OPPO MediaTek devices when the SECCFG modification fails: writing a modified boot1 preloader, again through mtkclient, using the oppo-mtk-fastboot-unlock project.

Qualcomm gets a longer treatment. The README describes a vulnerability on Snapdragon 8 Elite Gen 5 and Snapdragon 8 Elite in which the boot process did not perform signature verification for the Generic Bootloader, so write access to the efisp partition allowed arbitrary code execution. It states this was patched in February/March 2026. The vulnerability is described as universal to the platform but requiring device or OEM-specific tricks to obtain root and write the GBL, with some documented for Xiaomi devices. Older Qualcomm hardware is pointed at an Aleph Research write-up on EDL from 2018.

Note what this section is and is not. It is a set of pointers to other projects, each with its own prerequisites and risk. The wall of shame does not verify them.

Cloning the list and finding the page for your phone

There is nothing to install. The repository is a set of Markdown files, and the README lists three mirrors: GitHub, Codeberg and tangled. Issues, pull requests and discussions on Codeberg and tangled are explicitly not monitored, and the README asks that those go to GitHub instead. So the practical setup is taking a copy of the GitHub repository.

Clone it and confirm the layout described in the README:

git clone https://github.com/zenfyrdev/bootloader-unlock-wall-of-shame.git
cd bootloader-unlock-wall-of-shame
ls

You should see .github/, CONTRIBUTING.md, LICENSE, README.md, brands/, carriers/, misc/ and ru/. The ru/ directory holds the Russian translation the README links to.

To check a vendor before buying, open its page under brands/. The directory names are lowercase and do not always match the marketing name, so list the directory first and then the brand you care about. The README sends Vivo/IQOO readers to brands/vivo/README.md, for example.

If no directory exists for the phone you are considering, the repository has no page for it yet, and the front-page tier is all you get. The README also points to a carriers page for carrier-locked handsets, which is a separate directory from brands/.

Once you have a page open, treat it as a reading list rather than a verdict. Each one may link to an external tool, and the README's caution about offline unlocks applies to every one of them.

Where the repository stops being useful

The most obvious limitation is that it is a snapshot of vendor behaviour, and vendor behaviour changes. The README records that the Snapdragon 8 Elite GBL vulnerability was patched in February/March 2026, which is exactly the kind of event that invalidates a workaround page overnight. Nothing in the repository enforces that a page is re-checked after a patch. If you are reading a brand page months after its last edit, the exploit it describes may already be dead on a current firmware build.

Second, the tier names invite a category error. "Safe for now" is not a guarantee and the trollface signals that. A vendor in that tier has not blocked unlocking, which is a statement about the present, not a commitment. The README's own advice is to distrust every vendor whose unlock is not fully offline, which puts several vendors in the middle tiers in the same practical bucket as the ones above them.

Third, the workarounds are hardware procedures with real costs. Test points mean opening the device. Writing a preloader or a modified boot1 to a partition can brick a phone if the image is wrong, and the README does not document rollback for any of these methods. It also does not document warranty consequences, though unlocking a bootloader generally voids coverage. Nothing here tells you how to recover a device that fails mid-procedure.

Finally, the repository is not a support channel. The README directs questions to GitHub discussions and accepts pull requests with specific details, but it is a list, not a forum. If mtkclient fails on your handset, this project has no troubleshooting path for you.

Alternatives and the difference in approach

The closest alternative is the XDA Developers forums, and the difference is structural rather than a matter of coverage. XDA is organised around device subforums and threads, so the answer to a bootloader question is a conversation, often hundreds of posts long, with the current state buried somewhere in the middle. The wall of shame is organised around vendors and a fixed set of tiers, so the answer is a short page with a verdict at the top. XDA will tell you what worked for one person last week. This repository tells you what the maintainers currently believe about the vendor as a whole.

For the specific question of whether a device can run a custom OS with a locked bootloader, the README points to custom Android Verified Boot keys and to a list of supporting devices maintained in the avbroot issue tracker. That is a different axis from unlocking: it is about signing your own images rather than disabling verification. If your goal is a locked bootloader with a custom OS, the wall of shame is only the entry point.

For the workarounds themselves, the real alternatives are the upstream tools the README links: PotatoNV for Kirin, mtkclient and Penumbra for MediaTek, lkpatcher for OPPO and Realme fastboot access, and the Qualcomm EDL research. Those projects do the work. The wall of shame's contribution is telling you which of them applies to your chipset before you start.

Maintenance, licence and what to check before relying on it

The repository is not archived and the last push was on 2026-09-21, so the project is being updated. That says nothing about whether any individual brand page is current. With no releases and no versioning, there is no changelog to consult, and the only way to judge freshness is the file history of the page you care about.

The licence is recorded as NOASSERTION on GitHub, and the README displays a CC BY-NC-SA 4.0 badge linking to the LICENSE file. The non-commercial clause is the part that matters in practice: if you want to mirror this list inside a commercial product or a paid database, the licence as presented does not obviously permit it. Read the LICENSE file itself rather than the badge, and treat this as a pointer to the terms, not as legal advice.

The upgrade cost is human, not technical. There is nothing to rebuild, but every vendor firmware release can invalidate a page, and the README asks readers to submit specific details through pull requests or discussions. If you depend on this list, the maintenance burden falls on whoever notices the change first. CONTRIBUTING.md exists for that purpose. The mirror situation is worth noting too: the Codeberg and tangled copies exist, but the README states that issues and pull requests there are not monitored, so a correction sent to a mirror may never be seen.

Editorial conclusion

Read this repository before you buy an Android device you intend to flash, and read the specific brand page rather than the front-page tier. Do not treat it as an unlocking tool: it ships no code, no APK and no exploit, only links and notes. If you are on a carrier-locked handset, the carriers page is the relevant one. Verify two things first: whether the brand page describes an unlock path that is still offline, and whether the linked workaround repository is still being pushed to. The maintainers' own caution applies, that an unlock process which is not 100 percent offline should not be trusted.

Frequently asked questions

Official sources

1. Issues
2. README
3. zenfyrdev/bootloader-unlock-wall-of-shame on GitHub