The TWRP Password Protection Thread

[Defier525]

Out of curiosity, I tried the following on my Nexus-S:

- relock bootloader using "fastboot oem lock" (worked fine, shows status locked; trying to fast-boot another kernel is refused by the device)
- boot CM11 which was already there before re-locking using the locked bootloader (worked fine as well, seems not to check kernel signatures)
- send "fastboot erase data" from locked bootloader (worked fine as well !?! phone booted to fresh data partition):

$ fastboot erase userdata
erasing 'userdata'...
OKAY [  0.272s]
finished. total time: 0.273s

Recovery - no matter if password protected or not - was not involved at all in the process. In case the phone was not encrypted, stuff in userdata would be lost but I could easily access the emulated internal storage. With some file recovery techniques, I should be probably also able to restore most stuff in userdata, since the "wipe" by "fastboot erase", which took less than 300ms, probably just wrote a new filesystem signature to the data partition without really wiping anything.

Now, if I can get root (i.e. if the previous rom was rooted already or an exploit exists) I can now easily flash a new password-unprotected recovery and revert everything back to stock. And probably so can the burglar which you wanted to lock out with password-enabled TWRP. To put it with your terms, I don't consider this for the list of "other phones which actually make an effort to defend your data. "

Since you counted all Google Nexus devices in your whitelist of "secure phones", can you please confirm that newer devices like Nexus 4, Nexus 5 or OnePlus One are not affected by this vulnerability?

 

[Lanchon]

Internal sdcard in /data/media since AOSP 4.0: This was new to me, but it seems to be implemented this way in my Nexus S. I just wonder why my Xperia V does not handle it this way then?

eMMC and secure erase: Okay this was new to me as well. But afaik, TWRP does not use these commands for wiping, does it?

locked bootloader and password protected TWRP: What if an attacker would try to fastboot erase the data or recovery partition? Will a locked, properly implemented bootloader prevent that?

devices that were released in android 2.x days with "internal sdcard" emulated in the phone's emmc typically have a fat32 partition that implements it. devices released with android 4.x typically have a fuse process that reflects some content under /data/media (ext4 or some other linux fs) as the sdcard, emulating fat32 properties (no fs level security, case insensitive file names, etc). when devices are upgraded from android 2 to android 4, either by the OEM or by hobbyists, they are typically not repartitioned and the original schema is maintained.

typically all custom recoveries do this because they are based on stock recovery, unless its disabled to work around some bug (brickbug in the exynos 4210 platform, long wipe times in the nexus 5, etc). for CM recoveries see:
https://github.com/search?q=BOARD_SUPPRESS_EMMC_WIPE+user:CyanogenMod&type=Code

locked fastboot means no change to the emmc is possible and no booting of kernels over usb. no exceptions made, no signatures are looked for. locked means fastboot is not an attack vector.

 

[Defier525]

I don't agree with you in these points:
- considering fastboot, please read my previous posting (probably posted while you were writing this). I definitely consider this a serious attack vector, at least on my Nexus S.
- considering partition layout, I posted the internal layout in stock ROM from my Xperia V in another forum. The Xperia V originally came with Android 4.0 (unlike the Nexus S) and it uses 15 partitions for the internal eMMC. Userdata and SDCard are on separate partitions, no matter how they are mounted later with fuse. Therefore, only wiping Userdata will not affect the internal sdcard at all.

 

[Lanchon]

the wipe in CM recovery is done here:

https://github.com/CyanogenMod/android_system_extras/blob/cm-11.0/ext4_utils/wipe.c#L42

 

[Dees_Troy]

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.

i thought of that, but adding a feature like this to TWRP probably requires too much effort for somebody who doesnt know the codebase. i imagine that TWRP is sort of an app framework in itself. i chose to advocate for it instead of implementing, i just can't justify the effort it would take *me*. i also tried to help by centralizing ideas on how it should be implemented, if somebody chooses to.

anyway, it's great to know you are not opposing the idea and you would consider merging if somebody implements, that is a good start.

btw, there is a tangentially related issue i'd love to hear your opinion on:

i hear TWRP can mount encrypted partitions and there is a UI for entering PINs, passwords, patterns etc. but i dont have my phone encrypted because if i break my display with the phone encrypted then im toast: i cant extract my files from the device anymore.

