5

I have OnePlus One with CyanogenMod 12 from factory and I decided to update to CM 13 (nightly build).
To achieve this I did the following from OSX:

  1. Unlock the bootloader (fastboot oem unlock)
  2. Boot TWRP (fastboot boot twrp-2.8.6.0-bacon.img)
  3. From TWRP I installed CM 13 (cm-13.0-20160105-NIGHTLY-bacon.zip) and GAPPS (open_gapps-arm-6.0-pico-20160105.zip)
  4. I also installed the latest Cyanogen Recovery (cm-13.0-20160105-NIGHTLY-bacon-recovery.img)
  5. For some reason, I felt like leaving things as they were, and I relocked the bootloader (fastboot oem lock)

Now, I cannot unlock the bootloader anymore in order to do things like install/boot a custom recovery tool (like TWRP)
Running 'fastboot oem unlock' just reboots the device in recovery mode, but the bootloader remains locked:

$fastboot oem device-info
...
(bootloader)    Device tampered: true
(bootloader)    Device unlocked: false
(bootloader)    Charger screen enabled: false
(bootloader)    Display panel:
(bootloader)    console_enabled: 0
(bootloader)    exec_console_unconsole: 0

A solution would be appreciated, but I am also curious why it behaves like this after a manual lock.
As suggested by @Firelord, there seems to be a solution for Windows users here: https://forums.oneplus.net/threads/important-bootloader-wont-unlock-after-relock.324398/

2

2 Answers 2

2

In my search, I came across an interesting thread that was related, but in order to install their script, you need to have a custom recovery tool installed or to be able to boot into it (e.g. fastboot boot recovery.img).

I had the stock Cyanogen Recovery tool and I couldn't boot into TWRP because of my actual problem (cannot unlock bootloader anymore), so I dug inside their script and used the content meant to reset the lock and tamper bits of the bootloader.

Now I could run the commands manually if I had root access and luckily, in CM 13 ROM, you can enable it from 'Developer options' menu.

Here are the commands I used after enabling root access for ADB:

adb root     # restart the adbd daemon with root permissions
adb shell    # run remote shell interactively
dd bs=1 count=1 skip=1048080 if=/dev/block/platform/msm_sdcc.1/by-name/aboot 2>/dev/null | xxd | cut -c 10-     # print the lock bit state (00 - locked, 01 - unlocked)
echo -ne "\x01" | dd bs=1 count=1 seek=1048080 of=/dev/block/platform/msm_sdcc.1/by-name/aboot                  # set the lock bit to unlocked(01)
dd bs=1 count=1 skip=1048084 if=/dev/block/platform/msm_sdcc.1/by-name/aboot 2>/dev/null | xxd | cut -c 10-     # print the tamper bit state (00 - untampered, 01 - tampered)
echo -ne "\x00" | dd bs=1 count=1 seek=1048084 of=/dev/block/platform/msm_sdcc.1/by-name/aboot                  # set the tamper bit to untampered(00)

Result:

$fastboot oem device-info
...
(bootloader)    Device tampered: false
(bootloader)    Device unlocked: true
(bootloader)    Charger screen enabled: false
(bootloader)    Display panel:
(bootloader)    console_enabled: 0
(bootloader)    exec_console_unconsole: 0

I guess the tamper bit is changed the first time you unlock the bootloader (fastboot oem unlock) and after you lock it back (fastboot oem lock) it won't allow you to re-unlock.

0

If xxd and cut do not exist in locations available in $PATH (as it was in my case), prefix busybox in those commands.

# print the lock bit state (00 - locked, 01 - unlocked)
dd bs=1 count=1 skip=1048080 if=/dev/block/platform/msm_sdcc.1/by-name/aboot 2>/dev/null | busybox xxd | busybox cut -c 10-     
# set the lock bit to unlocked(01)
echo -ne "\x01" | dd bs=1 count=1 seek=1048080 of=/dev/block/platform/msm_sdcc.1/by-name/aboot                  
# print the tamper bit state (00 - untampered, 01 - tampered)
dd bs=1 count=1 skip=1048084 if=/dev/block/platform/msm_sdcc.1/by-name/aboot 2>/dev/null | busybox xxd | busybox cut -c 10-     
 set the tamper bit to untampered(00)
echo -ne "\x00" | dd bs=1 count=1 seek=1048084 of=/dev/block/platform/msm_sdcc.1/by-name/aboot   
3
  • 2
    Giving that this is just a small addition on top of the accepted answer, it should be a comment or a suggested edit, not a standalone answer.
    – codentary
    Feb 13, 2016 at 9:55
  • Sorry, I just want to share my 5 cents with others, your solution actually solve my problem.
    – Alsan
    Feb 14, 2016 at 1:11
  • Don't be sorry for sharing. I just pointed out the proper way to share in this case. Use the "Add Comment" button under my answer and add your remark that "busybox must be prepended if xdd and cut are not in path" and give a small example like: "busybox xdd" without duplicating all the commands. Another option is to suggest an edit.
    – codentary
    Feb 14, 2016 at 12:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .