The TWRP Password Protection Thread

Search This thread


Senior Member
Apr 2, 2016
Hi! @antonio.galea. Twrp PW Lock works for 3.4 boot only. When installer flashed Twrp boots without the PW screen. Any way to fix it?

I've rebased my repo over TeamWin's - now it follows version 3.4.0.

As before, my only changes are in gui/theme/portrait.xml, gui/theme/landscape.xml files - and now both contain the new TWRP stuff.

Can you try and see if those do work correctly?


Senior Member
May 4, 2016
Question about this TWRP: I've noticed that I can bypass the password screen by pressing Cancel and I'm still able to access features like the File Manager. Is this normal behavior? What does the password in TWRP protect?


Senior Member
Apr 2, 2016
Question about this TWRP: I've noticed that I can bypass the password screen by pressing Cancel and I'm still able to access features like the File Manager. Is this normal behavior? What does the password in TWRP protect?

I don't know about that specific password implementation. I've added a protection myself to standard TWRP and it definitely can't be bypassed like that. I've not been updating it in a while, but it applies cleanly to version 3.4.0.

That said, anyone with the skills can always overwrite your recovery with a passwordless one (unless you are one of the lucky fews who can re-lock their bootloader) - so password can only be treated as a protection against a casual prankster and not against a determined attacker.


Senior Member
Nov 3, 2015
Xiaomi Poco F3
Sheesh.. that's a lot of complex techy stuff.. I only wanted a password for stopping my little nephews from wiping my phone as a prank not for hacking the pentagon 😂

Then again the stock recovery is no better.. the manufacturers really need to start protecting the phones booting like laptops have this bios password thing.. anyone can just reboot to recovery and wipe the phone.. one of the few things that apple did better I guess..


Apr 2, 2022
Is there any file that works for twrp 3.6.0?
I don't care about absolute security, all I need is a way to have a password show up when entering twrp so idiots can't reset the device from recovery.

Any help on this would be greatly appreciated.


Apr 2, 2022
Also, if I have to use python tool, how can I use it on a A/B device, as I can't find out how to change the recovery when its part of the boot image?