would you consider implementing a way to enter the encryption password via usb? maybe some sort of adb shell command?

The features you're asking for will likely only be used by a tiny subset of users on a small subset of the overall devices that we support. The number of devices that allow you to relock the bootloader and still allow you to boot an unsigned image is basically just Nexus devices and the OPO. The number of users that need / want the feature you're requesting is very small, probably less than 20 people.

The amount of time and effort needed to properly implement what you are requesting is not small. Finding a safe location and method to store the password will hardly be trivial. We need to make sure that adb is completely disabled until after the correct password is entered, otherwise an attacker would be able to use adb to bypass most of the security measures. We cannot safely store the password anywhere in /data because the data partition may be encrypted and thus not accessible.

You still haven't come up with a solution to a fastboot erase command that I believe still works on Nexus and probably the OPO devices even if the bootloader is locked. As I said in my write-up, your best case scenario if someone else gets hold of your phone is that they don't get access to your private data.

You might be able to enter a password on a device with a broken display using a USB keyboard and USB OTG cable. As mentioned earlier, leaving adb running leaves a humongous gaping security hole open that basically makes all of your arguments for better security null and void.

The fact that you don't encrypt your device and the fact that you aren't willing to do the development yourself tells me you aren't that serious about security.

I guarantee you that I have thought about this subject way more than you have. It's extremely unlikely that you're going to win this argument, and even if you "win", it's extremely unlikely that I'm going to develop this feature for you as part of regular TWRP development because of the limited benefit to the overall project. I do take contract work though, on occasion if it is something that you're serious about. It's not cheap though.

Also, for the record, the Nexus S does NOT have unified storage. You can get unified storage on the Nexus S using lvm and some other "hacks", but in stock form it does not have unified storage.

 

[Lanchon]

Out of curiosity, I tried the following on my Nexus-S:

- relock bootloader using "fastboot oem lock" (worked fine, shows status locked; trying to fast-boot another kernel is refused by the device)
- boot CM11 which was already there before re-locking using the locked bootloader (worked fine as well, seems not to check kernel signatures)
- send "fastboot erase data" from locked bootloader (worked fine as well !?! phone booted to fresh data partition):

$ fastboot erase userdata
erasing 'userdata'...
OKAY [  0.272s]
finished. total time: 0.273s

Recovery - no matter if password protected or not - was not involved at all in the process. In case the phone was not encrypted, stuff in userdata would be lost but I could easily access the emulated internal storage. With some file recovery techniques, I should be probably also able to restore most stuff in userdata, since the "wipe" by "fastboot erase", which took less than 300ms, probably just wrote a new filesystem signature to the data partition without really wiping anything.

Now, if I can get root (i.e. if the previous rom was rooted already or an exploit exists) I can now easily flash a new password-unprotected recovery and revert everything back to stock. And probably so can the burglar which you wanted to lock out with password-enabled TWRP. To put it with your terms, I don't consider this for the list of "other phones which actually make an effort to defend your data. "

Since you counted all Google Nexus devices in your whitelist of "secure phones", can you please confirm that newer devices like Nexus 4, Nexus 5 or OnePlus One are not affected by this vulnerability?

im assuming you rebooted the bootloader after oem unlock and before erase.

well, you stumbled onto a bug. your device is 4 generations old and discussing a bug of your bootloader in detail here is off-topic. many, many devices have security broken, by design or by bugs, but that doesnt mean TWRP should break the security of those -many or few- that get it right.

let's do this anyway but please let's keep it brief.

recovery is only invoked on device wipe (oem unlock), never on fastboot erase. the emulated partition was deprecated 4 years ago, before encryption was added to android. current devices are of the /data/media type and encryption on these devices encrypts everything. on the other hand, fastboot oem unlock wipes everything, including emulated sdcard on old emulated partition devices.

fastboot (device side) understands the GPT but does not know about file systems. for sure fastboot erase did not "just wrote a new filesystem signature", it probably issued a (nonsecure) DISCARD emmc command spanning the partition. (or else maybe it did a no-operation?) nonsecure DISCARD is actually very efficient: it only unmaps blocks. the data is still in the flash though, the NSA could get it back. the emmc will be erasing the affected erase blocks at its leisure, when it needs to, or when it is idle, or the main cpu informs the emmc it's time to do housekeeping (device unused and charging, for instance).

after the DISCARD is issued, you would be unable to read anything out of the emmc. the emmc synthesizes blocks of zeros when reading out unmapped blocks. data is really gone, unless you can hack the emmc firmware (entirely possible for a worthy adversary), or you decap the module and access the flash directly. SECURE DISCARD on the other hand actually wipes the flash, including the many stale copies that might exist of the wiped blocks.

in any case, fastboot erase should be inaccessible in a locked bootloader and whatever it did in your device is nonstandard and not our concern here. write the nexus S off as an insecure device if you will.

moving on, the next point is moot: if you get root you are over the bootloader protection. the whole point of this thread is preventing root access by an unauthorized party.

i never white-listed any phones! for sure all nexus make a desgin effort to defend your data, but implementations can be flawed. in particular, the boot-into-recovery-to-wipe-and-then-unlock bootloader behavior, i can only vouch for it on the OPO where i tested it. and ive stated this in the OP. but according to messages ive read, it seems to hold true for the nexus 4 and 5 at least.

i cannot confirm or deny the fastboot erase vuln on other phones at this time. (this would wipe all useful data on newer phones though.)

 

[Lanchon]

The features you're asking for will likely only be used by a tiny subset of users on a small subset of the overall devices that we support. The number of devices that allow you to relock the bootloader and still allow you to boot an unsigned image is basically just Nexus devices and the OPO. The number of users that need / want the feature you're requesting is very small, probably less than 20 people.

The amount of time and effort needed to properly implement what you are requesting is not small. Finding a safe location and method to store the password will hardly be trivial. We need to make sure that adb is completely disabled until after the correct password is entered, otherwise an attacker would be able to use adb to bypass most of the security measures. We cannot safely store the password anywhere in /data because the data partition may be encrypted and thus not accessible.

You still haven't come up with a solution to a fastboot erase command that I believe still works on Nexus and probably the OPO devices even if the bootloader is locked. As I said in my write-up, your best case scenario if someone else gets hold of your phone is that they don't get access to your private data.

You might be able to enter a password on a device with a broken display using a USB keyboard and USB OTG cable. As mentioned earlier, leaving adb running leaves a humongous gaping security hole open that basically makes all of your arguments for better security null and void.

The fact that you don't encrypt your device and the fact that you aren't willing to do the development yourself tells me you aren't that serious about security.

I guarantee you that I have thought about this subject way more than you have. It's extremely unlikely that you're going to win this argument, and even if you "win", it's extremely unlikely that I'm going to develop this feature for you as part of regular TWRP development because of the limited benefit to the overall project. I do take contract work though, on occasion if it is something that you're serious about. It's not cheap though.

Also, for the record, the Nexus S does NOT have unified storage. You can get unified storage on the Nexus S using lvm and some other "hacks", but in stock form it does not have unified storage.

hi and thanks for answering! and for TWRP too

i absolutely understand the cost vs. return argument, i only wrote this thread because i didn't agree with the "we shouldn't do it because it's useless" stance as a way to trigger constructive discussion, such as this here.

as an option to where to store the password:

last sector of the recovery partition: a header plus integrity checking at the end of the sector (that could be the same hash function used to store the password). on init, the recovery reads the last sector of the recovery partition. (that shouldnt cause a problem in fastboot boot scenarios.) if the sector doesnt pass header/integrity checks, continue booting. otherwise ask for a password if the payload section of the sector has a password hash in it.

downside: susceptible to induced glitching attacks during the sector read. workaround (far from perfect): read the sector twice (bypassing caches) and fail to boot if the reads differ. (real workaround: die hard enthusiasts can build their own TWRP that fails to boot if the sector fails the checks.)

the fastboot erase vuln: this should be fixed by google if it wasnt ages ago. they can easily fix bootloaders in the field too. i will try to investigate this and post results here.

usb: well, because i always used patterns to unlock, i never thought i could encrypt the phone with a password then use a usb keyboard to decrypt. this is so simple it's brilliant! do you know if this would work while booting standard encrypted android? would the kernel connect usb keyboards before mounting data? (for sure BT keyboards wouldnt work.) if this works i would encrypt my phone.

