A warning about bootloader relocking

Search This thread

squid2

Recognized Developer
Mar 9, 2015
1,722
10,973
Ontario
Just a heads up to those who may attempt relocking an unlocked bootloader:

As you probably know, the new Moto E required you to enable bootloader unlocking in the Android developer options menu before you can run the fastboot oem unlock XXXXX command. Unlocking the bootloader wipes the frp partition. Wiping frp restores the default state of OEM unlock disabled. When you relock the bootloader, even if you are already running signed official firmware for your model, the phone will refuse to boot until you reflash the system image. For most models of the Moto E, official firmware has not leaked. Different carriers and regions have different CIDs, even among retail devices, so even signed builds that leak are incompatible across different carriers.

End result: If you are not careful when relocking your bootloader, there is a high risk of soft bricking your device. I made such a mistake today. I just got a new Telus Moto E today, unlocked the bootloader, then relocked it while leaving the software unchanged. Unlocking wiped userdata, disabling re-unlocking. Relocking prevented my phone from booting up till I flashed a signed image that I didn't have, and I could no longer re-unlock either. This soft bricked my phone. Stock firmware signed for my model and region has not leaked. I was able to fix my phone through other means (not available), but for most of you on XDA, your phone would be effectively bricked if you did what I did.

Morals of the story:
  • Don't relock unless you have a reason to
  • Make sure you re-enable bootloader unlocking in Android before re-locking
  • Make sure you have a fastboot flashable official stock image signed to work with your carrier and region before re-locking the bootloader. Currently running the official firmware is not enough.
 
Last edited:

soxtober05

Member
Sep 9, 2012
47
6
Is your model a GSM, or CDMA? I have a Boost 4G LTE that I'm having issues unlocking. If you have any ideas on this, hit me in PM so the thread stays on topic.

Peace,
Sox
 
  • Like
Reactions: Andr01dye

Top_Quark

Member
Oct 24, 2014
14
10
Dammit, I wish I had seen this before I tried relocking my bootloader!

I'm going to try going through Motorola Customer Service and see where it gets me. I'll keep this thread updated with status: https://forums.motorola.com/posts/dd336f32ff

I did some reverse engineering of the bootloader to try to understand the underlying issues and see if I could find a workaround. See my first post on the above thread (near the bottom of the post) for my findings. In case anyone is curious, I'm attaching the decompiled code (assembly with annotations) from the aboot image in the bootloader. I obtained this by grabbing the XT1524_RETEUALL_MOTOE2 (4G-LTE) _5.0.2_LXI22.50-13_cid7_subsidy-DEFAULT_CFC.xml firmware from here, then running the following on an Ubuntu Utopic (14.10) machine:
Code:
unzip XT1524_*.xml.zip

# The general bootloader.img file format is described here: https://android.googlesource.com/device/lge/hammerhead/+/master/releasetools.py#98
# This bootloader.img is slightly different, but I was able to find the offsets of each section by searching for "ELF" in bootloader.img, and I simply looked at the first 100 bytes or so of bootloader.img to determine the order of the sections in the file
tail -c +520705 bootloader.img > temp
head -c 1048576 temp > aboot.img

sudo apt-get install radare2
radare2 aboot.img
# Within radare:
# Set some options
# Yes, there really is an option named anal.plugin ...
e anal.plugin=arm
e asm.arch=arm
e asm.cpu=arm
e asm.parser=arm.pseudo
e asm.bits=32
# Analyze the file
# This takes a while to run and causes radare to consume over 1GB of RAM
aa
# Find the offset/length of the .text section
S
# This takes even longer to run than 'aa', but only consumes about 100MB of additional RAM
pd 0x00086ba0 @ 0x8f600140 > aboot.asm
# Quit
q
 

Attachments

  • aboot.tar.bz2
    1.7 MB · Views: 319
  • Like
Reactions: mai77 and squid2

Top_Quark

Member
Oct 24, 2014
14
10
Not sure if this is already common knowledge, but ...

While digging into the bootloader code further, I stumbled across this site where Qualcomm publishes versions of AOSP that are modified to work with various Qualcomm chips: https://www.codeaurora.org/projects/all-active-projects/android-msm

The source released on that site includes bootloader code: https://www.codeaurora.org/cgit/quic/la/kernel/lk
The branches and tags in that git repo are rather cryptic, but the chipset associated with each branch/tag is listed here: https://www.codeaurora.org/xwiki/bin/QAEP/release
(The LNX.LA.* branches/tags are for the msm8916_32 chip in the 2nd gen Moto E.)

It looks like Motorola's bootloader is based on this source code from Qualcomm. Qualcomm's open source implementation of the fastboot command handler is very primitive, so Motorola has replaced it with their own implementation, and it is Motorola's implementation that contains the bugs/misfeatures that cause our re-locking issue. However, much of the code called by Motorola's fastboot implementation is available in Qualcomm's repo, so having Qualcomm's source available makes reverse engineering of Motorola's fastboot implementation much easier.
 