Top Liked Posts

  • There are no posts matching your filters.
  • 20
    The TWRP Password Protection Thread

    Yes, it has been discussed to no end. People say it makes no sense. More importantly, the TWRP team says it makes no sense:

    Password protecting TWRP (lockscreen)

    I've had people ask enough for a protected TWRP that I'm creating this page as a response so I don't have to retype. If you're seeing this page, you're probably asking, "Why doesn't TWRP offer password protection?" You want to lock down your device so that a would-be theif won't be able to wipe your device to get past your lockscreen and/or so they can't wipe away that cool app you bought from the Play Store that will let you track your stolen device via GPS. Well, here's the short answer:

    Nothing trumps physical access to your device. If you've lost it, there's no way that TWRP can secure it.

    For a longer answer, it's very easy for anyone with just a little bit of knowledge to get around any kind of security that TWRP might have. All they have to do is flash one of the other recoveries that's available that doesn't have password protection to get around it. Most, if not all devices have ways to flash recovery without needing to boot to either Android or recovery (usually via fastboot or download mode / Odin). Quite literally the only way to truly secure your device would be to render the USB port completely unusable which isn't an option for most newer devices that don't have removable batteries. Even then most devices could still be worked with via jtag though it's unlikely that a thief will go to the trouble of paying for a jtag service on a device that has a broken USB port. (Note: I am not recommending that you purposely damage your USB port as it will also likely make it very difficult to recover your device if anything ever goes wrong!)

    I also don't want to offer a lockscreen / password protection because it offers such a superficial level of protection. Users rarely read and would skip over any disclaimers that we have that indicate that any protection that we displayed indicating that their device really isn't secure. If your device has fallen into someone else's hands, your best case scenario should be that you hope that they don't get your personal data. If you don't want someone getting your personal data, use Android's device encryption and a good lockscreen.

    But it does makes sense in many cases. My objectives with this thread are: to change the minds of the TeamWin team members on this matter, and to discuss the best way to implement TWRP security. I will start by answering TeamWin's post.

    1) Most people just want their data safe, not their phones unusable to burglars.

    It is true that nothing beats encryption. But encryption with a trivially short PIN, pattern or password is useless. Raw access to the encrypted media allows brute forcing which in almost all realistic cases will recover the key in no time. Making it hard to reach the encrypted media would in these cases provide more security than encryption itself. And in any case, this would be added security, not replacement security, and can only strengthen the system (and in common cases, by a great deal).

    The security of some phones is fundamentally broken, and there is nothing TWRP can do to fix that. The only fix could come from updated bootloaders. But bootloaders need to be signed by the phone manufacturer to work (so aftermarket bootloaders are not an option), and many companies are just not serious enough to care.

    Case in point: dirty Samsung. All Samsung cares about is ending your warranty if you dare install software of your choice on your own phone. It has made it impossible for developers to overcome this by actually blowing physical fuses within the phone in their bootloaders if you exercise your freedom. Their "upgrade" bootloaders also blow fuses to prevent you from ever downgrading to the more permissive bootloader that might have been in the phone when you first bought it.

    They care about invalidating your warranty a lot, but not at all about your data. I can grab a stock S3, flash whatever I want (voiding warranty, or so they say because in many countries it is rightly not so) and get to your data. So it better be encrypted because Sammy is not giving a damn to defend it.

    But other phones actually make an effort to defend your data. This is the case of, for instance, all Google Nexus devices, and the OnePlus One. I name these phones because these are the only mass-market phones I know that do not try to take away your tinkering freedom with threats of voided warranties, and so are the only phones I consider when buying. (No feature is worth loosing your freedom IMO.)

    These phones actually fully wipe your data when you unlock their bootloaders, a required step before any flashing is allowed. This means that if I grab a bootloader-locked nexus, I can wipe it but not get to the data without the lockscreen code. Well, unless TWRP is flashed. TWRP breaks the security that Google (and others) baked into their phones.

    There used to be a good reason to avoid security in the old CWM days: CWM was not touch, and much less was capable of popping up a keyboard. TWRP has gone such a long way forward that now security can be easily implemented. There is no reason to break the security of good phones just because some phones are broken.

    One could disallow access to the storage media on their phone (encrypted or not) by installing TWRP with a password and then relocking the bootloader. In this way, the modded phone would be as secure as its stock counterpart. Modding your phone would not longer mean zero security.

    2) It turns out that those who want to disable the burglar's ability to reset the phone and sell it can actually do it in many cases!

    It so happens that bootloaders usually do not wipe the phone themselves as it is "too complex" an operation. Many times during bootloader unlocking, the bootloader boots stock recovery instructing it to 1) do the wipe, then 2) reset the bootloader lock. If the bootloader is locked and TWRP is installed in place of the stock recovery and TWRP ignores these commands (as current versions do), then there is no way to wipe the data or unlock the bootloader (and thus no way to flash a door to the system) from fastboot.

    So if you:
    1) setup a TWRP lockscreen,
    2) keep a flashable zip that unlocks your bootloader in your phone (see boot unlock scripts),
    3) setup an android lockscreen,
    4) download a root app that unlocks your bootloader (see BootUnlocker),
    5) and lock the bootloader,

    ...then you are secure. You can recover bootloader access without wiping as long as either one of rooted android and/or recovery works. But you cannot use either without going through their respective lockscreens.

    This prevents access to your data, but in the case mentioned here (recovery does the actual bootloader unlock) it also prevents wipes. In this situation, it is not difficult to imagine a burglar attempting to sell you back your own phone on the cheap. Of course suitable contact info would be displayed in your lockscreen. This is even more security than was planned by Google, and not less as is the current situation with TWRP.

    I know for a fact that the OnePlus One works in this recovery-invoked-to-unlock-bootloader manner, and I suspect all Nexuses work in the same way. For these phones, anti-theft can be a reality, and getting them back after a robbery, a not so improbable scenario.

    NOTE: It should now be obvious why it is very dangerous to lock your bootloader unless a working stock recovery is in place. If you cannot obtain root access in either android or recovery, your recovery is custom (and thus it does not unlock the bootloader), and your bootloader is locked, then you are stuck: you will not be able to unlock your bootloader without a JTAG rig. Under some circumstances this can render your phone unrootable or effectively bricked. This is in part our objective anyway: that burglars are not able to gain control of the phone, not even by full wipe. But it can seriously backfire if you make a configuration mistake or simply forget your passwords. Keep in mind that you can make these mistakes today, without security in TWRP. Bootloader re-locking in a scenario other thank return-to-stock is an intrinsically dangerous operation that only advanced users should attempt.

    3) Encryption is insecure unless the boot chain can be trusted.

    An adversary that gains physical access to your phone can dump and save a copy of the encrypted partition(s) and plant a password sniffer that later forwards the password to them. You cannot trust your password to a non-tamper-evident device that can be trivially modified. The only way to protect the boot chain from tampering in today's phones is locking the bootloader and restricting access to the recovery.


    Some SoCs are compromised. For example, a signed USB-fed bootloader for the Galaxy Nexus has leaked into the public domain, and with it the SoC of a Galaxy Nexus can be booted entirely via the USB port. A monitor software can be loaded that can read (or write) the complete eMMC (the storage). This is possible because either TI or Samsung leaked a properly signed debugging bootloader. This is an extremely rare case because this bootloader makes you God. I think some Kindle Fires also have a similar thing. Few phones had their security broken so drastically; compromised SoCs are the exception and are very few.

    Finally, the attacker could open up the phone and use JTAG to directly access the eMMC. It requires equipment and know-how and work and time, and significantly adds to the full cost of robbing a phone, eating up their profit. Probably almost all phones could be recovered by JTAG.

    But of course, there are countermeasures to countermeasures. Many people have discussed damaging JTAG traces, bond wires, or even the IC itself, and some JTAG ports can be irreversibly disabled by design.


    1) TWRP is doing nothing in fundamentally insecure phones.
    2) TWRP is disabling the security of secure phones.
    3) Secure phones with TWRP could be as secure as they are with stock recovery.
    4) In some cases phones with TWRP can be even more secure, preventing their unauthorized wiping and reselling.
    5) A barrier blocking access to encrypted media can effectively protect more than encryption itself if short keys are used.
    6) Encryption is insecure with an unlocked bootloader or an open-access recovery.

    We have the rationale, we have the UI, we have the keyboard, and we have the great team of programmers behind TWRP: let's get this old rat hole plugged for good.
    I would like to try that! But I'm confused about how to use that kitchen tool, please may I ask you help?

    I wrote a Python script to simplify the process. I only tested it on Linux, I would appreciate if you can confirm me that is runs correctly on Windows too:

    I haven't got a tablet for testing landscape.xml - the password locking check is in place, but the appearance need revisiting. Anyone volunteers?

    If you have a recovery image that you want to protect, I've created a simple script to automate the process:

    Linux is needed.
    Badly need to lock recovery and secure adb as my work protocol requires to surrender phone daily to security personnel. Please help.

    I've installed my script on a Window10 64bit machine - and discovered that AIK has been updated, so the download links were not correct any more.

    Now I've updated them and made a few minor edits - I can confirm you that on Windows it works.

    Step by step guide:
    - install Python3 from here:
    - during install, make sure that you "add Python.exe to PATH"; if you forgot, launch the installer again, click on "edit" and check the box
    - download my script from here: and put it in the same directory of the image you want to password-protect
    - open a cmd prompt and cd to that directory
    - launch it with

    python <put the name of your twrp.img here>

    i forgot to mention in the first post that Philz Touch Recovery does have password support. (i think they are actually PINs.) i haven't checked how the security is implemented in Philz though. regrettably that recovery has been discontinued so further investigation seemed useless.

    TWRP is such a great piece of software that i simply can't imagine any competition will dare take on it again. that's exactly why it's important to get security merged in TWRP.

    3 people in the entire world do a majority of the work for TWRP. We are welcome for contributions to the TWRP projcect at OMNI's gerrit for people who want to get this done.