yes, i stated in post #2 that adbd and mtpd have to remain disabled before auth of course. or some new adbd mode could be used to get the password. or maybe a completely independent, hacked adbd binary could do it; that could make maintenance of standard adbd easier.

lol, i AM serious about security! im paranoid about my printers getting worms! really, i am serious, so much so that my phone doesnt keep anything of value outside of my keepass vault. it is protected by a 30 or so character passphrase that cannot be dictionary attacked. you should see me typing that phrase to unlock my laptop harddrive in public places such as airports: im so wary of cameras filming my figer movements, you'd think im scheming to blow something up, its ridiculous!

on the realistic side, with the opaque baseband owning the phone, connected to everything, and presumably full of vulns, no phone can really be trusted. phones will never be a trusted device for me.

yes, the first /data/media nexus was the galaxy nexus. the cutoff was probably at android 4.1, not 4.0 as i previously stated, i dont really remember.

 

[Defier525]

You still haven't come up with a solution to a fastboot erase command that I believe still works on Nexus and probably the OPO devices even if the bootloader is locked. As I said in my write-up, your best case scenario if someone else gets hold of your phone is that they don't get access to your private data.

I think that it is very essential to actually confirm or falsify this hypothesis first. A friend of mine has a Nexus 4, and when he unlocked the bootloader he simply intercepted the first boot after "fastboot oem unlock" so it went straight to the bootloader again, leading to userdata not being wiped at all.

@launchon I don't own any of these "probably-secure" devices you mentioned (Nexus 5 or OPO), but if you don't mind, please backup your userdata and internal sdcard and try "fastboot erase userdata" with your locked bootloader. In case this should be successful, boot your ROM and see if you can access data on sdcard or not. In case this erase behavior is broken on all Nexus devices, adding TWRP password protection would only protect you in case your data is encrypted (to some degree).