Last edited:
  • Like
Reactions: mai77

Top Liked Posts

  • There are no posts matching your filters.
  • 9
    Just a heads up to those who may attempt relocking an unlocked bootloader:

    As you probably know, the new Moto E required you to enable bootloader unlocking in the Android developer options menu before you can run the fastboot oem unlock XXXXX command. Unlocking the bootloader wipes the frp partition. Wiping frp restores the default state of OEM unlock disabled. When you relock the bootloader, even if you are already running signed official firmware for your model, the phone will refuse to boot until you reflash the system image. For most models of the Moto E, official firmware has not leaked. Different carriers and regions have different CIDs, even among retail devices, so even signed builds that leak are incompatible across different carriers.

    End result: If you are not careful when relocking your bootloader, there is a high risk of soft bricking your device. I made such a mistake today. I just got a new Telus Moto E today, unlocked the bootloader, then relocked it while leaving the software unchanged. Unlocking wiped userdata, disabling re-unlocking. Relocking prevented my phone from booting up till I flashed a signed image that I didn't have, and I could no longer re-unlock either. This soft bricked my phone. Stock firmware signed for my model and region has not leaked. I was able to fix my phone through other means (not available), but for most of you on XDA, your phone would be effectively bricked if you did what I did.

    Morals of the story:
    • Don't relock unless you have a reason to
    • Make sure you re-enable bootloader unlocking in Android before re-locking
    • Make sure you have a fastboot flashable official stock image signed to work with your carrier and region before re-locking the bootloader. Currently running the official firmware is not enough.
    2
    Dammit, I wish I had seen this before I tried relocking my bootloader!

    I'm going to try going through Motorola Customer Service and see where it gets me. I'll keep this thread updated with status: https://forums.motorola.com/posts/dd336f32ff

    I did some reverse engineering of the bootloader to try to understand the underlying issues and see if I could find a workaround. See my first post on the above thread (near the bottom of the post) for my findings. In case anyone is curious, I'm attaching the decompiled code (assembly with annotations) from the aboot image in the bootloader. I obtained this by grabbing the XT1524_RETEUALL_MOTOE2 (4G-LTE) _5.0.2_LXI22.50-13_cid7_subsidy-DEFAULT_CFC.xml firmware from here, then running the following on an Ubuntu Utopic (14.10) machine:
    Code:
    unzip XT1524_*.xml.zip
    
    # The general bootloader.img file format is described here: https://android.googlesource.com/device/lge/hammerhead/+/master/releasetools.py#98
    # This bootloader.img is slightly different, but I was able to find the offsets of each section by searching for "ELF" in bootloader.img, and I simply looked at the first 100 bytes or so of bootloader.img to determine the order of the sections in the file
    tail -c +520705 bootloader.img > temp
    head -c 1048576 temp > aboot.img
    
    sudo apt-get install radare2
    radare2 aboot.img
    # Within radare:
    # Set some options
    # Yes, there really is an option named anal.plugin ...
    e anal.plugin=arm
    e asm.arch=arm
    e asm.cpu=arm
    e asm.parser=arm.pseudo
    e asm.bits=32
    # Analyze the file
    # This takes a while to run and causes radare to consume over 1GB of RAM
    aa
    # Find the offset/length of the .text section
    S
    # This takes even longer to run than 'aa', but only consumes about 100MB of additional RAM
    pd 0x00086ba0 @ 0x8f600140 > aboot.asm
    # Quit
    q
    1
    Is your model a GSM, or CDMA? I have a Boost 4G LTE that I'm having issues unlocking. If you have any ideas on this, hit me in PM so the thread stays on topic.

    Peace,
    Sox
    1
    Not sure if this is already common knowledge, but ...

    While digging into the bootloader code further, I stumbled across this site where Qualcomm publishes versions of AOSP that are modified to work with various Qualcomm chips: https://www.codeaurora.org/projects/all-active-projects/android-msm

    The source released on that site includes bootloader code: https://www.codeaurora.org/cgit/quic/la/kernel/lk
    The branches and tags in that git repo are rather cryptic, but the chipset associated with each branch/tag is listed here: https://www.codeaurora.org/xwiki/bin/QAEP/release
    (The LNX.LA.* branches/tags are for the msm8916_32 chip in the 2nd gen Moto E.)

    It looks like Motorola's bootloader is based on this source code from Qualcomm. Qualcomm's open source implementation of the fastboot command handler is very primitive, so Motorola has replaced it with their own implementation, and it is Motorola's implementation that contains the bugs/misfeatures that cause our re-locking issue. However, much of the code called by Motorola's fastboot implementation is available in Qualcomm's repo, so having Qualcomm's source available makes reverse engineering of Motorola's fastboot implementation much easier.
    1
    I finally found a copy of the stock firmware for my phone!
    http://forum.xda-developers.com/showpost.php?p=60448421&postcount=27

    Flashing the original system image got me up and running again. :D
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone