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?
The TWRP Password Protection Thread
- Thread starter Lanchon
- Start date
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?
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.
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..
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..
I do that, but when I reboot to recovery again, it's switched back to 0. I'm pushing a different default.prop file with twrp, using adb root. Is there something I'm doing wrong?
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
20The 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:
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.
Countermeasures
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.
Conclusions
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.5
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:
https://github.com/ant9000/TWRP-protect
Antonio5
If you have a recovery image that you want to protect, I've created a simple script to automate the process:
https://github.com/ant9000/TWRP-protect
Linux is needed.5
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: https://www.python.org/ftp/python/3.7.0/python-3.7.0.exe
- 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: https://raw.githubusercontent.com/ant9000/TWRP-protect/master/protect.py 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
Code:python protect.py <put the name of your twrp.img here>
Antonio4
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.
