qualcomm_gbl_exploit_poc: a GBL boot stage proof of concept

The mechanism, in the author's own sequence

The repository is a Qualcomm device boot chain proof of concept in C, and the README describes the chain in a short sequence of steps.

Qualcomm adds a GBL boot stage in its ABL because it wants to limit the OEM's ability. GBL is loaded as a UEFI application, and it is stored in the efisp partition. To use it you need to flash the efi file into that partition. Qualcomm uses its own verification instead of UEFI secure boot, but GBL is unsigned, so an unsigned UEFI application can be loaded. That way arbitrary code execution is achieved, and from there the lock state stored in RPMB can be overwritten, because ABL itself reads and writes devinfo through a special function, and before the milestone you can call that function to overwrite the lock state.

That is the whole chain, and the vulnerability is a single missing check: the verification path for GBL is not the one that would catch an unsigned payload.

The repository top level shows what was produced. There is VbRwStateApp.c, the source of the application, and VbRwStateApp.inf, its installation descriptor. There are two built EFI images, gbl_efi_unlock.efi and gbl_efi_relock.efi, which correspond to the two directions of the RPMB lock state change. And there is the README and the MIT licence.

The primary language is C, the last push to the main branch was on 2026-06-29, and there are no GitHub releases.

The warning, and why it is not boilerplate

The README carries a warning section that is short and unusually concrete, and it is worth reading before anything else in the repository.

It says this is just a POC, and asks the reader to be careful to use it. It notes there are some TEE issues. And it says the author will not be responsible for any corruption.

The corruption warning is not a generic legal disclaimer. The mechanism the project exploits writes to the lock state that the bootloader consults, and the lock state lives in RPMB, which is replay protected memory backed by the secure element. A write to that area done incorrectly does not fail loudly, it leaves a device that will not boot or that stays locked out, and recovering from that can mean a full reprogram of the storage.

The TEE comment is a separate issue. The Trusted Execution Environment is the isolated region where the secret keys and the signing operations live, and the author flags it without further explanation, which reads as a known weakness in the proof of concept rather than a settled detail.

The pairing of a lock and a relock binary is also the tell that this is a state-changing operation rather than a read. The two files are the two transitions, and the existence of a relock path implies the author expected people to move the device between the states.

The licence situation is worth noting too, since the MIT licence in a repository containing binaries that change the device lock state is a deliberate choice rather than an oversight.

A disclosure history, written out in full

The larger part of the README is a statement on the GBL vulnerability, and it reads as a dispute record rather than a technical note. Since it is the substance of the document, it is worth summarising faithfully.

The author says he discovered the GBL vulnerability around January 15 to 17, while unpacking the ABL, and that he did draw on Gus's idea that GBL is only signed by Google, but asks whether a single sentence like that justifies an accusation of plagiarism, noting that Gus mentioned it in a public group with no additional access restrictions. At the time he says he did not have time to implement it and put it off until February, with the delay because he was collaborating with others on it, and that one collaborator dropped out midway, so they stepped back. The collaborators, he says, had nothing to do with Littlenine or Mlgm, and there was no issue of borrowing ideas.

Around the end of February he mentioned the vulnerability in his own KT group, a group he runs, to stimulate discussion and encourage people to look into follow-up vulnerabilities. At that point Littlenine approached him proactively to work on it, and they agreed that neither would disclose anything to others.

Littlenine then forwarded the author's messages from the KT group to other people and accused him of plagiarism, which the author notes happened when he had not made anything public. Since he did not keep his word, the author says he had no choice but to release it in March, while acknowledging he misread the timing of the patch by a few days.

His conclusion is a demand that Littlenine and Mlgm remove content accusing him of being a thief, an acknowledgement that there may have been a subtle timing overlap between the findings, and the point that an accusation of theft without sufficient evidence is a potential infringement of his reputation rights. He also says he never attempted private communication with Sunf or Mlgm about the vulnerability, that all conversations were in public group chats, and that anyone wanting evidence can message him privately.

Why the boot stage exists, and what limiting the OEM means

The technical motivation is stated in one sentence and it is the part that generalises beyond this particular device.

Qualcomm adds a GBL boot stage in its ABL because it wants to limit the OEM's ability. That is a supplier trying to keep control of a stage of the boot chain on hardware that an original equipment manufacturer sells and supports, and the GBL stage is where that control is exercised.

Once a stage is a separate loadable image with its own verification story, it becomes the interesting part of the chain to attack, because it is a new decision point that a compromise has to pass through. If the stage is signed, an attacker needs a signing key. If the stage is unsigned, or if the verification that applies to it turns out to accept an unsigned payload, then the stage is not a barrier at all and it is just another piece of code the attacker gets to run early.

The README's own assessment is that the vulnerability itself isn't particularly significant. That is a fair judgement for a hardware boot chain, where the interesting question is usually not the impact of running arbitrary code in a privileged early stage, but whether the stage lets you change the trust decisions made later. Here it does, because the lock state is written through a function that is reachable before the milestone, and the lock state is what decides whether the device accepts signed or unsigned code afterwards.

So the shape of the finding is a trust boundary problem rather than a memory corruption problem, and it is worth reading as an example of how that class of bug is described and disclosed.

What the repository does not tell you

There is a reasonable amount the README does not cover, and knowing where the gaps are is part of evaluating a proof of concept.

There is no build instructions. The repository has a VbRwStateApp.c, a VbRwStateApp.inf and the two EFI binaries, but the README does not describe how to rebuild the application, which toolchain produces the UEFI image or what SDK the inf file targets.

There is no description of the affected device models or the firmware versions in scope, beyond the mention of the efisp partition, the RPMB and the devinfo read and write path in ABL.

And there is no discussion of the TEE issues beyond the single line in the warning.

That is a normal shape for a proof of concept released after a patch has shipped, and the README says as much: the author heard the patch had been applied, and released accordingly. The document is a record of what was found and how the disclosure unfolded, with the code included as the artefact.

The evaluation path for the repository is therefore the README itself, read as a write-up, with the code as the supporting evidence. Anyone trying to reproduce it would need to fill the gaps themselves, and anyone trying to defend against a similar issue would take the sequence of steps as the specification of what to check.

Editorial conclusion

Adopt this repository as a reference when you are studying how a bootloader trust boundary is established, because the write-up names the specific mechanism, the partition involved and the missing signature check, which is the kind of detail that is usually missing from an advisory. Do not treat the included EFI binaries as a tool you flash onto a device you care about, since the README warns of corruption and of TEE issues, and the author says outright that this is just a proof of concept. Before you reproduce any of it, read the disclosure statement in the README as well as the code, because the history of how the finding was coordinated and then released is part of what the repository documents.

Frequently asked questions

Official sources

1. Issues
2. kasnria001/qualcomm_gbl_exploit_poc on GitHub
3. License: MIT
4. README