I can only tell from my personal experience with the Sony Xperia V Stock ROM. I had data encryption turned on and after entering the wrong passphrase too many times, the device rebooted and wiped my data without prior warning (I didn't know that!)! To my big surprise, only userdata was affected and the internal sdcard remained untouched. If you look at the partitioning scheme used on this device (which I mentioned in my last post) you will see that there is no such thing as /data/media, with media being just a symlink or something and with sdcard and userdata being physically on the same partition. Instead, there are two partitions: mmcblk0p14 for userdata and mmcblk0p15 for sdcard.

Also, my Nexus S has two flash memory devices: One mtd device and one eMMC. It seems like userdata, media and system are on eMMC while the rest is on MTD. The eMMC part is also split in separate partitions for userdata, media and system:

~ # ls -l /dev/block/platform/s3c-sdhci.0/by-name
lrwxrwxrwx    1 root     root            20 Jan  8 20:26 media -> /dev/block/mmcblk0p3
lrwxrwxrwx    1 root     root            20 Jan  8 20:26 system -> /dev/block/mmcblk0p1
lrwxrwxrwx    1 root     root            20 Jan  8 20:26 userdata -> /dev/block/mmcblk0p2

Well, maybe my understanding of how Android does mount the sdcard into encrypted data is wrong. Please explain it to me. As far as I have seen, you can specify "encryptable=sdcard" in fstab.vendor (like it is done e.g. for the Nexus S) - see this fstab. My understanding is that Android then encrypts the sdcard as well, putting a second cryptofooter at the end of the internal sdcard's partition and not using one cryptofooter for both userdata and internal sdcard. I will try to find out by experiment and post the results.

I looked into the source for fastboot.c, but I did not really understand it so I cannot tell what fastboot erase really does. But it seems like it falls back to less secure erase in some situations. After erasing, I was unable to retrieve the cryptofooter (which was previously there) and also other parts showed just zeros, therefore I assume that your description regarding DISCARD is correct. Yet, it would be better to dd if with zeros or random data afterwards but for the "regular burglar" scenario you mentioned it should be sufficiently secure.

in any case, fastboot erase should be inaccessible in a locked bootloader and whatever it did in your device is nonstandard and not our concern here. write the nexus S off as an insecure device if you will.

I certainly will. Nevertheless I am not sure if I understood you correctly: You already tried to fastboot erase your OPO with locked bootloader and it denied to wipe it or you just suspect / expect it to behave this way without having actually trying it?

The amount of time and effort needed to properly implement what you are requesting is not small. Finding a safe location and method to store the password will hardly be trivial. We need to make sure that adb is completely disabled until after the correct password is entered, otherwise an attacker would be able to use adb to bypass most of the security measures. We cannot safely store the password anywhere in /data because the data partition may be encrypted and thus not accessible.

Why not simple store it in / of /system with appropiate rights? If someone gains enough rights to read that, he should certainly also have enough rights to replace a password protected TWRP with something insecure (or less secure, that's what this thread is about).

 

[Lanchon]

I think that it is very essential to actually confirm or falsify this hypothesis first. A friend of mine has a Nexus 4, and when he unlocked the bootloader he simply intercepted the first boot after "fastboot oem unlock" so it went straight to the bootloader again, leading to userdata not being wiped at all.

@launchon I don't own any of these "probably-secure" devices you mentioned (Nexus 5 or OPO), but if you don't mind, please backup your userdata and internal sdcard and try "fastboot erase userdata" with your locked bootloader. In case this should be successful, boot your ROM and see if you can access data on sdcard or not. In case this erase behavior is broken on all Nexus devices, adding TWRP password protection would only protect you in case your data is encrypted (to some degree).

I can only tell from my personal experience with the Sony Xperia V Stock ROM. I had data encryption turned on and after entering the wrong passphrase too many times, the device rebooted and wiped my data without prior warning (I didn't know that!)! To my big surprise, only userdata was affected and the internal sdcard remained untouched. If you look at the partitioning scheme used on this device (which I mentioned in my last post) you will see that there is no such thing as /data/media, with media being just a symlink or something and with sdcard and userdata being physically on the same partition. Instead, there are two partitions: mmcblk0p14 for userdata and mmcblk0p15 for sdcard.

Also, my Nexus S has two flash memory devices: One mtd device and one eMMC. It seems like userdata, media and system are on eMMC while the rest is on MTD. The eMMC part is also split in separate partitions for userdata, media and system:

~ # ls -l /dev/block/platform/s3c-sdhci.0/by-name
lrwxrwxrwx    1 root     root            20 Jan  8 20:26 media -> /dev/block/mmcblk0p3
lrwxrwxrwx    1 root     root            20 Jan  8 20:26 system -> /dev/block/mmcblk0p1
lrwxrwxrwx    1 root     root            20 Jan  8 20:26 userdata -> /dev/block/mmcblk0p2

Well, maybe my understanding of how Android does mount the sdcard into encrypted data is wrong. Please explain it to me. As far as I have seen, you can specify "encryptable=sdcard" in fstab.vendor (like it is done e.g. for the Nexus S) - see this fstab. My understanding is that Android then encrypts the sdcard as well, putting a second cryptofooter at the end of the internal sdcard's partition and not using one cryptofooter for both userdata and internal sdcard. I will try to find out by experiment and post the results.

I looked into the source for fastboot.c, but I did not really understand it so I cannot tell what fastboot erase really does. But it seems like it falls back to less secure erase in some situations. After erasing, I was unable to retrieve the cryptofooter (which was previously there) and also other parts showed just zeros, therefore I assume that your description regarding DISCARD is correct. Yet, it would be better to dd if with zeros or random data afterwards but for the "regular burglar" scenario you mentioned it should be sufficiently secure.



I certainly will. Nevertheless I am not sure if I understood you correctly: You already tried to fastboot erase your OPO with locked bootloader and it denied to wipe it or you just suspect / expect it to behave this way without having actually trying it?



Why not simple store it in / of /system with appropiate rights? If someone gains enough rights to read that, he should certainly also have enough rights to replace a password protected TWRP with something insecure (or less secure, that's what this thread is about).

nexus 4: not true on the opo. the recovery wipes, then the recovery unlocks. if the recovery doesn't boot, the oem unlock doesnt unlock. verified on opo. i heard this is the case on the nexus 4 too. any other design would be silly, i dont deem google engineers silly.

opo: i will not touch my device, but i might experiment on a different one. you have to understand this: modern phones do not have an "internal sdcard" partition, its all stored in /data. if /data goes, everything goes. if /data is encrypted, everything is.

the nexus S: is an obsolete device (yes, it has two flash chips, fast and big). we've established it's not secure. discussing it beyond that point is not relevant to this thread. same thing applies to you xperia.

fastboot erase is not secure. nor it is meant to be, at all. in android phone wiping is done by the recovery, never fastboot. and btw, secure erase is not done writing zeros, it's done with the right secure erase command of the emmc.

opo: i stated eralier: "i cannot confirm or deny the fastboot erase vuln on other phones at this time. (this would wipe all useful data on newer phones though.)" this applies to the opo too.

/system is a possible store. but is very intrusive, is asking for trouble in the future, and interacts badly with flashing and backups. the password can be unexpectedly reset under many circumstances. the last sector of recovery is way better IMHO.

 

[Lanchon]

confirmed: the fastboot erase vuln is NOT present in the OPO.
(thus, probably also not present in recent nexuses, i suppose.)

rod@rod-latitude ~ $ sudo fastboot devices
[sudo] password for rod: 
e615fff	fastboot
rod@rod-latitude ~ $ sudo fastboot oem device-info
...
(bootloader) 	Device tampered: true
(bootloader) 	Device unlocked: false
(bootloader) 	Charger screen enabled: false
OKAY [  0.004s]
finished. total time: 0.006s
rod@rod-latitude ~ $ sudo fastboot erase userdata
******** Did you mean to fastboot format this partition?
erasing 'userdata'...
FAILED (remote: 	Device not unlocked cannot flash or erase)
finished. total time: 0.003s
rod@rod-latitude ~ $

things of note:

1) this is a "new" straight out of the box OPO delivered to spain by oneplus. it says "tampered: true". (mine didn't.) oneplus is probably selling refurbs as new units. some people reported receiving unwiped phones, with pictures taken by the previous owner inside and all. oneplus is also making it next to impossible to return the device on warranty. oneplus, i have to say, is shady IMO. this is the SECOND "new" OPO that i personally found to be sold in the "tampered" state.

2) fastboot (device side) refuses to erase the partition, as it should.

3) "fastboot format" (host command) creates the formatted partition on the PC side, then forwards and flashes the partition image like any other image. fastboot (device side) does not understand file systems.

 

[Lanchon]

You still haven't come up with a solution to a fastboot erase command that I believe still works on Nexus and probably the OPO devices even if the bootloader is locked.

the vuln is not present in the OPO, please see the previous post.

 

[Defier525]

I asked my friend to send me the partition layout of his Nexus4 and looked at it. Indeed - userdata and sdcard are on the same partition in eMMC. I always thought Android 4.0+ devices all had the ability to encrypt stuff, seems like only 4.1+ support this by default. I will try to find out if the newer stock ROM of the xperia does repartitioning, otherwise maybe I could try it myself. But I think I now get the point about the whole encryptable= option which should allow me to encrypt userdata and both sds on the Xperia using just one key without too much hacking. But this is really OT here, sorry.

/system is a possible store. but is very intrusive, is asking for trouble in the future, and interacts badly with flashing and backups. the password can be unexpectedly reset under many circumstances. the last sector of recovery is way better IMHO.

Some quick brainstorming on this:

I agree regarding /system being intrusive. Regarding the last sector of recovery I see one issue: As far as I understand, recovery usually is not a filesystem like ext4 but a rootfs image? In the nexus4 it is mounted as "emmc" according to fstab. What does this option do? If it's a compressed rootfs, it would be hard to use it as a file inside it. And if it's a regular filesystem, it might get corrupted if we write some unexpected stuff into its last sector?

Another idea: As we've discussed, most people will wanna use encryption anyway if password-protecting their TWRP. Some of these newer 4.1+ devices you mentioned also seem to store the crypto-block of encrypted devices not in the last bytes of the partition (like 4.0 devices do), but on a special metadata partition if I read the Nexus4's fstab correclty:

encryptable=/dev/block/platform/msm_sdcc.1/by-name/metadata

As you can read in Nikolay Elenkov's article I linked earlier, the cryptofooter contains tons of spare space which is reserved for future use. Since TWRP already attempts to extract the cryptofooter of encryptable partitions during launch, it already reads the cryptofooter anyways we could read a bit more of it and look for the TWRP pin in there as well.

Or even better: Why not use the same PIN for TWRP as the encryption passphrase? You will just have to compare the SHA256 sum of the user-entered password and you gain several enhancements: The user only has to remember and enter only ONE password when opening TWRP and TWRP access could even could be protected by default on encrypted devices (well, would be dangerous in cases fastboot erase does not work and you have a "secure" device like the OPO). But it would be pretty close to stock AOSP and reuse all its functionality.

A major issue with this approach could be the attempt to restrict access to the key on hardware level as it is probably already implemented in some qcom devices on android 5. The question here would be which parts of the cryptofooter are accessible how via API - but this is certainly relevant to TWRP offering key unlock support of data for Android 5+ ROMs anyway.

 

[Lanchon]

I agree regarding /system being intrusive. Regarding the last sector of recovery I see one issue: As far as I understand, recovery usually is not a filesystem like ext4 but a rootfs image? In the nexus4 it is mounted as "emmc" according to fstab. What does this option do? If it's a compressed rootfs, it would be hard to use it as a file inside it. And if it's a regular filesystem, it might get corrupted if we write some unexpected stuff into its last sector?

Another idea: As we've discussed, most people will wanna use encryption anyway if password-protecting their TWRP. Some of these newer 4.1+ devices you mentioned also seem to store the crypto-block of encrypted devices not in the last bytes of the partition (like 4.0 devices do), but on a special metadata partition if I read the Nexus4's fstab correclty:

encryptable=/dev/block/platform/msm_sdcc.1/by-name/metadata

As you can read in Nikolay Elenkov's article I linked earlier, the cryptofooter contains tons of spare space which is reserved for future use. Since TWRP already attempts to extract the cryptofooter of encryptable partitions during launch, it already reads the cryptofooter anyways we could read a bit more of it and look for the TWRP pin in there as well.

Or even better: Why not use the same PIN for TWRP as the encryption passphrase? You will just have to compare the SHA256 sum of the user-entered password and you gain several enhancements: The user only has to remember and enter only ONE password when opening TWRP and TWRP access could even could be protected by default on encrypted devices (well, would be dangerous in cases fastboot erase does not work and you have a "secure" device like the OPO). But it would be pretty close to stock AOSP and reuse all its functionality.

A major issue with this approach could be the attempt to restrict access to the key on hardware level as it is probably already implemented in some qcom devices on android 5. The question here would be which parts of the cryptofooter are accessible how via API - but this is certainly relevant to TWRP offering key unlock support of data for Android 5+ ROMs anyway.

the recovery image is always smaller than the partition. the last sector is completely empty, it's not part of anything. if TWRP adopted this password storage, the TWRP images should be padded with an extra sector of zeroes. that way, you wouldnt be able flash the recovery if the partition doesnt have the extra storage space. the worse that can happen then is, you reset the password while flashing. but setting a password would never overwrite and corrupt TWRP.

using the same password for encryption and TWRP is an option i proposed my original posts. you do loose all access "forever" if crypt gets somehow corrupted, or if you change your password then forget it. it's definitely an option though.

im looking at alternatives given that it's clear that TWRP is not getting this functionality i think.

 

[Defier525]

Sorry, it's been a while since I read your OP.

And if you say that the last bytes in the recovery partition should be fine - okay. But it could be a serious problem for devices like my Xperia which run (custom) recovery from rootfs in boot.img and not from a separate partition. No this is not because imy device is "legacy" - newer Xperias are like that as well. They simply don't have a recovery partition at all, although I don't know what boot2 is about...

im looking at alternatives given that it's clear that TWRP is not getting this functionality i think.

I wouldn't say so. I am sure If I understood Dees_Troy correctly (correct me if I am mistaken, Dess), such a patch would need to fulfill some requirements:
- it has to be a patch and not just a feature request (as it is now), they just don't want to do it themselves because they consider its priority too low
- it must make satisfy a purpose. I think even when running encrypted devices which suffer from the "fastboot erase" vuln it makes sense; and if your OPO is not affected that makes it even more justified (at least to me). The biggest drawback here is that it will only offer protection for devices with locked bootloaders, and probably most "TWRP customers" have unlocked bootloaders anyways. But at least it could be valuable for some of the 500.000 OPO owners (if you believe in the numbers...) who run custom roms but value security at least to some degree.
- it has to be low intrusive and easy to maintain in the future

@Lanchon Please PM me if you are interested in developing such a patch. Most stuff needed for it is already in TWRP (like the lockscreen), so it sounds really doable to me. If it turns out to be too poor for official inclusion in TWRP, you can still manually patch the sources of your TWRP and rebuild it. But I doubt the situation will get resolved if people keep demanding the functionality instead of coding a patch.

 

[Lanchon]

confirmed: in an OPO, i tried to interrupt "fastboot oem unlock" recovery bootup in a zillion ways and the bootloader never gets unlocked.

rebooted to QHSUSB__BULK, to fastboot, turned off while booting recovery, nothing worked (as expected).

but later, the next time i booted into recovery, stock recovery found "some state" and wiped the phone then unlocked.

DANGEROUS: doing a fast oem unlock with a custom recovery. command will be ignored but may plant a bomb. if u ever flash stock recovery again ages later, booting into it might unexpectedly wipe your phone. (this is all supposition for now.)

it might be worth to investigate where this "command" is stored. it could be stored the same way the tamper and unlock flags are.

 

[Defier525]

Well, on the OPO it's still not clear to me how the recovery (and not fastboot) can unlock the bootloader? I assume they know which relevant bit is responsible for the unlocked state and directly change/flash this bit on the bootloader, partition. If this is the case, it's a very untypical way of unlocking and very much OPO specific.

Possible cause for your observation: If you had data encrypted, the cryptoheader contains a counter of attempts to unlock the device. I could imagine that this counter is increased each time you are asked for a password even if you do not enter a (wrong) one. Pure and wild speculation though, I assume you still don't have your OPO encrypted, right?

 

[Lanchon]

And if you say that the last bytes in the recovery partition should be fine - okay. But it could be a serious problem for devices like my Xperia which run (custom) recovery from rootfs in boot.img and not from a separate partition. No this is not because imy device is "legacy" - newer Xperias are like that as well. They simply don't have a recovery partition at all, although I don't know what boot2 is about...

youd use the last sector of wherever the recovery is stored. in your case the last sector of the boot partition.

 

[Lanchon]

Well, on the OPO it's still not clear to me how the recovery (and not fastboot) can unlock the bootloader? I assume they know which relevant bit is responsible for the unlocked state and directly change/flash this bit on the bootloader, partition. If this is the case, it's a very untypical way of unlocking and very much OPO specific.

Possible cause for your observation: If you had data encrypted, the cryptoheader contains a counter of attempts to unlock the device. I could imagine that this counter is increased each time you are asked for a password even if you do not enter a (wrong) one. Pure and wild speculation though, I assume you still don't have your OPO encrypted, right?

no, the behaviour is standard on nexuses it seems, the recovery unlocks the bootloader after wiping, i mentioned a zillion times in this thread!

no, i didnt have encryption and i didnt enter any bad password. the recovery wiped because there was a pending instruction to do so from the bootloader.

finally, no, i wont implement the functionality for twrp and its not simple: if i cant unlock via usb it is useless for me. if i implement something it will be something else.

 

[Defier525]

Well the question is: Does fastboot check for a flag recovery sets after wiping (so unlocking is done by fastboot) or does recovery unlock itself? If it's the latter, how does recovery actually accomplish this?

And as I said, on both my friend's Nexus 4 and my "legacy" Nexus S wiping can be easily prevented. If the OPO (and maybe the Nexus 5?) is different in this respect they are probably better choices regarding security. But in fact, on devices where wiping can be prevented, implementing TWRP password security makes no sense which further lowers the number of devices which would profit from such a feature.

 

[Lanchon]

Well the question is: Does fastboot check for a flag recovery sets after wiping (so unlocking is done by fastboot) or does recovery unlock itself? If it's the latter, how does recovery actually accomplish this?

And as I said, on both my friend's Nexus 4 and my "legacy" Nexus S wiping can be easily prevented. If the OPO (and maybe the Nexus 5?) is different in this respect they are probably better choices regarding security. But in fact, on devices where wiping can be prevented, implementing TWRP password security makes no sense which further lowers the number of devices which would profit from such a feature.

1) non issue.
2) for the record, i won't believe your friend is right about the nexus 4 without further independent confirmation.