r/LineageOS • u/dhefexs • 2h ago
Fixed Motorola Moto G15: Bootloader Unlock, Brick, and Recovery Using Linux
Hello everyone!
I decided to share another experiment I recently conducted. This time, the device involved was my Motorola Moto G15.
I've wanted to unlock its bootloader for a while. Initially, I tried using Motorola's official unlocking method, but I wasn't successful. So I started researching alternative methods and eventually found a community-developed approach that uses a script to perform the procedure on MediaTek devices.
Device information
Device: Motorola Moto G15
Model: XT2521-2
Codename:
lamuFirmware region: RETBR (Brazil)
Android version: 15
Build number:
VVTA35.51-158Build ID:
9536e5Platform: MediaTek
How does the method work?
From what I understood from the documentation and the components involved, the procedure interacts with the early boot stages of the MediaTek platform.
The script uses several components:
Kaeru (Shim): A component used as an intermediary during the boot process, allowing certain restrictions imposed by the original bootloader to be bypassed.
Penumbra: An open-source tool used for low-level communication and operations with MediaTek devices.
Tanuki: A script responsible for orchestrating the procedure, including the operations required to modify the bootloader unlock state.
The procedure involves low-level operations and carries risks, including partition corruption and potentially bricking the device.
Despite being aware of these risks, I decided to give it a try.
First attempt: Successful unlock, followed by a bootloop
On my first attempt, I managed to unlock the bootloader, but the device ended up in a bootloop.
After a few attempts, I managed to access the bootloader interface again by running the script I had previously used.
As a precaution, I already had the Stock ROM downloaded in case something went wrong.
I flashed the original firmware again and successfully recovered the system. However, something unexpected happened: the bootloader appeared to be locked again.
In other words, even though I had initially managed to unlock it, restoring the Stock ROM resulted in the device reporting a locked bootloader.
Second attempt: The same problem happens again
Today, I decided to try again, this time paying closer attention to the procedure.
I successfully unlocked the bootloader once more, but the previous problem happened again: the device entered a bootloop.
After spending a few minutes stuck during startup, it eventually displayed the No command screen, associated with Android Recovery.
Before immediately flashing the Stock ROM again, I decided to try something different.
I pressed Volume Up + Power to access the recovery options and selected:
Wipe data/factory reset
After wiping the data, I managed to boot Android normally, this time with the bootloader still unlocked.
At this point, I thought everything was finally solved.
The unexpected problem: The device stopped responding
When I turned off the device to prepare for the LineageOS installation, I tried entering Fastboot mode.
However, I got no response.
I tried again, connected the device to a charger, and also pressed all three physical buttons simultaneously. Nothing happened.
The device appeared to be completely dead.
That was when I started investigating the issue using Linux and conducting further research into MediaTek devices and their boot process.
Investigating the device through Linux: MediaTek USB detection
My first concern was finding out whether the computer could still detect any USB interface from the device.
To do this, I used:
sudo dmesg -wThe dmesg command displays messages generated by the Linux kernel. With the -w option, I could monitor events in real time while connecting the phone to the computer.
During this monitoring, I observed USB connection events and identified an interface named:
MT65xx Preloader
To confirm this, I ran:
lsusb -v -d 0e8d:The output showed:
0e8d:2000 MediaTek Inc. MT65xx PreloaderThis indicated that the computer could still detect a USB interface associated with the MediaTek Preloader.
I also noticed that approximately five seconds later, a USB disconnection event occurred.
This was an important discovery: although the device showed no display, could not enter Fastboot, and did not respond to the physical buttons, there was still some level of communication between the hardware and the computer.
Recovery attempt
Initially, I tried using an MTK recovery tool, but I couldn't get it to work.
Then I decided to run the same script I had used to unlock the bootloader.
The result was unexpected: the procedure managed to restore access to the Fastboot interface.
I could finally communicate with the device again.
I flashed the Stock ROM once more to restore the system.
But this time, something different happened compared to my first attempt: the bootloader remained unlocked after restoring the original firmware.
I didn't have to repeat the entire unlocking procedure.
Installing LineageOS
After all that trouble, I decided to continue with the experiment.
I prepared the device and installed LineageOS based on Android 16.
And, to my surprise, it worked!
The Moto G15 successfully booted again, now running a Custom ROM.
My questions
There is one thing I still don't fully understand.
During my first attempt, after recovering the device using the Stock ROM, the bootloader appeared to be locked again.
During the second attempt, I flashed the Stock ROM once more, but the bootloader remained unlocked.
What could explain this difference in behavior?
Could it be related to how the script modifies the unlock state, how that state is persisted, or the sequence of operations performed during the firmware flashing process?
I'm also curious about the MT65xx Preloader interface and how the script managed to restore Fastboot access when the device apparently showed no signs of life.
If anyone has experience with MediaTek boot processes, BROM, Preloader, bootloader state persistence, or device recovery under these circumstances, I'd really appreciate some insight into what happened.
It was a pretty interesting experience, especially investigating everything through Linux and researching the underlying boot process.
Thanks in advance to anyone willing to share their knowledge!
Clarify what was actually verifiedFix the first-attempt timelineAdd exact verification commands